From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sat Apr  1 10:14:19 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09828
	for <megaco-archive@LISTS.IETF.ORG>; Sat, 1 Apr 2000 10:14:19 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.42E7EE40@standards.nortelnetworks.com>; Sat, 1 Apr 2000 10:08:43 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 114395 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 1 Apr 2000 10:06:57 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.9DDFA8D0@standards.nortelnetworks.com>; Sat, 1 Apr 2000 9:56:57
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id KAA29678; Sat, 1 Apr
          2000 10:01:48 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id KAA19040; Sat, 1 Apr
          2000 10:01:47 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <H9RHQKXQ>; Sat, 1 Apr 2000 09:57: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:  <4FBEA8857476D311A03300204840E1CF64CFF5@whq-msgusr-02.fore.com>
Date:         Sat, 1 Apr 2000 10:01:40 -0500
Reply-To: "Rosen, Brian" <brosen@FORE.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <brosen@FORE.COM>
Subject:      Re: Interim AH in MEGACO
X-To:         J Ramachandra <JRamachandra@axestech.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I'll need to do some more checking, but at first glance I think you
have found an error, and it should be 24 - 64 hex digits.

The port number question is very interesting.  It's hard not to conclude
that
it's the destination port number, as that would be the one in the UDP
header.
However, the most useful one would be the source port, as it's more useful
to aid in anti-spoofing.  I think we had better not go there, and say it's
the destination port, just like it would be in the real IPSEC.

Brian

> -----Original Message-----
> From: J Ramachandra [mailto:JRamachandra@axestech.com]
> Sent: Thursday, March 30, 2000 7:25 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Interim AH in MEGACO
>
>
> Hello,
>
> I have a couple of questions on Interim AH Scheme.
>
> The MEGACO V16 document (section 10.2) refers to RFC 2402
> Section 5. This in turn refers to RFC 2403 (HMAC-MD5-96)
> and RFC 2404 (HMAC-SHA-1-96)as two possible options. These
> two algorithms produce 128 and 160 bits authenticator value,
> but over the network only truncated 96 bits are transmitted
> to reduce the attack.
> Now, the question is, MEGACO/H.248 ABNF specifies authData
> as 32 to 64 Hex digits. Why is it not from 24 to 64
> hex digits?  Where one has to fit in the 24 hex digits(96 bits)
> in this 32 Hex digit space? OR am I missing something?
>
> Also, the same section specifies "synthesized IP header
> consisting of a 32 bit source IP address, a 32 bit destination
> address and an 16 bit UDP encoded as 10 hex digits". Which UDP
> port number to be used  (Source or destination)?
>
>
> - J.K.Ramachandra,
>   AXES TECHNOLOGIES.
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sat Apr  1 15:21:34 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11378
	for <megaco-archive@LISTS.IETF.ORG>; Sat, 1 Apr 2000 15:21:33 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.336D78B0@standards.nortelnetworks.com>; Sat, 1 Apr 2000 15:16:06 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 114676 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 1 Apr 2000 15:14:57 -0500
Received: from fw7.usa.alcatel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.A4DBC7B0@standards.nortelnetworks.com>; Sat, 1 Apr 2000 15:04:57
          -0500
Received: (from uucp@localhost) by fw7.usa.alcatel.com (8.8.8+Sun/8.8.8) id
          OAA28748 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Sat, 1 Apr 2000
          14:09:18 -0600 (CST)
Received: from <Chuong.Nguyen@usa.alcatel.com> (relay2.usa.alcatel.com
          [143.209.238.7]) by fw7 via smap (V2.1) id xma028741; Sat, 1 Apr 00
          14:09:14 -0600
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 OAA14034 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Sat, 1 Apr 2000 14:11:07 -0600
          (CST)
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 OAA00774 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Sat, 1
          Apr 2000 14:09:07 -0600 (CST)
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 OAA19605
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Sat, 1 Apr 2000 14:09:07
          -0600 (CST)
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <F033F6FEF3F1D111BD150000F8CD1431032A9D34@zcard007.ca.nortel.com>
Content-Type: multipart/alternative;
              boundary="------------560EA567CCC60BF4AFADF5D8"
Message-ID:  <38E65763.BF5D443B@usa.alcatel.com>
Date:         Sat, 1 Apr 2000 14:09:07 -0600
Reply-To: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Subject:      Re: V16 Review - Auditing contexts and their terminations
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--------------560EA567CCC60BF4AFADF5D8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


With the proposed solution, does this make contextAudit a new command?
If yes, it should follow other commands request and response/reply
syntax.
That is the command is included in the transaction reply.
Transaction = 1 {Context = 3 {command ...}}
Reply = 1 {Context = 3 {command ..}}

See comments below.

Chuong

Nancy-M Greene wrote:

>
>
> Here are 2 issues with the ABNF that have come up on our review of
> section 7.2.5 AuditValue:
>
> 1) 7.2.5 Audit Value - auditing all matching terminations and their
> contexts
>
> Issue: The entry before the last in table we have
> "ContextID=ALL  , TerminationID= wildcard, Audit of all matching
> terminations and contexts to which they are associated."
>
> Comment: In the ABNF, the reply reads like this:
> AuditValue = contextID { t1,t2,...}
> We can't report all the contexts in this reply.
> The ABNF must be fixed to allow returning list of contexts
> rather than just one with a list of terminations.
>

Doesn't the text say something about repeating a command for each
matching wildcard found.
That is keep use AuditValue to do context and termination relationship
audit.

Transaction = 1 {Context = * {AuditValue=*{Audit{ContextAudit}}}

(Have to add a ContextAuditToken to auditItem in ABNF first)

Reply = 1 {Context = 1 {AuditValue = contextAudit{t1,t2}},
                   Context = 2 {AuditValue =
contextAudit{t3,t4}}.......}


or go with the Nancy's proposed solution but make contextAudit a new
command.

>
> 2) 7.2.5 Audit Value - return all context ids
>
> Issue: The last entry in the table is:
> ContextID=All, TerminationID=Root, list of all contextIDs,
>
> Comment: The ABNF does not allow a list of contextIDs
> returned on the audit. This has to be fixed to allow list of
> contexts.
>
> Also, we need to check whether the ASN.1 handles these 2 cases
> correctly.
>
> Proposal: A proposal for solving these 2 issues in the ABNF:
>
> Auditing a context does not belong to any particular command. So it
> should stay out of AuditRequest. We already have a contextAudit in the
>
> ABNF, so we should use it instead.
>
> Case 1: List of all contexts and all terminations:
> Request: Context = ALL {ContextAudit{Terminations}, othercommands
> ....}
> Reply: Context=All {Root { Cid1 { t1,t2,3....}, Cid2 { ....}}, other
> replies}
> ; Terminations will be a new token added to contextAuditProperties
> ; and we will need RootDescriptor (list of lists as above)
>

Reply = 1 {Context = 1 {ContextAudit = {t1,t2},
                    Context = 2 {ContextAudit = {t3,t4},
                   Context = maxContext {ContextAudit = t4r4,t3434},
                  Context = 2 {other command reply...}, etc }

Assuming ContextAudit is classified as a new command.

>

>
> Case 2: All terminations and a specific context
> Request: Context=Cid {ContextAudit{Terminations}, othercommands ...}
> Reply: Context=Cid { Terminations { t1,2,t3, ...}, other replies}
> ; same as above but with TerminationsDescriptor this time (list of
> ; terminations
>

Reply:  Context=Cid {ContextAudit = {t1, t2, ...}}

>
> Case 3: All contexts, no terminations
> Request: Context=Cid or ALL {ContextAudit{Root}, othercommands ...}
> Reply: Context=Cid or ALL { Contexts { cid1,cid2,cid3, ...}, other
> replies}
> ; RootToken, ContextsToken and ContextsDescriptor.
>

Reply:  Context = cid1, Context= cid2, .....

The transaction might get too large but it seems to follow other
commands convention for
a transaction reply.


>
> This way we avoid falling into explaining AuditValue or
> AuditCapability
> for context audit and at the same time, auditing context at the
> context
> level. Also, remove contextTerminationsAudit from auditReply.
>
> Comments?
>
> Nancy
> Abdallah
>
>
> -------------------------------------------------------------------------
>
> Nancy M. Greene
> Internet & Service Provider Networks, Nortel Networks
> T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

--
  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 ****



--------------560EA567CCC60BF4AFADF5D8
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<br>With the proposed solution, does this make contextAudit a new command?
<br>If yes, it should follow other commands request and response/reply
syntax.
<br>That is the command is included in the transaction reply.
<br>Transaction = 1 {Context = 3 {command ...}}
<br>Reply = 1 {Context = 3 {command ..}}
<p>See comments below.
<p>Chuong
<p>Nancy-M Greene wrote:
<blockquote TYPE=CITE>&nbsp;
<p><font face="Arial"><font size=-1>Here are 2 issues with the ABNF that
have come up on our review of</font></font>
<br><font face="Arial"><font size=-1>section 7.2.5 AuditValue:</font></font>
<p><font face="Arial"><font size=-1>1) 7.2.5 Audit Value - auditing all
matching terminations and their</font></font>
<br><font face="Arial"><font size=-1>contexts</font></font>
<p><font face="Arial"><font size=-1>Issue: The entry before the last in
table we have</font></font>
<br><font face="Arial"><font size=-1>"ContextID=ALL&nbsp; , TerminationID=
wildcard, Audit of all matching</font></font>
<br><font face="Arial"><font size=-1>terminations and contexts to which
they are associated."</font></font>
<p><font face="Arial"><font size=-1>Comment: In the ABNF, the reply reads
like this:</font></font>
<br><font face="Arial"><font size=-1>AuditValue = contextID { t1,t2,...}</font></font>
<br><font face="Arial"><font size=-1>We can't report all the contexts in
this reply.</font></font>
<br><font face="Arial"><font size=-1>The ABNF must be fixed to allow returning
list of contexts</font></font>
<br><font face="Arial"><font size=-1>rather than just one with a list of
terminations.</font></font>
<br>&nbsp;</blockquote>
Doesn't the text say something about repeating a command for each matching
wildcard found.
<br>That is keep use AuditValue to do context and termination relationship
audit.
<p>Transaction = 1 {Context = * {AuditValue=*{Audit{ContextAudit}}}
<p>(Have to add a ContextAuditToken to auditItem in ABNF first)
<p>Reply = 1 {Context = 1 {AuditValue = contextAudit{t1,t2}},
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Context = 2 {AuditValue = contextAudit{t3,t4}}.......}
<br>&nbsp;
<p>or go with the Nancy's proposed solution but make contextAudit a new
command.
<blockquote TYPE=CITE>&nbsp;
<br><font face="Arial"><font size=-1>2) 7.2.5 Audit Value - return all
context ids</font></font>
<p><font face="Arial"><font size=-1>Issue: The last entry in the table
is:</font></font>
<br><font face="Arial"><font size=-1>ContextID=All, TerminationID=Root,
list of all contextIDs,</font></font>
<p><font face="Arial"><font size=-1>Comment: The ABNF does not allow a
list of contextIDs</font></font>
<br><font face="Arial"><font size=-1>returned on the audit. This has to
be fixed to allow list of</font></font>
<br><font face="Arial"><font size=-1>contexts.</font></font>
<p><font face="Arial"><font size=-1>Also, we need to check whether the
ASN.1 handles these 2 cases</font></font>
<br><font face="Arial"><font size=-1>correctly.</font></font>
<p><font face="Arial"><font size=-1>Proposal:</font></font> <font face="Arial"><font size=-1>A
proposal for solving these 2 issues in the ABNF:</font></font>
<p><font face="Arial"><font size=-1>Auditing a context does not belong
to any particular command. So it</font></font>
<br><font face="Arial"><font size=-1>should stay out of AuditRequest. We
already have a contextAudit in the</font></font>
<br><font face="Arial"><font size=-1>ABNF, so we should use it instead.</font></font>
<p><font face="Arial"><font size=-1>Case 1: List of all contexts and all
terminations:</font></font>
<br><font face="Arial"><font size=-1>Request: Context = ALL {ContextAudit{Terminations},
othercommands ....}</font></font>
<br><font face="Arial"><font size=-1>Reply: Context=All {Root { Cid1 {
t1,t2,3....}, Cid2 { ....}}, other replies}</font></font>
<br><font face="Arial"><font size=-1>; Terminations will be a new token
added to contextAuditProperties</font></font>
<br><font face="Arial"><font size=-1>; and we will need RootDescriptor
(list of lists as above)</font></font>
<br>&nbsp;</blockquote>
Reply = 1 {Context = 1 {ContextAudit = {t1,t2},
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Context = 2 {ContextAudit = {t3,t4},
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Context = maxContext {ContextAudit = t4r4,t3434},
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Context = 2 {other command reply...}, etc }
<p>Assuming ContextAudit is classified as a new command.
<blockquote TYPE=CITE>&nbsp;</blockquote>

<blockquote TYPE=CITE>&nbsp;
<br><font face="Arial"><font size=-1>Case 2: All terminations and a specific
context</font></font>
<br><font face="Arial"><font size=-1>Request: Context=Cid {ContextAudit{Terminations},
othercommands ...}</font></font>
<br><font face="Arial"><font size=-1>Reply: Context=Cid { Terminations
{ t1,2,t3, ...}, other replies}</font></font>
<br><font face="Arial"><font size=-1>; same as above but with TerminationsDescriptor
this time (list of</font></font>
<br><font face="Arial"><font size=-1>; terminations</font></font>
<br>&nbsp;</blockquote>
Reply:&nbsp; Context=Cid {ContextAudit = {t1, t2, ...}}
<blockquote TYPE=CITE>&nbsp;
<br><font face="Arial"><font size=-1>Case 3: All contexts, no terminations</font></font>
<br><font face="Arial"><font size=-1>Request: Context=Cid or ALL {ContextAudit{Root},
othercommands ...}</font></font>
<br><font face="Arial"><font size=-1>Reply: Context=Cid or ALL { Contexts
{ cid1,cid2,cid3, ...}, other replies}</font></font>
<br><font face="Arial"><font size=-1>; RootToken, ContextsToken and ContextsDescriptor.</font></font>
<br>&nbsp;</blockquote>
Reply:&nbsp; Context = cid1, Context= cid2, .....
<p>The transaction might get too large but it seems to follow other commands
convention for
<br>a transaction reply.
<br>&nbsp;
<blockquote TYPE=CITE>&nbsp;
<br><font face="Arial"><font size=-1>This way we avoid falling into explaining
AuditValue or AuditCapability</font></font>
<br><font face="Arial"><font size=-1>for context audit and at the same
time, auditing context at the context</font></font>
<br><font face="Arial"><font size=-1>level. Also, remove contextTerminationsAudit
from auditReply.</font></font>
<p><font face="Arial"><font size=-1>Comments?</font></font>
<p><font face="Arial"><font size=-1>Nancy</font></font>
<br><font face="Arial"><font size=-1>Abdallah</font></font>
<p><font face="MS Sans Serif"><font size=-1>--------------------------------------------------------------------------</font></font>
<br><font face="MS Sans Serif"><font size=-1>Nancy M. Greene</font></font>
<br><font face="MS Sans Serif"><font size=-1>Internet &amp; Service Provider
Networks, Nortel Networks</font></font>
<br><font face="MS Sans Serif"><font size=-1>T:514-271-7221 (internal:ESN853-1077)
E:ngreene@nortelnetworks.com</font></font></blockquote>

<pre>--&nbsp;
&nbsp; Alcatel USA, Inc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Internet: Chuong.Nguyen@usa.alcatel.com
&nbsp; 1000 Coit Road Plano, Texas 75075&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Phone:&nbsp;&nbsp;&nbsp; (972) 519-4613
&nbsp; **** The opinions expressed are not those of Alcatel USA, Inc ****</pre>
&nbsp;</html>

--------------560EA567CCC60BF4AFADF5D8--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sat Apr  1 15:41:32 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11485
	for <megaco-archive@LISTS.IETF.ORG>; Sat, 1 Apr 2000 15:41:32 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.00EB2510@standards.nortelnetworks.com>; Sat, 1 Apr 2000 15:36:09 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 114720 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 1 Apr 2000 15:34:10 -0500
Received: from fw7.usa.alcatel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.53BCB120@standards.nortelnetworks.com>; Sat, 1 Apr 2000 15:24:09
          -0500
Received: (from uucp@localhost) by fw7.usa.alcatel.com (8.8.8+Sun/8.8.8) id
          OAA00986 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Sat, 1 Apr 2000
          14:28:24 -0600 (CST)
Received: from <Chuong.Nguyen@usa.alcatel.com> (relay2.usa.alcatel.com
          [143.209.238.7]) by fw7 via smap (V2.1) id xma000977; Sat, 1 Apr 00
          14:28:13 -0600
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 OAA16420 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Sat, 1 Apr 2000 14:30:06 -0600
          (CST)
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 OAA04942 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Sat, 1
          Apr 2000 14:28:38 -0600 (CST)
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 OAA03623
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Sat, 1 Apr 2000 14:28:38
          -0600 (CST)
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="------------3B5F4C572B521D208F444EEA"
Message-ID:  <38E65BF6.35E71B82@usa.alcatel.com>
Date:         Sat, 1 Apr 2000 14:28:38 -0600
Reply-To: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Subject:      Modify Request Syntax
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--------------3B5F4C572B521D208F444EEA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hi

In ABNF,
ammRequest = (AddToken / MoveToken / ModifyToken) EQUAL TerminationID
                           [LBRKT ammParameter *(COMMA ammParameter)
RBRKT]

If an MGC send a Modify w/o any ammParameter should MG reply with error
code 442,
"Syntax Error in Command" even thought ABNF allows it.

Transaction = 1 {Context=1{Modify=t1}}

Or should the MG treats this modify as a no-op operation and reply with
the following?
Reply = 1 {context = 1{Modify=t1}}

If MG should reply w/error descriptor, can I do the following to do a
no-op Modify
Transaction = 1 { Context =1 {Modify=t1{Audit{} }}}

and expect MG to reply with the following:
Reply = 1 {Context = 1{Modify=t1}}


Thanks
Chuong

--
  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 ****



--------------3B5F4C572B521D208F444EEA
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<br>Hi
<p>In ABNF,
<br>ammRequest = (AddToken / MoveToken / ModifyToken) EQUAL TerminationID
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[LBRKT ammParameter *(COMMA ammParameter) RBRKT]
<p>If an MGC send a Modify w/o any ammParameter should MG reply with error
code 442,
<br>"Syntax Error in Command" even thought ABNF allows it.
<p>Transaction = 1 {Context=1{Modify=t1}}
<p>Or should the MG treats this modify as a no-op operation and reply with
the following?
<br>Reply = 1 {context = 1{Modify=t1}}
<p>If MG should reply w/error descriptor, can I do the following to do
a no-op Modify
<br>Transaction = 1 { Context =1 {Modify=t1{Audit{} }}}
<p>and expect MG to reply with the following:
<br>Reply = 1 {Context = 1{Modify=t1}}
<br>&nbsp;
<p>Thanks
<br>Chuong
<pre>--&nbsp;
&nbsp; Alcatel USA, Inc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Internet: Chuong.Nguyen@usa.alcatel.com
&nbsp; 1000 Coit Road Plano, Texas 75075&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Phone:&nbsp;&nbsp;&nbsp; (972) 519-4613
&nbsp; **** The opinions expressed are not those of Alcatel USA, Inc ****</pre>
&nbsp;</html>

--------------3B5F4C572B521D208F444EEA--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sat Apr  1 22:49:53 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16277
	for <megaco-archive@LISTS.IETF.ORG>; Sat, 1 Apr 2000 22:49:53 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D1BBB610@standards.nortelnetworks.com>; Sat, 1 Apr 2000 22:44:20 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 114862 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 1 Apr 2000 22:42:49 -0500
Received: from smtp10.atl.mindspring.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.35E4A680@standards.nortelnetworks.com>; Sat, 1 Apr 2000 22:32:49
          -0500
Received: from paris.mds.local (user-2ivf73m.dialup.mindspring.com
          [165.247.156.118]) by smtp10.atl.mindspring.net (8.9.3/8.8.5) with
          ESMTP id WAA09718 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Sat, 1
          Apr 2000 22:37:53 -0500 (EST)
Received: from berlin (berlin.mds.local [192.168.1.4]) by paris.mds.local
          (8.8.7/8.8.7) with SMTP id WAA16891 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Sat, 1 Apr 2000 22:37:41 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Message-ID:  <00bd01bf9c54$de1139c0$0401a8c0@mds.local>
Date:         Sat, 1 Apr 2000 22:38:09 -0500
Reply-To: "Paul E. Jones" <paul.jones@TIES.ITU.CH>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Paul E. Jones" <paul.jones@TIES.ITU.CH>
Subject:      New web site packetizer.com
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Folks,

Paul Long and I have created a new web site dedicated to providing
information regarding packet-based multimedia conferencing protocols,
including H.323, SIP, MGCP, Megaco/H.248, and others.

The web site is http://www.packetizer.com/ and it is intended to serve the
end-user, engineer, and executive, although the focus is on the engineer.
Most of the information we have posted currently is related to H.323, though
we want to expand the site's offerings to include information on much more
than that.

Contributors Wanted

This is a cooperative effort. Besides announcing the site, this email
invites _your_ input. If you have any information regarding these or other
packet-based multimedia protocols that you can share and would be of
interest to others, please forward it to us so that we can make it public on
this web site. We will attribute the work to you unless you request us not
to. We provide the web space, bandwidth, organization, indexing, and focus;
you provide information that is in the public domain or whose copyright you
or your organization own and does not contain trade secrets. We don't want
to get sued; you don't want to get fired. :-) Your contribution can be as
simple as a single tip for solving a particularly nasty implementation issue
or clarification of some aspect of a standard or as involved as a complete
tutorial on a particular protocol. See the list below for ideas. Conversely,
if there is something that you would like to see, please let us know. Maybe
we can find someone to write something up or maybe we can maintain a "wish
list" on the site for future contributions.

Contributions

Here is a list of the types of contributions for which we are looking. It is
likely that you already have things like this lying around somewhere that
you had to put together for your own use or use within your organization.
Let's share!

- Summary
- Primer
- Tutorial
- Implementation guide
- Implementation notes
- Cheat sheet
- Glossary
- Protocol comparisons
- Links to other online resources
- Description of how to participate, e.g., how to subscribe to the email
  reflectors and location of reflector archives
- List of standards organization(s) working in an area, with contact and
  membership info
- Diagrams
- FAQ
- Upcoming event sponsored by your company or institution, e.g., seminar or
  panel discussion

Kindest Regards,
Paul E. Jones, Editor of the H.323 Recommendation


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Apr  3 06:26:30 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15728
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 3 Apr 2000 06:26:30 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7E5B34F0@standards.nortelnetworks.com>; Mon, 3 Apr 2000 6:18:57 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 116236 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 3 Apr 2000 06:17:35 -0400
Received: from smtp1.cluster.oleane.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.4D253ED0@standards.nortelnetworks.com>; Mon, 3 Apr 2000 6:17:34
          -0400
Received: from oleane  (dyn-1-1-224.Vin.dialup.oleane.fr [195.25.4.224])  by
          smtp1.cluster.oleane.net  with SMTP id LAA51034; Mon, 3 Apr 2000
          11:21:47 +0200 (CEST)
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_00DA_01BF9D66.A30B1220"
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:  <00dd01bf9d55$e0872f00$0401a8c0@oleane.com>
Date:         Mon, 3 Apr 2000 12:17:53 +0200
Reply-To: Peter Lewis <peter.lewis@UPPERSIDE.FR>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and
              ignored.
From: Peter Lewis <peter.lewis@UPPERSIDE.FR>
Subject:      SIP 2000 International Conference
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_00DA_01BF9D66.A30B1220
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Unknown and even rejected by many vendors and operators only a few =
months ago, SIP is on the brink of making a definitive name for itself.=20
Visit the SIP 2000 International Conference programme:
http://www.upperside.fr/basip.htm



------=_NextPart_000_00DA_01BF9D66.A30B1220
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV>Unknown and even rejected by many vendors and operators only a few =
months=20
ago, SIP is on the brink of making a definitive name for itself. </DIV>
<DIV>Visit the SIP 2000 International Conference programme:</DIV>
<DIV><A=20
href=3D"http://www.upperside.fr/basip.htm">http://www.upperside.fr/basip.=
htm</A></DIV>
<DIV></FONT><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_00DA_01BF9D66.A30B1220--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Apr  3 09:59:07 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17331
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 3 Apr 2000 09:59:05 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6B6A7040@standards.nortelnetworks.com>; Mon, 3 Apr 2000 9:53:10 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 116413 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 3 Apr 2000 09:51:24 -0400
Received: from hoemail2.firewall.lucent.com (192.11.226.163) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.2BC28270@standards.nortelnetworks.com>; Mon, 3 Apr 2000 9:51:23
          -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 JAA04011
          for <MEGACO@standards.nortelnetworks.com>; Mon, 3 Apr 2000 09:56:33
          -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
          JAA03974 for <MEGACO@standards.nortelnetworks.com>; Mon, 3 Apr 2000
          09:56:31 -0400 (EDT)
Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id PAA11687; Mon, 3
          Apr 2000 15:56:26 +0200 (MET DST)
Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id
          PAA11683; Mon, 3 Apr 2000 15:56:25 +0200 (MET DST)
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <C51ED84B6F47D211917A0000F8BCBD11033227DB@zcard00g.ca.nortel.com>
Content-Type: multipart/mixed; boundary="------------2F3421D2BACF1F65A4DBD5AC"
Message-ID:  <38E8A2F1.C5114CF5@lucent.com>
Date:         Mon, 3 Apr 2000 15:56:01 +0200
Reply-To: John Segers <jsegers@LUCENT.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: John Segers <jsegers@LUCENT.COM>
Organization: Lucent Technologies
Subject:      Re: Summary of Issues Raised On the List
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.
--------------2F3421D2BACF1F65A4DBD5AC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom,

This is good work.  I compared your list of issues to the list I keep
myself (with input from others as well) and have some issues to add (see
attachment).

Cheers,

John

Tom-PT Taylor wrote:
>
> Attached please find a summary of the issues raised on the list.  The
> contents should be self-evident.  Please pay special attention to section 4:
> we MUST close off on these issues within the next week so we can end Last
> Call in timely fashion.
>  <<errata.txt>>
>
> Tom Taylor
> Advisor -- Emerging Carrier IP Standards
> E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
> Phone and FAX: +1 613 736 0961
>
> Media Gateway Control                                       P.T. Taylor
> Internet Draft                                          Nortel Networks
> Document: draft-ietf-megaco-errata-00.txt                    March 2000
> Category: Standards Track
>
>       Corrections To the Determined Megaco/H.248 Protocol Document
>
> Status of this Memo
>
>    This document is an Internet-Draft and is in full conformance with
>    all provisions of Section 10 of RFC2026 [1].
>
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF), its areas, and its working groups. Note that
>    other groups may also distribute working documents as Internet-
>    Drafts. Internet-Drafts are draft documents valid for a maximum of
>    six months and may be updated, replaced, or obsoleted by other
>    documents at any time. It is inappropriate to use Internet- Drafts
>    as reference material or to cite them other than as "work in
>    progress."
>    The list of current Internet-Drafts can be accessed at
>    http://www.ietf.org/ietf/1id-abstracts.txt
>    The list of Internet-Draft Shadow Directories can be accessed at
>    http://www.ietf.org/shadow.html.
>
> 1. Abstract
>
>    This document records the errors found in the draft Megaco/H.248
>    protocol document [2], along with the changes proposed in the text
>    of that document to resolve them. After joint IETF/ITU-T Study Group
>    16 approval of these corrections, they will be incorporated into the
>    final decided version of H.248 and the corresponding Megaco protocol
>    RFC.
>
> 2. Conventions used in this document
>
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
>    this document are to be interpreted as described in RFC-2119 [1].
>
> Taylor           Standards Track -- Expires Sep 2000                 1
>                        Megaco/H.248 Corrections             March 2000
>
> 3. Issues Not Found To Require Changes
>
>    This section lists a few of the issues raised on the Megaco list
>    which were found not to require a change in [2].  There were a
>    number of other such issues which may be recorded here as a matter
>    of record pending completion of IESG Last Call.  This section will
>    be deleted from the final document submitted into the ITU-T Study
>    Group 16 decision process.  All section numbers are from [2].
>
>    Section    Problem                         Resolution
>    7.1.9      Discarding of buffered events   No change.  Reasonable
>               when EventBufferControl is      case for making a
>               changed to OFF is               different decision from
>               inconsistent with provision     the one made in Geneva,
>               for notification of multiple    but not actually an
>               events at once in latter        error.
>               state.
>
>    7.1.11     Last bullet list and            Not an error or
>               preceding sentence simply       ambiguity, no action.
>               recapitulate definition of
>               KeepActive flag.
>    7.2.5,     Relationship between text and   Clarification, not
>    7.2.6      representation of wildcarded    ambiguity or error.
>               audit request is not clear.
>
> 4. Issues Identified But Not Yet Resolved
>
>    This section, as its title implies, contains issues which have been
>    identified in discussion on the list but for which a final
>    resolution has not been achieved.  All of these issues must be
>    resolved or moved to the previous section before Last Call can be
>    declared complete.  Hence this section will be deleted before this
>    document is submitted to the IESG for final approval.
>
>    Section                              Issue
>
>    6.2.2      Not clear what wildcard union responses look like.
>
>    7.1.1      Third para (discussing unspecified parameters): not clear
>               which parameters are mandatory.
>
> Taylor           Standards Track -- Expires Sep 2000                 2
>                        Megaco/H.248 Corrections             March 2000
>
>    7.1.9      Not clear whether events trigger side effects (e.g.
>               signal termination) at time of detection, at time of
>               processing (whether or not in active Events Descriptor)
>               or at time of notification.
>
>    7.1.14     Not clear whether non-matched events trigger side effects
>               at time of processing against digit map or when processed
>               against active Events Descriptor following digit map
>               completion event detection.
>
>    7.1.17     Not clear whether AuditValue of ObservedEventsDescriptor
>               reports events captured in current dial string of active
>               digit map.
>
>    7.3        There should be no error        Delete codes 404, 405,
>               responses to TransactionReply   461-467
>               or TransactionPending, lest
>               they create response loops.
>
>    8          Command execution should be     Not clear what "atomic"
>               specified as atomic.            means, particularly
>                                               where events and signals
>                                               are concerned.
>
>    12.2,      Text indicates that statistics can have the sub-list data
>    B.2        type, but ABNF does not support that.
>
>    B.2        Syntax for parmValue confounds over-specification and
>               sub-lists.
>
>    C.8        Length of GIT is wrong.
>
> Taylor           Standards Track -- Expires Sep 2000                 3
>                        Megaco/H.248 Corrections             March 2000
>
>    D.1.4      Second para: transaction originator may not have received
>               TransactionPending response(s) because they were lost,
>               and may therefore not know that responder is expecting
>               immediate acknowledgement of the TransactionReply.
>
>    E.1.2      Granularity of signal completion event is too coarse as a
>               mechanism to detect signalling failures.
>
>    E.9.2      Stated hook state reporting behaviour has race condition
>               where same transition could be reported twice.
>
>    E.10.2     Wording of condition for generating cmp event with
>               "success" does not cover case where test also requires
>               successful removal of tone.
>
> 5. Errors For Which Corrections Are Stated
>
>    This is the only section which will remain in this document after
>    the IESG has approved the combination of [2] and the corrections
>    stated below.  It describes the errors and ambiguities which have
>    been found in [2], along with the corrections they require.
>
>    Section    Issue                           Resolution
>
>    2          Q.724 is not used.              Delete from list of
>                                               references.
>    4          BRI is not used.                Delete from list of
>                                               abbreviations.
>    2, C       Leave Recs. referred to in      Do that.
>               Annex C undated, implying
>               latest issue.
>
> Taylor           Standards Track -- Expires Sep 2000                 4
>                        Megaco/H.248 Corrections             March 2000
>
>    6.2.4      Says that property values set   Add text to first para
>               in Null context are             third sentence: "Most
>               remembered and reinstated       properties have default
>               when termination returns to     values, which are
>               Null.  Contradicts latest       explicitly defined in
>               text in 7.2.3.                  this standard or set by
>                                               provisioning."  Delete
>                                               first para fourth
>                                               sentence, which read:
>                                               "The default value of a
>                                               property of a physical
>                                               Termination can be
>                                               changed by setting it to
>                                               a different value when
>                                               the Termination is in
>                                               the null Context."
>    6.2.4      DigitMap entry in table makes   Change existing text to
>               explicit reference to DTMF      new one as follows:
>               tones.                          "Defines patterns
>                                               against which sequences
>                                               of a specified set of
>                                               events are to be matched
>                                               so they can be reported
>                                               as a group rather than
>                                               singly."
>    7.1,       The order in which              Add text stating that
>    A.2        descriptors are processed       descriptors are
>               within a command matters, but   processed in the order
>               is not clear.  Moreover, it     in which they are
>               is fixed in the ASN.1 but       provided.  Change ASN.1
>               variable in the ABNF.           in Annex A.2 to impose
>                                               ordering as suggested by
>                                               John Segers ("Descriptor
>                                               processing order", Wed
>                                               15/03/00)
>    7.1.5,     Text allows CHOOSE for          Change ABNF:
>    B.2        property values in              propertyParm = pkgdName
>               TerminationStateDesc, but       ( "$" / parmValue)
>               ABNF does not.
>    7.1.6,     Text indicates use of "true"    Add comment in B.2 that
>    B.2        and "false" values while ABNF   "true" in text
>               uses "on" and "off"             corresponds to "on" in
>                                               ABNF, and "false"
>                                               corresponds to "off".
>    7.1.8      Last bulleted item should       Add "loopback".
>               include "loopback" in list of
>               possible states.
>
> Taylor           Standards Track -- Expires Sep 2000                 5
>                        Megaco/H.248 Corrections             March 2000
>
>    7.1.9      EventDM is part of syntax but   Add text: "If a digit
>               not mentioned in section.       map is required in the
>                                               EventsDescriptor,
>                                               EventDM is used to carry
>                                               either the name or the
>                                               value of the digit map.
>                                               See section 7.1.14."
>    7.1.9      Case 1, step 2(a) is both       Fix separation of
>               incorrectly formulated and      paragraphs.  Change step
>               incorrectly formatted.          2(a) to read: "While
>               Existing logic may result in    waiting for a new
>               an infinite loop.               EventsDescriptor, any
>                                               events detected which
>                                               appear in the current
>                                               EventsBufferDescriptor
>                                               will be placed in the
>                                               EventBuffer.  When a new
>                                               EventDescriptor is
>                                               received, event
>                                               processing repeats from
>                                               step 1."
>    7.1.13     Missing "extension"             Add missing component.
>               component.
>    7.1.14     Item 5 in second numbered       Add the words "and it
>               list  understates conditions    has been fully matched"
>               for digit map completion when   to the existing sentence
>               single candidate remains.
>
>    7.1.18     Third bullet attached to        Delete the clause ";
>               third para: says loopback       loopbacks are created by
>               achieved by manipulating        setting the
>               TerminationMode, which no       TerminationMode"
>               longer has that name.
>    7.2.5      Fails to indicate what          Add the following text:
>               AuditValue for                  "EventBuffer returns the
>               EventBufferDescriptor returns   set of events and
>                                               associated parameter
>                                               values currently enabled
>                                               in the
>                                               EventBufferDescriptor."
>    7.2.5,     Text and ASN.1 allow return     Fix production
>    B.2        of results involving multiple   contextTerminationAudit
>               contexts, but ABNF does not.    by allowing return of
>                                               list of context-specific
>                                               results as an
>                                               alternative.
>
> Taylor           Standards Track -- Expires Sep 2000                 6
>                        Megaco/H.248 Corrections             March 2000
>
>    7.2.5,     Does not indicate how an        Change syntax of
>    A.2,       audit of digit maps returns     DigitMapDescriptor to
>    B.2        unnamed digit maps.             allow return of unnamed
>                                               digit maps per John
>                                               Seger suggestion ("[Fwd:
>                                               Issues In v16 Draft]",
>                                               Wed 15/03/00).
>    7.2.6      Fails to indicate what
>               AuditCapabilities for           "EventBuffer returns the
>                                               Add the following text:
>               EventBufferDescriptor returns   same information as
>                                               Events."
>    7.2.6,     Inconsistency regarding         Add comment to B.2
>    B.2        permissibility of DigitMap or   "auditItem" production
>               Packages as capability audit    indicating that DigitMap
>               items.                          and Packages are not
>                                               allowed in the
>                                               AuditCapabilities
>                                               command.
>    7.2.8      Paragraph beginning "A          Add text to the
>               ServiceChange Command           offending sentence, so
>               specifying the Root..."         that it reads:
>               immediately following the       "Acknowledgement of the
>               description of ServiceChange    ServiceChange Command
>               Descriptor parameters           completes the
>               erroneously states that the     registration process,
>               response to the ServiceChange   except when the MGC has
>               command terminates the          returned an alternative
>               registration process.  This     ServiceChangeMgcId as
>               is so only if the response      described in the next
>               does not specify an alternate   paragraph."
>               MGC.
>
>    7.3        Text for error code 403         Change text to "Syntax
>               should be consistent with       error in
>               that for 404 and 405.           TransactionRequest"
>
>    8.2.2      Final para has wrong text for   Change to "Syntax Error
>               error code 442.                 in Command"
>
>    11.2       Second paragraph last           Restore original
>               sentence inadvertently          sentence: "If the MG is
>               modified -- duplicates          unable to establish a
>               material in 11.3.               control relationship
>                                               with any MGC, it shall
>                                               wait a random amount of
>                                               time as described in
>                                               Section 9.2 and then
>                                               start contacting its
>                                               primary, and if
>
> Taylor           Standards Track -- Expires Sep 2000                 7
>                        Megaco/H.248 Corrections             March 2000
>
>                                               necessary, its secondary
>                                               MGCs again."
>
>    11.4       Second para: wrong MG is        Change fourth sentence
>               specified as the one to be      to refer to "secondary
>               used after failover.            MG" rather than "primary
>                                               MG".
>    12.1.4     Note says that default          Add TO signals to note.
>               duration should be specified
>               for BR signals.  This also
>               applies to TO signals.
>    A.2        LocalControlDescriptor still
>               contains reserve rather than    separate reserveValue
>               reserveValue and                and reserveGroup
>                                               Replace reserve with
>               reserveGroup.                   Booleans.
>
>    A.2        Assigned object identifier      Add object identifier
>               missing.                        line with content
>                                               "itu-t recommendation h
>                                               248 media-gateway-
>                                               control(0)"
>    B.2        Syntax for parmValue and
>               VALUE together make parsing     in alternativeValue by
>                                               Replace range notation
>               of range ambiguous.             "LSBRKT VALUE COLON
>                                               VALUE RSBRKT"
>    B.2        Error in syntax for
>               digitMapDescriptor: value       digitMapDescriptor =
>                                               Change production:
>               meant to be optional.           DigitMapToken EQUAL
>                                               digitMapName
>                                               [ LBRKT digitMapValue
>                                               RBRKT ]
>    B.2        VersionToken not defined.       Add ABNF:
>                                               VersionToken =
>                                               ("Version" / "V")
>    B.2        DiscardToken not used.          Delete production.
>    C.9        ITC has reference to missing    Delete reference.
>               note 2
>
>    C.9        Not clear that Q.931 Bearer     Specify that values are
>               Capability IE rather than Low   those valid for Bearer
>               Layer Compatibility IE is       Capability IE
>               being used.
>
> Taylor           Standards Track -- Expires Sep 2000                 8
>                        Megaco/H.248 Corrections             March 2000
>
>    D.1        Even in the case of handoff     In the last sentence of
>               or failover, the originating    the first paragraph,
>               MGC needs confirmation that     delete the excepting
>               its command was received.       clause, so that the
>                                               sentence reads:
>                                               "Responses must be sent
>                                               to the address and port
>                                               from which the
>                                               corresponding commands
>                                               were sent."
>    D.1.1      Second para last sentence
>               provides a procedural
>               reference to 8.2.3.  Should
>               refer to UDP-specific
>                                               Add reference to D.1.4.
>               procedures.
>
>    D.1.4      First paragraph, last
>               sentence talks about when to    SHOULD send this
>               send the Transaction Pending    response if they receive
>               response.  When UDP/ALF is in   a repetition of a
>               use, the originator of a        transaction that is
>               transaction may repeat it       still being executed."
>               because it has not received
>               an acknowledgement that the
>               transaction was received.  An
>               appropriate response to a
>               duplicate transaction which
>               is still being processed is
>               to return Transaction
>                                               Add the sentence: "They
>               Pending.
>
>    D.1.5      Last paragraph is equivocal     Change the two sentences
>               about what                      following the phrase "_
>               ServiceChangeReason to use      and it begins its
>               when recovering from loss of    recovery process" to
>               contact; it must always be      read as follows: "The MG
>               "Disconnected".                 shall use a
>                                               ServiceChange with
>                                               ServiceChangeMethod set
>                                               to disconnected so that
>                                               the new MGC will be
>                                               aware that the MG lost
>                                               one or more
>                                               transactions."
>    E.6.2      "Long duration event            Replace with "Z".
>               modifier" is shown as "L" in
>               parameter DigitString --
>               should be "Z".
>
> Taylor           Standards Track -- Expires Sep 2000                 9
>                        Megaco/H.248 Corrections             March 2000
>
>    Appx       Step 20 fails to show a         Add the following to the
>    A.1.2      returned                        Media Descriptor
>               TerminationStateDescriptor      preceding the line
>                                               "Stream = 1_":
>                                               "TerminationState {
>                                               ServiceStates =
>                                               InService,
>                                               EventBufferControl = OFF
>                                               },"
>
> 6. Security Considerations
>
>    This draft is a supplement to [2], which contains the required
>    security section.
>
> 7. References
>
>    [1] RFC 2026
>    [2] draft-ietf-megaco-protocol-07.txt
>    [3] RFC 2119
>
> 8. Acknowledgments
>
>    This draft records the contributions of a number of people on the
>    Megaco list who took the time to read the Megaco/H.248 draft with
>    care and attention.  Thanks to all of them.
>
> 9. Author's Addresses
>
>    Tom Taylor
>    Nortel Networks
>    P.O. Box 3511, Station C
>    Ottawa, Ontario, Canada K1Y 4P7
>    Phone: +1 613 736 0961
>    Email: taylor@nortelnetworks.com
>
> Taylor           Standards Track -- Expires Sep 2000                10
>                        Megaco/H.248 Corrections             March 2000
>
> Full Copyright Statement
>
>    "Copyright (C) The Internet Society (date). All Rights Reserved.
>    This document and translations of it may be copied and furnished to
>    others, and derivative works that comment on or otherwise explain it
>    or assist in its implmentation may be prepared, copied, published
>    and distributed, in whole or in part, without restriction of any
>    kind, provided that the above copyright notice and this paragraph
>    are included on all such copies and derivative works. However, this
>    document itself may not be modified in any way, such as by removing
>    the copyright notice or references to the Internet Society or other
>    Internet organizations, except as needed for the purpose of
>    developing Internet standards in which case the procedures for
>    copyrights defined in the Internet Standards process must be
>    followed, or as required to translate it into other languages.
>
>    1  Bradner, S., "Key words for use in RFCs to Indicate Requirement
>       Levels", BCP 14, RFC 2119, March 1997
>
> Taylor           Standards Track -- Expires Sep 2000                11

--
John Segers                                  email: jsegers@lucent.com
Lucent Technologies                                        Room HE 306
Dept. Forward Looking Work                      phone: +31 35 687 4724
P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954
--------------2F3421D2BACF1F65A4DBD5AC
Content-Type: text/plain; charset=us-ascii;
 name="Comments megaco.txt"
Content-Disposition: inline;
 filename="Comments megaco.txt"
Content-Transfer-Encoding: 7bit

Issues raised on the Megaco list

This note captures some issues raised on the Megaco list after ITU-T SG16
redetermined H.248.  The issues mentioned here are not mentioned in Tom
Taylor's internet draft draft-ietf-megaco-errata-00.txt.  Some of the
issues mentioned below are closed, which case the resolution is stated, and
some remain open as yet.

Section Issue

2.      Reference to I.363.5 (AAL5) is missing.

        Proposed resolution: add reference.

2.      Reference to RFC 1661 (PPP) is missing.

        Proposed resolution: add reference.

7.1.1   The text refers to "the previous value" of parameters, although
        there may not always be a previous value.

        Proposed resolution: add text saying that initially all parameters
        are empty (see email from Flemming Andreasen 2000/03/28 "Re: V16
        review - Editorial comments".

7.1.9   Seventh paragraph, starting "When the MG receives a command with
        [...]".  The text does not say that the new events descriptor is
        used in processing the buffered events.

        Proposed resolution:  Add a sentence "The buffered events are
        processed using the new events descriptor." after the first
        sentence.

7.1.14  Various points related to digit map processing.  See messages from
        Flemming Andreasen and Tom Taylor on Megaco list, 2000/03/16-17.

7.1.18  Editorial corrections:
        * first bullet list, first entry: change "nor vice versa" to "and
          vice versa";
        * the word "be" is missing from the last sentence of the section.

7.2.3   The bullet list at the end of the section mentions provisioned and
        default values that contradicts the (older) text in section 6.2.4.

A.2     Two errors in the ASN.1 specification.
        * In EventBufferControl, the values ("Off" and "LockStep") are
          capitalized.  The initial caps have to be removed.
        * "IA5STRING" has to be replaced by "IA5String".

B.2     Both "TransactionID" and "TransactionId" are used in the ABNF.
        Strictly speaking, this is not in error, but it is better to use
        "TransactionId" throughout the section.

C.8     Generic Identifier Transport (raised by Keith Drage).
        The Megaco draft specifies four octets for the GIT field, even
        though Q.2941.1 allows up to 29 octets.

        The field was introduced in Megaco to transport binding reference
        per Q.2941.3 between MGC and MG.  The problem is that Q.2941.3 is
        not yet an approved standard and cannot be referenced from
        Megaco/H.248 according to ITU rules.

        Proposed resolution: allow the full 29 octets.

E.5.3   The megaco internet draft has a typo: it says "d1" twice in the
        table, and does not have "d0".

E.13.1  Editorial correction: replace "isrequested" by "is requested".



--------------2F3421D2BACF1F65A4DBD5AC--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Apr  3 17:38:35 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25176
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 3 Apr 2000 17:38:35 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A42A39C0@standards.nortelnetworks.com>; Mon, 3 Apr 2000 17:32:53 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 116906 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 3 Apr 2000 17:31:05 -0400
Received: from fw7.usa.alcatel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.FE2089E0@standards.nortelnetworks.com>; Mon, 3 Apr 2000 17:21:05
          -0400
Received: (from uucp@localhost) by fw7.usa.alcatel.com (8.8.8+Sun/8.8.8) id
          QAA09782 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 3 Apr 2000
          16:25:25 -0500 (CDT)
Received: from <Chuong.Nguyen@usa.alcatel.com> (relay2.usa.alcatel.com
          [143.209.238.7]) by fw7 via smap (V2.1) id xma009703; Mon, 3 Apr 00
          16:25:21 -0500
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 QAA09512 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 3 Apr 2000 16:27:15 -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 QAA00487 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 3
          Apr 2000 16:25:44 -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 QAA12070
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 3 Apr 2000 16:25:44
          -0500 (CDT)
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="------------886EF53071E0A4A593369B3B"
Message-ID:  <38E90C57.64E25749@usa.alcatel.com>
Date:         Mon, 3 Apr 2000 16:25:43 -0500
Reply-To: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Subject:      E.10 Basic Continuity Package
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--------------886EF53071E0A4A593369B3B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

E.10.5 Procedures

"When a continuity test is performed
on a termination, no echo devices or codecs shall be active on that ter-

mination."

Does this statement applies to MG?
That is MG should turn off echo and codecs w/o any instruction from MGC
when MGC
initiates COT.
After COT, MG resumes echo and codecs prior to COT.

Or MGC has to tell MG to turn off echo and codecs and after COT turns
echo and codecs on?


Thanks
Chuong

--
  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 ****



--------------886EF53071E0A4A593369B3B
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi,
<p>E.10.5 Procedures
<p>"When a continuity test is performed
<br>on a termination, no echo devices or codecs shall be active on that
ter-
<br>mination."
<p>Does this statement applies to MG?
<br>That is MG should turn off echo and codecs w/o any instruction from
MGC when MGC
<br>initiates COT.
<br>After COT, MG resumes echo and codecs prior to COT.
<p>Or MGC has to tell MG to turn off echo and codecs and after COT turns
echo and codecs on?
<br>&nbsp;
<p>Thanks
<br>Chuong
<pre>--&nbsp;
&nbsp; Alcatel USA, Inc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Internet: Chuong.Nguyen@usa.alcatel.com
&nbsp; 1000 Coit Road Plano, Texas 75075&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Phone:&nbsp;&nbsp;&nbsp; (972) 519-4613
&nbsp; **** The opinions expressed are not those of Alcatel USA, Inc ****</pre>
&nbsp;</html>

--------------886EF53071E0A4A593369B3B--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Apr  3 17:58:34 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25370
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 3 Apr 2000 17:58:34 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.73D378B0@standards.nortelnetworks.com>; Mon, 3 Apr 2000 17:53:00 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 116996 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 3 Apr 2000 17:51:37 -0400
Received: from fw7.usa.alcatel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.DC8573B0@standards.nortelnetworks.com>; Mon, 3 Apr 2000 17:41:37
          -0400
Received: (from uucp@localhost) by fw7.usa.alcatel.com (8.8.8+Sun/8.8.8) id
          QAA14919 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 3 Apr 2000
          16:46:06 -0500 (CDT)
Received: from <Chuong.Nguyen@usa.alcatel.com> (relay2.usa.alcatel.com
          [143.209.238.7]) by fw7 via smap (V2.1) id xma014858; Mon, 3 Apr 00
          16:45:19 -0500
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 QAA17650 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 3 Apr 2000 16:47:14 -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 QAA04396 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 3
          Apr 2000 16:45:02 -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 QAA25829
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 3 Apr 2000 16:45:02
          -0500 (CDT)
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="------------AF529EF50F5CFB298649782D"
Message-ID:  <38E910DD.8949D021@usa.alcatel.com>
Date:         Mon, 3 Apr 2000 16:45:02 -0500
Reply-To: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Subject:      E.10.3 Signals (Basic Continuity Package)
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--------------AF529EF50F5CFB298649782D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hi

The Respond SignalID: rsp (0x004)  has a Signal Type of Timeout.

Looking at Section 10.5,
"Upon reception of a command with the rsp signal, the MG
awaits reception of the continuity test tone.  When the tone is received

before the rsp signal times out, the MG returns the applicable return
tone."

What is the duration of this Respond Signal?  The text seems to imply
that the Signal Type is
Timeout but it is used to timeout the reception of the continuity test
tone.
Is the intend that the Respond Signal has the same duration as the
Timeout for the detection of
the continuity test tone?

If the Respond Signal duration is TimeOut, MGC gets indication from
Central Office that
COT test successful, should MGC sends a Modify to stop the Respond
Signal or
just let it play until Timeout?
If let it plays until Timeout, will or should MG sends Notify w/COT
failed due to Timeout of
Respond Signal?

Or should the Respond Signal be Brief or ON/OFF?

Thanks
Chuong


--
  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 ****



--------------AF529EF50F5CFB298649782D
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<br>Hi
<p>The Respond SignalID: rsp (0x004)&nbsp; has a Signal Type of Timeout.
<p>Looking at Section 10.5,
<br>"Upon reception of a command with the rsp signal, the MG
<br>awaits reception of the continuity test tone.&nbsp; When the tone is
received
<br>before the rsp signal times out, the MG returns the applicable return
<br>tone."
<p>What is the duration of this Respond Signal?&nbsp; The text seems to
imply that the Signal Type is
<br>Timeout but it is used to timeout the reception of the continuity test
tone.
<br>Is the intend that the Respond Signal has the same duration as the
Timeout for the detection of
<br>the continuity test tone?
<p>If the Respond Signal duration is TimeOut, MGC gets indication from
Central Office that
<br>COT test successful, should MGC sends a Modify to stop the Respond
Signal or
<br>just let it play until Timeout?
<br>If let it plays until Timeout, will or should MG sends Notify w/COT
failed due to Timeout of
<br>Respond Signal?
<p>Or should the Respond Signal be Brief or ON/OFF?
<p>Thanks
<br>Chuong
<br>&nbsp;
<pre>--&nbsp;
&nbsp; Alcatel USA, Inc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Internet: Chuong.Nguyen@usa.alcatel.com
&nbsp; 1000 Coit Road Plano, Texas 75075&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Phone:&nbsp;&nbsp;&nbsp; (972) 519-4613
&nbsp; **** The opinions expressed are not those of Alcatel USA, Inc ****</pre>
&nbsp;</html>

--------------AF529EF50F5CFB298649782D--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr  4 04:07:56 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24112
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 4 Apr 2000 04:07:56 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.848CEEC0@standards.nortelnetworks.com>; Tue, 4 Apr 2000 4:01:56 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 117616 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 4 Apr 2000 04:00:23 -0400
Received: from exchange.satyam.net.in (202.144.12.32) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.87F495B0@standards.nortelnetworks.com>; Tue, 4 Apr 2000 3:47:42
          -0400
Received: from hqbng01ex01.mindtree.com ([202.144.95.250]) by
          exchange.satyam.net.in (8.9.3/8.9.3) with ESMTP id NAA17773 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 4 Apr 2000 13:21:31 +0530
Received: by hqbng01ex01.mindtree.com with Internet Mail Service (5.5.2650.21)
          id <2GJV8B89>; Tue, 4 Apr 2000 11:46:34 +0530
Importance: high
X-Priority: 1
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF9DFD.3C40A636"
Message-ID:  <E34EEFC7FE67BE45A3BC560EEDDBE4A1132213@hqbng01ex01.mindtree.com>
Date:         Tue, 4 Apr 2000 11:45:49 +0530
Reply-To: Venugopal M <m_venugopal@MINDTREE.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Venugopal M <m_venugopal@MINDTREE.COM>
Subject:      Choice Strategy, Merits and Demerits...
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_01BF9DFD.3C40A636
Content-Type: text/plain;
        charset="iso-8859-1"

Let me keep this to the point. I haven't been able to find enough "strategic
or technical merits" information in the net for using MEGACO vis-a-vis MGCP.
I hope I have not overlooked but I don't think I found a clear discussion
anywhere - I could be happily corrected on this, of course.

 Given a choice between MEGACO and MGCP for the MGC-MG space what would
experts prefer ? If some one ( Maybe Brian,Nancy or john ...too! ) could
just put in a few lines of merits and demerits (at this point, without being
overly philosophical like "both are equally good etc.etc." ) that would be
great help to people who're jut beginning to wade into these waters. At  the
first look it does appear that MEGACO is a lot of work as compared to MGCP
... but what does it offer in return ? are companies betting more on MEGACO
as compared to MGCP ? or is the jury still out ?

( yeah, I wish I could attend a few VON seminars but then I live about 12000
miles away from the US :-( )



-Venu

* What's Voice without IP ? *

( aren't I optimistic ? )


------_=_NextPart_001_01BF9DFD.3C40A636
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 9">
<meta name=3DOriginator content=3D"Microsoft Word 9">
<link rel=3DFile-List href=3D"cid:filelist.xml@01BF9E2B.51A98630">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:View>Normal</w:View>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
@font-face
        {font-family:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;
        mso-font-charset:2;
        mso-generic-font-family:auto;
        mso-font-pitch:variable;
        mso-font-signature:0 268435456 0 0 -2147483648 0;}
@font-face
        {font-family:Verdana;
        panose-1:2 11 6 4 3 5 4 4 2 4;
        mso-font-charset:0;
        mso-generic-font-family:swiss;
        mso-font-pitch:variable;
        mso-font-signature:536871559 0 0 0 415 0;}
 /* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {mso-style-parent:"";
        margin:0in;
        margin-bottom:.0001pt;
        mso-pagination:widow-orphan;
        font-size:9.0pt;
        mso-bidi-font-size:12.0pt;
        font-family:Verdana;
        mso-fareast-font-family:"Times New Roman";
        mso-bidi-font-family:Arial;
        color:black;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
        {margin:0in;
        margin-bottom:.0001pt;
        mso-pagination:widow-orphan;
        font-size:9.0pt;
        mso-bidi-font-size:12.0pt;
        font-family:Verdana;
        mso-fareast-font-family:"Times New Roman";
        mso-bidi-font-family:Arial;
        color:black;}
span.EmailStyle15
        {mso-style-type:personal-compose;
        mso-ansi-font-size:9.0pt;
        mso-ascii-font-family:Verdana;
        mso-hansi-font-family:Verdana;
        mso-bidi-font-family:Arial;
        color:black;
        font-weight:normal;
        font-style:normal;}
@page Section1
        {size:8.5in 11.0in;
        margin:1.0in 1.25in 1.0in 1.25in;
        mso-header-margin:.5in;
        mso-footer-margin:.5in;
        mso-paper-source:0;}
div.Section1
        {page:Section1;}
-->
</style>
</head>

<body lang=3DEN-US style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D1 =
color=3Dblack
face=3DVerdana><span style=3D'font-size:9.0pt'><span =
style=3D'mso-bidi-font-size:
12.0pt'>Let me keep this to the point. I haven&#8217;t been able to =
find enough &#8220;strategic
or technical merits&#8221; information in the net for using MEGACO =
vis-a-vis MGCP. I
hope I have not overlooked but I don&#8217;t think I found a clear =
discussion anywhere
&#8211; I could be happily corrected on this, of =
course.<o:p></o:p></span></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D1 =
color=3Dblack
face=3DVerdana><span style=3D'font-size:9.0pt'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span><o:p></o:p></font></span></p>=


<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D1 =
color=3Dblack
face=3DVerdana><span style=3D'font-size:9.0pt'><span =
style=3D'mso-bidi-font-size:
12.0pt'><span style=3D"mso-spacerun: yes">&nbsp;</span>Given a choice =
between
MEGACO and MGCP for the MGC-MG space what would experts prefer ? If =
some one (
Maybe Brian,Nancy or john &#8230;too! ) could just put in a few lines =
of merits and
demerits (at this point, without being overly philosophical like =
&#8220;both are
equally good etc.etc.&#8221; ) that would be great help to people =
who&#8217;re jut
beginning to wade into these waters. At <span style=3D"mso-spacerun:
yes">&nbsp;</span>the first look it does appear that MEGACO is a lot of =
work as
compared to MGCP &#8230; but what does it offer in return ? are =
companies betting
more on MEGACO as compared to MGCP ? or is the jury still out ?<o:p></o:=
p></span></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D1 =
color=3Dblack
face=3DVerdana><span style=3D'font-size:9.0pt'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span><o:p></o:p></font></span></p>=


<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D1 =
color=3Dblack
face=3DVerdana><span style=3D'font-size:9.0pt'><span =
style=3D'mso-bidi-font-size:
12.0pt'>( yeah, I wish I could attend a few VON seminars but then I =
live about
12000 miles away from the US </span></span></font></span><span
class=3DEmailStyle15><font color=3Dblack face=3DWingdings><span =
style=3D'font-family:
Wingdings;mso-ascii-font-family:Verdana;mso-hansi-font-family:Verdana;
mso-char-type:symbol;mso-symbol-font-family:Wingdings'><span =
style=3D'mso-char-type:
symbol;mso-symbol-font-family:Wingdings'>L</span></span></font> =
)<o:p></o:p></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D1 =
color=3Dblack
face=3DVerdana><span style=3D'font-size:9.0pt'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span><o:p></o:p></font></span></p>=


<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D1 =
color=3Dblack
face=3DVerdana><span style=3D'font-size:9.0pt'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span><o:p></o:p></font></span></p>=


<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D1 =
color=3Dblack
face=3DVerdana><span style=3D'font-size:9.0pt'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span><o:p></o:p></font></span></p>=


<p class=3DMsoAutoSig><font size=3D1 color=3Dblack face=3DVerdana><span
style=3D'font-size:9.0pt'><span =
style=3D'mso-bidi-font-size:12.0pt'>-</span></span></font><!--[if =
supportFields]><span=20
style=3D'mso-element:field-begin'></span> AUTOTEXTLIST \s &quot;E-mail=20
Signature&quot; <span =
style=3D'mso-element:field-separator'></span><![endif]-->Venu<o:p></o:p>=
</p>

<p class=3DMsoAutoSig><font size=3D1 color=3Dblack face=3DVerdana><span
style=3D'font-size:9.0pt'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span><o:p></o:p></font></p>

<p class=3DMsoAutoSig><font size=3D1 color=3Dblack face=3DVerdana><span
style=3D'font-size:9.0pt'><span style=3D'mso-bidi-font-size:12.0pt'>* =
What's Voice
without IP ? *<o:p></o:p></span></span></font></p>

<p class=3DMsoAutoSig><font size=3D1 color=3Dblack face=3DVerdana><span
style=3D'font-size:9.0pt'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span><o:p></o:p></font></p>

<p class=3DMsoAutoSig><font size=3D1 color=3Dblack face=3DVerdana><span
style=3D'font-size:9.0pt'><span style=3D'mso-bidi-font-size:12.0pt'>( =
aren&#8217;t I
optimistic ? )<o:p></o:p></span></span></font></p>

<p class=3DMsoNormal><!--[if supportFields]><span =
style=3D'mso-element:field-end'></span><![endif]--><![if =
!supportEmptyParas]>&nbsp;<![endif]><o:p></o:p></p>

</div>

</body>

</html>

------_=_NextPart_001_01BF9DFD.3C40A636--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr  4 08:19:13 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00477
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 4 Apr 2000 08:19:13 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A36FA670@standards.nortelnetworks.com>; Tue, 4 Apr 2000 8:13:20 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 117921 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 4 Apr 2000 08:11:47 -0400
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.6C0F51D0@standards.nortelnetworks.com>; Tue, 4 Apr 2000 8:11:47
          -0400
Received: from zcard00n.ca.nortel.com (actually zcard00n) by
          smtprch1.nortel.com; Tue, 4 Apr 2000 07:16:43 -0500
Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com
          with SMTP (Microsoft Exchange Internet Mail Service Version
          5.5.2650.21) id 2HP04N4Y; Tue, 4 Apr 2000 08:16:41 -0400
Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) by
          zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id HNNLV5T1; Tue, 4 Apr 2000 08:16:41
          -0400
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <F033F6FEF3F1D111BD150000F8CD1431032A9D34@zcard007.ca.nortel.com>
            <38E65763.BF5D443B@usa.alcatel.com>
Content-Type: multipart/alternative;
              boundary="------------D923AE956BC089D34D37C5E5"
Message-ID:  <38E9DDA4.DF472724@americasm01.nt.com>
Date:         Tue, 4 Apr 2000 08:18:44 -0400
Reply-To: Abdallah Rayhan <arayhan@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Abdallah Rayhan <arayhan@NORTELNETWORKS.COM>
Organization: Nortel Networks
Subject:      Re: V16 Review - Auditing contexts and their terminations
X-To:         Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--------------D923AE956BC089D34D37C5E5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Chuong,

See comments below.


Abdallah

Chuong Nguyen wrote:

>
> With the proposed solution, does this make contextAudit a new command?
>
> If yes, it should follow other commands request and response/reply
> syntax.
> That is the command is included in the transaction reply.
> Transaction = 1 {Context = 3 {command ...}}
> Reply = 1 {Context = 3 {command ..}}

Context audit is a special command-property operation which needs
special handling just as other contextAuditProperties. Auditing
terminations and contexts were split at the context and the
command-descriptor levels, my proposal would make it happen at
one place which is the context. This is the way it should have been
done in the first place.

You approach adds another level of parsing when you consider
contextAudit and you wont know whether you are parsing a list
or a list of lists till you advance. I try to stay away from those
and simplify parsing to one look ahead symbol as much as I could.

Also, I rather not populate the reply transaction with all audit
contexts.
My approach is much easier to read and follow. You know what the
audit is about, whether terminations, contexts or root; no need for
deep parsing to figure it out. Also it is similar to contextProperties
and contextAuditProperties.

<snip>

>> Here are 2 issues with the ABNF that have come up on our review of
>> section 7.2.5 AuditValue:
>>
>> 1) 7.2.5 Audit Value - auditing all matching terminations and their
>> contexts
>>
>> Issue: The entry before the last in table we have
>> "ContextID=ALL  , TerminationID= wildcard, Audit of all matching
>> terminations and contexts to which they are associated."
>>
>> Comment: In the ABNF, the reply reads like this:
>> AuditValue = contextID { t1,t2,...}
>> We can't report all the contexts in this reply.
>> The ABNF must be fixed to allow returning list of contexts
>> rather than just one with a list of terminations.
>>
>
> Doesn't the text say something about repeating a command for each
> matching wildcard found.
> That is keep use AuditValue to do context and termination relationship
> audit.
>
> Transaction = 1 {Context = * {AuditValue=*{Audit{ContextAudit}}}
>
> (Have to add a ContextAuditToken to auditItem in ABNF first)
>
> Reply = 1 {Context = 1 {AuditValue = contextAudit{t1,t2}},
>                    Context = 2 {AuditValue =
> contextAudit{t3,t4}}.......}
>
>
> or go with the Nancy's proposed solution but make contextAudit a new
> command.

It is property type of command similar to topology. It is fine the way
it
is, IMO.

>> 2) 7.2.5 Audit Value - return all context ids
>>
>> Issue: The last entry in the table is:
>> ContextID=All, TerminationID=Root, list of all contextIDs,
>>
>> Comment: The ABNF does not allow a list of contextIDs
>> returned on the audit. This has to be fixed to allow list of
>> contexts.
>>
>> Also, we need to check whether the ASN.1 handles these 2 cases
>> correctly.
>>
>> Proposal: A proposal for solving these 2 issues in the ABNF:
>>
>> Auditing a context does not belong to any particular command. So it
>> should stay out of AuditRequest. We already have a contextAudit in
>> the
>> ABNF, so we should use it instead.
>>
>> Case 1: List of all contexts and all terminations:
>> Request: Context = ALL {ContextAudit{Terminations}, othercommands
>> ....}
>> Reply: Context=All {Root { Cid1 { t1,t2,3....}, Cid2 { ....}}, other
>> replies}
>> ; Terminations will be a new token added to contextAuditProperties
>> ; and we will need RootDescriptor (list of lists as above)
>>
>
> Reply = 1 {Context = 1 {ContextAudit = {t1,t2},
>                     Context = 2 {ContextAudit = {t3,t4},
>                    Context = maxContext {ContextAudit = t4r4,t3434},
>                   Context = 2 {other command reply...}, etc }
>
> Assuming ContextAudit is classified as a new command.

It does not look good and a bit confusing having more contexts in the
reply than the request.

>> Case 2: All terminations and a specific context
>> Request: Context=Cid {ContextAudit{Terminations}, othercommands ...}
>>
>> Reply: Context=Cid { Terminations { t1,2,t3, ...}, other replies}
>> ; same as above but with TerminationsDescriptor this time (list of
>> ; terminations
>
> Reply:  Context=Cid {ContextAudit = {t1, t2, ...}}
>
>> Case 3: All contexts, no terminations
>> Request: Context=Cid or ALL {ContextAudit{Root}, othercommands ...}
>> Reply: Context=Cid or ALL { Contexts { cid1,cid2,cid3, ...}, other
>> replies}
>> ; RootToken, ContextsToken and ContextsDescriptor.
>
> Reply:  Context = cid1, Context= cid2, .....
>
> The transaction might get too large but it seems to follow other
> commands convention for
> a transaction reply.

Let us try to simplify not complicate things.

>> This way we avoid falling into explaining AuditValue or
>> AuditCapability
>> for context audit and at the same time, auditing context at the
>> context
>> level. Also, remove contextTerminationsAudit from auditReply.
>>
>> Comments?
>>
>> Nancy
>> Abdallah
>>
>>
>> -------------------------------------------------------------------------
>>
>> Nancy M. Greene
>> Internet & Service Provider Networks, Nortel Networks
>> T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com
>
> --
>   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 ****
>
>

--------------D923AE956BC089D34D37C5E5
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Chuong,
<p>See comments below.
<br>&nbsp;
<p>Abdallah
<p>Chuong Nguyen wrote:
<blockquote TYPE=CITE>&nbsp;
<br>With the proposed solution, does this make contextAudit a new command?
<br>If yes, it should follow other commands request and response/reply
syntax.
<br>That is the command is included in the transaction reply.
<br>Transaction = 1 {Context = 3 {command ...}}
<br>Reply = 1 {Context = 3 {command ..}}</blockquote>
Context audit is a special command-property operation which needs
<br>special handling just as other contextAuditProperties. Auditing
<br>terminations and contexts were split at the context and the
<br>command-descriptor levels, my proposal would make it happen at
<br>one place which is the context. This is the way it should have been
<br>done in the first place.
<p>You approach adds another level of parsing when you consider
<br>contextAudit and you wont know whether you are parsing a list
<br>or a list of lists till you advance. I try to stay away from those
<br>and simplify parsing to one look ahead symbol as much as I could.
<p>Also, I rather not populate the reply transaction with all audit contexts.
<br>My approach is much easier to read and follow. You know what the
<br>audit is about, whether terminations, contexts or root; no need for
<br>deep parsing to figure it out. Also it is similar to contextProperties
<br>and contextAuditProperties.
<p>&lt;snip>
<blockquote TYPE=CITE>
<blockquote TYPE=CITE><font face="Arial"><font size=-1>Here are 2 issues
with the ABNF that have come up on our review of</font></font>
<br><font face="Arial"><font size=-1>section 7.2.5 AuditValue:</font></font>
<p><font face="Arial"><font size=-1>1) 7.2.5 Audit Value - auditing all
matching terminations and their</font></font>
<br><font face="Arial"><font size=-1>contexts</font></font>
<p><font face="Arial"><font size=-1>Issue: The entry before the last in
table we have</font></font>
<br><font face="Arial"><font size=-1>"ContextID=ALL&nbsp; , TerminationID=
wildcard, Audit of all matching</font></font>
<br><font face="Arial"><font size=-1>terminations and contexts to which
they are associated."</font></font>
<p><font face="Arial"><font size=-1>Comment: In the ABNF, the reply reads
like this:</font></font>
<br><font face="Arial"><font size=-1>AuditValue = contextID { t1,t2,...}</font></font>
<br><font face="Arial"><font size=-1>We can't report all the contexts in
this reply.</font></font>
<br><font face="Arial"><font size=-1>The ABNF must be fixed to allow returning
list of contexts</font></font>
<br><font face="Arial"><font size=-1>rather than just one with a list of
terminations.</font></font>
<br>&nbsp;</blockquote>
Doesn't the text say something about repeating a command for each matching
wildcard found.
<br>That is keep use AuditValue to do context and termination relationship
audit.
<p>Transaction = 1 {Context = * {AuditValue=*{Audit{ContextAudit}}}
<p>(Have to add a ContextAuditToken to auditItem in ABNF first)
<p>Reply = 1 {Context = 1 {AuditValue = contextAudit{t1,t2}},
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Context = 2 {AuditValue = contextAudit{t3,t4}}.......}
<br>&nbsp;
<p>or go with the Nancy's proposed solution but make contextAudit a new
command.</blockquote>
It is property type of command similar to topology. It is fine the way
it
<br>is, IMO.
<blockquote TYPE=CITE>
<blockquote TYPE=CITE><font face="Arial"><font size=-1>2) 7.2.5 Audit Value
- return all context ids</font></font>
<p><font face="Arial"><font size=-1>Issue: The last entry in the table
is:</font></font>
<br><font face="Arial"><font size=-1>ContextID=All, TerminationID=Root,
list of all contextIDs,</font></font>
<p><font face="Arial"><font size=-1>Comment: The ABNF does not allow a
list of contextIDs</font></font>
<br><font face="Arial"><font size=-1>returned on the audit. This has to
be fixed to allow list of</font></font>
<br><font face="Arial"><font size=-1>contexts.</font></font>
<p><font face="Arial"><font size=-1>Also, we need to check whether the
ASN.1 handles these 2 cases</font></font>
<br><font face="Arial"><font size=-1>correctly.</font></font>
<p><font face="Arial"><font size=-1>Proposal:</font></font> <font face="Arial"><font size=-1>A
proposal for solving these 2 issues in the ABNF:</font></font>
<p><font face="Arial"><font size=-1>Auditing a context does not belong
to any particular command. So it</font></font>
<br><font face="Arial"><font size=-1>should stay out of AuditRequest. We
already have a contextAudit in the</font></font>
<br><font face="Arial"><font size=-1>ABNF, so we should use it instead.</font></font>
<p><font face="Arial"><font size=-1>Case 1: List of all contexts and all
terminations:</font></font>
<br><font face="Arial"><font size=-1>Request: Context = ALL {ContextAudit{Terminations},
othercommands ....}</font></font>
<br><font face="Arial"><font size=-1>Reply: Context=All {Root { Cid1 {
t1,t2,3....}, Cid2 { ....}}, other replies}</font></font>
<br><font face="Arial"><font size=-1>; Terminations will be a new token
added to contextAuditProperties</font></font>
<br><font face="Arial"><font size=-1>; and we will need RootDescriptor
(list of lists as above)</font></font>
<br>&nbsp;</blockquote>
Reply = 1 {Context = 1 {ContextAudit = {t1,t2},
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Context = 2 {ContextAudit = {t3,t4},
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Context = maxContext {ContextAudit = t4r4,t3434},
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Context = 2 {other command reply...}, etc }
<p>Assuming ContextAudit is classified as a new command.</blockquote>
It does not look good and a bit confusing having more contexts in the
<br>reply than the request.
<blockquote TYPE=CITE>
<blockquote TYPE=CITE><font face="Arial"><font size=-1>Case 2: All terminations
and a specific context</font></font>
<br><font face="Arial"><font size=-1>Request: Context=Cid {ContextAudit{Terminations},
othercommands ...}</font></font>
<br><font face="Arial"><font size=-1>Reply: Context=Cid { Terminations
{ t1,2,t3, ...}, other replies}</font></font>
<br><font face="Arial"><font size=-1>; same as above but with TerminationsDescriptor
this time (list of</font></font>
<br><font face="Arial"><font size=-1>; terminations</font></font></blockquote>
Reply:&nbsp; Context=Cid {ContextAudit = {t1, t2, ...}}
<blockquote TYPE=CITE><font face="Arial"><font size=-1>Case 3: All contexts,
no terminations</font></font>
<br><font face="Arial"><font size=-1>Request: Context=Cid or ALL {ContextAudit{Root},
othercommands ...}</font></font>
<br><font face="Arial"><font size=-1>Reply: Context=Cid or ALL { Contexts
{ cid1,cid2,cid3, ...}, other replies}</font></font>
<br><font face="Arial"><font size=-1>; RootToken, ContextsToken and ContextsDescriptor.</font></font></blockquote>
Reply:&nbsp; Context = cid1, Context= cid2, .....
<p>The transaction might get too large but it seems to follow other commands
convention for
<br>a transaction reply.</blockquote>
Let us try to simplify not complicate things.
<blockquote TYPE=CITE>
<blockquote TYPE=CITE><font face="Arial"><font size=-1>This way we avoid
falling into explaining AuditValue or AuditCapability</font></font>
<br><font face="Arial"><font size=-1>for context audit and at the same
time, auditing context at the context</font></font>
<br><font face="Arial"><font size=-1>level. Also, remove contextTerminationsAudit
from auditReply.</font></font>
<p><font face="Arial"><font size=-1>Comments?</font></font>
<p><font face="Arial"><font size=-1>Nancy</font></font>
<br><font face="Arial"><font size=-1>Abdallah</font></font>
<p><font face="MS Sans Serif"><font size=-1>--------------------------------------------------------------------------</font></font>
<br><font face="MS Sans Serif"><font size=-1>Nancy M. Greene</font></font>
<br><font face="MS Sans Serif"><font size=-1>Internet &amp; Service Provider
Networks, Nortel Networks</font></font>
<br><font face="MS Sans Serif"><font size=-1>T:514-271-7221 (internal:ESN853-1077)
E:ngreene@nortelnetworks.com</font></font></blockquote>

<pre>--&nbsp;
&nbsp; Alcatel USA, Inc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Internet: Chuong.Nguyen@usa.alcatel.com
&nbsp; 1000 Coit Road Plano, Texas 75075&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Phone:&nbsp;&nbsp;&nbsp; (972) 519-4613
&nbsp; **** The opinions expressed are not those of Alcatel USA, Inc ****</pre>
&nbsp;</blockquote>
</html>

--------------D923AE956BC089D34D37C5E5--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr  4 09:57:16 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03498
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 4 Apr 2000 09:57:16 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.57291900@standards.nortelnetworks.com>; Tue, 4 Apr 2000 9:51:25 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 117971 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 4 Apr 2000 09:49:37 -0400
Received: from fw7.usa.alcatel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.B102B960@standards.nortelnetworks.com>; Tue, 4 Apr 2000 9:39:37
          -0400
Received: (from uucp@localhost) by fw7.usa.alcatel.com (8.8.8+Sun/8.8.8) id
          IAA05594; Tue, 4 Apr 2000 08:44:01 -0500 (CDT)
Received: from <Chuong.Nguyen@usa.alcatel.com> (relay2.usa.alcatel.com
          [143.209.238.7]) by fw7 via smap (V2.1) id xma005434; Tue, 4 Apr 00
          08:43:34 -0500
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 IAA00219; Tue, 4
          Apr 2000 08:45:32 -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 IAA14909; Tue, 4 Apr 2000 08:43:43 -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 IAA15380;
          Tue, 4 Apr 2000 08:43:42 -0500 (CDT)
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <F033F6FEF3F1D111BD150000F8CD1431032A9D34@zcard007.ca.nortel.com>
            <38E65763.BF5D443B@usa.alcatel.com>
            <38E9DDA4.DF472724@americasm01.nt.com>
Content-Type: multipart/alternative;
              boundary="------------229C9A95B02703C41AFD0FD3"
Message-ID:  <38E9F18E.F40E4616@usa.alcatel.com>
Date:         Tue, 4 Apr 2000 08:43:42 -0500
Reply-To: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Subject:      Re: V16 Review - Auditing contexts and their terminations
X-To:         Abdallah Rayhan <arayhan@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--------------229C9A95B02703C41AFD0FD3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Abdallah
Thanks for the reply.

It doesn't really matter to me what the approach is as long as it is
clearly documented somewhere
and agreed/understood by Megaco implementors.

Your approach about not repeating context seems contrary to previous
discussion on how to
handle wildcard command.

Transaction = 1 {Context = * {AuditValue = *{Audit{Media}}}}

What is the expected Reply?  The following or something else
Reply = 1 {Context = 1 {AuditValue = t1, t2 {Audit{...}}},
                   Context = 2 {AuditValue = t3,t4 {Audit{...}}},
                   ... , Context = n {...}}


Thanks
Chuong

Abdallah Rayhan wrote:

> Chuong,
>
> See comments below.
>
>
> Abdallah
>
> Chuong Nguyen wrote:
>
>>
>> With the proposed solution, does this make contextAudit a new
>> command?
>> If yes, it should follow other commands request and response/reply
>> syntax.
>> That is the command is included in the transaction reply.
>> Transaction = 1 {Context = 3 {command ...}}
>> Reply = 1 {Context = 3 {command ..}}
>
> Context audit is a special command-property operation which needs
> special handling just as other contextAuditProperties. Auditing
> terminations and contexts were split at the context and the
> command-descriptor levels, my proposal would make it happen at
> one place which is the context. This is the way it should have been
> done in the first place.
>
> You approach adds another level of parsing when you consider
> contextAudit and you wont know whether you are parsing a list
> or a list of lists till you advance. I try to stay away from those
> and simplify parsing to one look ahead symbol as much as I could.
>
> Also, I rather not populate the reply transaction with all audit
> contexts.
> My approach is much easier to read and follow. You know what the
> audit is about, whether terminations, contexts or root; no need for
> deep parsing to figure it out. Also it is similar to contextProperties
>
> and contextAuditProperties.
>
> <snip>
>
>> > Here are 2 issues with the ABNF that have come up on our review of
>> > section 7.2.5 AuditValue:
>> >
>> > 1) 7.2.5 Audit Value - auditing all matching terminations and their
>> >
>> > contexts
>> >
>> > Issue: The entry before the last in table we have
>> > "ContextID=ALL  , TerminationID= wildcard, Audit of all matching
>> > terminations and contexts to which they are associated."
>> >
>> > Comment: In the ABNF, the reply reads like this:
>> > AuditValue = contextID { t1,t2,...}
>> > We can't report all the contexts in this reply.
>> > The ABNF must be fixed to allow returning list of contexts
>> > rather than just one with a list of terminations.
>> >
>>
>> Doesn't the text say something about repeating a command for each
>> matching wildcard found.
>> That is keep use AuditValue to do context and termination
>> relationship audit.
>>
>> Transaction = 1 {Context = * {AuditValue=*{Audit{ContextAudit}}}
>>
>> (Have to add a ContextAuditToken to auditItem in ABNF first)
>>
>> Reply = 1 {Context = 1 {AuditValue = contextAudit{t1,t2}},
>>                    Context = 2 {AuditValue =
>> contextAudit{t3,t4}}.......}
>>
>>
>> or go with the Nancy's proposed solution but make contextAudit a new
>> command.
>
> It is property type of command similar to topology. It is fine the way
> it
> is, IMO.
>
>> > 2) 7.2.5 Audit Value - return all context ids
>> >
>> > Issue: The last entry in the table is:
>> > ContextID=All, TerminationID=Root, list of all contextIDs,
>> >
>> > Comment: The ABNF does not allow a list of contextIDs
>> > returned on the audit. This has to be fixed to allow list of
>> > contexts.
>> >
>> > Also, we need to check whether the ASN.1 handles these 2 cases
>> > correctly.
>> >
>> > Proposal: A proposal for solving these 2 issues in the ABNF:
>> >
>> > Auditing a context does not belong to any particular command. So it
>> >
>> > should stay out of AuditRequest. We already have a contextAudit in
>> > the
>> > ABNF, so we should use it instead.
>> >
>> > Case 1: List of all contexts and all terminations:
>> > Request: Context = ALL {ContextAudit{Terminations}, othercommands
>> > ....}
>> > Reply: Context=All {Root { Cid1 { t1,t2,3....}, Cid2 { ....}},
>> > other replies}
>> > ; Terminations will be a new token added to contextAuditProperties
>> > ; and we will need RootDescriptor (list of lists as above)
>> >
>>
>> Reply = 1 {Context = 1 {ContextAudit = {t1,t2},
>>                     Context = 2 {ContextAudit = {t3,t4},
>>                    Context = maxContext {ContextAudit = t4r4,t3434},
>>
>>                   Context = 2 {other command reply...}, etc }
>>
>> Assuming ContextAudit is classified as a new command.
>
> It does not look good and a bit confusing having more contexts in the
> reply than the request.
>
>> > Case 2: All terminations and a specific context
>> > Request: Context=Cid {ContextAudit{Terminations}, othercommands
>> > ...}
>> > Reply: Context=Cid { Terminations { t1,2,t3, ...}, other replies}
>> > ; same as above but with TerminationsDescriptor this time (list of
>> > ; terminations
>>
>> Reply:  Context=Cid {ContextAudit = {t1, t2, ...}}
>>
>> > Case 3: All contexts, no terminations
>> > Request: Context=Cid or ALL {ContextAudit{Root}, othercommands ...}
>> >
>> > Reply: Context=Cid or ALL { Contexts { cid1,cid2,cid3, ...}, other
>> > replies}
>> > ; RootToken, ContextsToken and ContextsDescriptor.
>>
>> Reply:  Context = cid1, Context= cid2, .....
>>
>> The transaction might get too large but it seems to follow other
>> commands convention for
>> a transaction reply.
>
> Let us try to simplify not complicate things.
>
>> > This way we avoid falling into explaining AuditValue or
>> > AuditCapability
>> > for context audit and at the same time, auditing context at the
>> > context
>> > level. Also, remove contextTerminationsAudit from auditReply.
>> >
>> > Comments?
>> >
>> > Nancy
>> > Abdallah
>> >
>> >
>> > -------------------------------------------------------------------------
>> >
>> > Nancy M. Greene
>> > Internet & Service Provider Networks, Nortel Networks
>> > T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com
>>
>> --
>>   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 ****
>>
>>
>
--
  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 ****



--------------229C9A95B02703C41AFD0FD3
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Abdallah
<br>Thanks for the reply.
<p>It doesn't really matter to me what the approach is as long as it is
clearly documented somewhere
<br>and agreed/understood by Megaco implementors.
<p>Your approach about not repeating context seems contrary to previous
discussion on how to
<br>handle wildcard command.
<p>Transaction = 1 {Context = * {AuditValue = *{Audit{Media}}}}
<p>What is the expected Reply?&nbsp; The following or something else
<br>Reply = 1 {Context = 1 {AuditValue = t1, t2 {Audit{...}}},
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Context = 2 {AuditValue = t3,t4 {Audit{...}}},
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
... , Context = n {...}}
<br>&nbsp;
<p>Thanks
<br>Chuong
<p>Abdallah Rayhan wrote:
<blockquote TYPE=CITE>Chuong,
<p>See comments below.
<br>&nbsp;
<p>Abdallah
<p>Chuong Nguyen wrote:
<blockquote TYPE=CITE>&nbsp;
<br>With the proposed solution, does this make contextAudit a new command?
<br>If yes, it should follow other commands request and response/reply
syntax.
<br>That is the command is included in the transaction reply.
<br>Transaction = 1 {Context = 3 {command ...}}
<br>Reply = 1 {Context = 3 {command ..}}</blockquote>
Context audit is a special command-property operation which needs
<br>special handling just as other contextAuditProperties. Auditing
<br>terminations and contexts were split at the context and the
<br>command-descriptor levels, my proposal would make it happen at
<br>one place which is the context. This is the way it should have been
<br>done in the first place.
<p>You approach adds another level of parsing when you consider
<br>contextAudit and you wont know whether you are parsing a list
<br>or a list of lists till you advance. I try to stay away from those
<br>and simplify parsing to one look ahead symbol as much as I could.
<p>Also, I rather not populate the reply transaction with all audit contexts.
<br>My approach is much easier to read and follow. You know what the
<br>audit is about, whether terminations, contexts or root; no need for
<br>deep parsing to figure it out. Also it is similar to contextProperties
<br>and contextAuditProperties.
<p>&lt;snip>
<blockquote TYPE=CITE>
<blockquote TYPE=CITE><font face="Arial"><font size=-1>Here are 2 issues
with the ABNF that have come up on our review of</font></font>
<br><font face="Arial"><font size=-1>section 7.2.5 AuditValue:</font></font>
<p><font face="Arial"><font size=-1>1) 7.2.5 Audit Value - auditing all
matching terminations and their</font></font>
<br><font face="Arial"><font size=-1>contexts</font></font>
<p><font face="Arial"><font size=-1>Issue: The entry before the last in
table we have</font></font>
<br><font face="Arial"><font size=-1>"ContextID=ALL&nbsp; , TerminationID=
wildcard, Audit of all matching</font></font>
<br><font face="Arial"><font size=-1>terminations and contexts to which
they are associated."</font></font>
<p><font face="Arial"><font size=-1>Comment: In the ABNF, the reply reads
like this:</font></font>
<br><font face="Arial"><font size=-1>AuditValue = contextID { t1,t2,...}</font></font>
<br><font face="Arial"><font size=-1>We can't report all the contexts in
this reply.</font></font>
<br><font face="Arial"><font size=-1>The ABNF must be fixed to allow returning
list of contexts</font></font>
<br><font face="Arial"><font size=-1>rather than just one with a list of
terminations.</font></font>
<br>&nbsp;</blockquote>
Doesn't the text say something about repeating a command for each matching
wildcard found.
<br>That is keep use AuditValue to do context and termination relationship
audit.
<p>Transaction = 1 {Context = * {AuditValue=*{Audit{ContextAudit}}}
<p>(Have to add a ContextAuditToken to auditItem in ABNF first)
<p>Reply = 1 {Context = 1 {AuditValue = contextAudit{t1,t2}},
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Context = 2 {AuditValue = contextAudit{t3,t4}}.......}
<br>&nbsp;
<p>or go with the Nancy's proposed solution but make contextAudit a new
command.</blockquote>
It is property type of command similar to topology. It is fine the way
it
<br>is, IMO.
<blockquote TYPE=CITE>
<blockquote TYPE=CITE><font face="Arial"><font size=-1>2) 7.2.5 Audit Value
- return all context ids</font></font>
<p><font face="Arial"><font size=-1>Issue: The last entry in the table
is:</font></font>
<br><font face="Arial"><font size=-1>ContextID=All, TerminationID=Root,
list of all contextIDs,</font></font>
<p><font face="Arial"><font size=-1>Comment: The ABNF does not allow a
list of contextIDs</font></font>
<br><font face="Arial"><font size=-1>returned on the audit. This has to
be fixed to allow list of</font></font>
<br><font face="Arial"><font size=-1>contexts.</font></font>
<p><font face="Arial"><font size=-1>Also, we need to check whether the
ASN.1 handles these 2 cases</font></font>
<br><font face="Arial"><font size=-1>correctly.</font></font>
<p><font face="Arial"><font size=-1>Proposal:</font></font> <font face="Arial"><font size=-1>A
proposal for solving these 2 issues in the ABNF:</font></font>
<p><font face="Arial"><font size=-1>Auditing a context does not belong
to any particular command. So it</font></font>
<br><font face="Arial"><font size=-1>should stay out of AuditRequest. We
already have a contextAudit in the</font></font>
<br><font face="Arial"><font size=-1>ABNF, so we should use it instead.</font></font>
<p><font face="Arial"><font size=-1>Case 1: List of all contexts and all
terminations:</font></font>
<br><font face="Arial"><font size=-1>Request: Context = ALL {ContextAudit{Terminations},
othercommands ....}</font></font>
<br><font face="Arial"><font size=-1>Reply: Context=All {Root { Cid1 {
t1,t2,3....}, Cid2 { ....}}, other replies}</font></font>
<br><font face="Arial"><font size=-1>; Terminations will be a new token
added to contextAuditProperties</font></font>
<br><font face="Arial"><font size=-1>; and we will need RootDescriptor
(list of lists as above)</font></font>
<br>&nbsp;</blockquote>
Reply = 1 {Context = 1 {ContextAudit = {t1,t2},
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Context = 2 {ContextAudit = {t3,t4},
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Context = maxContext {ContextAudit = t4r4,t3434},
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Context = 2 {other command reply...}, etc }
<p>Assuming ContextAudit is classified as a new command.</blockquote>
It does not look good and a bit confusing having more contexts in the
<br>reply than the request.
<blockquote TYPE=CITE>
<blockquote TYPE=CITE><font face="Arial"><font size=-1>Case 2: All terminations
and a specific context</font></font>
<br><font face="Arial"><font size=-1>Request: Context=Cid {ContextAudit{Terminations},
othercommands ...}</font></font>
<br><font face="Arial"><font size=-1>Reply: Context=Cid { Terminations
{ t1,2,t3, ...}, other replies}</font></font>
<br><font face="Arial"><font size=-1>; same as above but with TerminationsDescriptor
this time (list of</font></font>
<br><font face="Arial"><font size=-1>; terminations</font></font></blockquote>
Reply:&nbsp; Context=Cid {ContextAudit = {t1, t2, ...}}
<blockquote TYPE=CITE><font face="Arial"><font size=-1>Case 3: All contexts,
no terminations</font></font>
<br><font face="Arial"><font size=-1>Request: Context=Cid or ALL {ContextAudit{Root},
othercommands ...}</font></font>
<br><font face="Arial"><font size=-1>Reply: Context=Cid or ALL { Contexts
{ cid1,cid2,cid3, ...}, other replies}</font></font>
<br><font face="Arial"><font size=-1>; RootToken, ContextsToken and ContextsDescriptor.</font></font></blockquote>
Reply:&nbsp; Context = cid1, Context= cid2, .....
<p>The transaction might get too large but it seems to follow other commands
convention for
<br>a transaction reply.</blockquote>
Let us try to simplify not complicate things.
<blockquote TYPE=CITE>
<blockquote TYPE=CITE><font face="Arial"><font size=-1>This way we avoid
falling into explaining AuditValue or AuditCapability</font></font>
<br><font face="Arial"><font size=-1>for context audit and at the same
time, auditing context at the context</font></font>
<br><font face="Arial"><font size=-1>level. Also, remove contextTerminationsAudit
from auditReply.</font></font>
<p><font face="Arial"><font size=-1>Comments?</font></font>
<p><font face="Arial"><font size=-1>Nancy</font></font>
<br><font face="Arial"><font size=-1>Abdallah</font></font>
<p><font face="MS Sans Serif"><font size=-1>--------------------------------------------------------------------------</font></font>
<br><font face="MS Sans Serif"><font size=-1>Nancy M. Greene</font></font>
<br><font face="MS Sans Serif"><font size=-1>Internet &amp; Service Provider
Networks, Nortel Networks</font></font>
<br><font face="MS Sans Serif"><font size=-1>T:514-271-7221 (internal:ESN853-1077)
E:ngreene@nortelnetworks.com</font></font></blockquote>

<pre>--&nbsp;
&nbsp; Alcatel USA, Inc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Internet: Chuong.Nguyen@usa.alcatel.com
&nbsp; 1000 Coit Road Plano, Texas 75075&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Phone:&nbsp;&nbsp;&nbsp; (972) 519-4613
&nbsp; **** The opinions expressed are not those of Alcatel USA, Inc ****</pre>
&nbsp;</blockquote>
</blockquote>

<pre>--&nbsp;
&nbsp; Alcatel USA, Inc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Internet: Chuong.Nguyen@usa.alcatel.com
&nbsp; 1000 Coit Road Plano, Texas 75075&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Phone:&nbsp;&nbsp;&nbsp; (972) 519-4613
&nbsp; **** The opinions expressed are not those of Alcatel USA, Inc ****</pre>
&nbsp;</html>

--------------229C9A95B02703C41AFD0FD3--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr  4 12:32:05 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08163
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 4 Apr 2000 12:31:56 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E5E7F9E0@standards.nortelnetworks.com>; Tue, 4 Apr 2000 12:18:34 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 118091 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 4 Apr 2000 12:16:46 -0400
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.75E7A4B0@standards.nortelnetworks.com>; Tue, 4 Apr 2000 12:15:26
          -0400
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id WAA02193; Tue, 4 Apr
          2000 22:22:17 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          652568B7.00591487 ; Tue, 4 Apr 2000 21:42:59 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: multipart/mixed;
              Boundary="0__=CpfGEquZHC2A14se4aPSinL2WzWGKsJFjpgubpKR8tlbOuSD356XPkBU"
Content-Disposition: inline
Message-ID:  <652568B7.005913F1.00@sandesh.hss.hns.com>
Date:         Tue, 4 Apr 2000 21:42:56 +0530
Reply-To: smahajan@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: smahajan@HSS.HNS.COM
X-To:         SIGTRAN@STANDARDS.NORTELNETWORKS.COM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--0__=CpfGEquZHC2A14se4aPSinL2WzWGKsJFjpgubpKR8tlbOuSD356XPkBU
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline




Hi All,
As there exists multiple protocol options for MGC-MGC interface but nothing yet
standardized,
attached white paper proposes an interface definition (protocol) for MGC to MGC
communication
in SS7 networks based on MEGACOP, SIGTRAN and Packet-SS7 protocols.
Another attached document gives backgound on the Packet-SS7 architecture.
Regards,
Sunil Mahajan
(looking for comments and feedback.............)

(See attached file: packet-ss74mgc-mgc.zip)(See attached file: packet-ss7.zip)

--0__=CpfGEquZHC2A14se4aPSinL2WzWGKsJFjpgubpKR8tlbOuSD356XPkBU
Content-type: application/zip;
        name="packet-ss74mgc-mgc.zip"
Content-Disposition: attachment; filename="packet-ss74mgc-mgc.zip"
Content-Description: .ZIP File
Content-Transfer-Encoding: base64

UEsDBBQAAAAIANGmvih8+CujqicBAACEBQAWAAAAcGFja2V0LXNzNzRtZ2MtbWdjLmRvY+xcfYwk
x1WvvfPHnX2d+CuKFUxScYyZjWZm13f23TlAwnrubndt7974Zi8ngQ30dvfulK+ne+juufUgBEGC
/xCyAkKgiD8SGQvlnxyYL8dBigw2/0TCERKJkhCZD8kJGOkwViQMzvF7r6q6q2dn706RFSKYXr/d
me6q9169et/V51f+5tZXP/2H7/sHMXF9VOwX3718UNzg3KPPf7zPfLlFiBfweQ4fv3v58mW69UV8
/zzgzwB/DvgTwHOAy7PrB/Z681+E+A7g/f8qxFHAccAK4JcAvw54FvAHgFfo2etC/N2hOfFVwNcA
D3lz4hTg44DPAJ4B/OJ758RfATbuwn3A4/fOiZ8BHP0wngHeas6Jm1pzonl0TqwDDn9kTtwPOPVj
c2IF8DBgE7BxAvMBGeC3Ad9amRPvWsXYs8AJ+MmfAn3A3SFwA44DHgWsA8Tb4i3xHfH2W2+LS699
8yviy38t/vILz/8RfgR+Psu/n33+UwD6+eTzz/7as88Lcef+J0mJHzjwK52H7xRnD8wNVsR1CUDc
qp8sPvx+YR69R9+ZGHijmftu/nuXOP2wEI8BvGo+Rl9HQ8Qh+3CwcvCAuPGonnn7xEx6eBPuHdW3
a7OuE7d0Hr5D1O+UawAh5v1mg5Ee32g+g4NbhdiPbxC9OLgobl2cu7c7J+4CLJyR4gMXX1mQF1/9
iQ9evP2GuwEfenrjhnue/vrcj1wU4r0XW9ffefGl/YeevgQfcS1zFzF38QZ37vWLYv8b4rMf8sSa
OCmWxZLoiNOiK5pCip5YxZ0NcQZ31/HdF4kI8beLT4E4LyJRiBZG9cQx3N0Sqcjwdw1zOriv/3ri
AGAJM6VY4bEt3PcxMxI7+DvG/XOiLxTf0biH+ESYUp5VxycBqRjgZ4SnCnwQLsVjPfwcAq1NkeNe
xlwWmPFO/RD+DfBKfGr8CSipkj7JIGPuJCgrfA7ApWIeNjE6x8yQ50YiBgyBi+aRDBJ899ZOLi91
Tnebsre6vHFmaV36SSi7fnA+Klq93jG5lWZybbnTAngHvKVErvR6rWW/iHb8sTzXV0WE0cMok2li
x8kgHQxGiQr8QqWJ5x1a2syLzA8KeS2X5230I4nxSa5ovtzK0oEMVBaMVCE3/TwKZRHF0bCfJmOZ
RMVOmp2XRSp9ORxlkRwy72bghVQF0ZThOyqOZeGfxzM1iHjNO/1UqlxGF6KkGPlxPJbbqUq2CfOO
SuhRkhbyfJLuJG250cd3RjJgJP0ox++d1BLIIYPoKZUXLL88HUQlnQHkthnx/TgFfrqXRT8/UlmU
S5UUUdYiDER6E8iiKJmCvg0xLeUyjLZUgmVujuXGanfltN49P0yHhb47SMFCukUYJBYWplnOQ/IC
v/0szImP0aDJA+rEt80eb42SgPYhJxGUIsEKtISxQWGEDR+m9M1O8rOAVCMoaEcaa1GofGmVppMm
RZbGMXTmp6EtTzRl/TluPsFM9tR2go0giuWz3vIT80b8NRqlBEn/aPIuPZTDLC3SII2bLPui7xe0
aszVGzXwoR8QHC9Vj1BmQ7Z8KNHmqCAN6BM7YygYJO/HCoumvZiq+SQhfCRVAmejuCB0UNNub2O9
Rb8kPQSdLB1t963iWhVtkNboEdD7AgJrbY6Hfp7P602G/kVylIRRxpupF+TuN1Ow2LCUcr/IrPNK
tnaIXYOVk8z7vrWSwIecCC+Z5RZ2bgLH9DW0yZZBecgOAnhJSXKwEMl8FPQrSjt9ha+Bn8hRztY0
iZ9X7O43BDkhL8dRTWyD1g1mk9gfphnLaAoJ4mCTFKKArZCfYUUf5fojhJBBRUhp3ImVLTWiJPCH
2GmfzE8lC5VF4fuOKvpEdF7vXRyT4pwtN5BQ7eFAySFezcgqA9jL2BrAPC/h3VQxpuWE6YTFs6uq
C6SODBgmEGxGUIxsAg/5Ysxlv93rrMtGD0sP+uC8Y7z4ut6zeRpa89dWcSSv2WGmTgGaTmKqGT1Q
OdZAdHMVapfbPWG+YNcnFli4QnAdLnyiYjsiOUP8agtqj7WT8yGnQTcHsGk1jGuMWg8CvSvJNrBk
mEGRjbTfr5jTijBvDEAlQTwKsZ6VI4ePaBe42m3LlXQHUYkjrJ3Z1N5JGxZ8wmiAWewBSKuJFsTH
zmCYDqGPNDna15Y9yDtTAz9TcErXLN6rRaUJmYKFtjxVV6ZpBMgRx3G6w3cybfeG5gCSzieMw7g1
B2kDq8797UjHtKGf+YizmDF/1ZnwPEEUwm6mEElGg82I3cUwhj9oYCEmZltXE6TJltoeZWye896q
u7am3IOp+jCXg/qD9ZJ8l8iD+lIYYlhOt3owI0SFhrklN8ihxYaPnkkzjIetrVb72QG8E6kRtF6v
ktarsPILKkTOUw7kQdbRhZHnrW7t2mjXKGh45EODrZVZF2Uk1qzrU91UN0HIbNGAZeYYJBSFYlAM
/QdTMJd8GAVqS1l3StuKIAyrXIKkC+1z9lQ7YiKJopA5CLRnXCBfW7m6s4lCmIajy+d3+QZydQhp
SxyzSfddZWWBUDYGW9bGMUF80lnBuUO8nLdykNcuIM3UNhILZNW8FNpIzA5ZL432sduKsgEP453y
nZ2YGN2WDyFvQbQM4F/p/tQQ03SSnZLhvj8cRvBkxQ7l0I00CTjs8j5TKNE2XuLzOXLvwhKkozgk
48nHA6hnpgLjV2tOs/JsxCNrBA0BYk47c9hQW55sb7ettHRwga9zCgD2mq6UNhFa6IEzDj6QEud6
6sTIiF4wyliIUw39yv7VWc3I5Fmcx5QOO0+vmJ5EeXMPP0sUsQgdTerBizTNWST8u6Jd4qVgXF6q
E83YJTL2uUaRmCBhMvlhabiECwvCAvt2J3UW5bOkONaPdTpXZ18ldgUcdmhU6Ye4blGVUNkW2Con
km7HwhwG/E3E3DIhY/mY/JOEVCWfZ1z7dPPDkoB3OolseMj2Gl3fLpXXSU/Jgh0uXGHFYyifU9Ts
XlD01DBOFdcluJ1ASmAF7DkIm+QFIUh4bGgZsalrXIpSlI4M2I3VWJ5KtQ8FiiPeFuMJrQA0VpPZ
1ddukppKwqd1tuNVORHsnTIiMO3WUrsEX+qCx1ZbVQLk1c9sdBfObHS6E89Mds7m5edXwIlokJel
kB7CIrV7UsYAx70zYaZnWwxsGHHe1EmgW5yQO6rYovXVxcS4/EQHUE50iizSNobN9fPyGdMzCXWd
R+23fR3Kr6agJStX0k1XD6dpalNzE6aR7nQYHavMOx8NqXRiax7lWt9V7iYXts6ltcRpzqpbJUBu
94Nr2zJRajjlcZkXyYHKBz7qBtRLQUbYKAOpAp3jpdoe8uS66uhE9ETXNXAqy6ATAVSfqJp6lPIN
yrN5h69BdIaZqhNj03OWRl5QU6gW600kiFSZT1mGnNjlaCJR17XiarcKY9p7445x9Z53ak8XZeNn
Xmlp7rYg1AAmSmpkrHpraiVTTTX1QD03c0OUpoVhtcjdlmtpFqVaNjAh1ItGMLzGcvt1lW3kM6Cs
I5QNUsZ58mq1mroBCcxbU8ki5IV+UjgqqFFSkmYsrJfGIy6inUYEkhBN1WgAcorcDHM6Edfkafao
Hx3dzHc3Flinqs6Csql2NUOXhbJhzYxmgnMVUXQnfPy1ULlJE7mDtTvftavKS8Z2NS9MvValQCUq
y808pHkuulJzBkEqirccz4Ocp7bBDdMD3UV+fmrIrKVuner+BBpzG3mod65vCgWVl1HsY17V7ak5
xYqt1d7Z7kKv0+nOe2W406FQ1QKdLtoxlZMqXa+RGrASrToMErdlm40Q8Jd5z9soWZGuMG3PfYt8
ZLn2yvCAEP5s7cjZpfk91mC8kRuV9+4A2VYue2E/RkwKx1oNubY0zIDQdlTUyUxLt2ER3AzR4XDC
p7gWdK2c62SyjJoTnnWyDKrn5jr4aOcSq6KIKT1HsLAukVNLx26dDFSrL+cMNKTuSnnhpmJzeJMc
+GwjxZ/0v8balnpd2YA/i+0D5NEXdCcUyqMrTIsUY20VpuOvCbe6j184xYnDOqU3UA4n8UFsNo50
R6uZdjn1xYOswV6lM5TEGK3EH8QZrcdO4jh5IFDtq0pgIIPdAustT24pKb9uV0lO/G0xSYvGfRAj
j4uiCo4MQqW6yXhkmyrbMEo8+3rHKEUyirbDfVhXURtKp4BQlyQKCq2OzgCOMVgxtCsaUteXuxmo
Nlmw5VpNCCQRhZHODbUvpBhtmjHkn7CINFC6IWPDfKU1pW+g2ye6nbKeNlYhG1YDuJtht5diIldw
hpv5tjfZH0UhG5y3XJIxxGl6HpZwXhflHl0HvMnrIe31jIugU4xqxVYb6t7ElJ3lOqPKXcmGPktc
AJqu9lfGmxZczjAp9snI7HJd+009NXAanmWqBCKokQa5bfvQecaEy3YaoHbzFW0ntYuMaVOIyCNN
XDu9zmpHNmxbetUMN9bagf7l86SByDh9nZ1OaVYbNTT1T5Las8ryeK5Jtkg1B1tDUdCGOyKxDPHK
7Ny2dBJXbH+WYlaUmwzfBmLDTknQr44ETY7knOTWjgtM55hcKmunJTFJgHyEbhUydoiLzx5PqQyZ
dBcOXG0q+Nuxd9JasuMKdWfHpNbDLGpZnx1xsCYChFCvvLQSEOjUfDukwMOMf2867oHrTDux6Roj
B9KKe9nAHpBd0MoYG5XRzurmpYuLIz5qCbs51FkZKOrzNAhxRuqZR/MTQcjJPsgUK7snbKRp9eEN
LVCrpePykFuZFD4EJn32iiRn93x27xci8l18bmDCVxgF7Io2wemOCgsUUFUsSU3HBdh08K76wFoq
cZwGbNY2iFH9R5WXdX+bUeUBw7pHKylK/4IPaVFXY/dpAYf2Ve2Vsb5IXYjKcgo3iFGTcNibgxTx
DisiMUK2o4Dkqymw8rlpQclDk2ptYljPYAYnFusk4Yixm1i5SZsH1vQGUkcFbusNr7BMm+SPEkbD
XdkJDstpbRSlZuWEd3VprUq/7TJIOEhLsP0mxo0KffZOalATeqi2qamAQDDOle5WmJmV7diye4/d
qjV+SkepTZcWxgIZpkhjxnQOqfIqIrZ1YaWV04Ro+mJoGAelO6DGEnSMpqe0cuxBZScNtx25RseV
SLbzIhuRGNZ0NhHqAHQFUw9SJErItstKCww1uVIDlrK+obiB5Eg27IeAejRRqPv3NtuXsc8nwWmi
a/msDLDECFspJf3EAmWyJf/Wn6O0BDEoyNKJE9IcNcCYrTHZ1WTRIC3IsPIgU0PSdT/O0/p+7XIA
E3q01Fnj06L1tWaJP6fcTzc8KB+OdN7OsVnf1C6DUyNggaI2aMqCsUvsH7kP3uo20oNcN0lKD1/G
sNAvfBNRbQcGOUovAmramypMWMaqSGCXRn6HXpWwlpRE22lBGcaVtroeOWQ44oMzE+eL0dC+qcOq
aeuDKMHaAzY9FIC1tFjnsyuH739AbvmIcEirQCzSlY3ui9KWm1VbFtkcwNk0RqOntKTb8iST1Zhg
lky7zhgml3n9VrRjOqh0LmebaBQayGoIPfa7SbvNXzqn18vSSjv2KfzT6pTODQiJ8eYZBJWZt4im
TMJgUGozJQpjFSEjXDuQjCIcJ/7AvPOij+rGbqoDUdB7YFFGNhjk1js5yWR5qkc4mtoKGIEqz2er
lOEKigG+DC/7tDgQF838qYJJnNqCMgOuyNZpwbxPOu/n4z1uye8kxJGfjS1efneCuqQUkw3WhinB
IGCfXvwxKU/lbVUUhybUOUxxm207STM6SoRQLujlUE1oaklzWqDpOX2Q/8V4zppg/S8Jy1EE42pK
1DpF4bBLYksTHdn0iRWtnnddvdMZQhV/5eoPbGZQW3KZGTg1Dfn8esjflSskFM0S8vaN0jXql8bI
2HSRrLNAPPBqUVlHZP25cqs+v6jIJmcMuX7yDczsva+Yf1t9M0YW9FNqvV5hhg0IpjNBJKl9r8NX
mPIKuBfsTzFpLUmKZTkHWRvkdfy7iveo7wLFVZ6wm4pDBFh3B3FNTSslP7tmmsats+mQinHw5h3T
rsYN0iZ+52xBbnm/u+DHtbouywamt0S9GN1jBnJqT9FZoi2p43RbBXRwoOilJJYBl1l2K6mWInfI
Z+Jlb5xabX7M3byyjURNUqqmqaPZlVERtLnvQhMnBugkwr5TR/eddujq+lKX+r2rLrHlR/Z4/ZIC
Uqpf3iHnSdwuP1I1OCbsd2pfsU0zJnqZUD1/BB1GzRZUsb8yfSM9dsfGRVbv0BpcmyMVF9YUlM4t
TRvdpJicvZkm3Zmlnpxywrj8SNUqsUNJOcAyv5psGm1pAiPSpaTOjEiXYtvJoShDg5Pa2z3TqVHD
SB9K28On6qxeWQ/hnn00DQUOXxOHEzYMuj3kcltdkXOMKCbOLZyXLqtDkjqBSuis3DuR1tek9mJs
bt8mrtO2/Y+yWshQgNWRNhyvyF26onoXqxo2X54d2BafwYQawJ65lQmo3UTTxjNBv8wXGklapojO
y1p7v6uAta3TO+M7zgkxLTNFemPDDx2JVm2LtrcUUGuajdc5UqAt8qc8Mc5Iuw34OOQ5uenNUt1I
H5CH8znwhBXXtrgyBHiMMCU01j3ob/aVb0oMtN3mZYkZ+1VSbVnRnqthBEnlVAEFnm97nZR6JVTA
uieC1PTKxqZaNHmebVtPOfRzCpq9hc9ZRp9f1oAbSLjz3Hd13H23haQFMx7Lvtru69fdJvr8vNSy
zc+8u2cYWlXoFeEYyRzjI9rbdJBASUsW8bG5ObNCEI8V1ja0/3JjjzZhrQs58J8kQYZ05OpvmwZ+
tRyHGx2u+e34pn1ZKotGuZPy1E8s9WGa8YPsmJxXjFhbtVVpnWih0m7Vjv/PlKvzVjfOtjbkY7IX
8SnvGXptGiIONYbH2seOPtUkJN5qD/X6WXqzqWt67c5ZR2+cF0jx1tO2POYZnCt74FxpHzl8pOl9
XOX0CuWG+bcmkcGhA/1JbPWwrCEf5WRpCSKyb0Ln5pjDvHSBSaCdtJZHqJcgIOjOY0BuZNfTSu55
Px5m/lbRGvh9/0k/aelmSyvPj7VoE1uLi+3iqeKjHokKm673WMfcsexBUWO5pqd63plTHXn4gfuP
0JsUHwEF3ZJepQ3Vq+za93Us1V9QkAFywVauhq3NYNgqKoKw4ocoV+uYI6suVX2K9piWb0U01omI
ddgteRoR6r4HH3ywpBH4fMIWpy0YVq4CpgU5a4KW3FRSTIlrNzrvAUPmEMXbJ+uGj3BN+Q03DjhU
6io5k9uZj5zLnHo1q+Cmo5AeTu90J+e5v9X29p2zRwBF9Q9lQpUHo5z2d1weA+hKp3w/3j3rnvoi
276pvQP2AKgsY13RT7FlBOzlc6377lu8b+nq/+7KvTrpcJzBE6GGlStgBxvXS7eKHVqdVetH1UCR
Uzu8uLh48ODtsru0fFLecd97Dh70vpd/Jian5arXdhGuUzbgwlohHNxESPY8Oj/Hne7C2RP4u0Hp
OEY451Se82rcQv04rMSJiZ0Kw2lbFnneKVubGSuWvWVLUpO3hGscLnQoCbNnbobda0D8PVxids2u
2TW7Ztfsml2za3bNrtk1u2bX7Jpds2t2za7ZNbtm1+yaXf8fr+uEaAHagAVAAIgAA8BvAn4L8ImD
QjwDeP1mIf4NcOkWIf4d8Pe3Yf7tQnzsDiGWAV+9U4hvA77+PiG+AYh+SIgtwDYgB7z+AcwH/BfA
k0IcvVuIVcDjDSGGgH/8sBD/BPjbBeAGfBPwLcC3AZcBf7ooxMuAhcNCHAdcuh+4AC8fFeLLgC8c
E+IvAG8cF+I/AI8+KMQa4D8vvfaq+Nor4ksvvfgCfgR+nuPfn3vxGQD9fOrFz/0G/dXPnhMviRfE
C//3/4+g4jjt/5zRAbv/odEBu/+fv16IFwCnbsQ+A372gBA/B/jlg5Vu/LerU7Uvb+755Y09v7y2
55N//j59+R2xx/XI4+K28JKYE7c/I8QdgM494uTLn9hr+Pfr2o//7tl/8/GSLe/lA/tfvSWWX/wg
/0+aD/ywuXvDvldvwT0ev0/c+k7t/+8DfvcmIX7vkBBfAezzhDgBOA/4VcCXAPe+S4gfBRx+txBH
AG/Ch3zjtv9h70vg6yqq/8972V7TpGm6UaCFtJSQljTdS2lLSdM2XegSutACBZqtTaAbTVdErdif
P/78UOuGiIjIj01ALIiAiIiIFRGxICAiYq38tCBgqIjIlv/3nDPz7twtfU0LqOTl8703M3eWM2fO
nDmz3DueHjkf+DMwqZenUy4CrgJ+2ofoD8A9h4EW4Nd9PX1zLHRNKbDT6J0UdM3ogO5ZexTR3dA7
3wP2Ai8czVx75x16659pHv4DeO2VvXuefWqX8Xj4wfvgezfdzq4ddCvRzdd9/dZb2SWX/FSfRJdE
ftL5P8H/58j/WclZlJUswpPe/KSrhpL/853/uzj/p5z/85z/c53/c5z/s53/s5z/k87/hqLeQtFS
UDSOkl2ycO8PVr8XdRevC3yOv793jgwpyNCxw3VkSEH6N3WpoyFGvH1MdfrJYV4g9yvrcb8E3dW6
/1Dt/HJFReSXUtfq3gnVF9TrULY1H9Puch3x7MzwSYaOW13HLa7jhtgnPsc1mTn8PzRI4WqfRM4s
/Y/0w/iJogDX/dLwQf5M/ffYn458EfjL0Wq7vQL8FWgFXgX2AX8DXgP+DrwO/AN4A/gn8Kax9d4G
3gHeNXbfmy4hPscbHXDEp9bpiPhBLh0p7fde1THb9icY+37jsURVpUTfAO47jqi8TG3+s4zdv30o
0e1AsoLoGaAPbP2TgUuAx4fpeOAJ4EngKeDXwNPAb4BngN8Cz5oxw++B3cAfgD3AH4Hngf8D/gT8
2RlTvAj8BXgJeHkYWwMRP7YRXv/r3j88g/uvHvnJfXft+GZkOA2MXyF6fTUFuvlchT5Xgc/V1efK
97m6+FwpnyvP58r1uXJ8rmyfi00Ftk6o6v2uq3dcWYxv1L5gfztYx/uVT7zjRdfRES2XoUN+XdLt
u2jbxmTxtkvesS0+1EMdeSjbzyvAX4FW4FVg3zBv3N6pi98LZd6xnyMDh++v3ni+pWKkN+dSPDo8
7/ImMOgE2IbArBO8eZjngbxxsBGBYmAkMApYBFwGfBl4cJzO1/BczXXA74HdwF7gBeBNoM94jCuA
amAGUAOcCswHFgGnAf8DXAp8GvgM8FlgO/A54PPAF4AvAl8CLgO+DFwOfAW4AvgqcCXwNeAq4OvA
1cA3gGuA/wWuBa4DrgduAG4EvgncBNwM3AJ8C7gV+DawY3y6T3kLHPv7X1+ml6UC/uJUxgt/+tML
zu95/MF3j1tfu3c/99xzFP5lJUcAc4GxGLMlKCd5NBUmkokEfCa5I0/ZB2z+L9CYS1X/Lz6UdXyP
S9zdsQ5fsO/EOm5zHb4EfE98Jn9HHF93HfFU+xz2VzQpMBlUuJN72l3Jq3PWpqyNjVGAHSFgBMBa
919nTNijI23zYNqcr8N9Dx1vZebwxfGx0vfkldgn8Q63kfsdL7iOQ1ts/iXGquRB1vpT1348z+eJ
Zw4lxhcjzNGm/19Pm+QMpfPkjKA1xCculdBa2gC/RvnPO3fJf6LQRoTms5Aa2zldyE19E0KvxB+H
rpUUS+QUo1Xynz3naZOkUAL/FlwbkUsjnqwHPbUSm1NeITmvxt3SvEncNtZq+DG158l/m3CtgGuh
nPjU4qNklUMJn7HUYv7fJKn6S8Ax6/F/I22WdDgHe/5Ui5zA1BhRnlXmvKk68bXhVwqXVjjhmNvn
y8lN64SOEinRejmVamiaBlvqOkNZo3AnM+qZB4VyLhan3oCny5He+9UP3gbcHmz/b7qOjjyJN4Rf
zczRkTbmo+ADcbwc63B/WbOlW6LcEaaTYg1Aiblp7QDXkW7dfAe4A/gucCdwF3A38D3gHuD7wL3A
D4D7gB8C9wM/Ah4Afgw8CDwO/Ap4GvgN8Bzwe+B54P+Al4CXgdeAvwOJCRhPAscCpUAFMAyYCJwE
nArMBxYDS4CzgLOBRmA58AngIuC/gYuBLwGXATcBNwO3AN8CbgW+DewAbgNuB74D3AF8F7gTuAu4
G/gecA/wfeBe4AfAfcAPgfuBHwEPAD8GHgR+AuwEfgo8BPwMeBj4OfAI8AvgUeCXwC7gMeBx4FfA
E8CTE8RWdOvvrchazez3z39Eequ1yFbjHGA2Ud37Xe++QmU4qH0PHa/HOjIcsccnEB/sPXyiv65z
uIF7jb5wZ3ai5nDp8U3bt7rhyA+qLXZE1x70k4PW9h/Ik0NuITr6v/8HoRffw9J98A5f2/Rtd/hA
yEn/0O8HLQGg32pjzdeJlbqQZlINzaB5vrNXa3FdA9t+vS/sKvipFbwGlqS1QUuMxd4gdmeLk0qL
2P38fy2eNMgztYc3IK1yJ4X2LN8VgXNcl8uZrPXp81DVcm6hqFGC2uDuGEZPUGVbuF4s+LVSJn0W
zKlWzla1p8bWy5hEx0hlNEfiNMvYKXjS7BTJZb2c0rpSRkk8AjjTnC17lpS8vfga8iyHkwsQcgX+
1xGRLWM43gKJNzgw+vGXg+2Op4BfA08DvwGeAX4LPAv8DnhuQqREdf7+/X9dXDkOj0Ht+cdW8qxb
W0vUecg8Y7BOxt9rJNRKkW877uUWXis6Q9u65uuOqFdJXlukba71tWo3jebACHk51ZqZiDrQxOno
HEBTunVsIZ3BWC4+tdJutKXbcXHwzOf2yqg6RH3trITybANc69PU6WxKDVriQmjUoen/StIxtTzM
sQ2gs4mCMy7BWZSy9FyDm0az4alqmKGiodcKjS1o/64m1/kPjr1B/Pi89AuAvY0JSi1P0DNNCXoJ
WLo6QeuA1LoEHQW81pKg14FLNyboM8CzwHPAbiC1KUH5wBnAUqDb5gR1B+4HHgDGbklQNXAncDeQ
vCBBuUAK6AX0AfoCRwAlwEDgEuBd9vtIgmqAs4EngFeAVqDvhQkaDowEqoDNwKeAq4FrgIf52UcT
9NSVCXoaeOsNGMpvtL7RSi/Q8/Ts8795nh6Xv0ce+tFDj9xz1z233/MIfZtupm/SDfi7Fv/dcO0N
dNWX0k2l/Z2U3pnqWVVDkumT1mWTZWr4rAEkMbL5P2/35wDe/VnY5dwE/bFVYnSnPHM3ezwlfmC3
6PBZdURFSeQk3rmpBHy7qAP/+feRBnee6l5Tuy+VTuw8//3Dff575/zvh3v+t9P+/3Db/53234fb
/muUVro+HcKrobj27ZUhSJvWSrh92d66JVJug6kE6yEoT5xOk8M9q8HrRbIbHXptb7nctLn26TiQ
eqhI98taZg5rLQil12qSFsOFRsl3g7S8qDJtkrT0ab3QzTVkNbpyvn36vTqOa9/Npn22J1/RFlX7
rcHVGx43LffXSoqeHGVWCsuDurSG4NKoxKqcehp9Q1re1FclYZ3RIlbTxOUY1S+VSV71UqvaplW3
NhguDnN0j9dHNRoLplnytCXV9mfbHedsNc4iCrdAS1Xm/HctxIPtyaJ6gAPt2coMzYOl3lYLnesl
vNZOA62h9vt4z6pqT0Lao0xpaJ8Clh3VGOv2Q4+1izVfz95egFLOldwWmFqvl3poEN74bfG55Laz
welU4+3roMYpceo5mjPtlUF1upWm+J5eqYruG2x5OfcGcq3cGpoaeKJtvf0aXB8rCXEWrtqJzU5/
ZOVZpZ+fqLbXereWj7U0bMhVpp9uBv9XtsPRoA2i+i5c2jJTy9obcIvYQK69H8U5VyMMJn8PwPnX
w3+DhOaQM2gUjQRcK5Bt9Qp5tkZS2kjuGDaYp7Wwwz2W2gkbxKpoIdcGsLq6Oe2v3LOWwVrhkOpH
m3MjJYWqBUa+uU9YJc951LWF3gvpbS9uJmOl9uVUucBlqm5XM2VaAmsRc9w1tMkJs47c/t5fzlVG
plv203P4rbVoSstMXbfAf4XhoS3tWqGj1oxnNY/BhyBPtXnYSm8w/U1mJVktklknYby0VpLaB2Wm
Rvzj7KBVUy+SuVzo2iCls62aSzYztt7KJeUD4VR7qcXxoL0YcyNKX5MuvZZ9MlJrMKm1pEMtML2R
jhXKAqFYL1oLbWWAH9xy3dkMvw0bX7euPcv1sTYd0+p6ty5t/TabOt9IzcKVWokfTNFLKWjRsfQU
ChdVBttv0XE9hU2dbQLVwcG+LGhF+WVMR/Fx+qm9XrXOlMjfilaRJ2fRPaRqFDsO4l6M9f9KI6Et
UgLW8PVS1mYKWqe2tepIWPvKyUamdaRs7ZwD13aWE8wjztfjgbZEazMOS9u1UVYd6wamVi1yTrPF
sZyiueJadRVmvssbZ1u9H6dZPQmxc2PaL7s9R/sl359lVW+kaF3ap5bckbxrBXDKzPlm4f16Q5et
FdsizzMtyNOXft3nWVuc6yonNa9NMQ1RbaL9tFliqkjnW5olnXqqNRzW8JmPYvzWSXscbhLNslZo
VLnaRHYeukzSqk/Xktue7ajE7cfD9Fn6M6OFy8PWj7Zj1Y9bpISNIuNMl99ejbc0o2w2y0dPR9hU
lGKlT9u69kNcumm4rpD//LLljlzUroteAfBszThZqiMdtdgY0eklzahFZ5zbm3XyKLPlq5f+0ZPE
zHv0g7Ffo+vGm1/w0m+kaAu7RfjR0dkTbpM6wsncnrVl1JpwxybtjbysTouuSbXfm9NtyasVTU81
h1872Tz2L2WenevXSF4JLU3++cNwj2vp0hrSGmwKtUl3LqrWkSlvXK+jEjs71x73mw3X3DrwRjs2
rbA95K23uGt3nqR6/YLXV0bpIG+mO7oPi+ZALe4rDS+CM2Se/PjnP60kRc18zo/MmymNmz8Ml6CQ
5pH2YP7RQ3zf3JG5yWaHn1GlzmwuOJoXcZLFo1zVfAsiU8+khnjGk0c5a8jO7St36iQPlaX1ph0u
j6WwnKwtqBKpNnaj0bnKTXcd146l7OzIKvKssXguZ17WJqOBVpoya2vx24RBCXBp9c/ZtVfv/pma
KBme55vbKYycJ9L+3c4RKafj1qX2L/FhvVDo9LVRawLWVp8P6mpgLfN9Cv5rP55/7tzrvVQSOkIn
17D24sFVITcVT0qD7SQ8DojSsW6JvfIFdzF4PcZK01tqrluckgdXTqx1FMUtW3/tSZNHF6fvjkC9
GZ31IjNuP6YtV7kejOeVzz9D3R4fuRasvV1L1no/FBo0zJWO6s04fZipTi338YZn6nWcYvd0+PVY
VO/dIi3Wrjp5ffMGanHo9OZBo2Yuguu5tl5WivR7WjdqBsizsvxzUt66bXhGqcyXm+3xo+aLSkT6
WyRtXW/Q9aV6Cdliak3nQKJGdNG2VIXob55Pbk/reCVbgLqrie3B7WqZ6ol6o/VtWf3ro3Z+oySd
v23Dh0bq/Jzxl7olcvbck40WaZcrI/okT48GxwSNhnv++akgh6LHXdE60ZbdXVec6asNz152bW8N
47fqud+LH/u2t9/BP/5U7Ro1Rxctx2xJaC9qtZG/r2beZLomE5Wrf32gvXkzb4wRvyqgqcWPuSvk
/zVS1jU+udFeSNcX/RLj1WO49Wsd2ZVuV350FpXnOrg8ZWnNOJisrRa/Tl1mZGBwuhbc/kHnC2uN
VojSgi6VdibN34ctkLAb0jUZtyNCZ0Lcsvp1gM5TtARSi94TcehsmvZbXdwoO6hBPGmL37Hg6Smv
nr0SNJs24PE1Ko8W8lYLuW6DvZnNU3nebOTC9pANvqfrqdnw3dMX3h4sd6Qb13qCddUSwbH977zw
ehO7mzc4CxSmKsibwUY2F0v4ju2c0ZEU83Z5upb8vY/O88S3YLsK5fXx+yv9YMrUImpv1m1KZPj2
qfGHHmxGb4vJzkTY2UJtx8Gx2MkIG7W3J95SjOLWTDxbJLYFl2GKaKnCiNGdOyrUdhLHI2+lXXP1
Zqrc9TWrDTxNNDOGg5a34d1slgLvyWDSPThhrpTESmZwn/tysnZkuN6jejylUO2zOegRFiEdb20k
s3rw20ZxY+WO7AEK7sr1bGGuFR0nNTi2savNgpzREq0QqtorTaaz29pHcLkWUnB02L6dEtcHHWqe
2xSjx5pMebzNur/VoOC8eclHEzQQGASUAmXAEKAcqACGf1Tfo/nYlfouzTNA1dcSNBWoBq4BrgVa
v56gfUDqfxOUD4y/LkETgQtuSNCFwAfy8qvvnWqfI/7T4/Gp+T5K7ntyaD89Hu9o59fe979jvv2d
QLTDXfl2R76u5bpSesj1xirnGSAdWQZHCSq1ts/NdA7c7X1Zticb7ayptDcq8Vq8f401ut3YHi1q
R1L785th22Yy2jePrspI7fOVoRi6HmHbpzeOtzuyoynVdINroTpy1fkP/+xGo7EL7PyKcsy/chbN
dTt7pz1H9Iyfzpv4RySbyO3NXCu3vZrX0vpp98J7+lf78GBfqS4dz7r9cfSM8/7eEInS182iEzn3
VRlJGL9ZsT8tbXt+d3edllntrODKtK1pDa8ls2McXalsNjXKXLXrjf4xUnBVITgbYflc62tjdhbR
36NtEv7onG1cj1pGzb5ZYO1dOFR9WjrdGYiw9WnrvNboAl0dXmtkyt2b02hsESux4Xr1zwJYKWog
Ozen88buuMDOo/h3RpWlaWI3S3GzIxVKszubE6VrwnajDc0zZ1PI2rOeFPhtBaYiqAO8vTnB1mvn
CWwbCPLGjpI8iyd+J3w9ebuLbGlsz8Dzn2vkOcfy3pxj+grTfynn/7i/KnJtfb8VWZjON1zHQd3Q
nm1q7WfL+WB9NkZa17rXyHsvdZihpsZnX/vHJjYH/wjGGyfpnG2Lo4EO5F2T6B2+KnmuHGpJ6oz9
qjMG7m4v+35O+6MsqxlUAuJafnO6ddrdZf5e244iW4xU25K7lv4UtL8pwu/gbvmZgdT9fStLi+6L
HpzWgY2kowptLatDPI3fWe/Xhv71v9Wmtl3qOKzXp3KKSkMjeetcXt/AdpNt4dFSEuSQV2fBfFkS
5kXWvLZ+rkPNq9HRGkpJcEbEz51wCWsjyhmcR4x+J7uW4t4u8e85t6MUT3cGS7G/Elg7wt1V6tGu
0uW991otZdQ1iRpaY3heR83Gvt2CMNPSObc/K+7u2fKvWqyVsg6l4DhLa2mlT1tYCt06D/clWoIp
gfTC8+dean77vZyirQcbL3o1M7pn9GYkonjPLVnbge0vbJ15tNndCNF1xxo2ji5vjkfXpYItRy3W
ZtG1dj9XWZpiLsNGk0uj5BOsIZej0XNftleM6u8tbVantZd6mU9Cg7pU17H9+lDbnbci0WBoct97
HmzkZP/5e9a7vqut6Xvvm7h6XGWlnjyrqM7wdJPQzSEHU/S4xOvrlG9KG1Np7ZCo/eCurOgbEtrq
7FjHPxJjWnT0o2ueQetP7eCwDWjnU6NttHAZOSdeL1HZsnt12ltF8lPEpZ7ps5W1/thC30iqr4P9
EoewHOXn3mgkGHKV0M+yonVkpVHldgPVk5Vftwye5oubLQrzQXcnrnc47ObhcbD9mo1eCakzM4Ja
5/7VBjs+9O+Qd8cKNvQG4VlHatPqCs/GXO1QY2VkfzwM58a297w0r2ydW3pnws6cQ1GrH8HasJKj
syXa+v3jOF6Rcb97YLVBvKQ3kO7hXG/Kz21ui+hUd2+NP8+ofie42+HA2lZY07pv+6smsr2n2+va
GvMkhOteZ2N0JVbff/CsK3dcU0HuiqWrOf2jaPvEXw6/BeXuAfb3Ce442sa1da7tIKo/4dGfp69c
q0NDsM7VlQ397syGtDTM8c1NNJA7AupYr14v/hpe21ZwTVM5VJ52WysyvH5nxxs6c8TlDPrUk1ry
VuN7718E13Z0p4nOE3hyZjm4xsdPb/2hwdSs7UvtSo/lgp2TD/M/aJ/rqrWWTDXIZMSdSp7VqGkO
NjMX/p4pWDdc6lVCle2xWoQXvB/C6nXd86a6M6597d8CaF8f8ah3Tpp/vAYzxyfVlv4WsvN+7g4f
Oz+sfYHt/+z//pCuleHNGiktqlHL0rkM89Fq25+1PrxWXWFmD1ocSqNseNt7e+OwBvHnOnXHqME9
UDqPsoAaDdW23USNJoIcixoTBGvN2jsryc5M+/sk5tIKkRI7h9HRVt3emIO5sYG8Nw794/n10sda
O061J/dSVmv6tbnuUdF6r0+naFeA42eL3fnZGTSSRtMYYp1aSzqG09kqLZn2Td4eeG+/sG3l/roO
ctHrHZRnmXKUdZYr08yTaU5pXZq0t/TK3R7HNOfwfD3v5dskLm8Pcq3wLLwT0Y4abF9jqdf2XU62
bXtPppjvPgVXLW1NN2bMf1t39q1DPyV+23ydkah15NnlWzLOSVPWMlU4ZbKjsagS+SU3mKLtKXh9
erVw1P+dH/etSnfdJTiv1mRqpN7Uh+0H6yVXv+0UPTMZflfT0lFObl/gUdBMbt8ctLq99DqmMZRf
fr4kfdKh40V//plLjCcT/nULO2egLl4jm0u2hr325M73e29vWktEvwNneVRr9IqfXu+7I3YvsaYY
pNXOcrgjIC6ZymJwlifKtm2WNO030KzdH80pWys6Y7/GaIhN1GQkxc4J+9cJ/euS/ndL3PJF7wey
9fnhGp97OiFo/1rJitYIfqsmTLU7i+KNdq20rZGY3pjNpuy2SK+t+9fb/hXnEKLGv9xOO+cMDnTO
IL6Ww3MG0es01s5vb5S//3kFTlPHZqvJ2vY8Gxi0Gt0vzdmezV1J1hTdEbi70hccK7tjZNc/ylqt
Je+Lml4v5++R/XrYanO3lXm2d8fnv4P6zd+TsabgFVTVQB3LIzhCWEOujrKlbDQ9iTv60n3ptg68
feHcC2TSS7syacdlLekS2PGNN5J3x38HZ3u01xbseNXLIZOyRJdEac1kJO6WzdWUXrxDX06/te71
OlaLeSNvr425Vk3cSNo//m4hrw+KW73PZIVf/3R/7UwK7sDVrwLovhhvLslqhxYJy/MA9Q6F3io1
t4EVpF9XUN42m3py5UB5GTV3YdelrHXofScg/N7AetNqmCPe3szwbiS7k3hNmhLdo8vhWCfXo/14
+11sju2n4M5EeN9LsNpUw0fvDuZnk2XPAve+UXugbUmm0yl0YF8/tSMkLYl1WcvT8pbTjdrB0X7/
G7RK2pvFsnn4bcngvlzVerW0gVQP6zqbv0S2TUX1+n7Z86xjvxUZ9R1iP1110vfo24T+XkG1sOW8
yqR9G0F5HJ578++kmy+jovZrzWsXzDUuR3BXSTBVqzmUy5vIvgvn39HGqa80I2ZvVdLTIZ5eWulw
2pa+0Zey7reI3p10IGVjzVMlde29KR98862Fwu3d5uW+axf93o+3NqJl8EZfbqr7+z5Qg2+05e5D
D7fWOCn3xhGeRLW3v8vTIKopot4kaq8EUZLuae5NDnVWsuO+GNzijDbtPrf4cgf3f4TXFnRH1fp2
KS2jaFvR20vn7dpyv4sWldpgh/vRO/6DNFVITsH3HMMzoMGW6NrMwZF+eH6hzMhhcBbRzhQGczvw
72povc2VXLhON0Wm69XmGjN7Exz9rCe1U1siylEhNkI92V3TXs8bliS3FdVmGMdvGbnWhtpxOp/T
Qm67tNrL89H5cDuO219fHN+Ko3oEtTEapBbs7JJf2txn/pbkzRi4/a2On1aT14r0S4pRM9VBrrg2
V1lAIpUq9WMNrPtNp0heuq/ErsDGvSNqd3rxvJynjSz93nxeLfl3W0dpjLAkRq/QdETyK8jOZbDG
ayG746vFcM9aHkE9uv/v9ljZ0t54i+TAWryJ3K/7tb+f36vV8G5+j+/RKfi1inJANdT6NOcbnHKv
MCG9mZZ1kq72iKvJ/56djsSZ81pvbt1r/ge2m5BLNI+i9kJyezg3LZEN6becrUb2+qqo2onmjTu6
riX9YmKj2Qtj+z/LgQ2iHaJmedp7x9Z9M9FvD3oWU/RXrDzd6vZVrp4Yata0Pa4Gtad+0SlYdzxq
WIhecSiuJXSqpMch7G7f+WS/Nq5S3OCj4VSkewKNRZnL05QUyny9rq8vMhpGa97d1x79XscCmbFi
bvF8F/c9LAMnmFGmR+eMA6RzBtLRt+rLkdJpUkP2K6QLyX+uTWOAjhanfqaZVr3WadO2HmaTN7M0
2UhR8JvgnJb7Nof/Syeak5Z7NUo6XWhcZ2Tb7jo+1VDulzvlhtXkzK+J1CBxl0tb4xbTJK2mVtJ2
d7YMFb3JMmRb4lAajr8KPONZnklUmJYqbeluO3bHuVvEpRqV+TDHl2uhyGC1SPxIGkOjUR/2myTj
TRncXdIz0y3UrcuagN4Ll/UCajZysI7Uvm2ROuMzM+rlvj6yhNoXV5GdV5tC/resasiu9TWn27Gt
/aAUbSF3RiRoYQ8l1mw6hhpBJ8pfuBwsTd47bNw3DzU9VotQ4JVL5dktYbB0mZfKK5O37qa1bjnk
fxOlUGw4HXlzvMNLmC/+LxEXtisVPYlb6OlIexrkY7bYUqeYfHQ0vQby0RKQ4Ur8z2lX4L5a7tr+
SyhBvTIO3Rv581sgC5H3YtxPJ7Zu5qN2uOT8Da5FcM/A0wXCgXmQ34UScj782Od0WiCx5+DOvEiS
2w+H7R+da7CzWd7+C2+MXU/eyjrHWyE1pLN+/jffWOuGx7HuyNBNXfsXrofzTChOs0Jotu+x6UjX
Wgjh85UapBT1IoNWm22h8LsR7gpX+DSFuK8ccDncd2biv+3GXM50F4ZnEa03EuXuWMjMStH5hung
01C02BFoXSNkJPne/bFlvRa81S9wNknJyohbinJH9c8CKe16s3oS1XfNJt0vb+3WkaIbhlMX/HHL
q0E5poss90I5e4u/tmntObn83Be5cnegZ+u1N6+T6SzzofyzdFWHxvv81EqOhtQ5A/7ffo1Bw/CO
sUXmG1k84rFrBS0mXtTbZZpK2PIZ1u67cmE6NccpkTTMI2/kpPnys2qnDaqW8Fsm7D89VEq39MES
x/NwGPztvKC/JEHuHhqK35+/f9/f0843Hfh7Dqc533Tg7zY8CCy8Bf7A0jsTdDYw9h48A968N0H5
P0hQ+c4EzQVGPpyg0UD1zxM0A5gF1AELn0B8YB1wGbD36QR1+w3C/h/SBCpfRP7AwNeQNjAOmA3M
BS4A9v49QanXQecbCXoJWPou0gJSySQdBbyWlaTXgatzk3QN0ArsA14D+uUl6R+t9OJuevbJx3+O
Pz709cdy/eHjdwD8d/PjP7yK7/rsx/QkfYU+95XPuCet/prCJ632TZ8Iy2epwmPVDMqWc16LvRNb
zaPe6hMIaM9hDZ7SGjjxVY5q9Z/rmjdWY/YMxOSH5uxY9vbFyqbuU2b1coNmj7N1vBO49ZsJuvNb
CRpya4K2AtnfTtB8YBvQa0eCHgIeBnbfnqA9QANkYfQ9Kg/fcYVqR2aOb753jgwpyNBxYL9c+RRH
fil1re6d0O9y0ClLqUdDKyXSn+eYMoim7dy637Te61+xbctnfx/tFe35jXu9dr0VuBvIfyBBk4DW
HydoH3CPm4Kv4uMdPn6eF/skPk6GAmZ+U5f+i3DY1L9PJvzUjXj7mOp08MO8mLnBpCJ+Cbqrdf+h
2vkVcH0O2enp8J0PoZ0DKaPLLwWef9ivz5c+Bj38qwS9AsyGPp8L1ADzn1BdvwQ4A1gKnA0sA+qA
BuBtN3efw/d9njdcx99in/gcr2Tm8KWWYdLxjvjUPhCH75dDJBLXJ5EzS/8jFhmgyMrlkVwny4Em
4FxgJbAaWGv66/XARmCz03e/aPrvpt8jsT8k6D7gjT8m6InntU8fa/r1K/+KvgLY2pqg4fsSdCPw
JsMl8oN3+Oozw2AHXVHvVz76s/XfJ8H170hDP66P7X9LUMlran8NAkqBMmAIUA5UAMOBkcDo19RG
Gw9MBCYBlUAVMBWoBmYAs17zbLgaYD6w8LX26v5V1/FSp6NDjvTPq+Mu6f+Ktm1MFm+75B1HGo7k
OjkNWAKcASwFzgaWvea3vZ9+w7O/r3o7bIOvBR4E3q9G+13XEW92+ILdGuu4xXX4EvA9ibc3nZ/R
rNCxVv/2llb3r9PrO+2/J49rpu4vwv5+u3724pZ/3vNo8aUX0U10yje7JknL1BvIdLKVaHcglXHw
69g0L9F/aLEO/Y/b7E6ge5Y3jp6anaRLgEuBq4DdwB6gNCdJNwI3AdkYWy8D6oBtuTr2LsFYO96+
8zledh1/+Rd2XJ9ZMP3969j10DdFkwJDzsKd+dkQ6uTVOWtTVkv15PmRo4DVwFpgYCpJg4AngKeA
WV2SdAbwMPAI0Cc/SUcA/YAyYAhQDlQAo4GxwFVAD7SWCqABWAfsBZIFkBugHJgKVAOnAZcCVwB3
AHcCz/GzQu5L/iZ/L7+w54WXf/v0b3/125dpFz1CD9ND+PsJ/nvoJw/tnxf/Jr/sKbOKUSljUp/I
qhqSzDPzOtkyb5MaPmsAycxSNv/nzQ8N4Pmhwi7nJuiPrRKjO+WZu5kFkvj++SRvBotKuc1OBFYa
GRho6n5GF617W6dXA9cA1wLXAzcCNwG3ALcCO4DbgTuAO4G7gXuAe4H7gPuBB4AMv9z6VmYOXxxf
i/E98Y3/MqQgvq2/4Drew6/X+jLN8An/EmO1dcPq6E9d+/G3Xj0VkEOJ8RCzxNE6EjyS6+RBYCfw
EPAw8AjwKLALeBx4AngKeBp4BngWeA7YDewBngf+BOwFXgReAl4BWoF9wGvA68Ab+cl2hvw+R4aj
G9+YIUNHhj3Ue+jwdX7xjo4k7f6yZovql3rOHWE6g17iM9dKyJFcJ29yvQDvAsR6GsgGcoEUkA8U
AN2A7l093T4cGA9MBKqBGcB8YCFQ5+j+9cClwGe6ZmwfZOiIFyBfk+9IAvHB3q8nHaHN/+s6hyvZ
q/jCndmJmsNFImz9c508ATwF/Cmin64AxgHjnT57odNvfwa4PKL/3g3sAZ4H/gTsBV4EXgJeKWhP
D3SEIf+e1fiBOPjn1X9/rotWYB/wGvA68AbwJtcR8C5AsMWSQDaQC6SAfKAA6AZ0B3oAvYA+QF/g
CKAfcBRQAgwEBgGlhRnbAB+I43XX8VpssH8bR/oHnR/sBYB+XB9lwBCgHKgAhgMjgdHAWGAcMB6Y
CEwCKoEqYGqh2un/npzJgGf/2T+u/+7jqctwKh6eKK1JUD9g2PwSOnrHrmElO3afNGBHz9yBwDHb
F+YO2v7bxLE7MJDdMTSn746fZBVsb6VJGcUdjrjDc924OcMpax/ddEyakq7deXKyKVG87fJ3e7OJ
2pTInTcrQacCa8pkNMzEOoPo9y5qClFTGvXpjke9QaIqjwO/iKg8sVRB71sR3ag9qIny8c+ZVERJ
E6uMqPLVtiTfKVd2HOt38VfCzWFSsstgNQaWZ1Ci8lXaR2fAtwvNID3Xxe4KHAHfoUg7d1Aij82Q
3SCz57W9oH1aaVBDLsYnpXKtLNWBya5kLuXpdopyovmUlLTnR6Y9Er7HghqknV+a6FqdA81W8i6n
34r0m5BmQtK8OodsmiVEsylL0pwdmeYo+PZHzyhpJjXNsQk3TfR7ZDdXHIH42ZLajMjURktq2Zpa
VjC1Vqos5WVhJDVpSGIW5VQmUJpZkSmNgS/PJvdoaErwOG4z4mZTnzQlg2jerCzUaRbxvpJZlNtO
WmMlrVxfWjlIS+kIp5XXTlonwLcPuJs1KKtHQ18pWgOSnIgkc4s4xXmzspFUtiRF1ZSStKoj0xon
aaWi0sorIDehM6hL5QCkEy1zJ8J3EPzNBLedAdudUJanCnfmQSYgatSD+Sdl7pVOfyJNrtzX9g3c
mZqp1CjvZdgzQPU9hVqz53at7EKtNnvY3N9UqkJJ98kEdBeqIn77lfdF8j7wzRK2J+ogUNLNRAU+
3q+md+eBX4nVUmNV5H1ThHf5ryH3bCJCvXbnFEcMom7bWtHml+T0aHhWenpuawWJVMGxaGupglK5
HifXoVMplUeVF7/V1pQi0DgTVPdINCC1bjSH/O8xWj7zTjyiUipGHuOyi7c99Ja25GOd9nycXJF6
9+6y4WnerCRKlZRSjaUhldfQgATLYbHs0m0g3VHMuYTfQmFLdcaQBHI8QqSnFGXKASfnyf5Clpok
uJlCPn0k/VI6PCLcCRKuly9c34hwYyVcb1+4wyLCjZFwfXzh+kSEGy3hDnPCDaHeEm6IL9woCdeX
utJ4btAalMqpl4Qt94UdKWEPRx1Bfp3g1dTTtC83NOvgvnQEhKwpwTqscGdXytqVXJh7GbrfZDGn
McE0g3SuZaih2xJQwaBnNtk37+aS950K7hdU+yykEsl1ofhxa9C65DAl1A/SOBGSMpGsqJdBIrNV
Ne8tSXo6rIdP9qvoaEm1SlL1y14v1tGDkr2u3ZUs3JkiOdIokbSS5qZRinL8IcFp9EhT1r6sdUvT
052mzeC+r7/QAduZCiPS8Fp0AR2Ncm7P7dHAM9J9nHRcmkrpyAgpOVFqtMSRkpE0GLQXJ0dKHdSk
W6G/DrqqjtXkYY2JvsCdaXV7bd3N3kCNRlPl0kDQuivp1zfjTHxuU3nUYt4C4pxGCH3HOKVK+WKO
lJhVSZXMOuFkPrQw86N429p/9jDx3DjjJc785Hhie2KmQ5/KbC56d6YxKq6WtC45KSLuSMm71Gin
y9+Nil8t8dclq4WHdaLf9T1HPdekRbjUg46D9O5KMhWcEndGfo7NNxxjCyWL9BsVbD2V8dA6Z1Ci
27Y7QMfUPNGQJBqSREOSaEiKou0Mkyb3btkmzbX4v5wG+1K9A+3oIYpLuSdFNCo6W9K+Jnm2lHu5
01a9b8Fz7zkk1GpbpdVqbmWxtI83tI+X9JucVuumn6TjqYgCUdFXatyp0pb8cZkL60ytdAEnZEL7
jbzIVCahfT2e5FS4ffFbCCtFHrvDEgX/tChsVUArG6vwlBn9fF0UXQZaXqU9ycuEltlGIty2x29L
EPF7tfmlXbtWt+UVbSvNYiHhCddJO6EME+hRE1t5AMB2Fv8q6GB/Kvf7RO5zpP+vM6UroGFi6rBF
15Bup5UX51O43SSzOH6uE79OUhjupCDyE4xu8u8Rit8s8Uf44o+JiD/RxJ8YiM9SkULL1fhx1I+W
2COzRkvoFWTPYtdvOXKKoyCzV+f422iT6qasJmKZdd9Fa5a43rsmtp6JBqDfhi1VtO2SHNsANpN0
nF/p/ef+Px3AdVFE6DN9pRtPsyF787NY+lkS9Z0YbotjOLViDMM8ey+gSSppCuLWZVUSS2rYYizx
aTmu/bEyfcc9RgnxEh/XzWOJdVI3XeTt4xWBfrM3rCDQ0fPa+7N6wR6WLnhlSRK0stWv8bX3yCPe
l7DWvIHSKHHHaVy2ozdTOm6e6pleRFw7PGYcLaX3YnZD71bq6A2v3Dx+5FZ/fvKarKlSO1WOJra1
4ZZbW103cLpoW3VO8ban3uaKYXt7YKXVHXnyfon3dVy2fiYYy1g1+fB3OBYXo6vdui9rpBOl1T8g
0llA0wPy5fX0PYh149pU8bZlbwojxmUTW89c/sezmMJC0i9ErpPdHawt+FufVh4G0Uk6K/93Fo5r
e4CU48HRbuQtzhNbOWwLeOOeLtnMr2WSy56sZaFc6gOl5hqVEcZzksvg6Fxc60Rz0D5iX9bZIkeT
yZ7Is5H0ixJs+59seiId10uvMED6oEFS0wOkDxrUk9KvJjitxPRv2dy/pcQG2yg1bek+hipN6u0k
TdFpj6QRPILJVqvJSlDQauJSyeiwF3NgLE1FnIHZY4WjXhz7bhLL8QZSi6ZK5lJkqEbc1xVjjMet
vSgwCl0sXx325zklveWKRNIGUFX2RKkBf9yRkbGnOrHLTc7lwkGtIfs1rc0SepqGlgkhtuoeS9Zl
j4vIawSosi3L9mk5sHLBefzHVl1t9jrhZhHk32rreeiPLXc0NktFEi2G8D/X7kXZ69Hv8fc/moxU
aj/u9scjQEuWVLLQejzJyLU/OLwjUbyt5t0eDbuSCZKZobxEUyKRysvVnqFKZymmzWhts5U/i8ZW
fiP789mzJFevDl19opYhv2Em+VXpiLu7jH7dkcNUGg55uCZ7akCG3LSIjiSzhW5zelOlobNfkvf3
1ND4yuLs27NrAlLl1qtS1ItOIftmwGFILJXHhEXRxZx9IFvtI682giPzLjzHxXbORK903MpzkEoO
SsGpPJ5dJbJjxx9VpN+gY2rmpHvxVlXzNYfnF0g61kQaSaeCQ3tMK4vqq0aJHM2VHkp11z3Su+zD
neO4FPObutYyvAD0ZA2iHJaJfLWqxmX3aLhPyFmS1MkFWFdt3PHJPipjWuF3Mh3c7zCawCYHs6vI
sQa7pGgJaP9G9jXZS5Bbcax0eaeLEUaCNSodRQnucnpeWwP6r7aSzLOc2TJaHUL56bmAvHRPt5l0
BJRPp0IeHqLibePaCGG6xoTVEc98Hm0lbNiCmLCjJOwCnh9K2rCFMWFHS9iFCFuSZcN2iwk7RsIu
Qti96bBFMWHHStjTuKVn27DdY8KeIGEXI+zmHBu2OCbsOAm7BGErc23YHjFhT5Swp0t707AVNID7
jhy20gt9Yf06k8zYjO2lz9HtOToGrQ1p4SI6M63fUl2rzyBrbai5RneLtbEPd26z/IWGOjoH3OYv
mcxGmyC6mHg3YWLazq0s5R/kbsKutrcVypeakdpSYk0UnH/1dMnhdBapkSCmF7dknpDsee2lXIDK
i99uYwvHHXzxLKSOEW4XKywP7aiZvG/+cH5nk5dgkU8vcezTaD5qcV/OaaT2ZPt2tLadAvDd2ofj
snsandnHR1UV1bAk5VZRnM7jlHJoGacELRpMg7fu1dBClrBc7hPyffO5nm15FLjXbduzbUXbPgN1
Ucw7yHcla/K2d+neTWqiIJ0yp1hGi3guNZfXaXgmfAvpm/ZqffNLdrk8SqkakhxJw5D3yFymMtsZ
6RSAAtFUX+D+l23zPNCbJxU9VkdOuWOJtbg9X4J7lQbDL2tH++NNpAXIa37uxAzrYJTQ2Si2FaH9
noi+vC6XtW18X8765jDYIbbnJJLqq+zK3RZF16HOTqzL1fEZnwyyUiyeAsitVx5jWfZx+4BseimP
qLWAaE8pUeM4blFJ3kGBH+sCfmGAd27ZRsbtldfJsiQneQ9L2ikS4Y4LdcUSwJLEuZO8P871WyTc
5Xlx5hyXg3tk3W/eh7TZ9yVuWURHEFshRP2IV5lYcrjfIfCGx69EA4ltaR4H8DoZW+1Ex5Gs7dFg
Yt1IdDyRWJFDSWcnhgHDiaT3YUnhmuFegLnNWpu1MSshXj3jOa8lwDKAx9YbgK8A15C+kPkT4OfA
Y8BvAB7s8NbNLmDOUcDRQAkwABgIHAOw2XksUAocB5QBg4EhwPFAOTAUqACGAcOBEcBIYBQwGhgD
8CrbCcA44ERgPDABmAicBEwCTgYgpjQZqAKmAFOBaUA1MB2YAcwEZgGnALMTWvtsqyQEbfiR80uG
fDlcVsiXw2WHfDlcTsiXw+WGfDlcXsiXw6VCvhyuS8iXw+WHfDlc15AvhysI+XK4wpAvh+sW8uVw
RSFfDtc95MvhikO+HK5HyJfD9Qz5crheIV8O1zvky+H6hHw53GEhXw7XN+TL4Q4P+XK4I0K+HO7I
kC+H6xfy5XD9Q74c7qiQL4c7OuTL4UpCvhxuQMiXww0M+XK4Y0K+HG5QyJfDHRvy5XClIV8Od1zI
l8OVhXw53OCQL4cbEvLlcMeHfDlceciXww0N+XK4ipAvhxsW8uVww0O+HG5EyJfDjQz5crhRIV8O
Nzrky+HGhHw53NiQL4c7IeSbsP+I75UFUb5fjfT9WqTvVZG+V0T6/ijS975I3x9E+t4b6XtPpO/3
In2/E+l7e6TvbZG+3470vTXS9+ZI35uML9fZOArW0EzgxJAv778YH/I9BZgQ8uXeeWLIdw5wUsiX
1zUnhXznkY6n/b5st1aGfE8FJod82TqoCvkuAKaEfHnleGrIdxEwLeTLdn11yHcxMD3ky9bJjJDv
6aQ89vuyFTcr5HsmKY/9vjzumR3yPYuUx35fnkWdG/I9h5THft9lpDz2+9aS8tjvyys280O+9aQ8
9vuyjbsw5MujqUUh3+WkPPb78qh3cciXrb4lIV9eCzo95MvvG50R8uURypkh35WkPPb72v/9vvxO
5Fkh3zWknPf78irqOSHf80k57/flmbTakC/Pc9aFfHkcVR/yZXu4IeS7kZTz4R/riM4xw3/mmAHD
Tv2l5J+U7LNMyfgxlS3XHLnKXE4qT66yPJPqItd8uXaVq3QeKfniWErmBFJFcu0u12K59pBrT7nK
Ikeqt1z7yFUmj1J95Xq4XI+Q65Fy7SfX/nI9Sq5Hy7VErgPkOlCusn03NUiux8q1VK7HybVMroPl
OkSux8u1XK5D5Sor4qlhch0u1xFyHSnXUXIdLdcxch0r1xPkOk6uJ8p1vFwnyHWiXE+S6yS5nizX
SrlOlmuVXKfIdapcp8lVJthS0+U6Q64z5TpLrqfIdbZc58h1rlznybVGrqfKdb5cF8h1oVwXyfU0
uS6W6xK5ni7XM+R6plyXyvUsuZ4t13PkukyutXKtk2u9XBvkKjoltVyuK+TaJNdmucrbnqnz5LpS
rvIueWq1XNfIda1cz5frOrm2yHW9XDfIdaNcPW3G0syyrDMiFvvX2mTihX82xRzrYVqMv9/i/BCi
PAnNyOnm0MT0/zYVa68zlxpMvC8AXwTuQYDvc5tFE5wOnINGuAz4OBLdClwLXAd8BQ3ya2iIvwaS
aIpTgfOAbcAjQCka5nHASDTNUcBraJzPolH+zijm84E/A5PQOE8GpgMXAVcBP0Uj/QNwD5rp94Ff
o6E+DbwAHIuGWgrsBJ4FuMmOBpYDK4AWYC0a7d1ost8D9gIvAC8CfwFeAl4B/gq0Aq8C+4C/Aa8B
fwdeB/4BvAH8E3gTeAt4G3gHeBcohDIYCyVwAjAT2IjmX4XG/w3gPjT/cjT+pcBZwFpgO5r77UAS
Df4ZoA+a/MnAJcDjwK+AJ4AngaeAXwNPA78BngF+CzwL/A74PbAb+AOwB/gj8Dzwf8CfgD8De4EX
gBeBvwAvAS8DrwB/BVqBV4F9QBtwJ5TPTqACimcYMA4ohuJpBd4CdkLxPAa8CQyC+jkWmAXcC/wA
eB7Ig0JipVQMjARGAYuAy4AvAw8C+4C/AdlQWz2A+cAyYDOwBfgVUA5lthxYATwL/A7oAdXWE+gF
9Ab6AIcBfYHDgSOAI4F+QH/gKOBooAQYAAwEjgEGAccCpcBxQBkwGBgCHA+UA0OBCmAYMBwYAYwE
RgGjgTHAWOAEYBxwIjAemABMBE4CJgEnA5XAZKAKmAJMBaYB1cB0YAYwE5gFnAKcDpwBnAMsAxqB
5cB5wEqgBVgPfAS4ELgY+H/ALcC3gO8CdwI/Bh4EngZ+AzwH/B54Hvg/4CXgZYA7iy5AN6AI6Af0
B0YAI4FRwGhgDDAWOAEYB5wIjAcmABOBk4BJwMlAJTAZqAKmAFOBaUA1MB2YAcwEZgGnALOBOcBc
YB5QA5wKzAcWAAuBRcBpwGJgCXA6cAZwJrAUOAs4GzgHWAbUAnVAPbAcuJyc31ZGtE//DHxCsZaF
fGT0up9Y/3I+SzMIs3+f3gOifBIhn2TIJyvkkx3yyQn55Pp8nN/74BPkGNOTF/JJhXy6BNJJ/9I+
+68LTic/gzBd9xOmoz5FGYSZlUGYoE+fkPz0CclPn5D8ROXVkdwz88kkr06f98cn/TuoWH0GzAro
H/bJDvnkhHxyQz5+DdBxelIhny4hn/yQT9eQT0HIpzDk083n0yljnT6H2qdj1kVUD1sQ8vHLc2Z9
UyZhDpXPpAzC/Gf4HBobcv8+V1Tq/KwTJgOffAr+OJ1+vjAcK/0THw4TGAWEwoRT7nhJx2YQ5j/D
Z24GPiM65JP+fQh9ZnfIJ/37D/OZk0GYTp9On7BPo9m17p7LradjrpL3n/g///macac527O03BPt
9c26qLPHvNPHgqkEz4eKOh25iewZQkz5eUKXnozW6NBrz8vUt7z3R0fwfDH3FMSoU8biTrJVevXE
WT2Hy54cybu83bMd3TK5Jz/GnXjdPv22BuNOTHXPNIsrV0dOxPWfaOtx0zut1J5ibU+jzKQU/nOS
dedwo9k3rHK6hsKnKKuvPSNPT8Ds2Kno+k0ArtUW2Xmsb+/Zk+GGyTV4fqM+D565N1hKpefhNUrO
fG4py88iUx63BVqqMue/lUTmRAPZk06t/DFF/nMB25MQtyZVdudIGnzKZknonDf/+V0rDZfLDM2D
pd70HTp72vca0jOr93fCvD2Xuz0JaY8ypaF9Clh2vFPV2qNHY9l8wycWluE/rfV6qYcG4U2zcHmD
+AfPJxucTtXfGl3dGT7h3KvnaM60Vwb/ed1R9axPlKoNEZLpldeeDunxxJ7F6D2xZ4i3V4PrYyVB
a2e9tBiuQasDV5kzl73+yMqzSj8/8b7psV64ttC0/0Yn5CrSb/o0k55wHUfpGuedWqvJo0pbZmrZ
O8V8g/h75zCHOedqhMHk7wE4fz03vcHUzwxzRnGJUxt86l6FPFsjKenJ4V6v68+z3PAs3GMxLS3y
ZqI9sdvaAFZX+0+59iyDtcIh1Y8250ZKClULjHxzn+CdVLuF3gvpbS9utCTZnnWTUNm+nNpTPvVr
T/GaKdMScE2wZOi5vZucMOvI7e/95bRnmLbsp+fwW2vRlJaZurbfd2pxSmvf9FlFjaY0LZDPg89T
bR7+okyD6W8yK8lq551ZL62VpPZBmakRlrAtZC2CoFWj5+rq11Q2kHtW+mDztl90vZVLygfCqfZS
i+NBezHmRpS+Jl16Lbv/PGUbaoHpjVaRaih/KNaL1kJbGeAHt1wtU3NaJ3g2bHzduvasngPt6UzV
9W5d2vptNnWuJ53bk9eDKXopBS06lp5C4aLKYPstOq6nsKmzTaA6ONiXBa0ov4yxpMTrp/Z61TpT
In8rWkWenEX3kKpR7DiIezHW/yuNhLZICVjD10tZmylondrWar94xPptspFpTtmzcw5c21lO2DOf
PR5oS7Q247C0XRtl1bFuYGrVItfzcz3LKZorrlWno7TJZEeKnt6P06yehCyX9BtJ+2W352i/5Puz
rOqNFK1L+9SSdyK23wrQr9SskLQ1llsrtkWeZ1qQpy/9us+ztjjXVU5qXptiGqLaRPtps8Twe5nr
yY4t66nWcFjDZz6K8Vsn7XFYvymhb1urXG0iezp9maRVn64ltz3bUYnbj4fps/RnRguXh60fbceq
H7dICRtFxpkuv70ab2lG2WyWj56OsKkoxUqftnXth7h003BdIf/5ZcsduahdF5QVlUjP1oyTpfAZ
7VHpJc2oZTJZWzdOB3qU2fLVS//oSWLmPfrB2K/RdePNL3jpN1K0hd0i/Ojo7Am3SR3hZG7P2jJq
Tbhjk/ZGXlanRdek2u/N6bbk1Yqmp5rDr51sHvuXMs/O9Wskr4SWJv/8YbjHtXRpDWkNNoXapDsX
VevIlDeu11GJnZ1rj/vNhmtuHXijHZtW2B5i+dA+pTlSUr1+wesro3TQcqo1dRLdh0VzwPtaTHiG
zJMf//ynlaSomc/5kXkzpXHzh+ESFNI80h7MP3qI75s7MjfZ7PAzqtSZzQVH8yJOsniUq5pvQWTq
mdQQz3jyKGcNNRtZVe7USR4qS+tNO1weS2E5WVvQfsVLNVWDw82Nkke9qQkdS9nZkVXkWWPxXM68
rE1GA600ZdbW4rcJgxLg0uqfs2uv3v0zNVEyPM83t1MYOU+k/budI1JOB+eEMpf4sF4odPraqDUB
a6vPB3U1sJb5PgX/tR/PP3fu9V4qCR2hk2tYe/HgqpCbiielwXYSHgdE6Vi3xF753DlRf4+x0vSW
musWp+TBlRNrHUVxy9Zfe9Lk0cXpuyNQb0ZnvciM249py1WuB+N55fPPULfHR64Fa2/XkrXeD4UG
DXOlo3ozTh9mqlPLfbzhmXodpyj3gnosqvdukRZrV528vnkDtTh0evOgUTMXWwwXW8h++13rxX4T
0nI8agbIs7L8c1IttMbIYHhGqcyXm+3xo+aLSkT69cRQXW/Q9SX9DmSLqTWdA4ka0UXbUhWiv3k+
uT2t45VsAequJrYHt6tlqifqjda3ZfWvj9r5jZJ0/rYNHxqp83PGX+qWyNlzTzZapF2ujOiTPD0a
HBM0Gu7556eCHIoed0XrRFt2d11xpq82PHvZtb01jN+q534vfuwbr/+C40/VrlFzdNFyzJaE9qJW
G/n7auZNpmsyUbn61wfamzfzxhjxqwKaWvyYu0L+XyNlXeOTG+2FdH3RLzFePYZbv9aRXel25Udn
UXmug8tTltaMg8naavHr1GVGBgana8HtH3S+sNZohSgt6FJpZ9L8fdgCCbshXZNxOyJ0JsQtq18H
6DxFSyC16D0Rh86mab/VxY2ygxrEk7b4HQuenvLq2StBs2kDHl+j8mghb7WQ6zbYm9k8lefNRi5s
D9nge7pe6oifefqCnzYbjbf/+d1gXbVEcGz/Oy+83kR5G54FClMV5M1gI5uLJXzHds7oSIp5uzxd
S/7eR+d54luwXYXy+vj9lX4wZWoRtTfrNiUyfPvU+EMPNqO3xWRnIuxsobbj4FjsZISN2tsTbylG
cWsmni0S24LLMEW0VGHE6M4dFWo7ieORt9KuuXozVe76mtUGniaaGcNBy9vwbjZLgfdkMOkenDBX
SmIlk3XzdMSZD606l1T21Y4M13tUj6cUqn02Bz3CIqTjrY1kVg9+2yhurNyRPUDLxYqoJ0+XW1uY
a0XHSQ2ObexqsyBntEQrhKr2SpPp7Lb2EVyuhRQcHbZvp8T1QYea5zbF6LEmUx5vs+5vNai9eXN3
5ONaLitFQ643VhnPAOjIImglKtVW52Y6B+pqXy7bZNM6NZX2rFKvxv1rbNF8sxotakdK+/Nb4b5t
MuqXresyUvtsZSiGzkfb+vHGcVzvXjsNUqrpBtfCdOSi41//6LbR9At2fK0c86+cRHPdzt7MOZHo
OuB6YDewFygZTzQAqAZmADOBeUANcCowH1gEnAZcAjwIPA68DLwGDJtANBE4CTgVOAs4G1gOfAK4
GPgScBlwE/Ac8NSFRE8DzwBVH0XewGnANcC1wIX/jXyAhZfCH1h6GdIExl6BZ8CbVxLlf42o/Hoi
eoP2vfLnV/bt/t3up3fvoyfpMfol/QJ/D+O/Xzz8C3rw+7ffTNd9lb68/dNv4I/4L/TL5k90U8G8
WSgEIN8CzxurB0b0TB8/4D3Mt4cj9fPHyqbuesSc65N1LmeBGItSCf6UL3V1PrGMnIuJsuCTVTUk
mWeeZEvM1PBZA+Tjv5TN/1GhpsT/I6nCLucm6I+tY/TkqTxzN5RJ/HT4ozg8jf4ZeP8w8HPgEeAX
wKPAL4FdwGPA48CvgCeAJ7mugF8DTwO/AZ4Bfgs8C/zO1OfHLtQ6tfU51dTpB3+667+Y481Yx75Y
R3xqkb9Uf9LTv3PlsDQ9+zkpr5sf+UGe/1oI/TMNunkytPM8o/eCvb+1gWrI2yc71BkxRM1lFFLK
jFa5p+SwQ0N2y2Ky+581bTtWVe0YHE9Oie0b2PIrQF51xKOUdUKlWn6H5s/d3e3Z3a4m93rBevLv
OQ7OnHP/zadWcrzwDiavT+L+ys42xu9PdteNMkl9E9m5NO+dDbvG5NXzJknB9nr21DDeoa72PKe8
QnJ2x9S6hzLYV54n/22i1WlrT597lKxyKPHmf+z8aXgczjaCNyZ1d6r7d8zFzQHb8CuFS+4YODy/
2NHZqzjqmQc6i8Ope1aBa0MslBmjGXICjUdbrcxo6TkuXti494O0xhokX3d+JOo9C+UH7wl0V/Pb
K3lwF15wpOFZTGEp0ToIj+gO9q2Jsg6MkM40uuUss3MwPr6GPMvhZPRKazjeAok3OCD98eWIn+O2
OWcyVxy0+8vJk/v16VkGa/Nyvm6L0p2AWyh+ndW1jMOzfHWk62PWrrbc2UKqwVTma0l3PTLXbbs4
sPnwWtHCdpYhuF5kqVNtat+YG0reu3M2ppbHnQVq//2sMvJmdbw07B4BlbCh0kLXku7rH0xuS7bz
iHE7sbwa6nz/r/P9v873/zrf/zvQnq3z/b8G6nz/r/P9P9fe73z/z51tPfTS217cTMZKmaxPcpk6
3//reJ6d7//F8aC9GJ3v/3lrnnblwm/Rdb7/x/zqfP/PsxusVdf5/p+7i0Bz7Xz/z+3Hw/R1vv/X
+f5fsG463//zakXTU83R+f5f5/t/wf6z8/2/zvf/4sva+f6fXy90vv/X+f6ff4a6PT5yLXS+/+fq
sajeu/P9PzsH0vn+X5Az/lJ3vv/X+f5f5/t/nlb1a0GXys73/6L1pqvt43cseHrKq+fO9//c3sTu
5g3OAnW+/9f+rFvn+3+2zJ3v/3W+/7e/eUdNSfsILtdCCo4OO9//syOfzvf//Pavv2/7z3n/TzVH
9IyPjpv9FukmcrWZa+W0V/NaWj/tXniv/akOD+pKdel4xtXH0TOO+3tDIKq9Nkub4NxXZSRhvLN+
f63Uan53d5WWWfvZ4MqkrWkNryWzNq6uVDWbGmWu2vUmv40cnFUOjkYtn2t9bczOIvk12ibhj87Z
xWnUMmr2zQKqduFQ9WnpdEegYevD1nmt0QW6OrjWyJS7N6PR9EVWYsP16h8FWilqIDs3o/OGrl1o
x9H+nTFlaZrYzVLc7EiF0uyO5qN0TdhusKF55mQKWXvGkwJ/X8FUBHWAtzcj2HrtONG2gSBvrJXs
9XjxO6HrydtdYktjewae/1ojzzmW9+YU01eY/ks5/8f9VZFr6/mtiMJ0vuE6DuqG9mwTaz9Zzgfr
szHSutK9Jt57icMMNTU++8pvm9oc/BasZyfrnF2Lo4EO5F2D6B2eKnmuHGpJ6oz9oiNGd7ePfT+j
fSvbagaVgLiW35xunXZ3kb/XtqOIFiPVtuSupTcF7W+K8Du4W3pmIHV/38rSovtiB6d1YCOpVamt
ZXWIp/E7q/3a0L/+s9rUtksdh/X6VE5RaWgkb53D6xvYbrItPFpKghzy6iyYL0vCvMia19bPdah5
NTpaQykJjoj93AmXsDainMF5pOh3cmsp7u0C/55ja6V6ujNYiv2VwNoR7q5Cj3aVLu+9x2opo85J
19Aaw/M6ajb27RaEmZbOuf1ZUXfPjn/Weq2UdSgF7WytpZU+bWEpdOs83JdoCaYE0gvPn3qp+e33
coq2Hmy86NWs6J7RG5FG8Z5bsrYD21/YOvNos6vR0XXHGjaOLm+Mr+sSwZajFmuz6Fq7n6csTTGX
YaPJpVHyaW8kFD33YXvFqP7e0mZ1Wnupl/kkNKhLdR3Trw+13Xkz0g2GJve918FGTvafv2e967u6
mr73voGrx1VW6smziuoMTzcJ3RxyMEWPS7y+TvmmtDGV1g6J2g/syorukNdWZ8c6/pEY06KjH13z
Clp/ageHbUA7nxZto4XLyDnxfLnKlt2r0d4qgp8iLvVMn62s9ccW+kZSfR3slziE5Sg/90YjwZCr
hH6WFa0jK40qtxuonqz8umXwNF/cbEGYD7o7bb3DYTcPj4Pt12z0THidmRHSOvfPNtvxoX+HtDtW
sKE3CM86UptWV3g25mqHGisj++NhODe2veeleWXr3NI7E3bmHIqa/Q7WhpUcnS3R1u8fx/GMvPve
u9UG8ZLeQLqHb70pP7e5LaJT3b0V/jyj+p3gaveBta2wpnXf9lZNZHtPt9e1NeZJCNe9zsboSpzu
f/esK3dcU0HuipWrOf2jaPvEXw6/BeXuAfX3Ce442sa1da7tIKo/4dGfp69cq0NDsM7VmW397siG
tDTM8c1NNJA7AupYr14v/hpe21ZwTUs5VJ52WysyvH5jxxs6c8TlDPrUk1ryVuN7+++Dc/u600Dn
CTw5sxxc4+OnN//cYGrW9qV2pt9ywc7JhvkftM911VJLphpkMuJOJc9q1DQHm5kLf88UrBsu9Sqh
yvZYLcILXg+3el33PKnujGtf+7cA2tdHPOqdk+Yfz8HP8Um1pb+F7Lyfu8PDzg9rX2D7P/u/P6Rr
ZXizRkqLatSydC7DfLTa9metD69VV5jZgxaH0igb3vbe3jisQfy5Tt0xanAPjM6jLKBGQ7VtN1Gj
iSDHosYEwVqz9s5KsjPT/j6JubRCpMTOYXS0Vbc35mBubCDvjTP/eH699LHWjlPtyb2U1Zp+ba57
FLTe69Mp2hXA+Nlid352Bo2k0TSGWKfWko7hdLZKS6Z9k7cH2tsvalu5v66DXPR6B+VZphxlneXK
NPNkmlNalybtLb1yt8cxzTk8X897uTaJy9uDWis8C+9Es6MG29dY6rV9l5Nt296TKea7P8FVK1vT
jRnz39adfevMT4nfNl9nJGodeXb5loxz0pS1TBVOmexoLKpEfskNpmh7Cl6fXC0c9X/nxX2rzl13
Cc6rNZkaqTf1YfvBesnVbztFz0yG39WzdJST2xd4FDST2zcHrW4vvY5pDOWXny9Jn3ToeNGff+YS
48mEf93Czhmoi9fI5pKtYa89ufP93tt71hLR74BZHtUaveKn1/vuhN1LqikGabWzHO4IiEumshic
5YmybZslTfsNLGv3R3PK1orO2K8xGmITNRlJsXPC/nVC/7qk/90Ct3zR+0FsfX64xueeTgjav1ay
ojWC36oJU+3OonijXSttaySmN2azKbst0mvr/vW2f8U5hKjxL7fTzjmDA50ziK/l8JxB9DqNtfPb
G+Xvf16B09Sx2Wqytj3PBgatRvdLY7Znc1eSNUV3BO6u9AXHyu4Y2fWPslZryfuiotfL+Xtkvx62
2txtZZ7t3fH576B+8/dkrCl4BVU1UMfyCI4Q1pCro2wpG01P4o6+dF+yrQNvXzD3Apn00q5M2nFZ
S7oEdnzjjeTd8d/B2R7ttQU7XvVyyKQs0SVRWjMZibtlczWlF+/Ql9NvrXu9jtVi3sjba2OuVRM3
kvaPv1vI64PiVu8zWeHXP91fOZOCOzD1rXDdF+PNJVnt0CJheR6g3qHQW6XmNrCC9O165W2zqSdX
DpSXUXMXdl3KWofee+LhfePrTathjnh788K7kexO0jVpSnSPJodjnVyP9uPtd7E5tp+COxPhvS9v
tamGj94dys8my54F7n2j9sDakkynU+jAvn5pR0haEuuylqflLacbtYOj/f43aJW0N4tl8/DbksF9
mar1amkDqR7WdTZ/iWybiur1/bLnWcd+KzLqO7R+uuqk79G3yfy9gmphy3mVSbsbXXkcnnvz76Sb
L6Oi9mvNaxfMNS5HcFdJMFWrOZTLm8i+C+Xf0caprzQjZm9V0tMhnl5a6XDalr7Rl7Lut4jenXQg
ZWPNUyV17b0pHXzzqYXC7d3m5b5rFf3eh7c2omXwRl9uqvv7PkyDb7Tl7kMOt9Y4KffGEZ5Etbe/
y9Mgqimi3iRprwRRku5p7k0OdVay474Y2+KMNu0+t/hyB/d/hNcWdEfV+nYpLaNoW9HbS+ft2nK/
ixWV2mCH+9E7voM0VUhOwffcwjOgwZbo2szBkX54fqHMyGFwFtHOFAZzO/DvKmi9zZVcuE43Rabr
1eYaM3sTHP2sJ7VTWyLKUSE2Qj3ZXdNezxuWJLcV1WYYx28ZudaG2nE6n9NCbru02svz0flwO47b
X18c34qjegS1MRqkFuzskl/a3Gf+luTNGLj9rY6fVpPXivRLelEz1UGuuDZXWUAilSr1Yw2s+02n
SF66r8SuwMa9I2h3evG8nKeNLP3efF4t+XdbR2mMsCRGr9B0RPIryM5lsMZrIbvjq8Vwz1oeQT26
/++2WNnS3niL5MBavIncr7u1v5/fq9Xwbn6P79Ep+LWKckA11Po05xuccq8wIb2ZlnWSrvaIq8n/
npWOxJnzWm9u3Wv+B7abkEs0j6L2QnJ7ODctkQ3pt1ytRvb6qqjaieaNO7quJf1iXqPZC2P7P8uB
DaIdomZ52nvH0n0zzW8PehZT9FeMPN3q9lWunhhq1rQ9rga1p37RJ1h3PGpYiF5xKK4ldKqkxyHs
bt/5ZL82rVLc4KPhVKR7Ao1FmcvTlBTKfL2ury8yGkZr3t3XHv1exwKZsWJu8XwX9z0sAyeYUaZH
54wDpHMG0tG3qsuR0mlSQ/YrlAvJf65JY4COFqd+pplWvdZp07YeZpM3szTZSFHwm9Cclvs2h/9L
F5qTlns1SjpdaFxnZNvuOj7VUO6XO+WG1eTMr4nUIHGXS1vjFtMkraZW0nZ3tgwVvckyZFviUBqO
vwo841meSVSYlipt6W47dse5W8SlGpX5MMeXa6HIYLVI/EgaQ6NRH/abFONNGdxd0jPTLdSty5qA
3guX9QJqNnKwjtS+bZE64zMT6uW+PrKE2hdXkZ1Xm0L+t6xqyK71Nafbsa39oBRtIXdGJGhhDyXW
bDqGGkEnyl+4HCxN3jts3DcPNT1Wi1DglUvl2S1hsHSZl8ork7fuprVuOeR/E6WQklTSbo+vo2s7
f+PtOPBGlfXkrSVzvBVCk85z+d/1Yj0THrm5YyE3ddWoLI/nmVCcZoXQbN/c0rGd7RPDJ8o0SCnq
heu2/W6h8NsA7ppO+Pvxce91cznct0Tiv2bFXM5034FnA+ia5Upy1+gz65d1hD0dfBoKGR0BeRoh
Y6f37o9tybXgrX5zsElKVkasvZU72uIWSGnXm/WCKG09m3SHuLXURkprGE5d8NeTuLSTUa5p+K8X
ytRb/Avp0J4m1t5MRqbzqofyz9JVHRrh8lMrORpSR8n8v33/XMPwHqlF5qtAbOPb2fEWEy/qfSpN
JdzXD2v37bAwnZrjlEga5pE3VtB8+Vm10wZVS/j7Yn3DM1hKt/TBEsfzcBj87UyYvyRB7h4ait+f
v87ff8av2jljtfXjRPuA1CeJ8oHx/0U0Ebjgv73zV3cCt/4/ojs/TTTkM0RbgezPEs0HXnMT9h1Y
+df3yfG/mQXzOa7sgAO/XD5EMyu/lLpW907QKUupR0MrJajntSSHbU4ZRNN2bqUP+CcnfWaBLOo6
Lk1a4c5U1u7uK0vuH0DUg+ttG9BrO9FDwMPA7s8T7QEaLiMafYV3xu7ZXyWaBT68caWet/uGm1W8
4++H1LHDdXSEgvf5N3WpIwsj3j6mOv3kMC9QbjBWxC9Bd7XuP1T8z8iCX2672XOTtwJ3A/nXEE0C
WtGU9gFDrtczlecCO2+EjACpmyAXwKXA88CMmyEXwD1udne5Dl+lZfgkQ8etruMW13FD7BOf45rM
HL7U/L8csI352SeRM0v/I64uoCigJ0wd+GTiA/31sHU70tRp9c1efdYBC+8gOg1YB1wG7L2bqNv3
EPYnREuByoeJqoCBT0BPAOOA2cBc4AJg75OQl6eInnma6CVg6XNIC0jtIToKeO2PRK8Dy/6E/IBe
fybqA+wEHgIm7kV6wL3AfUDqBaICoBtwBNAPOAooAUqBMmA7kP0i/IDTgAbgGeA14B+voZt6rfW1
/wP479nXWn/Jd/b9x2v/oIfoR/L3/bt23PX9b17/zW988/t0FV1Bl9Nl78uJ3P7zxvumzwnnU8fx
eBXykbyKvVjmUW/1CQTMM3H1NPOiwLnlNMHW89LbUD/fIXoFmI16ngvUAPPvUBlYApwBLAXOBpYB
dUADsBxoAs4FVgKrgbVGZtYDG4HNjvz4TrnOUIX7HPFnZnc6AqwK/aCXHC3Vj+vjRdOmm34Inx+h
nQFv/JjoiQe1nY81bf3KX8I2ALbuguA9TnQj8Caw/Vdoa0+oDhgElAJlwBCgHKgAhgMjn8iY7L8d
rOP9yife8aLreL/qXn5d0vVbtG1jsnjbJe/YGu+TCNT/kVwno59Q3T0emAhMAiqBKmAqUA3MAGY9
4en2GmA+sBA4DVgCnAEsBc4Glj3h6f/ORnkQlfke/Jz672v756ef9vroq54N99NrgQeBnUD3P3r9
9tTniS4BLn0+YP/dHevwBftOrOM21+FLwPfEZ/91xPF11xFPtc9hf0WTAsO+wp352US7klfnrE2l
R19FaQuxt7S/f50xAfXgersK2A3sAUr/D3oduAnI/pPaZb2MPTZ+r9pj1s76PPBF4DLgcuAK4Erg
KuBq4BrgWuB64EbgJuAdN/f30PFWZg5fHB8rfU9eiX0S7/hLrOMF13Foi82/xFiVPMhaf+raD/8l
PfHMocT4YoQ5WkcoR3Kd3ALcCuwAbgfuAO4E7gbuAe4F7gPuBx4AHgR2Ag8BDwOPAI8Cu4DHgSeA
p4CngWeAZ4HngN3B+vdpu448iTcRX83M0REef/Adw8uxDveXNVvUEuWOMEqKJYASc9PSAdeRXCd7
gOeBPwF7gReBl4BXgFZgH/Aa8DrwBvAm8DbwLsBmTvJFb7w1ECgHKoBxwHhgKlANLHwx0Po6Yvsf
WsfrsQ6f+daRBOKDvYdP9Nd1DlewV+mFO7MTNYdLizd1b2XjyIXOGHk58DFgK7ATeAh4+kVv7Pw6
cBQ0WQkwBCgHxgLjgGpgBvAxYCtwCXApcD1wI7ALeBx4AnjqLx1rawf95KBb+wfy5JD3EE77709b
L3cfbWV0+nxYfEZIW3waeAZ4FngO2A3sAZ4H/gTsBV4EXgJeAVqBfcBrwOvAG8CbwNvAuwC9hD4B
yAZygRSQDxQA3V56T6X7g3f4dPNrscHeL0f6h34/aAkA/czTrWQkYq4Nn/ZJ/zp9PsQ+lOFvYwC3
RODbHDCbaM6JurbEtsXchgQ9fWWC+uUlqbowSUMQZCxwAfBJ4CdAHiS2KKFxr+1CNKkXbJYjYd6U
QH8Nw5hlOHTNOKIvj8c4BngJ+NYEop9N0HVuXuvk9S6e8+Z5z5FmforHwDeZ8QnbQ6wTWU9VFyZo
/tEJerM8QbMmJGjvjASNBJ17GxN06foEjd2SoHsuSNA+oO+F8AdKPpqgC2/As3vg/+MENTyB+PsS
tPC1BD2YTFIJyvdAfpLeAD7TNUmvFCSptFDLfDyKNhSoAFAcaGfQCIwGxgAnAGAZoViEItFEYBOw
GdgCfAS4EEBR6WPAx0kr7hPARcA24L8Anua9n2Sql3pQE+VDFZxJRZQk/ZURVb7aluQ75cqOU/0u
+kq4OUxKFidWz+iSfQYlKl+lfXQGfLvQDNJzHeweOaZ/KNLOHZTIY3N0N+qu57W9oH1aaVBDLiyQ
UrlWlurAdFcyl/J0saMctUVJSXt+ZNrMl2NBDdLOL010rc6BZit5l9NvRfpNSDMhaV6dQzbNEqLZ
lCVpzo5McxSxQZSlaSY1zbEJN80keKVLN1NmHYH42ZLajMjURktq2ZpaVjC1Vqos5cVYJDVpSGIW
5VQmUJpZkSlx3fMcUo+GpgSP4zcjbjb1SVMyiObNyqJTAV71mUW57aQ1VtLK9aWVg7SUjnBaee2k
xfLYB9zNGpTVo6GvFK0BSU5EkrlFnOK8WdlIKluSompKSVrVkWmNk7RSUWnlFZCb0BnUpXIA0omW
OW4fg+BvJjjt7NzuhLI8VbgzDzIBUYPkjzFl7pVOfyJNrtzX9g1pWX1oKjXKvnx7BqDuU681O1DX
yp7MarOjy/1NpSqUdB/uTGEV8duPvEuQ9wFvlrA9UQeBkqIRF/h4v5renQd+JVZLjVWR900J3uW9
htyzSVhXducURwyibttaqWjbkpweDc9KT89trSCRKjgWbS1VUCrX4+Q6dCql8qjy4rfamlIYAdJM
UN0j0YDUutEc8r/HZvnM+9KISqkYeYzLLt720Fvako912vNxckXq3bvLcuS8WUmUKimlGktDKq+h
AQmWw2LZs9pAur+Wcwm/hcCjlRlDEsjxCJGeUpQpB5ycJ7vtWGqS4GYK+fSR9Evp8IhwJ0i4Xr5w
fSPCjZVwvX3hDosIN0bC9fGF6xMRbrSEO8wJN4R6S7ghvnCjJFxf6krjuUFrUCqnXhK23Bd2pIQ9
HHUE+XWCV1NP077c0KyD+9IRELKmBOuwwp1dKWtXcmHuZccgmWJOY4JpBulcy1BDtyWggkHPbLJv
Xs0l7zsF3C+o9llIJZLrQvHj1qB1yWFKYF522zYRkjKRrKiXQSKzVTXvLUl6OqyHT/ar6GhJtUpS
9cteL9bRg5K9rt2VLNyZouTu7vcPSCStpLlplKIcf0hwGj3SlLUva93S9HSnaTO47+svdLBVXBiR
hteiC+holHN7bo+Gh4gc3dzdR1MpHRkhJSdKjZY4UjKSBoP24uRIqYOadCv010FX1bGaPE1SfYE7
0+r22rq3u4EajabKpYGgdVfSr2/GmfjcpvKoxbwFwjmNEPqOcUqV8sUcKTGrkiqZdcLJfGhh5kfx
trX/7GHiuXHGS5z5SbZlUvI2hKVPZTYXvTvTGBVXS1qXnBQRd6TkXWq00+XvRsWvlvjrktXCwzrR
7/qeW4l5t2u9yMxxkN5dSaaCU+LOyM+x+YZjbKFkkX6jgK2nMp5eyRmU6LbtDtAxNU80JImGJNGQ
JBqSomg7w6TJvVu2SXMt/i+nwb5U70A7eojiUu5JEY2Kzpa0r0meLeVe7rRV71vg3HsOCbXaVmm1
mltZLO3jDe3jJf0mp9W66bOdW0SBqOgrNe5UaUv+uMyFdaZWuoATsqDxRl5kKpPQvh5PcircvnhP
/kqRx+6wRME/LQpbFdDKxio8ZUY/XxdFl4GWV2lP8jKhZbaRCLft8bsDRPxeZX5p167VbXlF20qz
WEh4UnXSTijDBHrUxFYeZLOdxb8KOtifyv0+kfsc6f/rTOkKMF5gU4ctuoZ0O628OJ/C7SaZxfFz
nfh1ksJwJwWRn2B0k3+PUPxmiT/CF39MRPyJJv7EQHyWihRarsaPo360xB6ZNVpCryB7FrN+y49T
HAWZvTrH30abVDdlNRHL7GTSr4CwbmyWuN6bF7aeiQag34YtVbTtkhzbADaTdJxf6f3n/j8dwHVR
ROgzfaUbT7Mhe/OzWPpZEvUNEW6LYzi14m1NCc/eC2iSSpqCuHVZlcSSGrYYS3xajmt/rEzhco9R
QryNjOvmscQ6qZsu8vbpikC/2RtWEOjoee39Wb1gD0sXvLIkCVrZ6tf42nvkEb+HtNa8j9Eoccdp
XLajN1M6bp7qmV48RkWbwZhxtJTei9kNvVupoze8cvP4kVv9+clrsqZK7VQ5mtjWhltubXXdwOmi
bdU5xdueepsrhu3tgZVWd+TJ2xbe11HZ+plgLGPV5MPf4VhcjK52Y53sw5sorf4Bkc4Cmh6QL6+n
70GsG9emircte1MYMS6b2Hrm8j+exRQWkn4hkN/YGC/agr/1aOVhEJ2kqzO8K7nntT1AyvHgaDee
1TAbB4itHLYFvHFPl2zm1zLJZU/WslAu9YFSc43KCOM5yWVwdC6udaI5aB+xL+tskaPJZE9k2Uj6
RQG2/U82PZGO66VXGCB90CCp6QHSBw3qSenNhk4rMf1bNvdvKbHBNkpNW7qPoUqTejtJU3TaI2kE
j2Cy1WqyEhS0mrhUMjrsxRwYS1MRZ2D2WOGoF8e+qcNyvIHUoqlCvTdJA+A5mHfnFWOMx629KDAK
XSxfnfXnOSW95YZE0gZQVfZEqQF/3JGRsac6sctNzuXCQa0h+zWlzRJ6moaWvSRs1T2WrMseF5HX
CFBlW5bt03Jg5YLzxDNP786rzV4n3CyC/FttPQ/9seWOxmapSKLFEP7n2r0oez36Pf7+Q5ORSu3H
3f54BGjJkkoWWo8nGbn2B4d3JIq31bzbo2FXMkEyM5SXaEokUnm52jNU6SzFtBmtbbbyZ9HYym9k
fz57luTq1aGrT9Qy5PetJL8qHXF3l9GvO3KYSsMhD9dkTw3IkJsW0ZFktlBtTm+xM3T2S/K+nRoa
X1mcfXt2TUCq3HpVinrRKWT3hx+GxFJ5TFgUXczZB7LVPvJqIzgy78JzXGznTPRKx608B6nkoBSc
yuPZVSI7dvxRRfoNMqZmTroXb1U1X3N4foGkY02kkXQqOLTHtLKovmqUyNFc6aFUd90jvcs+3DmO
SzG/t2otwwtAT9YgymGZyFeralx2j4b7hJwlSZ1cgHXVxh2f7I8yphV+J9PB/Q6jCWxyMLuKHGuw
S4qWgPZvZF+TvQS5FcdKl3e6FGEkWKPSUZTgLqfntTWg/2oryTzLmS2j1SGUn54LyEv3dJtJR0D5
dCrk4SEq3jaujRCma0xYHfHM59FWwoYtiAk7SsIu4PmhpA1bGBN2tIRdiLAlWTZst5iwYyTsIoTd
mw5bFBN2rIQ9jVt6tg3bPSbsCRJ2McJuzrFhi2PCjpOwSxC2MteG7RET9kQJe7q0Nw1bQQO478hh
K73QF9avM8mMzdhe+hzdnqNj0NqQFi6iM9P6LdW1+gyy1oaaa3S3WBv7ZFthF+I39OvoHHCbv2Qx
G22C6GLiXYKJaTu3spR/kLsEu9reVihfakZqS4k1UXD+1dMlh9NZpEaCmF7cknlCsue1l3IBKi9+
u40tHHfwxbOQOka4XaywPLSjZvK++cL5nU1egkU+vcSxT6P5qMV9OaeR2pPt29HadgrAd2sfjsvu
aXRmHx9VVVTDkpRbRXE6j1PKoWWcErRoMA1+E6OGFrKE5XKfkO+bz/Vsy6PAvW7bnm0r2vYZqIti
3je6K1mTt71L925SEwXplDnFMlrEc6m5vE7DM+FbSN87V+v7PGLpwCilakhyJA1D3iNzmcpsZ6RT
AApEU32B+1+2zfNAb55U9FgdOeWOJdbi9nwB7lUaDL+sHe2PN5EWIK/5uRMzrINRQmej2FaE9nsi
+vK6XNa28X0565vDYIfYnpNIqq+yK3dbFF2HOjuxLlfHZ3wyxEqxeAogt155jGXZx+0DsumlPKLW
AqI9pUTPncAtKsm7aPBjXcDblnkXnm1k3F55nSxLcpL3w6SdIhHuuFBXLAEsSZw7ydvUXL9Fwl2e
F2fOcTm4R+bRF4+Ktdn3JW5ZREcQWyG6gN+fWHK43yHwhsevRAOJbWkeB/A6GVvtRMeRrO3RYCJZ
X+X1RrYi3TXH4eStO3LN2LVH1tqsjVkJ8eoZz3ktAZYBPLbeAHyF9J05fqeP12t/DjwG/Ib0FUze
+9cFzDkKOBooAQYAA4FjADY7jwVKgeOAMmAwMAQ4HigHhgIVwDBgODACGAmMAkYDYwBeZTsBGAec
CIwHJgATgZOAScDJAMSUJgNVwBRgKjANqAamAzOAmcAs4BRgdkJrn22VhKANP3J+yZAvh8sK+XK4
7JAvh8sJ+XK43JAvh8sL+XK4VMiXw3UJ+XK4/JAvh+sa8uVwBSFfDlcY8uVw3UK+HK4o5Mvhuod8
OVxxyJfD9Qj5crieIV8O1yvky+F6h3w5XJ+QL4c7LOTL4fqGfDnc4SFfDndEyJfDHRny5XD9Qr4c
rn/Il8MdFfLlcEeHfDlcSciXww0I+XK4gSFfDndMyJfDDQr5crhjQ74crjTky+GOC/lyuLKQL4cb
HPLlcENCvhzu+JAvhysP+dr9Fn5fDlcR8uVww0K+HG54yNfu3fD7criRIV8ONyrky+FGh3w53JiQ
L4cbG/K1+0X8vgn7j/heWRDl+9VI369F+l4V6XtFpO+PIn3vi/T9QaTvvZG+90T6fi/S9zuRvrdH
+t4W6fvtSN9bI31vjvS9yfhynY2jYA3NJN3j4/fl/RfjQ76nkO4D8vty7zwx5DsHOCnky+uak0K+
80jH035ftlsrQ76nApNDvmwdVIV8FwBTQr68cjw15LsImBbyZbu+OuS7GJge8mXrZEbI93RSHvt9
2YqbFfI9k5THfl8e98wO+Z5FymO/L8+izg35nkPKY7/vMlIe+31rSXns9+UVm/kh33pSHvt92cZd
GPLl0dSikO9yUh77fXnUuzjky1bfkpAvrwWdHvI9l5THfl8eoZwZ8l1JymO/r/3f77uKlPN+3zWk
nPf78irqOSHf80k57/flmbTakC/Pc9aFfHkcVR/yZXu4IeTLOyIbKerHOqJzzPCfOWbAsFN/Kfkn
JfssUzJ+TGXLNUeuMpeTypOrLM+kusg1X65d5SqdR0q+v5WSOYFUkVy7y7VYrj3k2lOussiR6i3X
PnKVyaNUX7keLtcj5HqkXGVDeKq/XI+S69FyLZHrALkOlOsxch0k12PlWirX4+RaJtfBch0i1+Pl
Wi7XoXKVFfHUMLkOl+sIuY6U6yi5jpbrGLmOlesJch0n1xPlOl6uE+Q6Ua4nyXWSXE+Wa6VcJ8u1
Sq5T5DpVrtPkKhNsqelynSHXmXKdJddT5DpbrnPkKnvlU/PkWiPXU+U6X64L5LpQrovkeppcF8t1
iVxPl+sZcj1TrkvlepZcz5brOXJdJtdaudbJtV6uDXIVnZJaLtcVcm2Sa7Ncz5XreXJdKddVcl0t
1zVyXSvX8+W6Tq4tcl0v1w1y3ShXT5uxNLMs64yIxf61Npl44Z9NMcd6mBbj77c4P4Qo4GUATjeH
Jqb/t6lYe5251GDifQH4InAPAnyf2yya4HTgHDTCZcDHkehW4FrgOuAraJBfQ0P8NZBEU5wKnAds
Ax4BStEwjwNGommOAl5D43wWjfJ3RjGfD/wZmITGeTIwHbgIuAr4KRrpH4B70Ey/D/waDfVp4AXg
WDTUUmAn8CzATXY0sBxYAbQAa9Fo70aT/R6wF3gBeBH4C/AS8ArwV6AVeBXYB/wNeA34O/A68A/g
DeCfwJvAW8DbwDvAu0AhlMFYKIETgJnARjT/KjT+bwD3ofmXo/EvBc4C1gLb0dxvB5Jo8M8AfdDk
TwYuAR4HfgU8ATwJPAX8Gnga+A3wDPBb4Fngd8Dvgd3AH4A9wB+B54H/A/4E/BnYC7wAvAj8BXgJ
eBl4Bfgr0Aq8CuwD2oA7oXx2AhVQPMOAcUAxFE8r8BawE4rnMeBNYBDUz7HALOBe4AfA80AeFBIr
pWJgJDAKWARcBnwZeBDYB8yGyroO+D2wG1gE5XUa8D/ApcCngc8AnwW2A58DPg98Afgi8CXgMuDL
wOXAV4ArgK8CVwJfA64Cvg5cDXwDuAb4X+Ba4DrgeuAG4Ebgm8BNwM3ALcC3gFuBbwM7gNuA24Hv
AHcA3wXuBO4C7ga+B9wDfB+4F/gBcB/wQ+B+4EfAA8CPgQeBx4FfAU8DvwGeA34PPA/8H/AS8DLw
GvB3IIE2nQSOBUqBCmAYMBE4CTgVmA8sBpYAZwFnA43AcuATwEXAfwMXA18CLgNuAm4GbgG+BdwK
fBvYAdwG3A58B7gD+C5wJ3AXcDfwPeAe4PvAvcAPgPuAHwL3Az8CHgB+DDwI/ATYCfwUeAj4GfAw
8HPgEeAXwKPAL4FdwGPA48CvgCeAJ4GngF8DTwO/AZ4Bfgs8C/weyPTtnf4Z+IRiLQv5yAh1P7H+
5XyWZhBm/z69B0T5JEI+yZBPVsgnO+STE/LJ9fk4v/fBJ8gxpicv5JMK+XQJpJP+pX32XxecTn4G
YbruJ0xHfYoyCDMrgzBBnz4h+ekTkp8+IfmJyqsjuWfmk0lenT7vj0/6d1Cx+gyYFdA/7JMd8skJ
+eSGfPwaoOP0pEI+XUI++SGfriGfgpBPYcinm8+nU8Y6fQ61T8esi6getiDk45fnzPqmTMIcKp9J
GYT5d/O5olJnQZ0wGfjkU/DH6djPKXix0j/x4TABOzwUJpxyx0s6NoMw/xk+czPwGdEhn/TvQ+gz
u0M+6d9/mM+cDMJ0+nT6dPp0+rg+4T4l3DeFY3X6fPh8KMPfRurYV5bGvUShLytxmPfja0qc9/H0
/nzhiMv0Agz2l5HJDiT2JBJ7boLuXOCVZl5bRtFkR1RbG4/D8miR7JnnbztswpXfTdT9+XyWH+88
P4xmIMx0XKfRAuLztuZRNS2kxTQZYaeJz+nEJ51Pg6WwgLrJmXEbZOc8f4dB342ok9P+1lEWwvDZ
X0nkcJ6kfSDn2CXAuTx564TfKuW37M6jHDzhHfrnEp/xORmh9NRFPQuxSVJiOopgsW2QLzvo/vtp
pOf8rkEOfF4hrxzzmjCvBbMM9RzwxbYvbcUos3WZTFXmtvLafrK7zmp/Ltvuelau8//2zawfA7+k
RGv3JO+byWsdxM9yR35q2+Cv7di2ceyatrsLblz61zZqMkOiPRfJLgZIhIbNyu7+/d+cd8ni60p/
1OXF3f+Y87OvtNGTZ2rYWSsTgbAX3/bm787b3fzw9EFDLvvljlW3t9EFZmh89EPBsBsbxp59a938
ZZte/p97Xn/sf8a1UY2ZmP3KDTmBsFlrH63+XM0dn039cebXhy7uv6GN9pkh2ld+HUy33w9Pv+5b
ve/btviTJ13/yTf6/6GNLjPTu/9zhs7KzTdhc3K+ev6z/ztg94vfOqLppAl9rnjtW+CDmbz6nz3B
dPv814Sav31hUd2Z/S697s9fv+uONsrrq2H/1qphPf4+eM+5F71c8Zcv0x//kTzqk3ufbaOthr+7
n9WyJU3Y8M+3RC+/dSZsXt7zs/5n1tSFPyo9ftKrV8/eWvWXNtnrxb/tn8wKhF12zR9Xv3PZ5kf6
PnXv8tSXa52w/zRhK+moV7m2dcW+Tdbu/0HUPVFEyVbefFFCqVbdyg5mpXiaI4vXaXHPbtUtwl1a
u1P4l6T8Vt08YxZZOMG9fXmXlCbIe1UeKOAM+r5qM0iSZrCx7wFkkK0ZcHje5VGVUP/H2TOfdx50
FW5MTXA7+XiCU/xhgun4eWLS74l+keBc2xJ9ZX9W99bsdA7F8v+RpDTd3kXzuCjh0dQKJlZ2RRlQ
mI8f4dF0C8rFyR6DvHkH0yd/zPuefsihUe4y8OT6Es2D74sQetExRF9EO3l8kN7Z//Eeeuc9Bfz8
uKP1Od/Zf/lAvd89HbI6gOi2Gfrc3vdgoPTnPKLV84l+C2WwDOz5OMhrW6Tp8f3Xp+p9D8Lkmnsh
wr0D/x/N17VnTofvnO47J+qdt/k0It9huH8PdBwD7c4HmXE4pq9wnN453GVHarjSnhquvIeG43Jy
OL5zuCT4sGe8xxf9aY0knBpJkNbEZ4j32inHebd0Mp/3tXZt5f1DW4l7sEvEH9wny/0c8D5FR5sd
KnxnrkxepNyZvEjztM+Rj9TzblyuZq2AktR09yjRBl1oZObEEFVXRlA1DlRdecioYuljqrYWelQN
9FE1TqR3SdLjmZXeq9FCdvXSNHYf7knvNaAuy0ovHSpK1xYrpcP7epRG1eQVETybCJ5dcUh4xmVm
CmyZLSWy7y3Ns4khqr4WQdV4UPW1Q0aVrYmtfTyqBvioGh+i6qoIqiaAqqsOGVVMDVPl1tpQH1UT
hCp+o9xq3usMVZ8EVWwdhjXvrgTX/GNyVc37yR/PTVPbhQpA7cumx/6SoWqxWU47a57eW07V+88X
6n1Ujd4vNwrcxreluT9XdfT2Hnq3pWFwCb5IXgmuRwkuyuedxl1bl1BUCR5NsHVlaQ9y2v0tW+i/
+39KG9PE7zXyfe1+aLvBcLejtE01/LT3p03t2/vUgBRY2vjD9Xxvj7YbD5I295cJ3yxNfI/imyuV
3zwkUtnLSOF2w6Vtxn2EkcrZRip3GarfMv5PGam08d0SiFQOipbKK4j1sZbgJlMCtmh4b+tW4nco
LhF/LUFbgu2tMF9tG/qSafncZuzd+rtUsV3DLf7+Ir+W1HUx2/Jnhii8OYLCGaDw5v1SeIWh4ApD
4U5D4U5D4RUBCnf1VwrZ8nIpzPNROEP6vrJuyssLHMutEtphF2tb3p94lNf3PeBYbiPFcitNW26D
xHI7+Qilg+9PwSb8VD+ilYj1vf56Z/+sIr1X9dHnv+mrz/nO/kOP1PsoWFP/wP3NE/W5vR81iegM
NJQfTAYF0MKnTMHYGe7LpkKvwVJaDmW/EPdLZhE9ivuVs9Wf700T9b5noj5nN4cvPUXjX4Znn0Z6
z8HNLwfxc86P75z/U1P0vnua0sd3Lg8/5/IdXan316q1/E9We/zQn1psqn7j+/lbI/qu6UYyLmbz
46D6ruFFCm5fux2LTVfirHxMD1H17Qiqqg8pVSx196O166cElKrRPqqqRWrnJz0NsD+LbYex2CzV
ms6hpJpfamFe3h9hvV1MHv9uM/wbBUoqSfk37T202/z1OS1Ez+0R9Ex9Dy02Pz1TQ/R8J4KeKe+h
reanZ4rQcz95veIdhp4vgJ5tdCC9oitX743F1h1lKjpS2y/f3TLZlmHL8V1jsXHvzu9rZGJ5hFuG
+8vE/mDKeOQlGmY/FN7p2B8dp/BArTdL4dWH+ceIURTedUgodH+Z8NBSxvcoHt5PHoV3m1o+FNJ6
qC05S//24/zSyiPooJ30vQg7qSrCQgpz90AtObZzWGdzb+NayGMkjNULVSEK74mgcHJGFB6oJTcc
feH2I9USq+wfR+HkA+4Tv99un0h0cPq2+xHGxhi0/z7x3gidX/ke9onyxl6ac5Uhen4QQc/J72Gf
6Kfn5BA990XQM+k97BP99EwK6cEf7lcP3p/gufJHE7x/Nm4se46hxt6vMVTa+zkBancZPbjjaL+m
Hk5hPXj/fnttl8L2R7Tub7bpkU8yuu/T5t59of9un/t/Wg5LP9/d9mzL4WqZH0VomZN8JYgbL1qt
vd3Iwi6jZay23h7gLr9kzdRcfYyO96Jl4SShsIo82RTGduP3+btKNKXt58xQQ1t2FvP45Cw9yM3T
AjxLxm8A8lt0/KYkr0d8i3Stov8gva+XXHm14J1329p47Dq0BPY/9ModMpLl0ejX3mpr+yWe/g5x
/lrMT/gnq8qk3w6oAw6DjB/RVWcEef52CdrhUmAYiB4FbAW2AduBLwI3ADcDfwf+CXRFvkXAG8Db
QM0A2G8D9N3CYcAzwO+B75TCTgB+i17u90CPwUR9gHOB84GJqKjKCn33jt+3s+/YtQJ/G6vvUfH7
U3nQx3nU7xCB/5Lp//k3zPBlIDh2DNAF0tgNuP5Y8A64DxW/BxgNOhcAlwMPjPbo/iNw9FiPfj/d
R8Qgz9yT8l9bWy+umQNcrx6IHms8LZVvHp9A59BGWkPNtBY+ehLAefLttaHm+WhaRSvgO9TcK6hB
1ss7c+3MlXMdZXJVdw3+02+vr5FvPtfLF6Ub5cvaJcTf2N4ouxx410NJhnTxdyYbOunqpOs9pauN
Po4efeNJc09pKwr+JWgrnrV+edCiqGefwLNUl/zPRz27CM/u/Pa2W6KefZLTnNbtpqhnF+PZs+c+
8rvJFH72//Bs9vG5J0fFQ1fe1n3nLbe1FfF3K7Od2ETo4vUXEe9U8OWyT2xf0ZZ+ycT+ErS2+mtU
sPyNE6Oe/Xh6P9h+XVJRzy7beFoih7pkRz2rWPpEojDm2X15TckieRamc0fDRckuMfE2D7ouGUfL
T2YeltU1Jt64wnlZz337jUuinhWPuovjRab5z/NezYrLb+iaz2Xv+8IrQ6PKcNL6y7Pj4s1dmsyJ
K/ve7hfmrH5i0KyoZ4npC3Lj6Lx95G9zRz/53JKoZ78qX5+XiMlvdd2n8+LSrFw8NfXcrXe8HPXs
d3POTMXFO/eEV1JxZa9Yuy4/+9yzH4p6Vl34i/xETP39V/nT+et/XvOlqGd9u+wsjCvfl4qWFcXR
+eTMm4vi4t12fN/ucfF29B/Y/f6i0z4SjMWb2b70sV9217KH01wxYXRxXH6zh02IffbpcZfHPltR
s6d43eHdL4h6Nqj3l3oUx/DzJ2ve6HHUjuELIuVlWt+ecfVXfdYpPePa9B2nre159akX9I16tvq8
B3vG1e2VU3b1jGu3F1aU9orj55qPjO1dFPPslZ6f6x0X77RpL/WOq9utCyr7XFI/pCJS5ueu6TPo
2WvOjHr2j5bL+8SV4TOrP3ZY2dMvnT0tpOeJrlv9o8Pm/vdz/y8q3i8rh/St7vd6abgMROetfqpv
XBm+NPSffdfdPOi7kXQO/vzhS6qvHRL17AeH33L4NS8vfyKKZ11z7jz88f9+dEbUs08ce9QRcbTM
mFB+ROXtF34y6tmntvzgiKv3Dbo66tm4k1ceGScvxSN+cWRcfp8b9/aRF3wlf3PUs/P67uwX146a
k0X942R+c/Y5/ePi5a5Y1z+ujX2n7xdLhq8e9JeoZ0clf1YS1/7+MLt4wINvD3kx6tmf1x0zII7O
MePHD4zriz8/eOMxcfG+v/Yjx8T1R8eO+d4xcby+esGUQXFp/t/HFg2i4wdG2hO31i4etPHRkq9E
Petx2KpBcbzeOuOFQUVxdXTsb46NK/vm4188Nq58r2b989i4/CaWpUr33Nn66ag0v7Wm7Lg4/bJ1
+snHxeX3+cL/Pm7Pm6UPhZ8R9TtpddlN/fq9VRPMDvk9N/eOsjheH3/SP8riyvD7lZMHx/Hs/9Y+
MfjSXmWXRT174sxbjz9jxfPdo56tKn/u+DiZuHDpc0O7bWuaFEXLZ/KnV8TVUdVxcyvi2vv1m39Z
EVf2RcnmYXHx/nvi5mGDbvnMH6KeFTR+fNiDR9+7IerZ/6v/f8Ounrjr2qgy/Lrl06PiaKnc8tyo
uHr/7ti+o/sWnzs9Kt5nFw0fHSdLz+fBaIir2+4zR8fV+3fP2Th6fpcn7o96tmTS22PiynD5R8eN
i0vzmcKzxsXV7T3dvj8u9dXlpVFpnjLrsRPj0hx/4TPjd39pfFlUvGeH7hkfJ2c/X9x1QlyaLecf
PiFOJs7t9tkJr2Vt3xb17Bstj02Is70bqNfEOJ79uvTm2GeF079yUiyv+9x0ctyz3zeOnBxXvo8v
b6uKi/fH6aVT4p5VL1gU++z4ksenxOX3s5asqXHP7h6/PPbZqqpVU+Pqr/no16etbvrTuVHPthf9
vLoopv6+VlQ2Pa4Mc7rdNz2uHX3h3Bemx9lnSyZ/Ysbs+n05Uc9GVx02c/ZtF34j6tmnV7w4M47O
W7fkzmrd/rHmqGffGVY9K04+/zluxOy48lWdd8XsOHtiz5lfnRvH62H5V8yLq6NHJv90Xly8V+vW
1YwbPvCcqGdZawtOjUvzD/POPPXs/7njlKh459O4+XHlG5v3/+bHpXnkGXkL43h25JjTFsaNUy9p
OGdRXJpXF/5v7LMblly36GNVqSOj0hzS69FF1H33m+F4RJ8++c+L7vhy9or6YDTE27g+/7Srf0an
jo+Y7/nG2C+fFtc3zm8+dnGcXJ+fXLc4jp+vnvLZxXH6+php1y+Os1unjz9sSZxtuvbsuiVxtNxw
xtTTVT7Dz7696vOn9z33oRuj0jz6wuPPiGub1zXsOCOubnuPGn1mXP09d96U2Gdf3HzWWXHPamfs
Oiuu7DeumnN2XHv/cqL27Lg0f5p84Oy9zSN/GBXvhEn/PDtOrou7Dz8nbqz9qY//6py4et96wU21
V/3w1uOinjWvv6t20qn3/znq2YyPv1IXV7cFp3arj8vv8xueiX324GHHN8Tx5XuDFzcMeer1J6Oe
nXzBxxri0vzWxq/Hpjm+5s3lcfE+MuEfK+Lss8vp0aa4so+perUpLs0FE48/N+5ZXb/l58bV7bez
tp4bJ/PTN11ybhydX51Xft7ntyyPnJ/o3+3R83SsHY63tO6J8+J4duKW6pVxz/atOWPV6wuv/kRU
fscf+9FVcfGmrj5pdVwZJox/fHVcvE/Nnrqm7vanIvvNhSdcsDYuXv3CJ2Kf/Wpp/vlx7fbSTcee
H9f/7ZvfcH5cmv91zN9jn20+YsC6OJno1mf0ujg9/+Wihpa4eL+my1ri9OAdBeetv/jFXndFPVt8
5Jb1ceX74tBX1sfNL1Wve37D5Stu7xUV778GHL9x7X/fOzHq2Zypn9x4/eXlP416dtuw0k1x7WH6
eadvmvS3vRVRtJx67t82xfFleeLlzXHPlpyevyUuv3vmTtwSV/bPza7cEle3Z627bkvsvHDuhAtu
nXTPZ6Oefazp4Qvi2sNljbM/EicT28/Y9pG48j018ccf0TFe+Nnwkp2xaT4x99wL49KkcZ+4MK7s
6z/yzIVx/Dy5aPRH454dPvfMjy4ZdckJs4KP8Oz+jZd8NC6/83v+78fi6Pzpid+NfZYw99CPdwDL
qdGXv9ubT0PdlczlfYcVEvawcHjqKjH4VEkTI5WXOw+2+6nAmjLioxjbj3p1Tjrq1TkHFnVcdjrq
uOwDi+ovYkTUeO40JdJRmxIZcccf44Ay0wO8w1WBGOltselfikhCEuVmmZA2bE47YXNM2ApKeuHz
4sPnOeErKMuJ0yU2TpdAnArKduN1jYvXNSJeBeX44hbGxC2MiVtBuf74bgNx4he1E7+C8gJpFEem
UbyfNCoCGwODv4Qc5npQwpV51BSipjTqDQcY9YPJ1Yn69nveap3MNn4g3Hn6Pz3XQxn1wCVBjrpx
fnw6K7fOom2lWRzjIGXmQPn4gTfGp/nl1MioRRL1IT59W6M+lMjVU9ed6Hv/3QT9feTyBxP1X0SV
pL+i7zTR3sCYVGJsiqbMKoMcZSFSFkfqQlPkU05r5VNQ66gkHSts/wyX/CthMd2vFlNlMlcTPSFF
J6ZoQoompqhqSIKP9p4xJJ3NgiG0MEVLhMj92U0DIqwyzePEVMIkbdNNJ5qJgdVXEl4GTXP125Lw
siyTcCBVpJepAdZb0mxFmt01zVabZiDBA7LOJNGtML23viWJbs0+cCtN0ugOy7/1TUmje07HrDVJ
h0cQyzQdjCAysdqy7OfXXREUVT88t3jbrn9GimJXmhw49b4E3cP4A+wR/u20hi+qBvT3k/zLkqgz
IGlLNeqMrFyJkm6toShxnfFg4k/oxNPnb3s+/dKaQdFG0SLUI++JXUdrZP8s751dCdHQr9CVoH6b
5Rtzqm42yT7aeqig1fJssygiloASEyqcVon8z/twN4jErMHz9U543p+7yuzPXeekvgFP2FddM6kG
1zrZl9so+S0AZSvwrFa+z8dn3q+A7wqqFZr423m8+3c50lmNNNcjxBpJSanhXNaZHcIcd7nkvkpi
25DLpSSr8N8cmg7Va+MugMv+XyvfDPQ4pCErqJAWG+pbpORaQv1a33rhHe9CbnLS5q/12fBaMi1n
rfB0jVC5XihfA/9GKieuD/7Kn6bD/hvkVHvmUyMF687jc63kZPm/RnKy/G4wJdNvDzaQfo9wAZ2A
+2rZM71JOHUe3GVIf7lTgnpJi0PVSx3YtOJSGEy2zrWOm0WSGtNaxX6jUCmskJysxIbrVfnq0aJp
NkiOjVK3zaaktuQqU7UI0yDfWWyR0palaWI3S3GzIxVK83If/4K175dTK3UaeirynGLK6krBKpN/
LWq+UahYb77gaCVjrdTI+nT+Hi9Yarll2TYQ5M1gkcdCWphucbblHHqr5u1/P8P+IHN9X+fGPiyD
LWVp2i7xfhJ1B6LWaNSnu+RGmSJkTJHImcEIy3i/M4QRvW1GM4URhmzGM4YRBuuHzTaNnFHs7tmm
ktbw3IxmFg/BAL4D8yixAtg3Ky3EfbNys8kWoH0RfAjVmTJkZufmklvs9oXwfjBsswrv/bm5KQoy
rH0xvDtVvG2viuHdqdz8UOxsfwoRgrgjv3jbEk1hR35uQWQKOYFUwqJ4Y0HxtodUnG8syO0Wm0pu
MKWwMHZDhWtKV3fL7d5uSnmh1ILiuLt7WrR3d8/tsd/UUnSgfcF/wJRQpT9aCTy7ykDzYijW3e8e
uu6DYqJmRUSVKEM7Xhn/HmbLv//U3oENmzvMndbW93TE/S8lRAed63tp+/7brbr8GzL2hn/lEcwH
twCWbDcGUfE2s6bdlJmp58TYlelYw4mT6a6EiHgHNtbwxz3wsYY/fsfGGv40Oj7W8KdzcGMNf1qZ
jDU+BI3kfaPzIPRqeE6h0l/EQ7ys/WFaNT2IuvgAup33tUM9xHTGjFo6Yuj68oubENGoDyXcCZGD
2s1wSJXUe9CC/52b4b/rjqTOauyM+p8a9VDO0/znDc4+8InMp/9DGXtouHMQs1gfvj25/+FC9L7u
ef1XsUxiq9RZdt6RyE2kQ8ZN+/init+3JeZx2R1fYr465+CWmFN5/zpLzGtT7/sS87+Zqv8gpysy
HwAc2MLP+7Z688H0toeqy/ywafaDFItOYzFakA50u9+hti7itYjm/OGcRjjAScQD3fzwL2+ofQjb
5KEcSn3gjD1k23T+M5typ5C/H9z5959j71BZD2pM8B5ZlUUROYeiH/za8AELU/zQv3Nzb/RQ2U2l
c3Pvv1TbPWhVHJAssq/cOtNmqbzczhebO19sjmk8+2nSB/Nic/qnzHJm9tamokUyP/IF539LO6Cz
Y+vs2P69O7Z/6Zc032vjWaP6jeeDmo79MG1Y/NBG7YO4F6ePI9XfJwPujwfc/y/gfivg5g9Eu27+
wL/rftcejzrhI6mE434p4J4x0e++1riD+QfpvSjg/kTAvTXgtunTSZo+f1Dbfc6HT7juIL/4cC3X
zR/8d918UI/r5g+nu27+MK/r5o/0u27+6K3r5o9+um4++Mt180eq23vOB4m4bj5gwnXzh5Bdd7D+
+YAk182HKbluPqzKdfNBFK6bP4rsuvkD0a6bP0zuuvnQJdfNh6S4bv5Av+vmj4m7bv4IrOvmD9S6
bj40znXzAUmumz/q6rr5gC/XzQcZuG4+/MV180eSXTcfrOK6+YPjrps/nOy6+TAE180fv3bd/OFj
180HC7luPujL9/z4F3308SENrpsPKnHdfIhY1POlpr3wR4vd53yAiOvmD6O7bv44q+vmj8O6Tj5Q
yXXzB/xdN38U3XXzoR2umz/A77r5g8uumw8ZcN18CJXr5o8+u24+yMh184FWrpsPF3LdfNiJ6+aD
5Fw3H5znuvmD166bD4Jz3VY/NRl+88En7nM+AM518wetXbeN/6CJz4cXuM/5wEHXzR8qdt18QJLr
5sN/XDcfcuW6+TAb182Hlbhu/iC16+YDRFw3f+jadfPhVK6bP47uuvkgSdfNh124bj7MwHXzx9xd
N3/s2XXzYSCumw9Ucd1yCJXz48NmXDcfLOS6+eAK180fLnbdfIik6+bDDF03HyTiuvnD3K6bP2rv
uvnD8q6bD5Jx3XyYi+vmA7dcNx8y6br54D7XzYcEuG7+kLbr5sNNXDd/9Nt186Ebrps/8uwLX/gL
f/lPz/fJIx/E47r5UDfXzR8Ed9184Ijr5kMjXDcfWOW6+ZAV182Hb7huPuTQdfOha66bD3tw3bb9
lUzy2zMXBtxPB9yjT/a7txu31b8vBZ6/EXAvrPS7dwTc2ZP97iXGzQcBkfPjQxpcN39A23XzYaau
mz+i7br5kCPXzYeOuW4+LMZ188fQXTcfFue6+ZBQ182Ht7puPgzGdfNBgq6bDyd13fwxe9fNB6K6
bj5wyHXzIZ6umw+qcN18EJbr5o+tu24+KNJ184FUrpsPYXTdfAiP6+aD0lw3H0bquvmgVNfNBxv6
3KPu8tUXH1bguq083GLkgQ+Xc5/zYR+umz/g7rr5gArXzQe4uG4+cMh184GGrpsP8HDdfHCM6+YP
zbtuPuzEdfOBva6bD2ly3XwwjOvmQzZdNx8c6rr5UA3XzQcQu24+vNR18wErrpsPUHTdfIia6+YP
7rtuPmjFdfNhnq6bD23wPW/Y4SsPHyjjuvnAXdfNB1e4bj7oyHXzoaqumw/Rc9180JTr5sPyXDcf
Cum65WAj58cHMbtuPrzCdfOhRa6bDx1w3Xywgc+98TRfffCBgK6bD3F03XxAqOvmwz1dNx8i5rr5
cFPXzYe5um4+1NB184G1rpsP3nTdfGif6+aDL1w3H2TpuvlQQdfNBxC6bj5k2/3xoc2umw8/cd18
AKXr5gPHXDcfLOS6+YBv98eHJrtuPqDCdfOBtq6bD15z3XxYnuvmQ7FcNx/24br54FnXzYfHuG4+
vMZ186GBrpsPwHTdfLix6+ZDq1w3H77quvnAY9fNhye6bj4gx3Xz4bSuu20/vysnfCRVQjr3GPz4
De9U04/f6OkLgekbjv5GO9FL0tF54Sf07RyOvnDiQeW+44Cid0H0Lm70qF/BSR1M8uT9svrf6cfF
Zztj/yE7/lufEav1uJGIynd/uw5dUv9pv/JJB9XELm4negYN/PmDy73y5INq4Fd2NLo2ZrcRZFce
lIQtO7jo93L0XRo8GJ1/bIJPmTWI5s3KR9R8jbpSonafrDm3H5XXlZOImtSoA0s4asPkTHIdHhX1
g/7dLaX+/H74rasTHzKF8AH8wqLT+ftQ/doqE1sTxAMrxoOnn9iFNzbZgdZYc0/26up58ENemflG
F6K7gMJ+GMwehWfACcBMYC/QCnQ9muhtYHAJwgDVQAuwEdgMbAGuBL4FPAP8Hvgr8HfgDeAtoGwA
0XxgEbAE2ABsBP4X2AW8AyQwlM4BRgKTgSpgFbAFuBD4KHA18A3gGuAG4AHgCWAv8ALwIqeBIepI
4BzgUoCnmH4A3Af8HHgU+CXwJPBH4HngL0ArUIzh2bHA8UA5cDpwJrAUOAtYA6wFLgN+DLQCR2AI
eixQBpQDQ4EZQD3QAJwHXA78BNgHFGGIVgwMB8YAdcBngWuBG4AbgSeBPcAfgeeBV4Ejj0MewCLg
IuDbwCPAL4B/AjkYCvUBpgDVQAtwBfBV4D7gl8AfgL3AP4Eug0EL0APoDVQBK4E1wDrgs8D2wTzo
J7oNuB34DvAgsAvgqdVXgDeAxBAIGNANKAJ6AoOAU4GPATcD9wO/AZ4B8jCs7gOUACcDK4FLgC8D
XwceAx4HfgX8DuBpsd8De4EXgJeAVuBVYB/QBpSXo76ATwE3At8F7gR2lvPCDPFrLjQUmAbMAGYC
G4H/BXYN5ck68KQCPRowFKgAhgHjgGUjiWqBVzE83AdcNwZ1BTwM/Ar4HfAc8HtgN7AXeAF4E+iD
BjcJqAZmADXAqcB8YBFwGnAp8GngNyeAP8CzwO+A54AaulAmxU6lveZeJpPqNVT5UXXf91l1v/hZ
dV92h7r/dLfe95r7i3fr827f0/vse/S+1Nw/b+7r79X7o+b+J3NP/UDvdebeZO4rzX21ud9h7k+Z
+/D79D7e3M8w9+XmvtLc15n7I+Ze8kO9l5p7udxraLlxN5n7A+be7369bzT3j5n7p8x99/0a/13j
ph/p/TRzX23u68194480/L3GfZ+532/uD5s7PaD3QeY+29znmnuNuX/K3Heb+/gf6/2L5v7KjzW/
1437DXPv8aDe+5r7EeZeau5V5j7V3Oeb+1Jzv8rcdz6o6T9u3E+Ye8VP1H+kuY/+ifqPNe4zjHup
ud9o7smdxt/cd5j7TnN/xNyfMPenzL3gp3qvMvep5j7f3G8x99yH9L7M3K8w96vM/Vlz/5O5V/7M
hDP3B839YXN/xNxLHzbhzb3K3Kea+9nmfru5P2LupT/X+1Zzf8bcez2i9z7mvtrcP2XuN5p78hd6
T5l7nbnvMPfbzf0Ncz/iUb1PMvfZ5r7a3D9j7leY+9Xmfr250y/1vtDczzD3ZXKvoSuM+0pzv9r4
P2fcu819j7ln79J7P3MfZO5LzH3lLo3/MePeau6Xm/sV5n6NuT9o7kc9pvfN5v64ub/9mKZX8bi6
hz+u7kuM+0bjvte43zTuhb9S93Zzv8nc7/mVPj/qCb2XmPvAJ/T5WOMeZ+7jzX22uc8194XmvtTc
zzb3ZSadC8z9CXOveFLvF5v7I09q+D+Z+17jn3pK7wPN/UJzf8rcc3+t9wJz72buTeb+gLn3e1rv
o839M+Z+09Oa31Pm/rS5P2PuL5lwE/+g7knmfvaf9L7sT/p855/1/rC5d9+r94HmPnavhh9n7uON
/0Rzn23uc819rbnfaO5vmHvqBb0XmHs/cz/qBU23xNxLzb3M3L9o7peZe8VLeh9u7qPNfazc2Sye
3mc7xq3JZG5WTnZOMiv7v33LGLBJzH0hNZuTWkpoLvEpQyU0X84I4tNmYM8hnSTl5CSSibzcZHpH
s7uouJUvC2gL4tQRn49ENKpUcu+am53kX2zuk2mdnEUjcYTi9C+0Xds+XEgzaQ5NQ45EEySfHtSr
4KPyPC7ODISfjTHCNIk9BfnCSjM05mcnE5nRWEJVuPL5NjyHfsIIH72xeU+RU4w4DX4PhOhEUzPZ
2VlZiUQqKy7f6XI6Dp9wtEY27KO0uVIXFPiF6mKxOTenwdx5BW7MwMyonS6vBzTSRuQMy1JyTCRy
E/ozgUI5zhEa+dygLfKCgZ61xWf7cN4D5a2Mi/vCKk2aF9pp3NAR1YV/n1b9mdemVU9KHpMLCxey
dePxTAmvyGRTVnd3Z4K+2WIJGBAkv/PXoV+P4VyZh4t08brhlWP2F2P/PxXntja7DpWANOivGzQL
a5Vz5cqngJ2Cq54C1kSHoZUugvzNkLbNEjSPqtFeF6MFzocf+5wOLMT/c6T1R/3YEGUjkw1BNs7Y
8GJjig0lNnrYwGHjhQ0S3jHQBcgHugIFQCHQDegOFLNuAXoCvYDeLH7ZGAcdTfTyMKId4zGunYAx
DcDDMTCTeDcZr+jxLrK2Nn67Ig+lWg2NsVrOIFtNKdGvrEP47Dk+6e1AS94N/qvl7Lla0dOsl2qh
e+tEY2QhzEyESiKH8yTtDdABTUbHL5Czttab09C0pW7BE35LbRXuCRoBimslbT3b7TxonFWiic5F
mELk3WLO8WqS2E2SEtNRBB27ASWzp5xNg+9alG8NcmjEXw9I1wSgBmgEk3ou6dXWe2sTeMRrvrzO
/22g54Avtn1paxGGw8tElHJbMbSnZHdhPfH2P/YWTWD+zzVurvdfUqK1e5LngvJ4KoNyc0d+atvg
r+3YtnHsmra7C25c+tc2ajJLpnsuUkU20oTNyu7+/d+cd8ni60p/1OXF3f+Y87OvtNGTZrvrrJWJ
QNiLb3vzd+ftbn54+qAhl/1yx6rb2+gCs7Xl6IeCYTc2jD371rr5yza9/D/3vP7Y/4xroxqjyr5y
Q04gbNbaR6s/V3PHZ1N/nPn1oYv7b2ijfWYJ+yu/Dqbb74enX/et3vdtW/zJk67/5Bv9/9BGl5ne
5H/OUBU534TNyfnq+c/+74DdL37riKaTJvS54rVvgQ/dTNg9wXT7/NeEmr99YVHdmf0uve7PX7/r
jjbKM8vafzMvn3j8ffCecy96ueIvX6Y//iN51Cf3PttGWw1/dz+rZUuasOFfeKp3nQmbl/f8rP+Z
NXXhj0qPn/Tq1bO3Vv2lDTKnv+2fzAqEXXbNH1e/c9nmR/o+de/y1JdrnbD/NGEr6ahXdXGGXW2y
SPMPbuZFlGydAa8SSrWmSAUpJ8WrFVmt3KCLKFsEMEFdWn1bqcwvSfkSj7/RIsXlBPf2Zb2qCfJ+
jgcKOIO+r9oMkqQZbOx7ABlkawYcnvfAVCXU/3H2hITUU1fhxtQEt5OPJzjFH7Imo58nJv0eGi/B
ubYl+hJXZffW7HQOxfL/kaQ03d5F87go4dHEb/JUwqwsQWE+foRH0y0oFyd7DPIej/Cf/HEFrj/k
0Ch3GXhyfYnmwfdFCL3oGKIvop08Pkjv7P94D72/cKQ+P+5ofc539l8+UO93T4esDiC6bYY+t/c9
c4j+DOth9Xwi3k6yDOz5OMhrW6Tp8f3Xp+p9D8Lkmnshwr3Dkyb4/86xmg7fOd13TtR7Crq9EfkO
w/17oOMY6Pz7B2g4pq9wnN453GVHarjSnhquvIeG43JyOL5zuCT4YLfRWf7YGkk4NZIgrYnPENu4
yvGvIm4yn63Krq28U2UrcCJdIv7gPlnu54D3KTrarKbwnbkyeZFyh+/WX/8rknrejcvVrBVQkpru
HiXaoAuNzJwYourKCKrGgaorDxlVLH1M1dZCj6qBPqrGifTyV7EsdVZ6r0YL2dVL09h9uCe914C6
LCu9dKgoXVuslA7v61EaVZNXRPBsInh2xSHhGZeZKbBltpQMlzCWZxNDVH0tgqrxoOprh4wqWxNb
+3hUDfBRNT5E1VURVE0AVVcdMqqYGqbKrbWhPqomCFU8oWw173WGqk+CKt5FHNa8u2TI9JhcVfN+
8sdz09R2oQJQ+7Lpsb9kqFpsxjZnmY3GLWZD/s8X6n1Ujd7txncb35bm/lzV0dt76N2WhsEl+CJ5
JbgeJbgIJWhBCXjfargEjybYurK0Bznt/pYt9N/9P6WNaWot0Pva/dB2g+FuR2mbavhp70+b2rf3
qQEpsLTVHK739mi78SBpc3+Z8M3SxPcovrlS+c1DIpW9jBRuN1zaZtxHGKmcbaRyl6H6LeP/lJFK
G98tgUjloGipvIJYH2sJbjIlYIuGd8dvBWaitbO/loD32qQi+Grb0JdMy+c2Y+/W36WK7Rpu8fcX
+bWkvgNlW/7MEIU3R1A4AxTevF8KrzAUXGEo3Gko3GkovCJA4a7+SiFbXi6FeT4KZ0jfV9ZNeXmB
Y7lVQjvsYm17vK59277vAcdyGymWW2nachskltvJZmMo35+CTfipfkQrEet7/fXO/llFeq/qo89/
01ef8539hx6p91Gwpv6B+5sn6nN7P2oS0RloKD+YDAqghU+ZghE13JdNhV6DpbQcyn4h7pfMInoU
9ytnqz/fmybqfc9Efc5uDl96isa/DM8+jfSegxsDZHnO+fGd839qit53T1P6+M7l4edcvqMr9f5a
tZb/yWqPH/pTi03Vb3w/f2tE3zXdSMbFbH4cVN81vEjB7Wu3Y7HpJgkrH9NDVH07gqrqQ0oVS939
aO3du3lUjfZRVS1SOz/paYD9WWw7jMVmqdZ0DiXVYJDw8v4I6+1i8vh3m+HfKFBSScq/ae+h3eav
z2khem6PoGfqe2ix+emZGqLnOxH0THkPbTU/PVOEnvvJ6xXvMPR8AfRsowPpFV25em8stu4oU9GR
2n6L5PUOr0y2ZdhyfNdYbNy785sPmVge4Zbh/jKxP5gyHnmJhtkPhXc69kfHKTxQ681SePVh/jFi
FIV3HRIK3V8mPLSU8T2Kh/eTR+HdppYPhbQeakvO0r/9OL+08gg6aCd9L8JOqoqwkMLcPVBLju0c
1tk8n66rXiUyq62rdSUym11Cc9ATTsGdZ6u34M5z02vkOcc6T+bD15vZ7cL0X8r5P+6vCnF1Rp2/
9TZF1sPW439eDy1M57ucNsC/Hk+aJUQJ/q+V+wbk2CgUNsq6Hc/qTxeqG2WufouUgdcBlcJGcbfg
j9cSmk1IfrpWcl0v/mtk1bJM1kun02TQMI+GGWpqaLCktUaocOn1cqjzlWq9rAKsRp6rhEMt6VJw
+HWyzrlCVgXWGr43CtdXy32TrAieRxXwmSFrIbzKqCmvkTAlsjbh5a4lqQNFujZRgjjN8tSrpSCN
wZJoGF3JYFoW4O+EEE0crsGsWzSDhmazWmIp4VpaKem1yBOv5Bvkf5W3KbK2zPyeAr91iLVB6C2B
vz/1eqHGpsHS0iDpDqZyKWWTlKZRarhE0g/ytE6eaY0Hy1Lr0L7OSIreV5vadqnjsJz7csmHU1Qa
Gk3KjUbm1pC2Im1Ttg7CUhLkkFdnwXxZEuZF1nytfKiO61DzajR8aElTYtuLJysud8IlrI0op+Ws
TaPGSWNoWlJqJaUmSalR2u4Gw821QqeW2rbNNWm+h0uxvxLoinmJrO2tEq6uc2hX6VKuscapljK2
SIwaxFWe1wErhdYtCDMtnbPVQNw+VuGP9ZAnhyq/Wl8zeR9KWi+tlbIONe2KebciXX7bJmwJLIVu
nbv8UBq0BFMC6bntQWXBS41zO1/qkv8rN7zSdWMtUYMjQ+Ecy9OlqkXIBkmlxXB2tdGZUbznlqzt
wPYXts482rRu4uqONWwcXdwbrBHXfFoo1PlbDnNpATWLrl0pUsj0WIq5DBtNLo2ST7CGXI42R/Cx
gWyvGOaYR5vVae2lXuaT0KAu3ULB9mjbXZ3JuUR6vHWmdWmqzLuKDPO3sqocWW3SrwfXNhjJ8PS4
ykq9UK0lrDM83SR0c8jBUhcbpPVqvTaatm21hfJNaWMqF5r0/dITlGNtL2tMq9M0Oex6kTKlnGnZ
IrmwPnfbba3hWSOpHtPvyq4iT5u5fYJHa2NkGTkn3uOjsqV9bJia9Ub3NoYo4lLPlPJZCrX+GpHi
RlJ9HeyXOITlKD9fTqwbV0WE1D1PLCtaR1YaVW51j0FDqAye5rO8D6Yb5gPrBpVJy2E3D4+D7des
anStmw3pOqgTSupMnZ9Hnl26Rvbc+Xs95kODcMh+oFVDbxCedaQ2ra7wbMzVDjVWRvbHw3BuFehZ
5qV5Zevc0jsTduYccmvX46G/NqzkML9WkrZ+1+pie3I90lyTTttqg3hJbxANoTWqu4xWyv4W1oDl
Tjg3z6h+x9P5dWmeZ962wprWSrCniWzv6fa6tsY8CeG65xqpF1pUdzWTZ1254xqul4Vk7WJXc25A
GlbbeE/85fBbUC2kWrycgn2C7hxq8NWUrXNtB1H9SRm5+sq1OjQE69xCpMOan633DWlp0L7S2p8N
5I6AOtar14u/hte25bU2zUc5VJ52WyuykTYLdz3q7XiDn6yXcgZ96kkteavx1bpnzlsL05OFlYZ2
V84sB9f4+Gml03LE60sX4Plchws1NFXcYf4H7XMec9rRjGqQyYg7lTyrUdPUnjnYMwXrhku9Sqiy
PVaL8KKZ1pLV61zuFlLdGde+9m8BtK+PeNQ7J82/yeDFHJ9UW/pbqJGsvmwSvxWktp+1L1UWXHn0
h3StjNW0mqx22ZjWqGXpXIb5aLXtz1ofXquuMLMHLQ6lUTa87b29cViD+HOdumNUtTWHyZ3nACpk
LLFAaFnjtJuo0USQY1FjgmCtWXtnpejhcJ/EXFohUmLnMDraqtsbczA3dA+2bbXueH699LHWjlPt
yb2U1Zp+bV4iNaj1Xp9OkXdcLhK6w/MvVlZqReswF2bQSBpNY4h1ai3pGE5nq7Rk2jetIruT0vYe
Xiv313WQi17voDzLlKOss1yZZp5Mc0rr0qS9pVfu9jimOTc7lGns5aRvHKwRnaDPdKf9WrK7362l
a0cNtq+x1Gv7Lifbtr0nPNvFmm+VKXGtlKnFZ7Fnxn9bdzwv1BCixG+brzMStY48u3xLxjlpylqm
CqdMdjQWVSK/5AZTtD1FA66rhaPNvhbZIhYnS/JyM/Kwdo1/Xq3J1Ei9qQ/bD9ZLrn7bKXpm0j97
51pB5eT2BR4FzeT2zUGr20uvYxpD+eXnS9InHTpe9OefucR4MtFoKLXzQjpnoK7JaEFzydaw155s
Cu6clWeJ6F5yy6Nao1f89Fqt0SLWVJPhSJhWO8vhjoC4ZCqLwVmeKNu2WdJUm9Cz+6M5ZWuFe43V
QiGnuomajKTYOWGtHX2rhGPxaHylkV07wlHN6pYvOMoY/CEen3s6IWj/WsmK1gh+qyZMtTuL4o12
rbStkZjemM2m7LZIr603H+I5hG4vEXUHegC9gD5AX+AIoB9wFFACDAQGAaVAGTAEKAf4zTp+q24k
wG/V8Rt144CPFSToKeAZoKowQVOBauAdcn6dDqI3Yx37Yh3xqUX+Uv2p17VEhTtzk7u73z+A32XL
GqQnFB156OeQouY/WE93zhkd6JxRfCsPzxlFr9PZcV57szz7n1fiNHVsvprs2I5ng4OjhsEOP6xl
w7VmZ0A0RXcGxl3pDc6VuHMkrn/UaKVWOK516Vk5fovM3w/b3tzVst7Yq+PrH8H+zW/JcE/BK+ja
A3Usj+AIcQ25fZQtZaOxJNzRdwNZa5HrgGvLWiyZWWmuTNpxeUu6BHZ8683kuOP/g7M922sLdr7C
yyGTskSXRGnNZCbGLZurKb14h76c/tGaZ3VYLebNvHhtzLVq42ZS/PMvLeTZIHG7NzLZ4aF/M8VW
n2nkYp3UDeet70W2SNm9uUSrHVokLM8D1TsUersUuA2skKclhrfNpp5cOVBeRs1d2XVJOzqw2rM5
RKet6fXCkfPSbq1d19bTkloNyamWydwih2OdXI/2w21Oa8Pm2H4K7kyUyjLXoNWmGj44f6I587PJ
smeFe9/CiBqwJZlOp5CVu6EOp6LWvbU3syNkLYl12ZGH5S2nG7WDp/3+N2i/tjeLafPwjyU828DV
erW0gVQP6zqrv0S2TUX1+n7Z80ZH/lFEsJy2FXl01Unfs5JUF7m9gmphy3mVSdZWy9M8Ds+9uqut
PEs5Wd6Ebq/WvHbBXONyBHcVBVO1mkO5vEmoXyncsi1X7avVpidyV6U9HeLppZUOp23pG30p636b
FtKxrsZ3Vw4yLRtrnirSLzMsNxzlHSAuN1so3N5tXl560XaVuzamZfBG326qQ9MxbMrB2QBPnrjc
tYanUXooTsq9caQnUdEcDGoQ1RSujrEWX3sliJJ0T3Nvcqizkl0j7+LPjeCiN9vQHFkfbrmD+3/C
a0u6o259u5SWUbStOIdG0SK0Ik7f7tpb6ZOxcGqDHe5bOfHPNAZpqpCcNogWaJb5GQ4TngEPtkTX
Zg7O9ITnl8qMHAZnke1McTA3W4bM+wCtt7mSC9fppsh0vdpcY2bvgqOf9aR2aktEOSrERqgXKWgh
bwQ4M0KS3FZUm2Ecv2XkWhtqx+l8Xgu57dJqL89H10PsOG5/fXF8K47qEdTGaKA1aWqC1oP7zN+S
vBkjt7/V8dNq8lrRWlppWlpwpSLIFdfmKgtIpFKlfqyBB0vtTZG8dF+RXYF3V9zd/YB2px/Py3ra
yNLvzefWGrl3ORXUGGFJjF6h64jkV5Cdy2CN10J2x1+L4Z61PIJ61KMuehzqyZb2xlskB9biTcJ7
7aVX+vgRXh/yatXPAb9sRKfg1yrKAdVQ69Ocb3DKvcKE9GZa1km62iOuNm3Q1qKOxJnzWm9u3Wv+
B7ablEs0j6L2wnJ7ODctkQ0y88IcthrZ66uiaieaN+7oulZKwfVdTp7cenP9G0Q7RM3yhHusMAW2
F3TnNqzFZPslXevzWqvVrW5f5eqJoWZPg8fVoPYshAUZrjseNSxErzgU1xI6VdLjEHa393xqTLcU
1S8uDaci3RNoLMpcnqakUNZrdH/FIqNhtObXkad5FlCU9eJ+d0f7HpaBE8wo06NzxgHSOQPpjKKR
QDlSOk1qaANpX7mQdNZgLTVJ6MYAHS1O/UwzrXqt06ZtPcwmb2ZpspEi/X6caw3pqk4z6dqMtmHW
v3Y0WGvKvRolnS40rjOybXedn2oo98udcsNqcubXRGqQuMulrXGLaZJWUytpuzubhoreZBmyLXEo
DcdfBZ7xLM8kKkxLlbZ0tx2749wt4lKNynyY48u1UGSwWiR+JI2h0agPTpn7wPGmDO4u+ZnpFurW
ZU1A74XLegE1GzlYR2rftkidDQWF9XJfH1lC7YuryM6rTRE95LXCGrJrvc3pdmxrPyhFW8idEQla
2EOJNZuOoUbQifIXLgdL0yqpEx07rZF6XGV62nqnXCrPbgmDpcu8VF6ZvHVXrXXLIaaJLVctS6HY
cDry5niF7UpAT+LWeDrSmQZZmC120ykmTR05r4EstATktRL/s2RU4L5a7trWSyhBvTIO3Rv58xs/
/M0w/o7Y6cSWzHzUBJey8AC/OMblTpLb54ZtHZ1XsDNX3l4bbzxdT94uCo63QmpDZ/hWkK656rtO
rGHDY1Z3FOimrn0J18N5JhSnWSE0Lybt63VUa60Bd33SWmVcinqRN6u5tlD4PRh3NdNdrdA9d3Vk
3zezUjTF7L3zvx9l9+SF+y3mcqY7bjzrZ72RKHd3SmYWic4tTAefhqJ1jkBLGiGjxvfuj63oteDt
OlJrkEtWRiUH+J067oP03Qhro44UPTCcuuCPW14NyjFdZLkXytlb/LX9ai/J5ed+x5W7EvDB2mbK
Lz8HD2RWMdMZ5UP5Z+mqDo3t+amVHA2p8wP8P0vpQuPPWm8Ynkw17oVk1wVaTLyoNwk1lbCVM6zd
9yLDdGqOUyJpmEfeKEnz5WfVThtULeG3Qth/eqiUbumDJY7n4TD42zlAf0mC3D00FL8/f/9ZP96T
cQ1wLdBalKB9QKpngvKB8b0TNBG44LAEXQg8COwEbj08QXf2T9CQoxK0Fcg+OkHzgdfchH0bFv76
Pjn+N7NgPseVHXCQfEQza1BWfil1rQaLTllKPRpaKUE9ryXZbDFlEE3buZU+4J/s9MgCWdR1XJq0
wp2prN3dV5bwZ/l6cL1tA3qVJOgh4GFg98AE7QEaShM0ekiCxgIXAmcfn6BZ5Ql6A3iT725W8Y6/
H1LHDtfREQre59/UpY4sjHj7mOr0E+fg19xgrIgfH561/1DxPyMLfrntxvWYPxTtGLgbyB+ZoElA
6yjoAmDI2ASVA3OBneMgI0BqPOQCuBR4HpgxAXIB3ONmd5fr8FVahk8ydNzqOm5xHTfEPvE5rsnM
4UvN/8shEn72SeTM0v9IP4KTKAroCVMHPpn4QH89uN7qgKWTE/TSlAS9AsyeivoGaoD5wEJgCXAG
sBQ4G1gG1AENwHKgCTgXWAmsBtYC64D1wEZgM3AZsHdGwr/LLcMm7HPE75nrdARYFfpBLh0p7cf1
8SLQbSbqcB4enpqg+4A3FiToiYVo54ug/4GlwJXnoG8Ati5L0PC6BN0IvAlsr09QSUOCBgKDgFKg
DBgClAMVwHBgZEMiU7L/drCO9yufeMeLruP9qnv5dUnXb9G2jcnibZe8Y2u8TyJQ/0fy18bcLySO
kRTsd6GqQl+ouSfiCzWTM/pCzYF+yW/4IKLtR+qX+Cr7x1E4+YC/ifb9gva+iUZ0cN/b6n6E+cbc
oP1/E+3egvA3vyrfw2+ijZIwlnOVQg+3ydHAWGA8MBGYBFQCVcBUoBqYAcwCZgNzgRpgPrAQOA1Y
ApwBLAXOBpYBFwB7G9tr852O/Tbm9+DntP++c516Si1P0DNNsAOApavRfwOpdQk6CnitJUGvA5du
TNBngGeB54DdQGoT7EbgDGAp0G1zgroD9wMPAGO3QIaAO4G7geQFCcoFUkAvoA/QFzgCKAEGApcA
77LfRyBrwNnAE8ArQCvQ90L0KcBIoArYDHwKuBq4BniYn300QW+9AYX/RusbrfQCPU/PPv+b5+lx
+XvkoR899Mg9d91z+z2P0LfpZvomLLwb6Fr8d8O17dh6cb/sKbOKoVfGpD6RVTUkmYf7lFn9KHvV
jC7ZlBo+awCtngFNk83/UWHWuRyF/1+UShR2OTdBf2yVGN0pz9zzcR+b+oTET4c/isMjjTq09CRy
Eu/cVAK+XdSB/wrmzUIvDiBuiooMJdYTdEIzaC745wRb7083eXV/1cpw/a8FHgR2At1bPHmYuh51
BVy6PmD/3x3r8AX7TqzjNtfhS8D3xGf/d8TxddcRT7XPYX9FkwLD/sKd+dl8bM/VOWtT6dF3UXqE
0FuP5fmXGRNSD663q4DdwB6gdAPsOuAmIBttexlQB6zdqG2/AO27DFhi2ns3085Hb9F2/oG8Q+Or
m4NO7c7MHPt/7yb0Sxz9r1T3LIk9uc6szr0U+AywHfg88EXgMuBy4ArgSuAq4GrgGuBa4HrgRuAm
4BbgVmAHcDtwB3AncDdwzwXtzQ/6ChL/3pPP8XKs4y+uI8PUOuLwZdqRJy/EOvZk5jC/3BFGDbEK
osRcYKxqH+ib/lLTXfvxO1+emsqhxHh0WEdwvdwL3AfcDzwAPAjsBB4CHgYeAR4FdgGPA08ATwFP
A88AzwLPAbuBPcDzwJ+AvcCLwEvAKwB/aHvfBR3TER+8NfZ6Zo4PntB4xZQ1WzoqKxnw6cf18Rrw
OvAG8Cbw9gWe7dUPKAXKgJHAaGASUAnMdWyzZcBm4ALgfuAB4PEIm81H3Kuu45VYR7xUxAd7v568
X7Rl6PD9TD13ncM3T0EU7sxO8Ce7uf6P5Do5AhgElDo2daVjV18AbIuwrx8BHgV2AY8DTwBPAU8D
zwDPAs8Bu4E9wPPAn4C9QTmIF9/368mHx0G+9t+f6+JF4CXgFaAV2Ae8BrwOvAG8CbwNvAsQxlRJ
IBvIBVJAPlAAdAO6Az2AXkAfoC9wBNAPOAoo+eghsBF9CtdnVXxIK7Xd6tYfWwUBOwHox/UxEBgE
lAJlwBCgHKgAhn9Ux9EfLPGdv/fgx/XfZTx1GU7FwxOlNWijwLD5JXT0jl3DSnbsPmnAjp65A4Fj
ti/MHbT9t4ljd2CQsmNoTt8dP8kq2N5KkzKKOxxxh+e6cXOGU9Y+uumY/VLY+XvPfz2oifIhCmdS
ESWNXxlR5attSb5jJDpX9tmskp08enpLSqaWVs/okn0GJSpfxQDnDPh2oRmyd8l7q3ME8Zlg6CcG
JfLYANkNiet5bS9on1Ya1JCLHqhUrpWlOiDZlcylPJKpqXI+iTMpac+PTHsk8UmRSU47vzTRtToH
mq3kXU6/Fek3Ic2EpMlz4SbNEqLZlCVpzo5Mk+fH+6N3lDSTmubYhJtmErzSibkps45A/GxJbUZk
aqMltWxNLSuYWitVlvJiPJKaNCQxi3Iq0a/SrMiUeMWD55B6NDQlePy2GXGzqU+akkE0b1YWnQqs
AkmzKLedtPT0hFxfWjlIS+kIp5XXTlonwLcPuJs1KKtHQ18pWgOSnIgkc4s4xXmzspFUtiRF1ZSS
tKoj0xonaaWi0sorIDehM6hL5QCkEy1zJ8J3EPzNBLedndudUJanCnfmQSYgapD8MabMvdLpT6TJ
lfvavoE7UzOVGuW9DH1fz76nUGv24a6VnanVZl+b+5tKVSjpPtyZwirit195ryTvA98sYXvyqpW/
pJuJCny8X03vzgO/EqulxqrI+6YI7/JfI3tY7V47PhWjO6c4YhB129ZKRduW5PRoeFZ6em5rBYlU
wbFoa6mCUrkeJ9ehUymVR5UXv9XWlCLQOBNU90g0EJ88PYf87zFaPvPuPKJSKkYe47KLtz30lrbk
Y532fJxckXr37sSzzPNmJVGqpJRqLA2pvIYGJFgOi2XnbgPpLmPOJfwWClurM4bANqEjRHpKUaYc
cHKe7DlkqUmCmynk00fSL6XDI8KdIOF6+cL1jQg3VsL19oU7LCLcGAnXxxeuT0S40RLuMCfcEOot
4Yb4wo2ScH2pK43nBq1BqZx6SdhyX9iREvZw1BHk1wleTT1N+3JDsw7uS0dAyJoSrMMKd3alrF3J
hbmXoftNFnMaE0wzSOdahhq6LQEVDHpmk33zbi5536ngfkG1z0IqkVwXih+3Bq1LDlNC/SCNEyEp
E8mKehkkMltV896SpKfDevhkv4qOllSrJFW/7PViHT0o2evaXcnCnSmSTxolklbS3DRKUY4/JDiN
HmnK2pe1bml6utO0Gdz39Rc6+KSYwog0vBZdQEejnNtzezQ8ROTo5u4+mkrpyAgpOVFqtMSRkpE0
GLQXJ0dKHdSkW6G/DrqqjtXkYY2JvsCdaXV7bd3h3kCNRlPl0kDQuivp1zfjTHxuU3nUYt4C4pxG
CH3HOKVK+WKOlJhVSZXMOuFkPrQw86N429p/9jDx3DjjJc785Hhie2KmQ5/KbC56d6YxKq6WtC45
KSLuSMm71Giny9+Nil8t8dclq4WHdaLf9T3HEvNu33qRmeMgvbuSTAWnxJ2Rn2PzDcfYQski/UYF
W09lPLzOGZTotu0O0DE1TzQkiYYk0ZAkGpKiaDvDpMm9W7ZJcy3+L6fBvlTvQDt6iOJS7kkRjYrO
lrSvSZ4t5V7utFXvLADuPYeEWm2rtFrNrSyW9vGG9vGSfpPTat30k3Q8FVEgKvpKjTtV2pI/LnNh
namVLuCETGS/kReZyiS0r8eTnAq3L34zYaXIY3dYouCfFoWtCmhlYxWeMqOfr4uiy0DLq7QneZnQ
MttIhNv2+A0KPjupAnZG167VbXlF20qzWEh4enUS72hJoEdNbOVBFttZ/Kugg/2p3O8Tuc+R/r/O
lK6AhompwxZdQ7qdVl6cT+F2k8zi+LlO/DpJYbiTgshPMLrJv0cofrPEH+GLPyYi/kQTf2IgPktF
Ci1X48dRP1pij8waLaFXiD2kFgq/Lc0pjoLMXp3jb6NNqpuymohl1n0XrVnieu+f2Hrm05VHsy1V
tO2SHNsANpN0nF/p/ef+Px3AdVFE6DN9pRtPsyF787NY+lkS9T0ZbotjOLXibU0Jz94LaJJKmoK4
dVmVxJIathhLfFqOa3+sTOFxj1FCvEmA6+axxDqpmy7y9vGKQL/ZG1YQ6Oh57f1ZvWAPSxe8siQJ
Wtnq1/jae+QRv4211ryV0ihxx2lctqM3UzpunuqZXnxSJdoMxoyjpfRezG7o3UodveGVm8eP3OrP
T16TNVVqp8rRxLY23HJrq+vG511vq84p3vbU21wxbG8PrLS6I0/eOfG+jszWzwRjGasmH/4Ox+Ji
dCWzDUJ2WUyUVv+ASGcBTQ/Il9fT9+BTwLetTRVvW/amMGIc76dqkPI/nsUUFpJ+IZTfWxkv2oK/
9WrlYRCdpPPxvCu957U9QMrx4Gg38jYOEFs5bAt4454u2cyvZZLLnqxloVzqA6XmGpURxnOSy+Do
XFzrRHPQPmJf1tkiR5PJnsi0kfSLEmz7n2x6Ih3XS68wQPqgQVLTA6QPGtST0ltPnFZi+rds7t9S
YoNtlJq2dB9DlSb1dpKm6LRH0ggewWSr1WQlKGg1calkdNiLOTCWpiLOwOyxwlEvjn1fieV4A6lF
U4V6b5IGwKf3vTuvGGM8bu1FgVHoYvnqtD/PKektVySSNoCqsidKDfjjjoyMPdWJXW5yLhcOag3Z
r2ltltDTNLTsJ2Cr7rFkXfa4iLxGgCrbsmyflgMrF5zHf2zV1WavE24WQf6ttp6H/thyR2OzVCTR
Ygj/c+1elL0e/R5//6PJSKX2425/PAK0ZEklC63Hk4xc+4PDOxLF22re7dGwK5kgmRnKSzQlEqm8
XO0ZqnSWYtqM1jZb+bNobOU3sj+fPUty9erQ1SdqGfJbZ5JflY64u8vo1x05TKXhkIdrsqcGZMhN
i49zNFvoNqe32Bo6+yV570YNja8szr49uyYgVW69KkW96BSy7wcchsRSeUxYFF3M2Qey1T7yaiM4
Mu/Cc1xs50z0SsetPAep5KAUnMrj2VUiO3b8UUX6DTqmZk66F29VNV9zeH6BpGNNpJF0Kji0x7Sy
qL5qlMjRXOmhVHfdI73LPtw5jksxv71rLcMLQE/WIMphmchXq2pcdo+G+4ScJUmdXIB11cYdn+yR
MaYVfifTwf0OowlscjC7ihxrsEuKloD2b2Rfk70EuRXHSpd3uhxhJFij0lGU4C6n57U1oP9qK8k8
y5kto9UhlJ+eC8hL93SbSUdA+XQq5OEhKt42ro0QpmtMWB3xzOfRVsKGLYgJO0rCLuD5oaQNWxgT
drSEXYiwJVk2bLeYsGMk7CKE3ZsOWxQTdqyEPY1berYN2z0m7AkSdjHCbs6xYYtjwo6TsEsQtjLX
hu0RE/ZECXu6tDcNW0EDuO/IYSu90BfWrzPJjM3YXvoc3Z6jY9DakBYuojPT+i3VtfoMstaGmmt0
t1gb+2TrWhfiLzTU0TngNn/JZDbaBNHFxDvFEtN2bmUp/yB3inW1va1QvtSM1JYSa6Lg/KunSw6n
s0iNBDG9uCXzhGTPay/lAlRe/HYbWzju4ItnIXWMcLtYYXloR83kffOH8zubvASLfHqJY59G81GL
+3JOI7Un27ejte0UgO/WPhyX3dPozD4+qqqohiUpt4ridB6nlEPLOCVo0WAavPm3hhayhOVyn5Dv
m8/1bMujwL1u255tK9r2GaiLYt43uitZk7e9ix4KTwXplDnFMlrEc6m5vE7DM+FbSN++V+v7PGLp
wCilakhyJA1D3iNzmcpsZ6RTAApEU32B+1+2zfNAb55U9FgdOeWOJdbi9nwR7lUaDL+sHe2PN5EW
IK/5uRMzrINRQmej2FaE9nsi+vK6XNa28X0565vDYIfYnpNIqq+yK3dbFF2HOjuxLlfHZ3wyzEqx
eAogt155jGXZx+0DsumlPKLWAqI9pURnjuMWlSQ95pl1AW9b5n19tpFxe+V1sizSt0tySNspEuGO
C3XFEsCSxLmTvFPO9Vsk3OV5ceYcl4N7ZB598ahYmz2/UsKvdBxBeih2P+JVJpYc7ncIvOHxK9FA
YluaxwG8TsZWO9FxJGt7NJhYNxIdTyRW5FDS2YlhwHAi6X1YUrhmuBdgbrPWZm3MSohXz3jOawmw
DOCx9QbgK6TvTPI7nT8Bfg48BvyG9BXct4AuYM5RwNFACTAAGAgcA7DZeSxQChwHlAGDgSHA8UA5
MBSoAIYBw4ERwEhgFDAaGAPwKtsJwDjgRGA8MAGYCJwETAJOBiCmNDnBp4gTTQGmAtOAamA6MAOY
CcwCTgFmJ7T22VZJCNrSb97oLxny5XBZIV8Olx3y5XA5IV8Olxvy5XB5IV8Olwr5crguIV8Olx/y
5XBdQ74criDky+EKQ74crlvIl8MVhXw5XPeQL4crDvlyuB4hXw7XM+TL4XqFfDlc75Avh+sT8uVw
h4V8OVzfkC+HOzzky+GOCPlyuCNDvhyuX8iXw/UP+XK4o0K+HO7okC+HKwn5crgBIV8ONzDky+GO
CflyuEEhXw53bMiXw5WGfDnccSFfDlcW8uVwg0O+HG5IyJfDHR/y5XDlIV8ONzTky+EqQr4cbljI
l8MND/lyuBEhXw43MuTL4UaFfDnc6JAvhxsT8uVwY0O+HO6EkG/C/iO+VxZE+X410vdrkb5XRfpe
Een7o0jf+yJ9fxDpe2+k7z2Rvt+L9P1OpO/tkb63Rfp+O9L31kjfmyN9bzK+XGfjKFhDM4ETQ768
/2J8yPcUYELIl3vniSHfOcBJIV9e15wU8p1HOp72+7LdWhnyPZX4HdygL1sHVSHfBcRv3QZ9eeV4
asiXX22dFvJlu7465LsYmB7yZetkRsj3dFIe+33ZipsV8j2TlMd+Xx73zA75nkXKY78vz6LODfme
Q8pjv+8yUh77fWtJeez35RWb+SHfelIe+33Zxl0Y8uXR1KKQ73JSHvt9edS7OOTLVt+SkC+vBZ0e
8uV3E88I+fII5cyQ70pSHvt97f9+31WknPf7riHlvN+XV1HPCfmeT8p5vy/PpNWGfHmesy7ky+Oo
+pAv28MNId+NpJwP/1hHdI4Z/jPHDPxZDfml5J+U7LNMyfgxlS3XHLnKXE4qT66yPJPqItd8uXaV
q3QeKfkKWUrmBFJFcu0u12K59pBrT7nKIkeqt1z7yFUmj1J95SofB0gdIdcj5dpPrv3lepRcj5Zr
iVwHyHWgXGX7bmqQXI+Va6lcj5NrmVwHy3WIXI+Xa7lch8pVVsRTw+Q6XK4j5DpSrvK1gtRouco3
H1Jj5XqCXMfJ9US5jpfrBLlOlOtJcp0k15PlWinXyXKtkusUuU6V6zS5ygRbarpcZ8h1plxnyfUU
uc6W6xy5zpXrPLnWyPVUuc6X6wK5LpSrfKghdZpcF8t1iVxPl+sZcj1TrkvlepZcz5brOXJdJtda
udbJtV6uDXIVnZJaLtcVcm2Sa7Nc5c3w1HlyXSnXVXJdLdc1cl0r1/Pluk6uLXJdL9cNct0oV0+b
sTSzLOuMiMX+tTaZeOGfTTHHepgW4++3OD+EuJKXATjdHJqY/t+mYu115lKDifcF4IvAPQjwfW6z
aILTgXPQCJcBH0eiW4FrgeuAr6BBfg0N8ddAEk1xKnAesA14BChFwzwOGImmOQp4DY3zWTTK3xnF
fD7wZ2ASGufJwHTgIuAq4KdopH8A7kEz/T7wazTUp4EXgGPRUEuBncCzADfZ0cByYAXQcph+s+Vu
NNnvAXuBF4AXgb8ALwGvAH8FWoFXgX3A34DXgL8DrwP/AN4A/gm8CbwFvA28A7wLFEIZjIUSOAGY
CWxE869C4/8GcB+afzka/1LgLGAtsB3N/XYgiQb/DNAHTf5k4BLgceBXwBPAk8BTwK+Bp4HfAM8A
vwWeBX4H/B7YDfwB2AP8EXge+D/gT8Cfgb3AC8CLwF+Al4CXgVeAvwKtwKvAPqANuBPKZydQAcUz
DBgHFEPxtAJvATuheB4D3gQGQf0cC8wC7gV+ADwP5EEhsVIqBkYCo4BFwGXAl4EHgX3A34A3OSxU
1wzgNGA1sAb4GTAQymwpcBbwOPArgFVbFyAf6AoUAIVAN6AI6A4UAz2AnkAvoDfQBzgM6AscDhwB
HAn0A/oDRwFHAyXAAGAgcAwwCDgWKAWOA8qAwcAQ4HigHBgKVADDgOHACGAkMAoYDYwBxgInAOOA
E4HxwARgInASMAk4GagEJgPzgBpgEXAacCawFKgF6oBm4FzgfGAd8DHg48A1wP8CNwO3AN8D7gEe
BX4JPAE8CTwD/BbYA/wReBdoA3gRPAfoAfQEjgPKgMHAEOB4oBwYClQAw4DhwAhgJDAKGA2MAcYC
JwDjgBOB8cAEYCJwEjAJOBmoBCYDVcAUYCowDagGpgMzgJnALOAUYDYwB5gLzANqgFOB+cACYCGw
CDgNWAwsAU4HlgKXk/Pbyoj26Z+BTyjWspCPjF73E+tfzmdpBmH279N7QJRPIuSTDPlkhXyyQz45
IZ9cn4/zex98ghxjevJCPqmQT5dAOulf2mf/dcHp5GcQput+wnTUpyiDMLMyCBP06ROSnz4h+ekT
kp+ovDqSe2Y+meTV6fP++KR/BxWrz4BZAf3DPtkhn5yQT27Ix68BOk5PKuTTJeSTH/LpGvIpCPkU
hny6+Xw6ZazT51D7dMy6iOphC0I+fnnOrG/KJMyh8pmUQZj/DJ9DY0Pu3+eKSp2fdcJk4JNPwR+n
088XhmOlf+LDYQKjgFCYcModL+nYDML8Z/jMzcBnRId80r8Poc/sDvmkf/9hPnMyCNPp0+nT6dPp
4/qMoIvJ+x4577pJ5vu/R37yIfoeuf0S+1ZZhIz6HvnJoe+j3xdBz6RDRA/TwfTwd9Kj6ZmU/qJ8
VULp+aGh55Ogh9fmpiY45McTPHOjX8C/H9c2ejTBY9i2RF/qG0HtOYYae7/GUGnv5wSo3XUYqIXx
v+NovVtqecWUKbzfofB+Q+EXQOG2/VL4WCLh0Dk3TWcXjD7MuNz8Ztfo/aRT9f5pc+++0H+3z/0/
LYeln+/u9/xtOZjT9pSBH5lyuKcMnOQrgXvWgMvd7YZ7240s7FqosrDLULg9wF3eBMHUXH0MUetR
HlV+WThJKOR1YyubwthuvN+mq0RT2n4uU3hKW3YW8/jkLP3QnncKAK9M8godr3I1jiN6HNL4LdJZ
3/6D9C6rrnQLuPDOu21tPNcytISoGsO5O2Tm5QE8+dpbbW2/xNPfIc5fi/kJ/75N+jsMsn0EwDv0
rgGWoP0tBYaB2FHAVmAbsB34InADcDPwd+CfQFfkVwS8AbwN1GAEuniArvkNA54Bfg98p5ToLuC3
x8EN9BhM1Ac4FzgfmIgKqgTeHs1fRyfaAqwY661fbQIu4LUfcGL5OJ5Z7neIkA3wX9K4dcZqIDh1
DNAFUtgNuP5Y8Ay4DxW+BxgNOhcAlwMPmHW8bIfuc4HrHfo9uo+IgaXjCENLHrW19eIaOsAzRQfS
FBqPsaeex3sObSQ+k3MtfKLO6x1Nq2gF1cupsHyvoAZ53ySYq/ltJdMjhMcm6V+nz4fYhzL8bQzg
lgiIjsrGqOVE6JPriV57keRMEf7O5BDSuYELiPtZ3RPGYa+FMp2EZrOc9yWUQP8MI7oTXQdvBPry
eKLbgZeAb00g+hlQ/VGi+Z8levNKolk3E+29m2jkE7g/SXTp80Q3vUC0G1iIvJ/6C3TBS3oWIp+H
x2ei8blYfDbSSHM2Bn8nn7+Vfo/5hnVf8x3bEvN9TChz3544ux8O6iO9F5t3K/FeJd6pxPuUNgGb
Af56xUeACwGQTR8DPk7K9E8AFwHbgP8CfgjcD/wIeAD4MfAgsBP4KfAQ8DPgYdK9dI8AvwCYhy9A
370M4naAiCdBxHMTdC8f98Dc34GVske4rY1nH/OgJ/gtMv7a0SZc+W19fWONz/jld7EOVIN1k7Nk
N4i+4i8T6duCdVQn75ZlIQyfCZpEDudJ2gdyvm0CHM+T9zD5Owv83vl56ElXyTtr5xKfej4ZofQ0
Zj0juUlSYjqKaDbyqk+/kTYNvmvl/bwtxOcY8x6OEUD1GN171HNJr7beW3mHFe+d4j1TLNE9B3yx
7Utb0UW3LpNlu9xW3gOX7K4rvJ/Ltm8HaV3w//YNZq7DX1KitXuS95fmtQ7iZ7kjP7Vt8Nd2bNs4
dk3b3QU3Lv1rGzWZCbo9F4nlAvnSsFnZ3b//m/MuWXxd6Y+6vLj7H3N+9pU2evJMDTtrZSIQ9uLb
3vzdebubH54+aMhlv9yx6vY2usBME/9/9q4Frqpi68/hwOGAwAGfKKioiCiK3ERFQEVAQCQVFcH3
i1BREdEQfKLSQ80y81VZUV0fX6WpWZa96F5v2VcZlZm36zWz7pfXrn1o3cyyy521Zx9Y+5xZwOEc
RYTdb9r+WXvNrJk9M3vN7H3Wv+Nxy2vzM/tN2T9j9LQllzYc/fmTDREVbJS4hD26x8XiWn3uiYSH
Rx1+yPjNsKd6pbe/u4JdUTcMH/3CMl//t8fv2tfqreL0tQN3r/2l/dcVbJv6qnPDBPGGarR6rYvL
4wvPPNvp3MV97WYPjGr92E/7eDuoL3I2nLfMt/U9UaN+fCRtxkT/B3Z999SRwxXM1Vdc+2O5uLaq
fY8dzV5zKfT77eybq04d1l44U8GK1PY9d0bUzUm91vrQfMqmHHnqta6u3yZvSI4f+05QyKDLJSlF
sd9XKN9Ew7Fprd7i2mnPfJPz+7aCD31PvZFl3D4dXXtNvTaGdbgMd1t4rRXKN25XuaupMzGncvhI
MYAZhUPKk4uRKXRYZpda/JRG0GFZHmY6LPD0lepChhd8wYsVGcI3neBnBjDfy+YCnJgoIN/XhgKc
RQFwPTjh5rUK+L1M9fGhNazXKh/oBn3FZy8dlCpWKfyvqkcOh/Cp/Ziw6ZCbKGONrsqmcr1Y5QXw
yqxqV2UTeNaQbRdeNnzpy9cROvM6oisL5m2yO0CUAec0fnUaXx9s4ePk00Bxhr9/2lyc4ds7kHfr
KORwhr9ndRbnVxN5X+W+88EkITefz9/J2HfcLc3hS5y/GcQ6ZRU3ryJN5AfnL1LF+Ty/xqCePfl1
v/O/v8P//Uo/kQ+cId/fB4gzfA57Fy+3Nz+/xu3owud8IHyF68A+zwhxhuu2+YnrglqI63o2F9dB
PeE6OMN1TrwdzkdWtYs4vCtXNpZcZw+yqvXS4+qKzsy6VsTgebhe+bv9K/pz/H8lMCvwmozyrrJE
DGjzKm6AlVU7JVZFcKt2Oswq6H1gFV65d9ZYFaH03gynqjaricEO1nN6c+9ljrI010dYindEZHfy
MUmbRfM2e8whbQZ1lnHXhSnXmNss2sqqJyRWRXKrnnCYVbIdrE4aqyKtrHpSYlUUt+pJh1kl28fq
pbEqSrHqKKuaeXd5VO1jga9pPfOWKTtD1e8PXVKf2FtVq9LVT0smjxTnRepe0AfqzksfdQ9phzqB
m/XNtSk1iDl6U3NxNtcGEtRgC6uqwW5egzXu8IucZuUZTFaDEzrwrqg9OHxMG6s9aw9hG9gEv/+H
c24Ntu1RW7eutsWr7Wk+n1bvvvkcb9ELzLYBpQecq7Ntr5224aM27Wa2Cc6ydsO98n8c0itbqr3Q
vM9XrOJ2aq9MUXuleT/wN/Xvp9ReadbHNVB6ZaC8V+Jdy+c8rHcth/HRDn+3ZkjF7WoeQ1vVkQ9j
xnw2/x1bBX4NjPhSk3aWFN+ImEf+MCsLn5dYmMQtfL5GC21lby1rLywEzwtb6KqxMEl59gV7ibZc
ijy3GD47lMFsGyL2Zc3Pvj8hz+0OxXMLqvTcAhXPbXA7YQecT3Gf8F5/xuZxrdfaizP8XW8S59jW
Qv5XXyGHM/y9l5849+He1FV+/nWAkJvPHQYxNoEPlDeHcAv4LDw8jq+oOd4Wz+c17ill8cl+LD+v
T2bsBD/vTBF/h/PsaHE+Hy3kgOH6oOFCfxuXbeT5neUYfkQLcigPzlD+qThxPjdU2AdnqA/IoX4d
Y8T5pwRR/88TqtpDHMJjE9Mv/ZzfL3l2JZLsvrY+uxSOXJMYX+eQxya+CzH3j0Qrq16UWJXgUKug
15Xy0S5C7girwjVWJTBbOYcPeFTHOewIq+HHn9CWNXEOH/Swfqc29Ab6bdr7OdTKnkMSe+JvoMem
tSfeyp6XJPbE3UBfTWtPHLN8o3fYo6Y3etRTEferG+OxefM6mfzE+IUzrpPlu9OXVY+Nfndq7XlY
jwx81Mb/AMtg5aXMMDVY+AryP+puoa3em9nCkjbaNaLMwiMOsRAftWlDs2VwlrVhKauy8FX1Ljui
tzrakzPbv6mbtrfCCtrST3pN4ifF1orl3lZPDvwcmLPhaYM95L7KNeZ5IdbKwqMSC4fUykJbPTlg
st/kJzwx/N5ea+EQm5+Jr1f7TGTMvvnWu53qYwTW/Ex8QzLnx9zAZ6L224IYK3uavsPB9jR9h1N1
NH2HAxbGMkd/hwNv9RrHdzjw+3P4zbn5d+bzecrtL35LDL8hdtz3N/Z/e2O2dRpPO5HNVbZS39zc
ut/bNJXaOEvto5Yq8Cj+L8FFskDhQJipMCzcpTBNBDDgnMhXvnGAbx4CamkXxF3ObLKrya4balcF
W8Wf3PkDRwyvMFn+p2NFXFa+PTBNJlvNZUY3980y2Roue+XF4hdksrWQ51Cv52Sy+7nsTPaHfx/C
rGXruCwlxDBYpscf2RXe775wsMIEcZydkTZj/FEuDoleKm+Xbas3zapQv5ipOnQsN+EJ5pH1ywCZ
7M+J/tzHczPKZNvyx+lcmJuzTBY66aTOk5C95TrbyaTIrO08kLnGyY3QKwjc5UTZ8pdhbfTNCL0I
z5H6sy/+sl4m8+lzBPSkeV6be1lPlddrwcPOVx75oZesDgMX73Cm9EZMcnKh6n7Be7lLzsnAZJlM
lzjGQNl56I6/GcI/P5shk33Wc7GrjigvZ8ZGVyrPmPR449n9hy/JZH+/c6KR0svu/4ORqntobp67
c/aU4zJZgudH7jri/t3T87T74g9GbZXJfN3e9aTqt9U0zUTZ+fmw502U3sEQX29K70D7zt6lpnHL
LLXgo7WtKz/2FnW3znNWVLgPVV5K7yhStjFiBymbNeq8T15b76UyWWCrrc19iPb8y4Jfmnc4EDZG
2l+G+rag7l/C5OEtqDF9eFxui5LUpb4yWc7cYy2oe7szrqwFNW6Xhwa1pNpzwbJ+rUyE7IcWD7ei
9MYN/Vcr6t4WjYlpvX5mj1Bpnx+xoHXgmWcmymRXF+1oTdXhwZyVbYJP/2vKUKt5nrFdOe+0GXHf
2XUyvY9jevgm+P8cZF0HxubmnPKl6rC11zXfvOcDX5ba2X1z24yEP/aQyd5s+0LbZy5lnZS1WTOX
V9p+et+JJJlsddcO7ShbkqJ6tos5tHytTHZv4ZvtSq4ElshkEYPn+VH9xecPH/lR5T0ccd1v6aPu
BTLZXN93/alxNMfJ1J7q8wXOU9tTeoZZee2pMfaS75aAsJzA72WyDk7vB1Dj7+sUn07Hrve4KJN9
l9elE2Vn38jIztSzeHP3/C6U3uu5y7pQz6OufV/rQrV1yZi4QCrPf6xMC2QhnaX+xP7p6YH5JwIe
lcmat5kfSLV1UdI/A03UPer6165U3QtCLnal6ndZf60rVV50sDHo/CvlG2V57lsQ3I2aX4oSB3ej
ytvseV+3878GHbeWMeY/MCf4OX//30ZZFsfLOzvicDDV1iEDrwZTdfhq3pDuVJv9I/dk9wdaBm+T
yU5O3B8yYda33jLZ/J5nQ6g+sXzS2V5exbMHyWx50D0xlLpHsd1GhFLjfXfBx6FU3dOc5vSm9O6L
Lugd+MKDX8tkHnet6n2s4xt3y2TrZq7rXRJd9kdZHb5YtLEPZUtM4dk+1H1/uZ9vuK9PdqJM76G0
sHCqL33ryp0G6t56Dwun7vvLU/PDR7udLJXJMgZd70vVYceKiAgqzy89J0dQ9/ao1+sRxsezgmR5
Dk/+ZACVZ+TyLyPPbY0Mlumd6XU+kupnH6Q3i6LyXLSwbRTVJ7K9Hor6Sb+pWCZ7etEnUZTvncla
RlNt9kXQ86TMM/HRgWRbt35uMCX76q47hlD1W5VVEUvpfZMYFEfJEsakkbKQgE/jqPLeX6SPp2Sv
RmaRsvmx8+Op+zen489Dc2b/X7ZMtsn0QYKJuH9PmIITqTrc6fVWIjWOHsn+ZyLln2UMWZ2UMvOK
i0wWHttmWMrB5U/LZBtnXRxG2bm/0JBcvmnlHJnspd4JyVT/vBbxhxSqfrFzH0uh/InzEx8fQbV1
b/fHRlL36MMh742k9C7PyBsVEdZ5qkymz/VIpfL8euTE1CkbDg+X6S1kEaOp+vVzXTeaytNvgutY
qs38+o4bS61T12dOTaPyLPF8lpTtydiVtjLW6CfLs0fLE2nM+9yv1nqMbRz8Xdrh7c6zZlqqcb38
xe7jSt5nqZGS/Z6n+20fRz0bR8/pmk7164VOeelUe14e/lA6NV93Gbo7nfJbEyPbZFC+ae6UGRmU
LXsmxI8X/dNa9uL8zeN9s4/vleXZcXnIBGps7so8MIG6t636hE+k7t/ZuXGkbEvB5MmUbHpS2WSq
7nvn3zmFGu/bddOnUHm+5/SnKRfm3PG2TK//oGtTqH7t4x02lVpr37vqs6nUfS9a+tz0J9/e300m
m7P4yPRBqaXfyWRJq36YQd1bj1SvmVR5m+/+kpQdaxOSSbXLa93TM3uc+vlzmWzw0pWZVJ778p8i
84wc9WsWpbcs6uosyj/bwU7MpureN/bybCrPMdEh2ZRshn9WNnVvX9QXZVN9PnHJ+mzKzsdH9py7
uTBLuj/R3uvEXLHWttabNOPkXKrNBhQmzKNkVxZMmP/z2JLVsvJCuq6YT+nF5wzMoeoQFflpDqV3
b0r8ghmHTkmfm2P7L82l9GaOPUnKPpvkvpAatw8s6bqQev5dGZ25kMrzni7/JmUF7TrlUX3Cq3V4
HjXPbzdlLqL0vmDbFlHz4GGPuYvvv9jyiEyW7le4mKrfll4/LKb2lxLyvr17x6xDLWV693QKyc+9
741omezO+LX5u3f0fE8mO9g7aAk1HhLnjl8y6McLoTJbUrN/XEK1S5buUgElyxjvXkiVd3REdCFV
94dTYgqpezs5b1chuS9siFq6f9DRh2SylbP/dyk1HrbdlbKM6hObJhQvo+p3KvrPy8Qaz1oWFvAu
mefJEdnLqTxZxOrlVN0XL/tyOdWeg03hKyhZ2xETV2T0Wd8/2VLEZaX561dQ5S1s8exKys73BrxM
ynTq2eqAL32Ly5x8inf8pxWwg5c5GeD7wlDl2jbW17NmigawLKsaRlfDSO67p/K0IJgBNXH1qiUu
laolLrapRjhXqkY426aqraJElW6d2bpK1dm6WrWOVsOmwsDOsN+tbwXXqPz8tfIwMqZcyZhBr15p
vtalmmtd1GtDmVPV9a709a7o+lCmRzpupI6bhU4oc8Z6zSi9ZhK9UOai0fUkdD0J3VBm0OrjAYL0
TdXohzJXizx8pHn41JBHqMUHgJaHTiE3t6tz1V7VyFWNQnWPjar1UypSvX7DRy0qLL9eWuf07V6q
I1Vt7wkK9Rs6gK0cRqepOEgPGnb2GVvbsd4H42n4EapU1aSoHueqEUL1uM4Ql+zNNOoXGlpHv4mt
XD+qt8hUUskcg4ZoK576GnX9jCwuOZj3Iz1X0oOSG4tTAjnlKoGg8lhApZa1/xOmlB/DPaZS4THF
OBlEpv2NbICRRRlZtJHF9tDFJfuzpB6VxYzpwcYaWYZiZE1+UyeJVybKGGDUqVmb863MtDYOlq+S
8TQ+05RcVzKeplcztsiV51dbB6yVkmc5z9Nb5FluztMiQ5u8MyXTIu56F/2mZFrkbLuXpuThzT3/
8l+VPLxd6uatKfnACmKayIevIGrjtenNlCO4CypTfZjBp7jsmrQrNmNDeDfMVaKIZbI5rIB3RiOL
tPGJ0OBmDY2quFD7nIRDr6gm8Z42Sagm6Q2KSuVotVKhHsbdGYTKoe3Tjj3N/FJeL7Pa9Yb3YLez
1Ju6Nm4szpZo0sp5qepQVA9w1VFC9bSbQTYVMXUqku4MSJ6MNe4QSEZbrXYKJA+yWu8YSB5Yje3Z
JN1R8K56Nil5hRlqtbPgAAe+DusosgP66is7sa/e4MzMFai+Cx7nt9OomulsMDBc7eo7YSlvsALR
eUsNBiOzbLDqu+GrRp/iC6Ibvmo0uFtpO2tzkHTEA+4+xRkihwPuBg9pDi4WuVh3xb0ePsXHRXfe
62HwInMxWOZk3Rm9+A0XOZV4GbyrzcnVKjfL7njOu7Jrn/M2NK8xNyOz9VlwGywJY7RqAfyPzRRH
834+sZ77j+MeH4xQ1UtUFZVedb8ZDcNtafhLe9vc5jq3Tnn5TfO4G9wO8031fRvcrmsDbNg9t/IK
pv42wJ2q1WDMp1h9pzW7dq4e0iir7VoD6dT2raREz7a1hlbX9rWGVr9uaw1tHnVfa2jzsW+toc2r
NmuNRjBIbpqddsyr1nsKMdoqOvi1VmN6a2LHvaiHx85NfaA62E5i1VIXR1dTHrUhIlSP6/CGiF1v
Mx06Sd2AEdyQh2FD/SKh6TY2qd6uqo7cp7n9Fmf1vpF5+jZtWMe0jh27WI3vm7zbvBPd1G/ebhXP
hLyl6LXzAZ1BV3klte2j3Sq+aa+YI5zr/oq5xMW+V8xG11vnFXOu8aa/Ym5gU319blfUfgFg24uf
Bva9VP2UepO/Zr4FZnY7u0WTsyjvSLZ+7udo74KeRUTJjXMbwcZNRFs/frjlHbVGOCYduZSq94Z1
2Gc6t+dQburkN6N1Gv4ee53qatea4AZ5lSZJyVbq9r8btrkz0Uv/po975UtlnEvTx7231Ni1eyq2
6FnM/JM7tG1mdDU0/bCx6YeNxOCpYUjb88PGykM0FtrZyzXKu6S79AeODdIPaHqwNT3YGvaD7Zb+
keaNdp6FqtZ5tms7tjF9sNhoVVtz3fsraQfFsdYCr7LA6yzwbxYYAsRiDAG+Mf6Pev2W1GVGHcLl
FjhltBbvVbFl+Zb2rrHAqy1wkQU25+88RuQPAXWxHILPY2zZXkCugzEE/MYYiDowhsDJGENgTowh
SDfGEPQSYwj6hzEQ/2AMQWqrkwORAMYQYB5jCISKseX9B4IUjIFMBWMgq8EYAtFjDEFRMYYAsRhD
YGKMgXQFYyBJwBgCdGMMwYQxhiCQGEOASoyBNApjIEjBGII6YgwEPxhDIHOMgfwBYwiSijEQK2AM
AYcxhsCpGEMwdIwh+C3GEPgUYyAWwRiIfjTykIsa+yBIO8ZAVIAxkAjJ5NPU8QJBS7EcCAQwhsDI
GENwRowhOCSGQKiCMQTwxhiCImMMQfsxhgDcGEPAVYwhyDjGQEKDMQR9xRiITDAGQhuMgVwEYyA7
wBiIpDAG4iyMIeAtxkAEhbF5fpqntjcQH2A5EEBhDAFtMTbrH1f1IXg5lgPhGMYQqBRjIEjBGMg/
MAaSG4yBzAJjICvAGALSYgwEAhhDoFuMgZwGYwiOjDEQyWEMwe4xhmDmGEMwZ4wh2CvGQAaAMRAq
YKyQ0KADyCYwBmIRjCFwPcYQuBRjIJHDGMjMMAYiAYwhMC/GENQaYwgsjTEQSWAMZA4YA+EOxkAy
hzEQd2EMQcIxhkC6GAO5AcYQ9BdjCLqPMQR51Vzv+ZG2/uPdNf0RiDgwBlInjCEgMMZAOIAxBI3H
GAhrMAaSBYwh+D7GQHKGMZAuYQzB3jE2j7/AsVp/psgCn7HAEWlavEXF5vm33EJ+3QJnjNPiwxbY
mK7Fk1QMRCAMHRCkHWMIoIsxkBliDEF0MQaSE4yBdAhjIIvAGIIhYwxkURgDSSDGQN6IMZBBYAxE
YhgDOSHGEMwaYyBExBgIRzAGEj+MIVA9xkCEgzEEW8YYiOIwBkIajIGEDWMg4cAYiJIwBjJCjIEo
EWMgNtPgPkc09wuClWNs7g8H1P4A5FJYDsH+MYYAzhhDgHqMgcABYyAcwRgIzTCGAP4YA3EExhBo
GmMgO8AYCDsxBpIWjIEYAmMg2cMYiAMxhqD6GAMBKcZAXogxECxgDARqGAOJEsYQcBtjIFrAGMj8
MIag7Rp55gFNfYBQAmMg3MQYAtdjDEQnGAOpIsZAooUxEM1gDGRZGAMpHMYKsQk6gIgVYwhejzGQ
lmAMQccxhsDmGpw/TnM/gBAMYyBxwxgIAjEGcj+MgUQIYyA3xBjIHDEGUjOMgbASYyDewxhIuzCG
wPcYA5EdxkAqhjEQkGEMJLv4ANJWjIH8AGMgoMMYCIcwBmIRjIHgFx9AmooxBKjHGAgtMQbiJYyB
LAtjIMXBGIL9YwzEkxgDeQTGQF6BMZCGYQwEeBgDuSnGQFqDMZAvYgyEpxgDeRrGQJCBMZBTYlxR
w1GSuswYwMTeo2XwG/hSTQS/EdHXLbZvQP16NeoBlerw4scqdg6oZ4y2q/TDNqm7cXU3rC47vMfU
McvBNTZ1Qzqg+uBn1Hxl3Y+CWjW1oBuQ3Hx8nHRcVrfbETbWriH2QDXqtRjgF+wrPT7NrgFeUld1
MZjxIDCOs6uHZdqnXgrqZeJyS3U4wAWPSw5kI5Pduaq7UJ2nqLZMFyVXrwrvlZ24qpNQ7RwAqrPT
a1NqmEy1vo83lFpvrqG9xduJRjYh1MNh3XWajkZ1VMToi/jarq9Ix8YPcIMPm3LUnQrz2SncQ/yj
H0+wCoM3M0+7MXaEJ09/vpjtwGU89edpGE8XeCrnqVlHxq7z1D2AX8NTAk+LeMrnqYCnQp528rSP
py95+oqn/+fp3zz9wtNvPAV3Ymw0T2k8ZfB0N0/5PD3LUxlPv/Ok40tpF57u4GkIT7E8zeepkKfl
PK3gqYSnp3l65r/tnQ2cT1X+x8/9zYMZxJAm4a9fVpoY02AwZDWYGeN5mJGHbBkMwzJjGaLaVq2t
Vq1s7Varp0m2JJWkh7WSSlYlSVhZSSUr2RappZT/53PP9zfO7zf3mCd5ao7X22e+9/zOPffh3HvP
vffc7xc8Dl4DG8Fu8DnYw3ngFrU1uAbcAfiI6WWwArwN1oF3wSbwKdgJvgD7QB3cnl0MWoB4MARc
BYaBX4ACMBHcA14H+0AD3IJeDOJAPGgJMsBIMAr8EtwH3gAHQG3cotUBiaAtGAHuBPPB42AB2AQ+
AZ+CnWA/aHgJ6gADwc3gGbAWvAMOgwjcCsWCbiAdTAZzwf1gBXgXfAx2g8Mg+lIsC6gLzgNdwXhQ
ACaBO8GcS3nTr9SzYAl4DqwC6wEfrX4JDgGnORoYqAVqg3NBU9Af3AieBCvBB2ArqIbb6ljgB1eA
8WAWuBc8DN4DG8D74EPAx2Ifgd3gc7AX7AP7wQFwFMTHY3+BW8AC8Dx4AayO54sZxc9cVEuQBjJA
DzAVPArWt+TDOmyTBFzRQEuQAC4DyWB4a6VywH7cHn4FDoNvQRQOrmhQHdRrywcuuCkFTcFlIBG0
Aq1BG3A5SAfdQQboAQaCK8EEOYALQBMcpE1Bd5AJhoKrwDDwC5ALRoNrwd3g7+B18AZ4B6wD74IN
4H0Q3R7LCK7E7fMgMAQMBVeBTHVDTV7J+6vdonHnUDNVyjnaXnGhtvdcqO17UrW9K0PrbtE9GTq/
Vg+tvXtqHSZ6l2hhb63rRHeJRvXROkI0T3S8aL7oUtHNool9tXYUHSo6WnS86CTRtaL+flqbicb3
0+sxWuw80ddEG2VqnSp6o+gtojsydfkfxFb9tV4pmi9aKDq1v/79crFXiK4UfUtUDdDaVLS3aF/R
TNFbRHeIdszS+ifRL7N0fd+IfUi0brbW+qINRJuJdhVNFR0gOkz0IdHV2Xr+G8TeKJowUE9vLZo0
UE9vJ/ZQsYeJLhD1XSnTRReLrhZdK7pRdLNozUGy3KKpogNEF4lGDtY6XHSu6EOi20R3iaYMkd+J
rhJ9S3StaLOh8nvRrqKpoleLLhFdK9rsKq0zRLeK1humNVY0X/QW0QWivl9ojRIdIbpYdInoIdEG
V2vtLNpbNF90tuhc0SLRx0TVNVqzRYeKDnc1U80V+wHRIpm+Xewdop+Ihg/X2ki0qehg0fHDdfkb
xZ4hep/oXNF5oqtEG+donSa6QfRIjp5fwghtJ47Q9iyxF4i9XOxvxc4eqe05ogtFl43U+Y1HafWL
Nhml89uJnSzaUbS3aF/RbNFholeLDpf5XCe6UTQhV+ttomtz9e93ie6W6VGjtTYRvUF0s2jkGK01
RWuJ5om+JtooT2uS6GzRhXm6vs2iW0S3iu6V33X6lbY7i149VU8fMVXb+aITZfodorNF54jOF10i
ulR0lehW0W2i20V3iH4iekA06lpdb/VrtV1TtJZMbyZ2nNhXig4WHSr5K6fJcogyqqy73UQTp+vf
txZNkuntRNNFM0THic4TPSDqu05rpGisaP3r9HwbiPpFm4jOFp0jGvdrrc1FE0QTXeWg6O6xc/Cn
zxcZFhEe4QsLvzXoNQ/6bKLZaqyaoHLVZOVXfaHXQgeoAkzLURzJ1Bbz8amICMfnVIv0FY/4Nl+6
zuB/WWo6yoxASY6XatPMrb1GZLiPyVp7FzUJ9efoMu4SF6cSw9kDmdmqh+qj0lAjemduPXVVvZq/
dvNtZTLw+964h0pzS3dDvejFyjJWD/c5ZVtGv+qK/3PUSMV3DO1bBS2vte5u2CZT3HnwOxmlOsie
CQ8PC3OcqDBbvd1R0yQwAeX5QQPWNtLdFyokldgXg1BXvhrjfgRB5RvKtk3KtrTd3c8nctVU1Iye
t1uj40Q6OsmPStTYx13GAlWIVsAPMPzYOwVY+kK37iYqHFvxtvrotfvkg3+V3LJVetLXaemzD6al
p/iaRiq1DG2rdjyXhG+swlVYjDlyQ3/5E1iAi0IXvypVKLVO5M68wG1dfK/asF1pJUpPujkfPRp4
T+egNehUC2cWnlXGuf/nYHov/M82Wqjy1Pk4Sgei/WW4xzZbUD+VjuN1ENrOAEzjlCEgG3/3cY/+
qnT2p71/fVX9SkWHKxVf9xU9SZ99MGX75WxTI8aNGFfYojDotb9O0eGx6oYHcD7pouF9+peY/lTI
73hTyhPKUSPUuO3vQAoaVaaaNdTwzNUJyjHYi+J1nqnmWIL1Mj0uo6RyjNw0KH8yH8rb98Dvk44q
NQcHWdNeur6Oopm9dH6oDhvjrZsO6GP1nwe0XRbl8q/CZeAgluelMEdxbMB3mN5BnlSaKbDegfpC
Ewd+cmzD4DHuziyxfN9JvTvztGY2DNFeKijRXsht3xNNxDlWLlQ5fz424Xz4hDUwn2Qs7wBjvpsO
KM8U2A8BLbFcIWpubyYuR++IY8uTiG7WLvz2i81QnIRnXqLUUmyQWfG8clY8BeoLrM/uHro9Fa24
a3/Pt15xuPyDGx5rd3lYHo7lem8f9kdIn+TUJXQ/0FfC8enTSxUB+M1XNRAFokF1UAPUBOeAWqA2
iAF1QF1wLqgHzgOx4HxQH1wAGoCGoBH4Px8HkSp1IfCDi0AT8DPQFFwMmoFLQBy4FDQHLUA8aAkS
wGUgEbQCrUEbkATagnagPUgGHUBHcDnoBH4OOoMrQAroArqCbiAVpIF00B1kgB6gJ+gFeoM+oC/o
BzJBf58eRJjl00f79/h7iE9rgKHymwBXwx4mvznVifci7Ff6cdVnP2GSChqPWmqKVRFOYF48x0ey
wSCt1NnuYKjhTRrfOujNV5zAkfEL/GSldLNT0UMpdPvCFUvVsdXN9Sm9BNqs4sBCnQa5/ehRWI4C
3HdMce/VuB3Kmhoon8NVKU/9A7D+vG4yRaCnxVonuHcj03H3lK9Gu8s0wd0yY92evz3FoX5ucZ7h
y1o/R7Qtlq7+TdCbwW/BTPA7cAu4FdwGfg9mgdvBHeAPYDa4E/CO54ej5U8PodzDoAg8AuaBR8F8
8FfwGHgcLABPgCcdfWeyCP89BZ4Gzzh6HZ4FS8BzYCl4HrwAXgQvgb+BZeDvYDl4GawAr4BXHb3N
XoO+7vDKq9QbYDX4B1gD3gRvgbcdva7vQNeBd8F68B7YAN4HHCq7CWwG/wRbwAdgK/gX2AY+BNvB
R2AH+Bh8Aj4FO8FnYBf4N9gNPgd7wBdgL/gP+BIccIJHS30Fm72Gr8E34H/gEDgMvgXfgSPge/AD
ywKesGo4+v0nj122IbZljqjkg4gopV1YsL3wmQc7Ify6h19rs8fGjiKPJd6JcBQoe2XnKd1b4ihe
jmTkXQ9HCPJizS+dONqwMbgQ+MFFSl+FOYqWvR+OXuWITY7CjlN0X4nzP2D3U15ZKY545ahQ3Fyp
VqA14Fc4HKnId7uvA47C58hIfj3EEecchbkKdAZvKN1H9WycVem0T09j3z0DFoNnwRLwHFgKngcv
gBfBS+BvYBn4O1gOXgYrAO91VoJXwWuALxzaQ/n11mrwD7AGvAneAm+DteAdsA68CzhW6T2wAbwP
NoJNAB1N9/qyBXwAtoJ/gW3gQ7AdfAR2gI/BJ+BTsBN8BnaBf4Pd4HOwB3wB9oL/KH2P9V+AjqTa
D9gR/QocBF+Db8D/wCFwGHwLvgNHwPfgB+BeKBwe76FXvvJdj5Jx/TH3jSpD4vVqvO4mYBG6uU9D
J6p+aoQK+vagTKku5sZzFc9ZZa2fKVCTrjUXW6AQd4UF8ny17ClWOaWu/77Fn2Wkod8TUDMvUWVj
u45ArbleRUtNtbD9OUOeq8u6/rXca4BejFaVr7/c/a+1qDohPGgzVCqVt/4Tnc7k+rkX2K853vWf
13Tb9Z9lzes/7VhVsX5hVTr56ZXkFU4KG8K2p9by3ixM2gSVbwyofGtgeyHA61yqJa/Maf2be6Yf
Xrauzh03q4Wq1xN81uB2INnwJrsXHrpC04+1U/D3ZPxLgOa7OtK9gOByGjIXdv8muA/Ax+PkXoBu
YNnnVY4Up7oWbx1TeSSxl8teb0UXg+VP3HnSKzk4UsOq63NI6L07++99xo6cVDC5YHShf1DBpFH+
1IKRUybk5he69wR9sjgNk9wzAf9OCOQnJKuDHZYEfXrnnX44yvOOr8R0TvFtemfTAwkNY+6+N0q1
iD/8NNtZRMi0FEf3a3hu4pbiQz+em+gVgHtgjtLns/uUvlcpUrppLVD6nMY+JJeefUWew1Yqff/C
vh/Pdetl3ttlmXaG6/sXbpuMKWPycif7s7B1rs2ZlOvPmj65MHfCZHfv8/l1mMyLyjc/1FbnRbn1
KqnfSxvH6HVhfX5VM0b/xVq5JtljC8fnqsBxGu/o8zZTnEwbIGX5pSR/t0Rswv12TWaP1Gu6D+yR
6ubWDEzJ6N2jb6+s4rXsAuW3uNejfXfBfVRX3Gel4x6rFe7BuuGvbioNf7XCv1R3WjL+T8QvW+L/
RNxTJqJEIu7LUvHbVPStWyn95TvnO1HWJcy6/7keO3738IHD/fJinvwj9vUlz33A+70Zjt6PzOe+
Zcn7lF7P+UpvC+5T7nvuQ17H2C/ntYz9aV7P+KUvr1n1HL09Eh297Ts5emtw0B73PQdr8VrHQTNs
U3yzyrYy0dFthYMZzDah99dk92991Oq/WXZATv64nPwcf6+csfmFeerYbzCdf7P+vgWTJuSMTxhV
UKjyi9vYwO4ZaVn+rH7p2YO6DEjzZw3Jyk7rk+WW57q2bd/O/ZvLE3KsJiegc5nCOrZccD/vP9y/
F8QtS8J53v176fwl7Ab6QBjbEYgADORSzdHbKVqviHt+WOgc62vUdvRbgDrcltwejt6e5wE6Wjof
1AcXgAagIaDriv8DjQEHTvrBRaAJ+BloCi4GzcAlIA5cCpqDFo5u6y1BArjM0futFWgN2oAk0Ba0
A+1BMugAOoLLHb1/fw46gysAzx1dQFfQzdFvgdJAOuju6HbAgZscpNkLcFAm32VxsCQHQHJQIwck
cnAhBw6yvXCgHgfdcUAdB8lxABwHo3Hg2oOAA804WIwDvNiuOOCKg6hGAg5e4sAkDj7iwCK2t7Fg
HPglGA8mgHxQ4Oh2yAFDk8BkUAimAA7e4cAbtk8OjOGgluvBDYADWG4Ev3H0sVTaW+AmOM47qmHu
9am9ukZNxZVpLI7fYUCP1MjFVa2l5CfhqjUGU1uKJqhR7t1led89V9X6Y9faRmrVdib+6oL7fvZP
Brh3wwVYjlz3CQDPaDmu5cfU0fi/bMuVg+mjqpararl+1OU66rpsm/rzvr2O1g7957ju7/bd23Sg
Vx5d5UVFV7/LK49u9V54ZuYirzy64NuXVmuhVx7d5W0bt/bDLqpkHl359W4ReYVXOboVjFm96Nmj
tX3oyYQbpY07aY9ydFdwz01zxpQcQOG4rhJqjj7UwSuPbqQcFR3llUcXExEqOtwrj+5AzrHk0bVc
bTev5HLSDUa0pRxd2tiWhe5NaljK0ZXU9mcOzfLKo9uXGpZ50oWPrT66Bztw95ctvdaBrqJs5eh2
0LbudJmYv7FpT688ut+xLSddWyRt2j7YK49u1RxLfXT5Y5sn3aNsf3rpf7zy6GrIVo5udmzrThde
4eOuXuOVR/dWjmX/0bVG4duZf/bKoxs52/rRBZBtOemu0FaOroxs5eiGbmXtK68PLUVfhXTxqNe9
5Dzpjs5WH10J2vLoptCWR5cdky6Iuc4rj+456li2J111NV6cmOXZXtLqn2vbf3TpYzum6d6lqP91
9b3y6DrHtm/pVsh23NKFpm170t1mbUseXWPaytHNlG3fzshKiZ01snmCZ5vvWxDbdNu8q7zy6CrJ
tg50cxq3Ze/VaSXO89qFUd9bt//eqxzdbaY3+qZZyXXQrrBs60C3MJOebPq853JeetcFg9PnN/fK
o/vGef8ZvdFrm9EV5IZb12V45dGNmG1Z6PIlZckNv/XKo7uhogNNi7zy6LrO1l7otstWH10WXfeX
6tO88ug+03Yc0VWjrc3TbaitHF3i2I4xuu9KzG/6hVceXePZjj+6RVp1pPkerzy6fLQtJ91p2a7F
dD1lK0c3nrbrEV3M2bY13SPa5um6gmzRxLM/QTdOU9f5/+KVR5ehtm1Nd5u1bfvo4g8utq073bra
1o8uaW310R3UJy/s+4PXPOlq13Z+oRthW310GffJt83WlMzT7pgWNmr0XZBPRqmPrgFt25puc23r
QJektm1G94531Iu7xyuPrruGjtkZ45VHN3u2NkGX0LVm5nX2Wha6H7PtI7pSsx3vdBtqW3e6WLOV
ozuwpotmf+yVR9dhqy5cPsUrj24kizqtn++1DnThalsWuou27Xe6NqtfZ1x3r3J0A21rS3SpVce2
b2N6JNn2O13pDYjeuNIrj24YbetAF722edJduW3f0rVY1P2jm3nNk255bfOki9gdf+4Y51WO7h9t
7YyujW3zpBtUW5ugi7WDYXNmeuXRPbmt701XnbZtRjeytjy6+LVu69iFV9jy6Orctn50Q2orRxe2
tjy6E7aeQ/wbutnqoxtvWx5dcNvy6B7Utv/oSjA/b9c4rzy6xatt2X90QWxbB7o7tx1HdHVp65/R
jXDvkQcivPLosrf3szc84pVH94C25aSr3H1zbhzrlUc3kbb2SRfNtvWje1Bbf4KuUG3bmm71bfuI
LmZt5egeODmxyTVeeXQVbpsn3TpfffvSXl7l6ILWtn50Z26bJ10j27YZ3XTa7lPp0ts2T7pDt+XR
9eKNXaMaes3TddsZs+PbkuW0S+Sl94aPGRlaDOUYPqHoTdW/o8fzHrr2tF0b6fbf1q7pwtu2PRlu
wna+pmtHW7+VbmVtfVOGELAtC93Z6vZZMo+upeuPW7PAa550O2s7NunC1bZvGR7Atv8Y6sGWR7f7
tjy6qLatO93H2o53ut63zZNuQ3ePbf2KVzm66LW1a7rLtd1r09W4bb/TTe5Drzx9iVceXRR37r/y
3155DDdh27d0dW2rj26ebXkMyWDbLnRn3HzzN5u88ui63TZPhuGwzZMu7G3lrr/8f2Ns/TOG3rCt
O93G2+ZJl/u2PLp7tu1buk62tXmGPbEtJ1263jV9tOfzCbpb1ffaJcsx1IZtmzGshi2PLmW/yS66
yas+hmewlWNoFts6MCyHrRxd8o5YstnzusnwDbZyDE1hy6NbZ9txSxfftusfw2PY5snQHrY8hmmw
tQm6dLad5xn+wVaOrq1t50GGPbhtT70XvfLowt22fgz3Ynu+xNAE941ZUs+rHN0yT7x1eSevPLoo
fuy++H945TH8gO14YCiazl/tTvBaFoZRsG0Xhqiw5TE8gq0+hq6xrTvDfNj2LV3wW58LR15+3dOd
l93plcfQRLbjgW67bW2CLvJt60f36Poer2QeXYPb5kk38bZ5MuSMbd3pzt62PRmqwpbHsB6D28xq
H+QbXfIY8sZWH8Mp2JaToRRseY5oiRRzzKOqG/Vrva9MAeuiqhWXiKpWvhBj2mlqIOhmuYomhxcX
TQ4vX9HgVTyB4fyqxl9VdvxV+9LHXzX+cIVt/FXx+Nu8pHq9QsbfLpfxt+cfZ/xtZdPZOv6SX76b
4y8vrhp/6Tn+8mSOX646/tVpd/wHp0rHjg0OEH7sYqO8wifjmuD+Em0xTB0//Lj52whVelRx8/fV
jN8fL2q4WSY6pMxxA4Mb5Wp4lDtuQHCj7DmWsscNBG6Ur32c8oEA4MfmYYQFMeZRp5R5JLgXcnty
VHO3npMS3fXURO2tRK1G0SOV6rUFp1Irm3pKtk6lQ1Sf7rWeyKLlbwnu8HUjuX7foliiWRhLVLLN
lHc7nvKDcYs1XHhtt2hwuPBuPWPUiQoZfmoa+lkfqPw0OZXoPqubig84fpjYNsppFyWxTMJQKIyF
otEtZ8d4IrrKHN7sLy5Vsv+T6Nafgh7TSt1jSvFF6pm2j1IdotTlUapTlOra3OnWs5HKaF5cTVZz
lR2lBrsLWVq/6SKPXpmuo0OUI7MOzLd4pmXpYNV3ZzwcZ5qiI+6Mh4fJjEPmivmVtQN2njtPBveJ
0fPcF5hnyAzL1TtzZzojvM7MGd+5M50RXv5emjuPmIg6M/d9684jJqJivTV3PnyCNFzPpyiiTL22
MFUchO5YE3RP9YmRdWauP+zZFGvgTm+i6y003/VUOg2NMQp3b2f5WSOoqP5h8HWSKcwtmoGWNkwX
zQiLdIsUH60litguxpeqwb7jLV/wsRd0ftl3Ss5qR868C3sla/0xe9mnZhVPk32ijp2XjiW36GIU
zdRFt0RHep2KlJyKPJ8MeFwZS31C4HG0lelJgceFrMxPDDwuWD+1a5PnE4WYY9cmd16JkWV6snAC
OvAVuI+yNsD6YcWNuH5YZLgKrMDxm+Aa7M4oWczwyEhlrvbxG+FKbLBpuvGujIyMUqEb7PjN8KWo
OjN362b4UlRk9RKlw4Pn4NEQF1evM3OwnsPi6pE1PecQETKXkk1xQc06M9fo5rygZmQt61wiQ+dU
sjHWwg7XcyqqFRlz3DlVKzG30Oa4I6a4ae+Iiaxb6tyiVHmvBWfBLWFKcDE/JurYhbf5PEJuVmLz
KEvRMI+ibpGWFd8ZZ0a35cy/tS9ft7nCW2ffvpPW4z7jnjCf1L7vGffU9QzcsI+fzncwp+4BuO+4
JZSqM1PeaeWVratnlFhf1nsNo0xZ30p6lCvfvUZw2fLfawSXr9i9RvA8Kn6vETyfyt1rBM+rLPca
P4GD5KQtZyXOqyWfKaQEr+IJfq31U3prUol9cQouOyf1gnqCl9Ny11KRjm5QfbYHIrroGsd8IFKp
t5kn9CT1IxzBZ/JheKaOSKjajVVFz9aiJ/I5zdl3c3bKH2RuOUs37InZOpV4ivXTG5N3ljeikzrm
7XTpmVh3qfHaebFDN8byS9tjn+BHxSftFXNyeMVfMRdFVO4Vc1S10+cV88Sok/6K+Qw71Z/KxxVl
vwEo34ufM2y81Kmp9SSPZj4NzuyVbBZVnUXvhlTe4X4nundhP4vomn+ajxHK+RCxvIMfTvuO2k/w
mDyRt1KnfMOesGE6Z+ehXNXIT8bWOfOfsVdoXSt1T/Aj9Spre9Rconjl3w2XuzHZb/2rBvd63yqb
c6ka3HtaHbuVPhWHtCwV+OTOeGwWVS2y6sPGqg8bLQdPKYd0ZT5sLE56YxlP9iZGeTfJ6p4fOJ6R
/YCqC1vVhe3MvrCd1h9p/tidZ100uPNcqcexP6UBiz/ZogyTyoBxZrHfhti/CbF/H2J/F2LTQbhp
M8CDaf8gv09tdT29sBXbRSH2kRB7cGtth9Yfurw3h9g3hdgzQuzA/JfK/OlQ3cxn8BHTDt1eDK5m
2gz4YNoM1GTadJxv2nTMbNoM0mDadHps2nT6atoM/GbadFJ+vHwGkjFtBhgxbTrCNu3Q/c8AWabN
YFqmzWBlps1AJKZNp9imTQfhpk3H9KbNoFumzSA5ps0ADaZNZ/KmTSfApk0HxabNoIGmzQBZpk2n
vqbNAG+mzUAWps3gP6ZNJ9mmzcA6pk2H86ZNx9mmzWAYpk3n56ZNx9emzcBSps1Ab0H5LfYELR+D
dJg2A9WYNoPIeeXHtNHHC51Wm/kMIGPadIxv2nTOa9p0DmyaDKhl2gzgYNp0im/aDNpi2gzAYNp0
uG3aDDJh2gxCZtp0+m3aDGRl2gxoZtoMLmXaDHZj2gwkaNoMnGjadHhu2gwEaNqB81Mj2d4MfGPm
MwCgadOhuWkHyk+T8gxeYeYz4KRp01G1aTNAlmkz+JNpM8iZaTOYkWkzWI1p0yG5aTOAjGnT0blp
MziZadM5vmkzkKhpM9iJaTOYhWnTmb9p09m3aTMYjGkzoI5pu0HIjMRgQ6bNwFKmzcAlpk3H1abN
IKKmzWCWps1AMqZNx+ymzaAGps3AAqbNQEKmzWA+ps2Aa6bNIKOmzcCNps0gEaZNR+qmzeA2pk2n
76bNoCumTSffQb8/553g9R9SPag9MhCTaTOon2nTIbxpM+CMaTNoiGkzYJlpM8iOaTP4imkzyKVp
M+ieaTPYh2kHjr+NbYL7M4lJwfYdIfbuEDu1rfR/5Pxb1DY4f1GIvfyiYLt+k2D7pcbBds0Ltc1A
UMpIDNJh2nSgbtoMZmvadKJu2gxyZdoMOmfaDBZk2nSGb9oMFmjaDBJr2gzea9oMBmTaDCRp2gxO
a9oMZmDaDIhr2gw4ZdoM4mraDFRi2gyEZtp0tm/aDBRq2gxIZtoMwmnaDMJk2gyUZ9oMRmvaDJRr
2gxsGWS3eTFofzFYhWkH2sPKa3V7YHBBM5/BXkybDvxNmwFKTJsBfEybAadMmwEtTZsBXEybgYNM
m4EGTJvBbkybAZtNm0G6TJuBgUybQVZNm4FjTZtBVUybAahNm8FrTZsBdkybATRNm0H0TJsBF0yb
gXZMm8FcTZtBO4LyRy0OWh8GFDJtBlw2bQYuMW0GujJtBtU1bQZRNG0GGjNtBks0bQYFNW03sJWR
GIjbtBm8xLQZtMq0GXTCtBnYIsieemXQ/mBASNNmEE/TZoBY02ZwV9NmEDnTZnBb02YwX9NmUEvT
ZsBi02bgVdNm0EbTZuAT02YgU9NmUEnTZgBK02aQdTMxaLdpM/iNaTMAqWkz4JxpM7CUaTPAu5kY
NNu0GaDEtBnQ2LQZeM+0GSzRtBkUzbQZ7MW0GXjYtBk8yLQZvMi0GTTStBkA1bQZ3Nq0GbTMtBl8
17QZ8Nq0GTzTtBkgybQZnNi0j5aSMltdH+VX+tljqPMbjlTTzm909I2Qxzcsvug4xf3Fxfnip4Tv
HBaPal2p2keVq3g0ikebxb3SyorO8opSN/WZlLj67GeU/suKp7g2ZdnUOtyMx84308wTN6uzLe0o
06axHmKdkip1gN93nOJlqP1guYqXOMAz21bqYDYPgpfKNCtrC1tzUaWKN8Xdk3+9/nlocSZ2wbv1
bKr69ayOotV10fFu0VWNdc3HL8r3yj4U9emiTfwsOu3astSa6FX0VKe1XHR1VynbW7+d+ImdEE5B
Ktl0qtJPKh1NCZvhqLC2ymXVkA7RHNgUJk8qDkuP1te7pv6jHeBdGN/MPBKt1IvgnEa4mW2MPNAe
9AC7wT5Q40KljoBL/fgNSAeTwVQwDUwHD4CnwFbwEfgv+BocAt+BuIuUGgAGgsFgCpgKHgXrwffA
wa10BGgNuoCuYAKYDm4AvwZF4BEwDzwOXgMbwW7wOdjDeeAWtTW4BtwB+IjpZbACvA3WgXfBJvAp
2Am+APtAHdyeXQxagHgwBFwFhoFfgAIwEdwDXgf7QAPcgl4M4kA8aAkywEgwCvwS3AfeAAdAbdyi
1QGJoC0YAe4E88HjYAHYBD4Bn4KdYD9oeAnqAAPBzeAZsBa8Aw6DCNwKxYJuIB1MBnPB/WAFeBd8
DHaDwyD6UiwLqAvOA13BeFAAJoE7wZxLedOv1LNgCXgOrALrAR+tfgkOAac5GhioBWqDc0FT0B/c
CJ4EK8EHYCuohtvqWOAHV4DxYBa4FzwM3gMbwPvgQ8DHYh+B3eBzsBfsA/vBAXAUxMdjf4FbwALw
PHgBrI7nixnFz1xUS5AGMkAPMBU8Cta35MM6bJMEXNFAS5AALgPJYHhrpXLAfhxMXyXpg+rbJH3A
hYO64FxQDzRuywebSjUDCaAD6AguB53Az0EayAT9wQCQBa4Bw8G1YBqYDuJxsCaA/mAoGAVywWgw
BhSAieAm8CB4A7wD3gX/BFvAB2Ab+BCc2x7LCIbjNjoHjASjQC7IVDc8wCt6f7VbNO5BaqZKeVDb
K57R9p5ntH3PRm3v2qJ1t+ieLTq/1gdae2/VOkz0LtHCbVrXie4SjfpQ6wjRPNHxovmiS0U3iyZu
19pRdKjoaNHxopNE14r6P9LaTDT+I70eo8XOE31NtNEOrVNFbxS9RXTHDl3+B7HVx1qvFM0XLRSd
+rH+/XKxV4iuFH1LVH2italob9G+opmit4juEO34qdY/iX75qa7vG7EPidbdqbW+aAPRZqJdRVNF
B4gOE31IdPVOPf8NYm8UTfhMT28tmvSZnt5O7KFiDxNdIOrbJdNFF4uuFl0rulF0s2jNf8tyi6aK
DhBdJBq5W+tw0bmiD4luE90lmvK5/E50lehbomtFm+2R34t2FU0VvVp0ieha0WZfaJ0hulW03l6t
saL5oreILhD1/UdrlOgI0cWiS0QPiTb4Umtn0d6i+aKzReeKFok+Jqr+qzVbdKjocFcz1VyxHxAt
kunbxd4h+olo+D6tjUSbig4WHb9Pl79R7Bmi94nOFZ0nukq08X6t00Q3iB7Zr+eXcEDbiQe0PUvs
BWIvF/tbsbO/0vYc0YWiy77S+Y0PavWLNjmo89uJnSzaUbS3aF/RbNFholeLDpf5XCe6UTTha623
ia79Wv9+l+humR71jdYmojeIbhaN/J/WmqK1RPNEXxNtdEhrkuhs0YWHdH2bRbeIbhXdK7/r5Phc
u7Po1e7wS7RX0XzRiZE6/2bRmTK9SHSe6HzRl0RXi64R3SL6peg+0QOiB0W/EY2sprVRNV1vY7H9
ok1kekexO4k9TnS8aL7kb4yS5RBtHK01UTQ1Wv8+XTRDpvcUHSo6TPRG0RdEI6trjRVtINpcNL66
nm+CaJJoO9F5ovNFO52jtbNoV9FUVzlYunvsHOxKny8yLCI8whcWfiszjPSwaLYaqyaoXDVZ+VVf
6LXQAW4UV0Z4RT8Y8/GpiAjH51SL9BWPBDdfxs7gf1lqOsqMQEmOo2rTzK29RmS4j8laexc1CfXn
6DLuEhenEsPcA5nZqofqo9JQI3pubj11Vb2av3bzbWUy8PveuLdKc0t3c2PhXiHLWD3c55RtGf2q
K/7PUSMV3z20bxW0vNa6u2GbTHHnwe9n0OuUPRMeHhbmOFFhtnq7o6ZJYALK80MHrG2kuy9USCqx
Lwahrnw1xv04gso3l22blG1pu7ufVeSqqagZvWG3RseJdHSSH5WosY+7jAWqEK2AH2b4sXcKsPSF
bt1N3K9ZbquP3rxPHAGo5Jat0tt9nZY++2BaehffxZE66i0j3jpu7OZwFRZjvhHTXwQFFuCi0MWv
ShVKdRO5My9wWxfftzJadtnT4aBXcoGkm/PRo4H3dw5ag061cGbhWUVHj87B9F5ufOl8tJM8dT6O
0oFofxnusc0W1E+l43gdhCNwAKZxyhCQjb/7uEd/Vap42vvXV9WvVHQ47nxjXtGT9FGNKdsv574a
MW7EuMIWhUGv2XWKDo9VN8T7VGwXx4X3w19i+lMhv+vj6PPM0aPHxsrY/g6koFFcqllDDc8InaAc
87woXueZar67Xy/T4zJKKsekTYNybNRS6CLn2O+3HVVqDhrvA710fUtE1/TS+aG6cYy35n6lj4Ex
X2m7LMrlH+9zFLuLw8MdxXfxt2N6f3kyaKbAegfqC02TMJ1nzvVjdKTy0OW7XeotHKs1s2GwBtYv
kGgvRN4dPdFEnGPlQpXzr+/o+STVPDafZCzvAGO+uV8pzxTYDwENXa5QNbc3E5ejd8Sx5VmJ7ssu
/Pb6f0Jxcpt5CfY5NsiseF6RKp4C9QXWZzi2Cxd5/Su+OEZy5/IPbnis3e3NU+o2aM5+7I+Qa/2p
SzdhSTgk6LdgJvgduAWwN3Ib+D2YBW4Hd4A/gNngTp8+Sv4I7gJ3gz+BP4N7wL3gPvAXMBfczyMK
PAgeAg+DIvAImAceBfMBhxM+Bh4HC8ATYCF4EiwCT4GnwTNgsU8PmFvi00fa9/j7BZ/Wv4mSHwwl
y5H3CnhZfvNTTuzjs7/mx9WU199JKmj8Z6kpVkU4gXnxHB/p3ungqNPZ7uCj4U0a3zroTRwRcmSs
wE9myDCpVFz5C90+ZsVSdex5c31KL6EURyA9LV3IQW7/dBSWowD9+SnuPRC3Q1lTA+Vz2BMvT/3P
Yv153WSKQA+GtU5we/nTcVeSr0a7yzTB3TJj3R61PcWhfs6JZ/iy1s8RZItl/VnYB8J8+qwUAXhz
zRti3gRzd/JmswaoCXhjWQvUBjGgDqgLzgX1wHkgFpwP6oMLQAPQEDQC/+fjoG2lLgR+cBFoAn4G
moKLQTNwCYgDl4LmoAXgJmsJEsBlIBG0Aq1BG5AE2oJ2oD1IBh1AR3A56AR+DjqDK0AK6AK6gm4g
FaSBdNAdZIAeoCfoBXqDPqAv6AcyQX+fPgdVNOWg/AgwEowCuWA0GAP4adRYMA780seegVITQD4o
ABNBoS94lNIU2FPBtWAamA6uA9eDG8CvwY3gN2CGj+0vtOWXrz0mo/2Z9Xu1t9CEat11YXLc++IJ
uFvsp0aooLG+ZUp1MTc+jODppKz1MwVq0rXmYgsUoldYIM8typ5icVdc2vrvW/xZRhrOewE18xJx
H5ODZRiPZahIqoXtzxlGqbKv/+1gc7heDBb2sX8OOCkC0HFuNcAR6NGytDWhC8E54I/Ojzsy7mxM
V2GbPXiWbre7sF53gz+BP4N7HH4oiP4f+AuYC+4HfGm5EjwEHgZF4BEwDzwK5oO/gsfA42ABeAI8
6egnPrxLe8rR126+4OQ17FmwBDwHloLnwQvgRfAS+BtYBv4OloOXwQrAo/BVR78Y4RdmXI9V+PsN
sBr8A6wBb4Ih6th+ewf2OvAuWA/eAxvA+4AvWzeBzeCfgC9Z+YKVL1P/BfjylC9C+VKTLyr58pEv
DvkSkC/4+BKOL9T4cowvvvgyiy+q+NKJL5j48ogvhPhShy84+NKEL0aG41zKFxq8a+QLBL4k4AsA
PsQ/DL4F34Ej4HvwA3BH96Fcq8qff8rd/1qLuhPk/HMiUnnrP9HpTK7/ZqXL/xY6E/wO3AJuVfpu
9fdgltJ9nDugfwCzwZ1gDvgjuAvcDf4E/gzuAfcqfmyO4x/MBfeDBwA/l3hI6afbReARMA88CuaD
v4LHwONgAXgCLARPgkWgOprN09BnwGLwLFgCngNLwfPgBfAieAn8DSwDfwfLwctgBeCzrpXgVfAa
GIr5tofya9nV4B9gDXgTvAXeBmvBO2AdeBdwbOh7YAN4H2wEm8BmxQ+FcPyDD8BW8C+wDXwItoOP
wA7wMfgEfAp2gs/ALvBvsBt8DvaAL8Be8B+ln7H9F+wD+8EBwIcRB8HX4BvwP3AIHAbfgu/AEfA9
+AG4DcXR51XuW9678R6C9zLsS7FPxT5FNDhP6XdJfAjFr6npHYdP7GKkLJ/w8qsbPpXj11KxMp1f
jlygKtc/rko/bsqRp/ApKk9Nxr8EaL6rI91+OVrpm3umH162rs4dN+NA7PVEDX7fM8F9Xj8efeYC
1RG/pk3vcKXNqyqdbumV5BVOCv/IS6rHZzM8D/CcQOWbOCrfxtletPE8F/SFbkXS+pAmxntDnkh4
4il74zqRDbUcqxWnuhZvHVN5Jr0Q0J9GRReD5SveTyrLZnVwdg6rrvsAoc/ueP7uM3bkpILJBaML
/YMKJo3ypxaMnDIhN7/QfYbUJ4vTMMm9EvDvhEB+QrI62GFJ0Keu3umHo7zu+EpM5xTfpnc2PZDQ
MObue6NUi/jDT3OHRIRMS3H0dY3XJm6pPKWvTfTCwT3APgqvZ+yL8LlfkdLbgH0LXtPYh+DSs6/A
a9hKJW97lL7WrZd5b5dl2omLZGMot03GlDF5uZP9Wdg61+ZMyvVnTZ9cmDthsrv3+eYlTOZF5RtV
aqvzotx6ldTvpY1j9LqwPr+qGaP/Yq1ck+yxheNzVeA4jXf0dZspTqYNkLL8Mpm/WyI24X67JrNH
6jXdB/ZIdXNrBqZk9O7Rt1dW8Vp2gfLb9+vRvruoDvi/tUpXSbhjaKm64a9uKg1/tcK/VHdaMv5P
xC9b4v9E1Q50BW2Qmw7aI1d7muB8J8q6hFn3P9djx+8ePnC4X17Mk3/Evr7kuQ8SMW2Go/cj87lv
WfI+pdeT/UduC+5T7nvuQ/Zj2C9jX4b9KfZn+FyDfZZ6jt4eiY7e9p0cvTUyHL3vsx3d1xnu6DbF
EQtsKxMd3VamOcFtQu+vye7f+qjVf7PsgJz8cTn5Of5eOWPzC/PUsd9gOv9m/X0LJk3IGZ8wqqBQ
5Re3sYHdM9Ky/Fn90rMHdRmQ5s8akpWd1ifLLc91bdu+vfs3lyfkWE1OSFTZKayj8Ycr2P90/14Q
tywJ53n376Xzl9Rw9PcGx+v/VVf2/h/3hdn/47mFbZ7HWKD/xy9y+bKOZ0J+3cvl5ZnNDy5S+i3c
z5R++8mvxZuBS5Ruz5eC5oCvn2WIuOIX5vwKm+2hFWgN2gAOQ2gLXlf6zS4vAPTWQw8P/Op5FegM
3lD6HfXrjm6NXRVH5+gTPr8+50uL7oqjhZTqAfjFPV/y9VYc4aKPCnrN4Ftkepfh8cZxCPySf6DS
327wq2Z6TuAxmAKuAsOUfq/NcwO9FAwHOUp/5zFSKXf0Be/CRwO+1OS5jC8x+aySI434ZJJXBT5/
5VflPIp4iuVoIo6v4VuLKYBvjemFhZ51+DaHX4jzq316buAxSA8hv1F6yM7/A1BLAQIUABQAAAAI
ANGmvih8+CujqicBAACEBQAWAAAAAAAAAAEAIAC2gQAAAABwYWNrZXQtc3M3NG1nYy1tZ2MuZG9j
UEsFBgAAAAABAAEARAAAAN4nAQAAAA==

--0__=CpfGEquZHC2A14se4aPSinL2WzWGKsJFjpgubpKR8tlbOuSD356XPkBU
Content-type: application/zip;
        name="packet-ss7.zip"
Content-Disposition: attachment; filename="packet-ss7.zip"
Content-Description: .ZIP File
Content-Transfer-Encoding: base64

UEsDBBQAAAAIAJiRvij0EXSiWJUBAAD8CQAOAAAAcGFja2V0LXNzNy5kb2PsfQlgHMWVdo1kS/LR
yEY2Vww0xPBLRBpbkm2MOYIu2xKWLCTZhoQsac20pMZziDlsK3sEEnZDziXHJn8SNifZ/+cIgbCQ
awMhBBNICOdy2Ak2wQaHU9hgQzi836uju2oOWTEOJqxq+Kyp7uqqV/XqvXrvVfVw7z0zt377+qMe
ZznpDFbK3tw7hZVp16YCL06SmRmM/bKEsRC+vrl371669Aru/SsuvIq/rwGvAy8BfwZ2Ai8Ao8De
ifSOSZ9cw9jXgMuBq4FrgOuBHwK3AL8AfgXcDtwJ3AU8BDwMbAO2AzuBPcArwGc2MvZj4KdAxR2Y
M8B0YAGwCLgEuBT4FPAZYMavGTsROAmoBcLAa/zzMhtlzwIv47NtC9vE7t90zyZ2F7ttC/2TO1//
ttP0lo4j2MoOxs4GWMX8juNYYjmbxCbN7+hnrLKk4uLSC6hcWUVoVUVoisjgW0UcpXjJyoUVF7d0
zPErKW8+aVp8+ZRJFS0dMxh9YdNwpaXjECavii9zl7Ap89nM+aETu0NsDjCvx2bHXnfvPPu6racf
d11V2fHAey/rK5t72ebQCdcxdvh1dZOPuO720umXjUJHjOfZ+Xh2fpn+7OT5rHQnu+q99ayBNbIF
bCFbxE5mi5nFmliWZdgQS7IUcr3IJZjHYsxmnczBdYddACRwrwrXlrNzWTdrYz1sBWtnXewsXIvj
Pj2RQR1LWJrng+fOxPc0PmH8TfC/EZSL47kQmzXu0rPR/jLQ2oe21+DvuXh+GahYyVaBHgt0rUJ+
Oe724k4vri9FWSrZg2t05VyAnu7EX4vVo/8WPgcjdTuRtW6mrrf3ZAuwM0k7uGJ3uZn1ydTatFVh
NSXs5b29dd2tK+w1Q17GRbFhN2UnE3r5/hG7N5vwYnanM+Rc4CRsy5re1J/OpJxIxh5Psqy+IddG
+UTay3iofCCVjNsRLxXJehm730m7UXtd0ougjBtzh4eSiRE7IYgk0oezKdce5vTso3DKvTDrpdy0
PZQddG0vsc5NZ+JuIhO22zO2E0sngxJpN5PxEoN2csB2UHnKicXcmGqlWP2RZHw4mUCFaXu9lxmy
o+6AlxBdQj3yYVU47Q0mUCs1MpxKZpKRZCxtO4lobrl+10lhzPnwDCdTmZzSXsJ2olHeSK2dzg7z
IgPJFG6AwJg3CHLQm9Q6kJwmzpnVh2nwvTSuEmM5wSjm6Pz1S9p60UzKQ0EMv7thOJYEBzLgoRd1
HepqPBn1Bkaoa+4GL80HUqvJ7wHvgLropCI0xSIZYifqVX0xxlzviCf4FsGM47xDretAACq1XSc9
ok+oYQfcMGaVqK7ILDJuYoQsazW/snIdOi5GRkmJ1ZeMOiNfSMtnqqlHSQxFyo67Uc/BDQeTAYyo
odkRh5xEHE4SBjIOejEyznpnxCQujdkTGcIDiQTGg0oTgaLd4GKaszmSTGPauwlwLlNrOxnOB/DE
TaRdYoWg68KsE/MyIzRsuJ/2O5cO230jw6ApVpgPfgVJ6nrOzPSFhaZaii5RdwayCUGzYqCiKTrI
6xPtowadBn6tYDWil5qw0AjzsTXLQ0hUi9AA0EmrA7oly5Y5GRdjjfZWJhQp9nByOBtzUv5NuxrN
oftDiWQsOYg5XmM78SQaiDuQdHBtdbK9267WRgVZORlqwnZrNkXUZEyFNjwEvQTx9BIRISixJA25
4uU6Yk3GHxAoj1gMoxt3INyka3v7utDZQQx1Ws4NN13L6ynGNMfOSLYOin7ZkVgyG+W1tXaZDcWS
ybU0S9NDyfUJ0icDyVgsuZ4rJo/XaOWkCvFfRYWCSLnfZFnKWjwnvvNHLXHZWuoNEslVdm/b2bbM
nHeS3dTT1NzeYs+qn12Aj4r6Jq3TlprGAMYumeVKh2vhZWvUE1aTPyy8GL/t9KPu/DmdHBiIJZ1o
IAH8CS6m7QYr6uqJdcQMOdS4QHMUV7iwiQcHXSwKRBYmJ4qroo12Ns0HWvQsmObVbngwbC8PNzY0
1uirglwN/DVAlOvp657X09fSXYMG0cjgEHE5bC9Dp3gjvOF0QE0/KiMy2oyONPKGsAKgyIhQwf3p
SMrrd1Nh22pPp7NuOm9IIbpgGUnfgLse8hEUEgPL20u7CSflJa0eyReohGVrME5cgVEBNNa7qrmu
2WqKRjlJfSQ8MaEqZemw1ZJMZFJYNsATEvWYS4u3kxqRC2H+egfdvRRNUAtS3AVRksyMT3s6GcsK
bSOWwKjogqkrawP60Z4jKc1olEbdiJeW2j3jrMUEcD2+GKAL/uyotb0BLF42iXcGSBuSrKZu1Mk4
ZM0UbQu3Y+ihvR9E9Y/wRTKRIb1D44/+kv5b67q0tFcvO6um1l4/5GENGkrGooLAgoQZ7cgb4X1S
BEKisJP8ycrnAqldlT9LqisQGneEescS5qb4rGxqDxRYNdcLmm1RI7tVq/rV2wJtLecDKVw+gYaT
GPqaMSaUb2cUm1l8MANyNeJ5g3lkha3eYAmLQx/3B90njUxDAr0TycToVma9CzbxYSEC8KWhUAWy
OzGx4KlRw6Rv4rNcTepAqQWanY+Sx9duzl25/PlirU0HZem05KxWOh/8/pK0BfayXkSZA1YnrEVe
PkPWJLjLlWyeAu7PerGo0I2ytsDgDgztMBdwd4MTB/dsixrUrHCx3IUt3daGKZgmMqVOlCuiVdAc
zzOXUc7XiYEkkBpTGty/nbbdTATiuTy53vV7S8YqGOdgSYm6Ua4J1rtYA1xpthUwllE3NwD8fIJu
1/JG+2Fq5q8dBdYLw/YM22tcsfSDlKiXjmTTaWW05BoS6SyUgG9lDMDgIoLlQzR5+uEHBNwzHjec
B99Qpqst0tDtFcZMVC7ycqbZNncIqaBpppOQuGSTuNEx7JQKzTjRbBIzY0krxJImyT7skIbZ46Db
yrUv4F5CSXvpIVIrwnagVa7JX+4kM1UHawtJajrjDqetXmVrRF0aXm0tdzIZNz6c4W44Va4XjWCW
aUX5lKfGU64DtvaqZZ+mEqdHqG5exL8pdY2oLCosV1JSYuXwVSrNxhEyWpN43pcMX2mTVsxVimGr
lSqlTgrK4JEnY+u49x0jTYMbCXeD7w8J50WWpTkeFHN836m6pb2lRsYB5ANKBoYcKLCYGmPh+Aej
JSoj31e696lsYi33BqT9Jxqo0QaHlHLweAILZXvvqm5dEr0ExjbuKB+u0HPSnueUipa4t2qUXkk6
POJ63F8cs41goa7N1QiiJangIm6UpjgkKgUl75BECaMVV7i7wOcLTROajIFJqKaF34NGLOUoIhya
aicS4QYlpkqNNP0CIvxZH1Aj+616rClXYSOBmoGU62qtiXEu0n1l1/qj6y/K+QMvnS9BgNYwHtcm
AGwE6gXo8IXZpRW2PaEUer6c+6LryLAINzd4sASClICARH0TyZcUbgCkM6BB+AiScBTTzcOw1UaS
m0hGXUO8uZjwq3I9pxENg8qBlINKs0Ihe1xjD8eciFizlMyY9HPumAtm2OomDvF1xV8c0R3dMlJK
2rcsqknmaQ2s4QNhjt+qtFrnlNIngrpVjENbrTQPA4Pi4lsMq1AC99a5aX3pNeMrWb8Bf/WgwagL
RgM05Cy5nj9cuF9NV/xZGsR1aJTTNbzhQNIKGo+1BcfHD2yEbSKAt6LJCE26gjGPrCzsxwP9goX6
H7b5vOVztLu3CfO9Wg4u1aF7znX1ME7/ZoYibHfLMJ8ex8gNpHC2E3HCSipoA5nj01B8fBowPp3e
Bh5W4XY12jQMHfSOe4tBq9LWpV5wE00ZuRqdHvluJg2NxWloBA2WstqU9cUXcT+iZlBEcg5LwfFi
/CupN6x6woGRQw7Th08MEdQ1DDdJvlSNPgsLW5gyElZ4mNUSXGRuUWs8+icixvKhtFqio5x9fHyU
9yBUWKBi8VwWbrAt1LTy55bKiWW1JbDoR/h0pJHiS6fSYFavFi2XnfEj06Bbaccg4gpnw0vF1ztm
gFoEI7l/G0mSNRMWGxrGkA54qXQm1+gWZuw6z11PxPFwpiNip8oF5FMtegEUdkLMCkMKMxRiUnUO
ZFNcKLESYIkUYSZj5ZAWsLSOlT1s8cBchQrNyajdvuzhRmEPm+Zvnx9fwZAN0DNiDpCJKOIc6I3f
ATmswnfNF3vfG1bDLxwUGTo2hoFH/9WCyXcDxALh1uUuY3ZXnWHM+VQUqFpFQHxC4s4wX/S66iJe
JB2wKO/JsB34fHSPHpDNkTE95KwTwbKoN+hlyFdQdzFWbfXz+urRNt2nGLrDtWaGC5i0xOUtCICd
HnbJJPdowLi32ZvUQr8FbJPiROtbXzG568ADybCnx29Od4EoDCnZfymwQiwT5myQHleuX2Ypt0xE
i/cdGl4w29a0pbIizJVN6Daz/SGHJtc67szkTQeSGQzKIObSMHGBSy3PBbO4q+4cO+cxKYxyWcwp
f46/QKO4l81QzE5SLv3JJb7h41coLce0E3f9eZLTqK4jfC7CegzUd2HDoC9vb62Qyk67efNTbDkU
EuJAOH3qIMX28tYVLYZKNcsIzW8WGpKSA7Zh9vBaKGCY4BzLBsTwjuKOI0ebFlf/TiIa4/pv0OX8
AFPjzlqXB6b4rqYqyR8lKtAa/84tcvhD5GLI2T48NJIWGymqgL/iBuMyoMWguFOsSbRDQi29SSKD
Lvo7jZICiq1pUzTYLFYViR3yMUc+5wnofTfKJ7STJjVoc6Ul1lM3LoY+kY2Tx4PmIORpWRAjJ6NU
cbGt64iBCAr7TXgJs20hNmFbC4MY/SIFplMjfRWsnGJrcHFd/Xw748WVU+O36DNBnzqeophrNuQM
LYVb2fiwdIqdTN7wUB/9FZw6Stoy7XfXSwWNCjoElwPLA85xGpoOrIsPU4TbP3eQN8+tXi/m0s4f
tUdFRUw2nY2JMYyRy9wPHbLei8JY1BQqrLQeF/4a30qPwWaSYQDiEZp1E7Q+kPOdzvixA+omWXer
pROrjg0kE/mTKrg5kEu8WZa8D8GUuEuK30vHiRToDWFr0NDwzSp/s0TMsKB5XkGP68Tq+sBgO2i6
W4l+dU9ft9jrKlRMmXZ68ZbuGkw2uT0RjJqItMluqOL+8gb+ZhN1KTfm0QYKLaOYYxhiVz9jIRc3
ZQOASXEaY7mJpMUj5aEDbsTYq1q757UHBqaa38oC4yNCEuELRDo7OIgFmoIv3G7ioRSu9wS1Nu05
q40XXyukaTtJo1vfWDY8IaKPQg/8+AD/ohYqkAw3fcBX+QPCWADBYAIsADFHfXOVNBZZaXEe0Umf
XCdnx5DrRGlz0DA7qAZ5P9hfjnlQwJa27sPG5Jqf8xtPLG/tCVa9DK46qaisHwqWtD0t8+JCbr1j
bl7b1SKOJEr6oxlz+l3eYaoWGiftDLrCjSODx4mCp+RzKWK5e9Fm2FJ5AmWtGZLLsbuBJtAgV9Ok
zbBAoV+w3mLJyFpbOH35GjtDveKDkndURAueSBGFCm/i4XjxgDTGzKJiwTaMimyC0yDDfXTFWQcv
kYsCZokR0h0QW6dJZTg0Zfh8JAVN4bmMWrxNagdpDvMzLcmUTlfUCyx+rqAHBkRGrD2gRFGGmca9
5gx3HOVIhg13bXm4YcFCzWuwmt0BUuI0k1SbJlnB/MzZ0dF8BF9HRJxhp9+LiTiWIsEwuISfjxHz
h1uM9ZBDLhzmbIYWOKkvpOFm0OOfVTGtByoOQrWTN8KnJP2Johd4GeJ5fxaDl+I7Y3E34+819elb
TLCD3XViNNUmNC2J3HsnCQOB5vJcolk2ev+hbHx2+OZHNDjnwvnHz7k5GAepUFLBsPFaud8eBGrl
4/keSq3thd0wrxel15MSEA4YdyR1srTO8x18LERCftubOn2BRuc9mszRbESELYSF7j9LCkArL90P
S9ujTHLjE0xzhR3h0zAS9NDTIhb9YiIW6lmXQ/ro/JUD57f4IYXz20XtyQJEeWkZFiFpTVvW4vKT
yxeVLyxfUN5Y3lBeX16+vHxZ+dLytvLW8pby5vKm8nKrGbrOXmovsVsCMtsUmT2SRqvQzS6sOqqA
XbBEcLd9YJ/DQAxMpuBAUKA2MRgU4qp7veMJOaaAPWeyr4HFehucw0DHO+W9PsjFErtZPVKIxurm
lrYaeFf+1Fhid9JagvEdsVc7KbHmr3ATg5mhJTwcdH5zU8ua81uauuFVrmjvO/f83rY+q/hZVfXo
OXbzCEyvMUqSwUIm3BK7qbfLFlM/w41rn+y0mxl7z3DsDUVdH5njq8yH3F1EGqe6etNQ1rY+YLgM
eDGxt1bcy0/79pWtbffI0CTfkwAXfc8rW8A1yd1Tg3Jv56pH7FEkkjlP6GsULbGyG9yE58EKf9NO
PSD9HD5qYauJFJ+rHlMbfWYbYSvntvIWSb+FC45cJFeDBlsyGkMEGTrPc6iTVQ+6CTfFzXlHiD9X
Zpo546uHQPNZfZ09djU3kuOesNk63aiXjSth5fyqWSIDdWbUwepa2dJuVwutxJ3A4Lypr5Vq9qFK
uAgtXdnDRWiJvVTq7NxJXiE7+bYk3laDCmhaYoAbbMUfsfAYDFFjH+gh6JHglByn3WrOs0n4s3SF
zA5hyLZo5r8fvMZEwSTk1ppYX1UrqqZafzrkiHhgtyZIgcREBDu/oFY99wxjmB6iGN9azbEgAwtd
rJ2KjGiB+GDQ2QFfbIvtqVi8/2iMjBVuTkpLUo2RdCzS5sHtfrfgA/6Z5QG1B8FJyKlnQAx6yhUh
L+7KS8GFWwzXAVWSj8VtQLAo6sJnEqEs/3SeL6vcduI2+oCIyfv2DT80ASsiiLPDWRyAA6UPWTxM
k43C7zTHxLZbxj/WK7ZbzG2BYCNAHkxUJyCSCdpv18dfuI+BPjA1jwiGQMtFc7zO4jukTiSFATL3
B3KTpcVmpdcmtgv2eWJm4WybDwVXShgEtddEfSbjlQdEgrHLC9OKvWZ3nZfM5t7y0sIUq6VjHwVk
xt+aT7uBSV/kxECecS+EvVYqEU4G/9oYtpcqzvOFSjnHxCR9TioewlrnbrNRb1Bfg7aPapQx22wP
Xu/gsTzpOg5kI4kMb83J2S0rPGa1hYbYHxsiH7kYvYegTu9jfAU5JNXddT38rtpXK6FruU/41UER
xZXdx1WN/7pHhg8JWerUR/48j2yktMMpunJCj8UIkYXBQz2BwEABxTxX6IM8LhJT1GJFMyHF31Zx
uLdf193UUkfhBmFr+nH63MiAP0lEfENoeu78JgeMMIk5/XCBu0tpbgkUGCc/MKsOAPOKzdbjzjCP
NXMbOaiNKzDhOtHBERGw4p4gvWDA1Zc4S0iugzMszgjzvUo+vPrYhgPSTNeXxoyu6CPFpyoPpjp0
Dii/MNUlg0HwnYJImdgb5eeNxBnDajcyRGEGSH9MngYWR0SIElqAg/c+pCPLg09y9E2PQrqX/HS1
P+cGtUW1XxyeGeGBZ41+rdaU6+CC8OblmzrB9l2wCNAhT58wdSJOVkEyySswPXnpqsedBFZ64QBq
61IQv+ULJz+CIHarCh6l5NHTg3pAo12GcMd3SEONoIoc/8WHNQpvXVm5O4dyUVJrlNo8FKvWPlao
RcYGonnkg853ic2/ICZi6E7t7IUSLk/f09Y7rK3AKqQTjIAKMSsdZVhwPfK9Dl/V4D8ZZDaCyhSy
NOkLbE99tGnmkoJw/EU4Y6/sbpnX2s2jeP1cgmi1SMqFDiKo7g87GA/NCNS9Of42w4h/jpnvWurP
FdxuUgST1Y2Hxb6b8q1yj4Ub3eD+qb9f4juH4ULbvf5mqO/PBSfA0l7co3e/5EkJkmdMQ+4M++sL
nfXrLsegl2sKsVxGrPnfbmeE3hQqL+et8wikYWepLc284H7OujFghnILefdca5OJXdBk4v5wRpol
3KImbmn2r29dJ6WVq+/kcXMJRAx5g0OGpqLR1irJ39TIH/OMFoRI+0aL2m6jDXh/mL2ENJSJVu7d
VJNTq58HqrW5p2peam5r8d0oWXGt734SyX6cSPP1As+5JjwReJkIvLzrAy8HM+5yYMIuYX0YCtr5
/kWlb/wLGFooblvofxk7MNZTzP+JqM67Naoj599bj+l0agsPd8LzzzjKN+7y1+N+N9jDyQQHr2L0
RjnZiKZdM9Y+dn6Axj+yKb8HZvA+LN+TZ9udiijhefivMxgd8N+VoCH238Dgm8bRC8iFS2QCr0Oz
csWObkIcJOLHHcUe3tjvqJlTH5oucCP9F1bkbx7ki5S+cppRLtPOc3Le8C0cLlGHoxst3S2Qh7T5
MPm2MpFY+Fi4aGD8r+VpP1+QG9TRvI142DhFkTMjfOenQh2ztPY9HRYXd4QaxzSpc4yFiL+MFTmc
6B+l5WcP9FO7/C1NOgUXiWVJB8gDkvz3R4wxJU/B/6EP/ScW/JddjV/SUO5D8Opoxvypj7wCYXuN
fPO70Im3c+xq05OTN2ogshE6EUZ85nznLAualT4iWlcvU3XZ1Zlk/rHOmlr6mvU0yZJ6BMMLN0L+
gIDyZfwjx9pbtTlHz8WsTabkew7mCKbjSb4AFvnxHXPcRJvateAp3mfRE+1EMX/ViB9ByKFXf0NC
3drH7+Hk/vIB5kuPKwPJaau9b1Vdn3223etyL7pHnU0TM/bscH1D/YZaWFdBjEOeGMajdO5+gN6J
ynmKeyT5T9gtvXX11jhabDiQLTbsu8WTF6FBSAxsQ6wsq7C8Qq7F4T7t3fHeEbgkcbsrGbZPVnUu
L1InP9JXa6320nT0tk8y3pV1CPa0QU8Ni2N3oH4Ffw+wCaLgd1cGOOScI/u+K5moW5aFMY2uYnqc
HZgEvcIk2DddDQ0La8WhLK1r3ca86eSxx94MaIlLBed9JBhnqfKauWPRmY1RZJceaNF1clp1dRwU
LQBFK7Cy2IZbgE5Rd7Wx4/Siwt7IUDb2kZQHpYnHa20YumnYw7bdi8xSqH40BKulJ8x70+FEkv1p
8ny/CFtpid1U6Aglt6T8w5NNw8Mx1Y8v1do9S1vs+sWLT6lFXYksBf/qTzllUT4dX+RBDemRUo1N
2aiX5ESsBgOT5K4ouRNy3+klPDJjW4Sd57d1yvzctpoiaxPJ9TH6LSDuIVklIn7g0UlKLs3RMK4R
BT1m1FwqQS8ug5cidDCg3schOgectNIwmA1YwVtX1NXXz69v2rfrkpdaksMjKW9wKGNX28uxQlHk
MzmQ4W2p2b8CZgXRga6dMmVKld3dtKzNnlW/aPaUKdb4fjqNzAzDNUyrc7tBXswXmt59PNY6jkfI
nbD4L7v1rmnva1lOyqO3r3u/GuPP9bYUehgNzOM/TdC1Jrc1QQHNwhQk0KFVy7Lg3OEOHOxqPmu4
F3w6N9N9a6fWJsf6dCWcnDwR1tHcwJoCdAetNxo5KOpu2DmdbX1tPXbLyq6+tq6+Xm5oD8Mp5Raw
J6XXrqaDOpjWSTr7qT13/oq2LtCkjvxoFXbh7+m24Yrrx4gsGMKW1dqNf1bSPzy+19ezwuLbZ91N
565Y2dQqMstbezjdKsIoC/Nv+S+c6GxpFuuiz698DupsOsfOZ2Nfd+6Qja/i3Ldnikw8vflW+UoJ
51/R8jolRBzX80vhDpFMdwWrouY7jYNc/sNdFv2WivyOr5gsUuCpYlJxy9bYLfQrKqiB/yCRJX5U
QQzJvshvHE93Vdv1eX01GjwwgjI+Th6Qfo3JxpbunCrGklifI1Jn5OgR7fYBUJZjqBKlNveb+v3Q
t+NX5n8ZVTzt+5dBJ9JEmkgTaSJNpIk0kSbSRJpIE2kiTaSJNJEm0kSaSBNpIv1Np0mMnQj8H6Aa
OB9wAI/+X37AZUB9OWNnAe+fytiZQDPQArQBy4F2YAXQCawG1gAfBhxgAFgLxIA4kASGgQuBFJAB
1gMbgBHg74F/AP4JuAj4GHAJ8C/AJ4BLgU8Bnwe+APx/4ErgKuBq4AHgFWDBdNAMbACeAV4dfWor
23Qv++3tv7zR+FzFoT7iO/se+963vsdu/+rnv8ry/s9qOf+vNv//wBb8X9lmi29UDjlV4Ahxlddm
3GCT6AKbruqML59SwcoXiXJVOa3Tzam4tkhcNp6axGa0dMxi5hW/VbTIW5sma+S3TyH+T5NzQPH/
w3IOKP5PL2PMAhYBi4Ew5sI8YH55MDde1+eUkXmpaGZn0cxTRe9se5sy/5cVSWedxw6NjrIQq7qC
sVlAy1zWtvGiYsXfrlSK/+aWTlvsk2VtrCjdOiNm/+I4/j/prDhaXi0r2ToD13j5EjbzQPF/PmSu
HmgAGkn+gIXAIuBkYDFwCrAEOBU4DTgdOGOq0CtNU4VeaZ0q9ArpFNInpEtIjwwCQ4AHXDBV6BTS
J6RLSI9kgXVThS4hPUI65KNThQ75+FShQ0h/fHKq0B+F9MTXgB8BT0udsdhi7G7g/EMwfpXQVZU0
0m+8wV571R/3PUU5UiC9vGfXrl3PP7X1sccevf83vzJuWSUdrCIUmhKaWmrkSowc/d9WK1SOleKb
VdIN2oKSKidKyhxKVgKnAucBi1nJlFL8PRpdP1i8K64vJjJ/1YxMQl+wow+0HL0LRugVPXONnrmq
aMZMocp37DrBSk9lMy+5t0Tyv+ov0X03AluArcDxM6AjgH8Efgs8CowCVTOhI4AY8Ibe7mvjy+wu
mnnxgGaKt7M/tI2zc0bm7UqTO9jUE9m0paGQ+oaLoW4xSw/bH76mD8V8AL4NPAI8CmwCNgO/B/4A
bAEeB/4IPAk8A7wClFaBIqAMmAJMBaYB04FK4FBgDXAO8EPgD8BRs2D3A9NmM9YBfAy4Dmg9DGWA
V1584YUdj7/wwqYHfnv7bbfedtutSLf5iWduueW22358/VXfvfzfPveJi/TRCVbMmUZuhpGrNHKH
GDnLyE03ctOM3FQjNwU5sSZX8nU5uFNhlCs3cmVGbrKRm2TkSnn9HZr1IEqrHJVm80nWj5f8Jl4X
4q/i6WOSr1slX7dL3j4t+btH8rikSvB5kuRzhcbjQySfZwJHEm+B+UA90AA0AqvlHCD+Nx0O2wL4
GHAxvKSPAd8Hth2JOo5CG+/B88AngP8Eyuegj8ADgAMD52XgVeDPwOvAGwR8drFnd7Fdm43Pg3Th
N2wj23jrRvZz3L4JxW66ln/+4yb2xlfxYay4H5frKVZKH66w51iO0uTNFfIgZ/rf1E3Lv0I526BB
VanTYnqTVTkl6SL3Ok/7a8jzDUxL1+sZ407xYuPMFK/t7coUp01L72RrYNaB0L+vAbWHC1k11vzi
w/P9opniz1z9Ds7kJlpfpaX1juU9zcuqXP4pXfszYAfQcISpd8uk3q2Hrr0RuAmYDF1bNsfUvX+i
a9C1pwAfPjrQxX+WOngvwI7B2gBMBw4BKoEZwCzgcOAo4GjgGOBYwAaOA44HVgP/aDP2T8DFwGXA
l4CvAZcD3wC+BVwBfA/4E5U7jmyFp3c8ueWR++7asePJ22/+0ZM8XXfld77+1dy0Y8eOr+x40k9f
eZKp9Vr3utFNLfceI3eUkTuS5ypZRXngrauc8NZlTnvmCKOGw43cYUZuNqcu15KYZZSpMnKH0hw4
9S/leXH194P9yBi1XaBnjKrdohktTa4U1m15iLWep8lY/evvXeoXOjwoX5ZbQYEUYj8a3XepMZKy
s9+pOmDawZDjP+sUGN72W84Ud9HeLsfyHZYJ/D/mz0ZNUuYQD9+UPCyXfJwKTJP8tCQvqyQ/D5M8
PVLydY7GV9LLNcBJwJlAE9AMtACrjjF19kW20Nv/agvd/UVb6O+v2kKHf90WevzfbaHLv2kLff5d
4Brg+8BtwK+A24GNdqDjP094L2wTYMUJjD0BlJ/I2Eg1Yx8HTqqBzwA0AGuAG09ibNcoPttHt4/u
kh+2mT3EHrrvIXb3ZvbLnI+48bMb8GE3/Ow/8MEXjEmw76OZ5GSOVy4cyxOYletRcAt+LP+gkD1f
eNdJ7C0V9VmaDtS6qsZ7nIazYfIZdw6+Lff/xlesoP2nbD7S+ZNPZZWXfGvyO9oGrLo4R1aSwNVS
ZrZJudlQLWTnEuCfgX8BamqEHNXnyNH9wJF1jL0HOBo4FrCB44AbgZuAHwM/Bf4LuBn4BfBL4FfA
RuAO4E7gN8DdwD3AfcADwH8DDwOPAI8Ce6nuMGPvB64FtgD2PPgpwKeBzwBXAq8AX5jP2AvA7HrQ
DHwWuBMoa0B5YBi4sIF2eN7Y/cKONwqmbTL90f/yxht/eEjdve+u2/7rxmvpGw0ut+9mBpEXlZtk
5EqNXImR8+3CmcIuxLcZxnXKsZLSECsn2y80eWpg3x3LdGvvGCNHCp+sRdZ6MPi+P3Fh45mJTE6m
uHFjpEmYI3NDh80N+XbpHMW73e+DXNRifa8VfDxK8nKO5Ocxmmwq+SufZ8oayRnJTwrYDjwF7ACe
Bp4BngU+sJCxdcDsRZhLwEnA+4BaYB4wHzgFeD/QArQCZwErgH4gAkQBFxgBwothawBNQDPw+VMZ
+wrwk9Mw14CfAb8D7gUeAB4EHgEeBTYBm4E9ozs2j/6Of36Dz69vG90js7/Tvv1ulN3Mbv7JzWx0
zzV7Rq/Qr7P8UyJyxZ3fcQytupo5UPDESAUty/xAxiTxL1+1i9sTWu2LzNrHjjnm2iHszLdDDxv2
/lvObGodV7ED3KieeaRo5oGimeLPFM8ESVnsM0JcaqHaIcSHzw2VfDnGJj90xCSsB4VQ8dAsVvGl
vXMn/WdFq/XgzOhhLx11ybGz5mp64Ii3sk5ul/JNsv0c8DywsJGxDPAAcM4CIe8f1GSe5H1/NNyB
dROLn0kyMgdWSb9lqvenUT+VVsIaHQqpmTRTzKQ5b4WPtVJfLwFOBU4DTgfOkPq7VdPRpJs/tMTU
z6Sb75G6+UGpk0kf/wH4I/AkcPzpEIozGKt7P+oB6oGFQBPQDqwCVgOTm1AWuBCY1szYEPA54Gqg
rAXtAx8FbgP+BHwIWuTDQARwAW6+wep7fJNh7j1i5N54hPIPUrofX+7eeMuPr79K3tKGmttpVYbd
V2XYfVWG3Vdl2H1Vhn1XlWvfUQQysA+nMt1anGLkKoxcuZGj2Be3/5oOBh8PiolkHNQ6KBS85czL
emac/dFS6FTTJ+XyT3z6veTV45Jf24HngOeBSeDbZKAMKD9d8DFX5kienpYydb6Uq34pW1EgvIyx
HuAmYCNwB3AncBfwW+Bu4H7gAeC/gYeBTcBmYAuwFXgK2AG8CewF2HJ0CJgJzG2HPgJuAe4E7gIe
ATYBjwFbgCeA7cBTwA7gGeBZ4HngBWA3sAewYBUdAlQCM4D3AV8BvgPcsQJ0At/uYmznMzuf2ca2
sC2btrBnHn7mnmd2yk/wTXxUmTuKXr8jYFHeDnKOvSbswkIWpLk/bFp9xe1I1vnX1qvT2g70KrhZ
z4xTch46oJn7x5fZHxE32vFTztpdFWJzxm0BHsImf2nvvSXXlt1kXVc1W7f9SP6PUDzqAK4EwktN
eb1DyundUj4fkvK5Wcolyd/xkJv3tgdyeLOURZLDR6UckgxukzK4Q8oeyR3J15c1Gdu4IpAzqxOT
FmgFPgrcCNwEbAGmQAanAvO6hDx+B7gDaFzJ2ALgXOAS4J+B6XB2LWADMAJ8CvgGsB14EngBGAWO
Pht9ATqAHqAPOA/4O+B8oB+IAJ8CPg18HbgcuBq45my+t/jE7zf56ZFNZpL5gtzetOnB+x40k7o1
ueRYZoVKQnSK9wz/xFBgK/g2QJVhA1QZNkCVYQNUKRuA9RwM3u+PA3Zg7f/9yewcX7F3WIYnvuoP
V6hVX9cjb6csHhTjbJyu3tuV2T6+YuPM6KnyjJwtBmsjeRz3lnxr8nCFOu+da/8dpfi1Pkc/flrq
yG9qOrIWOq5O042rgA8W0ZGXFtGRPwduBn4H3AM8BmwBtgHbgZ3ALmAP6VOgogfzCzgCOBI4CXgf
MA+YDywAFgJtwFKgB+gFPgw4wAAwCGSBdcBHgL8HfgHcCtwL3Ac8BmwBXqVo4OPscbb54Xsf3nzn
xjtvvXMzu5n9RPvcwK6V365lV/F/b+D/3szL3QA7ufmkaRTGq2jpmCGietNwpaXjECavHqLH+irm
dxzHxHtg9I1ZKrZ3HLfrplwQYk+McjtwBt8TpL/yDTD+vBXEAlF+7LfVSnHXOBnYMt41UvH1k2cX
X//2xdvX9ek6zsz+rAi79cwzRe/8qeid/ck8uR93thW9M86MlkKLhIzDrjuaTZtDb3cFimAyCy2Z
yd8DY6FjeeRf6oOj/hZk8lngOWBuL2MnAKcDZwCDwBAQA+LAhUAKWAesBy4CLgY+C3wO+DLwFeC7
wBXA94FrgVuBXwIbgTuA3wC/BTYBm4FngeeAV4E/A9P7MKbATOBQ4FjABuYCJwCNwAKgDVgKrAHO
AT4E/B2wFogBG4AR4BN9nIPF/HbaCXsNiok+Y6U9/DNmKi1ZAdQDXcAisONg8PftipeMM2NolYPy
jKG9xnnnxfHdQSqrl4YB6QIW6vL1BHJzDoa8GdQa+uyg8H/Xu/mOSJLjOTMBmPO/Rb9eCnwW+Bzw
deBy4ErgKuBa4AfAT4CfAg8ADwJ/BJ4AXgJeBtgqDBowDZgOVAFzgROA9wG1QAPQCJwMLF5F9uRu
/nlRftS3Z/HZwf99lude9XP0XV171b8mPk+8yP6Azw7iKWzKyZpNOVXYlPm2Z669qduibM3B4M84
tWJxzbA/d4q3866+Y6TSFdw51PX/X1NeXgNyZeYta+vi697z+3Hn3ZYxkuTztE76Eyh+a+OkUPeR
Qv+/56/J633pxqXAMmAF0Al8APggMAgMAeuA9cA/AP8IfAK4FPg34MvA5cC/A98FrgD+BDwNPA+8
ALwBvAlUrmZsBnAMcCwwFzgBaAAagfcDZwJdwEqgD1gF9AMRYBi4EMgC64CPAR8HLgM+D3wD+CZw
JXAVcC3wA+DnwM3Ar4E7gUeAR4GngWeA14DXgWlrMF5rxuLkW0iv5XoNwvYnH6ATXTxYfHpXS+Hf
hoYg+T96Qg7z5fA9wBygBjgJCAPzgEZgAXAm0AR0ASuB84APAYPAELABGAEuBT65hkRwNxt9bjf/
u/u5UfYUPtvYVm4X8nv+31F+lf5uw2c38Jr/oVLB3dfk8Vhl7/m2nW8TTmrpmMlyI4+5NuE5B4tX
E6L4zpD/gyE3b7kPu4veeanonf/t7A515UWCgDmKb7uAl4DdwB7gFYC9yd5804jGT6R3S6IzBCWh
UNlfso59Dfg6cDlwNXANcD3wQ+AW4BfAr4DbgTuBu4CHgIeBbcB2YOcaMdcmZPNgKwSh/+tZA2tk
C9hCtoidzBazI+00s1kTi+KTYi5L42Oxety18JlIE+ltTofOhyHKjsR0ZIx+QuGizn09oadwS6Gr
JfzfvXsPlfkQprxIh7Ae5rAEu4D/6+D6WfjXw/cMG2KHs+VsFVuGf9tYL+71spVsKetjayAwPbhG
V84F+vC9E38LpUNRz1S0+EFWKelgrBq20Yt7S+gvK2NdLAnRi6PdGBO0VvC9+gTs9Q/gyRfZTvYB
XJ0COlyUinL6BtF6Pa7WoUTZ3FA5RXy2QsSrrpiF5X6UzY2WhVjoRP7vmSeKPeF7S8pYuXgruJah
ByW87p6CdTfg6gkogbqnnhiatnQyTAn7Tap/FPUPoc4Qr/Nbk5mq04ZLyUp5nSsK1tmIq0ejBK+z
RNS5KKTXWYKxUr92exSjQxJU2/KCtS3gtU0StZXm1jbKzjwRLdH7UmecFOpgIBW96ShY00JcrWT0
/FCIttA34NlJ7DCfkrlsZUcpOxugk7gdqLV4XYt4XWVGXZNRl6Ajv67yMeo6GVcPQ4nSuaWHRo/g
XYuiytNQZVmleBNsEqqaxKvCzKzgdS0tWNdiXlfFxHScmI7voOlYqK7y6Uyv6AN4+jjUU3jOnYKr
c3Fd/uSFOhG3NSSGvMLaWI45gakGRbxQ9nmWX/9prOnMnXu/jb9ETSvqHkDtWcz8DOruxvcUMMj/
HYbk2OhNki8OemplzWeGMC9aOYXNKBFlIyjbh/o28LJVrDK3pxvgQxtjn2BvVmK8QgnOsWbQkGQR
thb1nA2KkqjHATzePgNfZ1CN9XPZIZeMsspLzvkf9q4EOqoyS9+3/VWQhCzsyBK2sCuELUKAEELY
MhgxLCJgCCBBwhYWgVEJEIVBx71hwO5BaVR0WkdtptsjNgIioiICTjP2GZhm6RGOtj0BW9S2oea7
93+VelX547Hbc2bOmTOV8916dXP/+2/33v/+r+q952XMPiU7Pfa1ZCuc3Bm+Fk7OEtpFaK8CCoco
b+O3kfIwoY1jIJ9h8ULbCMuXzv24t3NQZ3Sc56DvRFmUjjpy3PTqw99qT+4c8OcuQqE9Lc2/6MBG
r2zp1QDqnreD2ltsh+lYJhdC50LpDdcyQUZ8jmSeC9FbvtePQ6O7W6ixlVhPFqiHkbyJRvhWY2M0
w6inmejPQpJQV26gyDWJk2thkBsgck3j5Job5PqLXLM4uWYGuX4i1zwg1x3aWa57nFxfkWtBSTSI
HVqLUk+0mGV7xslmi2xLzBHsNyBeiHHQ/hWU5hjcAmPXGPGLY1jKoSRyjtklanNHqElnHYN9N6it
tStm6BULIRjtKRLP4rkZD6tbQGW+BSg/+pRQZh7XWiI89gY9lyyTSa1hjbmwlFyKmnpXWKSrQ/PF
TDsWwzLibD+f2onWfNEab3tNOEZ3spvsPGanHAqT3M7csqOWFtSRhX6ctVhHRm3LvtvWGtW2J41G
jua1r420Yzz+l2LQEfPoZGqHfj6iMmYfJgrE5rS4NmXRdQYruVFmNDNgJdnUDW1Pt7NlDoprvTB+
DpJ0jNXqaaiOF3jntgZX7UyZw9nSz2Uyoh3Q1mN2fLzJ8cuzT4Xg+YtRdpbU1Efa1zHQq3BcyWwp
mW9ryyyTkWyIKMzjkV69+JsMv1ywzCApM8EeRJxPjAm0T9uswurObTSV1T0ts4caymZL3Vl+dPqH
a6byhVK+0i6UMSyT+F4BDVy+AmO1VEYpg7rAeo/Z3ArWxItR/IhN8EeMMxQHtjQPs8TZU1f+vtXr
ZDWq3o12FIQkQpJESJIISRIhydS2qb5OXt1cX+diHPekbnFad8OPDlN9mhuTwalohujeYc+Qft8R
8NVM0BUyhrx6dq/jtTXitbq2rvW2fZDf9kGivzzgtUH9NvWgVEooirVSly0QX4ovy6NQ6c9KA4yE
/LT165BRy1B41gmbtbB/zUOZCrHHNGSiGD/dFc4qEJX9rHDc6NZxSxRtRlsu0Tl7s7SlyLeIoO/N
ke1oBV2PPCMpqTASSq3OcthI+OcVQw8hGFpYUa0q3lpynsWv6+mHvrTdXxa792T9L/N7l0w3SKrD
Gd3sWj/N29iQ6vqN7XB5FShfJhp6BzSI/SQW5/pvQoZQp/w8Kd8nrnx/Q/lcqT/DyU0oz1YRhufq
8vW1vp+Uznb6ifRcyYd0hlKJ7Io19pVrG+J9tFzHJqec2GaHYw55I8+xcZ6UjWZQmbXzTMgu+3Eu
lVq9yYs6wEqShXNr0wtt3mnPc5FKWDPjejcIGhDRHLZ+tsSZ4lvsi/1ZW3p1uRXL9xIiSR6NwDpT
5uQRW2rdjDEzLsrx7A+Qn3bwipFJ/EUez+1xq1LmpgHGleNG/LrZFFkQ2tF45z6nCfJhWYIrMm20
lbN+ntvjll49QqhjEaJOhb/2c9kcXZbz6JVUWzak40wTIp4d3jP2k97HSjbC6pYViBuxfvP+kb1+
ib3DKZDZyQ9E4uhsBPutva4RRjq1utBLrz75Z54Yzrc75EVjRwgrKufmscy4BQ32M2MdyXtf5VLc
jaToDdHkO9Fc8foDYp3JNCrBvmIrfQbl+ldTlf5JBiLHJc6euf8nHG5hCuLEPKydldAwSKJFBf4f
tYdONET/HudLNo6dGWhKD4xoI4pdrEOc5XAuENv3NHB5vEoxS5ci55zSOrXMSug1z6jsMP5Daulm
riWYnega9Bpx2ZkhdjQcOhdLDSskk1hKnPsP81civa+XVaG9rEGdZKbbyxrUqTHVXooS8BJ/fXN5
fQtLDrZCZjra7o6U52v/DtVk1p2NGIT44uqsKWpBiVkT90p2h014BAbAaizq4A6QEY2VGeHv69iO
l5POaPLlKlzZqhGvdenY47G3pybsQicjr0usc0TtTRhJLK095bu5MgPxZbONpQsCpXv6NfeUEdQz
NEe8ZB6tFOmRWro5S3NWd9wuc3MMdfVBq6KeFV3TPGS5GHkccVY3062U0UyF/Uej9U1Yj6Ojo0uz
VdjEF+Uvk9ld5y7DmKZAqty3Sr2OB9fjPmiLI5Msbe1BsnNtgxF+2UqvLr6WMfuYbZGcGQpZ5ZYV
Dim9MuTrsxQjR9dEopM/FrP4tPuYO1Zqjc1hMJ7ozDAF8UTqy9c77jTZ/QZ3DgXUG7Fkh1uQYENB
XYQs3r+p5ko0eAWCyqarfjtb23xdbTHsIt191S1OsKrgvOoWNaFx7Kf+hKVWh0PcMFO7eO094Or8
KDYbiTvzBnyOi/Oc3Fjv2Ms9aPHQC9Zyws0X24nuP/JRfqnMShPs+6OreI0O88UtGyaLnmiKlE03
Y4TO+V5mWqv6ih2NlxVKx67XZXW6jHcuE2xxJqw1mhmuRnucTuSxTTTUWVWOmzF7rzRniq1PLiC7
ivDCJ/fv9VMrvIbRD3s1p8GccvBwpQaywQZhmoIxe9rd4U5Bben1WldhIEdth/mXCU21eMlpvLMY
7X8qasl8ltOV3Wp3OfOqzwWEale6laR3QA3pZtjDYUqvzokQZJLqkdU7ngm827Kissn1yPYV2Vv4
/JAdlU2pR7afyJZANtOJyjaqR7a/yE6E7MVa2dR6ZAeI7CT2dDcqm1aP7ECRnQzZlV5UNr0e2RyR
nQLZPBWVzahH9kaRvVX8Tctej6wPa4fHWXpKnGx8zCR/b8b51qP0qqf3oDPrROFUuq02voWTCqdS
NNvQ6Rq9xis5ovhrxD67FLZURrdjtMcARfAJoo3Ed7G2Rh6qYiv/37yLdVJ0tZWWT/N3atOII1Hi
+ddYLGlJ00knCZJ6sSfzCcnGOx/kDuRt/HOEM5zg5ovPQuo9wquShYXgR5zhLMPoVJLe58ygmMLU
uLjEpSfBD5C9eJNI55PfnUdr30nGuEfzwxy3sR8zm8W1Kh8tQZ9VPtUX81iTR6WsCVE0UQdf3lsM
aViY4jWhYdz53Fhu2Raj16j6VCS1+iGEi3RoRLJWHHqkQVojmYnkWs2ssStN5HOpir+n4TPhq8QG
K/3sez6xdWCXkt/dzsb+EHsnvoEbYk9sp5OMFkikepzXX87NQ2hvSCZ6gN45qQHEUXwx6XPfvKrM
9scrmkfHl8tFfME+SOV+zznoK+2cI7kVwX9vxFpepjja1r+Wc7xpjjwkunISyfTlJfGyReY51Gcn
KpXen5WhXRWS8STDbmP98TPLZsE1wKWm/JUYAuLXt5BEFH5x+ngbMEM7CeIS7xxJ+sOrNJ8R5UjB
O88FwL3AQ8BTwDOknx/Gd43m84UngVOkL1ZmV+XviQqBEqAM2Ab8HDgNnAMuAL8Hrlj8Sx70AWgJ
dAQGArnAcKAYKAMWAeuADcCPgG3A88Ae4APgI+As8AfgKuA46A/QDoBB0w3AGGAKcCewAlgLbAOe
BnYBLwJvAAeAY8Bp4PfAZeAqwE+ZzABauvopk7OBpcB9wBPANmAX8C/AQeA94GPgE+Az4GtAwSGa
AO2ATkBfYCgwHigFlgBrgUeB7cBO4HngF8BB4ARwGvgDcA1IQ/hMB9oDXYD+wCBgGFAETAXKVXTe
o68IXnnJ+jieO9TIHWLk5hq5g43cQUZuHyO3i5F7JWTi/tHI/cLI/djIPWnkXjZyTxi5nxi5NUbu
LiP3BSP3WSP3kpH7gZH7rpFbZeSuNXLXGLn3Grl3G7mrjdyVRu4KI3eZkbvUyF1i5M41ckuN3BlG
7nQjd5qRe6uRO9nIHWnkFhu5+UbucCM3z8gtMnInGbklRm62kXuDkdvLyO1m5HY2ctsZuW2N3OuM
3JZGbnMjt4mRm2rkNjJyPSPXNXJtIzeiTNyrRu4VI/dLI/eykVtj5IaNLbtolL1g5H5i5I4yxvXz
RtlzRu5ZI/e0kfvvRu5HRu4JI/eIkfuekfu2kbvPyO1sHIcORm6mkdvayM03cscZuWOM3PlGbrmR
O9fIvcPInWPkbjVybzdyJxu5E43cCUZusZFbZOQ+bOT+vZH7gJG7KTl2rP8bPaoru9GoYYORu87I
XW3krjRylxu5S43cRT53Ydx/gq//3zP8390zzPejF4Vl7sO2UEeoK9QTKmJ60QjLlzLhBkIbCk0S
KoYUlt/fh+VMAD+SGTRNaLpQ+TEzP2oVVL7aCDcV2kyonDIKtxDaUmgrodcJbS20jdC2QtsJzRTa
XmgHoR2FdhLaWWiW0C5CuwrtJrS70B5CewrtJVS+Bw/fILS30D5Cs4X2FdpPaH+hA4QOFJoj9Eah
g4QOFpordIjQoULlfHA4T+hwoflCRwgtEDpSaKHQUUJHCx0jdKzQcUKLhMovz8Pjhd4ktFjozUIn
CJUffYdLhE4UOknoZKFThN4qdKrQ24ROEzpdqJxPCN8utFToTKFlQmcJnS10jtA7hM4VWi50nlC5
K1x4vtAKoQuELhS6SOhioUuEVgpdKlR+zxheLnSF0Pjoy7Yc3RNrBOOzOWoTRX94n/iKavSiDN9j
YmV5BLg+eMYh/sx6G1Bu7TF9z9c9CdhpwHMs6OqnoPPT0fgJKXyX7KfH67sj8RXTfDUUXyHHVsn2
xvbEtsMWwnbAs81zOtPXNQ7uPR8OzdkEP3GXH8XIT17kp+/xE7j4KTz8JA5+GgPfkZ3vysx3ZuW7
c/Id+vguXfsn6Lvp8B07kv2rrPnqzeH+FVXcHvYP9gv2CvYJ9oI8IvkdHVs+WzxbOls42zfbNdsz
2zFbMVsvWy3bLNsqWypbKFsm22UpUOb3iZ8czk8PXdtePw2C7yTMd5PjO0ok++1hT2WvZA9kP2Nv
Ys+JrnNs5Y8iAO4CXgBaQmdvIBvohgCVB+QDP0OAegt4GxiHusqA2cDn6LCLShRwAR28xp1EO66g
oymoMLVQ203j5GWRH1V9f8o+wtbPZ/LZHhq3fwJcNKqmVExY1XCks9NkIGiBq+3X8keGj5X/eRvw
IVk1abyqUqiGI6dS2fdXd/vJy9UrBiyKvJa8a9p/Rahcgi9W6nUS0ynbl3XctD2/mb9p8jNZ+xt8
euarv3l3a4R+fZuWHVthJchufOVPp+efmffeqE7dN3/48oJXI7Q6Vcu2O5wou2L2gBkvlU0ovevz
B16/cvyBnAgV+0nK1ue8BFln8dHCR4t3Pxw+P2Z7r8ltlkfockNf9t8S9bZ+89ZnXmy6t3ry+iHP
rv+6zdkIbfbd/oGpsvrBQ7Ss5z255NRP25/59MVW5UMGN9v2xxcxDo182XOJepvdN7j4i8cnlt3W
+sFnLmz/5e4IhVpo2S9qtGxsfA++fue6z6//bAud/8puu/7iqQhV+eN75pTum+3L1n3VDSaVvmwo
9LuxD4wtKNmf1WPopaeKqvI/i9A8X+aR9U6CbOmO8wuvbl55pMXJN+4Ib5kZkP3Gl82jtpd4tiV+
VelI9hUSDCuV7BoOJ5kUruGUgLvnhflLJaeGl8xUcsUALWpQk0Z1XzY1rNGphB9UWeGRIovSfIXD
oZH3D2nU4pLrV8DKZ0Dmeyt3tXKWZ3/OtzSf8yWCdcyiJBmJAotrWGOxxjctrvN9a+hvkUNabBYR
qwXxNKbVuLU1pMvxdQHdGX6dsiNsyLEsqYZLVRHH2k3CX2vt27cPNaRRWq2+nIA+yRcoxa9nsug+
QrH+HPB1d7SSan6MwzXEXcy3nsT7CIv9WPdk5H7WX7if86c1Ft9GqUrMb621FcnLeouXI92KfcI/
IJyDcvy+dRTNPirHuucbxRRc/NVEJLNAxHgSGC+NSeZYkkc/Q4EYSrnbun+Szfj943jPfdppxfr0
VqBPy6zEPnUJ9Olu6dP9dfqEqv7KPrXDX02kC3WhrtSBuuNTL2oFf26JFUF+Z4AVsgl8oiX2R61o
Cf5fCbllkH8S2IrPT1Bz7H7SqRrjsIpCdKd862jLKjsE772BTuC3wP9TIBeCvM0PR6Iu8peHpcAw
fv+TCMxVfmCuRvtzxbMc9ZuD/lzdAttuS2a/2b4o0WMKAlqzqK7HvG3wmEnwmLfr8Zi8gL5Vchz1
mEmie2qgxe/4updCd3dji2EtVeS3+6jF4vGtHx6ojXcTiWNy+K8akzEBrYOpboR619daf4Q6Bh8g
Oi40XvfAgO6+vu6NeN+RrHW/F2gxZ1dVxBmV1hqxOCKvf4t3QG86mcimPHwO095rOoPl91I0dAdS
sOh7lK+PdBv6Bdqgf/cSnaOJdfr6/g/o69hAPXmk+7qOYn09ErAtzu6qiDO779PLu27WPYy+R/n6
SNc+PqH2WC9LpCUTUmNx7sOoJSLOdUjVWRmPwfQwx7njKhbnCkIc58aHEuPckciRvzjO6e2MZ+/q
ZpGyp5y8Fhlm22C+afMIbHT0uB63aiIP0c3WXKqwJtLfWiNpo9WftiL6vmC1pj1WBp3Agv9b4DML
Ed8OU0+7IRXZKTQNCWaF3ZRW2W3ofrsLPWz3oSftIfS0XUTP2mPpFXsU7bGH0RF7IJ22e1GN3ZWu
QO5b4JoNf3IQ4Z2uOO5OV/G/qz7fwqwopzU1clJpFGJ1lWPTY8Azjku/dEL0rpNMJ5wMOuW0ogtO
Z7rk3EDfOoPIdUdSkltE6e4EaubeCpTRde48ynQrqKO7iLLcSkE3oAfQ010GrALupd7uOurjrqGR
7t00yV1B5e5CWu3OpZ+4d9AB4FP3TkrxFlJ7r5KyvdVU4K2jEu9BmuVtoaXes1Tl/Zwe9F6jR7w3
6HHvffpH72N63jtDL3n/SS97X9AvPM/a4zW19nmdrUPeYGu/NxLHxdZebzrey/B5Dvjl1gfendZH
wGmvwjrvLbOueautJFVltVAbrY7qMau3es4apfZb09Qpa5H6xrpHtbQfVAPsLeoWe7u6x96qdtmP
qV/ZD6lj9gZ1zl6jvrSXqav2cmU7q5QHNHBWq4a1uEelOOtUunOfaupsUm2ch1WWs0VlO9vVMOdZ
VeS8pCY7u9UsZ4+qcPaqaueQ+rFzVP3U+VDtco6rfwJeBL7A50HuUTXKPaJK3HfVAvcttcF9Q213
d6t/dl9Qb7rb1TvuFvWh+5g67j6k/tXdoE66d6vfuMvVKXeJOuPOU2fdOeq8W6Z+596uPhHMBMrk
/SI+X3SnA5PVZ+4E9bU7UTneFJXmTVdtvJmqszdHdfXmqh7ePNXLq1DXewtUH2+JyvEq1RBvmcoH
Sr27VZW3Tj3l3ad+5W1SB4Ej3t+pX3sb1FngK69aWWqdaqDWqrbqLtVHLVAFaqYqURPUNDVKzVK5
ar7qrJaoJLVcfeltU197e9VV75xyVCgUVq3+m73rAK+i2tZ7zpxzZiAhBAiEEiAQSgDpTakhSJEa
Qgu9C9KkBFBEjF3BLtiez3K9XpGrz/a8T314r/fZe0MFUUFEURFFMShFeWtOZp9Zs/eek5OZfB/k
+9bn9385Djn/WmvX2f9aMzEi0bZGKNrT+DOSbxyLjDBKIxONg5G5xteRFcankXuM5yNPGI9GXjTu
jrxpXBV5xzg/8r4xBXB25D2jA1zLjLxkaJEXjB/Crxvfhz8y9oe/MPaGvzN2hw8Zn4UPA0oBUfPt
cF3zX+Fs86lwW/OBcG/zqvBAc3W4wJwXLjQnhSeaBeEic3B4spkXnmp2Dk8zWwHqA2rC/0cBx/XJ
5o96kfmlPtF8Vx9vvq4XmC/pw81n9aHmk/ogc6ve0lyjZ5uL9SbmfL2hOVNPNyfrUXOsftwYqR8y
huqlRl/9d6OnftToojOzvR4xc/UUMwd+r4le26yn1zXT9HpmFL77ZyjHLA21Mw+E2ptfhTqan4c6
mTsRPodre+DnntjnruaO0Jnme6He5iuh/ua2UL75VGig+ffQIPMhAKwp5vrQcHNCaIjZMZRnGvA7
x7S+5kGtt7lHO9PcpXU3P9Hame9q2eYrmmk+px00Htc+MrZoO4wrtV3GdG2nMQI+94ZrbbR3jEzt
LaO29rpRU3vFSNVeNAztWeNX9rixlz1gbGd3G2+xW42X2LXG82yd8QybYTzG8o2trJuxhbU2HmRZ
xkMsHT6fjG5lB6OPsa+jT7Nd0efYB/DzjejjcAfzCNz3P8Sei97F/hG9hT0Z3cgejJaw26Jr2PLo
dDY8OpzlRHuxo5E27H3Atkg7tiXSnt0b6cQ2R7rDipLHlkRGsWmRaWxKZCZgHpscWcgmRJawwsj5
bCT8HAr/nx+Zz3rA77SPFMLqNJg1juSzepF+LCUCJ4pIV3Yi3IEdCbdjh8K57EA4h+0MN2Kvhuuy
p8Jp7N5wClsVDrPRsPl0BKSHrdp6jX0IK+0repQ9o6ewJ/Qa7FE9jT2sp7MtgNv0RmwjrNrr9R5s
tT6UTdf7wSrdiXXWc1iWXpdl6nVYbb0Wi8B3SmGX2BeqxrbDrvFyKAo7T5Q9B3g6FI7hPvi8EbAa
MA9+b1oohRXBd0bBrjIo1Ij1CWWzzqE2LBd2luxQL9YglM8yQsNhFypiemg+7HOr2Ak4A5zQrgZs
BNzCjmqb2RHAz9omtk+7nu2Ef9uuXQY7XQn7J/z+VtjpNmtFsLOOZIXaKNZbK2AttULWWBvL6moT
WESbBjcf09lxuDM4Amf2UsCX7CL2DtvMtrGn2VPsZfYw287uZ7/CKaCWdivrqFn751/1Lfopvpsn
EAgEAqEqA6lSXdAp28rUiBrPe4E1nv7IQg6ywFWEDwSNB8jg84bY9bJzedmJvExX4Kx9EGtu7DNX
B8bGLXAN7EOFhUKw8KGggZ3UTGShO7LQwmWhUGqlj5Jopa53npuglfohayol7GNfSlhfxNrMZsWa
9ydVUPPuhWJqzWTNewdp3qeN5t1b0Vd4VO/0NarPQqxY8+asnwbQPHsg7v5M1nd3KfTdMZWs73ZF
PpT5w1eeMVKsnwWIdQiyw3VyrO9+rtB3CypN3x2JrMeqgeJRFkjj5Atf42QosmB5K67auwOv2mOR
hWZMHt97fPk9HrFmM7lfvlT0y2jPfmlq18dYP62+GGCPvgH26OP/zq0XIuuxaq94v4yWPNmr8GSU
pycR25L1UzVCIoIn45AnzVyejJLyXF8hT3iea2SC3b0T4m7r4h4pjZOvA4+TzshaNpN79BtFOw6v
tJk2All39+hwyZP9Ck+GeXrSz7Zk/fxpdJkH/Ce/jj0Zjjxp4fJkmNSj3yp69By4a/s2qs5c1kLc
6S7uc6T7nu+q4H1PWUxOfOJ9z/d033Pa3PfUVPQV3hcO+NoXGiLWOkzezw4msU5ZPnqvU2nl+P2j
L78bINYMJt+v/RTgHsZE3LVs7huYs54dQtzWzlbCrPueDbHrlXvXFhE8cdafIVLEPweIOAvZsWjE
O9RfUB/xO9TBELF1vbJ2lKbIh7K4eayDmZibP8xH5WmVm7f+lXLzlJun3Dzl5ik3T7l5Rrl5ys0T
CAQCgXCqgFQkHZ2yuRqDM+elghpTYp2i4aRfGk2UOU8VWJ2z+yApc35EYeFssHAkmihznuJp4WxJ
s/otsLZeXbAmala/+9KsMhEr16ywgny0CirI1VBMKgX5GCnIp42CXEPRV3hUH/c1qushVpUSeyKA
LmkoPMZK7B8KJXYgrCV/VLoSGxY8cdafgVLEfwaIuDGyw7VnrMSeVCix+RDxyUpUYpsIPjix5ktr
rWawgGvtGciapUOL+0XItoD3iwEQsXXde7/QEGuKK4YBUgx64BhCyFp1JvdaGMXAey0PYrCuV1av
1Uc+xN7YEo84T/InovCnP/gTSeBPRfOydZE/GS5/+kt5WdP2B+dlhybo3WzEXc3FPVTq3eqBe7cR
ssafTsfrZoowQpNbNzOEGMQcRyr3m3IclOOgHAflOCjHQTkOynFQjoNAIBAIBAIH0jmbo5N1yD5Z
z2TOeb2GfbK+HM7rVs2+sqYV6LgiYHGUvZLQfYJvhuxozFE+ucqSplA1+iXIorQQ/HZUjX5xzYEr
JjVt7q7AXdvm7qusYc8RvHRY+0otUyvpltm+KVHLtEQ2eQ9gTaZ2EpqMFZK3JlMHWeBtjzWZOr40
mdoKVqxTZSh6tA/bELuuavu2iM/do32kNqmXTJsIo9LtfSuF91j1y1Sofr3B+8wEqh9+0kelQopP
+rRBPpS1Jo+4t9RH9X31UQdkQRVlA0WUvSDKBgmirOhTRO2QD279sZeUDWho+5Po3ZVePdoR2VHF
2kgR61kQa6MEsRbbsRR7xFosxNoe+WDEPvNYz4r5k645mmWW7c9h8GcPczTLO7IszfLVNEezLGKW
ZpnLuGbJR7hl+9+xtuEKZdlKY7XyJ6iF6sF/h+B3N4VmwonwBfZIKFvbFCrR1gH2sbxQOMT0FnqP
0ALjvsi4atWr5aUU13k1bVu9G2uEG05MXVjfDBc0CId6NGRsS6NiLTurGHws1qZmbYPP4VAtllGW
t3tUy/bEI1Zzl7VRNBan93rXOIm5bUXOozWYOBJyFRasucRHQhPFfnAmjIQm8ZHAmVojprJqAN6f
Z0q7TFMFa0/lSjcGsdZ3sfaMsQ5lTms0A9YStIrKrXHSxV0gcIut2zzwbjK4HAs5tsf+LQwqx0KL
wBZGKyzgvaulYu/qASOkpcfeNQnxZcc+8x7tEePGlQutbO6qVLlQFPuGE58VE65caI1iosqFUwDU
VxMVfYXvJHJ93UlMQaxNmTxj2ihmTHeYMW08ZswExFf2Tlc+Y7pL871t4DVrGrKWw+R7g/aKe4Nu
lVwVMRX5UHb3ySPuFvPnMuRPR9Sag21/ulZa9nsu8iTf5UlXKbPaibc9ZVYps0qZVcqsUmaVMquU
WaXMKoFAIBAIBA6kwyxEp2xLAeOqBj/jdxF0mBLrGtsQu+6d91yCWMuylfzs3kXSTfoloZskruZe
iqxlMFlL6u9LS1qmYMXqR55C/eiQVNYtmffrLUbWy+rueQt2kDwZoPCkfaVlxs5Hnrir/ttL+lq+
Ql87I0HV/wLEPczFfYY0TgYmoacnHieLBGui94MU3reFsT7IQx2cg/iau7xvK2VIBlcwQzJb4BZb
Y0hgtXEyssC1UmxhaOD8xTxkobHCwjmBYzhPYQHP/GG+Zv65iJW/QQ3nf62/05pXPXH+18r6va14
GmwW4s5k8qoyQjGXO3rO5W72XO3mMZe7CXN5PrJeltfnI7ajlAEaibIlVSUDNDP2DWfVFDNAo1BM
lAE6BUB9NUPRV3jujvY1d6cjVr5r4zW+QLHGt4M1vsBjjS9BfGVPjfEZ006aMWOq4Iy5JPYNJz5x
xhTSjDltZsx6RV/hGTPW14y5WMGKZ8w4xYzpDDNmnMeMWYH43PeLnaU7gPGB7wDWKby/hjn76QTU
Jjxn2qmSc6bLkQ/uiDtJ/kxU+NMGWtO6XlmZ08uQPy1c/rSRMqdFvAcoc0qZU8qcUuaUMqeUOaXM
KWVOCQQCgUAgcCA15hp0yuZKI86cThLUGPgiy4WT/iQjUeZ0g8DqnN1zJfVkchLqSeKM2A2KGLCi
NMWXonS9ghXnOKYqchytKy1zulGw7rRga8mTaQpPWlVa5vQ6T09aSSrbdIXK1jJB5vRqT+6W0jiZ
YQTNnF4rWBO9n6nwvgWM5ZkeGuFVnt63kDKns4yKZU6vVPiKW2N2YM1xDbLQUGFhThLtndjCpcgC
foMitzA3cAxXIAuqmT/P18y/ALG2YLIaO1+hfubAOJmfQP2saI7zcuRD2TN6fGzlSBmbBSi7UVUy
NhfFvuGdsTkPxUQZm1MA1FdrFX2FZ9lCX7PsQgUrrk9YZLMmqk/ot9uqT9CZyL0acatqHxYH4F5V
DvcSe930w11cDvdS4M4rh9urZmOlgjuXObvf+Xab8N+/Cf1+mv37eEdbJuyW5e1odyj48JPiy20+
/Ex3c1hVl8dXVc50O2Jyv8uhueTligp6eZvALXq5UuFlM/BypeTlZsTkrn1rFveSsxbz1Q5YU23W
bIFvE+JLc/FlS1GvqmDUtwrcon+rFf41Ffy7xdO/ppJ/ayro383l+HeBwr8mgn83Io4aLv+aSHPh
QmEu3Im+W1Nhf63CfmPB/j2Iw90+jaX2uaiC7fOfArfo3zqFf1mCf3d7+pcl+XdxBf37j3L8W6/w
r5Hg312e/jWK8eUzp/8usfnqAF/U5msYZ7oXMdV3MTWUmEoUTM6aej9iaupiqi8xXapgahBnug8x
NXQxNZD22wfL3W/5G9xxHzyALFjj32LFp8i/oT7lp8gMz/vZ1+z71dc87mdfE+5n/yJYd+LLkOJ7
yFd8fxUsiPFtUcRX2zM+fEpWvVVcPCX/TbDuxFdbiu9hexevWHwPCRbEnWmrYmeqAzvTVmlnetDT
1zrxOw4+al8XZrrFmgms1nXVmfh/EXdNF3dmjBufW97gs74KnVuei33DvRPgc8ubKCY6t5wCoL56
VtFXeB6+Ve46ozq3PKNgxTPmbcWMqQcz5m2PGfM/Ap8zY+rFuHGd0/s2N9U5UZ0T1TlRnRPVOVGd
E9U5UZ0TgUAgEAiEOJAW8A/hlG2drHGd0weCFlAS+50NsevedU5PC6zO2b1m3AJXGz7kZ3fmt37l
vxUxYD1juy894ykFq+U31zM+VrRMDWiZjwU9w13Z86TA6rRMDallPjFYwMqeJxQxYE1mh0KTSYUY
dnhoMo97ep/KxFzITtv7ZHMhjyl8xa3xaRLjxArAuzX+qxwLu5Jo78QWHi3HwmeBY3hEYQFrx7ur
oHb8dxQTz4Jh7XgPacenjXa8VdFXeK390tda+7CCFdd37LVZ/dSObCmHe5896/1wv4a4cVUEX1+/
sf3Guad05cr6L8TUPfaZr6zp0irybeBV5J/IWjqTe/E7X734KmJVVS59H6AXX0Dc3RXcBwL04iuI
W/Ummx8Ct/fzyIKqvQ/6au+XFX7jNvkxQHu/hLhxTTDn/ikA978Rt+otOYfQXQnPSNfyzEjvt5+P
3+/x/Px+4fn5bch6s9hnPtNqSZ78rPCkblKeqHLjoicvIk/c9Vp143dT3JNf+B7InEqQNOGu+/8Q
X6GLL02K7LAishTPyCpapfsW8iTD5UmK5MmvCk+qe3rCnwdo6uFJU8GTN5En7je8VJfGdGmAMf0G
slOLyWP6iCLKapUW5evIembsM4+ymnTPn5XqeMLv+afAPb91XbUz7fbkniLdfTa2uavS3ecXsW+4
VyN899kExUR3n6cAqK8+V/QV3keb2n1VsX30MwUrnjHZihkzGWZMtseM2SXwOTNmcowbVy40s7mp
coEqF6hygSoXqHKBKheocoEqFwgEAoFAIMSBtIBv0Cnbel6Mq/ZccWsuaAHwRTYJTu3NUxNVLhxE
rE1in/nZfZKUF8jhZ3ff+fkDyFo2k/WMFr70jEOINYfJlQstFS1TZP1lYUHPcFcu7EesDWKfecsU
SS3TKjVo5cK3yFp9JmsyrRWajAkxtPbQZPYhvlyX92Zca+fe56ZWrHJhL+JWvTGkTRLjxArAuzU+
QBbwWOcW2ibR3oktvFNODO0Cx/AlssDfeoK14zOqoHb8KYqJ9wvWjtuTdnzaaMc7FX2F19oOvtba
HR6sfJ3qbLPiCgBDuUJ9IjA5K5QhzcYugWfjxx5+cwtdfbXGRwpW7HePwH5vL8fvnr78/lDBirN3
vdBuw7N30UrLSL+NrLvzBVHJk94KTyKVlpHe4+lJJN7S3JM+ipEdhh3Yuu6+p/oOsbpHdjjGeg1i
7Yv6b4TNqgNr3zhr8Oz0D8gf9z2eLrV3P0V7hyotb/sj8qSdy5OQlJ3ub3viJzv9E7LD7whxq+cp
Wl2DVs9L0OoVjfV75EPb2GceqyZlxQbwdYKyYpQVo6wYZcUoK0ZZMcqKUVaMQCAQCAQCB1I5v0Kn
bPy0Ez/p5yvyJlMT5MO+Rnzud+JNlRSKgQEUineRHV4/j7nPtjMcfrjfR9z8mUnMPSgA93uIW/U8
3OBy9UjVOw1/QawZTNYjhyhUqRGeSk1F30n5M7Lu7vMRUnxDfcV3WLAgxneOIr7pnvFV9J2Upch6
zdhnHt90Kb5h4EleheM7giz0Zs6o4PENV2in09iG2HX3/PsVMaW7fJ0WH8c81zBCMbcXAqt1XZVx
iGoOt1vtXShl50ba3FUpOxcR4hOzc6NQTJSdOwVAfRXW5L7C83C0r7yOrmDFM6ZAMWPOs/5euMeM
CQl8zow5T9Kwx5CGTRo2adikYZOGTRo2adikYRMIBAKBQBCBtIAamnPK5u+Rwk92FApaAHyRLYBT
e2Fqoic70hFrPetj/Oy+QKpTHcvP7gnqVBM/v1AfWVPpGeN86RkZiLUuk5/sGK9omfnQMuMFPcP9
ZEdNz5aZL7XMBFsr998ytZA1/qQB1mQmKjSZcyGGiR6aTHXEV9/l/bkx7qHI+yLb+2Sf7KiGuDsw
uZ55UhLjxArAuzU0xTjBFiYn0d6JLZhC+4gWpgSOIU1hAWvHU6ugdsyEOSFqx9NIOz5ttOOy5I67
r/BaO93XWvunBytfp2YocjjzlCvUHwKTs0LNk2bjzMCz8YSH39zCLF+tcVzBiv2eHdjvY+X4PceX
30cVrDjTOA/tNjzTOMcz01jR5yl+F6w7PT8nvjdxT87lKwpz3vA3W7iHqac5fO632c2WIpuviGyW
Z2QVfYaiNvLEHdksyZMFCk9menpS0ecK6nh6MjN+b8HH0Hm2J34y/ZnIDt/lcL5nIeV7KN9D+R7K
91C+h/I9lO+hfA+BQCAQCAQRSL9L1ZyTNf47Flw/WKTICMxIkOlJQXxulWSGpAgsDqAIGMgOVwQw
91Jbu/fD/RtzuFWVq+cr2mQN2xC7rtIgmyFf68S4eZuskfT6ZVVQr88W4hP1+uWk1582en1TTe4r
rPSu8KX0dlSw4hmzUjFjVsOMWekxY5oIfM6MWS1pf8Wk/ZH2R9ofaX+k/ZH2R9ofaX8EAoFAIBBE
IC3gLM05ZfM3XeBa71WCFlBiXYNT+6rURLXe3QVW5+y+SqpcW51E5VriiubeyJqq1nuNLz2jB2Ll
egau9b5A0TLF0DIXCHqGu9a7p8DqtEyx1DIXppZfe5y4Zboha7z6DmsyaxWazEqIYa2HJtNV4HO8
Xxmvp+PeX2R7n2ytdxfEraqTXhe4wrGDR49yCxcn0d6JLeR4zCZuYX3gGDorWglrx5dUQe24saJf
sHZcQtrxaaMdZ2lyX+G19lJfa217xMrnDa71vsxmxbXeK5QrVCPBP2eFWiHNxssDz8aG5bTGFb5a
4wxFa2C/rwzsdzuP9uYWrvLld3NFa+A65KvRbsPrkJcnVeudzFv8G3j2/HLJk2sUniyrtKrztkLr
Op4skzzZoPBkaaVViff1bJOlkicbFZ4sqbQq8T6eniyR8rbX2Z74ydv2Q3ZUzxtcr4hycaVF2d+z
5xdLOasbKGdFOSvKWVHOinJWlLOinBXlrAgEAoFAIIhAGuSZmnPKxpWm/Ix/oyKrsShBtqoX4nOf
2hdJ2sRNAbSJNoIdkftmO//ghzu3HO5bAnB38mhvzn1rgDZpjbh5PgNzbwrgdyvEzd9yj7lvC+B3
S8TN3wSFuW8P4HcLhd9WZo2P7zt5PoQ5b6qYK4zpuoijmvUxPqbnxvjymaOux1xLc9Re7h+LeWax
hnWLo79uqU+c1frUyroahagBgwCDAUMA5wCGAYYDRgJGAUYDCgBjAIWAsYBxgPGAiYAiwCTAZMAU
wFTANMB0wAzALMBswBzAXMA8wCLAEsBSwDLACsBKwBrAhYC1gHWAiwElgEsBVwCuBFwN+Byi3g3Y
C/gKsA/wDWA/4FvAd4ADgB8ABwE/An4CHAL8DPgFcBjwK6AUcATwO+Ao4BjgOOAE4A/An4CTabHu
ZBpAB0QBBiAVUANQE5AOKG0AXIDfAL8DjgGOA/6w/nxrQ/g+IATQAWFABBAFmIBqgOqAVEA6oBag
NiADUBeQCagPaAhoBFifBeMScCngMsDlgCsAVwKuAlwNuAZwLWADYCPgOsD1gBsANwFuBtwC2ATY
DLgNcDvgDsBdgLsB9wDuA9wP+AvgQpgWawEXAdYBLgasB1wC+H/2rjwuq6pb73fgPahMiiIIKDKJ
IuAsoaiAigPOApZTzlMBopHz0PhpUWZZanmz75paqdXNND/FHHGe5wFUci6cM62U+yzXfvfLzbN/
v3v/uH/c+wt62ofznLX22muvtc4+x/O+ZwYwE3gFqBchRDRQH4gBYoE4IKAu7AeCgbGxQlwCLgNX
gWvAz0C1RkL4AdUBfyAAqAEEAkFAMFATqAWEALWBUCAMCAcigEigDhAF1APqAzFALNAAaAg0AhoD
TYCmQDOgORAPtAbaAElAMrAuXoj1wAagANgI/AhsAjYDW4CtwDZgO1AI7AB2AruA3cAeYC+wDzgI
HAIOA0eBY8Bx4ARwCjgDFAHFwDngPFAC/ARcBK61Rp61QZ4BzwODgCHAmhQh1gI/AOuAfwHrgQ1A
AbAR+BHYBGwGtgBbgW3AdmAHsBPYDewB9gH7gQPAQeAQcAQ4CpwATgKngDPAWaAIKKY+2qEPYDOw
BdgKbAO2A4XADmAnsBvYA+wF9gH7gQPAQeAQcBg4AhwFjgHHgRPAaeAMcBYoAs4B54ELQAlwCbgM
XAWuAdeBX4BS4EEv6HUTYqWgNzQjnsK5Hf+k0loNIRJRp9/A9iIU8kIrMVQ3bQbvoXJQhHwvtjpl
7qIqnUdRX47tgGpc5Zh5REw1/kalg6gDX0BmdRvSdgtMPgr5GcHPMLylmCD00x9/ZWP7V5T2Zt5O
bX9CZlNVfkcHaaOWmZtUF4Er2I7x4paZh9ibAS2bsO1XC1VCyfwGpjtsex/bIf7cMnPfwXsaYNsH
WX/e4vTBr2DmeLG2xVhW5Cjv/A6mL/p5i0aAftYrbaVypCTj6cktM9fB7LLwntnQdEsx18DQv4bQ
W2deA7NOWX0VzCI7/dsMaw1SFvjCbyuqskep7VzBKVMFTD8/Zqh1MZXAvG1hpqWN/2bGDVulwcwU
hKCSW5zz8wcsSK+O47E9L4BblnkA5l0f3jPQtzxjN/hTmvTUhyesn6Jm+wZk9qLnmdhOc+eWZX4m
vz0qKyMt+8q4ZaYijRQansF2P2g75eZkbkttmVJbppJ5DKaMzlrYvunLLTNlf2E2qJHecbD+alLb
dsW4w4IXDY6ZfciWIyoXPA3e86ngbPlRzZyHzB90JY5D5V5ltTeYIsTbV9heGYizi83JeIEp8KKn
KpAlkElV2iobvGetYNm1ajx+YPIrY5YFt4FKW02DY4e8EowYeFnFdbCcH8qbqbby+VPd4D00dpJ5
yeb0QVWD6wC9lykRfttqc2oLAHPTxp+pLYPf1qvZtsh+JgOlVm65n0CDI4M8SlmSomT8pYxNytiU
TA3JfCqZTxXzk4OrSqRgG4er+bnk4D1bsB1cBSsA5Z0DDvZXJ2wXIq4NVcXOEINVBz27MxU53vmJ
bcTsdnAcTMV2/0qoPYo5AmYfasdlwfnzocrT0yQD/cuktmXK6l1gChAVswT7YJZiNjl4FuhpBerv
sNJ2CszWEH77ly2MW5Y54eA9g7G9NYyvLJg5CcYde2KozzB6K5STOezguSSZLoiqKqqf4w5eyZF+
Gpern2OSaSqZpoo5KH1N2sjXgxWzHUwp/HUBeU1H3FORuEN6lI6lI1wyW8F8IXjPaBw6VzFbwCxB
+xEwFExfNdJtDn6CjqzNspW3Ogx9nEVsLsJ2EPrJtzuZUIO/D5GYKW7lmbNUXapx7GwI4JaZYjAt
Pfi7aX/x5JaZnbIiwc1PakiYYvY4uIrRt7m+UIFbZq6A6VKbnnfgs/M7FmdUXSZfPy4rI4YivqaK
tyIZVWRTfyRFrmL2kgzGtEewRycrJlz6gLw6BVVmosqF2gZne0PBeWRRTC0tc0HGKK0P6IiNyupz
Ds7Tf5NWU8syJVLmS8Fns+eUbeelDN3nIJkE5Z26Bo80xM4jbexwxk4dg8fymZ0j5JCauUiDI+S4
nSNkoaq9EbK+dbFz3D1yc2pLldWyyM7j2efulIkyOKpq2jmqaqp+Ygxef9CzYRTxRWo89QzW31Ow
9RnKB90MHgdVCpr1y4qhpyd6Yg/+E76huApVTBeDjyUtnqH8TBcznQ0+/6wTXJFOKaa9nLmxdp65
JMPJtDNlyAdxcjwRgsdzTM1pB4OPpXUOnbOmKh90kiONFjzSaGV1msGR2BhZT1p/Ek5tyQavNvoK
HtfHql53lP1QraLqXEkxDQze00pwvf5DzWmKwRWJvg+BtL6pfNBGznahnNM8h9OCRgZXPvIoVT6H
qnytDI7EZDtHYrIaaZLU1tXO0fvYzamttZQpljLFSiZDejTSyh49bnPK9DbYX7etHA92FYlZxGBd
dQ7MI7RlKufIzwXVmSHZbMW8IGeB9tARLmaMwdXiiYxRnhlscMTvt7J3BqoIGSa1XbZwP5eVR0cb
bK2vlWfOV83PKIOjt6uFo3eakhlp8LGvWjh6U5VMuuxnuuznVSXTy+Cc87ZyznkrmZ4GZz3pp6xf
pWR6GJz131k4619WMt3lzNFTb9TfaTXbQ2S80TdgU1yXqJnLNNj7pWBKq8JTNucKZYTB6z56J2Yi
qv8Ei5MZKrUdt3KsrlbaBhns4zUWPuINxTxvypC2AQbHs93G/murIr6PwfqvWDkXlqhaRXNIubDJ
yrLd1Ww/a3DE0/NfFPE3lQ/6Se8sk3GQaXfGaH/JDLFyxPsqpq/BEX/XyhF/V/n6OcmkWJhJUfMz
wWAfv449i3DN1FTZlm3QXUa+/okJwXpBMS+TtkBmqHUxeaStCmsjxqXtJYNz7YlMlfIy4w1ekz+R
qVJeZpyMRGKojjJD3sk1eHVG2qh1aRtr8JUrydAdRJdMjsE5RzLUumQmGuwVOp/2R1SNVX6bZvDa
f7Pgebqg/DbV4BpCMtS6ZKbI2NksbXPJTDZ4xkiGWpfMJDmnJEMjdslMl7bRaoMiZJWSmSmZr0X5
2KGfGWDu4y/6hv0MMJ3USJca7BV6mu8Rsv4bVfk+p/G48TPEFAf1lQXLpEdpD7VBKuK/NPiTC1cF
14b5KnqX00iRiX0EVzPORpL5QvZDNYH6oZa1lVC8Ac2pP3hnh+FkLpDVNfmubWIot8ycB5OMPUvd
eJ19XNl2zuBjz7jxSD9VMmcpqjAvD5DXU6n6ezmZM5Khs8AirKJPeDiZ0zQeN17DeOLMvraSkzkl
95ysxLLLlbaTpgx55wTNXA3uuQjjGq7urhw3eE+kJ1vPDMkcJW3YuIT4LLJxyzJHJNPUlxlqmTlM
vsZxHaElEfXnoY9T2yGDx14B/ayBJYVVnDI0A/2xJ92NfT7ScMrsNXitOwKeHGDnlmX2gFlgYe/T
6tGhmN1gPgBTCXt6W/n6jpld5GtoecWNZ7uR6ueWIWuvlevCcFXffgEzlmYMh/WowS1ruwqmhzvv
melVnrkM5gXsWYg9/aqUz4XrFDuQsaCfEk9umblpcBWj8yhd17vOp3fALIdMIvb8AJn+StttaXWu
YKvnqoi/YXBdG2Zhrb8q20rleAoFj4daZn422CaSyfUqL3NNjrRA8EgLlMxFg62lKy+awVBl9X0w
2+x8H2UoItJDrbh+NfhZ7zwrX/nnKZl7YL7HntexJx0yTdUs3DU4py8KXuV+YHUyCR4c8VugMR+2
5arqUg/MPsTlBBybjxPRPRUH9O5xugszDMwn7nxvgBl6uzddK1208BnKJUPvFCdfj7fyasDF1KWc
xl+drLxaG6qY5mAGwYJCaEsK5JaZZpIpEcxQy0xjWoejnwIcO9abW2YaSYaOJcYl0xBMP+xZiu00
Wssqj8aCSUTFexdaYsK4ZSYGTCPs2Y3tu2H8jfrM1PfgY+lh8VK0W5VMCJgusHaiYK1vq9pbC4wX
PP8W/ujqxi3L1AQzy8r6O8mVFzPBHnyPk76LqS2Yu4oJAtPfjcfTpYJzPNRPCznbuXK256o4iJaz
TdfMnn7lz1lRHjwvdDajI1qp/Eny4PsuJHPfk6+hmKkjZSbhmptkOlmcFiR7yJWjhc+0s5W22sTg
2CPYXgovzVFxEEG21eL75OTZq2o8kWCKcOxqnLfoiLbCKUN3Fegu0RZs50OmRFnQBsxyWP0AWjog
VpfbnavOMA9ePV0XnC3XlbZEDz6XUFwXQOYDm1MmlOK6GvL6Ea7NkMENYYm8/gGz1o3fa5MJmXXK
161lP5Mt3M9kNXPhkvGTFvgpC+gt9OarAHrrfUv0sxxyK2pxyzL0vnjzVQC9+5zWU3SfimZhi1px
0dvgzVcB9HZ2WgXQD60ChLKNvnuPsj7Kyudg17mE3vjwqKJck3vzep610RsmelTFegd7GgZxyzKD
JUP33Yhx3X+jt2k0rMhVf5BP+er/vGToWGJcMvTmkDQfnsuW0LpQydCbSmJCEG84lu4WHVEy9L6Z
0HB+185P4fw5E2bo7Tp0LK3Fi9AaStuzMq7fwZ7+uKJYrnxA77dODOKqT/0dVNFL79l+DM8fwB+t
HNyyDL0tne4qUc8JmIUsxdC74cfb6JMkQjQB01xZkCYjhEZK/xK1UPVD37u4Acz3Ql69q5yjNx7R
6nmn4Gz5UF1N0dubqE6/YuEjeiom05ShfsbIqCKr6QrshrKN3tdAlYKOokqxUUUivbmbrgq/BRUZ
zNfszPSVtq3C9iMkwgDlA3rDFt0bjpczN0FFL72VjKrXPcHXMkuUD+hdWnSXFSfbJ7JUS1jbCGk1
rQIoF0JVjNK7NOaB2UUrNJoRdZ+C3ihG6/jHVh7XYzXSBVJbrOCcKFZWD5cM3YkhJlrNAr0pI9jG
dzVL3bhlppfsJw4ZSf3EPaku9EOfr6PMaiIz66Kymj7pSLnQQWZJB6WNPllJueBh5VzYoCyYISO+
gZUj/nklM11GPJ3rKeLrKplxMq7PWTiu76hZGCujl7RQ9M5R2nJk9M6zcvQ+q7Rly+gl2yh6Nyht
9PlEqgf1bVwP6iuZqTJCrls4enNUVH0kmRkWtnGxsoCeA/oZZ5mjYCbjiKGKoaeP6IqVZOjc5ZKh
Z56uIW9WglmAI/Yphp7iovMp3dcpRdYPV1lPz45Rzp0A83YFfuqFmX/ImaO1GM2cXc3c63KkvQWP
lFqWeU3OKZ3raU7jVFTRZ3DJ+xaZC6674fQZeqpI9O9yVJFc11n0nY9Udx4JrjuPVD/05FgRkGHh
Su4azzTp0fmC74tFqX7os/9UD4ihI0aq+ZlkytCc0rcdUDZ+YuNsrK+qC33XxCI/9g6tID9QGUzf
7EC5sNCdc26huldD38LgzGnygWt9QJ+7W4kxLETe0LM+mcoH4+V4av1RVkZPsJxVPqAnCunqJhlr
l0eoB3dUzuVJC6jukAXxygf0eUqqFL9ZuVIsUytv+swnrW7Joyux7VDnbfrkI2X9Epn1S1RU0ecW
lzg4rmndvFDJLBP88x7Yr4AAxE9joC5WHinACoykEOjcCBkLlMbjHPWMEFdSEBlYHN1vJ4RPe1iV
hlU7cFniJtCzCyIOGAjMBt4C7vWCDPAQMP5bv3YJ+rXK9v+exWVlCA1RXXQQ6SIV/28neokQoJto
j6zMFEmiJ/bRnmeB3tjugraGSBEJop8Yh9/mYqDIE9lilMjBnhwxSAwRY8QwzHCM5GPFUPBD/se9
1Je9ZIqOoit+e2M7SbwEzdk4fhg0ZqPnYTifTYTsOPRMf4Vg73D839ySQWiH/m3J/ytL/o7Gvy35
37PkTzEd58W8xK6dy7z/+msRM8Dd+ig83YybCc69QsW5Ztwr4NZ8/doKM+5V0tnO60sz7h/gzo7e
W5QknuZmgUuLdrQ2k8PJv8yncMW3Zd5WYcNZwMVhhVQmf0zkeogm4sOZc0bQcf/1xyJy2i8SHsMf
PGPGbU0NwgKtgrsZ92FehsVNVLCbcbH9jlo8NdxGY6TV+wn3tJ3fDH3FWkEjNyH8c6vOlu0dq9sq
aeTiPbvZir9+MNuMq9x4LcmZ6nw45rZN119M9nv2O+/fiDEbQ+L4+XadXNd+Vjfd2K/6THHLOhre
yYyzpPZy6Oz8j0ZnHE2OFfcx447UH29YNP1lDc43dDrbZLZ1L161utSMK+rS110nN7r5DXfd2GNz
civaRw/Yaca199xX0aKZv9frn6w4fk/3eWacf4VCT9345nk/762z81jHr7x1ct9G+/vo5L4JDvXZ
5J0x+a9S9DzDvGkHfHjsT+sc0aJJZV1/aXEttFx+/HwtN6J7SeXcAJ9JZlx4tXlVKmv8uT37QZWa
3zToZRov7fx9dfPXvn9nX11Or87I8V3cY5K/GZc1Zpuvbm4/STnoq8vbKbGRVXX+zJ7crJq3hrvh
+141nVxGu1+q6eZ2Rq82frOH1Is1jfmu2X7hZ//Z14z7bdx8P90Y3smaVj3q5C8D2j1V54X4PGtz
9a5vFs8ykzvQpp5/+6D7kU+PQYgxWcf9dWOYF/PQP/er8O9N7aw7N6BP+yX1zLiCgBUB/ywdftTM
Z5Xc1gQcfnN/BzNuZkTNGjpb3phYUGPxnfDFZlx86xcCdTFRueG+QJ3O9+L/DJy0oOIEM26Mf2GQ
LldGWb2DdXE9wT4wWCfnGJEbrMuj7/w/CGmQFf6zGVfTuitEl2MX0irX3vZnvetm3JXcsNo6O5sm
JITqzrdz6+aF6eTW50wO051zIpquC9P5enGvlHCdzkvT0sNFdKjpmmHVoMzwvP0hC8y4KtVfDNf5
ekaHa+HeujmKOBWhG/uE6OsRuvHdtj2M0PXXMso9smTNrXwznSuzo+roasiM1NZ1dP3N9XyzTsnv
kTuf5oQISsyK+jIo6I/uf+0O/RV3XR2l83V04m9RujGceyGprs5nl3KO1n27atSHZtzRvquinxtx
0ceMe7F+cbQuJqb0K47xem1kKzNb3qmYGqubo+Q6XWN1+b50woFY3djTraPidHJvtpwQF77inQtm
nMew6XHbam14yYybNWRW3OKWB5eYjeHEuPzGOlvaTCxurJv375v5N/GvPDrVTO7d9AZNdLF0zqdj
E93cfj8wr0nPCkc3mXF9Wv3ZVGfn/Knx8Tqdpz37x+vm719e6+PdPx4eaaazc6dDz+h0Jkw5nXB+
XkKUmdzZmJIEXSztyazUQqdz3NiAFrp5H+31bot7tjmvmXGfjTvUQreGHiqqttT57ETkV1rOM3VB
otbXfl+21nHnhjVK0o1v+vCyZJ3cT6mRKTqufa90LRcdcjhF19+ucba2Ou6HhOFa7sXkF9vq5m9U
rfvtskZeHm3GzfHe095bM3+LvKNSdWPo4rUxVZcr74++lqpbZ/VJmtkhbcgdNzOuSXL1jmnfTvnM
jMsfcb2jzs5VEx2dbs2ZNsqM+y6ufSddfD6Mb5imG1/ymIVpujVDSd+Pu+p8HVdxYTfdHO1N2tFN
J3d7cG73+AahA804W45HD53OC9369hjw1urOZnJjRXxP3fiaGbN66nQGPmf01vkssGlGb9315uyh
A9N1Ohd7/ruWW9bn8/Rpye6BZjrrVd2fLnzO//60nBD5ra+kr/7IPmLIX8Uglze+YsbiXaJHgsl9
m8+afZShO//1HBWRqYvrsdbcTJ0/b3d+N1NXr8PaLc3UrU1TE6r30a0/cwYM7qOzZdlzbf+TvWuB
zqq60vve/5n3k4ctjn80RgxIeYYAKcQkxDRFCBgVEBBigIA8YghPX1AjpSxWxzpdlnmsKTpx6up0
WmQ5S8dxjSzbQcbVmYnWsS5XV8u4nFXaNWqk2mqlZvZ3zr1/9v3/e/IgmBCSyzr/z5d79j7nnrPP
Pvuce/69V2j5TL73o62Prhi/+fRTfjyvum/SStPYfLLx+EpT346ZMfMOU//98u5K471v71m92nRv
XU3HatOzP7X15jWm8f4da90aE8+X7ZfWnN00/UU/utnzP1ljkuuc7Kl3mtbMBx/82Z2mft+/7/vr
/vbFH17nd29T67Pr5i89+Wu/ezUPvtdg6tv0pZl3mcp7dOdbxns/GTep0dQu/3z97Y3Fb/z+v/3u
Ldj3QKOJ5z/u+q6R59y6P24w0d077w8bTTbYUfrPJtOzz6r4oMnE85aySZtN9xombNhs6tsfBfZv
Nsn8TbsPbzbV86+XTL770b0bfPcZVjW8frepXebsrd5iundu+8qtv68/dsCP56Rr799qoqva9uVt
pnrOm/vaNhPdwUVV2xtOvOE7N9bP3tdsorur/nXjvZ+tSr3HNDaP7L72HtMcd25Z4z0mng9f85Hx
3p4vFLSY+j1z7MwWky7/TlbjDhPdz+mxHSZd90z63a2Hfpv/rN+927+4t9X0fN++4b1W015Qdcs7
O49uPJHvR/dwwaRdzV9/oczv3s1VD+36+6OTX/a79/SXinabZP6mu1fsnv+7s1P86rJ08+92m9pl
g/XuHtO95StS95rKe35x2V7Ts39rUfleU9+ubnlyr3EPNzxv3w/nP//nfvceaHpln2k8PLZ+0b0m
mXhkZdu9pud7o+zH9+p1XPK9qbFTRp6vL958n4knlR64z/Tsrfe+dZ+pPRdkzbzfdO+KxXfcv3zG
4dm1ibf43sldh+83lXdP3t89YKrny3P+yXjPcr6TrmyirLYOO6ft6GdjToXI6rDxIz2aovKOS85P
aYoiGolTRCPhJWyfL+W0fSKTPdvZM+mxUJz0WKh/pKXBOGlpsH+k3kf0ITW3TpMVJ22y+tQ6Xop+
FYZ6Tv1TcleQ+lFwwhUlUjn1ySGV080b6iFvyMk7hezu/BFz/ojIP4UCgibFSJOSQDOFgpIuzUSX
5kM3hUIe2gwDbYaBdgqFvfRygAj6rB7op1AkgUeOL4+cXnhMUa65zBcvlwYqXH0njTJpVJN+r5+k
Q1OqID3/uY9aUdiuIWmdNy/3Ui8maf8lgcq9FE2AUVAUBUAxQJnpbzsO+WB8szNgIM1SpKeZtFST
nrbClbXZ5CE/O9wEfRBbeWhILxFV4vqdJDFE4f1pVtQqiVJl7USWowATBUCUQpXUROuomVrV0bNY
nCrZ/pmqyi9ni+mktpjK7bBmOjtKc6I0L0plUaootiprJ1BNcbyYW4qpPkrLVSV7s5sKfKwyXcac
qOWwdvnGmfbFwBqvGK9lTXPsvGK8NuAwTuDK/PpqgI1RPDuZZ7bm2enyTGDYL+tMMd3Ppvf+TxXT
/cH+W2mKRzZb/p1/VDyyQxdmrSk+WEGs1Xx4BdEXqy0AL6n66hZBpeqnhnPaOj7xFcU0upHFsJnF
cBs10ibaw8IYpbn9nBGGndbwkOqM3nkSV0CR1rCkrdKkNYGwIomP1iQS02R8PS23e6qfd+x59Evn
kGi188NvYh9gqYO6Nh4pxpZu0rhe6r4U6XEmrdOkb6aE/VQROarId2fAZ2bsdYfAZ7T1aafAZyLr
846Bz4Q10uYm3x2F7O65SfGaGu7TzsJFMOAvYB1lFMDxgbgQjw+Eg+Q+QM8ieJq7M+pUM4ifi4vH
7lkIT3KD7dHCezIcjlJig/Ushs9Fc9rOajF8LhpOTaIOejn4COLx1Jy25ZrD8dRwui+HUAKXZFF8
Kj2n7bQW56fSw5lGLuFETsnCmMkdrjkdywxn98gpksQtURzPZMdF+0x2OLdXblHq71xwGSwJy71k
Mf5jmjI0D7FiPfPZCJ/vRtI6vX828AW3TmfnoJnPw267eFAN2WG3hToMG/Z7l/JyZOh2s+0eKYhy
2pwXVH202wRFR18XDoKmr68Yfej6t3Dw0vZ/4eClv7CFg5fHhS8cvHwGtnDw8urLwmEEDJJBq+cA
9GryBkG59xEv8juqkfQKZAB9MQTTzqBOqIPfi6aNCk162pIbFQN6y3hR9c3nMBiH84garicFRrtx
lPRyJb2YWy6X3zpryDcY37xMG/bitM4ANqRG3lm5y1yIBvUs2qVimRi7VLwOPm6FrXhO0w6Od9d3
0F79lgYv/NXvsdDAXv1GI5fOq9/m6KC/+h1mqn4odx76vgDo3zucYXaOaWhKHeRTxpeAZh+gWIwa
i/6C1N9jeBfbujBrEV3yyNxG8JPWgA8pk6CBbhieDTQ6Jj+HeWG0YUcl9jJsneG/YX5BzzogA/9z
MhGzfEpOIh/4O9t+C5N5HT96gtZ/3Su5jJ6gvaTG7oBVcYJkkfu7NrEHFo2ER389OPrrQcPg6WVI
D+TXg/FLN5bYpmuO+otkqu+vCIelHTA6sY1ObMN7Yrukfwn5eRvPmtRrPA9ob3UkHSQcsaR5TIsI
OpLsoQT8YAL+RgL+NAHD06rE8JQt8WdO/sZ3f6PGkItPJuAJ73nxHgcnlp9Y368l4AMJeH8Cdvm/
7vCHZ1p5H57aJU5sL0SbkRiesyVG5AqJ4YFYYni4lBjeriWGZ0mJ4VlPYkTCkRjeXnu6D6/7EsMb
u8TwKCpxYv8jYojEiC4iMaK3SAyv7RLDu6jE8LQqMTz8SowoJBIjooDE8HQtMbzySgxPixLDC6TE
iKIkMSKGSAzPiRIj4o3E8AguMSIlSAxPpBIjCoHE8NwrMbyTSgyv4hLDi6zE8C4qMaJwSIzIN577
k37rqR+8nUsMr/4SI6qO3/2p7+vxAs+g8j488UsMD8MSwwOixPDAKCGij0gMT9gSw7uwxPB+LzE8
WUsMr6YSw1u3xIjKIjE8q0qMqB8SI8KLxIjEITGiBkiMyEoSI5KUxPAqKzEiI0ns6qcyp70RQUDe
R0QkieE1VmKX/qhDDy/g8j4icEkMb6ASI5qIxIiUITEiwkiMyA8Sw+u/xPD6KjE88UsMb7ISI5KL
xPAyLDEiq0kMr/ESwyu4xPCKLDE8qkoMr/oSIzKBxCpii7gQtUFiROGQGB7gJYZ3UIkRVU1iRPeS
GB75JYb3W4nhHVpieGiWGBEZJEZUBIkRnUZiRF2TGJGsJIa3bYnhrVZiRAmQGJ51JYb3eonhSdWT
P+M/vM+/ItUjj4hoITEiIEkMr7sSw3O/xPC+LjGiu0iMaAUSw4u9xIj6JTEiFEkMr+kSu+Pvw/e9
9syRh7z4bAKuavPiYw529e/5hPvRh724MQGfTMD5B724ycGIqEHigrdzieGlVmJE95MYnmolRrQQ
iRGhR2JEXZAYHoclRmQliRE1T2JEM5QYURUkRmQtiRGtT2J4jJYYEQIlRuQOiRHVTmJ4fJcYEWUk
hkdjiRE5TWJEdpEYUckkRjQLiRFVSGJE55MYkQMlRhQwD57xrKe/4BFcYlceXnDkAZGY5H14zZcY
XpIlhqd3iREJQWJE7pAY0b8khid8iRGBQWJ4c5YYUQMkRgRLiRHtRGJEWJAYUeckRiQ9ieGdXmJE
5JQY0fwkRqQCiRFtTGJEI5IYXq0lRsQCiRHdTmJ4RvfcbzzueR5EZpAYESglhnd4iRExRGJEGZQY
EackRsQWiRFZSmJEUJNYRQgRFyKTSgwP8RIj+ofE8OwtMbyHe/Cu2zz9gehZEiPimcSIpicxIuFJ
jGg8EiPan8SIbigxIoBJjAiOEiNKncSIcCUxvMtLjKhvEiMCl8SI1iUxos7KC1FMJUaEAYkRrU1i
RO6RGBE6JEbEW3khiqjE8AIvMSI8SowIRhIj6pTEiC4jMTzqS4xIjBIjQoPEiAIhMaJvSYxocRIj
2qfEiP4iMSIVSowIoBJ39XI1v/sbipHeS0z0GINjZNpjjHZZnrAdA/Kf9kAei5PjRU6SwxmQT3xv
QKW39Ys8hclTJLnfdeZCWS7otamH04XHh93Qe84Lv2re70tTax/9Pp0vr/aLx+pyu8oeGtAQO9oD
eR8G+IcDK72ubUAD/AcXSq4HsxwE+Q8PSMKaB0b+U5B36OyJ5LhgUlfWFtKS2lQmTdWkWxRp7KAu
uWdSvCe2mdTWpFfHQNp6sC+lTvUjHerrtHrqR3tpb/22YYQphMG5zieLy+g1Qq6ucmu/RTgTgVRX
cW8Ux5LCjp3vftvuvsTHt7DZjd8rlPO4ZHzT2Ed4hNp2OBAKhuxA8OueBRjRd53vetpEW2k97eCR
vpi/d/P3MtrOf1tHeMcwi/nYFApZthUJ2/GzGHI7ZD8+bqG9TNPAlHiTMaNIlZ4WDtq4jKXfSC1c
/jpNo2ocv5IOmrg36+krdDMt5BKJ5qlycik//X5130RTw/kX0W38CepKLpdogVPH1KBt9a2OMarg
z3V0F2H1MXuap77Gsiu5TXYqHjjBRjTH6ZlgMBCwrGjAVO5NXFILp61Mj6NG/LRh1ReUcCX1xe1c
1jbaqI4n4Rt7B7Ou7lttb1IHm9bTLi6ZaKEq0bLClr6cTEkl3qzquJ1aWQpwNCrGvbOda9+qyr5a
nSc7xEu6Dtv5XQ2V3jCt+siHC6vHrJ5+8CV1PCiXxXbCAtQkxveDFMg+KIrRZ/LcChQkn0K6FK9v
8Crzrzj9Dad/4PQDTk9zOsHpRU4nOf2E079x+ndOr3B6g9PPOb3D6X85neP0B04fczpyiug5Ts9z
ir5MlMopndNMTiWc2jgd4nSY0xFO2aeJijgVc5rMaQqn+a8QLeZUx2kZp3pOt3H6VP37iDrp/zh9
xP/e+RW9Ra+99V9v0Sv041/h4wX12ftzD/WVvqSW2Boh2lqTEqT0ytrx5P6FolNrC2hbDQtYcGpt
AxswdvRAQO32haPWrVErRQP+X3Qr51I5s2ZFD+gzk5pJpKI4DayjOGyuykjjv1TWZpLzV/2fYgoU
BnIbx7PU5rU3Un57GZUXRdKZTZDZBAn8V1IKFZBN2M9LYT21nsedO25jhLd+hfz31CJKq+Yh0tjJ
QyCv/YyV397JvKIZpyLWsZDFwyqXuI7zcVY0P86/jG4sP9f1OGEvfixVMe8NzH0n67BW5l3n6JeN
6rOZmvhv1Woce/bGma6i3KJzVKVqWME5GnmUx1iTrqc9Km8eG7EJT7qHOyF+alK1I32WZZFtYU7J
Unp0u9KjMVrKNYLmWMdpkyqfhZlVDHOcVkiZbZ1sYy4P5Tb+gh8dj13YmG5F069tDPNnkfq8Tn3e
UEXRCJUf+rSrKYpXEF/h/LkW9GYm6yfMcDvU00I7ue2sNXIR5ZAORnf600LmRda16rNIfV6nPpl7
djZpSdKGOp6qhIrLn6ACq4S55PDsAj2t9eB6NY+ixVEGdOpd/Am9W1NscYlf4NrZ/G2xPq+nJTxL
xAh7WDa3Js6cjlX8i+gKn3yzVb58T77xPvlKVL4xnnzjfPLNUvnGevKN9ck3U+UbJ/IVM3fkK/bk
m6HyjWc7ZC7Gjc5Kk7nGyDvZk3e6ynsF9xHLr8heze2A3NWe3NM493huu7z2Jh4CTVbGqTQKdNj1
4ceuYTY54DHPGQbxUidyDz1tTSbYRYvUyELfLGapg72iJSAMypLogXqKlaPUevU3jIbtzslzYpoJ
LI1lLCll5Ir6RJbIINciRNbZmD3W4VJZm+uR/Qq6SnGtUFy9spdPV7Kk2/ntHXbGqSjZZ7JPFli2
K2mSRxE/x/9Y4JEbr1nPspYZr082LawJ8zNfqeqBd0sZPjy6R3Q6XcXP+Ug4t5FnDBor+Mg6FdEX
faRkjurRmJCS6XQ91z3Hnq76oC4+Cr19kEZchMue5mt9wd+o62JlTWx1rLBNapytdzRVmO0L7D94
9U2pQ48xFeGR36zsNpQ0TdXvGvFUUQ/ldEVZYWvJbFAtmcpaGO2R09b8Sa5DJ2nmKpplNt7qRVnz
dNdPy2yYrlV19KPVT9pgz/ehna7KLiI3VKYffbWib7GrVRs2KP2+hTmAfgu31Q7VSrl0HUtvh+3u
1GAy8rbYMqfF8CY1wLK0iXuJaCL/CxRaoUIrs+0ZrkdVRGlIUhqSlIYkpSHJr24rHZ6Y3YIOT5xU
mUzXe7g+w+PoNJk455HPoKI1ivcT9hr13BvEWI0R7Nf1aiYpZN2UOGo71ajVpU001n2uU/e5in+T
GLWSv02TeD5LIOW5UtNWqbHkpUUrtDi9ksItwaM/r/3jiC+X+TyyXrPBJaRWaq2qZ2GA34D2048C
q4K1srJRYvTVmgmeKYoe47p8QG/bj6m6LHIkQo699Wp1sYWmsJ2RllbdFXEdZ+S180A8xcrQ4hnV
2g/7W1vvOAw90EvL/Tkl9yE1/zc4T5dOX1KmDmtHNibccVp+KJWSx40dAH1Y0DcoDlMFByU/ieRO
+blJ9JsU/TQP/Swf+jKHviyBHlIR5ZGr6U21n6mopwdmqtwblT2kLZQW2qs4zlB7md4x2qR1UwCn
fXJ5ZbqTy21SunGTonUtqFi8n3mtxPM221JZbYdD7gDYQ2ri/Msxv77y5QL0RRbxnOl5urnMgTVa
ANIPSVynxhbG4ixwy2lrsrrtvQRNUs7zAGu0QDlBUpMtxphHy6H3SyDNasaIESxn9M2rVovqmxRu
V+gN77w5hq0grkde+8lAPtvDagreErO5rtjCZfolr1p69ohwGdtZ62xx5n7Qlmpa2NFoC4c2ovVM
Pi+oMGa6bGXxBAVlJs9uRUJvdD/3Nq41Rv099hPqbGguP3e3JnZ7Qz63HnWZ3NJZbdWhnLY3zqNj
YG9fXe7qjgi3pP71m2sZj6d5jmXs/g4NVHiMNK0BxqsGVNL5Ab2kpDOdV/Ve+eqe6XMJurE5it97
qIYoxUmwRvX8rwVQwwzWE5t47mxhDnOVttjC9115KKQvo+9yGz+CcLTnclUmcYtmcrPxav9YqFkd
RMhXtkD3uicliPZay730QdfbgbVJpdyV8NToUbXC+KUq5Xr/UqR1okvQc8S5wBolR/qHWyhhl7Ik
sDdRRAucmShcaEUK9axQoOagQtXTBWoOKsyj+BpQjBJnfgtifosqG2yX6mm33tdQucO9B9bkz3s6
6yDWL0FtNbkSlGg14anU6lAdyC5hqbHo6mCJatFumkpnXQc53knaoqlQe/dqqUaY63J4jYfRnpWw
Cr2d7brEMivdFSlfkLQCqgiWqR7w0k73pa4S1JOdkierFkz8aR1yL9S51YEYWHWv2g3BUp+ypnGt
3JHlzmkhtnK55fl/sOrWBVtUa2ax/LvaegnPx27raGpIhU04P9SqevdrwVZu04ykX6LK+Xga1yWg
OlnVdRKpleuV5P7INbexw7YwTWPB3mTh9656ZlC/7ixk67yzy+38Wu7Fx4OPBmtVqd19KPWJtgwz
WJ+o8ir0ijtbrX7lyqGKprIueSJYlSBDkhexFV+r+ezhCu9ipXL4T049J9jYZ65jucgJngjWJUiV
7Fddo3z6Ksap02EIK4+K+dULLftSUNtH3b2RuDJP4dKUnVPW/XQY5SHmEuKnAJfXghVKdtz1RwXT
71C9ks/rfncW79Rqvu6K1HTFxzWRptNSbue3nVHmN1fNUHK0WM1QWnc9r2anc/wNGlnjGEuraxnu
4/oECikEmUjVVlVpMLfxX1V1ltt6c4Gtqy5MfIR2dkwrvjynjy/gGkfzYHKgubKENZgSpeWscx8P
PhFczqXlGKWrWtioV3H/qw7NsjDl5LXXcf2PuZLcwRISVKvVYtYp7l5AJD7T4eexWAGlcjtntZ2m
nLbSLuI8aYa8esWzDKsty82bbsg7Q+W9BftDtps3w5B3pspbz3ljATdvpiHvLJX3Vs57Np43y5C3
ROW9DSM96ObNNuSdrfLeznn3hNy8OYa8pSrvcs5bHnbz5hryzlF5V6jxpvNOYauP544QrPQMT16v
ziRnbQZ761t0IqTXoOuStHAW3RHXb9G06pXkWhvaXKPnMJOzFn+OMGZ3sCw10J3qXUs9yxjO1h2i
VVRZaC08tR9SPu38Nd0HxMRRR88pNsOF18u95zJfae5sq2q+ylmprSJoosT9125dcgWtJm0kKNML
IxkbknntR/AA5YfOd8HCkYsv7ELqNcIJZYVFeBzBwmlVb4P0OmcNdTPM8uglUN/G44CtlxDORub2
akfrsZPO7e7ah6XBPEdnjvXUqoJrws8criCTzgOnEK0FJ9aiiTywJ17HuVnCwpgTUj37ud225Z9x
62W2/aIrq+2brC5y8Oaqw66LPJKSnal6Ij3OGRwn0q3YSw3j5B52wvWbpBbH+sYbtzBWKRXF9nRe
H/LaKYxaBsVKJ51roDTVX2D+hW0e4fpGVEeX6JVTuISgxZtJ731jVml02su1o710ZaxfeB0ULutj
H8xQ9VyvbCvi8TuH5/KGMLSteS6HvhnHdog7cxKp7itPw7RF/n2odydawnp9pt+7Nqo22Ciex7Es
x8o5IEhjuInLWSFuwcqe9OtHmI/4TZp7DhTnJQs44XkwS2NHFJoCK0+cxcR5/29yOsbpSU7f5/Qv
/8/emYBXUWR7/PRS1aUBEhCQnci+iCwq8LEZImENTCYGgggYImFHhl0Y1LAjKI4o8gBHRAUCiiKI
CyCLLA4QQBARBniyKKCIE2QRRMj71+kbchPKcZk38+a9153vd27f/617eqs+VX27Tgfo3wv3gUPg
NNCnan3siZYgCaSCOWAFOAyOgZPgG3AROFidAqAkqAgagCagOUgAqWAQ0AOK9Z3TmWAOWAxWgx3g
E3AUfAuuAsfB9oDyABWaaoM2oDPoB0aAsWAOmA8ywFKwBnwIPgaHwTfgO3AVRODKowgoCR4EPcFQ
MBE8B+aADLASbALbwH5wApwGl1z/vyoVBeVBJXAnaAY6gBQwGIwFz4B54FWwGLwDNoE94DD4FlwD
UQifhcFtoCq4GzQC94B40AX0kTnHPWfSA01iCvjzedVmRrWpUW1iVBsb1UZGta5RrWpUL3om9bxR
PWdU9xvVfUb1O6O6x6ieMKpZRjXDqC4xqguN6lmjusOobjWq6UZ1rFF93Kg+ZlTHGNXRRvURozrC
qA4zqkON6mCj2tuophjV7ka1m1HtalTvN6rJRjXOqCYY1Vij2tyoxhjVeKPayagmGdV6RrW2Ua1l
VKsb1cpGtbxRLWdUSxvVkkb1VqNa1KhGGtVCRlUYVdeo2kY1W5rUq0b1olG9YFS/M6pZRlUZ1+yU
sexJo3rCqLYyxvXjxrLHjOpRo3rYqB40qp8Y1T1GNdOobjOqm3PUsTDjwHgwAUwEk8Bk0hdERE+A
qWAawHUEPUV+p+pp4sF89AyYAZ4Fz4GZQN/GmUX6mQpEs8EcMBe8AHRW0IvkDyF7CcwHL4NXwKvk
d9QWgkUgAywmv+P2GngdLAVvgDfBMvAWWA5WgLfBSvAOeBfoS733gf4RRHf81oAPgP59Yx1YDzaA
D4EeMrQJbAZbwEfkdxS3gm1gO8gEO8BOsAvoIdO7wR7wCdgLPiW/c/kZ2A8OgL+Cg+R3OA8D/Qvx
5+AIOAqOgePgC/AlOAFOglPgK/A1+R3Vb8AZ8C34G/kd17PgO3AOnAf6N+6L4HtwCVwGP5AeO0Wk
x+peBdcAJ1Pm1gm/Vqw31pXKxvOgglGNNqpljGqsUW1nVNsY1f5GtY9R7W1UexnVNKM626g+aFST
jWpHo5poVBOMarxRfdqoPmVUpxnVqQVy5/1Pc+ZuLDvF6GGyUR1nVEcb1UeM6nCjOtSoDgqpD+f5
JHwKrhn/714z9g9FL1J87JXN1mHrshVsuZjfaVB8U07x8/cU548qfpCe4oqk+Akpin8JUpzNrnhY
seJMTcX5l4qzahXf2lKcQa84z1TxT4aKc0QVZ+oqzu9VnNWr+FkyijM6VTm25dlGs72NbQW2FdlW
YluZbRW2VdlWY8tPilA12HLWr7qdLT8hSvE4CMXZuaoO27ps67Hlp6Kou9jyEwJUfbYN2HLOquIn
uyh+HoDiLFnFz05Q/AQV1Ywt3w9QMWybs41ley/bFmzj2LZk24pta7ac6as4f1u1YxvPtj1bfs6A
4qcxKH5mhuInl6hEtvexTWLLGbuK87QVZ88qztFXnOmvOB9d8VONVFe2/EQMxb8nKc6OVylse7BN
ZfsQ255s09j2YtubbR+2fdnyoFzFWb9qAFvOCFb8HCTF2c6Kn4GjONNdDWHLWfNqGNvhbDnPWOWN
vrou5/wm4hMen81Rm0Lfu3HK8ShyhNAZk/tdvQf08jy/N8R+PWpyfV6/TsWJpPunRXBqJIMKqOCd
wAJU7q9AC1SwUeAEKlEFVKFHcFBHgangP8B+cAJ0wWHeBz4DV8HAJL+reH1K1+jO5PUMbVb+N5aZ
E0P8O37eMj+rxFDu9MsV8lP3chW99DI3KHm/pZXrmeas5Mmr/1XTo/l41YDu6BPC82mE3KtY8EqE
sYMIL/Nx2n+OU7xhRz9JQScG6Jiko42OJjpy6Pigo4A+1/Ue6xHy1Q7Vtj9WW/clByBY34wg3RwB
uS6Cb3mE2+UIqqsQHNsiKNZAuKuF4BWB4HQKgWgCAs2XCDAb4PgNBJfuqI0FsA5fgWcQWppjYedC
66Ojo46K+hjriKhjYAwRj6LVcU/HOx3ndHzT0U1HNR3NdBTTMUzHLh2zdMTSkUrHKR2fdFzSUSkF
pIa2aRgO5XI0LWPROAzGWZWGnfA6nEzW6xdKvtBxWsdkHX91lNWxVMfNnF6OjnHZ2bpt87BcfcdC
j6wdCas4o0rfHRlJafy7/63Ywx2x9q05j0lny/wOPpOwr5ujbBwr94MkzLfHayHoeuSGvm+hR8H6
d6ZS8afvYzgo0walbCyhP/seTr151OFQ8jNxetEwLLsH33eK5lytoTyOYSBeLaqLNe7BvofxGIf+
iF0D+f5IP5QpiGUPhd6Xrf52H/ak1yMSe304j6v1737EQf0D3wsaBS2NnkEEywBLQEns4zqgHqiO
SBYDYsHrOGk2gs2gHfZ9KugJzqACuNjpEpzEAb+mDzqOi35UR0EcgMiWfqTbAPbF+xH1lgLDsmem
/wrbuWh2sXTdhujWQd/p1GfMLbc9h8+wmlkpHOJllu4J6FQ7VBUa6Prx3QrVHT0vQ+/1xfgusrKi
dK+TPF2Vz4ML4GJYHs90hPoXtvi5PA1xMZz0kZ+7k5O3UyUsXychLEdHX19en37hmyvhb975yTe/
xfVPL+e/t9gvm1roG8wUtyX9Z0v+sycr0q8NtxTBqaIHRTyAEyWns6DvvemhhbpKyTwD2/2qpHic
hh681gXf1DfVzalBupup/9uSP2ytSM8jlh4ZVzSUIpObvsKDjgQ/qR6nOd8OvF0Hdpt9Jxp9685r
ZZSQ+n6/FdFSUJGe0ddyhk73gU9/wOVLgnJ8RusA7LDPeKNP3RUuixLs0/Z91rfCfdrYVzlD8kuR
HgKnvbU2eruLvbm+Nye/N50bhSXp4ZzNalhtEc70bc62Rk+6Wx5J+vv6hq2+ARxTxQ1LDqiUZ1Re
W34c/U/5qs++ZB5fAr7qh3JS8vvy/o4v3RwXRwlDCpkMDRXPzSJD46HIT5cx+WrIvpTJV5COFqSj
Belo18vWoyAdLUhHG0JBOlqQjhakowXpaHrrgnS0IB0tSEdrQUE6WpCOFqSjBeloQTpakI7266Yg
HS1IRwvS0cxTkI4WpKMF6Wg6HS2Vh+D498l09zFIR/v/MbTQP+45kx4AFaSj+WqQjuarQTqarwbp
aL4apKP5apCO5qtBOpqv/kw6Wh41SEfy1SAdKUhHCq4ZgnSkIB2pIdsgHakn2zS2vdj2ZvuvTEfK
uSb2CY/P5qhN9I+lI+nlef+EdKR0MB3sBIdAAg5zJtgBzrXX/3k9SEcK0pHm50tH0jkQ/07pSHp9
dHQM0pGCdKS/l46kI927IDPej6j/ZulIWZX0Z7LepAnV/7xswoj6g7LfK5DR9W/Z1CcUBI6N4z4P
1QuVddyo1Qf6T01eUGXDTV8f+b791tnZ9OkDftm2A6x8Zae89cPh/kf6bmtVqcbzu5YNXJ5No0Mh
qfxf8pcd0bN+9zdSE1NGnpm26uLuaQ2zKcEvQrMXiXxlnT/sbPlMwttPq+Nt5tVKLjs8m74LhanZ
n+X3W2bd/QuWFls7IXl804XjL5U9mk3Ph5rFaV24d4j67JcVYu7gQ6/cduTrpaX6NG1cfM75pdgP
hUJlj+X3W3xi44Rzz3ZMfaDMkwtOznv37WzySvhlz2X5ZXP376ZV/cadueP0LDr+vV1u/KlD2ZQe
2r9HDvnbZofK3jjladB5GhIq63lftJ3WtkXShio1m519KT499nQ29Q2V+dN4J1/ZlJePP3z1+Ucy
S+xb00vN6hFW9nKobAyVO6uPNrfv6X5L/z064FYk2Vk64EaTytJdZr15QunmxcnSXcpIcrkCWnRT
VhTdONl0c5bf1Q51OrTDzHiLokIOm8Ojvr6OohJn3dACtPPuKPOLnbu+c11eR7xYy9f19QShdjxE
EbwnWlh6CY9b2uM6Sy9zu9Xsc/Q/LF0tsq0SpA9jVJZ7fQmFeb50mO8ioWXyLyY362gfkaW/lU66
NZrK+lhr/fr1WEIU/28031/DMH9+z6BgaDnJ7DuTcrfnw5DvilZElu5bPE56E2OtuXi919Lnsb8l
cRu0/5Yb9PXF45b+p2jpXP3GWrPRuR9v6e6avxbrWf+QlU08v93aidXeyfP+lk/hquDiLyube96I
GHNBB16ZAjqWxNDr+EIuKXqz/e3j3n5o+3RLpLfpVSt3mzaGbdMwK/82VQ3bpjG8TZNu2CYs6jdu
U3n8ZWVXpapUjSpQDbyrRaVwPpfEmvI4HPQhiuKcKImWohQNxudDUG4Yys8Fs/H+ObRc06kwTcB+
GIUWqR/flbe5H9IUr3VAJegl8HlBlPNQ3iZ9ZVeV/2LQOBj237+SsGMVG3as2oSOlT7KOefNptCx
ug91uxyZz5t5g/KfMS3CvFalG8+YzYYzphPOmM0/ccbEhPkbzfM5Z0wn9t0lbI0/CvkeCt81jGuM
2pJOofXeaeniede+edjS9HV2/n3yl9+0T9qEeW1CN0aorSGvPx2hPub/s7ibbV7fDcJ83xXyPQWv
LxfwfW8LW2Pd/0wn3ef0vep/xKxo/Eb9C8E6Jxr9TYH3itZe86/w9GsKVvRldFJzXnN0fy7q+nJz
1iGG53OOUccbtnX7P7CtbcOWo4+U9j2Ocrc1M6xu6f5vOum+7y/ZypG/97cw5zVH9+f8pXfIt/Tc
rUziNUmMzI1zu3JqIuJchUi/V6b3QTel49xumRvnWng6znXw8se5zOzMXx3n/Mt9YWdUt0janfdd
y77HtiGus/UemOL4+3W3lZU9nX5v9aYBVkf6oxVHU6y7aTai7xKrDK22itAeNPifg9MWIr6t6Hb7
Zoq3C1JXdDAH2MVolF2WJtlV6Wm7Ls21m9J8O54W2m3pLbsVrbbvoUy7AR22a1GWXY0uotwVcM2u
jE4TIoJTDfM16Co+uxrSLRwV6ZShQk4ktUKsTndsmgEWOC6963i01SlAe5widMgpRSedynTWqU1X
nEbkunEU4cZTYTeRirv3g1Qq7falaHcAVXQHURV3CFMd1AS3u8PAKPAY1XHHUV33cYpzx1AndwT1
cR+m0W5v+rPbiz4EX7v9qKB4mG4TQ6ieGE0txDhKEk/SQ2IWDRULKV2soCfFe/QnsYaeFdvpRbGf
Fosj9Ib4kpaJc/SOENZqUcxaLypbW0Rja4OIw3yCtVZ0w2sq3qdB72PtEP2sT8BhMcA6LoZZ18Ro
K0KmWyXkFKuinGHVkYusVnKD1VUesgbJy9ajsqT9pKxvz5L32fPko/ZsmWHPkB/Y0+XH9mR5zH5c
XrCHyav2cGk7o6QANzmj5c3XeVQWdMbJws5EWcyZKss6T8sqzixZz5kn73EWynjnDZnsvC0fclbL
Ac5aOcHZIl9wdspXnF0yw9ktXwNLwTm8b+TulK3cTJnkbpUD3Y1ysrtGznPflm+6S+Q6d578yJ0l
d7kz5G53utzrTpb73DHygDtcHnIHyyNuX3nUTZPH3VT5hfugPMH0AKn8egrvT7ndQLI87SbKS25H
6YjOMkp0k2VFD1lZpMlqoresKfrKWmKAvEMMlHXFYNlQDJFNxTAZC1LEGJkuxsmXxET5gZgqN4FM
8YT8VEyWR8H3YoK05Dh5kxwry8mRsq4cKFvIHjJJJsquspV8SDaR/WVlOVhGyOHygpgjL4m18qo4
Jh3peUqW8oSs4dmygXdNxHo/iHjvgkj2zoie3pdiiPdX8aL3gXjLWyo2ei+I7d4ksdMbJHZ7D4AW
4mPvDmi3ik2eJdZ737hbva/dT72T7n96x9yvvM/dLO+Qew5cAFLtcIupdW60WuHWUK+4jdUk9141
wk1QaW6iut9NVgluZ9XS7aJi3K6qrttNVQElQCTeS3DF6aK+dTqro06y2uV0VFudBLXJaafed1qr
5U6cWuJUViOdaDXAKad6O6VUihOlujhS3edc8do7WV5r54LX1LnkNXAue/UcUrUcoao5EaoiypVz
iqjiTjFVyCmuJL57za6oLtg11Wm7ljpu11aH7TrqQBiHoR3B6xGev1Pttxuqj+3Gaot9j1pjx6oV
9r3qNTtOLQKIKeoxu53qZLdSte0Y5aHMD1ZTdcZqrI5YDdVB6271mVVT7bKi1RZLqVXWGW+Z9amX
Ye33JloHve7WAS8e842hVbd2erdamV4Ra6sXaW3xClgbPc963ztPy7xj9Iq3l17wMulZbxM94X1A
Y7z36EHvTYr1ltBdXgZV9RZQGW8RRWE+Wy6hM/JN+lKupINyFe3B6za5DD2Y19HvX0Sr5Bx6R86g
5XIaLZDp9LwcSYNld2on21FF2Ygui+q0G6wRNSlD1KJ5og7NFHcjosTQQNGBuolu9IBIAWnURfSj
TmIgJYpB1B6vrfE+VvSm+ihTSyQiOrWksiKWiotmFCEaIfjfST+6d9BFtyZludXotFuRDril6SO3
GK1wC9E8N4KGuy79Do1PbRDl6twTiz5BpN3iSHrPiaC3nIK01ClEi50oygDPO6VpGqL2Y059GuG0
pu5OM0TpOlTXqUhlnGJ0q3MLFXEKk8B3LqCV+MK+ifai1dhsS7Q8klaBlbbLvIT5aWAESEO5bnYE
dcZ3OqBVibNLUxM7mura1akaWpZouxGVtGOpqN0OrVBncuzeaOeG04+4BvjRmgymgRl02ZpJF8FZ
6zn6wnqKDuCzvdY4tHTptBbll6Clm2l1RsvanhKtDtTYSqDKViKVte6jYlYnElY3dD660xX0DC7i
mv0COEp/pJ00k9bQSlpBm2kx7aX5dB5XAYWtZ6m2pdvPV50M53+4Nx8QEBDwX+xdB2AVVda+773k
TRJSCSUhAUIagUDoEHroLfQSeg29hRB6C4oNRRFBkV1X3FVhXeuuZV1BURRQRBEQkA4iTUGKoKiY
/5x3Z+67b+belPfy/8D+N+63M8yZc+45555b5tz7ZhQU7mZwWan63FM2rvWZczy7fc7xtOZKSORK
MLIIe0w5HhAG58td1+lzOX0ip3kFQ2oLTqprPwbLDvRlJRg5sL2CEvpACXtNObACWwBXQiOuhCSP
EvpYvPR1MbzU4OlxhXipFVeaKBO236tMWEtOarwulc95H7gLc97NOJtSiDXnfVDlvO+YnHdzQV3x
Uf2NV1HdlJPK57wNqYd8yHk25mRnEGt+97Agv9u7lPO7DTgdaL7Z6Hl6W2w94oOtnbhyjDw5n989
Ksjv9iq1/G53rnTXPjlmZS9LnBzzKk46cyXgfjxzr33c5167L1eC0b/yep/wSu/+nNRqxFovJwX1
0lNaL1X1/WN4xLpoo0dfGz36DLpReh+u9ETXuVEvPS2anBJo0kOqib9eEh5FEeJv0qQfp0m8hyY9
LOtc33KaGOtc3QsZ3etyslM9ZHe3xMl3PsdJPa40UY2eEfixW6m1tEyudM8a7WbR5KxAk65STVrp
JeHxx55UA+NoXOc16cZp4jmn6mqp0XOCGu0Cs7ZzTvHKZQQnO9xDdhfLvOf8XTjvoTa57TPPey6o
ec8dM+8JE9QVPy5879W4UImTGkms49nFYvRTqKO8nwotQu9LXukdzUktR6zztR99mMMEcLIjdNmP
End/dpmTjSNbPsF5z3LX9dKdtfmbNHH3P50sFl/xweJYrhwUY56hXuXqyJihdgSL8XppjShVOR2o
3YatHYl5bf6aEZV31No8UtXavFqbV2vzam1erc2rtXmi1ubV2ryCgoKCgsLtApdFcnBP2UY2hl85
v27KxuTjUzQ86V93FrZyHmyS6n5272BZOb8hKKE9lHDDWdjKeRlpCe0tOauffc6tB5lKM+esfvEq
Z1WRk2rkrPgM8s27MIMcyNkkyiD/qjLId0wGOURQV3xU/+ZVVFfgpIoysb/7kJfUBBrzmdhbgkxs
O+hLbpV6JtbPpIm7/2lnsfgPHyyuzJVj5J75TGyBIBPbFiwuKMVMbBWTDm5b21r6WptGfOxra3Gl
YR7aPF7Y9RL48aINWIzX5eOFjZNaxsOGNhYbHD7bYOdKCyLWWvPjbDBqLQNswOulVWtRnA6uNxox
izMs+vgL9GkN+vgXok9J12XLc/qU89CntWVdNkDXh1+X7VxI7cZxsgM9ZHe21G6Qz7Ubw5Vm/Dqd
7zfLmCK0eP1mOZMN5jWOYENvtcah1jjUGoda41BrHGqNQ61xqDUOBQUFBQUFBQNcnjOee7K260/W
I4n7eT1Ef7K+F57Xcc++cE8riDMyAiiDvpLQ8wm+GleOjbgzn0aWJVSQ1WhVyCpKoklvd1ajFcs5
GBmTMF12A5BdVpfdUriHPcGkpVtqS4tnIortmX2rC/NMElemUQN8TqZsMXIyaJI8JxPJlWD4ns/J
RHqVkykrkMrnqcoJarQFWe66LvJ9TU6eZ422sPikQnF8YopKT+2TBdrzWb+Kgqxfc9C+YiFZP/6X
PqIspPmXPjU4Hag3DYubW+ooyqs6SuNKEFkZLbCyGVgZXYiVJf0VUSqng2f+sZllNaCSrk9h766U
1WgdrhyRrTECW5uCrTGF2Jqn25InsTXPZGttTgfNdW7Y2tSlT7jNnbOM1fW5BvqcIO6c5dpYzFlu
D3XnLAcSzFmmECNnaUQ4lv2hyzdGhpL2NOjlA5yHKsB/l+He1faR8ES4hbxsj7OttufbFgJOkwy7
n504Eh2N7RO09f79AoMCM8rkRW4P3VThsRC/SlnBk6IC/HpF+9kbVyJkY0yeLS42D3TMsw2N3QTn
fvYIUo6u271ii5PiZXQ39ZHTZae8v6tcjLaNlhvWasQcCSmCErAtGZFQRTAepEMkVGGRYEiqzkmi
uwGM+ky3jDJVBVKbCHu63pzUaA+pTVxSOxO3N6qB1HyuF7V6o8BDdi+TbLN3430eTToWUUKCrrH3
JXQoooREn0voKSiBH7uSBGNXY4iQJMnYNYiTV811btRoY5dsfudCsi77btq5MNDF4bYPbeJ3LlTn
bFI7F24DuLrKEtQVP5NI8WomMYSTGkesLaaGoMU0ghZTQ9JiBnDy0l3nRotpZGnvNX3us4ZxpSUS
69ygtmBu0LCUd0UM5XSg44phcUOXPvdw+tThvNlR16dBqa1+Z3OatPPQpIFlZbWu4Xu1sqpWVtXK
qlpZVSuramVVrayqlVUFBQUFBQUFA1weZhL3lI0ZaSOrYTzj1zflYfLxGlnuui5f95zKSU10nRvP
7vUteZNWxcibFL6bexpXWnlizSW19iqXlCOQymc/MgTZj7RirboV5/16U7jS6e9xDA+mWTRpI9Ck
dqmtjE3nNCnvoUltS36trSC/VquQXf8TONndPGTXssRJu2Lk0wuPk8mm0szadxBoXxNivYMkOziG
k5fgoX1NywpJxxKukIw2yTZ7o5PP2cbBXAlxghI6+7x+MZYroYqghC4+2zBRUALf8rt61fLHcVLL
EXecGFLxS7YZQYWv/+Kq3y7Br8FGcbKjiLVXyRS05TrSttxQb6sNJW25oaktj+dKr+k6NyK2jmUF
qDu3WnK3rACNdHG4e03zClAPzia1AnQbwNXVCEFd8W23p1dtdzgn1Ri1+T6+l6CPT4U+vpekj8/n
5NF36hktJtXSYnrfhS1miYvDbZ+5xfRRLeaOaTGLBXXFt5i+XrWYRQKpfIvpJ2gx9aDF9JO0mFxO
nud8sZ5lBtDf5xnAQoH2DxL3eDqA84mxZlq3lNdMZ3A6eFpc16JPlkCfGuBNvF5aK6f3cPp4vj+5
hmXldKBRA2rlVK2cqpVTtXKqVk7VyqlaOVUrpwoKCgoKCgoGuGzMg9xTtpFp5FdOB5myMcBIUuBJ
f5BW2MrpcpNU97N7iiV7MrgY2ZPCV8QeFdjAZ5SGeJVRWiGQyq9xDBWscVQvtZXTh02luz1Y3aLJ
MIEmyaW2cvqIVJNkS5ZtuCDLllTIyukDUtlJljgZofm6cvqQqTSz9iMF2idCLI+U5Ajvl2qfaFk5
HaWVbOX0PoGuvDdG+5xznMOVECMoYUwx/F14CUu5EioLSsj22YZlXAmilj/Wq5Y/l5OaRKzZ2PGC
7GcCxMn4QrKfJV3jvJfToaPr3IitBMuKzQRudeNuWbFZ4OKQr9hM5GxSKza3AVxdzRfUFd/KJnnV
yuYJpPL7EybrUgvbn9DqOO5PcBCz7NmcbNHehyk+yJ5VhOyper/pjey8ImRPA9kZRciW7dmYKZCd
Qtyj33TdJ8b9K7n7w/T7+REtxzRaFjWirRXI438pPkOXx/+mOx561RmsVzUkPcVJ8nyjbLxFy9wS
avmkSbZZy5kCLauBljMtWq7hJHnufavGtDSk5hm9HUgN1qXGmeSt5uSFeciLs1g9q4RWP2GSbdZv
tkC/qib9Vkn1q2rRb04J9Xu8CP3mCvSrYtLvMU5GqId+VSxtYZ6pLTzN8Rrv++bLny8ov7Kp/L9w
Mjz9U9ninwUl9M8zJtlm/RYK9Is16fdnqX6xFv0WlVC/PxWh32KBfjEm/dZJ9YtxyWtL3PW3RJcX
CfKcurxKTNKznCTPd0JUskjKF0hy96nPcZLiPCRFWSQtFUiKZpLWc5JiPCRFsz7I8P4LRY63xhvc
+Tr4G1cCxj9K5Z8iX+Tq1HiKLCedz+7Q56s7JPPZHab57F9NpbvtK2exb4NX9j1vKsFs30aBfWWl
9vFPyaK3ipufkl80le62r6zFvr/ro3jJ7NtgKsE8Mr0kGJkiYWR6yTIyvSDVNZIYMw4jaj81tXSU
WhGk4nXRM/F7nOxwD9kVXbL555bPjFZ/Fz23/MfF4TkS8M8tOzmb1HPLbQBXV+8K6opvh58X2c+I
nlv+LZDKt5hdghZTAVrMLkmLecckz91iKrhk8/ucvtJlq31Oap+T2uek9jmpfU5qn5Pa56T2OSko
KCgoKCgwcLmAt01P2fhkze9z2mPKBeS77lnuui7f5/SWSar72T2MlWBkG/Yaz+7E2/0rbwps4PMZ
+7zKZ/xLIBX1NvIZ+wWeCQHP7DflMzx39vzTJNXtmRCLZw5oxMedPW8IbOBzMgcFOZlgsOGgJCfz
ulT7YMtayDe69sVdC3lNoCvvjUPFiBM0QO6NV4so4XAx/F14Ca8UUcIRn214WVACnzs+fhfmjv/B
2WSsgvG54xMqd3zH5I5fEtQV39ee9Kqv/btAKr+/45Qu1Zu9IxuLkH1ab/XeyN7ByeZ3RRj96xld
b37tKVzYs37ASWrsOjd61nBLL3LO517kfa4046vVfC2e96oWt3NSRTuXLvhQi1s42Y0Fsr/3oRa3
cbJFb7L5wWd/b+ZKEPn7olf+/kSgN++TSz74+2NONr8n2JD9ow+yP+RkRxHrivRlblZirEhHSFek
z+q/jz8r+f38WdPv5zdxpce7zo2WFmHR5IpAk/LF0kS0Nm7WZCunied+rfJsNmVoctUYA4l7J0io
adb9ESevr4e8UItl1wSWlZFaVtJdup9zmnjuAC9j0eQngSZBUk2M3wNUlWhS1aTJTk4Tzze8BFli
+roPMf0ZVw729GYrbwisDCw1Kz/lSo9ynRtWBlrm/LHBbk2MOf8QmPPjddHIdFwqe4hl9llZl303
zT6PuTg8eyN+9lmFs0nNPm8DuLo6KqgrfhytqteV5zhaDzzWgDQkjWDm0ISkk+i4mSSOtCHZ8F8u
GQvj+kywvR5QQ+A/9fff9tcXWk0viONMqPUsMgHaSx7UehxcG0Vy4CwXzqdDC6JXxpDJcC0PePrC
f00s0YORouLkbvorah59xHWXZ6/Cj5hxghFzMIyYcZIR87BJnnvEHOySze9cqqbLVjuX1M4ltXNJ
7VxSO5fUziW1c0ntXFJQUFBQUFBg4HKBZ7inbMwjG6t2RsY93pQLBEYyCJ7a44ML27l0kZNa1XVu
PLsPsqwLJhjP7l7vz/meK60aseYzE4X5zKLyGZc5qYnEunMpSeCZgfhlcVM+w3Pn0llOaiXXueGZ
gRbPJAf7unPpHFea6Ovo1QU5mQCwobokJ3Oak1fDQ/sAttZmaJ8SXLKdS6c42aI3BtUoRpygAXJv
7OFK4GPdKKFmMfxdeAlfFGFDqs82nORKMN56xK8d1boL144OcTYZ9cKvHdVWa0d3zNrRN4K64vva
NK/62oMSqUY/VU+Xyu8A0oQ91AGTJHcPpVlaY32fW+N+id5GCQ288sbXAqm83o191ntfEXo38Urv
vQKp/Op9M260MVbvnaW2I2UXV7rneoHToklzgSb+pbYj5YRUE3/maUOTFoLI9oMRGK97zqnOc1I9
I9vPJfVBTmpLrv4ydakOkNqSSfV9d8oPnD6eczyHxd+tBP62l9q+jUucJrU8NLFbdqe01jXxZnfK
j1w5yGv2eobA6zbwekYhXi+prRc4HVJd54atNsuqWBujn1CrYmpVTK2KqVUxtSqmVsXUqphaFVNQ
UFBQUFAwwGU5v+WesvlfOxpP+m0F6yZDC1kP+46TF+o6N57ah1oyFO18yFB8yZVj/H6Gl91eX+Hw
RvZXnGz+V/CG7A4+yN7NyTb8zecjOxaZjxS90/QqJ1X0jZVOgqxUpjRTU9J30l7hSves80yLfZ29
su+aqQSzfV0E9g2X2lfSd9Je50r3fIvBcIt9XUGTjBLbd4MroQVxR4VhXzdB7nQYWe667tn+fuIk
RXjoOozFsbHWkClo25NAKl4XrTg4bW7ZntneSZbVue667Ltpdc7fZJ95da4HZ5NanbsN4OrKz2at
K74d9vRqXcchkMq3mF6CFjMRWkwvSYuxm+S5W8xESw67t8phqxy2ymGrHLbKYasctsphqxy2goKC
goKCghlcLiDE5n7KNt4jx/+yo48pFwCMZAI8tfcJLuyXHeGc1Ip4yp7dJ1j2qfY1nt0L2ada+O8X
orjSRPmMfl7lM8pxUisQ6y87+gs8Mx4809+Uz/D8ZUeY1DPjLZ4ZoOfKvfdMBFea8UsDPieTJcjJ
jAMbsiQ5mSBOnudX68a5ZHfmtB+oa1/cX3YEcrLrEOt+5kHFiBM0QO4NmyBO+BIGF8PfhZcQYPKP
uYQhPtsQKiiBzx0PvQtzx8TUJsy542Eqd3zH5I7p4o5nXfF97XCv+to/JFKNfmqEYA1nrLCHumWS
5O6hxlpa40ifW+PvEr2NEkZ55Y3fBFJ5vUf7rPevReg9xiu9bwqk8iuNY7nRxlhpHCNdaSzp7yl+
MZXurvkxbGwyNBln9CjE/YbP0aY5TAWbW57n2yxHWywbL7BslNSykv6GoiyniadloyyaTBBoMlKq
SUl/VxAp1WQkm1sYMTRR18Sblf6KXDnGKMev90xS6z1qvUet96j1HrXeo9Z71HqPWu9RUFBQUFBQ
MIPL3wXb3E/W/HdsjPzBZMGKwIhCVnrKcPI8syQjLBmBKT5kBDSuHP4dVYbsaXru3hvZPxO3bNHO
1ekCn8why13XRTnIapyu5VyyDZ/MseTrc+7CfH2cyT5zvn6GytffMfn6qjZrXfGZ3lyvMr11BFL5
FjNT0GJmQ4uZKWkxVUzy3C1mtiX3l6dyfyr3p3J/Kvencn8q96dyfyr3p6CgoKCgoGAGlwtoanM/
ZRtvuuD3es8y5QLy8Ro8tc8KLmyvdyOTVPez+yzLzrXZxdi5VviO5uZcaaK93nO8ymc05qQa+Qx+
r/dcgWfywDNzTfkMz73eTUxS3Z7Js3hmXnDRe48L90xDrjRj9x2fk5kvyMnMBBvmS3IyDUzy3NrP
ZPvpDO0X6NoXd693fU62aJ/0Qp93OKZJatQoYVEx/F14CQmS1mSUsNhnG+oJvMTnjpfchbnjyoJ6
4XPH+Sp3fMfkjmNt1rri+9qlXvW1tTmpRrvh93rfo0vl93rnCnuoGJN+7h4q19Ia7/W5NVYqwhvL
vPJGLYE3eL3v81nvVIm/jRLu90rveIE3+H3ID3CjjbEPeUax9noX5y3+0dKan2HR5EGBJjmltuu8
psm7bk1yLJosF2gyrdR2ibeU+mSaRZOHBZpMLbVd4i2kmky1rNs+omvizbptK64c0e8NVgisnFJq
VraW1vwUy5rVo2rNSq1ZqTUrtWal1qzUmpVas1JrVgoKCgoKCgpmcDnIdJv7KZvfaWo84z8mWNWY
XMhqVTNOnudT+2RLbmKlD7mJGqZyzLIf19cfvJGdUoTsVT7IrivxtyH7CR98Up2TLdrDv9oHvZM5
2cZb7nnZT/qgdxIn23gTFC/7KR/0ThTojStrRnw/bayHEPebKrJNMV2ekxGEpyyms13y2hJ3dt2m
F2Rkew39iEszlOrnCITz1g7MPhlS8SwZrzrBakAHQEdAJ0AXQFdAN0B3QA9AT0AvQG9AH0BfQD9A
f0AWYCBgEGAwYAhgKGAYYDhgBGAUYDRgDCAbMBYwGTAVMA2QA8gFzATMAcwDzAcsBCwC5AOWApYB
7gM8ADgKVh8HnAJ8CzgNOAM4CzgHOA/4HvAD4CLgEuBHwGXAFcBVwDXAT4DrgBuAXwA3Ab8CfgP8
DrgF+ANQQKuT2AAOgBOgAYIBIYAwQDjgOjSFG4CfAb8AfgX8BriFTaQS8APsAAfAD+APcAICAIGA
IEAwIBwQASgLKAcoD6gIiAJUAsQAFsdCXAKWAu4B3AtYBrgPcD/gAcCDgIcAywEPAx4BrAA8ClgJ
eBywCrAasAbwJOApwFrAOsCfAX8BrAc8B/grYB40i/mABYCFgEWAxYAlgHzAUsA9gJpJhKQCagFq
A9IAdQDRNUB/QGXAjDRCvgOcAZwDnAd8DyhfH1onoCIgChANqASIAcQCKgOqAKoC4gDVAPGABEAi
IAmQDKgOSAHUBNQC1AakAeoC6gHqAxoAGgIaARoDmgDSAa0BGYA2gLaAd9MJeQ+wCbAZ8D7gA8AW
wIeAjwBbAR8DPgFsA2wH7AB8CvgMsBPwOWAXYDfgK8AewD7A14D9gAOAbwCHAUcBxwDHAScApwDf
Ak4DzreGdpYB7QwwEjAKMAbwdjtC3gH8G/Au4D+A9wCbAJsB7wM+AGwBfAj4CLAV8DHgE8B2wA7A
Z4CdgF2ALwBfAnYDvgLsBewDHAAcBHwDOAw4AjgKOIZldIAyAB8CPgJsBXwM+ASwDbAdsAPwGWAn
4HPALsAXgC8BuwFfAfYA9gL2Ab4G7AccABwCHAYcARwFHAecAJwEnAJ8BzgDOAc4D7gA+AFwETAa
uvw9/oS8QvALzRBPifSY5+pp7RohLaHzvR/OnwkBbe1IwX7TodEr2B0chfZ+zG7wXINe6QR06hvh
PLo87eUo5RZSytM3Ku2GfuDvwPNmBkq7DJQV0JEfJnQPw8OMEgvlDIN/TYfz69C1Nw4zpP0OPFvK
0W90oDQ8UsqP2C8CzsJ57VB6pJSbcHUASNkC5xWqQi/BeH4GSi/Q7Qk4j4uiR0q54aRX6sJ5OLT6
EzbDB9eBsjKUSlsfCf03886vQBkC5TyMFkA57zFpF3VLkSckhB4p5QJQPrXRK8tB0mVGOQ8UXA3B
r84sA8q7TOtzQHnGD9dmqNRYpkEk+O3lctSjeOwWaPCUBcrQCpSCRzelDFAesVFKCwf9N6X4w9nF
ypSyOQ56cptRP7+BBv0r0m/UrImmR8rzC1AeC6dXRkTyFD+QBsII7voIAe0Xstq+BDyfQ8lL4Twz
gB4pz/fot1sFBShlVwE9UkoQWgoSmsL5UJD2jb9BuaJLy9KlZTGeP4BSgKMWnP8YSY+UUmCibGKW
XnVS+eV1aZ8wSgBoMFWjMbMLWste1hZCNHrlWUJbywes5oL19gNFkf0g8nOmdRhQjkK8/QPOX4mB
0cVhUEKBsjkUd1VAKwGeTkxahEavvEMo7zvMngpAWREBtUzoMYZJq6LR2EGvVIYYmMPiurJeP9hu
Fjn49lNRo1fQduSZ5TB8UE6j/QB+l6kl+G2rw5AWDZQfHfQ3tQXgt/dYbdv0chYALtrpkZYTo9HI
QI9iK2nHeKJ0HofO42A8lXTKszrlWUb51kl7lWRCdRzH6uc7J73yEZxXLgszAOadL53UX13hfBvE
tcZ6scNIgVkH7t1ZBG28m0s3pHzmpHGwCM6HlYG+h1H2AmUX9B1nCG0/T7J2egh5QP4GXdoGpvWn
QNkMUfEQoT54iFG2OGkt4G4FLG8Pk/YNULbG0a9/ORLokfIccNIro+F8awJ9sqCUg0AJgCu1scwE
/CqUQdnjpHWJPN0hqsqycvY76UwO5aNd7nK+1imNdEojRtmt+xqloa9HM8onQLkI/joJ7Rrv+IlF
4nbdo3gv3uHm2QqUvxN6ZRLcuopRPgLK83B8CpANlCHM0o+ddAcdajvNwWudAGUcgdh8Bs5joZwV
fgYlXqPvQ0TKQn+ecgR7l/I0djZF0yOlHANKi2DXNJf8EEKPlLJD75HAza4+JIFRdjppL4Zvc50S
SI+UchYo3avhfgc6Oj9qM6LqDPr6j4ICpGDEV2HxdlSPKtRpGDSKXEb5HHnApp2EenQBoyTqPkCv
LoReZh5rC9U02trrEdqObIxSVUo5qccozg/wjveZ1sedtJ3+Rdcaj5TnlM7zEqGj2WCm2wmdB/Mc
yNOMeaeGRi2N86OWNnAasVNdo7Y850cj5CtWc8kajZD9fjRC1rG+N0nv37r70bi75W9I66T3lkf9
qD27AgyeFI1GVRU/GlVVWDm1NTr/wL1hGPFHmT01NSq/D6HaD2A+6KlRO7CnwFo/wyi4e6IPXIH/
kch4eApllO4avRelhMTTPV2U0k2j48+7hPZI3zBKR73mZvjRmmujGZQOQgr6oI5uTxKh9nzN6rSz
Ru/FeQ6OWYuYD7rqlqYSamkq0zpTo5HYAFo9Sv2WGNLaanS2MYRQu/7E+usuejnYV2HvXIZR6mr0
SitC++vfWJ2202iPhO9DQKkPMB9k6LW9Ta/T2U5Dg/oa7fnQo9jzOVnP10qjkdjWj0ZiW2ZpG11a
Dz8avX/4G9Ja6zzHdJ5jjGeA7tFkO/XofofB00+j/rpip/HgxyJxGlJgXnUcKLfgWMDaHPp5c0VK
Qd7pjDJFrwW8gne4KZM12lu4eDSeMlqjEf+FnXpnBIuQsbq0MzZazhnm0Uka1TbSTmsuktXPRI1G
bw8bjd7FjGeCRu+910ajtxPj6a+Xs0Qv517G01ejbS7MTttcGOPpo9FWj/Kx1b/KeHprtNX/y0Zb
/RzG00uvOdz1huUdYrU9Ro83fAM2xvUpVnNZGvX+RaBcLAeechgzlPEanffhNzFbQu8/12ZQsnVp
++00Vt9k0kZp1Mdv2+gd9zPKSCEFpQ3XaDz7Oaj/2rOIH6hR+WfttC08z/oqrENsC1vslLcXq+1B
Go143P+FEf8j88FQ3Tsb9DjI8jNidJhOGWOnER/JKEM0GvHX7DTirzFfD9Yp7WyU0o7Vz1yN+vg+
uPIMPDM1YrpN1zDLSJ9/asfBfIFR5qC0GErBo5syG6WVpdKQ4pY2S6NtzcVTlufJ0+ic3MVTlueZ
qUciUrAfpRT0Tq5GZ2coDY9uaTM0+uSKPJhBdPPkaLTNIQ8e3TzzNOoVHE+HQVTNYH5brNG5/4eE
1tNJ5rdFGu1DkAePbp6Feux8qOvm5lmg0RpDHjy6eebrdYo8aLGbZ4muG842MEJeZTxLdcprhI8d
/MsHyg34F75hfwBQujJLX9SoV3A33y1o9a+znu8FtMef7iHGOKjFNNigexSv4DGWRfxLGv3lwjlC
+4a1LHo3oqXQEgcS2pvR1og8f9fLwT4By8EjlXYK4w3QBMsD72zXDMpJ1LoKzdq2jKdHSjkBlLZw
5UV/Os/ez3Q7rtF7D/tTS59lPEcwqqBefoF2vQh7/1CDclin4CjwDMyiDwQblENojz+dw4TAyP5O
GYPyjX7lYBnKu5FJOyikoHcOYM1VoiUfBbvGsezKfo1eSQ6h2lMK8uxDaXDyHcTnUQc9Up69OqVR
JKXgkVL2oK/hvi4gpSX0PzfDDWlfadT2QCjnbdBkW1mDB2tgGFzp7099PkEzeD7X6Fx3PHhyuB89
Up6dQHnaRr2Ps0cno3wGlNVAKQNX+tnp8x2lfIq+Bin3+NPars/Kuazpfa+d9gvjWP/2A1BmYI3B
bb0r0SOVdg4ovQPolaWhPOUMUKbAlXVwZWhZvi1cwNgBHhuUcyqEHinlR432YjiO4nO9ezy9CpSN
wNMSrvwbeIYxaVd0rXMJ1XoVi/hLGu3Xxtqo1OtMt4u6PdsItQePlPK9RnVCntxQnue8bulmQi3d
zHhOa1RbfPLCGoxnWt8Aysd+NI+SDREZzGZc1zW613u2nT75z2Y8PwHlLbhyH1zpDzyNWC1c02ib
Pk3oLHe13aA0C6YR/xFIXAG65bLepSZQdkFczoV7V8BA9BOLA/z2OGZhxgLlzwE0N0Ap+HVvfFY6
baMjlJsHvymOvs6z09mAm1ID2zT8q6udztayGaUJUEaBBttAWpsYeqSUxjrlFKEUPFJKA5yHQzmb
4d4ZYfRIKfV1Ct6LFDdPPaAMhSsvwnkmzmWZR9OA0hJ6vMdASu0EeqSU2kCpD1c+g/NrCfSN+pRS
K5jei5vFL8JxK+OJA0p30HYeoVIfYX1vVaCEgucfhn/08KdHylMFKA/Zqfyu+syLUioH0xwnvoup
PVCuMUosUIb5U3u6Bxr2YDnN9drO1Wt7FYuDVL228Zk5pAI/ZqUE03rB0QzvaMXaT5tgmndBnhsh
9BmKUqrrPPPhmRt5utoMDdoG6zNHGx1plzNp1ZAC9+6F8xfBSytZHCShblVpnhw9e47ZkwyUo3Dv
mzBu4R3ticGDWQXMEn0E5yuA5xTTIAMoG0HrX0BKZ4jVjX7GrDMhmM6eLhDaWi4waS2D6ViCcb0Z
eFY7DJ54jOvy0K5vwbMZtOB6oIn+/AOUd/zpd22ygOdd5uvWejkLbLScBazmEnVKBV2DCkwD/Aq9
eBaAX71vAeVsBL6Xq9Ij5cHvxYtnAfjtc5xPYZ4Ka+EjNuPCr8GLZwH4dXacBeAfzgII0w3fvYet
PsVOx2D3WIJffLgVpM/Jw+h8nkrDL0z0LgfzHbhSL5YeKc9onYJ5N6S482/4NY16QbTXHxXO9/4j
dQreixQ3D345JDOc1mULkLqO8eCXSmrHQbzBvZgt2st48Hsz8Yn0WzvfJtLfmVAKfl0H78W5+FE4
akzaID2uH4Urw+CJYiPzAX7fumUs7fWxvN0sevE723+A57+Ef7Ry0iPlwa+lY1YJS24GtTCNUfDb
8HkO/CUJIQ2B0oRpkKlHCFqKK1HrWDn43sVNQHmL6E/vrM3hF49w9ryD0NbyJHuawq83YT99j43e
0YdRsoQULGeyHlWoNT6BXWK64fcasKfAu7CneJ9FIn65G58K3wBScmX6zE4pQ3TdXoXzW9AQhjMf
4Be2MDecrtfcXBa9+FUy7L1+IvRZ5nnmA/yWFmZZYbB18WJfQqWN17XGWQC2hXgWo/gtjTVA+RRn
aFgjLE+BXxTDefwfdmrXH8zSp3VpaYS2iWNM63E6BTMxSElltYBfyqjsoFnNi/70SCl99XLqQIvE
cuq4ehf8w9/XYctqqLes00xr/KUjtoXOeivpzKThLyuxLQTbaVvYxDTI1yO+rp1G/EjGs0SPeBzr
MeJrMJ6Zelwft9G4vspqYYYevSgFo3clk5ajR+8aO43eQUzadD16UTeM3k1MGv4+EfuDWg7aH9Ri
PIv0CLlgo9Gbw6LqKZ2Sb6M6rmca4D6g72GU2QeUBXBHNqPg7iN8YkUeHLvcPLjn6Ty0m1eA8jTc
sYtRcBcXjqeY17kIrX4ca/W4dwzb3AGgPBJId71QyoN6zeFcDGvOj9Xcfbql/Qi1FI+UZ5lepzjW
Y53WYVGFv8FF79v0tuDOhuNv6LFHwnU57JHcz1n4zkfsd24R2u/cYuXgzrGjgAE22pO77Vmse3Qt
oXmxFFYO/vYf+wOk4B0TWP3MF1KwTvFtB9ga/+ygrbEW613wXRPPVKDewRnkataC8c0O2BbWBdA2
t47lavAtDEabRh+45wf4u7tXwIZ10G5wr08W80Gebk/V3woKcAfLEeYD3FGITzdtYe5yC/qDq6zN
zdY1wH4HNUhnPsDfU2JP8bOd9hQb2Mwbf/OJs1v06Ctw7mTjNv7yEVv983qrf55FFf5u8XknjWuc
N69jPBsI/fspE8aV7nAEXAcMh1AZA9Bc/9ld/8/f1w+wRnp/JcZTUAAuIRVJZ9KfdIL/70D6kjhA
T9IRojGLtCF94BpeGQToB+fd4ViJtCPNyFAyE/5rQkaQ2WQ6mUhy4EoOGUXGkMlkLFhWW6enkWyg
jylxKbX0UrJIF9ID/usH523ILJA8He4fCxKnQ8ljoR+fB7wzoWT8VxxcHQf/L9ZkFByzlSb/VZqo
aFSa/O9p8jtZAuPB7JY9uhWEmf+zkXygXX4qsb+IthRoAYFBq0S0e4D29mvLXhbR7kWZHUJfEtEe
BNqRSZ8fbUOstIeAlpnqbC3ig0GvIHzby28UhNmJg/hx3DAzKND/BHy9SUPy5NKV4/E+zz8byen4
DAke90tTEW1rp1iYmAQGiGhPzh5g8yeBfiJa2tB9thAJ7X1tgj3MRbPq+Xr2PfZACd/cxBfsMl0+
6VLRUUbClx7S03HstV+Wi2gRDd5BPqHMm5OvOGTl1Z7+uN/VJy7VFtnQMm+tn4yvx1C7v8z2c+EL
/aftS+wqotk69XXK9Pxn/cPOhl8fGyii7a2Vp9kk5U0bvUKTyczIah9w7NU3L4poR7sPCZDxTWpy
KUBme1pObpDfpOE7RLSOIbuCbJL6u6/WwaC8nb3WiGhRgdtCZPatCRsZJtPz6y7/CJPxvZEaFS7j
e71yfPiWsAELzFy4jr9m8Zfh1HarzPHNG0bIysus01xKW5G+Vkob3+tURG50+HwRLbH8mrIREn9+
Mv2XslVer9tXGC8doiJl9ddxWLdIWZt+c0BO5Pre86NEtGmTP46U1e2f2+2OlLXbhWnJ5WT+nL6g
cfkwCe1S5OPlZXwDOvxQXla3+X0zKiwfUzNNGPM9pldIPPLXISLazzPXVpDZ8Oi0xRVTDv4wvIOl
nyfkhWkfVuzxwLGHRHxfZtSM6hh7I9lqAyGTp+2PktmwpvbNqNx/JL4l1LPGquiBHZ+vKaJtjn45
+q8Xx+0T+ayM/9vRex74orOItjSpSiWZLvfP21xp/dXE9SJaeuspMbKYiKi3K0Ym8/H032PmPx00
V0SbHLUtVtZWJtrDKsvieq7fiMoyPuf43MqydvSvqNVxdaclfi+iVbF/GidrYyczI6p9/HvNCyLa
2dyEajI9GzVrFi8bb1fVmJ0g43svZ0GCbMxJavRugszX6/u2S5TJ/G5x/0SSGi+cM7w6Kitx9hdx
T4toZStOTZT5Or/z+cQwWR0lfZMks31u6oUkmX1XHDeTZOW1SAlIPvX25RUima9MT6ku60PyO7Wu
LitvVcgD1U/9mrzDSiMktuW0lJdiY3/rZS4OyjvW480Uma9TW/6cIrPh+JQ2NWQ++y5nX41HyqU8
KaLtG/Jq6uDxp8NFtKm1jqXKYmLh0GO1Q5dNaCXS5dGgTmmyOmpbvUearL2/OPfLNJnt/e0T68j4
Hmgxt07iy4+eFNGCxy6p83HVTbNEtIfGPFRnfYvdz4tsODBzRQOZLhnzjjWQ1ftbjaMaRkVM6iTi
e6x/3YayWDoe3qWhrG7fGjG7YZ/AfVtEtIGtfm8k03PtovR0mcxDIcPSZfX3n9D30gP+NC5ZJLNb
16+aymQ2W3io2Yk1zVJEfEdqn2omi6WdWWWay2TOnBHdXFbvk0Ifa/6TY+UyEe25mV81l82hs0m5
FjKfHUj+h5QW0unpllJfV3iptYx2fGz9NjL7lowraCvj+7ZTcjsZrWPf/lJaatyedrLyPp3paC+j
/bvZOCltatup7WX1N7HqjQ7TJpyZJKKtDNvZMUxSf8+EpXSS2dA99P1OsrbyxKTznWTzrIFtlnbO
HHPVX0Rr2LZil8w3Fj4noq0Yf6GLTM9X5zm7Xl65eKKI9q86HbvK4vNmer1MmX1tJ6/LlM0ZTg35
Uw+Zr+sErespq6PP22zvKeO7Mjq3V3rd+BEimiMnuLdM5smeQ3oPf/jNbiK+GSS9j8y+xtpDfWQy
YwZr/WQ+i2k0oJ/seXN59oj+MpnrQ/4mpW0Y+EL/xW0DYkQya5b7oj8JP/GrlY+QFa3P9n/zKb/x
Y8xswDc7L2jA+k9J72aCvM1zjZ8aIBv/+kxMypLF9Qx7bpbMn1e6PZYl668TOryYJZubdmpWcaBs
/pkzfPRAmS4bBrcfROPTSntt6qpBUZN2bBTJrLowdbCsbb6Q/fpgWd2Wb9BwiKz+jk1uJ6Wtnjts
mIw2qvPuYTLbN07tPlzW3p+yjRouk7nd/tHwcxPrfyDia9Lq5nBZXEeE1x0he2a+f8neEbJ6z5//
0qi/fPBqdRFtYt47o1r13nJWROu85NJoWd0G9w4dIytv1axDUtrHFVOzZX55t0ZWds39N74W0VrP
X5wtk/nK7GelMpv1+nWcjG9B85/Hy+Zga8kXE2S2N2p7ZYJMZt8WqZNktNGx4ybJ6vY1R/4kWcx3
mrN8kkzPP/WsNXnVvHHCPMPQ0fsmy/zSdF7HKTLa1emDp97ot36pSGZq0qKpMr7201pOk+nZvNme
aTK++zPbTx/9z/3CsbFfk/k5Mr4x/fZJaXuHBs2Qtc1H5iTNkI1xV/tkz5DJvC/hupQ2t1K1XFm9
h1ZomCvry58Ky54p4ztAnpwp6+veDJ6c9+CFcu+IaFkx8/Jk9q2ufSlPlgvqmHt61trx/ywn4ruv
WursnAc2tRDRure/d/aLa2ttF9HeqJM8RxbznSYPmtPq2rk0kS69J12bI/PLONvFuTLawEFB82Tl
/adHi3ky2x/PzJgnq9thuS/Mk+Zwnc3nv9rqP4+JaIsnfDZf1h6eHJu5QBYTKwcvWyCzb3+LrQvo
c5yVVjdum1Tmvh6TFspkkvSlC2W25y04tFDmz9ZhDRfJaNE9hiwa2GB5k65mEtC2zF6+SFbejMi/
LZbpub3pW1KaTT9a/sIJCVu22x6xbO0f5bf5E9tuO/44jaS57q1ovZ+UcXEEaIwjQHP2hPl5b8D0
FGB753LhrOv9Get6/5Kxpvsx1nS/krF6mihglXtngo2xTrAVyzueHCUqDPWse8taFcT1Y1jTXwAh
rjvpjhnXnca9/oXc66/fm0bs7vs1+f0ad38acXA8gVKeQBNPGvHj+crI+MoI+NKIvwdviIQ3RMKb
Rpye/HwD4fjDCuFPI5pJRoRQRkQRMtJcr6SS/8Hjkq/BVXzWAGANoKwbSsh6e0rlWH//X2+1XGGz
b4t3Dv63l1qarCWPBJLhyTEB/xmAHMkO5PAxZkrqx9veGA9edkhYw1ysO4A1nbLusDnbdQ0nHuzn
7rZA/z/08u1hvUO6EkLYNIE1OHzrUaMAW+MA0q5rCsSRA5gcyBRI2pEJZBTJIXmurWdxjMs6/6nr
Kj8DZkxb6Iwpw+6kQpsEkKYBpHkAaRFA2ta0tesaSzrXZMX0rUn6BZCBLiWLmjdVE8zKaBlNA2y6
aEMuE1qcCVaUS/BI6GnW/+4SPNKhCzZJBXnFnYCVd8m8DDLDqczLhkyTwBLNzlxC82Hqnf+bS2i+
X8lnaS4Z4TDzv/yrS0a4v3ezNZccfIIYSeXAE0RxZm0O/ZWfhA9BV1df1xmxbPdNYSiWIW0gDHMg
DKeRbDKRzIVgDCDNSjgi3HW9hgcrvdFznMQ/h4u1M0TaUMra2eF0sbDWamGRDcY1yEB7Yfp5tj2P
/uXybenVfr/7BnYfS/0/fTb+/zLZoi5l/ZL7z8X6OrD2oqwHA52irojoXZEwMyAYGYvMEAhaW7Ey
BYKBrNgZA8GA9f9tbBJmFMLdY5NLVl1nsTILpTCB9+I5ShqA/8PetUBXVaXn/5z7TMibgNEBvWAM
iGAhPIw8NIQQMfISg+CLBRgUnAARwsuZ1gipk+Ish05dzqB2CQx2rGvZMrNstY5LQS1mHFRwtU67
aqcZndVxqbMaUKtTZ7j9v3/vk/zn3JuQEAQi2Vn7nnzn7P3v17+fZ5/9FYXalbgoFA2Tl4CuVbCF
izNuoxnGZ9Iq2V0r4X7OsM1GefdHo3EKZljXavhcPL/pA6OGz8WjmSm+w34JaRRxX2Z+02IjYV9m
NCuthEhASqoqPpmV39Ri1PnJrGhOp1KiQUmpypjDBW4k7cqJ5nUpKZYiLaiOrXntqt2aFy04obQ4
9bQv+BpMCcv93hJ8c4AMNJu5YW09fo73d+fSPL1nY+CTzp22ttM2fO5zy8WndSDb55ZQ+2DG/vhs
no6cudVst0sfRPlN9gVVN8dtysfh7k4clJ/uvmJM469nEwe/355PHPz+T27i4Jdx8hMHv5zeTRz8
srozcTgHKslpi2cv2tXUBYJyfxJP8Tuqc+kVSC/K4gx0O6e1Qz39pdjZQoXx2uLohYpevWU8pe3N
V1AZ+3KN6qs7BfqLsd/rGfUqBIjRaOn9TZf+9b6mjZPWJp/LevLW/0nSyqHGwXtb8+RaSjFxGwrn
/ezfv7l90RMlBzI+bP18zs93JulfbzFuq+ucgNvmn/zff36zddXr1xSPevitfat/mqR77HDzopag
2421k5b83fIFSzf97oHn//fIA2VJmm9rx84fRwJuQ/VvVv3l/Ge+F3//2sfHLBq6IUnH7OuLnb8M
yh3y0k1PPD3oxaZF26b9zbYvhv46KSQ1MA/cbGYdC6zbSOTRu9/90bDWD5++YOW0KYMf+fRpzocc
6/a9oNzBfz5l/id/tXD5LUO++8RvH3/2mSTFiozbT2y/udy6jUZfff6urb+7/KMf0Pufuxdu++Dd
JDXa/G1916TNtW5TTTLlzjrrNhb7TfUD1ZU1B0ouu+rortmNFR8laZV1s2NbKOB26Z731/zx4c2H
it554Y74D5Ypt7+3bsvpwqMo7SSCbMQ1mfyc+3onl1xhuUxQ3LBSso2gnaJQ21giYa0cKfcz2vIo
1biWzRJtmyQXAg/NdngYYQROd8xRjHlUdDRsA4DwJeym28LDRniQ7hMkcN2jEoVa+Ok+jTGkmt9Q
sj16ThAWBelsF9F2uX+fs3//fktq68krU/Kmyv8e9ecikX2IOtLzspV9sTOg7TH+915CEisc0DPN
cB4hLyUzD0B+1QGQ8dzrYHLcKOp3n7NzPKgluBBtLPbL/Zflzqvy/y+cNznab8r/JuXNogph/mtL
zpWYPUKPsp0rkcnCBL+8c/rfGeLDpA+EJUjTXqcjTa+oNDU4wTSNUGn6tqTp/pQ0cVAnmaaL+K8t
OYJG0EgaTqMYjaELuD6fT9OokOZwmd7K11WM1/D9u/n5OnbXwO4fZbuT8UPccD5I+dTE+bCFp6t3
cbpuZTuHpU/j61i2xXy/iJ9ns7sYu3cJZ++OkL9yqkyXf6fTqrKqIJ85m4Zn58A62xl/wfRvX9OM
PTW504sXEufeXumvuRKd1r3IZ8vMtNMiVduB9jlRp91lZyv4/rd+p23rT1n45Lf+7Ir0butPPHb2
bP2pj5/2rT99rKk/kyvP3V8A6kkb2+f2sZ6ZUE/zVyZnQcveS7XoHyymV6SebsM+1aOLzlsRE/K5
uYycTltDabyyF2TQmL6ZQf118ivoF/oztl9jv4a50/dfmJ5UWns1wP+Khoi5aUJO8d77PTs9VqbO
5/H9X1Ckn/dqKf1fUJxVdbfXTXFAs8j7rlmtgcVj0f6vx/u/Hu+k8pygSvfm6/F2YzJLLdPVx9Or
ZGbar8j75Digv2Pr79j6dsd2Vn8J/1UPno1X/+C5V2ur59JG8nPW60D2CwY17W1bAN8bwH8RwF8G
ME7a1hhMCRoft+6br9sYdhT+TQCXz/bjxywOhh+M79YAvi+AGwPYk/+FlY+TyfVzMHVoHMwvsI1p
DOYEjcFcpDFOoNcYJxxrDLYDjXGysMY4WVVjMKFpjNO+u3oO1hWNwcahMU6U1jhY/mCM0hjsUhqD
vUtjsHZojNOlNcZJ2xrjhHeNwUKlMRhlNAbTgcY4lV1jnLSrMU4B1hgsehqDMUpjnJyrMRjPNAYj
hMZgytEYJ1FrDBYajXFyu8Y4nVpjsEpojFPENcbp0hqDhUljMJ/5nl/2oS9+YLvQGKwuGoNVLd3z
mjmmvuBkaP0cTCwa44R5jXECrsY4gVdDsE9pDCYEjXG6vMZgP9EYTAYa41RrjcHWoDFYuTTGydoa
g/VJYzB8aQwmJo3BGqMxmPU0BpOgxjhVXGMw42nstU9LbX6DQUY/ByOexjg1XGPP/wvWP1gg9HMw
MGqM06A1BpuUxmBK0hiMYBqD+UdjsL5ojFO/NQYTi8Y4TVxjMHlpjFPmNQazpsZgDdEYrBAa41R8
jXGitsZgVdEYzDQaC2OXMmDt0RgsTBqDAURjnA6tMVg1NQa7o8ZgZNEYp59rDHYAjXFCv8Zg5NEY
rDgag51MY7BuagwmQ43BtqAxTivXGCwxGuNkdY3BXqIxTtL2uc9+w5/+mzJ9+ghGI43BgKcxTl3X
GMwtGoN9Q2Owe2kMthqNwWKiMVgfNQZDncZgzdDYq387NvjHMx8H8KyNfrw3gGmTHf/Y9vfWTf7n
KwP41QBObPbjhgBusRiMSqQM2C40xinlGoPdVWOcVK4x2KI0BkObxmDd0RgnzmsMZj2NwZqqMdhs
NQarjsZgVtQYbK0agzFAYzDEagzmJo3BaqoxGD80BqOYxjjRXmMwZ2oMZi+NwUqpMdiMNAarnMZg
Z9UYzLEagwXSh8c/6ysvMEJo7OnDkC1GH8DEp5+DNUVjnJKvMZg+NAYTjsZgbtIY7I8agwlFYzDw
aIzT/DUGa4zGYDDWGGxXGoNhR2OwjmoMJlWNwU6iMRiZNQabq8ZgqtEYbJMag41OY7AaaAzGGo3B
bqoxmDF8z2v3+dIDZh6NwUCsMdhBNAZjlMZgmdUYjIMag7FLYzALagwGTY2FIUoZMFNrDIYQjcH+
pDGYHTQGe4QPb7zRVx5gT9QYjJcag01VYzChagw2No3B9qox2G01BgOkxmDw1RgspRqD4VBjsIto
DNZPjcHAqDHYGjUG67g2YLHWGAwzGoOtU2Mwt2kMhiaNwXiuDVikNQYLiMZg+NUYDHYag3VQY7CL
aQxGFY3BxKsxGHo0BguQxmBf1BhsoRqD7VljsH9pDKZajcEArXHyBOah6zaGE2TWEoMnhmEbmTkx
zFBWBJZj4L2tC++Jdu94kZNy4Bi8z57dq9Cf7JH3DPaeob2nM+E5Jyny6hNmdV8ySD7GDSd2efKm
rltZbTha0hS+NjUbTpmor5t5rFtZ02kV+6IL792o4DUbexX6vh55T6ngWZt6VZl1JWjolqhONexw
77yP5tlO4rBxHvQOgyH1jOpimledyV4zjdc68dq42YTctVe8J3bZq2u8Dk/A6790K9Sx6byeaTNy
C1L9/RPkt3nbcI41CKfH/CFVXfrNOWKS5aFGhz7heTPskHnfimNb0id2Hu1dnXwKFYcKaou4Og7c
W0uFezeT22gnW3/Lk4Kn2I7jNqaU7XSeBFWwfXUIT5nZ3l5KVMs2ciUPgdkmsUhYydMzHrznst3M
gWxhey/bRrYPsv0e2x1sMaHfzXYP26fY/gPbf2T7LNvn2P4T2wNsD7F9g+2bbN9i+x9s37WJ+pTt
vDlE89keZNvC9g22n7L9jO1tPEldwnYp22Vsl7OtxzcZ5Vjy+fZBpLGeagYZ/GcW15YY3Ghx01SD
t1q8fbrBTRa31Bl8v8VZ9xjcbDHtMHi7xRc+BFxP3xV8Nz1o7z9ir4/Z+8/Z6/P2+oK9HrbXX9lr
q7222Wv0NXON22umvWbZa469XmivE14z4U6yuMxeJ9v7CyyusbhtF750qafC3SYdW+3zQ7ttvlh3
L+wxzw/aa7O9P/hHBv/335vrB/b6sb0a+dgyc83gHayWrhsNRcIRNxT+jm8RgOhxe62hVbSaVtB6
StBcvm7i6wJay/eWEd5zTWQ5LkUijuvEom77fiC9JNeInxtoC/tZzj7xNm18iYQ+IBp2YToNfTqt
4/CXGT8S43aTstnJe1hD19IcmskhEk2RcAqoMOtP5Xlnfmax+9l0I//C9wwOl+hqG8fMsOt0L44J
quDfZXQ7YQZ8xThffDsNewbnyQaRgV2URFfakgmHQyHHiYc6C/caDmkd29XsH9vdOLVRKQsKmJSy
WMRhraE7ZYscrli/mji8e7G9RjbXraCNHDLRTAnRcaKOMdZRSohzJI5rqYG1ANvzElw6azn2DRL2
cArTAWouIjrs2m+7qGzMuKpJn82sGnRb6f2vOGFO1DBW24arEZME4UyVUN53VDBmX6gXgWGpO+H6
zUmY0rEozPNFu7Dq9vGcE/nQ5nLfiy3PGHVOJr1VHFOeMDncsqBVuUt+l/H96/gXOtpAK+k8rqUL
Wf9mSd2GBs2jKq6vi7gGLuB7uHMT2xr+f47U/n7Tb/ymgPUokzXuFpzPZe+NJCo/mnRxpSj3cWiX
Vts+B27itHpWRnzNrIzwzezzKB0jrO9nsB6uYFdeG5qgcWQ+sYwWO7Fip6C2VYZ9hTzsa6Pi2ig3
UCXyW15C2dj+ddiNUowmxu+bUT0aJ7S5IntBWtk8EKRL2AXLzixxBlRFqKA2cRzy21j+SpbpZJtN
1uTJTBD3aCGROTutTOwKGMouRKZrZE5ytEyX84plTYK4C9h/WKTNSittgkgLG2mhoLQ2Ki/hkIhF
XTXKqZb95y5Vp5WEt3W5BP/oCTBoLi8J0+D2mBS37/hezVGqlj3oncmaJLKiPlkRlmXikSor1oWs
K/juYHYRGNPzCLYkmguJ86rDLCosorhliousqrSyykRWPJ2sWBZpQTez72EsJ73OYedJMd/PLKEB
HFJBbRsHOnBvq2OyPJ59MMY6warGmj/RprmwXf5Uml5+LLlbzmkbzJOLFXQHS9/Amt/Asufb8cWd
8lvPNSfBqVkrrbE2lVTBY8pjmJxwTCrYRS338gluh1fQZnE7ECfdBWdClOXL+zV0PJfzy1kjJYZx
1FoZRyXoeo4RRg7L2K6S8InLNQ8SxxVTTlMb5TYtjhTUvstJN3Uty4lnXcJ1LZ5VIr8j5HdMJcVj
VN78ZXJlHK/Br2X3BQ56thzuLzDCXS+pxejEy2czIiuhfDKE2C1fmpp8iarPI+SXpefl0YzqovbF
IqRqEo0q30PDHOhhPvdLGKeZcRBCWSA5jjAwprqdfzHumjXK4RAvEO0p4d8I5+Q8HiUarXE5N/Hd
w2CRX8K9cqq7K8Rdoc9dURp3k8TdIJ+789K4myjuBvvcDU7jboK4O0+5G8XS4W6Uz914cVfE85DJ
qNDGKY3mGMPtaJ/bUnF7PpcR669yXsX5YOqXdo02uIjzbiC3X2jDsg8OoNBhtyb68MUsJh8ypthq
0B7qSC6hnzjcBHN8ZkvNQtnMZa3DfMVoQNS2PjWUKEeoNXIPtWGt/fqJ2M8Q1saprClTyVP1kayR
YdM0f5BwO9qwAp/uV9BFIrVCpPp1rxBtdLFbuPewm30wTm5r3v5hjutpmpZRwun4tQMZBe0x61rX
ctrjk0czZ6HvGyrxwP6G7DQyOmp0Fl3E6dwRLahtIVJtc54vTiX0jTRacqWUaEJpSSldynHPd0ul
DOa310J/GQwwbawRT1eZ9kLOYMz29doJKcNaSWeD5OhwWQP3tzdl1j/qVIxrfj0tk1xZJzrk0sUq
VXGfz1LxWeEazVwuOZnJrTDyI7+p/vcF1p/2M1n8LHCxsyTOLU9H/IzORrl3RxzT+TUpXe5elcZv
qYRdYlunHx5P579K/K9zqyQPl0v7XscS4L+O82q95FIBjWDtPex6bwvQGflzbIHNMYxQQqxLq7iU
MHoayfrpRIqdnKZnOB6VMWkhSVpIkhaSpIWkdHG72cpE7xa2MrFbcjRd6pP6DNejFupM8kBKU6lo
icje4y6RdN+h6mqCMH9dIT1JMbdNwVrbJrXWhDay07hPtnGfLPJXqlqr5bt0GeVSwCv3lcZvpdQl
v1/kwjpbKhmcE1z7B+79IpZWylVcs952ISUiKzUNUrKYs41B/pmkYFTBrbIdFV43a4ivi6KHOS5H
6T33YYnLbKsRuu6tkPlfHV3O44wBA6qSMe/wpoF7uSIe5MbQ4R7VacRczsze8UFOb43R+2Oi9xHp
/5fb1GXRn8hQByO62vZ6Wt6cSan1xo1wNmEosUGWsVBtbpD/V8vwZotUqDvam4+OIYZnynhQotf9
00fWb7DBuM7OLxxZ4FnNaj2PE+DbutQtU8Bqgg1D2ETS3fBhvJBMqCs4Bxq4aV1rF+C6b7ijP2H6
59fOeXDC6y853lU/q5RcXZbOW7dMJqe/p/mPrP+l/X8sV4wO1em5yeHyx6omEtXd8H/IjrPLAut2
vTA9Tf+pNn05fJQb9lBiRRAbqSMWo0xRr/AJKjZQYVE8yz7Dx55494t1TGxOwlIVNpHhwxpsFh1s
3fWbs9+E0H9EVf+xXAp6rOpBZPwQ7D5s/1OQ4n+V+B/n8z8xjf+p1v/UgP81onil1n9nvdcE8V0a
miCu75T5sJmhotOCxPGyn8I/RltpxqahlaK007mjw8rpWnm7sF51b4n2fp5oGM/beC6d27Q94g2A
NpNMnHYO+u3Q14aRVAaeM/lSN5kl8Ig2hNFP2DbyK6SaTIS0/KaVTsd8PzCSLOcukUe0oXKpYqkr
BgnfKBdVdhJGMzJjSLCEDOnbjzjrpGwyOF8xbvTPmwbxLJjjMXDv/lDh3lYzBatLuBxXrPqw/3lH
HDN7iHEYa7l7rrNzP/gtM36xjrKZ2v3GzDiTWwGUDtYMJ0jqO3zm8OymRI0bO9KN9UOM+u5298j3
aQWc7o6RuFcaOt1m1JXDOZ3bVBXJb3rnDygYdKjDy72xY4xz0pzA4Q1bimiKXRnxzsKALyRjgBkB
FkkGinYepZdFO7PomoB+dcz0Cghj4/o4vjmXjChDI1or6X87hBhm8+BmFQ8v1rGEyTJarOPnnj4U
0zSUXUHtZ1COvQUclcs4R3PQFh92d0XqZTN0ocwFO9a9MsLIr6VcSkeT74WWpoRyeyDVKFFZYfqV
hHJp+lD07NSEYOYIx0JLRI/M4REIYaPMJPFuqoSutjMRs64rs4JhMgcplpIeJnOQ4oEmd4f42wA7
vwljfhOXOfhGKWkv3hdTuZXehWhKL7uU2yBuX8Jm1uxpUHDWjFTJ6iD6Lq5HlexneHiS5GiHnxlk
1vWgxxvIzGgrZP+QLNUR5jr5dEzmOrmBVchFPMQMhjnDW5EkEk0bRhXhqVICfr+laX1XKt+jbcij
JQeDx3vA9UzjWjblY1Z/xF0eLksT1jiOlVezvDlNhKqIc57AenI8d1l4neRmrhoyzuPJgZc7xje0
wiV8w9Agpbs13MB5mp1yGo6ej43juISkkCWul5GsXA4l76CdgtrDrkPyZiDmrHRw5o7pGSrMKvXM
WW1Jr/CruRR3h78frpZQO8pQtydmZSCb2xMJr8KsuObJ6qdeOaqksdyW7AlXBnRIywIvSLWRs5kj
vJEble1/tPEc4mJaMp/1Ij/80/D8gFbpcjUxKqTrUE9tgeU2xWOIWLp4IWdfDpv5cUdpBFdmM/CO
A/PcqR2pQy2PsJQIpwJS3g5XiO54608V7H+9lIpwYthevM008/PPz8wSOd4UuZSu53x+z9aydH3V
eNGjudJDmbbreemdjvEVfnSME6yt3srAPRyfUDFFoBOZZlZdFi6ofVGis9g1i8s8u06i45PpX8e8
yvcF5EmY82gKhhzIrly1GpARp8Xc5u4O7wkv5tDyO9WuKrVGcRGXvxRoroMuZ+De+Rz/XZ4m4y1X
WFYrR8mbN7MWHGvv6XBED1bAMjmfc5taKL+pjIf4ozjf0rs1K14LsNrmeG6zOnE7Xtwarha80wFX
C9Y2Pd6cV6PigG6gAW0X8r/peHMeXxtkzDFfnxmpI61UrAd7jDn/bKVqxpwbabvcT8eYU67kmS9p
PMacG0X2zSrGr1nZ61n2qLQx3u8gQBPvNx1ZNPDFfroKDd+RBfOk5aTy5FoldRp15Ikn9edWaucM
RYdl88gR+fXLvkLJnmhlN/N1T5aR/bqKMd50NrJdaKVih3Octr2C1aiXQglayjU1zn8vHjcTSVyx
g23PQrOTbY/99MV77sVhgoqDyUGvjBampPUXvUhrtQoHrRZkb6WOtB5SuoX+sZGw36k7qdx0vUmh
d/Xum/9M6HMDoXekskZisiC3g+foLU8TnQFtw3PN1Bp5cFscPEdHol66Zx6ojIHnaG4syHN0KHmo
xzxHsrJDEffJSx2KuovfOZ682nX55ksucqA5ZPL1iNOWfJCud3jW5CykbzkzqdmZSDudEfSUM4R+
5hTQ204u/Rfbj5xMynLjNNrNpNluNt3q5lGdO4i2uEPp/9m7Eugqiqx9e6tuSNghQBIgEBLCEnYB
WcMSQAkQwxaWIKCsggwYcGRQI6Oi6Oj8uI2OI/o7CuIu6rjg9qsoCiiCAgIKiKIiimJwQeCvfunK
u11V/ZK8lzmQc0rPPek07333u7XXd6s71+ut4Fa9E/xT7wMP6DnwsH4+PK0PgZf1frBJ7w579Uw4
qmfAcfq5E9RO6WkABu1TRga9bgMn6b+d9O5rtFaIkQw1jVowxKD1ZuiwktpDhgn/MWzYaMTDR0Zd
2GMkwiEjDX40OsAJurcyzWyIM3Po7JoHCeZ4atMgyZwNKeZcSDXnQ7q5MGStqbWl1o6uRdqZV1C7
Cjqay6CTeTVkm0thrLkYZpmXwhJzJvzLnEFn1hnwrTkHaliXQnNrIXS2lsAgaxmMtm6Gi6y74DLr
YSiy1sHN1gvwd2s93Ga9D/dZO+ERax88YX0JT1nH4HnL0l62GmivW2naBquX9oaVTa9ztVetAvpz
Gv19Or0/S9tszdG2UdtrzdW+sAq1U9YSLY4UaY3IDVoqWal1JKu1IeQNbRLZo80nv2lXksb6zaSb
fhcZpa8iV+p3kzX6SvKKfgv5UF9ODuhXk2K9kJzUFxHduIJY1KoZS0j1UruS1DCWkTrGdaSBsYI0
MW4l6cZdpLOxivQzHiY5xhNknPEsuch4mcw1XiXXGhvIvcYW8qDxAVljbCWPUnuc2jH6e09zCxli
biKjzY1knvkmWW6uJ6vMZ8mT5lrymrmKvGPeRT4wV5Kt5i1ku7mcfGIuJbvMRWSPuYDsM2eT/eZ0
8oU5jRw0LyRfhWwqtWmhn1/T3782C6iNI4fNPPKrOYYYVj6pbRWQJtZUkmZNJxnWTNLWmk0yrbmk
vTWPdLIWkB7WQtLHKiQDqE2xlpIiaxm537qOvGKtIG9R22TdSD62lpP91H6xriUaWUaqkWtIU3I5
6UTmkUFkKhlN8sgkMoRcRHqTS0gaWUDiyCJSbN1DfrVeJSetA8Qgtu2QRNsibWyddLdPWQPs360c
u9gaZx+xLra/tBban1r32a9YT9uPW2/a91rv29dbW+z51lZ7IrVB1od2e3qvofWWrVmv29+ZG+1v
zY/tQ+Zn9gHzG/tz86i9xzxGrZgacTabDZzXzBRnndnGedDs5VxvDnQWm7nOdDPPGW+Oc3LNfGew
OcHJMic5ncwCJ51aI2q16O+E2gljgvO9ke/sN8Y5HxhjnI1GrvOWMcx50RjqPGNkO2uNNOdyI8WZ
azR1ZhqJzhSjtjPBIM4o44Q93DhqDzWK7T7Gr3Z34ze7swFOpmE5GUack0o/19So6yQYDZyaRoJD
6HdP6alOsd7WOaxnOl/oHZy9ekdnF7K99N4++nNf6LqLs1Pv4Xyo93I26P2c9foAZ50+0HlUz3ZW
U6NjinOVPswZqw9xOuhZjk0/87vWxzmi9XL2aT2c3do5zg6trfOBluJs0BznJe2I/ZT2sb1G22lf
p+22J2u77Bx63Yvea61tsRtqm+y62ka7lrbBjtfetG3tRftneMo+AA/a2+FeexPcZr8FN9qvwFL7
BbjQfhIG2Guhq70GWtkPQbK9GmrT69NkLRwhT8KX5DnYTV6Cj+jP98hTdAXzGLxOVsNL5B54nqyE
Z8hN8BApgjvJ5bCATIZhZBikkp7wm9UatlJbb7WFNVYmrLI6wh3WOXREyYJ51ggosApgojWF2nSY
YM2BsdY8yLPmw3D6cyj9fYA1E7rRz2RaeXR0GgxNrAGQYPWFOIvuP60u8IfZHo6bbeGomQGHzVTY
ZSbBO2YDWGfWhFVmHCwyTRhJJ58O1Gqb7v5eg210pN1gEHjBiIOnjRrwuFETHjFqwxpqdxpJcBMd
ta8yusFiYyhMNvrSUbojdDJSIdloAA2NelDXqAMW/U4xnSUO6tVgO5013qZr29eovUTtOd0M2f30
+iZqi6lNp58r0OMgn35nBJ1VsvUk6K3T9a7eGjLozJKi94TGOt2c6cPoLJQPhj6TznOL4A+tiNpy
ajdRWwm/aXfAcWo/arfDQe1vsIv+23ZtGZ3piuBV+vm1dKa7Q8unM+twyNNGQC8tF9K0PGiijYIG
2liwtAK6+JgMJ+jK4DjdSRVT20/XmlvgDlgPz8E6eBsege3wAPwMd0Md7TbooLnz57+NNXSOgjP5
1/yUKVOmTJmyqmxT3K16yS67M9pluzoer/F8GLPG0w95SEMemIrwEafxUDB6vSJ0v2RfXrIjL9EV
GGpvhNomdM3UgVGlHpgGtk3iIY962MZpYKc1B3k4B3lI93nIE0rp43KUUpe7Z0Qopb7Im0wJ+yQq
JawPQk31UDdBWDfZ4aFWpb953RPF1NqLCf/N650oJvU3r8+AobrqJakr3Kp3RdWqz0WoWPNmqJ/G
oHl2Q9j9QdR3d0v03QsqWd/tgjiUvK2IjTwXCLHuiSHWIcgP08mxvrtXou/mVpq+Oxx57xS6ZlHm
Cu3ks6jayVDkoSOIc9vnMY/ao5AHNr5i3vui4j0GobYAsV72S+plZGC9NDtdUu7uT7cu+nutr7/X
+ti/M+95yHta6JrVy0iByQEJkxGBTCzPk/tT1kIsjsloxCTVx2SEkOf6AjFhea7hEWb3jgi7nQ97
uNBOvoy5nXRC3mQ1+pWkHIdVWk/LQd79NTpMYHJIwuT8QCZ9PU/uzx9GljBgP9l9zGQYYuJfU50v
1OjXkho9j67a3PuyzGUdhF3bh32esO75pgque0piCsfHr3u+Veues2bdU0tSV3heOBzVvJCIUOuB
OJ8dKcc45XIMHqdqlsH7+6h4N0ao9UFcr/0QwxrGQdh1POxbIDyeHUXY7sxWBO66Z0XofuWu2iyO
SXj8GSJE/GMMEScjPy4Mv0L9CdURW6EOphG79ytrRmmGOJTEzWIdDHxu/hhrlWdVbt79V5WbV7l5
lZtXuXmVm1e5eVC5eZWbV6ZMmTJlys6UIRXJQLtspsbgzHkxp8YUubtoutMvJpEy5/Ecanjvni1k
zo9LPAyiHo6TSJnzuEAPgwTN6peYtfXqnDdes/o1Ks2qIUJlmhVWkH+rggpyNRSTTEH+XSnIZ42C
XENSV7hVn4iqVScgVJkS+0cMuqQtYYyV2JMSJXYgHUtOVroSa3JMwuPPQCHiUzFE3AT5YdozVmJP
S5TYATTi05WoxDblOIRjHSCMtaE3x8Q01rZD3lwdmp8vdM8Dni/604jd+8HzhYZQ43wx9BdiMGKO
QUfeqoNYayaKgdVaFo3BvV9ZtdYIcSj5e2As4iyBjyXh04/ysSLwqWhetgHiU9/Hp5+Ql3U8Pjgv
OzRC7aYg7Go+7KFC7VaPuXaTkDc3M8GPm3FcCy3fuFmfi4HPccQz3irHoXIcKsehchwqx6FyHCrH
oXIcypQpU6ZMmTJmSOdsgXbWurezngLh/XoNb2f9V7pfd8/sS8+0UjimCLgYOzS0R/b8NEd+NAgr
n0xlqSlRNfpGyKK05HiHVY2+pZoDU0xqedhdKHZdD7uP9Ax7KscyjNpHKJk65S6Z7bdHKpk05JPV
ANZk6pZDk3FDCtZk6iEPrOyxJlMvKk2mrgQV61T1JTXaG1aE7svKvg3C89dob6FMEspTJlyr9LNP
l7DHql9DierXi7JvGEH1w0/6yFRI/kmf1ohDSWmyiHsJddQoqjpqjzzIomwsibInjbJxhCgr+hRR
W8TBrz/2FLIBiR6f4GxAcI12QH5ksSZJYj2XxpoUIdZCL5bCgFgLuVgzEQc7dM1iPTfEp7YW1iyT
PT7HKJ99ENYs/5Hsapbv1AxrlvngapYZwDRL1sJd32+EyoYplCUjjVvKO1AJJdD/j9LP3q5PoTvC
1+ExPUW7XS/SllI7CFm6qYPR0uimz7Lvt0ZXq14tK66w3js11yfcWsNMHBc/p5Fj5jY29W6JAGuS
CrWU5ELKsVCblLyeXpt6Hahfkrd7XEsJtMfc4i4pIxKKM3i8a1KOvu1GzqK1gW8JGRIPbl9iLaGp
ZD7oQVtC09KWwJBaIaSS0wCsPnsIs0wzCWp36Uh3AUJN9KF2D6EOhXBpNKeoRWgUFUvjtA87l8Pm
S7dFzLPJ4DI8pHqMo/eQXYaHljF7GCnxgOeuNMnc1Y22kLSAuWs8witZUbEa7RbCxicX0j3sqnRy
IT/0jXB8bkz45EIrFJM6uXAGDNXVOEld4ZVERlQriYkItTmIPaa1pMecQ3tM64AeMxbhlbxPgPWY
c4T+3ibmMasAeWPvQMFrg0zJ2qBrJZ+KmIQ4lMxQLOKuIT7LEJ8OqDQHe3y6VFr2+2LEZJCPSRch
s9qRlb3KrKrMqsqsqsyqyqyqzKrKrKrMqjJlypQpU6aMGdJh5qBdNnv3In56rDOnwxS592BF6H5w
3nMeQvW/S6yzoJv0LYduEvk096XIWwKIWlK/qLSkP0lQsfqRJVE/2pcr61ae9+vNRd5LnjJjJdhe
YNJfwiSz0jJj8xGTBB+TTEFfGyDR19pFOPU/C2Hn+LDbCe1kYDn09Mjt5BLOG88+W8K+DW3r2QHq
4EUIr6WPfRshQzK4ghmSaRw2XxpDYlYbJyAPzSUehsacv5iOPDSTeDgv5hhmSzzgnn9+VD1/BkJt
AOF2wlCHUdSs6pHzv27Wb7PkabCpCLsxiKNKjqQvdwjsy129vto1oC935fryTOS9JOPNWmwHIQM0
vApmgKaEvhEeNfkM0AiVATprMkAXSuoK992RUfXdyQiVzdp4jM+VjPFt6RifGzDGFyG8kic5WY9p
K/SYC6pgj7k69I1wfHyPyVM95qzpMVdJ6gr3mFFR9ZgrJai4x4yW9JhOtMeMDugxCxGef73YSVgB
jIl5BbBUwv4GCM+nY1GZsJxpx0rOmS5AHPwRdxT4jJPwaU1L071fWZnTZYhPuo9PayFzms9qQGVO
VeZUZU5V5lRlTlXmVGVOVeZUmTJlypQpU8YMqTE3oF02Uxpx5nQ8p8bQL0IG3emPtyNlTldwqOG9
e4agnkwoh3oSOSN2iyQGrChNjEpR+psEFec4JklyHK0qLXN6E+c9XIKtBCYFEibplZY5vTmQSbqg
sk2WqGxpETKnywOx04R2cqEda+b0Rs4bz36KhH1L2panBGiE1weybylkTqfaFcucXifhiktjWsya
4+XIA36/IfNwUTnKO7KHa5CHphIPF8ccw7XIg6znT4+q5/8ZoaaDqMbOlKifqbSdzIygflY0x/lX
xGFI6Jq1rVQhYzPL41OVMjZ/CX0jOGMzG8WkMjZnwFBdLZHUFe5lc6LqZVdIUPH5hEs81EjnE/p+
7p5PMIDHXoywZWcf5saAvagM7HneuBkNdmEZ2JdS7KwysIPObFwmwc6A8Ow33ysT9vm/o8+zdxzj
Ge1P3GxZ1oz2DwkeflJ8gYeHn+luQUfVBaWjKkO6CyHVD12zsbGFwHJhBVneyWHzLC+TsGxOWV4m
sLwDIfnPvjUvZclQC9loR1HjPdQUDu92hOd/03OKEPWiCkZ9G4fN81ss4deM47cykF8zgd/lFeT3
P2Xw+7OEX1OO360Io5aPX1OhL1zB9YW70XfZ26+x/yUS/004//chDH/5NBHK5y8VLJ9/cdg8v6US
fskcv3sD+SUL/K6sIL9/lsHvKgm/JI7fPYH8kkJ4AyBcf1d7ePUoHvHwEkuRViGkRB9SooBUJEEK
j6kPIKTmPqRGAtI1EqTGpUj3I6RkH1JjYb59qMz5lr3BHdfBg8hDLRD3sw+jOmW7yPqB69l3vfXq
uwHr2Xe59ez/ct7D8dUX4lsdVXz/5jzw8a2RxFc3MD68S5a9VZzfJT/MeQ/HV1eI7xFvFq9YfKs5
D/zMtFYyM9WjM9NaYWZ6KJBrPWArDtZqN3I93UVtSFHd+7I98csI2/+O/oYhbLxveY/1+iq0b3kp
9A3/TID3Le+jmNS+5QwYqqsXJXWF++GmMscZ2b7lBQkq7jGbJT0mgfaYzQE95j8cXrjHJISw8Tmn
rR62Ouekzjmpc07qnJM656TOOalzTuqckzJlypQpU6as1JAW8Dy3y3Z31vic00ecFlAU+syK0P3g
c07PcajhvXutUg9MbdjG9u4Q7fmVZyUxYD1je1R6xjoJqsub6RmfSEqmBi2ZTzg9w3+y5xkONVwy
NYSS2WFDjCd7npbEgDWZnRJNJp7GsDNAk3kqkH28kAvZ5bEvby7kSQlXXBqflqOduAEEl8YTZXjY
XY7yjuzh8TI87Ik5hsckHrB2/HkV1I4fRTGxLBjWjvcp7fis0Y7XSuoKj7X7oxprH5Gg4vMdBzzU
aM6OrCkD+6DX66PBfhdh41MRbHz9yuONc0+1pSPrawipe+iajay1hVHk65hHkVeRt7og1uI3UdXi
OwhVdnLp2xhq8XWE3V2CfTiGWtyAsJuBOGp/F3N5v4I8yMr7SFTl/baENy6T72Mo77cQNj4TzLB/
iAH7DYQte0vOUbQqYRnpOoEZ6UPe8/GHAp6fP8Q9P78eeU8NXbOeVkdg8qOESYNyMZHlxnkmbyIm
/vNaDUpXU4zJT2wOhPBJkJrcqvv/EN5oH15NIbJjksjiAiOr6CndTYiJ/wR4nMDkZwmT6oFM2PMA
zQKYNOOYvI+Y+N/wUl1o08UxtOn3kB/3b13xUR6XRFmt0qLciLw3Dl2zKKsJa/7k+DATtuafSNf8
7n3ZzPR5IPZEYfXZxMOuSqvPz0Lf8I9GePXZFMVUKavPY+Noo6dWTO04tV+o/UrtFjoP3UvtBWo9
6Fw6mtq11FZQu5laOl1ttKPWntpJQP+V85cT+JfnA3+JBjrYTzk/9l/7b9AkGNgSsjcUlfnJ//Z/
Wi13HAG1+6ioob66N1SS/r6K11HNvL5asXXUHgkqHjFTJCPmBDpipgSMmLs5vPCIOSGEjU+uNPew
1ckVdXJFnVxRJ1fUyRV1ckWdXFEnV5QpU6ZMmTJlpYa0gK/QLjsJxJMrLTgtgH4RxtNde4v4SCdX
jiDUlNA127uPF/JCqWzvHvX5jMPIWwsQ9YyWUekZRxEq+0uz+ORKmqRk8t2/LM3pGf6TK4cQalLo
mpVMvlAy6fGxnlz5GnlLBFGTaSXRZBwaQ6sATeYgwmvjY++U5loY+4z4ip1cOYCwZW+MaV2OduIG
EFwaHyEPuK0zD23KUd6RPWwpI4a2McewH3lgb73BuYN2VTB38CmKidULzh1kVnbuQGnHFTNUV7sk
dYXH2vZRjbU7A1DZONXJQ8UnQGzpCLWDQwqPULbQGzvH3Bs/CeDNPHSJqjQ+lqBi3t1i5r29DN7d
o+K9TYKKs7c90WzDsrek0k4kbEbe/fkCIjDpJWFiVdqJhH2BTKzSkmZMektatklnYPe+f031DUL1
t2wzhHoDQu2D6i/HQzUoap9S1NhPJ3yH+KT4+BhCefeVlLdeaXn77xGTTB8TXTid0M9jEs3phB+Q
H7YixKWeJSl1jZZ6VoRSr2is3yIO7ULXLFZNyIr1Z+OEyoqprJjKiqmsmMqKqayYyoqprJgyZcqU
KVOmjBlSOb9Au2z8tBvb6Q+Q5E0mRciHfYnwaoWu2a59kqBQDIxBofgA+WHPT2DsQV6GIxrsrQgb
PwXNsLNjwP4QYcuehxxcph4pe6flTwhV9jc2hkhUqZxApaai7yT9EXn313mOEN/QqOI7xnng4ztP
Et/kwPgq+k7SYuTd/xT7ZCG+8ymTrArHdxx56APhVsHiGybRTgtgRei+v//9jJDq+rgWlLZjlmvI
kfTtORTVvS/LOBAtjO1Xe+cI2bnhHnZVys5ZXHx8dm4Eikll586AoboyNbGucD8cGVVex5Cg4h6T
K+kxs92/Fx/QY3QOL9xjZgsa9gVKw1YattKwlYatNGylYSsNW2nYypQpU6ZMmTLekBZQQwvvstl7
xPCTHXmcFkC/CLPorj0vPtKTHbURqrvXD+/dZwnnVEexvXuEc6qRn19ohLzJ9IzRUekZ9RFqQxCf
7BgjKZmZtGTGcHqG/8mOWoElM1MombGeVh59ydRB3tiTBliTGSfRZGbQGMYFaDLVEV6ij/2MEPZQ
xD7fY1/eJzuqIeyOIJ5nHl+OduIGEFwamqSdYA8TylHekT04XPnwHibGHENNiQesHU+qgtoxcH2C
144LlHZ81mjHJckdf13hsXZyVGPtqQBUNk5dKMnhTJeOUCc5pPAINV3ojVNi7o1/BPBmHqZGVRon
JKiY9/+zdyXQWRTZuv4lfyeQkJAQ1rAIARESkE1QiWwCssqOCmENi4BJCPu+q6AoIiDyZHTmoKDj
+p4j4xOUXVZBdoQERERAAgqCuITMd3Or798k3ajEd87MO53wUZ3++t66detWdXV1dfeAQtv982/Y
PfCW7P7JRqv1TuMgy9nGvNM40PFO4x99nuJavtyDNT9Qzk2mJYPNHkUF3/A4IN8YpqQnqO/GtxkO
KFCyITYl6+9Ysj/6DEW0xZIbS9a/gCVDbSzp52jJH32uIMbRkn4ytjBj6FFtya3c6S9lycc8y1nv
9wxz7/e493vc+z3u/R73fo97v8e93+Pe73HhwoULFy5c5Idl/i7cE7yyrqgKPrMw3OaOQN+b3Okp
atF34yxJ3wIzAiMKMSNgWPKxvqPK1J2q5+5vRfePKqjbbuVqmo1Pxql5efvt5iBvs9gam6fb9Mm4
AvP16f+B8/WV8pUv/3z9SHe+/t9mvr6ip2BdWWd6M25ppre2jVZrixll02LGosWMcmgxFfLpC7aY
sQXm/ka7c3/u3J879+fO/blzf+7cnzv35879uXDhwoULFy7ywzIXcLcneJVtvunCutZ7TL65gOm0
D1ftY8Jvtta7QT6twWv3MQVWro39HSvXbr6i+V5LbnZrvcfd0nzGXRat5nyGda33eBvPjIZnxueb
z7hxrXfDfFqDnhldwDMTwn977fHNPVPfkpu5+s46JzPRZk5mFMow0WFOpl4+fUHrR8l6OtP6Sdr6
37vWu65Ft9066cmFXuFYy6FGzRym/A5/3zyHKg6tycxhaqHLUMfGS9a542n/gXPH5W3qxTp3PN2d
O/63mTuO8xSsK2tfO+OW+tpEi1az3VjXes/UWq1rvTNse6hy+ewL9lAZBVrjrEK3xrK/4Y3Zt+SN
BBtvWO2eU2i7azr428zh8Vuyu7KNN6zrkJ+wnG3Mdcgjf9da79/zFv8yjjU/soAlT9pYkv6nrTqv
kc+7QUvSC1gyz8aS1D9tlXiSo09SC1jylI0lj/1pq8QbO1ryWIH7tk9rS27lvu19lnzMEY+1lPNt
SjniTytlE8eaH1HgntUz7j0r956Ve8/KvWfl3rNy71m596zce1YuXLhw4cKFi/ywzEE28gSvsq0r
Tc1r/Gdt7moMv8ndqnss+m68ah9eYG5iQSHmJu7Il09+3c/p+w+3orv6b+heWAjddzr429T9fCF8
crtFt90a/kWFsLuaRXekje4lhbC7qkW3+SYoq+4XCmF3vI3ddGfNjO8XzfshKvimipR8MR1r0VGU
NiWmU/L0NVfB2fU804oFZ3tN+1SeZaTV7wvDdhMfzT6ZWmmrGu0NoNRAS6AV0BpoA7QF2gEdgI7A
g0AnoDPQBegKdAO6Az2Bh4CHgUeAXkBvIBnoA/QF+gMDgIFACjAIGA48BqQC6UAGMAoYB0wAJgKT
gSnAdGAGMBuYAzwBZKLUx4GTwFfAKeA08A1wBjgLfAucB7KBC8BF4Dvge+AScBn4AbgCXAWuAT8B
PwO/AL8COcB1ILcYV6kH8AEBwADCgQggEogCrpSBLuBH4BrwM/ALkEO3t9FMPIAX8AF+IAQIAKFA
GFAECAeigOJANFACiAVKAaWBskA5YGoc4hKYAcwEZgGzgTnA48ATwJPAXGAe8BTwNDAfeAZYADwH
LAQWAYuBJcALwFJgGfAS8BfgFeCvwN+ACWgWE4FJwGRgCjAVmAZMB2YAM4EaVZWqCSQAiUAtoDZQ
5g7YD5QHRtZS6mvgNHAGOAt8C8TWRW8IlAJKA2WAskA5IA4oD1QAKgKVgNuAykAVIB6oClQDbgeq
AzWABCARqAXcCdQB6gL1gPpAA+AuoCHQCGgCNAWaAc2BDxsp9RGwBlgLfAx8AqwD1gMbgI3AJmAz
sAX4FNgKbAO2AzuAncAuYA/wObAX2A8cAA4Ch4AjwFEgE8gCjgMngJPAV8Ap4GwTtLOmaGdAP6A/
MBD4oIVSq4F/Ah8C/wt8BKwB1gIfA58A64D1wAZgI7AJ2Ax8CmwFtgM7gF3AZ8BuYA/wObAP2A8c
Ag4DR4CjwDEgE8iiPFoiD2A9sAHYCGwCNgNbgE+BrcB2YAewE9gFfAbsBvYAnwN7gX3AfuAAcBA4
BHwBHAWOAZnAceAE8CVwEvgaOA2cAc4C54DzQDYwAl3+3hCl3lL0hWbEUzyno/N6Wq+hVBL66cex
vTwC1nqJoX7TZ/Ae6g4y0d6zvKbMZfRKJ9Cpr8J2mVju5ZjJISaW36i0B/3A65B5vylp+w7MfHTk
RxWvYXhKmDjkk4y/0rB9BV37XZGmtl8hs64Ef6ODtFHKzEXqF4FvsJ1YjFNmfsLeHtCyDtslK6KX
EJkfwXSCbc9ju1JpTpm5GuA99Pa+KLT6Ex7TB1fALCjG2l6JQf8t3vkZTC/k8xSVAPl8JNqydUlJ
JiKCU2bOgdnm4T3zoOk7Yc6Cobsh9NWZ2WA+FKvPgFnup3szrDVOLIiB394swR6ltF2YKRMNpndJ
ZigNMkXBPO1hprGP/2YmBFvZ5ZlZWwk9ucesn19gQXcMHxpje3EZTlnmGphno3hP3xgr4zf4qUpa
9REB6ydLbV+AzE7kPAPb7UM5ZZlvyW85ubmkZVcup8wUoZJCw93Y7g1tR0JM5nutrafW1lNkroPJ
pbMWti/GcMpMbj5mjZT0UoD1x2ptm4UJhQWPGRwzu9Ba9klbiDB4z8uKW8snUnPhuv3Q6OggVO4U
qyPBZCLe/o7tt8rh7OIzmWJg1hajVRVoJZBpLdqKG7xntWLZ1VKekmDmF0ctK07LibYKBscOeaU8
YmCcxHV5XT/Ubqb4rO2nlMF7qOwkM8Zn+qCEwf0AfZcpCX7b6DO1lQFz0cfP1ObCbx9JbXt0PpOA
bC+nnE85gyODPEqtpIXIlNYyPi3jE5mymnlZMy8L81WAe5Vqim0cLPXzdYD3bMB2+WiMAMQ7uwPs
r7bY3oK4NqQXO0oMRh20dmcK2ni7PNuI2R7gOJiC7WQMWROF2QdmF/qO04rbzxJpp1+QDPSv1NpW
itXbwKxFVMxV7IO5wqwLcC3QagXKb69oOwJmYyX++pevCqcscyjAewZge2MVvrJg5jCY0Cr89fht
VeirUCazN8B1STIdEFXRks/BAI/kSD+VK5jPAc000EwDYfZoX5M28vUAYTaDyYa/vkS7piN+kEj8
VHuUjqUjgjIbwbyueM8wHLpQmA1gViB9AUgB00tKuinAK+jI2lSf1eoqyOMYYnM5tuOQz3y/yVQ2
+H2IxEwOsTLHqHeJ5dhZU4ZTZrLANA7nq8HzEZwys1X3SHBzXh9SRZgdAe7F6G2uI8I4ZeYbMB1u
o/UOfHZ+xmNG1Wny9fXcXGIo4itIvGXqqCKbktEoMoTZSTIo0w7FHp0kTLz2AXl1MnqZCdIWbjO4
tddR3I48wlR0ZL7UMUrjAzriY7H6eIDb6V+01ZSyzEkt84bis9kjYtsJLUPzHCRzj3jnDoNLWsnP
Ja0XMGPndoPL8lc/R8jnUnPVDI6Qg36OkGXS91bV/VsHP8ddToiprbXuLTP9XJ5doaZMdYOjqoKf
o6qC5JNo8PiD1oZRxGdKeWoYrL+LYut7iA8eNLgc1FNQrZ8WhlZPdMEe/FMxlXEVKkwHg48lLRGV
eU0XM+0MPv98qLhHOiJMK11zI/1cc80Mk2lpy5APauvyVFVcngNSpw8YfCyNc+icNUV80FaXtKbi
ktYUq9sbHIn10OpJ61fK1Nbc4NFGL8Xl+i/pr9vofKivot65qDB3GrznPsX99S9Spy0M7pHofQik
9QnxQVNd21t0nY4NmBbUNbjnI49SzxeQnu8+gyOxuZ8jsbmUtJnW1tHP0Xs9xNTWRMtkaZkskemh
PVrNyx496DNluhnsr++9HA9+icRUYjCuOg4mB2mutDny89pSzJBsmjAjdC3QHjoiyAw3uLfIkzGs
zACDI/4zL3unr0TIIK3ttIfzOS0eHWawtTFerrkYqZ9HDY7ejh6O3qkiM9TgY2d5OHpbi0x3nc80
nc8skelqcJuL9HKbixSZLga3etJPrf5tkelscKv/Hw+3+nEi00nXHK16o/y+kNoeqOON3oBNcX1S
aq6nwd7PBpNdAp7ymSOUIQaP++ibmEno/cd7TCZFazvo5Vh9X7T1N9jHH3j4iMeF6WfLkLY+Bsez
38f+u18i/iGD9X/j5bawQvoqqkNqC+u8LNtJavthgyOe1n9RxF8UH/TW3lmp46Cn34zRZM0M9HLE
xwjTy+CIv+zliL8svn5EMy08zLSQ+hlvsI/nYM9yXDM1ENvSDJpl5OufxEoYLwgzjrSVY4bSIDOW
tEWzNmKC2sYY3NbyZKKtMqMNHpPnyURbZUbpSCSG+lFmyDsZBo/OSBulQW0jDb5yJRmaQQzKpBvc
5kiG0qDMBIO9QufTZETVSPHbVIPH/usV19OX4rcpBvchJENpUGayjp312ragzCSDa4xkKA3KTNR1
SjJU4qDMNG0bjTYoQt4WmRmaeUdZY4d+poO5ir/oDfs9wLSVkr5msFdoNV8OWv270vO9SuUJ4TXE
FAcJYsFK7VHaQ2mcRPwbBj+5cEZx37BUoncVlRQt8SHFvRm3RpJ5XedDfQLlQylrO0nxBjSk/OCd
Tw2T+ZKsrsCztkmVOWXmBJjm2PNaCI+zD4ptxw0+9mgIl/RlkTlGUYV6uYZ2PYV6/2Imc1QzdBZY
jlH0oXCT+YLKE8JjmAic2VcXNZkjes/hoiy7SrQdtmXIO4eo5spyzpko12CZXTlo8J5qEWw9MySz
n7Rh42vEZ6aPU5bZp5kGMcxQysxe8jWOawMtSeh/fooytX1ucNnDkM8HsGRLtClDNZCMPd1D2OdD
DVNmp8Fj3SHwZB8/pyyzA8yLHvY+jR4DwmwHswhMUezp5uXrO2a2ka+hZWYI13Zdyec7Q/e9Xu4X
Bkv/dh7MSKoxHNa5LKes7QyYzqG8Z0YxK3MazAjsWYY9vaOtbeEcxQ5kPMjnZASnzFw0uBej8yhd
1wfPp5fArIJMEvb8EzLJou17bXWGYqsXSsRfMLhfG+RhrVfEtmxdni2Ky0MpM98abBPJZBSzypzV
JV2ruKRrReaUwdbSlRfVYGWx+iqYTX6eR0lBRIbLiOuKwWu9x3r5yn+syPwA5h/YMwd7ukOmgdTC
ZYPb9CnFo9xFXpO5J5wjfgM0zodtGdK71ACzC3E5HsfOx4noB4kD+vY4zcIMAvNSKM8NMENf96Zr
pVMePkMFZeib4uTr0V4eDQSZO6hN46+2Xh6tpQjTEEx/WLAF2pqV45SZuzRzUjFDKTP1aByOfNbi
2JGRnDJTVzN0LDFBmTpgemPPa9huT2NZ8WgtMEno8Z6FlsQqnDKTCKYu9mzH9uUq/EZ9ZhLC+Vha
LJ6NdKPIVALTAdZOUKz1ael7K4IpBs8/hT86hnDKMhXAzPWy/rZ65MVM+XCe46R3Md0P5rIwcWCS
Q7g8HcLM8lA+9+raztC1vVDioKaubbpmjihpPWdVD+d6obMZHXGftJ9m4TzvQjJXI/gaipnbtcxE
XHOTTFuPaUHzcD1y9PCZdp5ou40YHLsP26/BSwskDqqSbRV5npw8e0bKUw1MJo59H+ctOuJ+ZcrQ
rALNEm3A9nzInBQLmoJZBauvQcsDiNVVfnPUWSWcR0/nFLeWc6ItKZzPJRTXayGzyGfKVKa4jkW7
zsG1GVpwHViir3/ArA7h79r0hMyH4usmOp9JHs5nktRcvGZKagtKigX0FXr7UQB99b4x8lkFuTcr
csoy9L14+1EAffucxlM0T0W1sEFGXPQ1ePtRAH2dnUYB9EOjACW20bv3qNVX9/I5OHguoS8+5BTR
Y/JIHs+zNvrCROcSGO9gT504TllmgGZo3o2Y4PwbfU2jThHu9ftHWXv/fpqhY4kJytCXQ9pHcV02
htZlIkNfKkmshHjDsTRbtE9k6HszleP5WztfxfNzJszQ13XoWBqLZyI1RNvDOq6fwZ5kXFGsEh/Q
962T4rjXp/z2SPTSd7avw/O78cd9AU5Zhr6WTrNKlPM9qIVUYejb8KN99CSJUvXBNBQL2usIoZLS
nahlkg+9d3ENmH8offUubY6+eESj562KW8sSuZqirzdRPz3Tw0d0EaanLUP5DNdRRVbTFdgFsY2+
10A9BR1FPcXHEon05W66KnwPVLXyfM3OTC9t29vYzkFD6CM+oC9s0dxwI11z4yV66atk1Hv9oPha
ZoX4gL6lRbOsONnmyVJfwtqGaKtpFEBtobLEKH1LYzGYbTRCoxqReQr6ohiN4697uVzXpaQvam21
FLeJLLF6sGZoJoaYmlIL9KWM8j6e1cwO4ZSZrjqf2miRlE/tvN6Ffuj5OmpZ9XXLOiVW05OO1BYe
0K3kAdFGT1ZSWwj3cltYIxZM1xF/p5cjvp/ITNMRT+d6ivg7RGaUjuvjHo7rS1ILI3X0khaK3gWi
LV1H72IvR+/Doi1NRy/ZRtG7RrTR84nUHyT4uD9IEJkpOkLOeTh60yWqXtDMdA/b+IpYQOuAvsVZ
Zj+YSTgiRRhafURXrCRD566gDK15Oot28xaYF3HELmFoFRedT2leJxutfrC0elo7Rm3uEJinw3jV
CzNP6pqjsRjVnF9qbo4uaTfFJaWUZWbrOqVzPdVpbYkqegaXvO/RbSE4G07P0FOPRPflqEcKXmfR
Ox+p38lR3O/kSD60ciwT6OHhnjxYnqnao0sVz4tVl3zo2X/qD4ihI4ZK/Uy0ZahO6W0H1Bpf8nFr
TJDehd41sbwke4dGkIukBdObHagtLAvlNrdM5mroLQxmmyYfBMcH9NzdWyjDMrQbWuvTU3wwWpen
4i+5ubSC5Zj4gFYU0tVNc4xdctAfXJI2N1ZbQP0OWdBIfEDPU1JP8aOXe4qVMvKmZz5pdEsefQvb
ATlv05OP1OpX6Fa/QqKKnltcEeC4pnHzMpFZqfhnQnvUPHAdeKQDUiAXGIqQeQwwlB+gX2/e/6bM
XItMH+Dlm8qWFfncXLhKlVIPqO6qNf5vqbqqSsCDqhWitKdqprpgH+15GOiG7Q5Iy6oW6h7VW43C
b0PVV41VaepRlY496aq/GqiGq0EocaLma6kU8AP/cC4JOpeeqo3qiN9u2G6mxkBzGo4fBI1pyHkQ
+vcJkB2FnOmvStg7GP/bW9IfaYpryf8rS9xodC35v7PkVzUN54mxSR3b5Ubm//Wo6eC+eyG+ux03
A1xoWJGFdtxMcB+8M/tNO24W6WxZ7A077klwx4btzGymCnJzwbWvGWhiJ4eTYW7Uljffy430Kh/O
A0EO54lc/WMj11nVV0tmLBhCx93441HprZar8MHX7rbjNraOw4AlLNSOWzK2hydEhfntuFq993si
HLiPjaHeyDyuoJ3vpsz0hjnIjY9/1etky+Y2pXxFHeQaRTzoy3rn2jw7rni91SRnq/On4d/7nPJL
THvOf+n5C4l2ZUgavdTvJNextzfEqexnoiaHpO6Pb2vHeVp3DTjZ+d91jwbqH8h6yI7blzDa8Djk
lzpgvuGks2nP+0Oz3n4/247L7NAr1EluWMMLoU5lr5WeUcQ/rM9WO65VxK4iHof6m5NwuMjoHZ0W
23Glw7ZEOJVvcWS/SCc7D7T5e6ST3Hs1S0c5yb1bvnLUusgek/JL0f39xVN3R3HZC+occm/94k75
ta99ryM3v9FSR25Ip5PFM8pETbTj4mMXRxd38OfmtGvRFd69s6ttvLQsHeNUf62S28U4ten3e6TH
vNJ5Ymk7LnX4phinun2pxZ4Yp3Y7uVa1Ek7+TJt0V2ykA3ch5rlYJ7keLc/HOtXt9K5NS84bWKOW
bcx3TCsZf+xvvey4H0ctLelUhmdSp5aqfvh8n5YF+nmlXk1dX6rjE1lz7eR2N61RulXc1WoFy6DU
8H+xdy1wWVXZfn1PPt4PUTHNUBERFFBBEUkRFBBREUHwHQ8VUBAREXziDGU5ZeZUWt07YWk11ZTT
2OQ0dXNm/Kk9prHymtMts+5UTjXzQ6dpbuXIXWuf832s831n8xBFEfbvt9z+2Xut/T5nn33Ot/7l
p4JkbXhg5HdBlc+EvKhbz+G7+uWl7AvXS3u137P9HvvbspN6feZp+XW/d7e9naaXtnXowJtkdbmj
9tWbGi6ENOilxU1a2V82J/xH/bG/zOZ9cRf7r3/Io0YvbUXQ0QGytVJi9L1ZNq9rzEtululZl1fe
LFtHvwq6Pzi6POQrvbSBxteDZWvskwz/QUcuhn+pl/ZF5ZBBsnrGxscPlt1vdw2vHiLT+23FhiGy
e87Q2N8MkfV1w5zkEJnNzzbnhEDEYN09w3P5uSHVbwc/pJcW0LcsRNbXdWl/DfGVjdHQPw+Vtb0m
4suhsvadN303VFZeQpgt9NNfN96jZ/MXq8KGya4hdamThsnK2+W9bdin34ced00DGHBredjTAwb8
kOlcHJZ3ZubBMFlfR9z6rzBZGz5eOXm4rM8+qzg5/O7AsAf10k4ueC5i/vK/+OmllY04EyGbExsX
nhnpU188Ua8uOzxSI2VjlDRsZqRsvT9R86dIWdtzjCVRMr1tCTVRIc/u+EQvzWvplqgjt7yyVi/t
rsK7ohoSTuzTa8P7a+4ZI6tLYu2ZMbJxf3FsUEyQf2mqnt69OdExsrn0sd+0GNnYvrikOibL/eRh
vbS8iRdjZfXcsykuTmbzA+9FcbLxe9nnt3G2R5aF6tmcnv7OeJnN+I0fxJ99ID5MT+/DkZ/Gy+bS
m7meE2Q216zuN0E27qU+9074xrSzXi9t75p3Jsj20EUQmCDrs/dDn5Gmeac+dKu0r/s8PUmW9vHS
0ZNl7duyrClJpve/qaHJsrSUOTnStIjgd5Nl5b2+xjRFlnYofpk0rSypbIps/Epu+XZqefHnpXpp
O33fTPGVjN9/+oalytoww+e/UmVr5aelf02V7bPyJm9Nyyi8YNFLi0nqOy3jlxv36qXds/zLabJ6
PldrTW/cublEL+1XUSnpsvn5XdyoDFn7klY8nCHbM3y64JGZsr6O8nh4lmyM3pp8bJZM73xBZWZc
9OAlemmmCq/ZMpufzFowe/FPDk7X01sNcVmy9o11uytLZrP/fLdsWZ/1j52bLXve3F60JEdms8H7
cWnak3n7czYn2frr2QwPfDsH/M5+76oHcM+kL3IO7jYvL3RWQ73qKo+5Da/D7Hidc5u9Y3fPld3/
skqG5srm9WpjZa6sP89PvzdXdr0eMvWJXNneNDW+b55s/1mxuCBPVpcn50+Zp8xP17Tny3bNCyo9
/pSezVs2RsyXrc39RQfmy8a295iYBbLxO7MiWZp2f82iRbK0/LQTi2Rtf6psxmLZet9tyF8ss3nM
+PvF50pGv6anN27id4tl89rfL3qJ7Jn5ji3vLZGNe936p/N/9tpzw/TSSqpeyp84+/AXemlpW/5e
IBtbr9k+hbLydq39QJp2pG9EkaxffjM8tyj81Lf/rZc2af3mIpnNX1Q/KrUZn/n9Mpnehgn/Wi7b
g+2Bt4tlbY9NOl8sszknIaJUllYwYFmpbGyfN9WVyuZ86rrtpbJ6PjJrxIpdtct0zxkWFpxcIeuX
8bUpK2VpF1bNL/s2u2Grns2IoZvKZHpTym8tl9VzQvy75TK9OzKmrCp44ZTuvTF73PoKmV5h9klp
2nsLPVbL1ubd64ault3jLmQVrZbZvH3IP6VpNTcNqpSNu0+fmErZtXy3b9Eamd778OAa2bXuoNeK
qju/DHxJLy23f22VrH33j/x7lewsKKXyL2v3LH8hUE/v9kER1RXbXknQS5sx5cfVT+wZcUwv7ZdR
oetkcz51xbx1E/9xLlKvLrNL/7FO1i/LDH+rkaXlzfOolZX38syEWlnb78tIrJWN7aLK/bXSM1zr
hPXPTXz5Xr20zcVvrJethweXZmyQzYmd8+s3yNp3KuEPG5TnONe06OCjUpsnZ5ZulNmEuK0bZW2v
2vDBRll/TvKN2SRL6zdzwaa8MdvHpTsnYdrh6u2bZOWt7vX4Zlk9j41/UZpmUGOX4AfgW3/C6F+/
51LvoxYwnDDSj9YgUuTt65ofPIWGzc2hYXOzzsL9+WyUVWGo9lJjy6oNFodqg6V9qnFmh2qcuX2q
2ibqqMp7p9jgUC02tKl3tBrtKozqGf1v16EA8SNZp2ADEDmVL2lETnteSwt5LWreSDA253eT53dj
+SPBxHTcpTruTjqRYOZ6njI9Tx29SLBodL0lut4S3UiwavX5AmH6vi3oR4Kbkw1/XRv+rdiIFK6q
5AEflzo6udquakNVm6L6ZDtVr02pTPXiVV+1rLDqa9I7p2/0Uq+kavtnAiRqNYoJ2kgj1EQaHZwz
7e3Ha74YTzeaJKq+QvU4qsYpqscN1uR0P9Con+tqE70Te/naqF4nlxIAxzbBseDIG1KszTDWBsnp
YTiPTKhkIiV3SIZiyIcKqBKfngU7tFz3P9Gi/ETcMR1WdkyJRqtidJwNxttggg0SbJAUbkhOHwBp
4Y5i5oRDtg3yRCVb2zcN0tmVKWWMtxlU03a7DqNt2WAFCcO34ZWm4aIwfJtJNexkFe21dQPWW9hs
RJt+is1Gu00ng+3anQmjdbj1rvtBGK0zt3+XJmz44c6/8Xthw89yebs1YYeeIG5T7OATRFt2bSby
GqqE5ikoLvXRVv/6E9/pTkVPmIzTsAKnYTkUQQnU4GS0QXw77whd7qqhUVUyau+TFExCNQ1n2kJF
Nc1kFSqO1eqiIrsZD4c8Y0v10649zfWl8Zpc1S52vRt7B0vt1Gfj7rLZUrrUcV1qDkL1AKpmKqqn
3a16lyJQL0W6JwM6d8ZWTwh0VlubTgp0bmRtPjHQuWF1t3uT7omCX/O9SdiKtrbpZOEKbOAv4zlK
OgGDTI5JHGSymsHegJan4HEcTptaTTP9fJo1u+VJeBg7rEaZvIetVhs4d1jL0/CQzb/+nDIND9ms
Hi7aZq0FnYl4wMO/Pk+xcMDD6qVrweJkxXUqPuXlX39cmc5PeVl9pFaszpZcJ6MPDrhiqcHH6tei
JTcXa87T8ayfY2qf9bMGtGrNBu29F9wAj4SJWrVg/KOn2GjeiRfWs5e6+f2uOz2nt28PfNm909jY
advnLndc3Kkb2S53hNoFO/bJ6/lx5NqdZhtb1ADwr1dfULVx38Y0TrT1wYHptPUVo45e+x4ctLrt
f3DQ6l/eg4PWxuU/OGjtdOzBQWurLQ8O3WCRdFo9O3BddT0gSNQ28Qq/o+pOr0A6MBbX4LbTqTfU
zh9F2UGFonrcwA8qOvSW8Ypeb67CYuzMZQFz8L95+DwQ1wQQDt6oaBSfm7jBNHGwuFQcLMYAHUtm
Y95gkz2vjyRvrMibg3nPOfL6SvKOFXnnYt4DZnteP0necSJvLuatsdjz+kvyxom8eZg30WrPGyDJ
O17knQfKF2yUNxIGYa4AC/ko89bkTcM4Xxy3lsNyIGeD84E8xV/yvQ9esJDHeJt4UcmPZbGzYQGY
QgxuIQaPUJtnCqp4Qqxta3J6MJSluZvhEFyadR4uYEzvRdfAWiiAJdjb01AyYCr+9U5YCMkhhqlH
62hQR10ckuIYTTbCVmg90MRoPZc8qDUfoNR8IbacenUhEM+NtneCIUn4/liKaf1gEVhCDNYQw6gQ
oI/2Aoo+xKr02nc3NSDxzotNyel9YHoavZE04hw2QrGNeH7I+gsmYuhxg0y0WwhV2DuVwqYXLIZm
g75o5Ycmrj0XsrCICxbyvB+AdVmFNSOvJdliLKvwf/aRLRdotLC5BEfKpNrsJWxSzbjdJKwJttma
JHpDzy5ZssBtZAkCXWyUp4E5E3PjDLNmAs29JFgpfOmsYFYABmLv+dR/2ORbvwO8j/rTG+QTxky3
ne5+PmIkvByWyWIY5CQ+BoOsYUBzKA1rVCFelq8Uo7ECaHZMDDckhRtHQxSWPdpKtTTj/CrBMaoS
9grBIxQ8U34K2H4vrK8b1tdNDPRYMRJJ1rGoaRZ+XipR6O5TpPZXr301EIii1UvA64sBsqwJbRyD
MaKeS8XlCXD9joe95gJrHtrwdtSU5tVabNdK4WdGud70hWVUD1F9ADF8iZ6B+3Cm649hvGhPpTVe
9EEB1msl1oL6YDlrTy9lrjerijlvwi6OxAvivGwQVxQK5P2LfFAsVhYJ0P56EAq1ZwoonuroSlGM
UoayGWUHSgPKflB4SojxgvxMngLF29pXoDB3jcWeSEHJRikwKF6fiXngI4PitfULlK9RvkUhgnXy
ENgPZYhR8X6ZgDIZJROlAGUVyo9QtqE8cKV3VF31S7FEg0atq93Ge1R7VKWqV/LI/cY7Z7vmL5hO
36Ade2V6pwMvJLrft9I3+CTq1G+Rr5ediXRI2edABwxWgyOn7ARf+9av0z79iTNf/qc/DZaOffpj
c7t+Pv2psHX6pz9d7FJ/LU+e2/4A0L53+F3sO9ZrU2on/8rkOriyd3Ba9GwW9SdSez/DvtK7C/lV
RCm5ex4j6M1Wk44qqlAHjeyaHdSzJq/CfaGnY3tm7A3YO13/wPyy2tqhDf5V2iL66pTsot7xb3ba
PZnkz/E9v6DQf+7lVnp+QXFdrd0OX4qdZhbYf9fMzsBsbtaeX4/3/HpcsnhaWdId+fW4IyidxY7p
Kmz6U9JD91fkXXIf0HNj67mxde0b23X9S/irvXlWVLWb5w6drXanD8m7rWov1CUGNa72Yye8xQnf
5YR/cMLkaZtjYkrg+JKa/5sR1WYDw5kjtfhZJ2yLVLBz+c71/ZET3uqE65yw3X6Rap88k/N0Yurg
2Lm/iG2MY2JO4JiYizgmD/Qck4djjontgGPyLMwxeVblmJjQOCZv3y2lE+sKx8TGwTF5lObYefyJ
MYpjYpfimNi7OCbWDo7JuzTH5GmbY/LwzjGxUHFMjDIcE9MBx+SVnWPytMsxeQHmmFj0OCbGKI7J
cy7HxHjGMTFCcExMORyTJ2qOiYWGY/LczjF5p+aYWCU4Ji/iHJN3aY6JhYljYj7TpEd8qakfsV1w
TKwuHBOrml76YXW9kGdonk5MLByTh3mOyQMux+SBl0Nin+KYmBA4Ju/yHBP7CcfEZMAxebXmmNga
OCZWLo7JszbHxPrEMTF8cUxMTBwTawzHxKzHMTEJckxexTkmZjyO7dent9T+JgYZnk6MeByT13CO
7fphUYo+sUDwdGJg5Ji8QXNMbFIcE1MSx8QIxjEx/3BMrC8ck9dvjomJhWPyJs4xMXlxTF7mOSZm
TY6JNYRjYoXgmLzic0wetTkmVhWOiZmGY8HYxQKx9nBMLEwcEwMIx+QdmmNi1eSY2B05JkYWjsn7
OcfEDsAxeejnmBh5OCZWHI6JnYxjYt3kmJgMOSa2BY7JWznHxBLDMXlW55jYSzgmT9qa/N5/1LZ/
nodmPhKjEcfEgMcxeV3nmJhbOCb2DY6J3YtjYqvhmFhMOCbWR46JoY5jYs3g2L7+6qO0+5mzTjgh
Wov3OOFvVGy//maO0qYvdMKHnHDgaC0udsKvqJgYlYAFYrvgmLyUc0zsrhyTp3KOiS2KY2Jo45hY
dzgmj/McE7Mex8SayjGx2XJMrDocE7Mix8TWyjExBnBMDLEcE3MTx8RqyjExfnBMjGIck0d7jok5
k2Ni9uKYWCk5JjYjjolVjmNiZ+WYmGM5JhZIDR7zkma8iBGCY/t88BujzAdi4uPpxJrCMXnJ55iY
PjgmJhyOibmJY2J/5JiYUDgmBh6OyZs/x8QawzExGHNMbFccE8MOx8Q6yjExqXJM7CQcEyMzx8Tm
yjEx1XBMbJMcExsdx8RqwDEx1nBM7KYcEzOGJr3ogKY9xMzDMTEQc0zsIBwTYxTHxDLLMTEOckyM
XRwTsyDHxKDJsWCIYoGYqTkmhhCOif2JY2J24JjYIzS4eq5mPIg9kWNivOSY2FQ5JiZUjomNjWNi
e+WY2G05JgZIjonBl2NiKeWYGA45JnYRjon1k2NiYOSY2Bo5JtZxHojFmmNimOGY2Do5JuY2jomh
iePZoKmuYJHmmFhAOCaGX46JwY5jYh3kmNjFOCZGFY6JiZdjYujhmFiAOCb2RY6JLZRjYnvmmNi/
OCamWo6JAZrjplYCjKw2B4NylujsMYw+I1M8himUFU7HMaS+sAX1YIc6vchxcThG6oc6VnpgZHvU
3VHdnavrhYrLNTmp1a7uSoGaT/uG1nNefjjdpq5WOFp0Bp+HmKgrZupGCzvb1DXSJfZ1C+ptWOBp
0R0qfV+71F0WOIzq0GLmi6C4TaakM+xIx9SD8Wkn+ISS3VmdAm2pk9NDYFa6B6p6KKorhWrVaKXk
llXDHL81F6qDg0n1eJtKjdZTvdZhwBhq9a5W+lt529DNLgidEy66Tpee0E1CU6KpzgBb8bmZZES/
XCN9lrRVfY7eosYGf3J5EVAUhMux174i4cXDuE992Po5PhQ8jTIKrzGjUSbjQ1ASypEB+MiMUjga
oAjFMh63wChNdEg4BR/PcPPui1KDhdRmKIXVqRW5C2U7yh6Uh1DowX4fyjMoz6IcRHkN5TDK71B+
j/IHlDdRTqG8j3Ia5c8on6F8jvJvlEso82YAzEc5gfIuyvsol1CaUJbjA2sxSinKCpSVKBX0+4xE
Ov4RvjcQZ/dWsFHFRaEKNqu4PkHBVhVvn6xgm4qPr1Swh4q91ivYS8WwU8E+Kh54P+EKuPso4dWw
Q439jitxgBoHqvkfPqrE/6HmO6TGL6vxK2p8Qo3PqPFZNW5UY+sxJbapsYcae6mxjxoPVOOYY0q5
Y1Ucp8bx6t+zVJyt4sYG+jVMBQTuVdoXorbjrb1K+0PV9rzymJJ+VI3D1b/3eVzBnz+vxOfU+Gs1
VuzTZzWpfXbi1DUarSaL2WI0mbdpDgoAHlXjbCiBMlgKayAYZmK8DuMsWIV/ywd6FxaLdoxgsRiM
Bjer0fHNED+2q6N/5kAt6ihOYwDGhIrSPa1mIwVp6ZOhEsvPV3REjR3B5YMoeyK5gJoBU7FEgAmi
nAAI9Nok0mU6aZg/A+biv6SdjOUCTFLr6GE2GtpWx2DhlChfOCUCGDdKU19p2cnYJ2uFDfrSEmC8
OjJms8lkMNhMsnJTVYdCZahfLhzxTLCKsQCn4DIWuaqzKbvTKTrjih3cttqmig/wlkK1cGU0VZRo
MFgNSlAzuZQ4Q9RxFVSpLpaCcXRWYe2rRNmDxXePdwaRryb1918QN3JUyth/Tk3pvWj0HUcMZmzU
EJy2GydRTYKBHBCZ/LaxYpRvR+0VGOT6tVxPuIwQEE2D2U/MLjqZ+3ZGaxo8RGpeftmDMp2bmuwn
Pcp4UvDBKwtdVUrFv/n49+n4b4lwc1UMfXGV5uD8SxNrm2bQLEjB9ZqLKzAL/0Z/mYeSjf+fIVb/
1Qpf7/8dXovdzbg9CHhN+ZMy4/Ev/5dL7SgoLSitiqjSHFYqwd3cB+ANgD6TDULo/kuO4PY75Sux
KmuwibHQyv5vD83vwlaPMUJof4DdM42iak+qca/blN7nMT8BHaf+PbbANaY3e7djTDugdzA+yfIf
XmaGnfhfw1IjPEHlYUwnk68uVdKd4/c+MOnGHxWaxfz4uFB5L9qWmOqfWWKGb3DxT1lhBjrRNBWZ
4VWn6yYFe7vt5TmH6S+aoH4owJ8w3Qyu9SO7FFL/R8EvzTRqYnv77IHwjlkGOF+I/W9o1nOOyX6M
aifGq9nOo0uMkMXsflSoeV/sCPZxsMfO9XKOeX9ToHoMtjTXp+SsCXbh/IlNM8PTuPC/mm+Eg5j1
PNZnMFx+sJdnb8/+QmU+RX+yO2b6G68ZqP6XDM3zzg3rk4jxx/lm8ffrI9DWw4hiQjGjWEwKcbAb
ig3FHcUDxRPFC8UbxQfFF8UPxR8lAKUXSiBKb5Q+KPQyLQilH8pNKP1RBqDcjDIQ5RaUYJNydxuM
MgQlBCXUpNz5hmEchjIcJRwlAmUEykiUSJQolGiUUSijUcagxKDEooxFGYcShzIeJR5lAkoCyq0o
E1EmoSSiTEZJQklGmYIyFSUFJRUlDWUaSjrKdJQMlBkoM1Ho44tMlNkoWShzULJRclDmouSi5KHM
Q5mPsgBlIcqi/2fvXMBsqvo/vvY+55gdgyHkFkO5howuRBjTjOuQDE0kDIbBmMHMuOXNuCaURAmV
qIQi6U65lMq9KHShFJXoMugmr+b9/NY6x1ys/qn3ed/n/z5Pe57P2nu+Z52199qXtX5rnd9aG3pB
b+gDSdAX+kF/SIYBMBBSYBAMhiGQCkMhDdJhGAyHEZABmZAFI2EUjIYxMBZuh3HwD7gDxkM2TICJ
MAkmwxSYCnfCNLgLpsMMmAl3wz0wC+6F2XAfzIG5cD88APPgQZgPC2AhPAQPwyOwCB6FxbAEHoMn
fQX7uZfx/3JYAU/B07ASVvnk51WlVsOzsAaeg+eBQk+9CPJj9cvwCqyFdfAqvAbrYQNshE3wOrwB
m+FNeAvehi2wFbbBdp/5iXunz9T6Z9kWNrp52yH2BePu9ZnP/j8v0v5J19NoxmnbZIQq4EXxh0s5
FXBCaZFdVeSiYC1qPtY/4R16u13Eka7rnVDJuF/OfdC0j8LGSaItlaqndP3zSwmuRv78/PE3lLYA
1w4xpXeitt37q1g9AWuWbh+mqQKeHf/nUlG5jmTlz+x/h5yobWY7gHUnex2qW0Bj9HSoA/QxiZKJ
xZiuCvhpFlpqs38545KbC92//M67OlgDTXDNZKCTYDJMgamumRx0GtwF02EGzIS74R6YBWIlzYb7
4AGYC/fDFpgHD8J8WAAL4SF4GB6BRfAoLIYl8BhIn5M45SyFJ2EZLIcV8BQ8DSthFTwDq+FZWAPP
wfPwArwIL8HL8IprnsXfWzYFP/+9OFv5fBtshx2wE3bBO65p4e2GPfAevA97YR/shw/gQ/gIPoYD
cBA+gU/hEHwGn8NhOAJfwJfwFRyFr+EYHIdv4Fv4Dr6HHDgBJ+EU/AA/wk/wM/wCp+FXOAP/hLMg
05Dkghjl0s51wQfitxMAmUssDDy4CIpCMQiH4lACSoJYgaWgNMiQgDJQFsrBJSAdihWgIlQCcbi8
FKpAVYiEalAdLoPLoQbUhFpQG+pAXbgC6kF9aABXQkOIgkZwFVwN1zhmwtzG0ASug6bQDK6H5tAC
WkI00GxRMXADxEKcYybbbQNtoR20hw4QDx2hE2AIq85wE3SBBMdM0NsNxLEkEW6B7tADboWecBv0
gt7QB5IcM6lvP+gPyY64llL/O6b3YBAMhiGQCkMhDdJhGAyHEZABmZAFI2EUjIYxMBZuh3GyL2XK
ifFsZ0MN7oEkcyvoMiQQLB+k80v8f2Tkm/htSD8bxrwSn2QZYyYtNmmFiU+EtH7Fd0X8+cVHTVpL
4nsk/hfS0ha/GfGVEf9s8ZGoAlUhUplJkqvDZSCtH/G5ET8T8R0T/wvxsawL0vysp2RyGBlExfUH
GvTUH0pPty2+w9LqEB86mVS+MYg/h/g8i5+c+I6IP6H4FMs07eKbG62U7h2LUdJzZSZqFh8eqbTE
96stiI+L+C11ALHupdNA/OrE91BakeKjK60aaaOLP5T4pIgfkviGiP+Z+LCJn5X46kvbWNq14icj
vl59lFmk7OnH+g65/qzFz1gml0+BQSB+ZNILJz2H4sMi9YH45oi/tvhkSU+b9D1JrSU+s9JqFF9W
8U+W2lz8bMT3SfzfxGdW/CzHK9OdNYF9ToRJMBmmwFS4E6bBXTAdZsBMuBvuAelhE9tmNuv7YA7M
hfvhAfnfNffZfMdMWL0QHoKH4RFYBI/CYlgCj8Hj8AQshSdhGSyHFfAUPA0rYRU845g67FlY45gJ
sZ+HF+BFeAlehldgLayDV+E1WA8bYCNsgtfhDdgMb8Jb8DZsga2wDbbDDtgJu+AdeBd2wx54D8TB
by/sg/3wAXwIH8HHcMAxk3Z/Ap/CIfjMMZN4H4Yj8AV86ZhJvY/C13AMjjtmku9v4Tv4HmQI1wk4
CadAeg1+dMxE4D/DL3AafoUz8E84C9L61L+pu+bZlnJUnm8pH+UZl3JPnnMpz+RZl3JKnncpj+SZ
l3JHnncpX6QaOeI3z7RsR3InyrYkr4Lb8t0uSWmDk9KSIjskDUrLTFF5cdBlW/bfKX3E0KTUBv3T
M1WaaFJ+tO3Wpm1cQmTCja27JrbqEheZ0D2ha1zHBP19Ka+uvqaR3pbj6Tio34j0jPQBmZGJ6SP6
RzZp0FB1jZZ9lB/S+zllnnf1edOcnd3WO3r7+cfXbGgS3E65uozYpr7gcclaemllLT21srYtv+XK
cbjn6aK4e3fufahBpYg58zx1Rb3Tq6R8CRTSpA6Sn2jlvMt+5ZmX8yXPtpTF9ypTHj+oTFn7qDJl
6zJlztlqZa6JvDpCzsFGZcpf+RFFruG7wbQ/UQWvlT63WQNTkjMiEzhjo5JGJEcmjMnITB6aofMq
/dGyjgyupbdU1lFlPRUayvx76yoRJi/mfgiPMFuyV8lJ10GZqckqdJ6lTg/1A9UOal2C35VyU+Kt
Cf4vyP3au3O72N5turWL1Z+Gh5S28e06dUg4l8tWypTUt1O+t6IeiKGeaE0dEUUdcgNbN1DW1+e/
KMp90ZoQNiRmfcKG1CEN+UZD6pVY4sZSn0QpM95A0h0WzItPH3WMXpdXeXeJrOXqSS0ntd5Q3feb
SgmdTm2Uof+XOSlM73A02xn8NWCdptf99K9S5vuO+k8uDnewr6gpqwu33SRHhZ6p2PR+WUOT0zL1
deiYIBqSvgNlu0Ho8wZN1A/XrSngMGxf9itT7/5by7tbj405vXZXqZkT1QrVYXkxyYY8JGKMXPjJ
PlQoFTEf/uqFu+Dl98oPueqHpiw6efrGlIinZlNW1HruQ7F3xGYrFfxcygb5ppQNcsc9rsyzJGWC
3H1SBogdJ73bYssdVcaeE7tebDax16Xx6LrmxRF+CICMVA8DD+SWKApyTuXFEsWhBJSECCgFZdy8
9m9ZtsvBJVDeNS+iqAiVoDJc6srQF+5siIRqUB3kZRWXQw2oCbWgNtSBunAF1IP60ACuhIYQBY3g
KrgaroFrXfPiiyZwHTSFZq55EUZzaAEtIdo1L8aIgRsgFuKgNbSBttAO2kMHiIeOIB3PN7rmhRo3
QRdIgK6uuLVj/0EiyCSf3aEH3Ao94TboBb1BOriTXPNSjn7QH6QzeQAMBBlgOggGwxBIhaGQ5pqX
eAyD4TACMiATsmAkjILRMAbGwu0wDv4Bd8B4yHb1/SPNc2lmr3NN81aastIslWamNBela1i6eaXL
VrpopetVukWle1O6JqW7UboRpZtPuvOk20666aS7TbrW3oWD8A2chLNQjPu0NFSA3iC/RWTAFJgL
C2AZvACbYRt8AF/CcfjFb14oWQaqwuVwFbSATtAHhsMEmA2L4HFYDi/CZtgDB+E7+A0iKNFLQTWo
BddAU2gJ8dADUoqE3vsSWuSmjw7Pe2jz1BZWtblVvd6qNrOqTa1qlFWtZVV/CrOpP1jVU1b1A6u6
z6qetKp7rOqXVjXHqi6zqius6lKresKq7rSqW61qtlWdYFXHW9U7rOo4qzrWqo62qiOtaqZVzbCq
w63qQKvax6r2sqq3WdWeVrW7VU20qnFWtbNVjbGqraxqtFWNt6o3W9WuVrWRVb3Sqta3qnWsag2r
WtWqVrGqlaxqBat6iVUtY1VLWtUSVjVgVf1W1bWquUVs6lmr+pNV/dGqnrSqOVbVsx7ZUWvcr6zq
l1a1jbVcP2yN+7lV/cyqHrSqH1vV96zqHqu6w6pus6pvWtWNVrWG9TxUt6qRVrWyVY2xqh2sajur
OsSqpljVgVZ1gFVNtqrzrWpvq5poVbtZ1S5WtbNVjbeqs6zq3VZ1hlWdHp63bT4NbZ0fd5o1hTut
6kSrOtaqjraqWVY1w6qmB9W0Ap/kX/5n3hn4d5vhT7cZhgRLL932Ni1r419D6NdhQIc6mqk0PE+H
eupBTw+d9XQHm6dvJE9PDuPpN4F62n3O0357nh6k6mmHRE8PKPb0NEuenjzA00NsPT0w3NPDYz09
SNnTQ5s9PaDZ09PoeHowq1dFh1V1GKnDajqsrsPLdHi5DmvosKYOa+mwtg71JBleXR1qH0Kvng71
5FieHnLt6YHJXkMdRumwkQ71hDCeHkfs6ckRvGt12FiHeriupye18fRUCJ4eIOzpaSM8PXmM10KH
LXUYrcNWOozR4Q06jNVhnA5b67CNDtvqUA9y9vTQda+DDuN1qL1HPT3FgqcnovA661BP2uLpqSQ8
7bjp6WHynh6s7Okh6p4eOOzp6Qk8PcmBp4fie3pCJ6+nDrUDpKeHVHt6YgCvjw6TdNhXh/102F+H
yTocoMOBOkzR4SAd6qkIPD3g2UvVoe6l8rRrgacHenvDdKj77Dw9tN7TEwZ42hnCy9KhHmLtFSx9
5V4OtYkN+ctne6mtVMh5tvASSjEQEoJPTN535WzL/nhu3pL/JV2/uv7ctqzl3pMrNJoHapM8VDwi
cRDBjR4Lc7jJ90MjbrSB8D43UwS30i5uCRnCcpDboQI3wwAu9sB4M4xlKrwF70NbEn8DNsMx+Ab+
weWeDjNgFtwLc+F+WAxL4BlYDa/BetgCW+FD+Ai+hmNwBs5COPksDqXhYoiEalADakJduAIaQxOI
g9aQAD3gEZVvyRaks/DcQHWt2OOcG2yvlYf+B+MsiDY/uf5n4vyhEq3ylgtXlPn5J0+RvZ+b2Oyc
UvBbohS8pudPTrwg/z86zoPnKX/H+TvOfz+OusBlXCEes7BUIvqx9zCSzvJIvIDh8TEGwWIq6k+p
lJtQDd9F9XvzNuMiIvZBrDKuHlJfSL0ttbM8y0nBtDpgjg3hgZLWXyrmVVHMqlaYUFGYS1UxkNZg
Bq3FnGmPGVMXA6U+5kYx6o+jmA6Tqay+wCTYRMKrKM97USaHcwxfw2yMgVbs7FTweJqogq4qIRcV
sVXEUhELRSyTkEuK2CFif4TcUMTaCLmf3KKM64lYFCGXkz7KuP9InjIpZNZgDE7AnBtO/ZfMSXia
RO6U40s0Qz/EshIrSiwmsYvE+pG6N9QuEaskN1es0TD2K++Yl2FRowg9PaxOho6NUsn6Te1/dsBL
CfQ0laWG6UFhMnwmRruJ9tVukj7itFPyU+8Q/iTtLDWQdpIZ2ifDsQaoTPYtcc0ArTH6zfHJpJWB
hRHFESfptDP1r3lDsDaG6gFog4lTnH1noA/SoXw7Rackx1GSs55FzkLvq49DHUb+0tlDMn/jsTUe
gAchjHNcBSLhEmyOBtAQFlCcPwvPwXWc+87QBT7mBjgJP8BeLvg38B0c4cKfgbNxxgZ5BjbHGxvo
4vDM3Puz/0R4S5ncstli9Yk9J05C8sRcXG0un3GYOX20UVYkR+wnN8L8nDjUbywyJ3jvyHaR4P/y
NL+jnBz5KbCvCsu5XD4r0mjq5DoPr5488tr03JfDl/X8PlelBKunzyea0UWNgnF9/oh1Hw6ZnvhE
zU0XHTv0c8et83PV3uC8pu1TnUJxpz3768EhhwZta3N53QfeWT10Ta4aG6wsq24pHHdk/2t7rerb
pc+ob2es/Wn3jCa52l1PlvlPBgrF9Q3b1Xp25+dneYfbLaqfeGlWrjoZrEDn7y+cbuUN3Z9YWXb9
5MRJzZdO+uXSz3K166ssM3ro9hz3s4kbCCwcfuCxaoeOrayY0rxZuQU/rOQ8lAjG/bxwuuWmNOt8
ak63vrdWnvnEV4teej5XhZU3cU/lmLh553fz2sETv21wfJ46/LNbZdLRA7kqO3h+Dx0weXODcc9f
zvcQHhGMGxZ2pP2M9rFdN9W8osWJR+OzY47navczWe6d5CsUt8+Sw2lnHxi9o/y+Vwd485LyxT0d
jButqpyQq60t8mxjm/8sXqMllZsjBW6k8nKkkSvZC3hi+PhypBFYUvlzjC/IRTkR6vzFVUVzTOM4
2EyQBHfEOyoimKA4dUqPWIQqf8If3IEk3os4F5y43yQu8aXEi3GMLj0A4v3QTxXTZyLWkT2IO6Wj
ncoi1HanxafiKCa3Ra5TXjuGROT4z+2hlN6ulC/t0sF96j7OolLaF8uRb2UrqY2ma32Cs3HjRvYQ
oZ0tTHpN8qVnJkstHtxPok57h8rLz+vBtC9ziuWI9SwOgH5ytVCJ86s8xyYncZsk/dabKkocR4ai
Zuvbb4Iz/ypxE5QGljmKjVp/XSub9fZ2Z1d54x4Xyvk0fSv4+cvJNdMRLlALoZM+mHApS6K1X18e
fSTbJn+6fR7Mn9SGkidxEgzl6Y18eRLn14J5qpUvT+N0nqaelyd29RfzVJW/nNxaqhZtzeqqLv/V
VxV5nitwJcpQP5XGhijDM1GBmqKiGs7nI4iXSfyFMJ//51Jz3aNKqcmchzHUSIPJV08QO6Q564ZK
BjSGscdw6qRSbF2CIn0xtfRfNJaL5fz9N8l3rWLyXasOwWslVzn03GwOXqsE7u0qyv7cLEov/MTE
5ku1jjr/iXnT8sTczBPz5u88MdH50hunt0NPzM067R75jvjtYNoZpF3XesTcLdkqeNy7HIle8Ohb
5dublDmFz8mWv3RO2uVLtYU6v4TaGkz190uod/Xo9t06LJh243xpXxtMexrrJeEm7W35jljsz2wl
NqdJVVxKPTXpDenT2+CLxN4M8L+n1v9m+mRk3YcDXYKRGlqHdLNljuHqfMdg7qrQNep2Xl63/xt5
bZ9vP1LSSNoTVV5ed+S7t8T+zVZi+15ILkfdZHIYWod0s2X23qnQ3vNy2VUfSZeSeeXcO6E7kXKu
esmQw2SMc5sn5dzuInnlXGyYlHOdwgqXcztyd/zpcs500AXcZXUcVcS9Zd9vuS1dF3GDK2dgms+c
191OTu496iZnoEp1uqnbnTg1zblGzaf0XeFUVuuc0moPFf6ncNyhxHc9Vc8tquLd4qonBmaqW1aN
cS9VU91aapYbpRa6zdViN14tddurZ902ap3bUu1wG6uDbn2V49ZWPxHvDPzm1sBoooT31Wa7rjrL
Z2eDusNVKeKrrEr4SuphnNk+V90HT/j86iVfmNrqC1d7fKXVAV9F9ZWvhjrhu1Kd8TVVfn+cKuaP
V6X8XVQ5f3foqyr5B6lIf6q6zJ+uavpHaOrAFVDPnwlj4A7V0D9RRfnHqzj/OHWzf6RK8aepsf6B
6mH/APU6HPMPVsUDaapaYIRqFBirYgMTVdfATNUvME9lBJaq7MBzambgZXVv4FU1J7BdPRL4QC0P
HFKrAl+o1YFT6sVAwFkXKOtsDNRw3go0czYF4tju7PyLvSuBrqLYttVTdUPCGEggJBAIMwYIswwh
BIEoo2EKQyCAyCCIQABF0IgDGhz+x+np9z9836cg6nN+X304fRVFAUVQQVABUVREUQxPHH/1vV3p
01XVNzfdWQuyVi3XWbm0ufvsU9U17XO685JRRH7OJP+eTa7PVXYY85XdxD4xFiifGyXKH8ZKJQGX
Kk3wjUomXq90xRuVYfhVZSo+oCzCp5XVuKl6M+6l3o3HqhvwavUevEldj19Ub8XvqWvxYfVqXK6W
4N/VZVjVrsAGsVraSly7wlbjOtoa3EC7HjfWynC6dhtuq92Nu2kb8EDtITxC+weeqD2DZ2n/wgu0
l/B12lZ8n7YTP6C9izdpu/AjxB4jdpL8u6++Ew/Tt+Nx+ja8UH8Nr9W34A36M/hxfTN+Wd+A39Tv
xu/q6/Eu/Va8R1+LP9RX4X36MnxAX4wP6vPwIX02/lyfiY/o0/GXEZtBbGbk51fk31/pRcQm4mN6
Af5ZH481oxDXN4pwujEDtzFm4/bGHNzJmIezjAW4s7EQZxuLcR9jCR5glOA8YsXGKlxqrMH3G9fj
F40y/Dqx7cZN+ANjLT5E7N/GdVjBa3AtfA1ujlfgbLwQn4dn4HG4AE/Fw/As3B9fgtvgxTgBL8Pl
xr34Z+Ml/LtxGGvYNC2cahq4o6ni3uYfRp75izHCLDcmmseNi8wvjCXmx8ZfzReNJ83HjNfM+4x3
zBuMneYiY5c5hdh5xntmZ3ItxXjdVIxXzG/1beY3+gfmUf1T87D+tfmZfsI8oJ8kVk4MWzv0xtbL
eob1tN7RekDvZ92gD7aW62Os2XqBNUmfaI3RC62h+mQrV59qZetFVltiTYjVI//GxH7VJlvfaYXW
IW2i9a423tqmjbFe14Zbz2v51lPaEGuz1sZaoWVYC7Tm1hwt1SrW6luTNWyN1X41R2onzHyt3Byg
/Wz21k6b3TRkZWmG1V5LsDLJ7zXXGlrJWmOrrpZsYfLdP9RMq1ztZB1Ts6zP1S7WJ2pXax+wT8i1
g+Tnwcjn7tZetY/1ntrP2qoOtLaoedbT6mDrEXWItZEYmVOsq9Th1gR1mNVFzbVM8ju/KAOs40o/
66DSx9qv9LQ+UjpZ7yoZ1lbFsl5QjptPKB+Ym5S95vXKfnOass8cQT73I9c6KDvNFGW72VDZZtZT
tpqJymumqTxv/oSeMA+jB8w96D5zO7rdfB3dZL6IVpnPoenm4yjP3Ix6mJtQO/NBlGZuRPXJ5z/x
ZnQcP46+wM+i/fgF9D75+TZ+guxgHiX7/o3oBXwv+idej57C69CDuBTdhVegxXgaGo6Ho0zcF502
OqBdxLYYndAmIwttMLqiO42eZEbJRQuNUajIKEJTjGJis9FkYz6aYCxEBcYiNJL8zCf/zjPmoF7k
d7KMAjI7DUXpRh5KNnJQgtGXTP7d0W96Z3RK74RO6O3RMT0T7dOboTf1xuhpvS7aoCegZbqORpPF
pwux+rqCfiTrwm4y027VMHpOS0BPanXQY1pd9LBWH20idpfWDK0js/ZVWi+0XMtH07QcMkt3Rdla
JkrTGqMULQk11Bogg3ynnKwSR9RaaA9ZNd5QMVl5MHqB2LOqHrH7yed1xJYTm01+r0hNQIXkO6PI
qjJEbYb6qxkoW+2A2pOVJUPti5qqeaiROpysQoVIU+eQdW4Z+o2cAX5T1hJbR2w9Oq3ciU4R+0G5
Ax1RbkH7yP/bo6whK10peon8/may0t2pFJKVdSQqUEahfsoY1EYpQOnKWNRYmYAMpYhsPqahX8nO
4BQ5s5cTO4SuRDvRnWgLehY9jd5AD6M96G/oJ3IKaKDcjroo9vr5d22TdoZ389KkSZMmTVpNNqBK
dQOn7FyEOI3nvdAaz0DgoS3wQFWE9xmNh4CRz2WR69FzefREHtUVKGp/gBp98xpVB8ZWeKAa2G6B
hwLiYTejgf2pWMBDT+ChncdDAddKH8TRSt3vuThGK+UAbyIl7MNAStgAgNraQYWa90c1UPPuC2Lq
iHjNe6/UvM8azbufoK/gXb0v0F19LkCFmjdF/TiE5tkLYOchXt/dL9B3L6xmfbc74BCNlc48F3Kx
HggR6zDgh+rkUN/9RKDvjqk2fXck8B5dhWiUY7j75NNA90k+8GBXzbKz9mehZ+2xwENrxN/fBwPx
Hg9QMxHfL4cE/TLat19aOBWf9k+7LwY5d98g5+6j/596LwDe20Y+034ZzTE5LGAyypeJ4Xiyf4ru
EINhMg4wae1hMorLc30OmNA818gYq3tXgJ3lwR7J3SdfhL5PsoE3UY9+KWjH4dU20kYA794eHc4x
OSpgcoEvkxzHk/3z+9FRBvQnvQ6ZDAdMvHuqC7ge/UrQo+eTXZt9XZS5bACw63uwz+f2PV/XwH1P
NCY3Pnbf843c95w1+556gr6C68KxQOtCKkBNQvx6djyOecrm6D9P1a2E93eBeDcFqI0Qv1/7PsQe
xgLYDRzsW5E7n50A2PbKVorsfU9Z5Hr17toMhok7/wzjIv4hRMRpwI8Nw+5QfwR9RHeoQ0nE9vXq
WlFaAA7RuGmsQxGbmz9J78qzKjdv/1+Zm5e5eZmbl7l5mZuXuXkkc/MyNy9NmjRp0qSdKQMqkgZO
2VSNgZnzckaNKbVP0eSkX45jZc4TGVT37D6Ey5yfEng4j3g4hWNlzhN8PZzHaVb/Dq2t12a8sZrV
z4E0qxSASjUrqCCfroEKci0Qk0hB/kUqyGeNglxH0Ffwrv410F2dDFBFSuxvIXRJU8AYKrG/C5TY
wWQu+b3alVidYeLOP4O5iP8IEXE68EO1Z6jE/ilQYvNIxH9WoxLbnOHgxprHzbWKiULOtecAb7YO
za4XquMBrheDSMT2df/1QgGoCZ4YBnExaKFjUIG32ojvNR3EQHstl8RgX6+uXmsCOCRFPtOIczk+
hoDPQMLHiMGnqnnZxoBPIw+fgVxe1nL4wLxsfozezQDYtTzY+Vzv1g7du82AN/p0Opw3E5g7NL55
sxETA5vjSKS8ZY5D5jhkjkPmOGSOQ+Y4ZI5D5jikSZMmTZo0adSAztkKnKxV52RdjNzzeh3nZH0t
Oa/bNfvCmlYCRxUBGyP6SkLvCb4l8KMgV/mkKktdgaqREyOL0prh7aoaORWaA1VM6jnY3Ql2Qwd7
gLCGPZNh6aIO4FqmQdwts+eOWC3TBvikPQA1mYZxaDJ2SP6aTBLwQNseajJJgTSZhgJUqFM1EvRo
f1QWuS5q+44Az9uj/bk2SY6nTZi70su+rYA9VP1SBKpfP8I+JYbqB5/0EamQ7JM+HQCHaGvSiPtx
fdQkUB91Bh5EUTYVRNmXRNk0RpRVfYqoE+Dg1R/7ctmAVIdPrHdX+vVoF+BHFGszQaznklibxYi1
xImlxCfWEibWLMDBjHymsZ4b4WP/QXqqWaY5fE4SPgeRq1n+Jc3WLN+s62qWhcjWLNsjqlnSO9z2
/WqkbahCGZ1p7Fb+CLRQMvnvBPndO9RiciJ8BT2qZih3qKXKKmJHUK6qq0hrrfVS55r3G+Nq1a6V
m1CS9GbdLcm31dFTJybOb2LpY5rqaq9UhDY1K1Ey0koIxxJlatoW8llXG6BG0bzdY0qGrz1qN3e0
jXAkTv/5Lj2OsW1HTqM1EXsntBd4sMcSvROaC9aDPuROaF5xJ1CkdgApWg1A+7MPt8q0EKD2Fs50
FwLUZh7U3hHUfOS2RkuCWgpmUb41/vRgj2Gw2dZtFXo1GVqJh0yHcXAPQyrx0Dq0h9ECD3DtaiNY
u3qRO6SNz9o1CeBF9xC0R3tFsGHlQlsHuyZVLhRGvuHGZ8cEKxfagZhk5cIZMNBXEwV9BXcS7QPt
JKYA1FaIHzEdBCOmJxkxHXxGzASAF32jBB0xPbnx3jH0nFUEvLVF/N4gS7A36FHNVRFTAYfozo9G
3CPCZw3g0wW05lCHT/dqy35fBJgM8TDpzmVWu9K2l5lVmVmVmVWZWZWZVZlZlZlVmVmVJk2aNGnS
pFEDOsx8cMq2VQuqatAzfjdGhym1r6GyyHX/vOdCgBrNYdGzezdON8mJQzeJXc19KfCWgngtaWAg
LekyASpUP3IF6kfnuLJu8bxfbwHwHn0OgLZgZ47JIAGTrGrLjC0CTFI8TLI4fS1PoK+dE6Pqfy7A
HunBPoe7TwbHoafHvk8uYbyx7IcI2Hck9/oQH3VwFsBr42HfkcuQDK1ihmQmg822xrDQauNk4IFq
pdBDfuj8xWzgIUPg4fzQMcwTeIAj/4JAI/9igJqM3PuEotp/yTa3duz8r5312yF4GmwGwE5F/Kwy
QjCWu/iO5R7OWO3hM5Z7MGN5DvAefUqL3rFduAzQyBqYASqOfMOdNdkM0CiZATprMkDTBX0Fx+7o
QGN3GkClqzac48cI5vhOZI4f4zPHlwK86FOUdMR04kbMhTVwxFwd+YYbHztiCuSIOWtGzFWCvoIj
ZmygEbNagApHzDjBiMkmI2acz4hZAvC8+8VsbgcwPvQOYJWA/Y3IXU8ngDahOdOu1ZwzXQw4eCPu
yvGZKODTgbSmfb26MqdrAJ92Hj4duMxpIe0BmTmVmVOZOZWZU5k5lZlTmTmVmVNp0qRJkyZNGjWg
xtwITtlUaYSZ00mMGkO+iNqTk/4kM1bmtIxBdc/u7Tn1ZHIc6knsjNitghigojQlkKJ0iwAV5jim
CnIc7aotc7qO8e62YDuOSZGASdtqy5ze7MukLaeyTROobG1iZE7X+mK34e6T6WbYzOlNjDeWfbGA
fWtyLxf7aIQ3+LJvzWVOZ5hVy5xeL+AKW2NmaM1xBfCQLvAwK472ju3hGuChhcDDRaFjuA54EI38
2YFG/uUAtR3i1dg5AvUzk9wnc2Kon1XNcV4LOORHPtN7K5PL2Mx1+NSkjM2VkW/4Z2zmgZhkxuYM
GOirlYK+gqNsfqBRdoUAFdYnXOKgxqpPyPnMrk/QEIu9HGCLah8WhMBeVgn2QmfeDIJdUgn2pQQ7
txJsv5qNpQLs9shd/RY5bUJ//z/A79M3/sIV7TJmtaxsRfuLAA8+Kb7YwYPPdLcis+riilmVIt0N
kKJvc6VzYyuO5ZIqsryLwWZZLhWwbElYLuVY3gmQmnhYtqxgSVFL6GxHUBMd1AwG7w6A5337cQYX
9bIqRn07g83yWy7g14Lht96XXwuO34oq8vvPSvhdLuDXnOF3G8Dwvim7OTcWrmDGwj3guw0F/lcK
/Kcz/v8KMLztk861z5VVbJ//ZrBZfqsE/NIYfvf58kvj+K2uIr//qoTfVQJ+zRh+9/ryaxbBy0Nu
/13t4CURPOzgpVYgbQBI3ndCpHJIpQIkd079G0Bq5UFqwiFdI0BqWoF0P0BK9yA15dbbBytdb+kb
3GEfPAA80HfWw1PkQ6BP6Smyke9+9i1nv/qWz372LWY/+z+Mdze+Rlx8GwPF93fGAxvfJkF8DX3j
g6dk0VvF2VPyQ4x3N76GXHwPO6t41eLbyHhgV6bNgpUpiaxMm7mV6UFfrkkVOw56125jRrqNmkJQ
7euiM/G/ALb3PUspEWx4bnmbjvoadG55IfIN70oAzy3vgJjkueUMGOir5wV9Bcfh9krnGdG55TkB
KhwxOwQjJpmMmB0+I+Z/GTx3xCRHsGGd0y4HW9Y5yTonWeck65xknZOsc5J1TrLOSZo0adKkSZNW
YUAL+CdzyrZP1rDO6X1GCyiN/E5Z5Lp/ndOzDKp7dq9X4YGqDbvp2R0FrV95RhAD1DP2BNIznhag
TkaunvGhoGXqkJb5kNEzvJU9TzGobsvU4VrmIxOFrOx5UhAD1GT2CjSZRBLDXh9N5glf9olcLmSf
wz7eXMjjAq6wNT6O4z6xA/BvjX9U4mF/HO0d28NjlXg4EDqGRwUeoHb8WQ3Ujh8BMdEsGNSOD0rt
+KzRjjcL+grOtYcCzbUPC1BhfcdhBzVI7cimSrCPOKM+CPZbABtWRdD59UuHN8w91RfOrC8DpD6R
z3Rmrc/NIl+FnkVeAt6SEN+LXwfqxTcBqqhy6ZsQvfgKwO4jwD4Wohe3AuwMxM/a34Zu7xeBB1F7
Hw/U3m8IeMM2+S5Ee78OsGFNMMX+PgT2qwA7FfEZ6RNgV0Iz0g18M9JHnefjj/o8P3+UeX5+C/De
OvKZjrQGHJMfBEwax8VElBtnmbwGmHjrtRpX7KYokx/pGojcSpC6zK77/wDeeA9eXS6yk4LIEnwj
q2qV7nbAxFsBnsAx+UnApLYvE/o8QAsfJi0YJu8AJt43vNTm7unyEPf028BPI8Tf06cEUdaqtii3
Ae+pkc80ylrcnj8t0WVC9/xTyJ7fvi5amT7zxZ7C7T7THeyatPv8NPIN72wEd5/NQUxy93kGDPTV
J4K+gutoC6evqraOHhCgwhGTIRgxk8mIyfAZMfsZPHfETI5gw8qFlg62rFyQlQuyckFWLsjKBVm5
ICsXZOWCNGnSpEmTJq3CgBbwJThlpyG+cqEVowWQL6JJ5NTeKjFW5cJxgNoy8pme3SdxeYFMenYP
nJ8/BrxlIl7PaB1IzzgBUNsivnKhjaBlCu2/LMzoGd7KhaMANS3ymbZMIdcybRPDVi58BbyJ/jpy
O4EmY5EY2vloMkcAXicPe6tCa6fs2ydWrXLhMMAWvTGkQxz3iR2Af2u8DzzAe5166BhHe8f2sLOS
GDqFjuEQ8NAC8ZUL59RA7fhjEBPtF6gdZ0nt+KzRjvcJ+grOtZ0DzbV7fVDpPJXtoMIKAFM4Q33E
ILkzlMmNxm6hR+OHPryph+6BWuMDASrk3Ss07z2V8O4diPduASrM3vUFqw3N3uFqy0jvAN69+QLM
MeknYGJUW0b6oC8To6KlKZP+gjtbJyuwfd27p/oaoHrvbD2CeiNAHQD6b4SDqhHUARWo4bPT3wI+
LT18NK69cwTtrVZb3vY7wKSzh4nKZacHOkyCZKe/B37ojhC2eq6g1RXS6rkxWr2qsX4DOGRFPtNY
FS4rNojOEzIrJrNiMisms2IyKyazYjIrJrNi0qRJkyZNmjRqQOX8HJyy4dNO9KSfJ8ibTI2RD/sC
4HnfiTeVUygGh1Ao3gV+aP08xD7PyXAEwd4FsOFTsBR7SAjs9wC26Hm4oZXqkaJ3Gv4IUEV/Y2GY
QJUa4avUVPWdlD8A794+H8HFlx8ovpOMBza+8wXxTfONr6rvpCwH3r1PMU/j4ruAMMmtcnyngIcc
5N4VNL7hAu20CJVFrnvH308AKcnDtYjLiY4QjO35BNW+Lso4YMXF9qq987ns3EgHuyZl5wwmPjY7
NwrEJLNzZ8BAX+kK31dwHI4OlNfRBKhwxIwRjJh59t8L9xkxKoPnjph5nIZ9odSwpYYtNWypYUsN
W2rYUsOWGrY0adKkSZMmjTWgBdRR3FM2fY8UfLKjgNECyBfRXHJqL0iM9WRHfYBq/30h9+w+l6tT
HUvP7jHqVGM/v9AEeBPpGeMC6RmNAGoTxD/ZMV7QMnNIy4xn9Azvkx31fFtmDtcyExytPHjLNADe
6JMGUJOZKNBkLiYxTPTRZGoDPO9frbo4gp0P2Bc67ON9sqMWwM5GfD3zpDjuEzsA/9ZQBPcJ9DA5
jvaO7cFi2of1MCV0DHUFHqB2PLUGaseIGROsdlwkteOzRjuOJne8fQXn2mmB5to/fFDpPDVdkMOZ
LZyhfmeQ3BlqNjcai0OPxt98eFMPMwK1xq8CVMh7Zmjev1TCe1Yg3qcFqDDTOBusNjTTOMs301jV
5yl+Zry7PT+rYm2iTC6mMwpy3/A3k9nDJCsunvdtdjO5yOYIIpvhG1lVn6FoCJh4I5vBMZkrYFLs
y6SqzxUk+TIprthb0HtonsMkSKY/BfihqxzM98yX+R6Z75H5Hpnvkfkeme+R+R6Z75EmTZo0adKk
sQb0u0TFPVlnIP6ZhUsEGYHpMTI9CQDPq5JM5xSBBSEUARP4ge+ootiXOtp9EOx/IxdbVLm6SNAm
K1BZ5LpIg2wJuCZHsGmbrOD0+stqoF6fwcTH6vWLpV5/1uj1LRS+r6DSuySQ0ttFgApHzFLBiFlO
RsxSnxHTnMFzR8xyTvsrkdqf1P6k9ie1P6n9Se1Pan9S+5MmTZo0adKksQa0gHMV95RN33QBa72X
MVpAqX2NnNqXJcaq9e7JoLpn92Vc5dryOCrXYlc09wPeRLXeKwLpGb0AKtUzYK335YKWKSEtczmj
Z3hrvXszqG7LlHAtc0Vi5bXHsVumB/BGq++gJrNSoMksJTGs9NFkujN4LvulFfV0lP2VDvt4a727
AWxRnfSq0BWOnX16lHpYHUd7x/aQ6TOaqIerQseQLWglqB1fXQO143RBv0DtuFRqx2eNdpym8H0F
59prAs21WQCVjhtY673GQYW13kuEM1Qzhp87Qy3hRuO1oUdjaiWtcV2g1jhH0BqQ9/WheXfyaW/q
4YZAvFsJWgPWIa8Fqw2tQ14cV613PG/xb+rb84s5JjcKmFxWbVXnHZnWdZlcxjEpEzC5tNqqxAf4
tsmlHJN1AiYLq61KvL8vk4Vc3vZmh0mQvG0O8CN63uCW/2fvuuOrqrb0vvUkkEZCSSCBkEYoCUgR
HhJp0kmkCIgURaqASQjF0MGOGkQEFEZG5v0QEKlKkQdBpCkCgoABhARBRFroIpaQ+VbWvuveB+e8
+c0w88/8EviyT8531tprr73WPvuUe7dJK0f+r7WyuWXPj7zvmdXM0mdWpc+sSp9ZlT6zKn1mVfrM
qvSZVekzq1KUohSlKEUpSnEvfO5BNrF5r7J93zT1XOO/bfJUY8S/eFrV1EffP1+1j7jv3sSsB7g3
UfOeeu7V/Y5+/vA/0Z34X+ie/QC661n426P73QfwSQ0f3Wbv8M95ALsTfHR7vuXeV/e8B7A73kd3
uInu9x7A7jgTu+nJmie+53uehyjvN1UMuiemK/jooGO8MT2oRF8r5b27XmJakPdur8c+VWIZaXU6
/LHd3EF3nzxaaSsBSHIjQoAGQEOgEdAYaAL8DXgEaAakAI8CzYEWQEugFdAaaAO0BdoB7YEOQEeg
E9AZSAUeB7oAXYFuQHegN9AH6Av0B54BBgCDgaHAMGA4MAJIBzKALGA0MBbYi1bvBw4C3wGHgCPA
90AecBQ4DvwAnABOAvlAAXAK+BE4DZwBfgLOAueAX4DzwAXgInAJuAwUAleAq8B14BbwK/AH8CdQ
BNwlXRHQBfwMnAPOAxeAS8AV4CpwDbgO3ABuAreA28BvwB3gD+AuUEy3QSsrZQccgAtwA36APzAy
UqnngQwgExgFZAGjgTHAWGAc8AKQDYwHJgATgUnAFGAqMA14EXgJeBl4BXgVeB14A3gLmAm8DcwC
hiIthgHPAcOBEcBI4HkgHcgAMoHweKUigMpAFSASiAKMmrAfKAs8nazUYeAIkAccBY4DjvpKOQEX
4AYMwA/wB8oAZYEAIBAIAoKBEKAcEAqEAeWBCkBFIByoDFQBIoGqQDUgGqgOxACxQBwQDyQASUAy
UBeoByxtotTHwHLgE2AFsBJYBawG1gBrgU+Bz4B1wHpgA7AR+BzYBPwD2AxsBb4AtgHbgR3ATmAX
8BWwB9gL7AP2A98CB4HvgEPA0ebIsxbIMyANeBzoCixurdRHwBJgKbAM+BhYDnwCrABWAquA1cAa
YC3wKfAZsB7YAHwObAI2A1uAXGAr8AXwJbAd2AXsBr4C9gDfAHuBfVRHG9QBrAbWAGuBT4HPgHXA
emAD8DmwCfgHsBnYAuQCW4EvgG3Al8B2YAewE9gFfA3sAb4B9gL7gW+BA8BB4DBwBMgDjgLHgB+A
E0BvDPmHXLBR0QrNiMs4LseUjLR2A6MexulXsb0wEC20E0PjpsPgPUh1lR+M8cTukbmJUelHDNjL
sB1RgUcyZoqIqcDfqHQQOf0xZNa1IG3XwORgID+h+B2GN4WJRD398FcGtn/F0P5wsEfbX5DZVp7X
6CBtVDJzFUw+8Au2k4K4ZOZ37O0JLduwXbEaslxkfqOxGba9i+3ocC6Zue3mPfWwHYKs/9Hm8cGv
YGYFsbZFYch18c4fNKqjnjepBahns2gr1C0lmcBALpm5CGaPjfe8AU3XhLkAhp6G0KozL4PZJFaf
B7PQSc9mWGukWBAGv60ozx6lspO/RyYUTN+KzFDpZcqCecvGTDMH/82MC1uFUczkRmOkt3n6509Y
0APTtWbYnhvBJcvcAfN2CO95OsyXcRr8vY301kcgrJ8kvX0FMvtQ83Rsd/bjkmUukd+KiotJy/5i
LpkpQy2Fhr9huy+0HXd5mOtaWy+trZfI3AVTHMzziqthXDJTfA+zRVp6w836K2htu4TxgwXPGxwz
+5EthyUXAg3e86HibPlCei5A5w+qUnlQuU+sDgaTj3j7BNsrMaGc6PAwQWByg+itCmQJZNqJtnIG
79moWHajtKcimJxy6GXFZRXRVtXg2CGvRCEGXpC4jtL9Q3kz2eGbP5UM3kNtJ5mxDo8Pyhs8DtC6
TCnw2w6HR1sEmKsO/kxtMfy2WXrbpuuZCBTaueR6qhgcGeRRypLWIhOuZRxaxiEylTXzoWY+FOYn
N48qCYptHCL987Ob92zHdlQorjHEOwfc7K+O2N6NuDZkFDtBDGYd9O7OZOR4pxLbiPnGzXEwGdv9
ymLsEeYwmP0YO84pzp95kqc/kAz0L9XalorVe8DkIipmKPbBDGG2ubkX6G0Fqu+QaDsOZkc0r/7l
iOWSZY66ec+z2N4Ry1cWzBwD4xfLK6rviaVVoTzMITf3JcmkIqpCpZ48MEURrJ/a5a3ne8000kwj
YQ5qX5M28vWzwuwCUwh/nUZe0xG3JBK/0h6lY+kIr8wOMB8r3jMch84WZjuYxSjfAwaB6SMt3enm
N+jI2nSHr9WxqOMkYnMhtiNRT47Tw8QY/H2IxExy+TInaXSpwLGzJYJLZgrANAvgNzkvB3LJzNd6
RIKbS8aQWGH2unkUo29zHenPJTO/gEmtTu878Nl5ps0TVefI13eLi4mhiK8q8Zavo4ps6oekyBJm
H8mgTXsVe3SiMHHaB+TVSRhlxksuVDc42+n7aymPbMJUs2RO6xil+QEdsVWsPuXmPP13bTWVLHNG
yyxXfDZ7Smz7UcvQfQ6SaSreqWlwS6Od3NIGbk/s1DC4Lf/h5Aj5TnouweAIyXNyhCyQsTdej2+p
To67IpdHWzs9WuY7uT37/TwyiQZHVVUnR1VVqSfJ4PkHvRtGEZ8v7allsP5uiq3vKT543OB20EhB
vX5OGHp7ohv24L8Ki8EMV5hUg48lLYEx/E4XM50MPv9sUjwiHRemre65UU7uuZaGh2ljypAP6ur2
xCtuz/fSp+0NPpbmOXTOmiw+6KhbWltxS2uL1Z0NjsQGyHrS+pPyaGtl8Gyjj+J2/ZuM1x10PTRW
0ehcVph6Bu+htfJovP5T+rS1wSMSfR8CaX1NfNBC9/Zu3afj3B4L6hs88pFHaeRzy8j3qMGR2MrJ
kdhKWtpSa0tzcvTedXm0NdcyBVqmQGR6ao8m2NmjeQ6PzBMG++u6nePBKZGYTgzmVafAFKEslpwj
P+dWYoZkM4QZqXuB9tARXmaEwaNFiYzhyzxrcMR/a2fvPC0RMlhrO2fjes6JR4cbbG2YnXsuTPrn
OYOjN83G0TtFZIYZfOxLNo7ediLTQ9czVdfzksh0Nzjngu2cc8Ei083grCf9lPWrRKarwVn/mY2z
/gWR6aJ7jt56o/p+kN4eqOONvgGb4vqM9Fwvg71fCKawPDzl8MxQhho876M1MVMw+mfbPMwgrS3P
zrG6TrQNMNjHG2x8xKvCPGPKkLb+Bsez08H+e0wi/kmD9f9i51xYLGMV9SHlwjY7y3aR3u5tcMTT
+18U8VfFB321d5bqOOjl9MRoP80MtHPEhwnTx+CIv2nniL8pvn5KM61tzLSW/sk22MevYM9CXDM1
EtsyDLrLyNc/SdGYLwjzAmmrwgyVXmYcaQtlbcR4tY01ONdKZEJ9ZcYYPCcvkQn1lRmtI5EYGkeZ
Ie9kGTw7I21UerWNMvjKlWTo7p9XJtPgnCMZKr0y4w32Cp1P+yGqRonfphg89/9ScT+dFr9NNngM
IRkqvTKTdOx8qW3zykw0uMdIhkqvzATdpyRDLfbKTNW20WyDImSVyEzXzGrlGzv0Mw3MbfxF37Df
E0xHaekSg71Cb/MVIevXyMj3EbXHxe8QUxzUEQuWao/SHiojJeKXG/zJhfOKx4b3JXqXUUuRiU8q
Hs04G0nmY10PjQlUD5Ws7QzFG9CY6oN3vjI8zGmyuirfjU2J4ZKZH8G0wp4lLp5n54ltpww+9oSL
W/qhyJykqEK/3EFeTw7l+7XMnNAMnQUWYhZ9NMDD/EDtcfEcJhBn9o1lPcxxvedYWZZdJtqOmTLk
naPUc5W55ny0a4jcXckzeE9CIFvPDMkcIW3Y+Bnxme/gkmUOa6ZRGDNUMnOIfI3jOkBLCsaf30M8
2r4zuO3+qGcDLNkd6pGhHuiHPT1c7PNhhkdmn8FzXbo/3t/JJcvsBTPfxt6n2aNbmG/AzAFTFnue
sPP1HTN7yNfQ8qKLe7u+1HPN0GOvnceFITK+XQYzinoMh3WtzCVrOw+mqx/vmR7ky5wDMxJ7FmBP
31DfXLhIsQMZG+o5E8glM1cNHsXoPErX9d7z6Q0wyyCTgj2fQ6afaLuurc5SbPVsifgrBo9rg22s
9VexrVC3Z7fi9lDJzCWDbSKZrCBfmQu6pbmKW5orMmcNtpauvKgHY8Tq22B2Ovk+yiBEZIDMuH41
+F3vcXa+8h8nMrfArMeeV7CnB2QaSS/cNDinzyqe5c6xe5imARzx26ExB7ZlyehSC8x+xGU2js3B
ieiWxAGtPU53YQaD+cCP7w0wQ6t707XSWRufobwytKY4+XqMnWcDXqYm5TT+6mjn2dogYRqDGQAL
dkNbyypcMvOwZs4oZqhkpgHNw1FPLo4dFcwlM/U1Q8cS45V5CExf7FmC7c40lxWPJoNJwYj3NrQk
xXLJTBKY+tjzDbZvxvI36jNTJ4CPpZfFC1HuEJloMKmwdrxirW/J2FsNTBA8/yb+SHNxyTJVwcyw
s/6OeubFTFQA3+Ok72J6DMxNYSLB9HNxe1L9Pe2heh7RvZ2le3u2xEFt3dt0zRxY0feclRjA/UJn
MzriUcmflgF834VkbgfyNRQzNbTMBFxzk0xHm8eCVgF65mjjM+0boq06MTj2MLaXwEuzJA7iybZq
fJ+cPHte2pMAJh/HrsN5i454THlk6K4C3SXaju0cyJwRC1qAWQar70BLe8TqMqdn1hkbwLOni4qz
5aJoSwngcwnFdS5k5jg8MjEU1xWQ10W4NkMGPwRL9PUPmI0uXtemF2Q2ia+b63om2rieidJzcZqp
qC2oKBbQKvTmswBa9b4Z6lkGuRXVuGQZWi/efBZAa5/TfIruU1EvbJcZF60Gbz4LoNXZaRZAPzQL
UGIbffceZX2inc/B3nMJrfhQVEbPyYN5Ps/aaIWJruUx38GehyK5ZJlnNUP33Yjx3n+j1TQeKsOj
/oAQ39H/Gc3QscR4ZWjlkM4h3JfNoHWByNBKJUnRiDccS3eLDosMrTcTE8dr7fwUx58zYYZW16Fj
aS6ej9IQbb11XM/Enn64olgmPqD1rVMiedSn+g5K9NI623fh+QM2flp+QOqh1dLprhLV3BS9kC4M
rQ0/xkGfJFGqIZjGYkFnHSHUUnoStUDqoe9d3AJmvdJX75JztOIRzZ6/Vpwt8+RqilZvonH6RRsf
0U2YXqYM1TNCRxVZTVdgV8Q2Wq+BRgo6ikaKrRKJtHI3XRWuBZUQxdfszPTRtq3CdhESob/4gFbY
onvDTXTPZUv00qpkNHrdUnwts1h8QGtp0V1WnGxLZGksYW1DtdU0C6BciJEYpbU05oLZQzM06hG5
T0EritE8/q6d23VXWjpfa0tWnBMFYvUQzdCdGGJqSy/QShlRDr6rWejikpnuup66yEiqp27J6EI/
9Pk6yqyGOrPOitX0SUfKhfY6S9qLNvpkJeVCgJ1zYYtYME1HfD07R/wzIjNVRzyd6ynia4rMaB3X
p2wc1zekF0bp6CUtFL2zRFumjt65do7e3qItQ0cv2UbRu0W00ecTaTyo4+DxoI7ITNYRctHG0Zsp
UfWeZqbZ2MZFYgG9B3QJZ5kjYCbiiEHC0NtHdMVKMnTu8srQO08XkDcrwczHEfuFobe46HxK93UK
kfVDJOvp3THKuaNg3qJ7AcK8rnuO5mLUc07puVd0S59Q3FIqWeZl3ad0rqc+rStRRZ/BJe/bdC54
74bTZ+hpRKLncjQiea+z6DsfadwpUjzuFEk99OZYPtDTxiO5tz1TtEffV3xfLFHqoc/+03hADB0x
TPpngilDfUrfdkDZ+IGDs7GOjC70XRMLK7J3aAY5RzKYvtmBcmGBH+fcArlXQ9/C4Mlp8oF3fkCf
u1uJNixA3tC7Or3EB2N0e6r9WVw8D5acFB/QG4V0ddMKc5cijAc3JOfGaQto3CELmogP6POUNFL8
ZueRYqnMvOkznzS7JY+uxLZbztv0yUfK+sU66xdLVNHnFhe7Oa5p3rxAZJYo/mkFdAYu41f7VEQ0
cBnogZB5CjCUE6B/9pLf9JMIpPrIdAZy/qVsZZEvLoarVCXVXvVQ7fC7jequooHHVVtEaS/VUnXD
PtrTG3gC26koK6vWqqnqq0bjX2P1tBqnMtRzKhN7MtUANVCNUIPR4iTNJ6tB4Af+t2upo2vppTqo
NPx7Atst1VhozsDxg6ExAzUPxvg+HrKjUTP9FY29Q/Db3JIBKAeVWvL/ypLSaCy15P/Okr/UVJwn
xqWkdSoOvvefTU0Dd+29uB5m3HRwfv5lZptxL4LbsPrlFWbcS6SzTdByM+51cCeH78tvqe7nZoDr
XNvd3EwOJ8PikN0r1hYH25UD5wEvhxlDsf4xkeuqGqp502cNpeP++cemMtsuVAFD7vzNjNvRLhIT
Fn8/M27euJ42l/J3mnHJfY/YAi24rcYwe3AJd7+dawa9aPe3kMuO+8huZcuuDpUcZS3kmgQ+7ihY
fecNM65cg40kZ6rz9xHXHVb1JWW847zx7pUkszakjHnfaSWX1tfusmr7+ZBJrvQjcR3NOFu77m4r
Oz+tf8Ld8PuCJ824w3XGGDaL+tKfzTGsdLbo9Zhfwap1hWZcfmofPyu54Y2v+Fm1PTkzq4xzeP+v
zbi2gfvL2Cz675U6x8qM2dtlrhkX7r870Kp9c4OfCbay8/sOnwRbya2tHR5iJbcmKiZkW3DPifdK
0fP9uVMOhHDb79c59JGG5azq61z3EUsup8n7ltzQLmfKZUWETDDj4irMDS1n4c9dGXdCq66p1900
XtqEh1n1X9t+ncKscnpdz8ywRV0nhJtx6SN2hln17QetD4ZZ5e2k5ITyVv7MmPhwhWAL7krYOxWs
5Hq2uVzBqm+ndW9R8Y2BtZJNYz4to2Lcyb/3MeN+G/1+Ras2zEyfUinx2OX+be4b55X6KP3LSmmv
FcwwkzvQolZ428jbCfe3QakR6XnhVm2Ym/R7eNYncetN7aw5O+LJtotrmXG5ESsi/l445IiZz8q6
NkQceu3b9mbc9Piqla1seXV8buVFN+IWmXFNmo+sYhUT5R7aX8VK5ztN/qoyYX6ZbDNuRPjuSKtc
ec4eHGUV19nOp6Os5NxDs6Ks8uiz8DnR9dLjLplxVe17oq1y7HTnctV3/lXrohn3S1ZsdSs7GzVt
GmN1vp1dc1ysldzmzImxVuec+EabYq18vah76zgrnT9P6RGnaseYzhlWDegVN+7b6PlmXGil5+Os
fD2t/YW4YKs+ij8eb9X27NoX463ad93xe7xVfc0S/RLObLiWY6ZzZUZiDasxZFq75jWs6psd+FqN
M38kfH0/p1RkSnri8sjIP7vcWx3qK0hbl2jl69opvyVateHUyJY1rXz2c+aRmm+VT5xnxh3ps6r2
U0PPhphxz9cpqG0VE5P6FiQFvTzsUTNbZpZpl2zVR61qpCVb5fuS7APJVm3vYX+urpXca82y68at
mHnajAsYPLXuzmpbxppxMwbOqLuo2cHFZm04OjqngZUtLcYXNLDq9/UPhzcM/0/2rgS8iiLd1l1y
cwkhJBg2YTCgIhKJAQKEgJCNJEAgkIWE3UCAJGQjRCBsgkRBXEBcwGXGoLg8F0DUARlGMjMOoKIP
BZfxzVNGfcoo+kVF5+kgzPm7+iZ/39sVskBCSCrfSd1zq/+q6qrq7qruvv8JyI03s9uQFhqmGkuf
+I8OU/XtyzMXhSW3OVZhlpYx4vQgVT23rAgPV+X5Ubvp4ar+2+v3h3Dnw3N7m+U5dsw7Q1V5Riz/
KOL4/RF9zOz+3u/TCNVYejO97TBVngsXdB2m6vdcvw3DTtk2lpmlbV34zjDVHDpLBA5XtdkHvZ9V
prWLf/AGZVt3emakKu2TOQOiVPt389yz0Sq7z+J7x6jS4lLSlGnBQe/GqMp7faEtVpW2J2KuMi0/
Oj9W1X85V/w0qiD7i1yztI3t34xrr+i/37bvE6/ah3F+r8arjpV7c/8Zr5pnZUStTkic/b2XWVpY
dOfRiS8s32qWdte8r0ar6rm91DGmcuPKHLO0F6+PG6Manz+H909U7V/0/IcSVXOGT6c+PF7V1tf7
PJSk6qPDUQeTVHbfzSqeEB7aa6ZZmq3Id6Iqz38kTZ04446XxprZLRDhyar9G+x9e7Iqz25TvFNV
bdZt0KRU1XpzfdbMNFWe5e0eV6Y9lfFE2spoZzezPPsGvp0m/I//4mknxF0jv0x7abN93mx3M9gt
KvGZVP66mBhhct9m6+DNk1TXv+Scq9NV43qBtThd1Z7fjd2QrjpfXznqyXTV3DQ+onOGav5ZNGNW
hqouT02JnSzHp2fajvxNk7vkHnraLM8rlgdPUR2bT2TtnKLq244Dw6aq+u/j+THKtPuWTJ+uSstM
ODJdte9P54+boTreN1syZ6jyPGj984wTOQP2m9kNGfHzDNW4DvAPnalaM99289GZqn5ftfSZzN/t
336NWVpOye7MERMrvjRLS7j521mqvvWd6DdbVd6mmz5Spr3WOThL1S6vXJue1ff9n94zSxu5dGWW
Ks/nFz2qzDNiwi9zVXbLhv1rnmoOtkW8na3a90HR32Wr8kwZHpyrSpvVfW6uqm932FblqsZ8/OL1
uap6Ppx03fxNpXNN7zNMm3VsvqpdhpbG5anSvi+ckv9TavlqszyDr16Rr7KLLbihQFXPYRHvFqjs
bkuMLZy1633Ta2PqkKVFKrvZqceUaUen+SxQHZt3Lr56geoa931y1gJVnrde+aMybcnlPYtV/e7X
KaxYdS7f3D5rocruA/HAQtW57iXf+SXrvgrcbZaW3q20RLV/9/X7tkR1Lyiu+PObtszbFWhmd2vP
4EVFa/cNN0sbF7tm0ZNbrjtolvbC9b0Xq8Z8/PzJi0f8cCLErC4Tc39YrGqXuZZvlqjSMib7lKrK
2zt+eKlq3+9JjCxV9e304idKlfdwHcOWbh+xd4NZ2srsN5aqjocH5iQuU42JjVPKlqn27/3hf1km
13GeaaFBB5R5Hhufu1yVpwhfvVy17yXLPlquas+R7cNWqNK6jp+6ImPg+iFj3JOQVrFo/QpVeQsu
e3ylqp4Hh76sTLPosUfwF6J92RFrQNmWMx0PeAnLESv9aE2EaNt29txetNUsnN5VFk5vRxLm5xOB
wj4w211Zs2m5V5VpuVfdTMPtVabh9rqZGnfRxFTdOtmWKtNsS61ax2hRp8KonqG/enaF0H4k6xac
QmhbyjdptC1d23rVsK2Xvm2IsFZv763e3pttHyJszKaN0qaNm02IsHO7tiq7tiZ2IcLLYNtOYdtO
YRsiHEZ7foAw+/Y12IcIb7c8AkzzCDhHHiGaqyp1wHKpoYOr9qZOmDql6VN1NG2aUpnp6Qt+1LLC
FjVJ63x4qZd6Pk3rPhJEpNEim6iTLHrbyKKBY6au7djkB+OHlTaFaXvN9BBMw6XpIYsjZoy/MJif
aG4DvRFbuWlML5JTiRBV04SqA468IQ1yWgY7RcyYPhhHNhjZyKiNiBHZIlMUiRLt1bOgKivP+U+o
Vn4kZkwVcsYUaXXITIc4xVCnGOYUw50iuq8lZkx3kdC3qpiUviLVKTK0Sp5r3tTTZFYmyxjqtOhZ
u/KtyrQ2E6wuWsY34kxTflrL+EabnrFbrsivthOwjlqelcjTX+ZZ6crTLcM6zc60TFdh6r3q31qm
q+x1n6Vpefhj5l/5i5aHv1f9ZmtaPrSCuFHmgxVEbWZtNvIaKkP1ENRO9aGOgLIjP5sOxbYiCsOw
CMOwQGSJHLEEg9EpIup4RWh2Zw2DqdzQeJ2kYNNMEzDSpknTBJtDM6k6Wj1MVBfja0WGtab6GY89
w/mlsknOaqeb34W9gaU26tq4pUy2ZJNWnZeqg2a6E6YTpOmHbRxmpyKhn4pM7wyYXBnPeYfA5Gir
1Z0CkwtZre8YmFywWtq1yfSOgn/1tUnLK9RRqzsL52ECX491lHIAdrFVDeIuNodduHag5iF4CN3p
1Ktpp59Ps92ueRBWoMGWyMFb4XA4hXuD1TwM9zgDyk7IYbjH6fDxsLYbczAZiDt9AsoyZA47fRy+
pjl4ueXiORSf9g0oOySH89O+Dj9lLg73nDwHox86XOZU7ufwrzEnb4/c3Ifjcf+qoX3c39HhnLk5
RV2vBZfAkjDSaBaEL9tqE811OLEeP9PCr3ctaZ1etzlwvVunsrLRps/N7nZxo05km90t1GbYsE9d
zMuRprubba3RQoiAMv0BVS3nbcziSG0XDsymto8YTezqtnAw2tZ94WC0r9/CwZhH/RcOxnwatnAw
5lWbhUMLOEgarZ4NOK963iCINO7ieX5G1ZIegTSgL5rgstOoF9TG70XVjQppesjCb1Q06CnjeT3f
XICDseb6nTkrcLK2euRFGx6/9dHvf07K9n/2HqcIvubFv4Xiu1VICNDTNwqpeU8Oh6i5twnKS4id
Qkr1kJszutweE1I+7YSQD+rIaTUt7gMt8u5kKGK6NA63SHmTBMR0mUu1SDf9NyKmyxW1BnZRFCG+
TEhneVT+5yi0h14XciPRQ7jGtvxMtsmZBbmZBZlBYzNzCkqyRfU2+J4+U/njC4vzM/NCsgpLRAF9
R87LEtLiE0alBKUkxaWmRyWPCkqZnJI6alyKZk/7GjZooPaZ6jMuZ3Zx4cLCuSVB6YXFWUHhIaEi
NZLK6DJ/5ouItM+fRlS+lfaqRfv80rZd+8P1z6f2Th37xn5tvkT1ojiorYzzR8r4QgRV/9M31vfe
eu+RkG7+925G/1/38/ZYfOfl9h0NWJKhoH6jeqNptfYuEnIM0BihG2w0RmjclAs5AMl5FLU5jRXq
0z1CtmGFkG4YaezQGDii5/2xMPa11jc3zcueszAoBS2+OLN4TlBK6cKSOfkLtbZaK/Q21OPPx8m4
f0encM3TVHEPf7kvcjz5+stPVCrtSWpOSd4c4eoncvZo1+366N8l67ZThCxzl84JNN5nThgdOzM+
bXSslurr+iYhcfT4sSlVexmFeLwg8ZlofB6K/wNEnAgT/UU/EYNPMWIUPvXHX6z2XTj+h2LLfvgf
KgYD0cBApMYBQ5C6Qqsl5Vuk74tNq3W0FncR1aOMYuo98jvZHcgXmSJH5GmOWyJwVBGnZ+i5QAHG
dbbmniUEcYEWk2OXfN2++ozWevyLi+7418NFOqNqrm+KNfplvNW01fTiPzxbwH22Jn/A9OEl2rDn
p3Ua8ECi5b0rfYkPovPwKkOzO2jUXcpeB9ppcViqtlTdwTc+9Wu0V3/C7fV/9afcq2Gv/ji9L55X
f4qcjf7qTzM71TflnefaLwDqco5tdu+xNk2pjfwrk4vgzN7AYdE6WTQfSHV9Dft8zy7UZxFZcsu8
jWA2Wm0mpjChBurXPBuo9Zi8ANeF1oZtHbGXYOs0/xvm9drXBk3wL9AUsb1JyR7mDX9np86DSb2O
b/0Fhfm6l+fS+guKi+rYbfCp2G1kCdfvmtk9MKe3o/XX462/HlccPOc4pBvy6/GqIBuL3aYrcpoP
SR/TX5E3y3lA64Wt9cLWvC9sF/Uv4S/05FmaGifPDbq32pJeJG+xppfBlhTUuNkaN36zG7/djf/b
jZOnbc5JKYHzM/r2zo7L6G3EKp7lxivcePdOkruX717fW9z4aje+yo278l+i50+eyXk6KXVw7t5e
pDbGOSkncE7KRZyTB3rOycMx56R2wDl5FuacPKtyTkponJO375rSSXWFc1Lj4Jw8SnPu3v+kGMU5
qUtxTupdnJNqB+fkXZpz8rTNOXl455xUqDgnRRnOSemAc/LKzjl52uWcvABzTip6nJNiFOfkOZdz
UjzjnBQhOCelHM7JEzXnpELDOXlu55y8U3NOqhKckxdxzsm7NOekwsQ5KZ8Z0oO/MtSP1C44J1UX
zklVzSz9mH68kGdonk5KLJyTh3nOyQMu5+SBl1NSn+KclBA4J+/ynJP6CeekZMA5ebXmnNQaOCdV
Ls7JszbnpPrEOSl8cU5KTJyTagznpKzHOSkJck5exTknZTzOXeen43p7k4IMTydFPM7JazjnLvvh
naU9qUDwdFJg5Jy8QXNOalKck1IS56QIxjkp/3BOqi+ck9dvzkmJhXPyJs45KXlxTl7mOSdlTc5J
NYRzUoXgnLzic04etTknVRXOSZmGc02xiwVS7eGcVJg4JwUQzsk7NOekqsk5qTtyToosnJP3c85J
HYBz8tDPOSnycE6qOJyTOhnnpLrJOSkZck5qC5yTt3LOSSWGc/Kszjmpl3BOnrQN27d7y7j/k30M
45EUjTgnBTzOyes656Tcwjmpb3BO6l6ck1oN56RiwjmpPnJOCnWck2oG567jb0tn43zmlBuf0MXI
n3Pjzq76/Ec//2Z1NaYXufHKXkaeeKWRl7vxUzonRSXBAqldcE5eyjkndVfOyVM556QWxTkptHFO
qjuck8d5zklZj3NSTeWc1Gw5J1UdzklZkXNSa+WcFAM4J4VYzkm5iXNSNeWcFD84J0UxzsmjPeek
nMk5KXtxTqqUnJOaEeekKsc5qbNyTsqxnJMKpIEP3G3oL1KE4Nw1HhKukuOBlPh4OqmmcE5e8jkn
pQ/OSQmHc1Ju4pzUHzknJRTOSYGHc/LmzzmpxnBOCsack9oV56SwwzmpjnJOSqqckzoJ56TIzDmp
uXJOSjWck9ok56RGxzmpGnBOijWck7op56SMYUjP2mnYH1Lm4ZwUiDkndRDOSTGKc1KZ5ZwUBzkn
xS7OSVmQc1LQ5FxTiGKBlKk5J4UQzkn9iXNSduCc1CMMfNEkQ3+QeiLnpHjJOampck5KqJyTGhvn
pPbKOanbck4KkJyTgi/npFLKOSkcck7qIpyT6ifnpMDIOak1ck6q4zyQijXnpDDDOal1ck7KbZyT
QhPnpHjOA6lIc04qIJyTwi/npGDHOakOck7qYpyTogrnpMTLOSn0cE4qQJyT+iLnpBbKOak9c07q
X5yTUi3npADN+dlzhMCOy5xBQt5LdPcYRq+RSY9hUrLC7XYMmRfVYB5UZU4PcjwcjpH54YaV3qdT
XczbwLwNNzcLZfXNcuQ5m7o5Bdp9mjece8v6h5O1amqp0WLS+TwkdD5vWV1qYVutmkZ5iIkuDTrA
p9VgXovS99TJ3OMAD+zaoIOZHwSv9WrQCDvdMPMMrHaCjsjN3c0p0JQ6ZsxVImmMD0x9pGmeZvrc
lbLkmk3pObEVplZp2itI6/uralNqqJlpU4dUqrrYdI72lk8bWtgJoXHCac/h0hpaSDgbaVllEbRs
JuzrN7QNvZbkWka7Hk9ZAoTtKluHrC44HC/bliUCty0R1n3W6o3IYDMWB1uAK3CuCQKux2IoFNjV
HUs7YOIAIZKBHzCJPgV8EyPEt8BpLIp+BeYik3lAPlAAFAKLgSWJtNTA8gRYB2wCHgRosf8Y8Dyw
HdgB7AReAF4BXgP+ChwADgJHgWPA18BJIH6cEAnAq8B+4DXga+AkkIqFaxqQDmQAk4FI+p1GpBa/
QfsdKfZpPEqM0HlqR8kjdZ7VW/JonZcNlzxW5+ujJI/T+aE8yRN07rtU8jE6FxslT9R5j/tkfe48
QDxK3K3H/odk3EGPAw/J7R86IONH9O326PFePd6nx0f0+GM9Pq7HlXrsOChjpx776LGvHvvpcQ89
Djsoyx2s83A9jtC/T9Z5qs4ry+lXMpEicKvcv/FvyPTDW+X+T3C1/2My/YAeJ+vfd3pc8i92yPiE
Hp/UY5k/vW4T32kjhrTV6rB52b2sNvtaqzCER/U4VeSIfDFHLBRBYjzixYiTNX845CtHiEHIxyq8
vCxWi7fDWvUuEb+dt4r+pYhS2MyCZR7YwN5a6W0ddisFZelRohjlZ0obrcZVweNFKVdiqhgtxolR
KFGIYVo5HUSg7wotXWWTgO0TxST8J+sYlCvESL2OPnarpXZ1DBLR+J8pZgtaPQ/pb6ivsuwYtMlN
Wh70BqYQQ/WesdttNovFaVOVG4+SioF82NOrcthbh9YXwi149EU6yioQ87TX6yime1+DetWutvHa
i3lzxCKULMQorUSLxWGRQd/Io8RxWh0LRQlGAb3aF4TeKUTtS7Sye2nvQ67rIsQRq/67MBHer39c
+I+j4jpOH3DbXy127BT5DyLfQRZYk7cim/9aVox8p9RVgZ4X2MFQSwkdQqkzu2qji+7Ykd+x2gfD
Ox5VQQ7ns2ddd4Bkf1Lww5mFzirSD1cmvh+reeoqwDjJFp1xlKZh/CVoxzaNoCQRh+M1HUdgMr6j
byYDqfg8Tjv6W0NLCyef+JNYINrYhRjuv19+Jc9F+Ob/02mEzcqdlVsSXGK4vSxDG3snIQ4L0SnK
ooFmStOE9APJQ45Dnh3PMt1g1WdXqH562S7cKnp3w9UsxapVLUaPd2TJ44LH/J71Uf37NbmeMT2L
PYoYFRZXzLdqHipd2/cutIuN+JiUbxVPgv+ImO4lty2Q6e5xz89spnFwnvSr2C9PPsmuTUz1//0C
uziF0/IzC+2C7kFPxPfvuV3RKLj221Wee3jwjzZRdrUQv0G6XXjWb6Je7v06T0mxGmLX/rkC8buT
LGJkHtrfUm3nHlP+YXo+Yb7V+QxDfZNZvsF5hif8VcHVD67YvV7uMW9vClSPXl7V9dl9wiY2Yfys
mWAXz+CUvHamVbyETe9C/r1E/YOrPNf+/DBfjqeKfWfnkCc/qv9Or+pxl4b6RCLul2sXZwwzh6YM
FuyEFbABdsALoJflvQGnXWhnBh+gLeALtAP8gPaAPxAAdAAuAwKBjkAnoDPQBegKXA50A7oDvwF6
AFcAQUBPoBdwJXAVcDXQG7gG6ANcC/QFgoHrgH5ACHA9EAr0BwYAA4EwYBAwGBgChANDgQhgGDAc
uAEYAYwEIoEoIBqIAWKBUUAcEA8kAKOBMcBYIBEYB4wHkgAMKDERSAZSgFQgDZgEpAMZwGRgCjAV
mAZMB2YAM4EbgUxgFjAbyALmAHOBeUA2kANgwIj5AA24fKAAwElKFAE4WYhiACcLUQLcBCwCFtvp
JTwhSoGlwDJgObACWAncDKwCVgO3AGuAMuBW4DZgLbAOuB1YD9wB3AncBdwNbAA2AvTa1ibgXuA+
4H7gAWAzQK/wPAg8BDwMPAL8Fvgd8ChQDmwFHgMeB7YBTwBPAk8BTwP/BTwDPAs8BzwPbAd2ADuB
F4BdwIsAHdUvA78HdgN7gFeAvcAfgH3AH4FXgf1ABfAn4M/AX4CDduOTkUPgrwNvAG8Ch4G3gLeB
/waOAO8A7wJHgWPAe8D7wAfAh8DfgI+A/wH+Dvwv8DHwCXAc+AfwKfCZXfox/T/gC+BL4ATwT+Ar
4GvgpF2+GPGtXc4Jf8VnQoVVfj6j85/07X60V2/DwQOtTGmVEYQ5IM0ai4XhvZdzhk7Cy+LKi863
jjbybFchk7WHrscPjvb/PPVVi+vM+C/Uq0JfdPXH7DMTq9w8rHHqE/zQEnx/zm0htLn5XjqgBK3s
aFWVJWIRz8aqMl9brRnexakxXC6sFtqVupT/DRV9WH72wrybSs3X1qalWEsXiLlaneibEszlC4Xh
zVq30AflU4tTlrUtn57M79SvQKvRabcAa4Ay4FbgNmAtsA64HVgP3AHcCdwF3A1sADYC9wCbgHuB
+4D7/9PefQBbUZ0BAL73PQhIFTtgAUGR3qsC0kGKiBoUpIsEaRaKdHvsGY2VXhQEFANYEAsqRcCu
iYh0VJAeAamS+P1vyUxiMgOjZjKZYWe+t/e9u/e9d3fPOXv2nP/fy+M8wZM8xShGM4axjGM8E5jI
JCYzlWeYwgqeZRrTmcFzPM/MzAiI8R6YxWzm8CIv8TIRXjSXV5nHa7yOTlHqTebzFm/zDgtYyCIW
8y5LWMoy3stM6tTPWb702pWsYjVrWMs61rOB6Kx8zTdsZBM6LqnNbGEr29jODnYSeTgR9raL3ezh
e/ayj/0c4CCH+IHD/I2syqrQVPjl9S8dQ1hRnOK9Hm37WJ60cZH+2Y6+4TEu/7yvj771r7/8P//9
2zQeEQp1B3dyF3cTY2j3cC/3cT8P8CAP8QfiKulhHuFxHuUxlvAET/IUoxjNGMYyjvFMYCKTmMzT
RBjlFKbyLNOYzgye43lm8gJ/YhazmcOLvMTLvMJc5mUk++c165iFeIM3mc8CdmdLno+6vdD3i1ic
EQFI/h91ZKn1Mt7jfT7gQz7KSMbePuFTPuPPxJXa5yznC1bwJStZxWrWsJZ1rGcDX/E137CRTXzL
ZrawlW1sZwc7+SvfsYvd7OF79rKP/RzgIIf4gcPEjaP+TlyUH7//+i+7//rxz0/49/Xxz0+I9a//
+Qn/jSWtBGfmStrAn/bd4x39pE417NdtQJ/ufftnHYeWl8fP/CirBMbjcv94vlyN1J6as/8lxPc/
L8tpeNStjrJ8vHTL4APzPizwwO2p6anm03LH24hKEiHux76z1/3kt0QA5889cMe8/K8/fyeO+0kZ
yeuzHXndb468LueR7eNYR92OmhZtSpwToo2Kox7/S/yuaHsiAzN2ebQ/sfuj/MQcSEQ6R3Rz1ISI
ao2WIEp2EYqmUlmjcMUoTkRJR2RwRPtHexBZMaWI4ecyqWSGJCKrI/o49kdFKhHZXjHqGFkP1ahO
HMDIUovMhoj2jQyQyAKrgyY963wQtbl+KuYUk3IYUddx0RrR+k2JqOSING+eSiIXYjonWpXIFolR
5MiqivYqZk8igj2iiCNyPKJ5I2Mgsg6iHYvsyhgbj3HtiGyO6PzODD9yDLp5PMLj6IVHZliPVHIu
6ElE/sf8aMzpRuGK68GIpo5WKKpYzIHGrGBctUaWU4waR/ZRZJTF1XxERke0emQsRBsWmTEjU8lE
Y8xAZpAZ7TDZibs/50gn5eQEcpGbPOQlH/mJUeACUZaIJO4oT6dyGqcTISAFKURhIkXuLM7mHIpQ
lHMpRnHO43xKcAElKUXpdHKuKEs5yqeTfktFKlGZKlSlGtWpQU1qcWE66d/Upg51iXNvPerTgIY0
ojFN0kk/qBmX0JwWtKQVl9Kay2jD5emkv3QlkQrQlqu4mna05xo60JFO6aRf1YWudONauqcjGdDx
Tyf9rZ5cTy9604e+9Esn/bAbuYmb6c8ABjIonfTPBjOEoQyLv5WK5FXHP520JdHhySCTbGQn7uad
g5ycEH1EcpOHvOQjPydSgJM4mVM4ldOI9JczKEghCnMmZ3E251AkM5l3PpdiFOf8zKQ+lLC+gJKU
ojRlKEs5ylOBilSiMlWoSjWqU4Oa1OJCLqI2dajLxdSjPg1oSCMa04SmNOMSmtOClrQi0iVbcxlt
uJwruJLf0paruJp2tOcaOtCRTnSmC13pxrV05zp68Dt6cj296E0f+tKPG7iRm7iZ/gxgIIO4hcEM
YSjDGM4IRnIrtykDt3MHd3IXd/N77uFe7uN+HuBBHiJiH2Is8WHrR/gjj/IYj8f3Gck56ilfRjGa
MYxlHOOZwEQmMZmneYYpTOVZpjGdGTzH88zkhXQyhjWL2czhRV7iZV5hLq8yj9d4nTd4k/m8xdu8
wwIWsojFvMsSlrKM93ifD/iQj/iYT/iUz4iUrL/wOcv5ghV8yUpWsZo1rGUd69nAV3zNN2xkE9+y
mS1sZRvb2cFO4qYb37GL3cSs4ffsZR/7OcBBDvEDh4nZp6wo6DhGGRE5o/6TjezEvWVykJPoEuYi
+lR5yEs+8nMiBTiFkzOS8bFTrU/jdM6gIIUozJmclRHJquo/RSjKuRSjOOdxPiW4gJKUojRlKEs5
ylOBilSiMlWoSjWqU4Oa1OJCLqI2dajLxdSjPg1oSCMa04SmNOMSmtOClrTiUlpzGW2IycgrMiIR
Tf2nLXFb7qtpR3uuoQMd6URnutCVbsSEZ3euowdxS4iexARiL3rTh5hw7McNGZFYrv5zM/0ZwEAG
cQuDGcJQhjGcEYzkVn4EUEsBAhQAFAAAAAgAmJG+KPQRdKJYlQEAAPwJAA4AAAAAAAAAAAAgALaB
AAAAAHBhY2tldC1zczcuZG9jUEsFBgAAAAABAAEAPAAAAISVAQAAAA==

--0__=CpfGEquZHC2A14se4aPSinL2WzWGKsJFjpgubpKR8tlbOuSD356XPkBU--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr  4 15:46:38 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14032
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 4 Apr 2000 15:46:38 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2B0E16F0@standards.nortelnetworks.com>; Tue, 4 Apr 2000 15:40:56 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 118345 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 4 Apr 2000 15:39:21 -0400
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.F2435CE0@standards.nortelnetworks.com>; Tue, 4 Apr 2000
          15:39:21 -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id
          VAA03570; Tue, 4 Apr 2000 21:44:34 +0200 (MET DST)
Received: from ericsson.com (arael25m037.ericsson.se [130.100.251.166]) by
          al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id
          VAA28726; Tue, 4 Apr 2000 21:44:32 +0200 (MET DST)
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <652568B7.005913F1.00@sandesh.hss.hns.com>
Content-Type: text/plain; charset=iso-8859-1
Message-ID:  <38EA4565.BF2E6E11@ericsson.com>
Date:         Tue, 4 Apr 2000 21:41:26 +0200
Reply-To: Stephen Terrill <stephen.terrill@ERICSSON.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Stephen Terrill <stephen.terrill@ERICSSON.COM>
Organization: L.M. Ericsson
Subject:      Re: MGC-MGC communication
X-To:         smahajan@HSS.HNS.COM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA14032

Hi Sunril,

I think that you have overlooked the Q.BICC work which is being designed to support the ISDN service set over technologies other than STM - and it is a standardised interface..  The first phase is completed (supporting ATM bearers) - see Q.1901, and Q.765.5 (I think).

The second phase will support IP bearers (both in the signalling and for the voice transport) and that is activively ongoing now.  There have certainly been discussions of using SCTP for the signalling transport, and for using H.248/megaco beteween the call and the bearer/transport level.

Regards,

..//steve

smahajan@HSS.HNS.COM wrote:

> Hi All,
> As there exists multiple protocol options for MGC-MGC interface but nothing yet
> standardized,
> attached white paper proposes an interface definition (protocol) for MGC to MGC
> communication
> in SS7 networks based on MEGACOP, SIGTRAN and Packet-SS7 protocols.
> Another attached document gives backgound on the Packet-SS7 architecture.
> Regards,
> Sunil Mahajan
> (looking for comments and feedback.............)
>
> (See attached file: packet-ss74mgc-mgc.zip)(See attached file: packet-ss7.zip)
>
>                                                   -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>                                 Name: packet-ss74mgc-mgc.zip
>    packet-ss74mgc-mgc.zip       Type: Winzip32 File (application/zip)
>                             Encoding: base64
>                          Description: .ZIP File
>
>                         Name: packet-ss7.zip
>    packet-ss7.zip       Type: Winzip32 File (application/zip)
>                     Encoding: base64
>                  Description: .ZIP File


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr  4 16:03:39 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14543
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 4 Apr 2000 16:03:38 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8CD6AC60@standards.nortelnetworks.com>; Tue, 4 Apr 2000 15:57:59 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 118380 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 4 Apr 2000 15:56:33 -0400
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.F379C490@standards.nortelnetworks.com>; Tue, 4 Apr 2000 15:46:32
          -0400
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id PAA07403 for
          <MEGACO@standards.nortelnetworks.com>; Tue, 4 Apr 2000 15:51:43 -0400
          (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id PAA00935 for
          <MEGACO@standards.nortelnetworks.com>; Tue, 4 Apr 2000 15:51:45 -0400
          (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <22M6LZTP>; Tue, 4 Apr 2000 15:46: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:  <4FBEA8857476D311A03300204840E1CF6780F3@whq-msgusr-02.fore.com>
Date:         Tue, 4 Apr 2000 15:51:43 -0400
Reply-To: "Rosen, Brian" <brosen@FORE.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <brosen@FORE.COM>
Subject:      Re: MGC-MGC communication
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I'd second this.  If you want maximum ISUP compatibility, use
Q.BICC.  If you want more "flexibility", consider SIP (or H.323).
Another standard is, IMHO, unwarranted at this time.  I think
such an attempt would not get support in IETF, or ITU at this time.

Brian

> -----Original Message-----
> From: Stephen Terrill [mailto:stephen.terrill@ERICSSON.COM]
> Sent: Tuesday, April 04, 2000 3:41 PM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: MGC-MGC communication
>
>
> Hi Sunril,
>
> I think that you have overlooked the Q.BICC work which is
> being designed to support the ISDN service set over
> technologies other than STM - and it is a standardised
> interface..  The first phase is completed (supporting ATM
> bearers) - see Q.1901, and Q.765.5 (I think).
>
> The second phase will support IP bearers (both in the
> signalling and for the voice transport) and that is
> activively ongoing now.  There have certainly been
> discussions of using SCTP for the signalling transport, and
> for using H.248/megaco beteween the call and the
> bearer/transport level.
>
> Regards,
>
> ..//steve
>
> smahajan@HSS.HNS.COM wrote:
>
> > Hi All,
> > As there exists multiple protocol options for MGC-MGC
> interface but nothing yet
> > standardized,
> > attached white paper proposes an interface definition
> (protocol) for MGC to MGC
> > communication
> > in SS7 networks based on MEGACOP, SIGTRAN and Packet-SS7 protocols.
> > Another attached document gives backgound on the Packet-SS7
> architecture.
> > Regards,
> > Sunil Mahajan
> > (looking for comments and feedback.............)
> >
> > (See attached file: packet-ss74mgc-mgc.zip)(See attached
> file: packet-ss7.zip)
> >
> >
> --------------------------------------------------------------
> --------------------------------------------------------------
> --------------------------------------------------------------
> --------------------------------------------------------------
> --------------------------------------------------------------
> --------------------------------------------------------------
> --------------------------------------------------------------
> --------------------------------------------------------------
> --------------------------------------------------------------
> --------------------------------------------------------------
> --------------------------------------------------------------
> --------------------------------------------------------------
> --------------------------------------------------------------
> --------------------------------------------------------------
> -------------------------------
> >                                 Name: packet-ss74mgc-mgc.zip
> >    packet-ss74mgc-mgc.zip       Type: Winzip32 File
> (application/zip)
> >                             Encoding: base64
> >                          Description: .ZIP File
> >
> >                         Name: packet-ss7.zip
> >    packet-ss7.zip       Type: Winzip32 File (application/zip)
> >                     Encoding: base64
> >                  Description: .ZIP File
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr  4 20:15:05 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20816
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 4 Apr 2000 20:15:05 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.ADAE2F30@standards.nortelnetworks.com>; Tue, 4 Apr 2000 20:09:27 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 118723 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 4 Apr 2000 20:08:23 -0400
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.87B82AB0@standards.nortelnetworks.com>; Tue, 4 Apr 2000
          20:08:23 -0400
Received: from zcard00n.ca.nortel.com (actually zcard00n) by
          smtprch1.nortel.com; Tue, 4 Apr 2000 16:00:46 -0500
Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com
          with SMTP (Microsoft Exchange Internet Mail Service Version
          5.5.2650.21) id 2HP0WB2W; Tue, 4 Apr 2000 16:59:05 -0400
Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) by
          zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id HNNLV706; Tue, 4 Apr 2000 16:59:03
          -0400
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <F033F6FEF3F1D111BD150000F8CD1431032A9D34@zcard007.ca.nortel.com>
            <38E65763.BF5D443B@usa.alcatel.com>
            <38E9DDA4.DF472724@americasm01.nt.com>
            <38E9F18E.F40E4616@usa.alcatel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38EA5814.4A530581@americasm01.nt.com>
Date:         Tue, 4 Apr 2000 17:01:08 -0400
Reply-To: Abdallah Rayhan <arayhan@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Abdallah Rayhan <arayhan@NORTELNETWORKS.COM>
Organization: Nortel Networks
Subject:      Re: V16 Review - Auditing contexts and their terminations
X-To:         Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Chuong,

I think you are confusing context auditing with terminations
which is why we have this proposal; we want to separate these
two concepts. Termination auditing occurs at the
termination level with Audit descriptor while context
audit either reports contexts and/or terminations, and
not auditing the terminations at the same time. The latter
is possible, however, it is performed at the command
level not the context .

Let me try to explain the cases we have and how that
translates in terms of transactions and replies.

Case 1: List of all contexts and all terminations:
Request:
Transaction = tid { Context = * {ContextAudit{Terminations}}}
Reply:
Reply = tid { Context=* {Root { Cid1 { t1,t2,t3....}, Cid2 { ....}}}}

Notice that we dont have to repeat "context=cid". If there are other
contexts in the reply, they each have unique ids.

Case 2: All terminations in a specific context
Request:
Transaction=tid { Context=Cid {ContextAudit{Terminations}}}
Reply:
Reply = tid { Context=Cid { Terminations { t1,2,t3, ...}}}

Again, if the request has other commands for the context cid,
the reply commands would come after ContextAudit{Terminations{ ....}}.
This includes AuditValue which could have a wildcard.

Case 3: All contexts, no terminations
Request:
Transaction = tid { Context=* {ContextAudit{Root}}}
Reply:
Reply =tid { Context= * { Contexts { cid1,cid2,cid3, ...}}}

Case 4: Perform case 1 in addition to terminationaudit
This case should be discouraged, IMO, my 2 cents,
because of the  size of the reply. Instead, the MGC
should use AuditValue with a specific  terminationId
instead of with a wildcard.
Request:
Transaction = tid { Context = * {ContextAudit{Terminations},
                                                   AuditValue = * { ....
} }}
Reply:
Reply = tid { Context=* {Root { Cid1 { t1,t2,3....}, Cid2 { ....}}},
                   Context = 1 { AuditValue = tid11 { ....}, AuditValue
= tid12 { .....} },
                   Context = 2 { AuditValue = tid21 { ....}, AuditValue
= tid22 { .....} },
                   .......}

One thing to remember when you audit the context you dont need to audit
the termination using the same command. I believe separating the
two is important.

Abdallah

Chuong Nguyen wrote:

> Abdallah
> Thanks for the reply.
>
> It doesn't really matter to me what the approach is as long as it is
> clearly documented somewhere
> and agreed/understood by Megaco implementors.
>
> Your approach about not repeating context seems contrary to previous
> discussion on how to
> handle wildcard command.
>
> Transaction = 1 {Context = * {AuditValue = *{Audit{Media}}}}
>
> What is the expected Reply?  The following or something else
> Reply = 1 {Context = 1 {AuditValue = t1, t2 {Audit{...}}},
>                    Context = 2 {AuditValue = t3,t4 {Audit{...}}},
>                    ... , Context = n {...}}
>
>
> Thanks
> Chuong
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Apr  5 04:25:57 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07160
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 5 Apr 2000 04:25:55 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2FA14D80@standards.nortelnetworks.com>; Wed, 5 Apr 2000 4:19:51 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 118949 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 5 Apr 2000 04:17:52 -0400
Received: from ish7.ericsson.com.au (203.61.155.111) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.82C16EC0@standards.nortelnetworks.com>; Wed, 5 Apr 2000 4:07:51
          -0400
Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id SAA25017; Wed, 5
          Apr 2000 18:11:23 +1000 (EST)
Received: from mcsi00.epa.ericsson.se (mcsi00 [146.11.8.201]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id SAA15499; Wed, 5
          Apr 2000 18:11:47 +1000 (EST)
Received: from ericsson.com (mcdh183.epa.ericsson.se [146.11.81.183]) by
          mcsi00.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id SAA13773; Wed,
          5 Apr 2000 18:11:10 +1000 (EST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <C51ED84B6F47D211917A0000F8BCBD11033227DB@zcard00g.ca.nortel.com>
            <38E8A2F1.C5114CF5@lucent.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Message-ID:  <38EAF51A.6CCD1887@ericsson.com>
Date:         Wed, 5 Apr 2000 18:11:06 +1000
Reply-To: Christian Groves <Christian.Groves@ERICSSON.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Christian Groves <Christian.Groves@ERICSSON.COM>
Subject:      Re: Summary of Issues Raised On the List
X-To:         John Segers <jsegers@LUCENT.COM>,
              Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit

G'Day John, Tom, all,

I've gone through the issues list and have a few comments and
suggestions. I've also added a few more items on the bottom of the
email. Please see [CHG] below.

Cheers, Christian

..snip..
> > 4. Issues Identified But Not Yet Resolved
> >
> >    Section                              Issue
> >
> >    6.2.2      Not clear what wildcard union responses look like.
[CHG]  A suggestion:
        Add "ie. Given termination Ta with properties p1=a, p2=b, and
               termination Tb with properties p2=c, p3=d a UNION
               resonse would be T* p1=a, p2=b,c, p3=d"
> >
> >    7.1.1      Third para (discussing unspecified parameters): not clear
> >               which parameters are mandatory.
[CHG] This depends on the application I would imagine. Can we really
give an
example of a mandatory parameter. Isn't this a statement of behaviour
rather than what a mandatory parameter is?

> >
> >    7.1.9      Not clear whether events trigger side effects (e.g.
> >               signal termination) at time of detection, at time of
> >               processing (whether or not in active Events Descriptor)
> >               or at time of notification.
[CHG] The current text states that "Normally, detection of an event
shall cause active signals to stop". So this is covered.

> >
..snip..
> >
> >    7.3        There should be no error        Delete codes 404, 405,
> >               responses to TransactionReply   461-467
> >               or TransactionPending, lest
> >               they create response loops.
[CHG] Sounds reasonable

> >
> >    8          Command execution should be     Not clear what "atomic"
> >               specified as atomic.            means, particularly
> >                                               where events and signals
> >                                               are concerned.
[CHG] No roll back

> >
> >    12.2,      Text indicates that statistics can have the sub-list data
> >    B.2        type, but ABNF does not support that.
[CHG] Isn't a list just an octet string? Does there need to be specific
ABNF. This leads to 12.3. Does a list need to be IANA registered as the
list name will be unique within a package. Proposal: remove last
sentence of 12.3

> >
..snip..
> >
> >    E.1.2      Granularity of signal completion event is too coarse as a
> >               mechanism to detect signalling failures.
[CHG] Unless people have more detailed codes I think we can live with
this. We can in v2 add more enumerations to the list if we need to.

> >
> >    E.9.2      Stated hook state reporting behaviour has race condition
> >               where same transition could be reported twice.
[CHG] Is this in the case of restrart?

> >
> >    E.10.2     Wording of condition for generating cmp event with
> >               "success" does not cover case where test also requires
> >               successful removal of tone.
[CHG] This is implied. An event stops a signal by default.

> >
> > 5. Errors For Which Corrections Are Stated
> >
> >    This is the only section which will remain in this document after
> >    the IESG has approved the combination of [2] and the corrections
> >    stated below.  It describes the errors and ambiguities which have
> >    been found in [2], along with the corrections they require.
> >
> >    Section    Issue                           Resolution
> >
..snip..
> >    7.1.8      Last bulleted item should       Add "loopback".
> >               include "loopback" in list of
> >               possible states.
[CHG] Should this be section 7.1.7?

..snip..

John Seger's Notes:
-------------------
>
> 7.2.3   The bullet list at the end of the section mentions provisioned and
>         default values that contradicts the (older) text in section 6.2.4.
[CHG] Isn't the default and provisioned value the same thing in this
case? as per 6.2.4?

Christian's additional comments:
--------------------------------
Chp 6.2.5 para 1
Change:
Root thus may have properties and events
To:
Root thus may have properties, statistics and events
Reason: Can't root have statistics?
Chp 7.2.4
Add:
The "choose"CHOOSE option is an error, as the Move command may only be
used on existing Terminations.
Reason: To align with the subtract command

Chp 7.2.8
Change:
The ServiceChangeReason parameter specifies the reason why the
ServiceChange has or will occur.  It consists of an alphanumeric token
(IANA registered) and an explanatory string.
to:
The ServiceChangeReason parameter specifies the reason why the
ServiceChange has or will occur.  It consists of an alphanumeric token
(IANA registered) and an optional explanatory string.
Reason: The explantory string is optional in the encoding.

Chp 7.2.8 point 1
Change:
…establishing new connections using the specified terminations and
should attempt
Reason:
Reads like NO new connections should be made where no connections should
be made on the specified terminations in the ServiceChange
Chp 8 Last Paragraph
Change:
Applications SHOULD implement an application level timer per
transaction.
to:
Applications SHOULD implement a protocol timer per transaction.
Reason:
Its not really timing the application but the protocol

Chp 12.1.2
Add:
… independent properties. Properties may also be defined in Local and
Remote descriptors.
Reason:
Reads like properties can only be defined on local control and
termination state.

A.1
Change:
TerminationID 0xFFFFFFFFFFFFFFFF SHALL be used to indicate the ROOT
Termination.
to:
TerminationID with all bits set to 1 (eg. 0xFFFFFFFFFFFFFFFF) SHALL be
used to indicate the ROOT Termination.
Reason:
A terminationID can be from 1bit to 6octets long. If your termination
scheme is only one octet it makes no sense to use 6 octets for ROOT.

E.2.1
Add:
Properties shall be defined in Local Control Descriptor
Reason:
Root properties are not defined for any descriptor


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Apr  5 12:56:29 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12811
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 5 Apr 2000 12:56:29 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.880533A0@standards.nortelnetworks.com>; Wed, 5 Apr 2000 12:50:33 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 119479 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 5 Apr 2000 12:49:04 -0400
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.ED42A150@standards.nortelnetworks.com>; Wed, 5 Apr 2000 12:39:04
          -0400
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id MAA27185; Wed, 5 Apr
          2000 12:44:18 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id MAA10583; Wed, 5 Apr
          2000 12:44:20 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <22M6MKX2>; Wed, 5 Apr 2000 12:39: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:  <4FBEA8857476D311A03300204840E1CF678110@whq-msgusr-02.fore.com>
Date:         Wed, 5 Apr 2000 12:44:18 -0400
Reply-To: "Rosen, Brian" <brosen@FORE.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <brosen@FORE.COM>
Subject:      Re: Summary of Issues Raised On the List
X-To:         Christian Groves <Christian.Groves@ERICSSON.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

G'Day All (Adelaide is still with me!)

Some comments on your comments to Johns comments to Tom's list

> > >
> > >    8          Command execution should be     Not clear
> what "atomic"
> > >               specified as atomic.            means, particularly
> > >                                               where
> events and signals
> > >                                               are concerned.
> [CHG] No roll back

Okay, so do you propose descriptors are executed in order?
What if part of a descriptor had an error?  For example, suppose
you said ...Signals{one,two} and it correctly applied one,
but could not apply two due to dsp resource exhaustion.
What should the state of the MG be?

Wouldn't you agree that it is essential that the MGC know what state
the MG is following this kind of error?

> > >    12.2,      Text indicates that statistics can have the
> sub-list data
> > >    B.2        type, but ABNF does not support that.
> [CHG] Isn't a list just an octet string? Does there need to
> be specific
> ABNF. This leads to 12.3. Does a list need to be IANA
> registered as the
> list name will be unique within a package. Proposal: remove last
> sentence of 12.3
You need lists to be IANA registered because multiple extensions
can be proposed, each extending the list.

I've asked for anyone to come up with a statistic that needed a list
without any responses.

> Chp 7.2.4
> Add:
> The "choose"CHOOSE option is an error, as the Move command may only be
> used on existing Terminations.
> Reason: To align with the subtract command
This would have to be clarified.  You can MOVE to a new context. So,
you might want to say "the CHOOSE option for a TerminationId is an
error...".  Might want to do the same in Subtract.
I do agree with the idea however.


> E.2.1
> Add:
> Properties shall be defined in Local Control Descriptor
> Reason:
> Root properties are not defined for any descriptor
All of the properties should be defined in Termination State,
as none of them are stream specific (streams of course have no
meaning for the Root Termination).


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Apr  5 18:22:09 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17130
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 5 Apr 2000 18:22:08 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FF076220@standards.nortelnetworks.com>; Wed, 5 Apr 2000 18:16:00 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 119716 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 5 Apr 2000 18:14:57 -0400
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.735D8ED0@standards.nortelnetworks.com>; Wed, 5 Apr 2000 18:04:56
          -0400
Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com
          (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id PAA14312; Wed, 5 Apr 2000
          15:08:55 -0700 (PDT)
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <C51ED84B6F47D211917A0000F8BCBD11033227DB@zcard00g.ca.nortel.com>
Content-Type: multipart/alternative;
              boundary="------------7B7E2968A6D6E8FD3380B2E0"
Message-ID:  <38EBE448.D12CDA98@cisco.com>
Date:         Wed, 5 Apr 2000 18:11:36 -0700
Reply-To: Flemming Andreasen <fandreas@CISCO.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Flemming Andreasen <fandreas@CISCO.COM>
Organization: Cisco Systems
Subject:      Re: Summary of Issues Raised On the List
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--------------7B7E2968A6D6E8FD3380B2E0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Tom

Some comments below. In addition to what you have here, I think we still have
one or two open issues with the digit maps - I'll resend the latest e-mail
exchange we had on this.

Regards

            Flemming



Tom-PT Taylor wrote:

> Attached please find a summary of the issues raised on the list.  The
> contents should be self-evident.  Please pay special attention to section 4:
> we MUST close off on these issues within the next week so we can end Last
> Call in timely fashion.
>  <<errata.txt>>
>
> Tom Taylor
> Advisor -- Emerging Carrier IP Standards
> E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
> Phone and FAX: +1 613 736 0961
>
> Media Gateway Control                                       P.T. Taylor
> Internet Draft                                          Nortel Networks
> Document: draft-ietf-megaco-errata-00.txt                    March 2000
> Category: Standards Track
>
>       Corrections To the Determined Megaco/H.248 Protocol Document
>
> Status of this Memo
>
>    This document is an Internet-Draft and is in full conformance with
>    all provisions of Section 10 of RFC2026 [1].
>
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF), its areas, and its working groups. Note that
>    other groups may also distribute working documents as Internet-
>    Drafts. Internet-Drafts are draft documents valid for a maximum of
>    six months and may be updated, replaced, or obsoleted by other
>    documents at any time. It is inappropriate to use Internet- Drafts
>    as reference material or to cite them other than as "work in
>    progress."
>    The list of current Internet-Drafts can be accessed at
>    http://www.ietf.org/ietf/1id-abstracts.txt
>    The list of Internet-Draft Shadow Directories can be accessed at
>    http://www.ietf.org/shadow.html.
>
> 1. Abstract
>
>    This document records the errors found in the draft Megaco/H.248
>    protocol document [2], along with the changes proposed in the text
>    of that document to resolve them. After joint IETF/ITU-T Study Group
>    16 approval of these corrections, they will be incorporated into the
>    final decided version of H.248 and the corresponding Megaco protocol
>    RFC.
>
> 2. Conventions used in this document
>
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
>    this document are to be interpreted as described in RFC-2119 [1].
>
> Taylor           Standards Track -- Expires Sep 2000                 1
>                        Megaco/H.248 Corrections             March 2000
>
> 3. Issues Not Found To Require Changes
>
>    This section lists a few of the issues raised on the Megaco list
>    which were found not to require a change in [2].  There were a
>    number of other such issues which may be recorded here as a matter
>    of record pending completion of IESG Last Call.  This section will
>    be deleted from the final document submitted into the ITU-T Study
>    Group 16 decision process.  All section numbers are from [2].
>
>    Section    Problem                         Resolution
>    7.1.9      Discarding of buffered events   No change.  Reasonable
>               when EventBufferControl is      case for making a
>               changed to OFF is               different decision from
>               inconsistent with provision     the one made in Geneva,
>               for notification of multiple    but not actually an
>               events at once in latter        error.
>               state.
>
>    7.1.11     Last bullet list and            Not an error or
>               preceding sentence simply       ambiguity, no action.
>               recapitulate definition of
>               KeepActive flag.

I read it slightly different as it seems to imply "KeepActive" semantics,
regardless of whether the flag is present or not (not an issue, just want to
clarify)

>
>    7.2.5,     Relationship between text and   Clarification, not
>    7.2.6      representation of wildcarded    ambiguity or error.
>               audit request is not clear.
>
> 4. Issues Identified But Not Yet Resolved
>
>    This section, as its title implies, contains issues which have been
>    identified in discussion on the list but for which a final
>    resolution has not been achieved.  All of these issues must be
>    resolved or moved to the previous section before Last Call can be
>    declared complete.  Hence this section will be deleted before this
>    document is submitted to the IESG for final approval.
>
>    Section                              Issue
>
>    6.2.2      Not clear what wildcard union responses look like.

Proposed resolution:        Add an example somewhere.

>
>
>    7.1.1      Third para (discussing unspecified parameters): not clear
>               which parameters are mandatory.

Proposed resolution:    Add a table.

>
>
> Taylor           Standards Track -- Expires Sep 2000                 2
>                        Megaco/H.248 Corrections             March 2000
>
>    7.1.9      Not clear whether events trigger side effects (e.g.
>               signal termination) at time of detection, at time of
>               processing (whether or not in active Events Descriptor)
>               or at time of notification.

Proposed resolution:    At time of processing, i.e. if an event specified in the
active Events Descriptor is processed, signals on the termination stop (unless
KeepActive is specified).


>
>
>    7.1.14     Not clear whether non-matched events trigger side effects
>               at time of processing against digit map or when processed
>               against active Events Descriptor following digit map
>               completion event detection.

I didn't follow that - can you elaborate ?

>
>
>    7.1.17     Not clear whether AuditValue of ObservedEventsDescriptor
>               reports events captured in current dial string of active
>               digit map.

Proposed solution:        Given the way digits collected according to digit maps
will be reported in the end, it would seem consistent to not report the current
dial string. Alternatively, I guess you could include a DigitMap Completion
event with a digitstring, but without a Termination Method.

>
>
>    7.3        There should be no error        Delete codes 404, 405,
>               responses to TransactionReply   461-467
>               or TransactionPending, lest
>               they create response loops.

Agreed.

>
>
>    8          Command execution should be     Not clear what "atomic"
>               specified as atomic.            means, particularly
>                                               where events and signals
>                                               are concerned.

Proposed resolution:        Get Brian Rosen to type up something :-)

>

>    12.2,      Text indicates that statistics can have the sub-list data
>    B.2        type, but ABNF does not support that.
>
>    B.2        Syntax for parmValue confounds over-specification and
>               sub-lists.
>
>    C.8        Length of GIT is wrong.
>
> Taylor           Standards Track -- Expires Sep 2000                 3
>                        Megaco/H.248 Corrections             March 2000
>
>    D.1.4      Second para: transaction originator may not have received
>               TransactionPending response(s) because they were lost,
>               and may therefore not know that responder is expecting
>               immediate acknowledgement of the TransactionReply.

Proposed resolution:        Add an optional field in the TransactionReply
allowing the responder to indicate if an immediate ack is expected or not.

>
>
>    E.1.2      Granularity of signal completion event is too coarse as a
>               mechanism to detect signalling failures.

Proposed resolution:    Define an EventsDescriptor parameterfor the Signal
Completion event allowing the MGC to specify which Termination Methods it's
interested in.

>
>
>    E.9.2      Stated hook state reporting behaviour has race condition
>               where same transition could be reported twice.

Proposed resolution:    Add the following event parameters for the onhook and
offhook events:
1. No expected hook-state, just report next transition
2. Event indicates expected hook-state, report if hook-state differs (current
text)
3. Event indicates expected hook-state, let command fail if actual hook-state
differs.


>
>
>    E.10.2     Wording of condition for generating cmp event with
>               "success" does not cover case where test also requires
>               successful removal of tone.

(actually E.10.5)

Proposed resolution:        Replace "If the return tone is detected before the
signal times out" with "If the test succeeds before the signal times out"


>
>
> 5. Errors For Which Corrections Are Stated
>
>    This is the only section which will remain in this document after
>    the IESG has approved the combination of [2] and the corrections
>    stated below.  It describes the errors and ambiguities which have
>    been found in [2], along with the corrections they require.
>
>    Section    Issue                           Resolution
>
>    2          Q.724 is not used.              Delete from list of
>                                               references.
>    4          BRI is not used.                Delete from list of
>                                               abbreviations.
>    2, C       Leave Recs. referred to in      Do that.
>               Annex C undated, implying
>               latest issue.
>
> Taylor           Standards Track -- Expires Sep 2000                 4
>                        Megaco/H.248 Corrections             March 2000
>
>    6.2.4      Says that property values set   Add text to first para
>               in Null context are             third sentence: "Most
>               remembered and reinstated       properties have default
>               when termination returns to     values, which are
>               Null.  Contradicts latest       explicitly defined in
>               text in 7.2.3.                  this standard or set by
>                                               provisioning."  Delete
>                                               first para fourth
>                                               sentence, which read:
>                                               "The default value of a
>                                               property of a physical
>                                               Termination can be
>                                               changed by setting it to
>                                               a different value when
>                                               the Termination is in
>                                               the null Context."
>    6.2.4      DigitMap entry in table makes   Change existing text to
>               explicit reference to DTMF      new one as follows:
>               tones.                          "Defines patterns
>                                               against which sequences
>                                               of a specified set of
>                                               events are to be matched
>                                               so they can be reported
>                                               as a group rather than
>                                               singly."
>    7.1,       The order in which              Add text stating that
>    A.2        descriptors are processed       descriptors are
>               within a command matters, but   processed in the order
>               is not clear.  Moreover, it     in which they are
>               is fixed in the ASN.1 but       provided.  Change ASN.1
>               variable in the ABNF.           in Annex A.2 to impose
>                                               ordering as suggested by
>                                               John Segers ("Descriptor
>                                               processing order", Wed
>                                               15/03/00)

Solves the "audit order issue" in 7.2.9, but not quite sure what that means in
lieu of atomic command execution.

>
>    7.1.5,     Text allows CHOOSE for          Change ABNF:
>    B.2        property values in              propertyParm = pkgdName
>               TerminationStateDesc, but       ( "$" / parmValue)
>               ABNF does not.
>    7.1.6,     Text indicates use of "true"    Add comment in B.2 that
>    B.2        and "false" values while ABNF   "true" in text
>               uses "on" and "off"             corresponds to "on" in
>                                               ABNF, and "false"
>                                               corresponds to "off".
>    7.1.8      Last bulleted item should       Add "loopback".
>               include "loopback" in list of
>               possible states.

Just to clarify:        Last bulleted item in the second last bullet list.

>
>
> Taylor           Standards Track -- Expires Sep 2000                 5
>                        Megaco/H.248 Corrections             March 2000
>
>    7.1.9      EventDM is part of syntax but   Add text: "If a digit
>               not mentioned in section.       map is required in the
>                                               EventsDescriptor,
>                                               EventDM is used to carry
>                                               either the name or the
>                                               value of the digit map.
>                                               See section 7.1.14."

When is a digit map required in the EventsDescriptor ?

>
>    7.1.9      Case 1, step 2(a) is both       Fix separation of
>               incorrectly formulated and      paragraphs.  Change step
>               incorrectly formatted.          2(a) to read: "While
>               Existing logic may result in    waiting for a new
>               an infinite loop.               EventsDescriptor, any
>                                               events detected which
>                                               appear in the current
>                                               EventsBufferDescriptor
>                                               will be placed in the
>                                               EventBuffer.  When a new
>                                               EventDescriptor is
>                                               received, event
>                                               processing repeats from
>                                               step 1."
>    7.1.13     Missing "extension"             Add missing component.
>               component.
>    7.1.14     Item 5 in second numbered       Add the words "and it
>               list  understates conditions    has been fully matched"
>               for digit map completion when   to the existing sentence
>               single candidate remains.
>
>    7.1.18     Third bullet attached to        Delete the clause ";
>               third para: says loopback       loopbacks are created by
>               achieved by manipulating        setting the
>               TerminationMode, which no       TerminationMode"
>               longer has that name.
>    7.2.5      Fails to indicate what          Add the following text:
>               AuditValue for                  "EventBuffer returns the
>               EventBufferDescriptor returns   set of events and
>                                               associated parameter
>                                               values currently enabled
>                                               in the
>                                               EventBufferDescriptor."
>    7.2.5,     Text and ASN.1 allow return     Fix production
>    B.2        of results involving multiple   contextTerminationAudit
>               contexts, but ABNF does not.    by allowing return of
>                                               list of context-specific
>                                               results as an
>                                               alternative.
>
> Taylor           Standards Track -- Expires Sep 2000                 6
>                        Megaco/H.248 Corrections             March 2000
>
>    7.2.5,     Does not indicate how an        Change syntax of
>    A.2,       audit of digit maps returns     DigitMapDescriptor to
>    B.2        unnamed digit maps.             allow return of unnamed
>                                               digit maps per John
>                                               Seger suggestion ("[Fwd:
>                                               Issues In v16 Draft]",
>                                               Wed 15/03/00).
>    7.2.6      Fails to indicate what
>               AuditCapabilities for           "EventBuffer returns the
>                                               Add the following text:
>               EventBufferDescriptor returns   same information as
>                                               Events."

Not sure that's entirely accurate since EventBuffer is a sequence of Observed
Events

>
>    7.2.6,     Inconsistency regarding         Add comment to B.2
>    B.2        permissibility of DigitMap or   "auditItem" production
>               Packages as capability audit    indicating that DigitMap
>               items.                          and Packages are not
>                                               allowed in the
>                                               AuditCapabilities
>                                               command.

I still don't understand how digit maps can apply to all terminations,
regardless of type (e.g. consider video)

>
>    7.2.8      Paragraph beginning "A          Add text to the
>               ServiceChange Command           offending sentence, so
>               specifying the Root..."         that it reads:
>               immediately following the       "Acknowledgement of the
>               description of ServiceChange    ServiceChange Command
>               Descriptor parameters           completes the
>               erroneously states that the     registration process,
>               response to the ServiceChange   except when the MGC has
>               command terminates the          returned an alternative
>               registration process.  This     ServiceChangeMgcId as
>               is so only if the response      described in the next
>               does not specify an alternate   paragraph."
>               MGC.
>
>    7.3        Text for error code 403         Change text to "Syntax
>               should be consistent with       error in
>               that for 404 and 405.           TransactionRequest"
>
>    8.2.2      Final para has wrong text for   Change to "Syntax Error
>               error code 442.                 in Command"
>
>    11.2       Second paragraph last           Restore original
>               sentence inadvertently          sentence: "If the MG is
>               modified -- duplicates          unable to establish a
>               material in 11.3.               control relationship
>                                               with any MGC, it shall
>                                               wait a random amount of
>                                               time as described in
>                                               Section 9.2 and then
>                                               start contacting its
>                                               primary, and if

First paragraph actually.

>
>
> Taylor           Standards Track -- Expires Sep 2000                 7
>                        Megaco/H.248 Corrections             March 2000
>
>                                               necessary, its secondary
>                                               MGCs again."
>
>    11.4       Second para: wrong MG is        Change fourth sentence
>               specified as the one to be      to refer to "secondary
>               used after failover.            MG" rather than "primary
>                                               MG".
>    12.1.4     Note says that default          Add TO signals to note.
>               duration should be specified
>               for BR signals.  This also
>               applies to TO signals.
>    A.2        LocalControlDescriptor still
>               contains reserve rather than    separate reserveValue
>               reserveValue and                and reserveGroup
>                                               Replace reserve with
>               reserveGroup.                   Booleans.
>
>    A.2        Assigned object identifier      Add object identifier
>               missing.                        line with content
>                                               "itu-t recommendation h
>                                               248 media-gateway-
>                                               control(0)"
>    B.2        Syntax for parmValue and
>               VALUE together make parsing     in alternativeValue by
>                                               Replace range notation
>               of range ambiguous.             "LSBRKT VALUE COLON
>                                               VALUE RSBRKT"
>    B.2        Error in syntax for
>               digitMapDescriptor: value       digitMapDescriptor =
>                                               Change production:
>               meant to be optional.           DigitMapToken EQUAL
>                                               digitMapName
>                                               [ LBRKT digitMapValue
>                                               RBRKT ]
>    B.2        VersionToken not defined.       Add ABNF:
>                                               VersionToken =
>                                               ("Version" / "V")
>    B.2        DiscardToken not used.          Delete production.
>    C.9        ITC has reference to missing    Delete reference.
>               note 2
>
>    C.9        Not clear that Q.931 Bearer     Specify that values are
>               Capability IE rather than Low   those valid for Bearer
>               Layer Compatibility IE is       Capability IE
>               being used.
>
> Taylor           Standards Track -- Expires Sep 2000                 8
>                        Megaco/H.248 Corrections             March 2000
>
>    D.1        Even in the case of handoff     In the last sentence of
>               or failover, the originating    the first paragraph,
>               MGC needs confirmation that     delete the excepting
>               its command was received.       clause, so that the
>                                               sentence reads:
>                                               "Responses must be sent
>                                               to the address and port
>                                               from which the
>                                               corresponding commands
>                                               were sent."
>    D.1.1      Second para last sentence
>               provides a procedural
>               reference to 8.2.3.  Should
>               refer to UDP-specific
>                                               Add reference to D.1.4.
>               procedures.
>
>    D.1.4      First paragraph, last
>               sentence talks about when to    SHOULD send this
>               send the Transaction Pending    response if they receive
>               response.  When UDP/ALF is in   a repetition of a
>               use, the originator of a        transaction that is
>               transaction may repeat it       still being executed."
>               because it has not received
>               an acknowledgement that the
>               transaction was received.  An
>               appropriate response to a
>               duplicate transaction which
>               is still being processed is
>               to return Transaction
>                                               Add the sentence: "They
>               Pending.
>
>    D.1.5      Last paragraph is equivocal     Change the two sentences
>               about what                      following the phrase "_
>               ServiceChangeReason to use      and it begins its
>               when recovering from loss of    recovery process" to
>               contact; it must always be      read as follows: "The MG
>               "Disconnected".                 shall use a
>                                               ServiceChange with
>                                               ServiceChangeMethod set
>                                               to disconnected so that
>                                               the new MGC will be
>                                               aware that the MG lost
>                                               one or more
>                                               transactions."
>    E.6.2      "Long duration event            Replace with "Z".
>               modifier" is shown as "L" in
>               parameter DigitString --
>               should be "Z".
>
> Taylor           Standards Track -- Expires Sep 2000                 9
>                        Megaco/H.248 Corrections             March 2000
>
>    Appx       Step 20 fails to show a         Add the following to the
>    A.1.2      returned                        Media Descriptor
>               TerminationStateDescriptor      preceding the line
>                                               "Stream = 1_":
>                                               "TerminationState {
>                                               ServiceStates =
>                                               InService,
>                                               EventBufferControl = OFF
>                                               },"
>
> 6. Security Considerations
>
>    This draft is a supplement to [2], which contains the required
>    security section.
>
> 7. References
>
>    [1] RFC 2026
>    [2] draft-ietf-megaco-protocol-07.txt
>    [3] RFC 2119
>
> 8. Acknowledgments
>
>    This draft records the contributions of a number of people on the
>    Megaco list who took the time to read the Megaco/H.248 draft with
>    care and attention.  Thanks to all of them.
>
> 9. Author's Addresses
>
>    Tom Taylor
>    Nortel Networks
>    P.O. Box 3511, Station C
>    Ottawa, Ontario, Canada K1Y 4P7
>    Phone: +1 613 736 0961
>    Email: taylor@nortelnetworks.com
>
> Taylor           Standards Track -- Expires Sep 2000                10
>                        Megaco/H.248 Corrections             March 2000
>
> Full Copyright Statement
>
>    "Copyright (C) The Internet Society (date). All Rights Reserved.
>    This document and translations of it may be copied and furnished to
>    others, and derivative works that comment on or otherwise explain it
>    or assist in its implmentation may be prepared, copied, published
>    and distributed, in whole or in part, without restriction of any
>    kind, provided that the above copyright notice and this paragraph
>    are included on all such copies and derivative works. However, this
>    document itself may not be modified in any way, such as by removing
>    the copyright notice or references to the Internet Society or other
>    Internet organizations, except as needed for the purpose of
>    developing Internet standards in which case the procedures for
>    copyrights defined in the Internet Standards process must be
>    followed, or as required to translate it into other languages.
>
>    1  Bradner, S., "Key words for use in RFCs to Indicate Requirement
>       Levels", BCP 14, RFC 2119, March 1997
>
> Taylor           Standards Track -- Expires Sep 2000                11

--
Flemming Andreasen                Phone: +1 732 452 1667
Cisco Systems                     Fax:   +1 240 359 5839


--------------7B7E2968A6D6E8FD3380B2E0
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi Tom
<p>Some comments below. In addition to what you have here, I think we still
have one or two open issues with the digit maps - I'll resend the latest
e-mail exchange we had on this.
<p>Regards
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Flemming
<br>&nbsp;
<br>&nbsp;
<p><tt>Tom-PT Taylor wrote:</tt>
<blockquote TYPE=CITE><tt>Attached please find a summary of the issues
raised on the list.&nbsp; The</tt>
<br><tt>contents should be self-evident.&nbsp; Please pay special attention
to section 4:</tt>
<br><tt>we MUST close off on these issues within the next week so we can
end Last</tt>
<br><tt>Call in timely fashion.</tt>
<br><tt>&nbsp;&lt;&lt;errata.txt>></tt>
<p><tt>Tom Taylor</tt>
<br><tt>Advisor -- Emerging Carrier IP Standards</tt>
<br><tt>E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)</tt>
<br><tt>Phone and FAX: +1 613 736 0961</tt>
<p><tt>Media Gateway Control&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
P.T. Taylor</tt>
<br><tt>Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Nortel Networks</tt>
<br><tt>Document: draft-ietf-megaco-errata-00.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
March 2000</tt>
<br><tt>Category: Standards Track</tt>
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Corrections To the Determined Megaco/H.248
Protocol Document</tt>
<p><tt>Status of this Memo</tt>
<p><tt>&nbsp;&nbsp; This document is an Internet-Draft and is in full conformance
with</tt>
<br><tt>&nbsp;&nbsp; all provisions of Section 10 of RFC2026 [1].</tt>
<p><tt>&nbsp;&nbsp; Internet-Drafts are working documents of the Internet
Engineering</tt>
<br><tt>&nbsp;&nbsp; Task Force (IETF), its areas, and its working groups.
Note that</tt>
<br><tt>&nbsp;&nbsp; other groups may also distribute working documents
as Internet-</tt>
<br><tt>&nbsp;&nbsp; Drafts. Internet-Drafts are draft documents valid
for a maximum of</tt>
<br><tt>&nbsp;&nbsp; six months and may be updated, replaced, or obsoleted
by other</tt>
<br><tt>&nbsp;&nbsp; documents at any time. It is inappropriate to use
Internet- Drafts</tt>
<br><tt>&nbsp;&nbsp; as reference material or to cite them other than as
"work in</tt>
<br><tt>&nbsp;&nbsp; progress."</tt>
<br><tt>&nbsp;&nbsp; The list of current Internet-Drafts can be accessed
at</tt>
<br><tt>&nbsp;&nbsp; <a href="http://www.ietf.org/ietf/1id-abstracts.txt">http://www.ietf.org/ietf/1id-abstracts.txt</a></tt>
<br><tt>&nbsp;&nbsp; The list of Internet-Draft Shadow Directories can
be accessed at</tt>
<br><tt>&nbsp;&nbsp; <a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>.</tt>
<p><tt>1. Abstract</tt>
<p><tt>&nbsp;&nbsp; This document records the errors found in the draft
Megaco/H.248</tt>
<br><tt>&nbsp;&nbsp; protocol document [2], along with the changes proposed
in the text</tt>
<br><tt>&nbsp;&nbsp; of that document to resolve them. After joint IETF/ITU-T
Study Group</tt>
<br><tt>&nbsp;&nbsp; 16 approval of these corrections, they will be incorporated
into the</tt>
<br><tt>&nbsp;&nbsp; final decided version of H.248 and the corresponding
Megaco protocol</tt>
<br><tt>&nbsp;&nbsp; RFC.</tt>
<p><tt>2. Conventions used in this document</tt>
<p><tt>&nbsp;&nbsp; The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT",</tt>
<br><tt>&nbsp;&nbsp; "SHOULD", "SHOULD NOT", "RECOMMENDED",&nbsp; "MAY",
and "OPTIONAL" in</tt>
<br><tt>&nbsp;&nbsp; this document are to be interpreted as described in
RFC-2119 [1].</tt>
<p><tt>Taylor&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Standards Track -- Expires Sep 2000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Megaco/H.248 Corrections&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
March 2000</tt>
<p><tt>3. Issues Not Found To Require Changes</tt>
<p><tt>&nbsp;&nbsp; This section lists a few of the issues raised on the
Megaco list</tt>
<br><tt>&nbsp;&nbsp; which were found not to require a change in [2].&nbsp;
There were a</tt>
<br><tt>&nbsp;&nbsp; number of other such issues which may be recorded
here as a matter</tt>
<br><tt>&nbsp;&nbsp; of record pending completion of IESG Last Call.&nbsp;
This section will</tt>
<br><tt>&nbsp;&nbsp; be deleted from the final document submitted into
the ITU-T Study</tt>
<br><tt>&nbsp;&nbsp; Group 16 decision process.&nbsp; All section numbers
are from [2].</tt>
<p><tt>&nbsp;&nbsp; Section&nbsp;&nbsp;&nbsp; Problem&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Resolution</tt>
<br><tt>&nbsp;&nbsp; 7.1.9&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Discarding of
buffered events&nbsp;&nbsp; No change.&nbsp; Reasonable</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
when EventBufferControl is&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; case for making
a</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
changed to OFF is&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
different decision from</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
inconsistent with provision&nbsp;&nbsp;&nbsp;&nbsp; the one made in Geneva,</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
for notification of multiple&nbsp;&nbsp;&nbsp; but not actually an</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
events at once in latter&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; error.</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
state.</tt>
<p><tt>&nbsp;&nbsp; 7.1.11&nbsp;&nbsp;&nbsp;&nbsp; Last bullet list and&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Not an error or</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
preceding sentence simply&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ambiguity,
no action.</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
recapitulate definition of</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
KeepActive flag.</tt></blockquote>
I read it slightly different as it seems to imply "KeepActive" semantics,
regardless of whether the flag is present or not (not an issue, just want
to clarify)
<blockquote TYPE=CITE>&nbsp;
<br><tt>&nbsp;&nbsp; 7.2.5,&nbsp;&nbsp;&nbsp;&nbsp; Relationship between
text and&nbsp;&nbsp; Clarification, not</tt>
<br><tt>&nbsp;&nbsp; 7.2.6&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; representation
of wildcarded&nbsp;&nbsp;&nbsp; ambiguity or error.</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
audit request is not clear.</tt>
<p><tt>4. Issues Identified But Not Yet Resolved</tt>
<p><tt>&nbsp;&nbsp; This section, as its title implies, contains issues
which have been</tt>
<br><tt>&nbsp;&nbsp; identified in discussion on the list but for which
a final</tt>
<br><tt>&nbsp;&nbsp; resolution has not been achieved.&nbsp; All of these
issues must be</tt>
<br><tt>&nbsp;&nbsp; resolved or moved to the previous section before Last
Call can be</tt>
<br><tt>&nbsp;&nbsp; declared complete.&nbsp; Hence this section will be
deleted before this</tt>
<br><tt>&nbsp;&nbsp; document is submitted to the IESG for final approval.</tt>
<p><tt>&nbsp;&nbsp; Section&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Issue</tt>
<p><tt>&nbsp;&nbsp; 6.2.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Not clear what
wildcard union responses look like.</tt></blockquote>
Proposed resolution:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Add an example
somewhere.
<blockquote TYPE=CITE>&nbsp;
<p><tt>&nbsp;&nbsp; 7.1.1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Third para (discussing
unspecified parameters): not clear</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
which parameters are mandatory.</tt></blockquote>
Proposed resolution:&nbsp;&nbsp;&nbsp; Add a table.
<blockquote TYPE=CITE>&nbsp;
<p><tt>Taylor&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Standards Track -- Expires Sep 2000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
2</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Megaco/H.248 Corrections&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
March 2000</tt>
<p><tt>&nbsp;&nbsp; 7.1.9&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Not clear whether
events trigger side effects (e.g.</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
signal termination) at time of detection, at time of</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
processing (whether or not in active Events Descriptor)</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
or at time of notification.</tt></blockquote>
Proposed resolution:&nbsp;&nbsp;&nbsp; At time of processing, i.e. if an
event specified in the active Events Descriptor is processed, signals on
the termination stop (unless KeepActive is specified).
<br>&nbsp;
<blockquote TYPE=CITE>&nbsp;
<p><tt>&nbsp;&nbsp; 7.1.14&nbsp;&nbsp;&nbsp;&nbsp; Not clear whether non-matched
events trigger side effects</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
at time of processing against digit map or when processed</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
against active Events Descriptor following digit map</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
completion event detection.</tt></blockquote>
I didn't follow that - can you elaborate ?
<blockquote TYPE=CITE>&nbsp;
<p><tt>&nbsp;&nbsp; 7.1.17&nbsp;&nbsp;&nbsp;&nbsp; Not clear whether AuditValue
of ObservedEventsDescriptor</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
reports events captured in current dial string of active</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
digit map.</tt></blockquote>
Proposed solution:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Given the
way digits collected according to digit maps will be reported in the end,
it would seem consistent to not report the current dial string. Alternatively,
I guess you could include a DigitMap Completion event with a digitstring,
but without a Termination Method.
<blockquote TYPE=CITE>&nbsp;
<p><tt>&nbsp;&nbsp; 7.3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; There
should be no error&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Delete codes
404, 405,</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
responses to TransactionReply&nbsp;&nbsp; 461-467</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
or TransactionPending, lest</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
they create response loops.</tt></blockquote>
Agreed.
<blockquote TYPE=CITE>&nbsp;
<p><tt>&nbsp;&nbsp; 8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Command execution should be&nbsp;&nbsp;&nbsp;&nbsp; Not clear what "atomic"</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
specified as atomic.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
means, particularly</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
where events and signals</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
are concerned.</tt></blockquote>
Proposed resolution:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Get Brian
Rosen to type up something :-)
<blockquote TYPE=CITE>&nbsp;</blockquote>

<blockquote TYPE=CITE><tt>&nbsp;&nbsp; 12.2,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Text indicates that statistics can have the sub-list data</tt>
<br><tt>&nbsp;&nbsp; B.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; type,
but ABNF does not support that.</tt>
<p><tt>&nbsp;&nbsp; B.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Syntax
for parmValue confounds over-specification and</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
sub-lists.</tt>
<p><tt>&nbsp;&nbsp; C.8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Length
of GIT is wrong.</tt>
<p><tt>Taylor&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Standards Track -- Expires Sep 2000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
3</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Megaco/H.248 Corrections&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
March 2000</tt>
<p><tt>&nbsp;&nbsp; D.1.4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Second para: transaction
originator may not have received</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
TransactionPending response(s) because they were lost,</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
and may therefore not know that responder is expecting</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
immediate acknowledgement of the TransactionReply.</tt></blockquote>
Proposed resolution:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Add an optional
field in the TransactionReply allowing the responder to indicate if an
immediate ack is expected or not.
<blockquote TYPE=CITE>&nbsp;
<p><tt>&nbsp;&nbsp; E.1.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Granularity of
signal completion event is too coarse as a</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
mechanism to detect signalling failures.</tt></blockquote>
Proposed resolution:&nbsp;&nbsp;&nbsp; Define an EventsDescriptor parameterfor
the Signal Completion event allowing the MGC to specify which Termination
Methods it's interested in.
<blockquote TYPE=CITE>&nbsp;
<p><tt>&nbsp;&nbsp; E.9.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Stated hook state
reporting behaviour has race condition</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
where same transition could be reported twice.</tt></blockquote>

<p><br>Proposed resolution:&nbsp;&nbsp;&nbsp; Add the following event parameters
for the onhook and offhook events:
<br>1. No expected hook-state, just report next transition
<br>2. Event indicates expected hook-state, report if hook-state differs
(current text)
<br>3. Event indicates expected hook-state, let command fail if actual
hook-state differs.
<br>&nbsp;
<blockquote TYPE=CITE>&nbsp;
<p><tt>&nbsp;&nbsp; E.10.2&nbsp;&nbsp;&nbsp;&nbsp; Wording of condition
for generating cmp event with</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
"success" does not cover case where test also requires</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
successful removal of tone.</tt></blockquote>
(actually E.10.5)
<p>Proposed resolution:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Replace
"If the return tone is detected before the signal times out" with "If the
test succeeds before the signal times out"
<br>&nbsp;
<blockquote TYPE=CITE>&nbsp;
<p><tt>5. Errors For Which Corrections Are Stated</tt>
<p><tt>&nbsp;&nbsp; This is the only section which will remain in this
document after</tt>
<br><tt>&nbsp;&nbsp; the IESG has approved the combination of [2] and the
corrections</tt>
<br><tt>&nbsp;&nbsp; stated below.&nbsp; It describes the errors and ambiguities
which have</tt>
<br><tt>&nbsp;&nbsp; been found in [2], along with the corrections they
require.</tt>
<p><tt>&nbsp;&nbsp; Section&nbsp;&nbsp;&nbsp; Issue&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Resolution</tt>
<p><tt>&nbsp;&nbsp; 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Q.724 is not used.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Delete from list of</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
references.</tt>
<br><tt>&nbsp;&nbsp; 4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
BRI is not used.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Delete from list of</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
abbreviations.</tt>
<br><tt>&nbsp;&nbsp; 2, C&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Leave Recs.
referred to in&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Do that.</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Annex C undated, implying</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
latest issue.</tt>
<p><tt>Taylor&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Standards Track -- Expires Sep 2000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
4</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Megaco/H.248 Corrections&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
March 2000</tt>
<p><tt>&nbsp;&nbsp; 6.2.4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Says that property
values set&nbsp;&nbsp; Add text to first para</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
in Null context are&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
third sentence: "Most</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
remembered and reinstated&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; properties
have default</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
when termination returns to&nbsp;&nbsp;&nbsp;&nbsp; values, which are</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Null.&nbsp; Contradicts latest&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; explicitly
defined in</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
text in 7.2.3.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
this standard or set by</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
provisioning."&nbsp; Delete</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
first para fourth</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
sentence, which read:</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
"The default value of a</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
property of a physical</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Termination can be</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
changed by setting it to</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
a different value when</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
the Termination is in</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
the null Context."</tt>
<br><tt>&nbsp;&nbsp; 6.2.4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DigitMap entry
in table makes&nbsp;&nbsp; Change existing text to</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
explicit reference to DTMF&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; new one as follows:</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
tones.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
"Defines patterns</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
against which sequences</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
of a specified set of</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
events are to be matched</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
so they can be reported</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
as a group rather than</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
singly."</tt>
<br><tt>&nbsp;&nbsp; 7.1,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The order
in which&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Add text stating that</tt>
<br><tt>&nbsp;&nbsp; A.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; descriptors
are processed&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; descriptors are</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
within a command matters, but&nbsp;&nbsp; processed in the order</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
is not clear.&nbsp; Moreover, it&nbsp;&nbsp;&nbsp;&nbsp; in which they
are</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
is fixed in the ASN.1 but&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; provided.&nbsp;
Change ASN.1</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
variable in the ABNF.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
in Annex A.2 to impose</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ordering as suggested by</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
John Segers ("Descriptor</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
processing order", Wed</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
15/03/00)</tt></blockquote>
Solves the "audit order issue" in 7.2.9, but not quite sure what that means
in lieu of atomic command execution.
<blockquote TYPE=CITE>&nbsp;
<br><tt>&nbsp;&nbsp; 7.1.5,&nbsp;&nbsp;&nbsp;&nbsp; Text allows CHOOSE
for&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Change ABNF:</tt>
<br><tt>&nbsp;&nbsp; B.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; property
values in&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
propertyParm = pkgdName</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
TerminationStateDesc, but&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ( "$" / parmValue)</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ABNF does not.</tt>
<br><tt>&nbsp;&nbsp; 7.1.6,&nbsp;&nbsp;&nbsp;&nbsp; Text indicates use
of "true"&nbsp;&nbsp;&nbsp; Add comment in B.2 that</tt>
<br><tt>&nbsp;&nbsp; B.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and
"false" values while ABNF&nbsp;&nbsp; "true" in text</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
uses "on" and "off"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
corresponds to "on" in</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ABNF, and "false"</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
corresponds to "off".</tt>
<br><tt>&nbsp;&nbsp; 7.1.8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Last bulleted
item should&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Add "loopback".</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
include "loopback" in list of</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
possible states.</tt></blockquote>
Just to clarify:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Last bulleted
item in the second last bullet list.
<blockquote TYPE=CITE>&nbsp;
<p><tt>Taylor&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Standards Track -- Expires Sep 2000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
5</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Megaco/H.248 Corrections&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
March 2000</tt>
<p><tt>&nbsp;&nbsp; 7.1.9&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; EventDM is part
of syntax but&nbsp;&nbsp; Add text: "If a digit</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
not mentioned in section.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; map is required
in the</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
EventsDescriptor,</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
EventDM is used to carry</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
either the name or the</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
value of the digit map.</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
See section 7.1.14."</tt></blockquote>
When is a digit map required in the EventsDescriptor ?
<blockquote TYPE=CITE>&nbsp;
<br><tt>&nbsp;&nbsp; 7.1.9&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Case 1, step 2(a)
is both&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fix separation of</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
incorrectly formulated and&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; paragraphs.&nbsp;
Change step</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
incorrectly formatted.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
2(a) to read: "While</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Existing logic may result in&nbsp;&nbsp;&nbsp; waiting for a new</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
an infinite loop.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
EventsDescriptor, any</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
events detected which</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
appear in the current</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
EventsBufferDescriptor</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
will be placed in the</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
EventBuffer.&nbsp; When a new</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
EventDescriptor is</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
received, event</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
processing repeats from</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
step 1."</tt>
<br><tt>&nbsp;&nbsp; 7.1.13&nbsp;&nbsp;&nbsp;&nbsp; Missing "extension"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Add missing component.</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
component.</tt>
<br><tt>&nbsp;&nbsp; 7.1.14&nbsp;&nbsp;&nbsp;&nbsp; Item 5 in second numbered&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Add the words "and it</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
list&nbsp; understates conditions&nbsp;&nbsp;&nbsp; has been fully matched"</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
for digit map completion when&nbsp;&nbsp; to the existing sentence</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
single candidate remains.</tt>
<p><tt>&nbsp;&nbsp; 7.1.18&nbsp;&nbsp;&nbsp;&nbsp; Third bullet attached
to&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Delete the clause ";</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
third para: says loopback&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; loopbacks
are created by</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
achieved by manipulating&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; setting
the</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
TerminationMode, which no&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TerminationMode"</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
longer has that name.</tt>
<br><tt>&nbsp;&nbsp; 7.2.5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fails to indicate
what&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Add the following
text:</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
AuditValue for&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
"EventBuffer returns the</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
EventBufferDescriptor returns&nbsp;&nbsp; set of events and</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
associated parameter</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
values currently enabled</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
in the</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
EventBufferDescriptor."</tt>
<br><tt>&nbsp;&nbsp; 7.2.5,&nbsp;&nbsp;&nbsp;&nbsp; Text and ASN.1 allow
return&nbsp;&nbsp;&nbsp;&nbsp; Fix production</tt>
<br><tt>&nbsp;&nbsp; B.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of results
involving multiple&nbsp;&nbsp; contextTerminationAudit</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
contexts, but ABNF does not.&nbsp;&nbsp;&nbsp; by allowing return of</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
list of context-specific</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
results as an</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
alternative.</tt>
<p><tt>Taylor&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Standards Track -- Expires Sep 2000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
6</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Megaco/H.248 Corrections&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
March 2000</tt>
<p><tt>&nbsp;&nbsp; 7.2.5,&nbsp;&nbsp;&nbsp;&nbsp; Does not indicate how
an&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Change syntax of</tt>
<br><tt>&nbsp;&nbsp; A.2,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; audit of
digit maps returns&nbsp;&nbsp;&nbsp;&nbsp; DigitMapDescriptor to</tt>
<br><tt>&nbsp;&nbsp; B.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; unnamed
digit maps.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
allow return of unnamed</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
digit maps per John</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Seger suggestion ("[Fwd:</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Issues In v16 Draft]",</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Wed 15/03/00).</tt>
<br><tt>&nbsp;&nbsp; 7.2.6&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fails to indicate
what</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
AuditCapabilities for&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
"EventBuffer returns the</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Add the following text:</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
EventBufferDescriptor returns&nbsp;&nbsp; same information as</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Events."</tt></blockquote>
Not sure that's entirely accurate since EventBuffer is a sequence of Observed
Events
<blockquote TYPE=CITE>&nbsp;
<br><tt>&nbsp;&nbsp; 7.2.6,&nbsp;&nbsp;&nbsp;&nbsp; Inconsistency regarding&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Add comment to B.2</tt>
<br><tt>&nbsp;&nbsp; B.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; permissibility
of DigitMap or&nbsp;&nbsp; "auditItem" production</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Packages as capability audit&nbsp;&nbsp;&nbsp; indicating that DigitMap</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
items.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
and Packages are not</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
allowed in the</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
AuditCapabilities</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
command.</tt></blockquote>
I still don't understand how digit maps can apply to all terminations,
regardless of type (e.g. consider video)
<blockquote TYPE=CITE>&nbsp;
<br><tt>&nbsp;&nbsp; 7.2.8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Paragraph beginning
"A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Add text to the</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ServiceChange Command&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
offending sentence, so</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
specifying the Root..."&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
that it reads:</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
immediately following the&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "Acknowledgement
of the</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
description of ServiceChange&nbsp;&nbsp;&nbsp; ServiceChange Command</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Descriptor parameters&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
completes the</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
erroneously states that the&nbsp;&nbsp;&nbsp;&nbsp; registration process,</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
response to the ServiceChange&nbsp;&nbsp; except when the MGC has</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
command terminates the&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
returned an alternative</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
registration process.&nbsp; This&nbsp;&nbsp;&nbsp;&nbsp; ServiceChangeMgcId
as</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
is so only if the response&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; described in the
next</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
does not specify an alternate&nbsp;&nbsp; paragraph."</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
MGC.</tt>
<p><tt>&nbsp;&nbsp; 7.3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Text
for error code 403&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Change
text to "Syntax</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
should be consistent with&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; error in</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
that for 404 and 405.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
TransactionRequest"</tt>
<p><tt>&nbsp;&nbsp; 8.2.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Final para has
wrong text for&nbsp;&nbsp; Change to "Syntax Error</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
error code 442.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
in Command"</tt>
<p><tt>&nbsp;&nbsp; 11.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Second paragraph
last&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Restore
original</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
sentence inadvertently&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
sentence: "If the MG is</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
modified -- duplicates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
unable to establish a</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
material in 11.3.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
control relationship</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
with any MGC, it shall</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
wait a random amount of</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
time as described in</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Section 9.2 and then</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
start contacting its</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
primary, and if</tt></blockquote>
First paragraph actually.
<blockquote TYPE=CITE>&nbsp;
<p><tt>Taylor&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Standards Track -- Expires Sep 2000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
7</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Megaco/H.248 Corrections&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
March 2000</tt>
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
necessary, its secondary</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
MGCs again."</tt>
<p><tt>&nbsp;&nbsp; 11.4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Second para:
wrong MG is&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Change fourth sentence</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
specified as the one to be&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to refer to "secondary</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
used after failover.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
MG" rather than "primary</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
MG".</tt>
<br><tt>&nbsp;&nbsp; 12.1.4&nbsp;&nbsp;&nbsp;&nbsp; Note says that default&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Add TO signals to note.</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
duration should be specified</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
for BR signals.&nbsp; This also</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
applies to TO signals.</tt>
<br><tt>&nbsp;&nbsp; A.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LocalControlDescriptor
still</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
contains reserve rather than&nbsp;&nbsp;&nbsp; separate reserveValue</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
reserveValue and&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
and reserveGroup</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Replace reserve with</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
reserveGroup.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Booleans.</tt>
<p><tt>&nbsp;&nbsp; A.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Assigned
object identifier&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Add object identifier</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
missing.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
line with content</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
"itu-t recommendation h</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
248 media-gateway-</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
control(0)"</tt>
<br><tt>&nbsp;&nbsp; B.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Syntax
for parmValue and</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
VALUE together make parsing&nbsp;&nbsp;&nbsp;&nbsp; in alternativeValue
by</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Replace range notation</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
of range ambiguous.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
"LSBRKT VALUE COLON</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
VALUE RSBRKT"</tt>
<br><tt>&nbsp;&nbsp; B.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Error
in syntax for</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
digitMapDescriptor: value&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; digitMapDescriptor
=</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Change production:</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
meant to be optional.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
DigitMapToken EQUAL</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
digitMapName</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[ LBRKT digitMapValue</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
RBRKT ]</tt>
<br><tt>&nbsp;&nbsp; B.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; VersionToken
not defined.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Add ABNF:</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
VersionToken =</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
("Version" / "V")</tt>
<br><tt>&nbsp;&nbsp; B.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DiscardToken
not used.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Delete
production.</tt>
<br><tt>&nbsp;&nbsp; C.9&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ITC
has reference to missing&nbsp;&nbsp;&nbsp; Delete reference.</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
note 2</tt>
<p><tt>&nbsp;&nbsp; C.9&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Not clear
that Q.931 Bearer&nbsp;&nbsp;&nbsp;&nbsp; Specify that values are</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Capability IE rather than Low&nbsp;&nbsp; those valid for Bearer</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Layer Compatibility IE is&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Capability
IE</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
being used.</tt>
<p><tt>Taylor&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Standards Track -- Expires Sep 2000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
8</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Megaco/H.248 Corrections&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
March 2000</tt>
<p><tt>&nbsp;&nbsp; D.1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Even
in the case of handoff&nbsp;&nbsp;&nbsp;&nbsp; In the last sentence of</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
or failover, the originating&nbsp;&nbsp;&nbsp; the first paragraph,</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
MGC needs confirmation that&nbsp;&nbsp;&nbsp;&nbsp; delete the excepting</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
its command was received.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; clause, so
that the</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
sentence reads:</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
"Responses must be sent</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
to the address and port</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
from which the</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
corresponding commands</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
were sent."</tt>
<br><tt>&nbsp;&nbsp; D.1.1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Second para last
sentence</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
provides a procedural</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
reference to 8.2.3.&nbsp; Should</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
refer to UDP-specific</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Add reference to D.1.4.</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
procedures.</tt>
<p><tt>&nbsp;&nbsp; D.1.4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; First paragraph,
last</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
sentence talks about when to&nbsp;&nbsp;&nbsp; SHOULD send this</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
send the Transaction Pending&nbsp;&nbsp;&nbsp; response if they receive</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
response.&nbsp; When UDP/ALF is in&nbsp;&nbsp; a repetition of a</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
use, the originator of a&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; transaction
that is</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
transaction may repeat it&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; still being
executed."</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
because it has not received</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
an acknowledgement that the</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
transaction was received.&nbsp; An</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
appropriate response to a</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
duplicate transaction which</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
is still being processed is</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
to return Transaction</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Add the sentence: "They</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Pending.</tt>
<p><tt>&nbsp;&nbsp; D.1.5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Last paragraph
is equivocal&nbsp;&nbsp;&nbsp;&nbsp; Change the two sentences</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
about what&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
following the phrase "_</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ServiceChangeReason to use&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and it begins
its</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
when recovering from loss of&nbsp;&nbsp;&nbsp; recovery process" to</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
contact; it must always be&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; read as follows:
"The MG</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
"Disconnected".&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
shall use a</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ServiceChange with</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ServiceChangeMethod set</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
to disconnected so that</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
the new MGC will be</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
aware that the MG lost</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
one or more</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
transactions."</tt>
<br><tt>&nbsp;&nbsp; E.6.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "Long duration
event&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Replace with "Z".</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
modifier" is shown as "L" in</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
parameter DigitString --</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
should be "Z".</tt>
<p><tt>Taylor&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Standards Track -- Expires Sep 2000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
9</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Megaco/H.248 Corrections&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
March 2000</tt>
<p><tt>&nbsp;&nbsp; Appx&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Step 20 fails
to show a&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Add the following
to the</tt>
<br><tt>&nbsp;&nbsp; A.1.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; returned&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Descriptor</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
TerminationStateDescriptor&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; preceding the
line</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
"Stream = 1_":</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
"TerminationState {</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ServiceStates =</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
InService,</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
EventBufferControl = OFF</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
},"</tt>
<p><tt>6. Security Considerations</tt>
<p><tt>&nbsp;&nbsp; This draft is a supplement to [2], which contains the
required</tt>
<br><tt>&nbsp;&nbsp; security section.</tt>
<p><tt>7. References</tt>
<p><tt>&nbsp;&nbsp; [1] RFC 2026</tt>
<br><tt>&nbsp;&nbsp; [2] draft-ietf-megaco-protocol-07.txt</tt>
<br><tt>&nbsp;&nbsp; [3] RFC 2119</tt>
<p><tt>8. Acknowledgments</tt>
<p><tt>&nbsp;&nbsp; This draft records the contributions of a number of
people on the</tt>
<br><tt>&nbsp;&nbsp; Megaco list who took the time to read the Megaco/H.248
draft with</tt>
<br><tt>&nbsp;&nbsp; care and attention.&nbsp; Thanks to all of them.</tt>
<p><tt>9. Author's Addresses</tt>
<p><tt>&nbsp;&nbsp; Tom Taylor</tt>
<br><tt>&nbsp;&nbsp; Nortel Networks</tt>
<br><tt>&nbsp;&nbsp; P.O. Box 3511, Station C</tt>
<br><tt>&nbsp;&nbsp; Ottawa, Ontario, Canada K1Y 4P7</tt>
<br><tt>&nbsp;&nbsp; Phone: +1 613 736 0961</tt>
<br><tt>&nbsp;&nbsp; Email: taylor@nortelnetworks.com</tt>
<p><tt>Taylor&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Standards Track -- Expires Sep 2000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
10</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Megaco/H.248 Corrections&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
March 2000</tt>
<p><tt>Full Copyright Statement</tt>
<p><tt>&nbsp;&nbsp; "Copyright (C) The Internet Society (date). All Rights
Reserved.</tt>
<br><tt>&nbsp;&nbsp; This document and translations of it may be copied
and furnished to</tt>
<br><tt>&nbsp;&nbsp; others, and derivative works that comment on or otherwise
explain it</tt>
<br><tt>&nbsp;&nbsp; or assist in its implmentation may be prepared, copied,
published</tt>
<br><tt>&nbsp;&nbsp; and distributed, in whole or in part, without restriction
of any</tt>
<br><tt>&nbsp;&nbsp; kind, provided that the above copyright notice and
this paragraph</tt>
<br><tt>&nbsp;&nbsp; are included on all such copies and derivative works.
However, this</tt>
<br><tt>&nbsp;&nbsp; document itself may not be modified in any way, such
as by removing</tt>
<br><tt>&nbsp;&nbsp; the copyright notice or references to the Internet
Society or other</tt>
<br><tt>&nbsp;&nbsp; Internet organizations, except as needed for the purpose
of</tt>
<br><tt>&nbsp;&nbsp; developing Internet standards in which case the procedures
for</tt>
<br><tt>&nbsp;&nbsp; copyrights defined in the Internet Standards process
must be</tt>
<br><tt>&nbsp;&nbsp; followed, or as required to translate it into other
languages.</tt>
<p><tt>&nbsp;&nbsp; 1&nbsp; Bradner, S., "Key words for use in RFCs to
Indicate Requirement</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Levels", BCP 14, RFC 2119, March
1997</tt>
<p><tt>Taylor&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Standards Track -- Expires Sep 2000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
11</tt></blockquote>
<tt>--</tt>
<br><tt>Flemming Andreasen&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Phone: +1 732 452 1667</tt>
<br><tt>Cisco Systems&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Fax:&nbsp;&nbsp; +1 240 359 5839</tt>
<br>&nbsp;</html>

--------------7B7E2968A6D6E8FD3380B2E0--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Apr  5 18:29:13 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17172
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 5 Apr 2000 18:29:12 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FB1C28C0@standards.nortelnetworks.com>; Wed, 5 Apr 2000 18:23:03 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 119717 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 5 Apr 2000 18:21:38 -0400
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.62091B30@standards.nortelnetworks.com>; Wed, 5 Apr 2000 18:11:37
          -0400
Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com
          (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id PAA15002; Wed, 5 Apr 2000
          15:10:35 -0700 (PDT)
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <C51ED84B6F47D211917A0000F8BCBD11033227DB@zcard00g.ca.nortel.com>
Content-Type: multipart/alternative;
              boundary="------------789E3FC028C622D18C586FFD"
Message-ID:  <38EBE4AC.51068B70@cisco.com>
Date:         Wed, 5 Apr 2000 18:13:16 -0700
Reply-To: Flemming Andreasen <fandreas@CISCO.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Flemming Andreasen <fandreas@CISCO.COM>
Organization: Cisco Systems
Subject:      Re: Summary of Issues Raised On the List
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--------------789E3FC028C622D18C586FFD
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Tom

Some comments below. In addition to what you have here, I think we still have
one or two open issues with the digit maps - I'll resend the latest e-mail
exchange we had on this.

Regards

            Flemming



Tom-PT Taylor wrote:

> Attached please find a summary of the issues raised on the list.  The
> contents should be self-evident.  Please pay special attention to section 4:
> we MUST close off on these issues within the next week so we can end Last
> Call in timely fashion.
>  <<errata.txt>>
>
> Tom Taylor
> Advisor -- Emerging Carrier IP Standards
> E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
> Phone and FAX: +1 613 736 0961
>
> Media Gateway Control                                       P.T. Taylor
> Internet Draft                                          Nortel Networks
> Document: draft-ietf-megaco-errata-00.txt                    March 2000
> Category: Standards Track
>
>       Corrections To the Determined Megaco/H.248 Protocol Document
>
> Status of this Memo
>
>    This document is an Internet-Draft and is in full conformance with
>    all provisions of Section 10 of RFC2026 [1].
>
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF), its areas, and its working groups. Note that
>    other groups may also distribute working documents as Internet-
>    Drafts. Internet-Drafts are draft documents valid for a maximum of
>    six months and may be updated, replaced, or obsoleted by other
>    documents at any time. It is inappropriate to use Internet- Drafts
>    as reference material or to cite them other than as "work in
>    progress."
>    The list of current Internet-Drafts can be accessed at
>    http://www.ietf.org/ietf/1id-abstracts.txt
>    The list of Internet-Draft Shadow Directories can be accessed at
>    http://www.ietf.org/shadow.html.
>
> 1. Abstract
>
>    This document records the errors found in the draft Megaco/H.248
>    protocol document [2], along with the changes proposed in the text
>    of that document to resolve them. After joint IETF/ITU-T Study Group
>    16 approval of these corrections, they will be incorporated into the
>    final decided version of H.248 and the corresponding Megaco protocol
>    RFC.
>
> 2. Conventions used in this document
>
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
>    this document are to be interpreted as described in RFC-2119 [1].
>
> Taylor           Standards Track -- Expires Sep 2000                 1
>                        Megaco/H.248 Corrections             March 2000
>
> 3. Issues Not Found To Require Changes
>
>    This section lists a few of the issues raised on the Megaco list
>    which were found not to require a change in [2].  There were a
>    number of other such issues which may be recorded here as a matter
>    of record pending completion of IESG Last Call.  This section will
>    be deleted from the final document submitted into the ITU-T Study
>    Group 16 decision process.  All section numbers are from [2].
>
>    Section    Problem                         Resolution
>    7.1.9      Discarding of buffered events   No change.  Reasonable
>               when EventBufferControl is      case for making a
>               changed to OFF is               different decision from
>               inconsistent with provision     the one made in Geneva,
>               for notification of multiple    but not actually an
>               events at once in latter        error.
>               state.
>
>    7.1.11     Last bullet list and            Not an error or
>               preceding sentence simply       ambiguity, no action.
>               recapitulate definition of
>               KeepActive flag.

I read it slightly different as it seems to imply "KeepActive" semantics,
regardless of whether the flag is present or not (not an issue, just want to
clarify)

>
>    7.2.5,     Relationship between text and   Clarification, not
>    7.2.6      representation of wildcarded    ambiguity or error.
>               audit request is not clear.
>
> 4. Issues Identified But Not Yet Resolved
>
>    This section, as its title implies, contains issues which have been
>    identified in discussion on the list but for which a final
>    resolution has not been achieved.  All of these issues must be
>    resolved or moved to the previous section before Last Call can be
>    declared complete.  Hence this section will be deleted before this
>    document is submitted to the IESG for final approval.
>
>    Section                              Issue
>
>    6.2.2      Not clear what wildcard union responses look like.

Proposed resolution:        Add an example somewhere.

>
>
>    7.1.1      Third para (discussing unspecified parameters): not clear
>               which parameters are mandatory.

Proposed resolution:    Add a table.

>
>
> Taylor           Standards Track -- Expires Sep 2000                 2
>                        Megaco/H.248 Corrections             March 2000
>
>    7.1.9      Not clear whether events trigger side effects (e.g.
>               signal termination) at time of detection, at time of
>               processing (whether or not in active Events Descriptor)
>               or at time of notification.

Proposed resolution:    At time of processing, i.e. if an event specified in the
active Events Descriptor is processed, signals on the termination stop (unless
KeepActive is specified).


>
>
>    7.1.14     Not clear whether non-matched events trigger side effects
>               at time of processing against digit map or when processed
>               against active Events Descriptor following digit map
>               completion event detection.

I didn't follow that - can you elaborate ?

>
>
>    7.1.17     Not clear whether AuditValue of ObservedEventsDescriptor
>               reports events captured in current dial string of active
>               digit map.

Proposed solution:        Given the way digits collected according to digit maps
will be reported in the end, it would seem consistent to not report the current
dial string. Alternatively, I guess you could include a DigitMap Completion
event with a digitstring, but without a Termination Method.

>
>
>    7.3        There should be no error        Delete codes 404, 405,
>               responses to TransactionReply   461-467
>               or TransactionPending, lest
>               they create response loops.

Agreed.

>
>
>    8          Command execution should be     Not clear what "atomic"
>               specified as atomic.            means, particularly
>                                               where events and signals
>                                               are concerned.

Proposed resolution:        Get Brian Rosen to type up something :-)

>

>    12.2,      Text indicates that statistics can have the sub-list data
>    B.2        type, but ABNF does not support that.
>
>    B.2        Syntax for parmValue confounds over-specification and
>               sub-lists.
>
>    C.8        Length of GIT is wrong.
>
> Taylor           Standards Track -- Expires Sep 2000                 3
>                        Megaco/H.248 Corrections             March 2000
>
>    D.1.4      Second para: transaction originator may not have received
>               TransactionPending response(s) because they were lost,
>               and may therefore not know that responder is expecting
>               immediate acknowledgement of the TransactionReply.

Proposed resolution:        Add an optional field in the TransactionReply
allowing the responder to indicate if an immediate ack is expected or not.

>
>
>    E.1.2      Granularity of signal completion event is too coarse as a
>               mechanism to detect signalling failures.

Proposed resolution:    Define an EventsDescriptor parameterfor the Signal
Completion event allowing the MGC to specify which Termination Methods it's
interested in.

>
>
>    E.9.2      Stated hook state reporting behaviour has race condition
>               where same transition could be reported twice.

Proposed resolution:    Add the following event parameters for the onhook and
offhook events:
1. No expected hook-state, just report next transition
2. Event indicates expected hook-state, report if hook-state differs (current
text)
3. Event indicates expected hook-state, let command fail if actual hook-state
differs.


>
>
>    E.10.2     Wording of condition for generating cmp event with
>               "success" does not cover case where test also requires
>               successful removal of tone.

(actually E.10.5)

Proposed resolution:        Replace "If the return tone is detected before the
signal times out" with "If the test succeeds before the signal times out"


>
>
> 5. Errors For Which Corrections Are Stated
>
>    This is the only section which will remain in this document after
>    the IESG has approved the combination of [2] and the corrections
>    stated below.  It describes the errors and ambiguities which have
>    been found in [2], along with the corrections they require.
>
>    Section    Issue                           Resolution
>
>    2          Q.724 is not used.              Delete from list of
>                                               references.
>    4          BRI is not used.                Delete from list of
>                                               abbreviations.
>    2, C       Leave Recs. referred to in      Do that.
>               Annex C undated, implying
>               latest issue.
>
> Taylor           Standards Track -- Expires Sep 2000                 4
>                        Megaco/H.248 Corrections             March 2000
>
>    6.2.4      Says that property values set   Add text to first para
>               in Null context are             third sentence: "Most
>               remembered and reinstated       properties have default
>               when termination returns to     values, which are
>               Null.  Contradicts latest       explicitly defined in
>               text in 7.2.3.                  this standard or set by
>                                               provisioning."  Delete
>                                               first para fourth
>                                               sentence, which read:
>                                               "The default value of a
>                                               property of a physical
>                                               Termination can be
>                                               changed by setting it to
>                                               a different value when
>                                               the Termination is in
>                                               the null Context."
>    6.2.4      DigitMap entry in table makes   Change existing text to
>               explicit reference to DTMF      new one as follows:
>               tones.                          "Defines patterns
>                                               against which sequences
>                                               of a specified set of
>                                               events are to be matched
>                                               so they can be reported
>                                               as a group rather than
>                                               singly."
>    7.1,       The order in which              Add text stating that
>    A.2        descriptors are processed       descriptors are
>               within a command matters, but   processed in the order
>               is not clear.  Moreover, it     in which they are
>               is fixed in the ASN.1 but       provided.  Change ASN.1
>               variable in the ABNF.           in Annex A.2 to impose
>                                               ordering as suggested by
>                                               John Segers ("Descriptor
>                                               processing order", Wed
>                                               15/03/00)

Solves the "audit order issue" in 7.2.9, but not quite sure what that means in
lieu of atomic command execution.

>
>    7.1.5,     Text allows CHOOSE for          Change ABNF:
>    B.2        property values in              propertyParm = pkgdName
>               TerminationStateDesc, but       ( "$" / parmValue)
>               ABNF does not.
>    7.1.6,     Text indicates use of "true"    Add comment in B.2 that
>    B.2        and "false" values while ABNF   "true" in text
>               uses "on" and "off"             corresponds to "on" in
>                                               ABNF, and "false"
>                                               corresponds to "off".
>    7.1.8      Last bulleted item should       Add "loopback".
>               include "loopback" in list of
>               possible states.

Just to clarify:        Last bulleted item in the second last bullet list.

>
>
> Taylor           Standards Track -- Expires Sep 2000                 5
>                        Megaco/H.248 Corrections             March 2000
>
>    7.1.9      EventDM is part of syntax but   Add text: "If a digit
>               not mentioned in section.       map is required in the
>                                               EventsDescriptor,
>                                               EventDM is used to carry
>                                               either the name or the
>                                               value of the digit map.
>                                               See section 7.1.14."

When is a digit map required in the EventsDescriptor ?

>
>    7.1.9      Case 1, step 2(a) is both       Fix separation of
>               incorrectly formulated and      paragraphs.  Change step
>               incorrectly formatted.          2(a) to read: "While
>               Existing logic may result in    waiting for a new
>               an infinite loop.               EventsDescriptor, any
>                                               events detected which
>                                               appear in the current
>                                               EventsBufferDescriptor
>                                               will be placed in the
>                                               EventBuffer.  When a new
>                                               EventDescriptor is
>                                               received, event
>                                               processing repeats from
>                                               step 1."
>    7.1.13     Missing "extension"             Add missing component.
>               component.
>    7.1.14     Item 5 in second numbered       Add the words "and it
>               list  understates conditions    has been fully matched"
>               for digit map completion when   to the existing sentence
>               single candidate remains.
>
>    7.1.18     Third bullet attached to        Delete the clause ";
>               third para: says loopback       loopbacks are created by
>               achieved by manipulating        setting the
>               TerminationMode, which no       TerminationMode"
>               longer has that name.
>    7.2.5      Fails to indicate what          Add the following text:
>               AuditValue for                  "EventBuffer returns the
>               EventBufferDescriptor returns   set of events and
>                                               associated parameter
>                                               values currently enabled
>                                               in the
>                                               EventBufferDescriptor."
>    7.2.5,     Text and ASN.1 allow return     Fix production
>    B.2        of results involving multiple   contextTerminationAudit
>               contexts, but ABNF does not.    by allowing return of
>                                               list of context-specific
>                                               results as an
>                                               alternative.
>
> Taylor           Standards Track -- Expires Sep 2000                 6
>                        Megaco/H.248 Corrections             March 2000
>
>    7.2.5,     Does not indicate how an        Change syntax of
>    A.2,       audit of digit maps returns     DigitMapDescriptor to
>    B.2        unnamed digit maps.             allow return of unnamed
>                                               digit maps per John
>                                               Seger suggestion ("[Fwd:
>                                               Issues In v16 Draft]",
>                                               Wed 15/03/00).
>    7.2.6      Fails to indicate what
>               AuditCapabilities for           "EventBuffer returns the
>                                               Add the following text:
>               EventBufferDescriptor returns   same information as
>                                               Events."

Not sure that's entirely accurate since EventBuffer is a sequence of Observed
Events

>
>    7.2.6,     Inconsistency regarding         Add comment to B.2
>    B.2        permissibility of DigitMap or   "auditItem" production
>               Packages as capability audit    indicating that DigitMap
>               items.                          and Packages are not
>                                               allowed in the
>                                               AuditCapabilities
>                                               command.

I still don't understand how digit maps can apply to all terminations,
regardless of type (e.g. consider video)

>
>    7.2.8      Paragraph beginning "A          Add text to the
>               ServiceChange Command           offending sentence, so
>               specifying the Root..."         that it reads:
>               immediately following the       "Acknowledgement of the
>               description of ServiceChange    ServiceChange Command
>               Descriptor parameters           completes the
>               erroneously states that the     registration process,
>               response to the ServiceChange   except when the MGC has
>               command terminates the          returned an alternative
>               registration process.  This     ServiceChangeMgcId as
>               is so only if the response      described in the next
>               does not specify an alternate   paragraph."
>               MGC.
>
>    7.3        Text for error code 403         Change text to "Syntax
>               should be consistent with       error in
>               that for 404 and 405.           TransactionRequest"
>
>    8.2.2      Final para has wrong text for   Change to "Syntax Error
>               error code 442.                 in Command"
>
>    11.2       Second paragraph last           Restore original
>               sentence inadvertently          sentence: "If the MG is
>               modified -- duplicates          unable to establish a
>               material in 11.3.               control relationship
>                                               with any MGC, it shall
>                                               wait a random amount of
>                                               time as described in
>                                               Section 9.2 and then
>                                               start contacting its
>                                               primary, and if

First paragraph actually.

>
>
> Taylor           Standards Track -- Expires Sep 2000                 7
>                        Megaco/H.248 Corrections             March 2000
>
>                                               necessary, its secondary
>                                               MGCs again."
>
>    11.4       Second para: wrong MG is        Change fourth sentence
>               specified as the one to be      to refer to "secondary
>               used after failover.            MG" rather than "primary
>                                               MG".
>    12.1.4     Note says that default          Add TO signals to note.
>               duration should be specified
>               for BR signals.  This also
>               applies to TO signals.
>    A.2        LocalControlDescriptor still
>               contains reserve rather than    separate reserveValue
>               reserveValue and                and reserveGroup
>                                               Replace reserve with
>               reserveGroup.                   Booleans.
>
>    A.2        Assigned object identifier      Add object identifier
>               missing.                        line with content
>                                               "itu-t recommendation h
>                                               248 media-gateway-
>                                               control(0)"
>    B.2        Syntax for parmValue and
>               VALUE together make parsing     in alternativeValue by
>                                               Replace range notation
>               of range ambiguous.             "LSBRKT VALUE COLON
>                                               VALUE RSBRKT"
>    B.2        Error in syntax for
>               digitMapDescriptor: value       digitMapDescriptor =
>                                               Change production:
>               meant to be optional.           DigitMapToken EQUAL
>                                               digitMapName
>                                               [ LBRKT digitMapValue
>                                               RBRKT ]
>    B.2        VersionToken not defined.       Add ABNF:
>                                               VersionToken =
>                                               ("Version" / "V")
>    B.2        DiscardToken not used.          Delete production.
>    C.9        ITC has reference to missing    Delete reference.
>               note 2
>
>    C.9        Not clear that Q.931 Bearer     Specify that values are
>               Capability IE rather than Low   those valid for Bearer
>               Layer Compatibility IE is       Capability IE
>               being used.
>
> Taylor           Standards Track -- Expires Sep 2000                 8
>                        Megaco/H.248 Corrections             March 2000
>
>    D.1        Even in the case of handoff     In the last sentence of
>               or failover, the originating    the first paragraph,
>               MGC needs confirmation that     delete the excepting
>               its command was received.       clause, so that the
>                                               sentence reads:
>                                               "Responses must be sent
>                                               to the address and port
>                                               from which the
>                                               corresponding commands
>                                               were sent."
>    D.1.1      Second para last sentence
>               provides a procedural
>               reference to 8.2.3.  Should
>               refer to UDP-specific
>                                               Add reference to D.1.4.
>               procedures.
>
>    D.1.4      First paragraph, last
>               sentence talks about when to    SHOULD send this
>               send the Transaction Pending    response if they receive
>               response.  When UDP/ALF is in   a repetition of a
>               use, the originator of a        transaction that is
>               transaction may repeat it       still being executed."
>               because it has not received
>               an acknowledgement that the
>               transaction was received.  An
>               appropriate response to a
>               duplicate transaction which
>               is still being processed is
>               to return Transaction
>                                               Add the sentence: "They
>               Pending.
>
>    D.1.5      Last paragraph is equivocal     Change the two sentences
>               about what                      following the phrase "_
>               ServiceChangeReason to use      and it begins its
>               when recovering from loss of    recovery process" to
>               contact; it must always be      read as follows: "The MG
>               "Disconnected".                 shall use a
>                                               ServiceChange with
>                                               ServiceChangeMethod set
>                                               to disconnected so that
>                                               the new MGC will be
>                                               aware that the MG lost
>                                               one or more
>                                               transactions."
>    E.6.2      "Long duration event            Replace with "Z".
>               modifier" is shown as "L" in
>               parameter DigitString --
>               should be "Z".
>
> Taylor           Standards Track -- Expires Sep 2000                 9
>                        Megaco/H.248 Corrections             March 2000
>
>    Appx       Step 20 fails to show a         Add the following to the
>    A.1.2      returned                        Media Descriptor
>               TerminationStateDescriptor      preceding the line
>                                               "Stream = 1_":
>                                               "TerminationState {
>                                               ServiceStates =
>                                               InService,
>                                               EventBufferControl = OFF
>                                               },"
>
> 6. Security Considerations
>
>    This draft is a supplement to [2], which contains the required
>    security section.
>
> 7. References
>
>    [1] RFC 2026
>    [2] draft-ietf-megaco-protocol-07.txt
>    [3] RFC 2119
>
> 8. Acknowledgments
>
>    This draft records the contributions of a number of people on the
>    Megaco list who took the time to read the Megaco/H.248 draft with
>    care and attention.  Thanks to all of them.
>
> 9. Author's Addresses
>
>    Tom Taylor
>    Nortel Networks
>    P.O. Box 3511, Station C
>    Ottawa, Ontario, Canada K1Y 4P7
>    Phone: +1 613 736 0961
>    Email: taylor@nortelnetworks.com
>
> Taylor           Standards Track -- Expires Sep 2000                10
>                        Megaco/H.248 Corrections             March 2000
>
> Full Copyright Statement
>
>    "Copyright (C) The Internet Society (date). All Rights Reserved.
>    This document and translations of it may be copied and furnished to
>    others, and derivative works that comment on or otherwise explain it
>    or assist in its implmentation may be prepared, copied, published
>    and distributed, in whole or in part, without restriction of any
>    kind, provided that the above copyright notice and this paragraph
>    are included on all such copies and derivative works. However, this
>    document itself may not be modified in any way, such as by removing
>    the copyright notice or references to the Internet Society or other
>    Internet organizations, except as needed for the purpose of
>    developing Internet standards in which case the procedures for
>    copyrights defined in the Internet Standards process must be
>    followed, or as required to translate it into other languages.
>
>    1  Bradner, S., "Key words for use in RFCs to Indicate Requirement
>       Levels", BCP 14, RFC 2119, March 1997
>
> Taylor           Standards Track -- Expires Sep 2000                11

--
Flemming Andreasen                Phone: +1 732 452 1667
Cisco Systems                     Fax:   +1 240 359 5839


--------------789E3FC028C622D18C586FFD
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi Tom
<p>Some comments below. In addition to what you have here, I think we still
have one or two open issues with the digit maps - I'll resend the latest
e-mail exchange we had on this.
<p>Regards
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Flemming
<br>&nbsp;
<br>&nbsp;
<p><tt>Tom-PT Taylor wrote:</tt>
<blockquote TYPE=CITE><tt>Attached please find a summary of the issues
raised on the list.&nbsp; The</tt>
<br><tt>contents should be self-evident.&nbsp; Please pay special attention
to section 4:</tt>
<br><tt>we MUST close off on these issues within the next week so we can
end Last</tt>
<br><tt>Call in timely fashion.</tt>
<br><tt>&nbsp;&lt;&lt;errata.txt>></tt>
<p><tt>Tom Taylor</tt>
<br><tt>Advisor -- Emerging Carrier IP Standards</tt>
<br><tt>E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)</tt>
<br><tt>Phone and FAX: +1 613 736 0961</tt>
<p><tt>Media Gateway Control&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
P.T. Taylor</tt>
<br><tt>Internet Draft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Nortel Networks</tt>
<br><tt>Document: draft-ietf-megaco-errata-00.txt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
March 2000</tt>
<br><tt>Category: Standards Track</tt>
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Corrections To the Determined Megaco/H.248
Protocol Document</tt>
<p><tt>Status of this Memo</tt>
<p><tt>&nbsp;&nbsp; This document is an Internet-Draft and is in full conformance
with</tt>
<br><tt>&nbsp;&nbsp; all provisions of Section 10 of RFC2026 [1].</tt>
<p><tt>&nbsp;&nbsp; Internet-Drafts are working documents of the Internet
Engineering</tt>
<br><tt>&nbsp;&nbsp; Task Force (IETF), its areas, and its working groups.
Note that</tt>
<br><tt>&nbsp;&nbsp; other groups may also distribute working documents
as Internet-</tt>
<br><tt>&nbsp;&nbsp; Drafts. Internet-Drafts are draft documents valid
for a maximum of</tt>
<br><tt>&nbsp;&nbsp; six months and may be updated, replaced, or obsoleted
by other</tt>
<br><tt>&nbsp;&nbsp; documents at any time. It is inappropriate to use
Internet- Drafts</tt>
<br><tt>&nbsp;&nbsp; as reference material or to cite them other than as
"work in</tt>
<br><tt>&nbsp;&nbsp; progress."</tt>
<br><tt>&nbsp;&nbsp; The list of current Internet-Drafts can be accessed
at</tt>
<br><tt>&nbsp;&nbsp; <a href="http://www.ietf.org/ietf/1id-abstracts.txt">http://www.ietf.org/ietf/1id-abstracts.txt</a></tt>
<br><tt>&nbsp;&nbsp; The list of Internet-Draft Shadow Directories can
be accessed at</tt>
<br><tt>&nbsp;&nbsp; <a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>.</tt>
<p><tt>1. Abstract</tt>
<p><tt>&nbsp;&nbsp; This document records the errors found in the draft
Megaco/H.248</tt>
<br><tt>&nbsp;&nbsp; protocol document [2], along with the changes proposed
in the text</tt>
<br><tt>&nbsp;&nbsp; of that document to resolve them. After joint IETF/ITU-T
Study Group</tt>
<br><tt>&nbsp;&nbsp; 16 approval of these corrections, they will be incorporated
into the</tt>
<br><tt>&nbsp;&nbsp; final decided version of H.248 and the corresponding
Megaco protocol</tt>
<br><tt>&nbsp;&nbsp; RFC.</tt>
<p><tt>2. Conventions used in this document</tt>
<p><tt>&nbsp;&nbsp; The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT",</tt>
<br><tt>&nbsp;&nbsp; "SHOULD", "SHOULD NOT", "RECOMMENDED",&nbsp; "MAY",
and "OPTIONAL" in</tt>
<br><tt>&nbsp;&nbsp; this document are to be interpreted as described in
RFC-2119 [1].</tt>
<p><tt>Taylor&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Standards Track -- Expires Sep 2000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
1</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Megaco/H.248 Corrections&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
March 2000</tt>
<p><tt>3. Issues Not Found To Require Changes</tt>
<p><tt>&nbsp;&nbsp; This section lists a few of the issues raised on the
Megaco list</tt>
<br><tt>&nbsp;&nbsp; which were found not to require a change in [2].&nbsp;
There were a</tt>
<br><tt>&nbsp;&nbsp; number of other such issues which may be recorded
here as a matter</tt>
<br><tt>&nbsp;&nbsp; of record pending completion of IESG Last Call.&nbsp;
This section will</tt>
<br><tt>&nbsp;&nbsp; be deleted from the final document submitted into
the ITU-T Study</tt>
<br><tt>&nbsp;&nbsp; Group 16 decision process.&nbsp; All section numbers
are from [2].</tt>
<p><tt>&nbsp;&nbsp; Section&nbsp;&nbsp;&nbsp; Problem&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Resolution</tt>
<br><tt>&nbsp;&nbsp; 7.1.9&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Discarding of
buffered events&nbsp;&nbsp; No change.&nbsp; Reasonable</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
when EventBufferControl is&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; case for making
a</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
changed to OFF is&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
different decision from</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
inconsistent with provision&nbsp;&nbsp;&nbsp;&nbsp; the one made in Geneva,</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
for notification of multiple&nbsp;&nbsp;&nbsp; but not actually an</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
events at once in latter&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; error.</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
state.</tt>
<p><tt>&nbsp;&nbsp; 7.1.11&nbsp;&nbsp;&nbsp;&nbsp; Last bullet list and&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Not an error or</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
preceding sentence simply&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ambiguity,
no action.</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
recapitulate definition of</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
KeepActive flag.</tt></blockquote>
I read it slightly different as it seems to imply "KeepActive" semantics,
regardless of whether the flag is present or not (not an issue, just want
to clarify)
<blockquote TYPE=CITE>&nbsp;
<br><tt>&nbsp;&nbsp; 7.2.5,&nbsp;&nbsp;&nbsp;&nbsp; Relationship between
text and&nbsp;&nbsp; Clarification, not</tt>
<br><tt>&nbsp;&nbsp; 7.2.6&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; representation
of wildcarded&nbsp;&nbsp;&nbsp; ambiguity or error.</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
audit request is not clear.</tt>
<p><tt>4. Issues Identified But Not Yet Resolved</tt>
<p><tt>&nbsp;&nbsp; This section, as its title implies, contains issues
which have been</tt>
<br><tt>&nbsp;&nbsp; identified in discussion on the list but for which
a final</tt>
<br><tt>&nbsp;&nbsp; resolution has not been achieved.&nbsp; All of these
issues must be</tt>
<br><tt>&nbsp;&nbsp; resolved or moved to the previous section before Last
Call can be</tt>
<br><tt>&nbsp;&nbsp; declared complete.&nbsp; Hence this section will be
deleted before this</tt>
<br><tt>&nbsp;&nbsp; document is submitted to the IESG for final approval.</tt>
<p><tt>&nbsp;&nbsp; Section&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Issue</tt>
<p><tt>&nbsp;&nbsp; 6.2.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Not clear what
wildcard union responses look like.</tt></blockquote>
Proposed resolution:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Add an example
somewhere.
<blockquote TYPE=CITE>&nbsp;
<p><tt>&nbsp;&nbsp; 7.1.1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Third para (discussing
unspecified parameters): not clear</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
which parameters are mandatory.</tt></blockquote>
Proposed resolution:&nbsp;&nbsp;&nbsp; Add a table.
<blockquote TYPE=CITE>&nbsp;
<p><tt>Taylor&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Standards Track -- Expires Sep 2000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
2</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Megaco/H.248 Corrections&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
March 2000</tt>
<p><tt>&nbsp;&nbsp; 7.1.9&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Not clear whether
events trigger side effects (e.g.</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
signal termination) at time of detection, at time of</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
processing (whether or not in active Events Descriptor)</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
or at time of notification.</tt></blockquote>
Proposed resolution:&nbsp;&nbsp;&nbsp; At time of processing, i.e. if an
event specified in the active Events Descriptor is processed, signals on
the termination stop (unless KeepActive is specified).
<br>&nbsp;
<blockquote TYPE=CITE>&nbsp;
<p><tt>&nbsp;&nbsp; 7.1.14&nbsp;&nbsp;&nbsp;&nbsp; Not clear whether non-matched
events trigger side effects</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
at time of processing against digit map or when processed</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
against active Events Descriptor following digit map</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
completion event detection.</tt></blockquote>
I didn't follow that - can you elaborate ?
<blockquote TYPE=CITE>&nbsp;
<p><tt>&nbsp;&nbsp; 7.1.17&nbsp;&nbsp;&nbsp;&nbsp; Not clear whether AuditValue
of ObservedEventsDescriptor</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
reports events captured in current dial string of active</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
digit map.</tt></blockquote>
Proposed solution:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Given the
way digits collected according to digit maps will be reported in the end,
it would seem consistent to not report the current dial string. Alternatively,
I guess you could include a DigitMap Completion event with a digitstring,
but without a Termination Method.
<blockquote TYPE=CITE>&nbsp;
<p><tt>&nbsp;&nbsp; 7.3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; There
should be no error&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Delete codes
404, 405,</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
responses to TransactionReply&nbsp;&nbsp; 461-467</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
or TransactionPending, lest</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
they create response loops.</tt></blockquote>
Agreed.
<blockquote TYPE=CITE>&nbsp;
<p><tt>&nbsp;&nbsp; 8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Command execution should be&nbsp;&nbsp;&nbsp;&nbsp; Not clear what "atomic"</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
specified as atomic.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
means, particularly</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
where events and signals</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
are concerned.</tt></blockquote>
Proposed resolution:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Get Brian
Rosen to type up something :-)
<blockquote TYPE=CITE>&nbsp;</blockquote>

<blockquote TYPE=CITE><tt>&nbsp;&nbsp; 12.2,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Text indicates that statistics can have the sub-list data</tt>
<br><tt>&nbsp;&nbsp; B.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; type,
but ABNF does not support that.</tt>
<p><tt>&nbsp;&nbsp; B.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Syntax
for parmValue confounds over-specification and</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
sub-lists.</tt>
<p><tt>&nbsp;&nbsp; C.8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Length
of GIT is wrong.</tt>
<p><tt>Taylor&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Standards Track -- Expires Sep 2000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
3</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Megaco/H.248 Corrections&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
March 2000</tt>
<p><tt>&nbsp;&nbsp; D.1.4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Second para: transaction
originator may not have received</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
TransactionPending response(s) because they were lost,</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
and may therefore not know that responder is expecting</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
immediate acknowledgement of the TransactionReply.</tt></blockquote>
Proposed resolution:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Add an optional
field in the TransactionReply allowing the responder to indicate if an
immediate ack is expected or not.
<blockquote TYPE=CITE>&nbsp;
<p><tt>&nbsp;&nbsp; E.1.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Granularity of
signal completion event is too coarse as a</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
mechanism to detect signalling failures.</tt></blockquote>
Proposed resolution:&nbsp;&nbsp;&nbsp; Define an EventsDescriptor parameterfor
the Signal Completion event allowing the MGC to specify which Termination
Methods it's interested in.
<blockquote TYPE=CITE>&nbsp;
<p><tt>&nbsp;&nbsp; E.9.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Stated hook state
reporting behaviour has race condition</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
where same transition could be reported twice.</tt></blockquote>

<p><br>Proposed resolution:&nbsp;&nbsp;&nbsp; Add the following event parameters
for the onhook and offhook events:
<br>1. No expected hook-state, just report next transition
<br>2. Event indicates expected hook-state, report if hook-state differs
(current text)
<br>3. Event indicates expected hook-state, let command fail if actual
hook-state differs.
<br>&nbsp;
<blockquote TYPE=CITE>&nbsp;
<p><tt>&nbsp;&nbsp; E.10.2&nbsp;&nbsp;&nbsp;&nbsp; Wording of condition
for generating cmp event with</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
"success" does not cover case where test also requires</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
successful removal of tone.</tt></blockquote>
(actually E.10.5)
<p>Proposed resolution:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Replace
"If the return tone is detected before the signal times out" with "If the
test succeeds before the signal times out"
<br>&nbsp;
<blockquote TYPE=CITE>&nbsp;
<p><tt>5. Errors For Which Corrections Are Stated</tt>
<p><tt>&nbsp;&nbsp; This is the only section which will remain in this
document after</tt>
<br><tt>&nbsp;&nbsp; the IESG has approved the combination of [2] and the
corrections</tt>
<br><tt>&nbsp;&nbsp; stated below.&nbsp; It describes the errors and ambiguities
which have</tt>
<br><tt>&nbsp;&nbsp; been found in [2], along with the corrections they
require.</tt>
<p><tt>&nbsp;&nbsp; Section&nbsp;&nbsp;&nbsp; Issue&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Resolution</tt>
<p><tt>&nbsp;&nbsp; 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Q.724 is not used.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Delete from list of</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
references.</tt>
<br><tt>&nbsp;&nbsp; 4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
BRI is not used.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Delete from list of</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
abbreviations.</tt>
<br><tt>&nbsp;&nbsp; 2, C&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Leave Recs.
referred to in&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Do that.</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Annex C undated, implying</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
latest issue.</tt>
<p><tt>Taylor&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Standards Track -- Expires Sep 2000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
4</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Megaco/H.248 Corrections&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
March 2000</tt>
<p><tt>&nbsp;&nbsp; 6.2.4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Says that property
values set&nbsp;&nbsp; Add text to first para</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
in Null context are&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
third sentence: "Most</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
remembered and reinstated&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; properties
have default</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
when termination returns to&nbsp;&nbsp;&nbsp;&nbsp; values, which are</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Null.&nbsp; Contradicts latest&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; explicitly
defined in</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
text in 7.2.3.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
this standard or set by</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
provisioning."&nbsp; Delete</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
first para fourth</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
sentence, which read:</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
"The default value of a</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
property of a physical</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Termination can be</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
changed by setting it to</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
a different value when</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
the Termination is in</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
the null Context."</tt>
<br><tt>&nbsp;&nbsp; 6.2.4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DigitMap entry
in table makes&nbsp;&nbsp; Change existing text to</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
explicit reference to DTMF&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; new one as follows:</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
tones.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
"Defines patterns</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
against which sequences</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
of a specified set of</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
events are to be matched</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
so they can be reported</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
as a group rather than</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
singly."</tt>
<br><tt>&nbsp;&nbsp; 7.1,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The order
in which&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Add text stating that</tt>
<br><tt>&nbsp;&nbsp; A.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; descriptors
are processed&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; descriptors are</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
within a command matters, but&nbsp;&nbsp; processed in the order</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
is not clear.&nbsp; Moreover, it&nbsp;&nbsp;&nbsp;&nbsp; in which they
are</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
is fixed in the ASN.1 but&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; provided.&nbsp;
Change ASN.1</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
variable in the ABNF.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
in Annex A.2 to impose</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ordering as suggested by</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
John Segers ("Descriptor</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
processing order", Wed</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
15/03/00)</tt></blockquote>
Solves the "audit order issue" in 7.2.9, but not quite sure what that means
in lieu of atomic command execution.
<blockquote TYPE=CITE>&nbsp;
<br><tt>&nbsp;&nbsp; 7.1.5,&nbsp;&nbsp;&nbsp;&nbsp; Text allows CHOOSE
for&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Change ABNF:</tt>
<br><tt>&nbsp;&nbsp; B.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; property
values in&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
propertyParm = pkgdName</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
TerminationStateDesc, but&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ( "$" / parmValue)</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ABNF does not.</tt>
<br><tt>&nbsp;&nbsp; 7.1.6,&nbsp;&nbsp;&nbsp;&nbsp; Text indicates use
of "true"&nbsp;&nbsp;&nbsp; Add comment in B.2 that</tt>
<br><tt>&nbsp;&nbsp; B.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and
"false" values while ABNF&nbsp;&nbsp; "true" in text</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
uses "on" and "off"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
corresponds to "on" in</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ABNF, and "false"</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
corresponds to "off".</tt>
<br><tt>&nbsp;&nbsp; 7.1.8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Last bulleted
item should&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Add "loopback".</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
include "loopback" in list of</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
possible states.</tt></blockquote>
Just to clarify:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Last bulleted
item in the second last bullet list.
<blockquote TYPE=CITE>&nbsp;
<p><tt>Taylor&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Standards Track -- Expires Sep 2000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
5</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Megaco/H.248 Corrections&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
March 2000</tt>
<p><tt>&nbsp;&nbsp; 7.1.9&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; EventDM is part
of syntax but&nbsp;&nbsp; Add text: "If a digit</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
not mentioned in section.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; map is required
in the</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
EventsDescriptor,</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
EventDM is used to carry</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
either the name or the</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
value of the digit map.</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
See section 7.1.14."</tt></blockquote>
When is a digit map required in the EventsDescriptor ?
<blockquote TYPE=CITE>&nbsp;
<br><tt>&nbsp;&nbsp; 7.1.9&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Case 1, step 2(a)
is both&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fix separation of</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
incorrectly formulated and&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; paragraphs.&nbsp;
Change step</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
incorrectly formatted.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
2(a) to read: "While</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Existing logic may result in&nbsp;&nbsp;&nbsp; waiting for a new</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
an infinite loop.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
EventsDescriptor, any</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
events detected which</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
appear in the current</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
EventsBufferDescriptor</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
will be placed in the</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
EventBuffer.&nbsp; When a new</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
EventDescriptor is</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
received, event</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
processing repeats from</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
step 1."</tt>
<br><tt>&nbsp;&nbsp; 7.1.13&nbsp;&nbsp;&nbsp;&nbsp; Missing "extension"&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Add missing component.</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
component.</tt>
<br><tt>&nbsp;&nbsp; 7.1.14&nbsp;&nbsp;&nbsp;&nbsp; Item 5 in second numbered&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Add the words "and it</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
list&nbsp; understates conditions&nbsp;&nbsp;&nbsp; has been fully matched"</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
for digit map completion when&nbsp;&nbsp; to the existing sentence</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
single candidate remains.</tt>
<p><tt>&nbsp;&nbsp; 7.1.18&nbsp;&nbsp;&nbsp;&nbsp; Third bullet attached
to&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Delete the clause ";</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
third para: says loopback&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; loopbacks
are created by</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
achieved by manipulating&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; setting
the</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
TerminationMode, which no&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TerminationMode"</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
longer has that name.</tt>
<br><tt>&nbsp;&nbsp; 7.2.5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fails to indicate
what&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Add the following
text:</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
AuditValue for&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
"EventBuffer returns the</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
EventBufferDescriptor returns&nbsp;&nbsp; set of events and</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
associated parameter</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
values currently enabled</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
in the</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
EventBufferDescriptor."</tt>
<br><tt>&nbsp;&nbsp; 7.2.5,&nbsp;&nbsp;&nbsp;&nbsp; Text and ASN.1 allow
return&nbsp;&nbsp;&nbsp;&nbsp; Fix production</tt>
<br><tt>&nbsp;&nbsp; B.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of results
involving multiple&nbsp;&nbsp; contextTerminationAudit</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
contexts, but ABNF does not.&nbsp;&nbsp;&nbsp; by allowing return of</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
list of context-specific</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
results as an</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
alternative.</tt>
<p><tt>Taylor&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Standards Track -- Expires Sep 2000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
6</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Megaco/H.248 Corrections&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
March 2000</tt>
<p><tt>&nbsp;&nbsp; 7.2.5,&nbsp;&nbsp;&nbsp;&nbsp; Does not indicate how
an&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Change syntax of</tt>
<br><tt>&nbsp;&nbsp; A.2,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; audit of
digit maps returns&nbsp;&nbsp;&nbsp;&nbsp; DigitMapDescriptor to</tt>
<br><tt>&nbsp;&nbsp; B.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; unnamed
digit maps.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
allow return of unnamed</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
digit maps per John</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Seger suggestion ("[Fwd:</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Issues In v16 Draft]",</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Wed 15/03/00).</tt>
<br><tt>&nbsp;&nbsp; 7.2.6&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fails to indicate
what</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
AuditCapabilities for&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
"EventBuffer returns the</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Add the following text:</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
EventBufferDescriptor returns&nbsp;&nbsp; same information as</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Events."</tt></blockquote>
Not sure that's entirely accurate since EventBuffer is a sequence of Observed
Events
<blockquote TYPE=CITE>&nbsp;
<br><tt>&nbsp;&nbsp; 7.2.6,&nbsp;&nbsp;&nbsp;&nbsp; Inconsistency regarding&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Add comment to B.2</tt>
<br><tt>&nbsp;&nbsp; B.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; permissibility
of DigitMap or&nbsp;&nbsp; "auditItem" production</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Packages as capability audit&nbsp;&nbsp;&nbsp; indicating that DigitMap</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
items.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
and Packages are not</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
allowed in the</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
AuditCapabilities</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
command.</tt></blockquote>
I still don't understand how digit maps can apply to all terminations,
regardless of type (e.g. consider video)
<blockquote TYPE=CITE>&nbsp;
<br><tt>&nbsp;&nbsp; 7.2.8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Paragraph beginning
"A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Add text to the</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ServiceChange Command&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
offending sentence, so</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
specifying the Root..."&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
that it reads:</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
immediately following the&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "Acknowledgement
of the</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
description of ServiceChange&nbsp;&nbsp;&nbsp; ServiceChange Command</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Descriptor parameters&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
completes the</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
erroneously states that the&nbsp;&nbsp;&nbsp;&nbsp; registration process,</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
response to the ServiceChange&nbsp;&nbsp; except when the MGC has</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
command terminates the&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
returned an alternative</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
registration process.&nbsp; This&nbsp;&nbsp;&nbsp;&nbsp; ServiceChangeMgcId
as</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
is so only if the response&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; described in the
next</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
does not specify an alternate&nbsp;&nbsp; paragraph."</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
MGC.</tt>
<p><tt>&nbsp;&nbsp; 7.3&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Text
for error code 403&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Change
text to "Syntax</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
should be consistent with&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; error in</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
that for 404 and 405.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
TransactionRequest"</tt>
<p><tt>&nbsp;&nbsp; 8.2.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Final para has
wrong text for&nbsp;&nbsp; Change to "Syntax Error</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
error code 442.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
in Command"</tt>
<p><tt>&nbsp;&nbsp; 11.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Second paragraph
last&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Restore
original</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
sentence inadvertently&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
sentence: "If the MG is</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
modified -- duplicates&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
unable to establish a</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
material in 11.3.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
control relationship</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
with any MGC, it shall</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
wait a random amount of</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
time as described in</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Section 9.2 and then</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
start contacting its</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
primary, and if</tt></blockquote>
First paragraph actually.
<blockquote TYPE=CITE>&nbsp;
<p><tt>Taylor&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Standards Track -- Expires Sep 2000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
7</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Megaco/H.248 Corrections&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
March 2000</tt>
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
necessary, its secondary</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
MGCs again."</tt>
<p><tt>&nbsp;&nbsp; 11.4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Second para:
wrong MG is&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Change fourth sentence</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
specified as the one to be&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to refer to "secondary</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
used after failover.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
MG" rather than "primary</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
MG".</tt>
<br><tt>&nbsp;&nbsp; 12.1.4&nbsp;&nbsp;&nbsp;&nbsp; Note says that default&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Add TO signals to note.</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
duration should be specified</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
for BR signals.&nbsp; This also</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
applies to TO signals.</tt>
<br><tt>&nbsp;&nbsp; A.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; LocalControlDescriptor
still</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
contains reserve rather than&nbsp;&nbsp;&nbsp; separate reserveValue</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
reserveValue and&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
and reserveGroup</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Replace reserve with</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
reserveGroup.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Booleans.</tt>
<p><tt>&nbsp;&nbsp; A.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Assigned
object identifier&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Add object identifier</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
missing.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
line with content</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
"itu-t recommendation h</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
248 media-gateway-</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
control(0)"</tt>
<br><tt>&nbsp;&nbsp; B.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Syntax
for parmValue and</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
VALUE together make parsing&nbsp;&nbsp;&nbsp;&nbsp; in alternativeValue
by</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Replace range notation</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
of range ambiguous.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
"LSBRKT VALUE COLON</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
VALUE RSBRKT"</tt>
<br><tt>&nbsp;&nbsp; B.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Error
in syntax for</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
digitMapDescriptor: value&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; digitMapDescriptor
=</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Change production:</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
meant to be optional.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
DigitMapToken EQUAL</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
digitMapName</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[ LBRKT digitMapValue</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
RBRKT ]</tt>
<br><tt>&nbsp;&nbsp; B.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; VersionToken
not defined.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Add ABNF:</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
VersionToken =</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
("Version" / "V")</tt>
<br><tt>&nbsp;&nbsp; B.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DiscardToken
not used.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Delete
production.</tt>
<br><tt>&nbsp;&nbsp; C.9&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ITC
has reference to missing&nbsp;&nbsp;&nbsp; Delete reference.</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
note 2</tt>
<p><tt>&nbsp;&nbsp; C.9&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Not clear
that Q.931 Bearer&nbsp;&nbsp;&nbsp;&nbsp; Specify that values are</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Capability IE rather than Low&nbsp;&nbsp; those valid for Bearer</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Layer Compatibility IE is&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Capability
IE</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
being used.</tt>
<p><tt>Taylor&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Standards Track -- Expires Sep 2000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
8</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Megaco/H.248 Corrections&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
March 2000</tt>
<p><tt>&nbsp;&nbsp; D.1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Even
in the case of handoff&nbsp;&nbsp;&nbsp;&nbsp; In the last sentence of</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
or failover, the originating&nbsp;&nbsp;&nbsp; the first paragraph,</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
MGC needs confirmation that&nbsp;&nbsp;&nbsp;&nbsp; delete the excepting</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
its command was received.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; clause, so
that the</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
sentence reads:</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
"Responses must be sent</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
to the address and port</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
from which the</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
corresponding commands</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
were sent."</tt>
<br><tt>&nbsp;&nbsp; D.1.1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Second para last
sentence</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
provides a procedural</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
reference to 8.2.3.&nbsp; Should</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
refer to UDP-specific</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Add reference to D.1.4.</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
procedures.</tt>
<p><tt>&nbsp;&nbsp; D.1.4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; First paragraph,
last</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
sentence talks about when to&nbsp;&nbsp;&nbsp; SHOULD send this</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
send the Transaction Pending&nbsp;&nbsp;&nbsp; response if they receive</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
response.&nbsp; When UDP/ALF is in&nbsp;&nbsp; a repetition of a</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
use, the originator of a&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; transaction
that is</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
transaction may repeat it&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; still being
executed."</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
because it has not received</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
an acknowledgement that the</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
transaction was received.&nbsp; An</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
appropriate response to a</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
duplicate transaction which</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
is still being processed is</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
to return Transaction</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Add the sentence: "They</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Pending.</tt>
<p><tt>&nbsp;&nbsp; D.1.5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Last paragraph
is equivocal&nbsp;&nbsp;&nbsp;&nbsp; Change the two sentences</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
about what&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
following the phrase "_</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ServiceChangeReason to use&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; and it begins
its</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
when recovering from loss of&nbsp;&nbsp;&nbsp; recovery process" to</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
contact; it must always be&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; read as follows:
"The MG</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
"Disconnected".&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
shall use a</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ServiceChange with</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ServiceChangeMethod set</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
to disconnected so that</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
the new MGC will be</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
aware that the MG lost</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
one or more</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
transactions."</tt>
<br><tt>&nbsp;&nbsp; E.6.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "Long duration
event&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Replace with "Z".</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
modifier" is shown as "L" in</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
parameter DigitString --</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
should be "Z".</tt>
<p><tt>Taylor&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Standards Track -- Expires Sep 2000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
9</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Megaco/H.248 Corrections&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
March 2000</tt>
<p><tt>&nbsp;&nbsp; Appx&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Step 20 fails
to show a&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Add the following
to the</tt>
<br><tt>&nbsp;&nbsp; A.1.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; returned&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Media Descriptor</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
TerminationStateDescriptor&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; preceding the
line</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
"Stream = 1_":</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
"TerminationState {</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
ServiceStates =</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
InService,</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
EventBufferControl = OFF</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
},"</tt>
<p><tt>6. Security Considerations</tt>
<p><tt>&nbsp;&nbsp; This draft is a supplement to [2], which contains the
required</tt>
<br><tt>&nbsp;&nbsp; security section.</tt>
<p><tt>7. References</tt>
<p><tt>&nbsp;&nbsp; [1] RFC 2026</tt>
<br><tt>&nbsp;&nbsp; [2] draft-ietf-megaco-protocol-07.txt</tt>
<br><tt>&nbsp;&nbsp; [3] RFC 2119</tt>
<p><tt>8. Acknowledgments</tt>
<p><tt>&nbsp;&nbsp; This draft records the contributions of a number of
people on the</tt>
<br><tt>&nbsp;&nbsp; Megaco list who took the time to read the Megaco/H.248
draft with</tt>
<br><tt>&nbsp;&nbsp; care and attention.&nbsp; Thanks to all of them.</tt>
<p><tt>9. Author's Addresses</tt>
<p><tt>&nbsp;&nbsp; Tom Taylor</tt>
<br><tt>&nbsp;&nbsp; Nortel Networks</tt>
<br><tt>&nbsp;&nbsp; P.O. Box 3511, Station C</tt>
<br><tt>&nbsp;&nbsp; Ottawa, Ontario, Canada K1Y 4P7</tt>
<br><tt>&nbsp;&nbsp; Phone: +1 613 736 0961</tt>
<br><tt>&nbsp;&nbsp; Email: taylor@nortelnetworks.com</tt>
<p><tt>Taylor&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Standards Track -- Expires Sep 2000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
10</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Megaco/H.248 Corrections&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
March 2000</tt>
<p><tt>Full Copyright Statement</tt>
<p><tt>&nbsp;&nbsp; "Copyright (C) The Internet Society (date). All Rights
Reserved.</tt>
<br><tt>&nbsp;&nbsp; This document and translations of it may be copied
and furnished to</tt>
<br><tt>&nbsp;&nbsp; others, and derivative works that comment on or otherwise
explain it</tt>
<br><tt>&nbsp;&nbsp; or assist in its implmentation may be prepared, copied,
published</tt>
<br><tt>&nbsp;&nbsp; and distributed, in whole or in part, without restriction
of any</tt>
<br><tt>&nbsp;&nbsp; kind, provided that the above copyright notice and
this paragraph</tt>
<br><tt>&nbsp;&nbsp; are included on all such copies and derivative works.
However, this</tt>
<br><tt>&nbsp;&nbsp; document itself may not be modified in any way, such
as by removing</tt>
<br><tt>&nbsp;&nbsp; the copyright notice or references to the Internet
Society or other</tt>
<br><tt>&nbsp;&nbsp; Internet organizations, except as needed for the purpose
of</tt>
<br><tt>&nbsp;&nbsp; developing Internet standards in which case the procedures
for</tt>
<br><tt>&nbsp;&nbsp; copyrights defined in the Internet Standards process
must be</tt>
<br><tt>&nbsp;&nbsp; followed, or as required to translate it into other
languages.</tt>
<p><tt>&nbsp;&nbsp; 1&nbsp; Bradner, S., "Key words for use in RFCs to
Indicate Requirement</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Levels", BCP 14, RFC 2119, March
1997</tt>
<p><tt>Taylor&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Standards Track -- Expires Sep 2000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
11</tt></blockquote>
<tt>--</tt>
<br><tt>Flemming Andreasen&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Phone: +1 732 452 1667</tt>
<br><tt>Cisco Systems&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Fax:&nbsp;&nbsp; +1 240 359 5839</tt>
<br>&nbsp;</html>

--------------789E3FC028C622D18C586FFD--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Apr  5 20:29:03 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18119
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 5 Apr 2000 20:29:02 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C30A4EB0@standards.nortelnetworks.com>; Wed, 5 Apr 2000 20:23:10 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 119830 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 5 Apr 2000 20:21:38 -0400
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.25301C20@standards.nortelnetworks.com>; Wed, 5 Apr 2000 20:11:36
          -0400
Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com
          (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id RAA00472; Wed, 5 Apr 2000
          17:11:37 -0700 (PDT)
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="------------13BFF7356F9A8CEFCD8F27B6"
Message-ID:  <38EC010A.F376E747@cisco.com>
Date:         Wed, 5 Apr 2000 20:14:18 -0700
Reply-To: Flemming Andreasen <fandreas@CISCO.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Flemming Andreasen <fandreas@CISCO.COM>
Organization: Cisco Systems
Subject:      [Fwd: On 7.1.14]
X-To:         Tom-PT Taylor <taylor@nortelnetworks.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--------------13BFF7356F9A8CEFCD8F27B6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Tom

Resending this one with the items I think are still open (the ones we
left open last time and/or I didn't see in your latest issues summary
list).



Flemming Andreasen wrote:

>
>
> Tom-PT Taylor wrote:
>
>>
>>
>> Responses below.
>>
>>      -----Original Message-----
>>      From:  Flemming Andreasen [SMTP:fandreas@CISCO.COM]
>>      Sent:  Saturday, March 11, 2000 11:47 AM
>>      To:    MEGACO@STANDARDS.NORTELNETWORKS.COM
>>      Subject:      On 7.1.4
>>
>>      Tom Taylor wrote:
>>
>>      >
>>      > > 7) 7.1.14, last sentence in paragraph beginning with "The
>>      letter 'x'
>>      > is
>>      > > used as a wildcard..." specifies that "As a consequence of
>>      the thrid
>>      >
>>      > > timing rule above, inter-event timing while matching the
>>      dot symbol
>>      > uses
>>      > > the short timer by default." is incorrect. The grammar may
>>      continue
>>      > past
>>      > > the dot symbol implying the dot could only possibly produce
>>      a
>>      > partial
>>      > > match which furthermore implies that the short timer may
>>      not be the
>>      > > right one to use. The sentence should simply be removed.
>>      >         [[TomT]]  Agreed that the grammar may continue past
>>      the dot,
>>      > but
>>      > until you get that far you have an ambiguous situation -- you
>>      don't
>>      > know how
>>      > many events will be mapped into the dot.  The sentence is
>>      correct
>>      > AFAIK.
>>
>>      That's not entirely accurate, e.g. consider "x.#" Now, if what
>>      follows
>>      the dot has a non-empty intersection with what precedes the dot
>>
>>      (ignoring timers), you have an ambigous situation. In that case
>>      you
>>      could then apply the short timer, or alternatively simply leave
>>      the
>>      timing rules undefined then (since you can always rewrite the
>>      digit map
>>      to avoid this, well at least in most cases).
>>      [[TomT]]
>>      The term "ambiguous" is used in this section to mean that
>>      multiple patterns in the digit map match the current dial
>>      string.  The pattern "x.F" (not "x.#") is a short way of
>>      specifying a whole series of patterns: "xF" | "xxF" | "xxxF" |
>>      ...  This is why I say that the dot creates an ambiguous
>>      situation which calls for the use of the short timer.  At any
>>      point in the dialling process short of receiving the final #,
>>      there is an indefinite number of patterns which the current
>>      dial string may match.
>>
> That still doesn't sound right as it would imply that if I had say "12
> | 13" in my digit map then upon entering 1, I would apply short
> interdigit timing. The only thing that makes ambigouity interesting,
> is when you *cannot* determine whether there is a match or not. The
> way you determine that is then to apply a short interdigit timer,
> otherwise a long timer is applied.

>>
>>
>>      >
>>
>>      >
>>      > > 8) 7.1.14, next paragraph specifies that "A timer specified
>>
>>      > following a
>>      > > dot specifies inter-event timing for all events matching
>>      the dot as
>>      > well
>>      > > as for subsequent events". It's unclear why the timer
>>      couldn't
>>      > simply be
>>      > > put in front of the dot and thereby be consistent with
>>      digit map
>>      > timers
>>      > > in general. In the absence of a compelling argument the
>>      sentence
>>      > should
>>      > > simply be removed.
>>      >         [[TomT]]  Same problem as with the previous remark --
>>      you
>>      > don't know
>>      > when you've gone past the dot until it's too late.  If there
>>      is a
>>      > timer both
>>      > before and after the dot, a timer after the dot never gets
>>      used.  It
>>      > may be
>>      > better just to say that, I suppose, leaving it up to the MGC
>>      to set a
>>      > timer
>>      > before the dot if it wants.
>>
>>      You could have have "S.xL", but otherwise I agree.
>>      [[TomT]]
>>      At this point I see that my remarks were a little imprecise: if
>>      there is a timer both before and IMMEDIATELY after the dot, the
>>      timer after the dot doesn't get used to detect the event that
>>      indicates that the dot has been passed.  It may apply to events
>>      subsequent to that point.
>>
> Even that may not be entirely accurate (although it in practice is
> probably not a big deal), e.g. consider "S.xLF".

<snip>


>>
>>      >
>>      > > 11) 7.1.14, numbered list, item 5:    It is entirely
>>      unclear why an
>>      > > event triggering a partial match is not reported as part of
>>      the
>>      > matched
>>      > > string. In the absence of a compelling argument, the
>>      triggering
>>      > event
>>      > > should be included in the string as it otherwise may be
>>      processed
>>      > twice,
>>      > > which is hardly what the user had in mind.
>>      >         [[TomT]]  I had it that way in the first place (with
>>      the
>>      > triggering
>>      > event distinguished by being placed in an "extra event"
>>      parameter) and
>>      >
>>      > consensus was to change it to what it is now.  Have to
>>      overrule you on
>>      > this
>>      > one unless you get more support.
>>
>>      Well, I think it would be more appropriate that those who argue
>>      against
>>      explain why. There's got to be a reasonable explanation here,
>>      or
>>      reviewing this stuff is a waste of everybody's time.
>>      [[TomT]]
>>      The reasoning was that when you activate a digit map it's what
>>      the digit map matches that is of interest -- anything left over
>>      needs to be handled in a separate processing step.  The typical
>>      situation in our experience is that digit collection happens in
>>      multiple stages.  The MGC doesn't want to receive that extra
>>      digit because it wants the digit to be processed against the
>>      next map to be activated.
>>
> Agreed, but only in the case where the first stage did not contain an
> error, i.e. mismatch. You want to consume the "error" input.
>
>>
>>
>>      I'll have to think about the "double processing" question.
>>      Events have side effects, such as stopping signals, and clearly
>>      we only want those side effects to happen once.  It may be that
>>      we need language to make sure this is what happens.
>>
>>      > I'm also not clear how you get duplicate
>>      > processing -- the situation is logically equivalent to the
>>      triggering
>>      > event
>>      > (a non-matching digit) happening just after the digit
>>      completion event
>>      > has
>>      > been notified.
>>
>>      Consider an IVR menu where input consists of two or more
>>      digits. For
>>      sake of argument, let's say the only valid choice is "12", and
>>      I
>>      erroneously enter "13". Upon entering "3" we get a mismatch and
>>      I
>>      probably hear a recording telling me that "13" is an invalid
>>      choice and
>>      I should try again.
>>      [[TomT]]
>>      More likely you'll get a recording telling you what the valid
>>      choices are.  Under our current rules, of course, the MGC
>>      doesn't know about the 3 when the digit map completion event is
>>      reported.
>>
>>      When digit map processing resumes for renewed input,
>>      "3" will now be processed and I get another mismatch.
>>      [[TomT]]
>>      Seems clear in this case that the MGC should ensure that the
>>      event buffer is cleared before resuming the operation.
>>
> Agreed, however LockStep doesn't do that, so you have a problem.
>
>>
>>
>>      The event was
>>      processed twice which is the problem (a "process"/"discard"
>>      parameter in
>>      event handling would of course be a general cure for such
>>      problems, but
>>      alas, that was not to happen)
>>
>>
>>      >
>>      >
>>      > > 12) 7.1.14, second last paragraph states that "Regardles of
>>      whether
>>      > a
>>      > > digit map is activated, this form of event specification
>>      will cause
>>      > the
>>      > > individual events to be reported to the MGC as they are
>>      detected".
>>      > Some
>>      > > clarification is requested here.
>>      >         [[TomT]]  This paragraph gives the interpretation of
>>      e.g. the
>>      > "dd/*"
>>      > event specification.  Using the example digit map which
>>      immediately
>>      > follows,
>>      > a dialled "1" will be reported immediately and also
>>      accumulated into
>>      > the
>>      > digit map.  Of course, if EventBufferControl is set to
>>      LockStep, the
>>      > digit
>>      > map will never complete because a new Event Descriptor will
>>      be loaded
>>      > before
>>      > completion can be reported.  (There is a corner case with a
>>      dialled
>>      > "0" and
>>      > short timer expiry before the new Event descriptor is loaded,
>>      but
>>      > let's not
>>      > go into that.)
>>
>>      I can, to some extent, understand that, although I think this
>>      dual
>>      processing does little but underscore the lack of generality in
>>      the
>>      event handling scheme (interesting case when you have
>>      EventBufferControl
>>      off). At a bare minimum I think you should define that an event
>>      detected
>>      can at most match or be consumed by a single "event" specified
>>      in the
>>      EventsDescriptor.
>>
>>      What I don't understand in the above sentence is, that it seems
>>      to imply
>>      that the name by which we refer to an event impacts the
>>      reporting of
>>      that event. With the current "dd" package, you may request
>>      digit map
>>      matching without by only requesting the "Digit Map Completion"
>>      event,
>>      i.e. do not request DTMF digits (correct ?). Thus I might
>>      define another
>>      package, call it "dd2" that only consists of this particular
>>      event. What
>>      the above sentence now implies is, that when I request "dd/ce",
>>      I will
>>      process according to the digit map, but when I request "dd/*",
>>      which can
>>      only expand to "dd/ce", I will report the digits invidually.
>>      Doesn't
>>      seem right.
>>      [[TomT]]  It seems like you typed this one a bit quickly.
>>
> Yes, the example should of course have referred to "dd2" instead of
> "dd".
>
>>      The problem is that dd/* currently includes within its scope
>>      both the individual digit events and the digit map completion
>>      event.  If you moved the latter off to an extension package
>>      dd2, then I think we would have:
>>
>>       - dd/* reports only individual digit events
>>       - dd2/* reports only the digit map completion event.
>>
> Agreed (report most specific event). The current sentence does not
> seem to imply this though unless you qualify it to specifically only
> reference the "dd" package.
>
> -- Flemming
>

Regards

            Flemming
--
Flemming Andreasen                Phone: +1 732 452 1667
Cisco Systems                     Fax:   +1 240 359 5839


--------------13BFF7356F9A8CEFCD8F27B6
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi Tom
<p>Resending this one with the items I think are still open (the ones we
left open last time and/or I didn't see in your latest issues summary list).
<br>&nbsp;
<br>&nbsp;
<p>Flemming Andreasen wrote:
<blockquote TYPE=CITE>&nbsp;
<p>Tom-PT Taylor wrote:
<blockquote TYPE=CITE>&nbsp;
<p><font face="Arial"><font color="#0000FF"><font size=-1>Responses below.</font></font></font>
<ul><font face="Arial"><font size=-2>-----Original Message-----</font></font>
<br><font face="Arial"><font size=-2><b>From:&nbsp; </b>Flemming Andreasen
[SMTP:fandreas@CISCO.COM]</font></font>
<br><font face="Arial"><font size=-2><b>Sent:&nbsp; </b>Saturday, March
11, 2000 11:47 AM</font></font>
<br><font face="Arial"><font size=-2><b>To:&nbsp;&nbsp;&nbsp; </b>MEGACO@STANDARDS.NORTELNETWORKS.COM</font></font>
<br><font face="Arial"><font size=-2><b>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

</b>On 7.1.4</font></font>
<p><font face="Arial"><font size=-1>Tom Taylor wrote:</font></font>
<p><font face="Arial"><font size=-1>></font></font>
<br><font face="Arial"><font size=-1>> > 7) 7.1.14, last sentence in paragraph
beginning with "The letter 'x'</font></font>
<br><font face="Arial"><font size=-1>> is</font></font>
<br><font face="Arial"><font size=-1>> > used as a wildcard..." specifies
that "As a consequence of the thrid</font></font>
<br><font face="Arial"><font size=-1>></font></font>
<br><font face="Arial"><font size=-1>> > timing rule above, inter-event
timing while matching the dot symbol</font></font>
<br><font face="Arial"><font size=-1>> uses</font></font>
<br><font face="Arial"><font size=-1>> > the short timer by default." is
incorrect. The grammar may continue</font></font>
<br><font face="Arial"><font size=-1>> past</font></font>
<br><font face="Arial"><font size=-1>> > the dot symbol implying the dot
could only possibly produce a</font></font>
<br><font face="Arial"><font size=-1>> partial</font></font>
<br><font face="Arial"><font size=-1>> > match which furthermore implies
that the short timer may not be the</font></font>
<br><font face="Arial"><font size=-1>> > right one to use. The sentence
should simply be removed.</font></font>
<br><font face="Arial"><font size=-1>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[[TomT]]&nbsp; Agreed that the grammar may continue past the dot,</font></font>
<br><font face="Arial"><font size=-1>> but</font></font>
<br><font face="Arial"><font size=-1>> until you get that far you have
an ambiguous situation -- you don't</font></font>
<br><font face="Arial"><font size=-1>> know how</font></font>
<br><font face="Arial"><font size=-1>> many events will be mapped into
the dot.&nbsp; The sentence is correct</font></font>
<br><font face="Arial"><font size=-1>> AFAIK.</font></font>
<p><font face="Arial"><font size=-1>That's not entirely accurate, e.g.
consider "x.#" Now, if what follows</font></font>
<br><font face="Arial"><font size=-1>the dot has a non-empty intersection
with what precedes the dot</font></font>
<br><font face="Arial"><font size=-1>(ignoring timers), you have an ambigous
situation. In that case you</font></font>
<br><font face="Arial"><font size=-1>could then apply the short timer,
or alternatively simply leave the</font></font>
<br><font face="Arial"><font size=-1>timing rules undefined then (since
you can always rewrite the digit map</font></font>
<br><font face="Arial"><font size=-1>to avoid this, well at least in most
cases).</font></font>
<br><b><i><font face="Arial"><font color="#0000FF"><font size=-1>[[TomT]]</font></font></font></i></b>
<br><font face="Arial"><font color="#0000FF"><font size=-1>The term "ambiguous"
is used in this section to mean that multiple patterns in the digit map
match the current dial string.&nbsp; The pattern "x.F" (not "x.#") is a
short way of specifying a whole series of patterns: "xF" | "xxF" | "xxxF"
| ...&nbsp; This is why I say that the dot creates an ambiguous situation
which calls for the use of the short timer.&nbsp; At any point in the dialling
process short of receiving the final #, there is an indefinite number of
patterns which the current dial string may match.</font></font></font></ul>
</blockquote>
That still doesn't sound right as it would imply that if I had say "12
| 13" in my digit map then upon entering 1, I would apply short interdigit
timing. The only thing that makes ambigouity interesting, is when you *cannot*
determine whether there is a match or not. The way you determine that is
then to apply a short interdigit timer, otherwise a long timer is applied.</blockquote>

<blockquote TYPE=CITE>
<blockquote TYPE=CITE>
<ul>&nbsp;
<p><font face="Arial"><font size=-1>></font></font>
<p><font face="Arial"><font size=-1>></font></font>
<br><font face="Arial"><font size=-1>> > 8) 7.1.14, next paragraph specifies
that "A timer specified</font></font>
<br><font face="Arial"><font size=-1>> following a</font></font>
<br><font face="Arial"><font size=-1>> > dot specifies inter-event timing
for all events matching the dot as</font></font>
<br><font face="Arial"><font size=-1>> well</font></font>
<br><font face="Arial"><font size=-1>> > as for subsequent events". It's
unclear why the timer couldn't</font></font>
<br><font face="Arial"><font size=-1>> simply be</font></font>
<br><font face="Arial"><font size=-1>> > put in front of the dot and thereby
be consistent with digit map</font></font>
<br><font face="Arial"><font size=-1>> timers</font></font>
<br><font face="Arial"><font size=-1>> > in general. In the absence of
a compelling argument the sentence</font></font>
<br><font face="Arial"><font size=-1>> should</font></font>
<br><font face="Arial"><font size=-1>> > simply be removed.</font></font>
<br><font face="Arial"><font size=-1>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[[TomT]]&nbsp; Same problem as with the previous remark -- you</font></font>
<br><font face="Arial"><font size=-1>> don't know</font></font>
<br><font face="Arial"><font size=-1>> when you've gone past the dot until
it's too late.&nbsp; If there is a</font></font>
<br><font face="Arial"><font size=-1>> timer both</font></font>
<br><font face="Arial"><font size=-1>> before and after the dot, a timer
after the dot never gets used.&nbsp; It</font></font>
<br><font face="Arial"><font size=-1>> may be</font></font>
<br><font face="Arial"><font size=-1>> better just to say that, I suppose,
leaving it up to the MGC to set a</font></font>
<br><font face="Arial"><font size=-1>> timer</font></font>
<br><font face="Arial"><font size=-1>> before the dot if it wants.</font></font>
<p><font face="Arial"><font size=-1>You could have have "S.xL", but otherwise
I agree.</font></font>
<br><b><i><font face="Arial"><font color="#0000FF"><font size=-1>[[TomT]]</font></font></font></i></b>
<br><font face="Arial"><font color="#0000FF"><font size=-1>At this point
I see that my remarks were a little imprecise: if there is a timer both
before and IMMEDIATELY after the dot, the timer after the dot doesn't get
used to detect the event that indicates that the dot has been passed.&nbsp;
It may apply to events subsequent to that point.</font></font></font></ul>
</blockquote>
Even that may not be entirely accurate (although it in practice is probably
not a big deal), e.g. consider "S.xLF".</blockquote>

<p><br>&lt;snip>
<br>&nbsp;
<blockquote TYPE=CITE>
<blockquote TYPE=CITE>
<ul><font face="Arial"><font size=-1></font></font>&nbsp;
<br><font face="Arial"><font size=-1>></font></font>
<br><font face="Arial"><font size=-1>> > 11) 7.1.14, numbered list, item
5:&nbsp;&nbsp;&nbsp; It is entirely unclear why an</font></font>
<br><font face="Arial"><font size=-1>> > event triggering a partial match
is not reported as part of the</font></font>
<br><font face="Arial"><font size=-1>> matched</font></font>
<br><font face="Arial"><font size=-1>> > string. In the absence of a compelling
argument, the triggering</font></font>
<br><font face="Arial"><font size=-1>> event</font></font>
<br><font face="Arial"><font size=-1>> > should be included in the string
as it otherwise may be processed</font></font>
<br><font face="Arial"><font size=-1>> twice,</font></font>
<br><font face="Arial"><font size=-1>> > which is hardly what the user
had in mind.</font></font>
<br><font face="Arial"><font size=-1>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[[TomT]]&nbsp; I had it that way in the first place (with the</font></font>
<br><font face="Arial"><font size=-1>> triggering</font></font>
<br><font face="Arial"><font size=-1>> event distinguished by being placed
in an "extra event" parameter) and</font></font>
<br><font face="Arial"><font size=-1>></font></font>
<br><font face="Arial"><font size=-1>> consensus was to change it to what
it is now.&nbsp; Have to overrule you on</font></font>
<br><font face="Arial"><font size=-1>> this</font></font>
<br><font face="Arial"><font size=-1>> one unless you get more support.</font></font>
<p><font face="Arial"><font size=-1>Well, I think it would be more appropriate
that those who argue against</font></font>
<br><font face="Arial"><font size=-1>explain why. There's got to be a reasonable
explanation here, or</font></font>
<br><font face="Arial"><font size=-1>reviewing this stuff is a waste of
everybody's time.</font></font>
<br><b><i><font face="Arial"><font color="#0000FF"><font size=-1>[[TomT]]</font></font></font></i></b>
<br><font face="Arial"><font color="#0000FF"><font size=-1>The reasoning
was that when you activate a digit map it's what the digit map matches
that is of interest -- anything left over needs to be handled in a separate
processing step.&nbsp; The typical situation in our experience is that
digit collection happens in multiple stages.&nbsp; The MGC doesn't want
to receive that extra digit because it wants the digit to be processed
against the next map to be activated.</font></font></font></ul>
</blockquote>
Agreed, but only in the case where the first stage did not contain an error,
i.e. mismatch. You want to consume the "error" input.
<blockquote TYPE=CITE>
<ul>&nbsp;
<p><font face="Arial"><font color="#0000FF"><font size=-1>I'll have to
think about the "double processing" question.&nbsp; Events have side effects,
such as stopping signals, and clearly we only want those side effects to
happen once.&nbsp; It may be that we need language to make sure this is
what happens.</font></font></font>
<p><font face="Arial"><font size=-1>> I'm also not clear how you get duplicate</font></font>
<br><font face="Arial"><font size=-1>> processing -- the situation is logically
equivalent to the triggering</font></font>
<br><font face="Arial"><font size=-1>> event</font></font>
<br><font face="Arial"><font size=-1>> (a non-matching digit) happening
just after the digit completion event</font></font>
<br><font face="Arial"><font size=-1>> has</font></font>
<br><font face="Arial"><font size=-1>> been notified.</font></font>
<p><font face="Arial"><font size=-1>Consider an IVR menu where input consists
of two or more digits. For</font></font>
<br><font face="Arial"><font size=-1>sake of argument, let's say the only
valid choice is "12", and I</font></font>
<br><font face="Arial"><font size=-1>erroneously enter "13". Upon entering
"3" we get a mismatch and I</font></font>
<br><font face="Arial"><font size=-1>probably hear a recording telling
me that "13" is an invalid choice and</font></font>
<br><font face="Arial"><font size=-1>I should try again.</font></font>
<br><b><i><font face="Arial"><font color="#0000FF"><font size=-1>[[TomT]]</font></font></font></i></b>
<br><font face="Arial"><font color="#0000FF"><font size=-1>More likely
you'll get a recording telling you what the valid choices are.&nbsp; Under
our current rules, of course, the MGC doesn't know about the 3 when the
digit map completion event is reported.</font></font></font>
<p><font face="Arial"><font size=-1>When digit map processing resumes for
renewed input,</font></font>
<br><font face="Arial"><font size=-1>"3" will now be processed and I get
another mismatch.</font></font>
<br><b><i><font face="Arial"><font color="#0000FF"><font size=-1>[[TomT]]</font></font></font></i></b>
<br><font face="Arial"><font color="#0000FF"><font size=-1>Seems clear
in this case that the MGC should ensure that the event buffer is cleared
before resuming the operation.</font></font></font></ul>
</blockquote>
Agreed, however LockStep doesn't do that, so you have a problem.
<blockquote TYPE=CITE>
<ul>&nbsp;
<p><font face="Arial"><font size=-1>The event was</font></font>
<br><font face="Arial"><font size=-1>processed twice which is the problem
(a "process"/"discard" parameter in</font></font>
<br><font face="Arial"><font size=-1>event handling would of course be
a general cure for such problems, but</font></font>
<br><font face="Arial"><font size=-1>alas, that was not to happen)</font></font>
<br>&nbsp;
<p><font face="Arial"><font size=-1>></font></font>
<br><font face="Arial"><font size=-1>></font></font>
<br><font face="Arial"><font size=-1>> > 12) 7.1.14, second last paragraph
states that "Regardles of whether</font></font>
<br><font face="Arial"><font size=-1>> a</font></font>
<br><font face="Arial"><font size=-1>> > digit map is activated, this form
of event specification will cause</font></font>
<br><font face="Arial"><font size=-1>> the</font></font>
<br><font face="Arial"><font size=-1>> > individual events to be reported
to the MGC as they are detected".</font></font>
<br><font face="Arial"><font size=-1>> Some</font></font>
<br><font face="Arial"><font size=-1>> > clarification is requested here.</font></font>
<br><font face="Arial"><font size=-1>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[[TomT]]&nbsp; This paragraph gives the interpretation of e.g. the</font></font>
<br><font face="Arial"><font size=-1>> "dd/*"</font></font>
<br><font face="Arial"><font size=-1>> event specification.&nbsp; Using
the example digit map which immediately</font></font>
<br><font face="Arial"><font size=-1>> follows,</font></font>
<br><font face="Arial"><font size=-1>> a dialled "1" will be reported immediately
and also accumulated into</font></font>
<br><font face="Arial"><font size=-1>> the</font></font>
<br><font face="Arial"><font size=-1>> digit map.&nbsp; Of course, if EventBufferControl
is set to LockStep, the</font></font>
<br><font face="Arial"><font size=-1>> digit</font></font>
<br><font face="Arial"><font size=-1>> map will never complete because
a new Event Descriptor will be loaded</font></font>
<br><font face="Arial"><font size=-1>> before</font></font>
<br><font face="Arial"><font size=-1>> completion can be reported.&nbsp;
(There is a corner case with a dialled</font></font>
<br><font face="Arial"><font size=-1>> "0" and</font></font>
<br><font face="Arial"><font size=-1>> short timer expiry before the new
Event descriptor is loaded, but</font></font>
<br><font face="Arial"><font size=-1>> let's not</font></font>
<br><font face="Arial"><font size=-1>> go into that.)</font></font>
<p><font face="Arial"><font size=-1>I can, to some extent, understand that,
although I think this dual</font></font>
<br><font face="Arial"><font size=-1>processing does little but underscore
the lack of generality in the</font></font>
<br><font face="Arial"><font size=-1>event handling scheme (interesting
case when you have EventBufferControl</font></font>
<br><font face="Arial"><font size=-1>off). At a bare minimum I think you
should define that an event detected</font></font>
<br><font face="Arial"><font size=-1>can at most match or be consumed by
a single "event" specified in the</font></font>
<br><font face="Arial"><font size=-1>EventsDescriptor.</font></font>
<p><font face="Arial"><font size=-1>What I don't understand in the above
sentence is, that it seems to imply</font></font>
<br><font face="Arial"><font size=-1>that the name by which we refer to
an event impacts the reporting of</font></font>
<br><font face="Arial"><font size=-1>that event. With the current "dd"
package, you may request digit map</font></font>
<br><font face="Arial"><font size=-1>matching without by only requesting
the "Digit Map Completion" event,</font></font>
<br><font face="Arial"><font size=-1>i.e. do not request DTMF digits (correct
?). Thus I might define another</font></font>
<br><font face="Arial"><font size=-1>package, call it "dd2" that only consists
of this particular event. What</font></font>
<br><font face="Arial"><font size=-1>the above sentence now implies is,
that when I request "dd/ce", I will</font></font>
<br><font face="Arial"><font size=-1>process according to the digit map,
but when I request "dd/*", which can</font></font>
<br><font face="Arial"><font size=-1>only expand to "dd/ce", I will report
the digits invidually. Doesn't</font></font>
<br><font face="Arial"><font size=-1>seem right.</font></font>
<br><b><i><font face="Arial"><font color="#0000FF"><font size=-1>[[TomT]]</font></font></font></i></b>&nbsp;<font face="Arial"><font color="#0000FF"><font size=-1>
It seems like you typed this one a bit quickly.</font></font></font></ul>
</blockquote>
Yes, the example should of course have referred to "dd2" instead of "dd".
<blockquote TYPE=CITE>
<ul><font face="Arial"><font color="#0000FF"><font size=-1>The problem
is that dd/* currently includes within its scope both the individual digit
events and the digit map completion event.&nbsp; If you moved the latter
off to an extension package dd2, then I think we would have:</font></font></font>
<p><font face="Arial"><font color="#0000FF"><font size=-1>&nbsp;- dd/*
reports only individual digit events</font></font></font>
<br><font face="Arial"><font color="#0000FF"><font size=-1>&nbsp;- dd2/*
reports only the digit map completion event.</font></font></font></ul>
</blockquote>
Agreed (report most specific event). The current sentence does not seem
to imply this though unless you qualify it to specifically only reference
the "dd" package.
<p>-- Flemming
<br>&nbsp;</blockquote>
Regards
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Flemming
<br>--
<br>Flemming Andreasen&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Phone: +1 732 452 1667
<br>Cisco Systems&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Fax:&nbsp;&nbsp; +1 240 359 5839
<br>&nbsp;</html>

--------------13BFF7356F9A8CEFCD8F27B6--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Apr  5 21:28:04 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18710
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 5 Apr 2000 21:28:03 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.05889460@standards.nortelnetworks.com>; Wed, 5 Apr 2000 21:22:18 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 119898 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 5 Apr 2000 21:21:13 -0400
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.78FC5050@standards.nortelnetworks.com>; Wed, 5 Apr 2000 21:11:13
          -0400
Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com
          (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id SAA17029; Wed, 5 Apr 2000
          18:16:23 -0700 (PDT)
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <C51ED84B6F47D211917A0000F8BCBD11033227DB@zcard00g.ca.nortel.com>
            <38E8A2F1.C5114CF5@lucent.com> <38EAF51A.6CCD1887@ericsson.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Message-ID:  <38EC1037.4F563AEC@cisco.com>
Date:         Wed, 5 Apr 2000 21:19:04 -0700
Reply-To: Flemming Andreasen <fandreas@CISCO.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Flemming Andreasen <fandreas@CISCO.COM>
Organization: Cisco Systems
Subject:      Re: Summary of Issues Raised On the List
X-To:         Christian Groves <Christian.Groves@ERICSSON.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit

Hi Christian

A couple of comments below

Christian Groves wrote:

> G'Day John, Tom, all,
>
> I've gone through the issues list and have a few comments and
> suggestions. I've also added a few more items on the bottom of the
> email. Please see [CHG] below.
>
> Cheers, Christian
>
> ..snip..
> > > 4. Issues Identified But Not Yet Resolved
> > >
> > >    Section                              Issue
> > >
> > >    6.2.2      Not clear what wildcard union responses look like.
> [CHG]  A suggestion:
>         Add "ie. Given termination Ta with properties p1=a, p2=b, and
>                termination Tb with properties p2=c, p3=d a UNION
>                resonse would be T* p1=a, p2=b,c, p3=d"
> > >
> > >    7.1.1      Third para (discussing unspecified parameters): not clear
> > >               which parameters are mandatory.
> [CHG] This depends on the application I would imagine. Can we really
> give an
> example of a mandatory parameter. Isn't this a statement of behaviour
> rather than what a mandatory parameter is?

I don't think so. The application would reside in the MGC, however the MG would
need to know what to when a parameter is omitted, i.e. either retain previous
value or use default value. We really need a table or something that clearly
shows what will happen for each parameter.

>
>
> > >
> > >    7.1.9      Not clear whether events trigger side effects (e.g.
> > >               signal termination) at time of detection, at time of
> > >               processing (whether or not in active Events Descriptor)
> > >               or at time of notification.
> [CHG] The current text states that "Normally, detection of an event
> shall cause active signals to stop". So this is covered.
>

Indeed it does, however it's "only" specified under EventsDescriptor. Consider
the case of lockstep, where you are currently waiting for a new EvetsDescriptor,
and a signal is playing (say because of KeepActive). An event specified in
EventBuffer Descriptor is now detected. On one hand, you could argue, that by
specifying the event in EventBufferDescriptor you would want the synchronization
to occur (although I'm not convinced that holds) regardless of whether that
event is specified in a subsequent Events Descriptor. However, now consider that
the event in the new Events Descriptor is specified with a KeepActive parameter
- you probably didn't want the syncrhonization to occur then.

I spent a fair amount of time going over this earlier today and ended up
convincing myself that the synchronization should occur at time of processing,
although I'll gladly admit that it's not obvious.


>
> > >
> ..snip..
> > >
> > >    7.3        There should be no error        Delete codes 404, 405,
> > >               responses to TransactionReply   461-467
> > >               or TransactionPending, lest
> > >               they create response loops.
> [CHG] Sounds reasonable
>
> > >
> > >    8          Command execution should be     Not clear what "atomic"
> > >               specified as atomic.            means, particularly
> > >                                               where events and signals
> > >                                               are concerned.
> [CHG] No roll back

Hmm, I think I'm with Brian here.

>
>
> > >
> > >    12.2,      Text indicates that statistics can have the sub-list data
> > >    B.2        type, but ABNF does not support that.
> [CHG] Isn't a list just an octet string? Does there need to be specific
> ABNF. This leads to 12.3. Does a list need to be IANA registered as the
> list name will be unique within a package. Proposal: remove last
> sentence of 12.3
>
> > >
> ..snip..
> > >
> > >    E.1.2      Granularity of signal completion event is too coarse as a
> > >               mechanism to detect signalling failures.
> [CHG] Unless people have more detailed codes I think we can live with
> this. We can in v2 add more enumerations to the list if we need to.

Please see my e-mail to Tom. I was basically proposing that you can specify
which of the Termination Method's you are interested in by adding Termination
Method as an EventsDescriptor parameter. Any objections ?


>
>
> > >
> > >    E.9.2      Stated hook state reporting behaviour has race condition
> > >               where same transition could be reported twice.
> [CHG] Is this in the case of restrart?

No. Please see my e-mail to Tom.

>
>
> > >
> > >    E.10.2     Wording of condition for generating cmp event with
> > >               "success" does not cover case where test also requires
> > >               successful removal of tone.
> [CHG] This is implied. An event stops a signal by default.

Actually, it should have referred to E.10.5 (my fault), where it specifies
something different. Please see my e-mail to Tom

>
>
> > >
> > > 5. Errors For Which Corrections Are Stated
> > >
> > >    This is the only section which will remain in this document after
> > >    the IESG has approved the combination of [2] and the corrections
> > >    stated below.  It describes the errors and ambiguities which have
> > >    been found in [2], along with the corrections they require.
> > >
> > >    Section    Issue                           Resolution
> > >
> ..snip..
> > >    7.1.8      Last bulleted item should       Add "loopback".
> > >               include "loopback" in list of
> > >               possible states.
> [CHG] Should this be section 7.1.7?
>
> ..snip..
>
> John Seger's Notes:
> -------------------
> >
> > 7.2.3   The bullet list at the end of the section mentions provisioned and
> >         default values that contradicts the (older) text in section 6.2.4.
> [CHG] Isn't the default and provisioned value the same thing in this
> case? as per 6.2.4?
>
> Christian's additional comments:
> --------------------------------
> Chp 6.2.5 para 1
> Change:
> Root thus may have properties and events
> To:
> Root thus may have properties, statistics and events
> Reason: Can't root have statistics?
> Chp 7.2.4
> Add:
> The "choose"CHOOSE option is an error, as the Move command may only be
> used on existing Terminations.
> Reason: To align with the subtract command
>
> Chp 7.2.8
> Change:
> The ServiceChangeReason parameter specifies the reason why the
> ServiceChange has or will occur.  It consists of an alphanumeric token
> (IANA registered) and an explanatory string.
> to:
> The ServiceChangeReason parameter specifies the reason why the
> ServiceChange has or will occur.  It consists of an alphanumeric token
> (IANA registered) and an optional explanatory string.
> Reason: The explantory string is optional in the encoding.
>
> Chp 7.2.8 point 1
> Change:
> …establishing new connections using the specified terminations and
> should attempt
> Reason:
> Reads like NO new connections should be made where no connections should
> be made on the specified terminations in the ServiceChange
> Chp 8 Last Paragraph
> Change:
> Applications SHOULD implement an application level timer per
> transaction.
> to:
> Applications SHOULD implement a protocol timer per transaction.
> Reason:
> Its not really timing the application but the protocol

I disagree. It really is an application level timer so I don't see anything
wrong with the sentence.

>
>
> Chp 12.1.2
> Add:
> … independent properties. Properties may also be defined in Local and
> Remote descriptors.
> Reason:
> Reads like properties can only be defined on local control and
> termination state.
>
> A.1
> Change:
> TerminationID 0xFFFFFFFFFFFFFFFF SHALL be used to indicate the ROOT
> Termination.
> to:
> TerminationID with all bits set to 1 (eg. 0xFFFFFFFFFFFFFFFF) SHALL be
> used to indicate the ROOT Termination.
> Reason:
> A terminationID can be from 1bit to 6octets long. If your termination
> scheme is only one octet it makes no sense to use 6 octets for ROOT.
>
> E.2.1
> Add:
> Properties shall be defined in Local Control Descriptor
> Reason:
> Root properties are not defined for any descriptor

-- Flemming

--
Flemming Andreasen                Phone: +1 732 452 1667
Cisco Systems                     Fax:   +1 240 359 5839


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Apr  5 22:24:11 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20320
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 5 Apr 2000 22:24:10 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DB3137F0@standards.nortelnetworks.com>; Wed, 5 Apr 2000 22:18:23 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 119956 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 5 Apr 2000 22:16:43 -0400
Received: from ish7.ericsson.com.au (203.61.155.111) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.3923E300@standards.nortelnetworks.com>; Wed, 5 Apr 2000
          22:06:41 -0400
Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id MAA27872; Thu, 6
          Apr 2000 12:10:24 +1000 (EST)
Received: from mcsi00.epa.ericsson.se (mcsi00 [146.11.8.201]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id MAA05715; Thu, 6
          Apr 2000 12:10:49 +1000 (EST)
Received: from ericsson.com (mcdh183.epa.ericsson.se [146.11.81.183]) by
          mcsi00.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id MAA07094; Thu,
          6 Apr 2000 12:10:18 +1000 (EST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF678110@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38EBF208.8B74DC56@ericsson.com>
Date:         Thu, 6 Apr 2000 12:10:16 +1000
Reply-To: Christian Groves <Christian.Groves@ERICSSON.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Christian Groves <Christian.Groves@ERICSSON.COM>
Subject:      Re: Summary of Issues Raised On the List
X-To:         "Rosen, Brian" <brosen@fore.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Brian,

Please see my comments CHG2 below.

Cheers, Christian

"Rosen, Brian" wrote:
>
> G'Day All (Adelaide is still with me!)
>
> Some comments on your comments to Johns comments to Tom's list
>
> > > >
> > > >    8          Command execution should be     Not clear
> > what "atomic"
> > > >               specified as atomic.            means, particularly
> > > >                                               where
> > events and signals
> > > >                                               are concerned.
> > [CHG] No roll back
>
> Okay, so do you propose descriptors are executed in order?
> What if part of a descriptor had an error?  For example, suppose
> you said ...Signals{one,two} and it correctly applied one,
> but could not apply two due to dsp resource exhaustion.
> What should the state of the MG be?
>
> Wouldn't you agree that it is essential that the MGC know what state
> the MG is following this kind of error?

[CHG2] I agree that the MGC should know the state on the MG following an
error. It should also be responsible for the action after this error.
When I say no rollback what I don't want to see is that given a command
which plays a signal and then fails when is changes a media property
that it doesn't "roll back" the signal. This is irrespective descriptors
processed in order. When you get an error you stop further processing
but it hard to undo previous processing. Rollback on a whole command
isn't valid, Rollback on a certain descriptor that is erroneous probably
is.

>
> > > >    12.2,      Text indicates that statistics can have the
> > sub-list data
> > > >    B.2        type, but ABNF does not support that.
> > [CHG] Isn't a list just an octet string? Does there need to
> > be specific
> > ABNF. This leads to 12.3. Does a list need to be IANA
> > registered as the
> > list name will be unique within a package. Proposal: remove last
> > sentence of 12.3
> You need lists to be IANA registered because multiple extensions
> can be proposed, each extending the list.
>
> I've asked for anyone to come up with a statistic that needed a list
> without any responses.

[CHG2] I don't understand the "multiple extension" concept. If this this
is contained in a package then the package name scopes the extension
that you made to the enumerated list. Can you give an example?
>
> > Chp 7.2.4
> > Add:
> > The "choose"CHOOSE option is an error, as the Move command may only be
> > used on existing Terminations.
> > Reason: To align with the subtract command
> This would have to be clarified.  You can MOVE to a new context. So,
> you might want to say "the CHOOSE option for a TerminationId is an
> error...".  Might want to do the same in Subtract.
> I do agree with the idea however.
[CHG2] Your clarification is good.

>
> > E.2.1
> > Add:
> > Properties shall be defined in Local Control Descriptor
> > Reason:
> > Root properties are not defined for any descriptor
> All of the properties should be defined in Termination State,
> as none of them are stream specific (streams of course have no
> meaning for the Root Termination).
[CHG2] Good point. I'm not particularly bothered on whether it should be
TermState or LocalCont. It just needs to be document.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr  6 00:33:20 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22863
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 6 Apr 2000 00:33:20 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9EFAEC10@standards.nortelnetworks.com>; Thu, 6 Apr 2000 0:25:33 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 120057 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Apr 2000 00:24:11 -0400
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.5C7BE970@standards.nortelnetworks.com>; Thu, 6 Apr 2000 0:23:41
          -0400
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id KAA20736; Thu, 6 Apr
          2000 10:31:00 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          652568B9.0017EB5F ; Thu, 6 Apr 2000 09:51:15 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <652568B9.0017EA5E.00@sandesh.hss.hns.com>
Date:         Thu, 6 Apr 2000 09:51:12 +0530
Reply-To: smahajan@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: smahajan@HSS.HNS.COM
Subject:      Re: MGC-MGC communication
X-To:         "Rosen, Brian" <brosen@FORE.COM>
X-cc:         SIGTRAN@STANDARDS.NORTELNETWORKS.COM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi Brian, I think you missed the important point in the document. it is not
trying to define
any new protocol for MGC-MGC communication rather proposing to use the existing
protocols (SS7, SIGTRAN and MEGACO) for such interface. Moreover i believe that
SS7 is ITU protocol and MEGACO and SIGTRAN are IETF protocols, so where comes
the question of not supporting another application or using it for another
interface,
by ITU and IETF.
I donot think that if somebody comes up with use of MEGACO for some other
interface
(other than MGC-MG), you are going to call it a new protocol definition.
I believe as most of the telecommunication (at the network level) network is
based on
SS7 signaling why not use the same for MGC-MGC, as this is also a trunk
interface or
 may be interface across networks.
Ok, may be let me put your question back to you, if existing standards
(SS7, SIGTRAN and MEGACO) can be used across MGC-MGC interface
why define new one (extension of SIP etc.) for such an interface?

The solution/problem that we were trying to explore is - is SS7 good enough
for MGC-MGC interface, may be it require little modification to protocol or to a
new
definition to the network architecture (new definitions of CIC in packet
network). But
it does give lot many advantages as well.

I haven't seen/read Q.BICC/Q.1901, can you give me pointers to where can i get
these drafts or standards? are these trying to address MGC-MGC communication
or rather a more generic problem which addresses MGC-MGC part as well? How
soon do you think we will get it as standard, as we may need MGC-MGC
interface fixed soon after we start building MGCs and MGs based on MEGACO
(MGC do need to talk).

Regards,
Sunil Mahajan







"Rosen, Brian" <brosen@FORE.COM> on 04/05/2000 01:21:43 AM

Please respond to "Rosen, Brian" <brosen@FORE.COM>

To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
cc:    (bcc: Sunil Mahajan/HSS)

Subject:  Re: MGC-MGC communication




I'd second this.  If you want maximum ISUP compatibility, use
Q.BICC.  If you want more "flexibility", consider SIP (or H.323).
Another standard is, IMHO, unwarranted at this time.  I think
such an attempt would not get support in IETF, or ITU at this time.

Brian

> -----Original Message-----
> From: Stephen Terrill [mailto:stephen.terrill@ERICSSON.COM]
> Sent: Tuesday, April 04, 2000 3:41 PM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: MGC-MGC communication
>
>
> Hi Sunril,
>
> I think that you have overlooked the Q.BICC work which is
> being designed to support the ISDN service set over
> technologies other than STM - and it is a standardised
> interface..  The first phase is completed (supporting ATM
> bearers) - see Q.1901, and Q.765.5 (I think).
>
> The second phase will support IP bearers (both in the
> signalling and for the voice transport) and that is
> activively ongoing now.  There have certainly been
> discussions of using SCTP for the signalling transport, and
> for using H.248/megaco beteween the call and the
> bearer/transport level.
>
> Regards,
>
> ..//steve
>
> smahajan@HSS.HNS.COM wrote:
>
> > Hi All,
> > As there exists multiple protocol options for MGC-MGC
> interface but nothing yet
> > standardized,
> > attached white paper proposes an interface definition
> (protocol) for MGC to MGC
> > communication
> > in SS7 networks based on MEGACOP, SIGTRAN and Packet-SS7 protocols.
> > Another attached document gives backgound on the Packet-SS7
> architecture.
> > Regards,
> > Sunil Mahajan
> > (looking for comments and feedback.............)
> >
> > (See attached file: packet-ss74mgc-mgc.zip)(See attached
> file: packet-ss7.zip)
> >
> >
> --------------------------------------------------------------
> --------------------------------------------------------------
> --------------------------------------------------------------
> --------------------------------------------------------------
> --------------------------------------------------------------
> --------------------------------------------------------------
> --------------------------------------------------------------
> --------------------------------------------------------------
> --------------------------------------------------------------
> --------------------------------------------------------------
> --------------------------------------------------------------
> --------------------------------------------------------------
> --------------------------------------------------------------
> --------------------------------------------------------------
> -------------------------------
> >                                 Name: packet-ss74mgc-mgc.zip
> >    packet-ss74mgc-mgc.zip       Type: Winzip32 File
> (application/zip)
> >                             Encoding: base64
> >                          Description: .ZIP File
> >
> >                         Name: packet-ss7.zip
> >    packet-ss7.zip       Type: Winzip32 File (application/zip)
> >                     Encoding: base64
> >                  Description: .ZIP File
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr  6 06:48:41 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06741
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 6 Apr 2000 06:48:41 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.50D309C0@standards.nortelnetworks.com>; Thu, 6 Apr 2000 6:42:45 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 120198 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Apr 2000 06:41:32 -0400
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.252C6AA0@standards.nortelnetworks.com>; Thu, 6 Apr 2000 6:41:32
          -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id
          MAA28782; Thu, 6 Apr 2000 12:46:43 +0200 (MET DST)
Received: from ericsson.com (kipe69.eraj.ericsson.se [147.214.68.69]) by
          al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id
          MAA27413; Thu, 6 Apr 2000 12:46:41 +0200 (MET DST)
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <652568B9.0017EA5E.00@sandesh.hss.hns.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38EC41A0.8858CBFD@ericsson.com>
Date:         Thu, 6 Apr 2000 09:49:52 +0200
Reply-To: Stephen Terrill <stephen.terrill@ERICSSON.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Stephen Terrill <stephen.terrill@ERICSSON.COM>
Organization: L.M. Ericsson
Subject:      Re: MGC-MGC communication
X-To:         smahajan@HSS.HNS.COM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi,

Regarding Q.BICC (Q.1901), this is availble within the ITU organisaiton, it is defined as a MGC - MGC protocol (although different terminology is used).  It is an adaptation to ISUP to allow for different bearer technologies.  CS-1 (supporting ATM) is complete, CS-2 is scheduled to be completed at the end of this year.

I do tend to agree with Brian, that BICC would be the better protocol if ISDN service set transparence is required, and that SIP / H.323 would be better in the case of Mulitmedia type application are to be supported.

Regards,

..//steve

smahajan@HSS.HNS.COM wrote:

> Hi Brian, I think you missed the important point in the document. it is not
> trying to define
> any new protocol for MGC-MGC communication rather proposing to use the existing
> protocols (SS7, SIGTRAN and MEGACO) for such interface. Moreover i believe that
> SS7 is ITU protocol and MEGACO and SIGTRAN are IETF protocols, so where comes
> the question of not supporting another application or using it for another
> interface,
> by ITU and IETF.
> I donot think that if somebody comes up with use of MEGACO for some other
> interface
> (other than MGC-MG), you are going to call it a new protocol definition.
> I believe as most of the telecommunication (at the network level) network is
> based on
> SS7 signaling why not use the same for MGC-MGC, as this is also a trunk
> interface or
>  may be interface across networks.
> Ok, may be let me put your question back to you, if existing standards
> (SS7, SIGTRAN and MEGACO) can be used across MGC-MGC interface
> why define new one (extension of SIP etc.) for such an interface?
>
> The solution/problem that we were trying to explore is - is SS7 good enough
> for MGC-MGC interface, may be it require little modification to protocol or to a
> new
> definition to the network architecture (new definitions of CIC in packet
> network). But
> it does give lot many advantages as well.
>
> I haven't seen/read Q.BICC/Q.1901, can you give me pointers to where can i get
> these drafts or standards? are these trying to address MGC-MGC communication
> or rather a more generic problem which addresses MGC-MGC part as well? How
> soon do you think we will get it as standard, as we may need MGC-MGC
> interface fixed soon after we start building MGCs and MGs based on MEGACO
> (MGC do need to talk).
>
> Regards,
> Sunil Mahajan
>
> "Rosen, Brian" <brosen@FORE.COM> on 04/05/2000 01:21:43 AM
>
> Please respond to "Rosen, Brian" <brosen@FORE.COM>
>
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> cc:    (bcc: Sunil Mahajan/HSS)
>
> Subject:  Re: MGC-MGC communication
>
> I'd second this.  If you want maximum ISUP compatibility, use
> Q.BICC.  If you want more "flexibility", consider SIP (or H.323).
> Another standard is, IMHO, unwarranted at this time.  I think
> such an attempt would not get support in IETF, or ITU at this time.
>
> Brian
>
> > -----Original Message-----
> > From: Stephen Terrill [mailto:stephen.terrill@ERICSSON.COM]
> > Sent: Tuesday, April 04, 2000 3:41 PM
> > To: MEGACO@standards.nortelnetworks.com
> > Subject: Re: MGC-MGC communication
> >
> >
> > Hi Sunril,
> >
> > I think that you have overlooked the Q.BICC work which is
> > being designed to support the ISDN service set over
> > technologies other than STM - and it is a standardised
> > interface..  The first phase is completed (supporting ATM
> > bearers) - see Q.1901, and Q.765.5 (I think).
> >
> > The second phase will support IP bearers (both in the
> > signalling and for the voice transport) and that is
> > activively ongoing now.  There have certainly been
> > discussions of using SCTP for the signalling transport, and
> > for using H.248/megaco beteween the call and the
> > bearer/transport level.
> >
> > Regards,
> >
> > ..//steve
> >
> > smahajan@HSS.HNS.COM wrote:
> >
> > > Hi All,
> > > As there exists multiple protocol options for MGC-MGC
> > interface but nothing yet
> > > standardized,
> > > attached white paper proposes an interface definition
> > (protocol) for MGC to MGC
> > > communication
> > > in SS7 networks based on MEGACOP, SIGTRAN and Packet-SS7 protocols.
> > > Another attached document gives backgound on the Packet-SS7
> > architecture.
> > > Regards,
> > > Sunil Mahajan
> > > (looking for comments and feedback.............)
> > >
> > > (See attached file: packet-ss74mgc-mgc.zip)(See attached
> > file: packet-ss7.zip)
> > >
> > >
> > --------------------------------------------------------------
> > --------------------------------------------------------------
> > --------------------------------------------------------------
> > --------------------------------------------------------------
> > --------------------------------------------------------------
> > --------------------------------------------------------------
> > --------------------------------------------------------------
> > --------------------------------------------------------------
> > --------------------------------------------------------------
> > --------------------------------------------------------------
> > --------------------------------------------------------------
> > --------------------------------------------------------------
> > --------------------------------------------------------------
> > --------------------------------------------------------------
> > -------------------------------
> > >                                 Name: packet-ss74mgc-mgc.zip
> > >    packet-ss74mgc-mgc.zip       Type: Winzip32 File
> > (application/zip)
> > >                             Encoding: base64
> > >                          Description: .ZIP File
> > >
> > >                         Name: packet-ss7.zip
> > >    packet-ss7.zip       Type: Winzip32 File (application/zip)
> > >                     Encoding: base64
> > >                  Description: .ZIP File
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr  6 08:19:39 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07397
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 6 Apr 2000 08:19:38 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.08CB2CE0@standards.nortelnetworks.com>; Thu, 6 Apr 2000 8:13:48 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 120227 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Apr 2000 08:11:55 -0400
Received: from mailcity.com (209.1.236.7) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.5FD72E50@standards.nortelnetworks.com>; Thu, 6 Apr 2000 8:01:55
          -0400
Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Thu Apr  6 05:05:47
          2000
Mime-Version: 1.0
X-Sent-Mail: off
X-Expiredinmiddle: true
X-Mailer: MailCity Service
X-Sender-Ip: 12.10.198.190
Content-Type: text/plain; charset=us-ascii
Content-Language: en
Content-Transfer-Encoding: 7bit
Message-ID:  <DKGPCAGIKGEEBAAA@mailcity.com>
Date:         Thu, 6 Apr 2000 05:05:47 -0700
Reply-To: marc_mathew@mailcity.com
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Marc Mathew <marc_mathew@mailcity.com>
Organization: MailCity  (http://www.mailcity.lycos.com:80)
Subject:      clarification
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi,

   Can anyone please tell me what modem descriptor is used for. Should modem not be specified as a seperate package (NAS ?). Isn't modem a different kind of termination. Why is there a seperate descriptor for it.

Always,
Marc


Send FREE April Fool's Greetings to your friends!
http://www.whowhere.lycos.com/redirects/American_Greetings.rdct


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr  6 09:54:04 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08329
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 6 Apr 2000 09:54:03 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.33498CC0@standards.nortelnetworks.com>; Thu, 6 Apr 2000 9:48:02 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 120332 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Apr 2000 09:46:51 -0400
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.A289FF40@standards.nortelnetworks.com>; Thu, 6 Apr 2000 9:36:50
          -0400
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id JAA14857; Thu, 6 Apr
          2000 09:42:06 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id JAA10213; Thu, 6 Apr
          2000 09:42:09 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <2MSFSYL6>; Thu, 6 Apr 2000 09:37:16 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF67811F@whq-msgusr-02.fore.com>
Date:         Thu, 6 Apr 2000 09:42:07 -0400
Reply-To: "Rosen, Brian" <brosen@FORE.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <brosen@FORE.COM>
Subject:      Re: MGC-MGC communication
X-To:         "smahajan@hss.hns.com" <smahajan@hss.hns.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Sunil

I think Christian and Steve have covered this, but just in case:
Q.BICC (Q.1901) is now available from ITU.  It is a very simple
extension to ISUP that allows you to carry the address/port of the
MG plus an identifying token (BNC-ID) that lets you correlate
the narrowband signalling with the broadband signalling.
Both of those features are required in order to use ISUP for
signalling with IP or ATM (or FR or ...) bearers, as I'm sure
you would discover if you thought about it.  You can argue over
where to put those things, and that is what Q.BICC answers.
So, it does exactly what you proposed to do, use ISUP for MGC to
MGC communications. Q.1901 is ISUP with one additional message
and one additional IE.

If you want an ISUP based way to build voice over packet/cell
systems, then Q.BICC is the answer, and I really don't think
there is any support for different answers.

SG11, which developed Q.BICC, is now looking into using Megaco
(H.248) for decomposed gateways that use Q.BICC -- the current
Q.1901 does not define the MG/MGC interface (they call it
BCF/CSF).  The present Q.1901 only defines ATM bearers, but
there is work underway to define IP bearers.

Q.1901 should be available from the usual ITU sources (TIES).
There are various drafts around in the T1S1 website.

In addition, there is SIP and H.323.  I'm more aware of the
SIP-ISUP interworking issues than the H.323-ISUP interworking
efforts.  The former is nearing completion.  There is a
draft out which contains a mapping of SIP and ISUP messages.
There is a mechanism to tunnel ISUP messages and IEs that have
no SIP equivalent across a SIP signaled network, and there
is a new method, INFO, that handles mid call events.  I would
expect that this effort will finish sometime this year.  Of course,
there are already complete systems that simply use SIP (and others
that use H.323) as the MGC-MGC protocol.  The ISUP interwork is
required to connect such systems to the PSTN in a standard way.

Brian

> -----Original Message-----
> From: smahajan@hss.hns.com [mailto:smahajan@hss.hns.com]
> Sent: Thursday, April 06, 2000 12:21 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: MGC-MGC communication
>
>
> Hi Brian, I think you missed the important point in the
> document. it is not
> trying to define
> any new protocol for MGC-MGC communication rather proposing
> to use the existing
> protocols (SS7, SIGTRAN and MEGACO) for such interface.
> Moreover i believe that
> SS7 is ITU protocol and MEGACO and SIGTRAN are IETF
> protocols, so where comes
> the question of not supporting another application or using
> it for another
> interface,
> by ITU and IETF.
> I donot think that if somebody comes up with use of MEGACO
> for some other
> interface
> (other than MGC-MG), you are going to call it a new protocol
> definition.
> I believe as most of the telecommunication (at the network
> level) network is
> based on
> SS7 signaling why not use the same for MGC-MGC, as this is
> also a trunk
> interface or
>  may be interface across networks.
> Ok, may be let me put your question back to you, if existing standards
> (SS7, SIGTRAN and MEGACO) can be used across MGC-MGC interface
> why define new one (extension of SIP etc.) for such an interface?
>
> The solution/problem that we were trying to explore is - is
> SS7 good enough
> for MGC-MGC interface, may be it require little modification
> to protocol or to a
> new
> definition to the network architecture (new definitions of
> CIC in packet
> network). But
> it does give lot many advantages as well.
>
> I haven't seen/read Q.BICC/Q.1901, can you give me pointers
> to where can i get
> these drafts or standards? are these trying to address
> MGC-MGC communication
> or rather a more generic problem which addresses MGC-MGC part
> as well? How
> soon do you think we will get it as standard, as we may need MGC-MGC
> interface fixed soon after we start building MGCs and MGs
> based on MEGACO
> (MGC do need to talk).
>
> Regards,
> Sunil Mahajan
>
>
>
>
>
>
>
> "Rosen, Brian" <brosen@FORE.COM> on 04/05/2000 01:21:43 AM
>
> Please respond to "Rosen, Brian" <brosen@FORE.COM>
>
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> cc:    (bcc: Sunil Mahajan/HSS)
>
> Subject:  Re: MGC-MGC communication
>
>
>
>
> I'd second this.  If you want maximum ISUP compatibility, use
> Q.BICC.  If you want more "flexibility", consider SIP (or H.323).
> Another standard is, IMHO, unwarranted at this time.  I think
> such an attempt would not get support in IETF, or ITU at this time.
>
> Brian
>
> > -----Original Message-----
> > From: Stephen Terrill [mailto:stephen.terrill@ERICSSON.COM]
> > Sent: Tuesday, April 04, 2000 3:41 PM
> > To: MEGACO@standards.nortelnetworks.com
> > Subject: Re: MGC-MGC communication
> >
> >
> > Hi Sunril,
> >
> > I think that you have overlooked the Q.BICC work which is
> > being designed to support the ISDN service set over
> > technologies other than STM - and it is a standardised
> > interface..  The first phase is completed (supporting ATM
> > bearers) - see Q.1901, and Q.765.5 (I think).
> >
> > The second phase will support IP bearers (both in the
> > signalling and for the voice transport) and that is
> > activively ongoing now.  There have certainly been
> > discussions of using SCTP for the signalling transport, and
> > for using H.248/megaco beteween the call and the
> > bearer/transport level.
> >
> > Regards,
> >
> > ..//steve
> >
> > smahajan@HSS.HNS.COM wrote:
> >
> > > Hi All,
> > > As there exists multiple protocol options for MGC-MGC
> > interface but nothing yet
> > > standardized,
> > > attached white paper proposes an interface definition
> > (protocol) for MGC to MGC
> > > communication
> > > in SS7 networks based on MEGACOP, SIGTRAN and Packet-SS7
> protocols.
> > > Another attached document gives backgound on the Packet-SS7
> > architecture.
> > > Regards,
> > > Sunil Mahajan
> > > (looking for comments and feedback.............)
> > >
> > > (See attached file: packet-ss74mgc-mgc.zip)(See attached
> > file: packet-ss7.zip)
> > >
> > >
> > --------------------------------------------------------------
> > --------------------------------------------------------------
> > --------------------------------------------------------------
> > --------------------------------------------------------------
> > --------------------------------------------------------------
> > --------------------------------------------------------------
> > --------------------------------------------------------------
> > --------------------------------------------------------------
> > --------------------------------------------------------------
> > --------------------------------------------------------------
> > --------------------------------------------------------------
> > --------------------------------------------------------------
> > --------------------------------------------------------------
> > --------------------------------------------------------------
> > -------------------------------
> > >                                 Name: packet-ss74mgc-mgc.zip
> > >    packet-ss74mgc-mgc.zip       Type: Winzip32 File
> > (application/zip)
> > >                             Encoding: base64
> > >                          Description: .ZIP File
> > >
> > >                         Name: packet-ss7.zip
> > >    packet-ss7.zip       Type: Winzip32 File (application/zip)
> > >                     Encoding: base64
> > >                  Description: .ZIP File
> >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr  6 10:36:45 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09093
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 6 Apr 2000 10:36:44 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CD83B860@standards.nortelnetworks.com>; Thu, 6 Apr 2000 10:28:09 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 120407 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Apr 2000 10:26:47 -0400
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.C1015120@standards.nortelnetworks.com>; Thu, 6 Apr 2000 10:20:38
          -0400
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id UAA19941; Thu, 6 Apr
          2000 20:15:42 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          652568B9.004D7350 ; Thu, 6 Apr 2000 19:35:57 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <652568B9.004D710C.00@sandesh.hss.hns.com>
Date:         Thu, 6 Apr 2000 19:35:51 +0530
Reply-To: smahajan@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: smahajan@HSS.HNS.COM
Subject:      Re: MGC-MGC communication
X-To:         "Rosen, Brian" <brosen@fore.com>,
              kawa@nortelnetworks.com, stephen.terrill@ericsson.com
X-cc:         SIGTRAN@standards.nortelnetworks.com
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Brian, Stephen, Kawa
Thanx a lot for the information. I donot have access to ITU-T TIES site, but i
will try to get it
from other sources as mentioned in your mails. But in case if you have copy of
these
documents (Q.BICC and Q.1901), can you please send it to me.
Regards,
Sunil Mahajan





"Rosen, Brian" <brosen@fore.com> on 04/06/2000 07:12:07 PM

To:   Sunil Mahajan/HSS@HSS, MEGACO@standards.nortelnetworks.com
cc:

Subject:  RE: MGC-MGC communication




Sunil

I think Christian and Steve have covered this, but just in case:
Q.BICC (Q.1901) is now available from ITU.  It is a very simple
extension to ISUP that allows you to carry the address/port of the
MG plus an identifying token (BNC-ID) that lets you correlate
the narrowband signalling with the broadband signalling.
Both of those features are required in order to use ISUP for
signalling with IP or ATM (or FR or ...) bearers, as I'm sure
you would discover if you thought about it.  You can argue over
where to put those things, and that is what Q.BICC answers.
So, it does exactly what you proposed to do, use ISUP for MGC to
MGC communications. Q.1901 is ISUP with one additional message
and one additional IE.

If you want an ISUP based way to build voice over packet/cell
systems, then Q.BICC is the answer, and I really don't think
there is any support for different answers.

SG11, which developed Q.BICC, is now looking into using Megaco
(H.248) for decomposed gateways that use Q.BICC -- the current
Q.1901 does not define the MG/MGC interface (they call it
BCF/CSF).  The present Q.1901 only defines ATM bearers, but
there is work underway to define IP bearers.

Q.1901 should be available from the usual ITU sources (TIES).
There are various drafts around in the T1S1 website.

In addition, there is SIP and H.323.  I'm more aware of the
SIP-ISUP interworking issues than the H.323-ISUP interworking
efforts.  The former is nearing completion.  There is a
draft out which contains a mapping of SIP and ISUP messages.
There is a mechanism to tunnel ISUP messages and IEs that have
no SIP equivalent across a SIP signaled network, and there
is a new method, INFO, that handles mid call events.  I would
expect that this effort will finish sometime this year.  Of course,
there are already complete systems that simply use SIP (and others
that use H.323) as the MGC-MGC protocol.  The ISUP interwork is
required to connect such systems to the PSTN in a standard way.

Brian

> -----Original Message-----
> From: smahajan@hss.hns.com [mailto:smahajan@hss.hns.com]
> Sent: Thursday, April 06, 2000 12:21 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: MGC-MGC communication
>
>
> Hi Brian, I think you missed the important point in the
> document. it is not
> trying to define
> any new protocol for MGC-MGC communication rather proposing
> to use the existing
> protocols (SS7, SIGTRAN and MEGACO) for such interface.
> Moreover i believe that
> SS7 is ITU protocol and MEGACO and SIGTRAN are IETF
> protocols, so where comes
> the question of not supporting another application or using
> it for another
> interface,
> by ITU and IETF.
> I donot think that if somebody comes up with use of MEGACO
> for some other
> interface
> (other than MGC-MG), you are going to call it a new protocol
> definition.
> I believe as most of the telecommunication (at the network
> level) network is
> based on
> SS7 signaling why not use the same for MGC-MGC, as this is
> also a trunk
> interface or
>  may be interface across networks.
> Ok, may be let me put your question back to you, if existing standards
> (SS7, SIGTRAN and MEGACO) can be used across MGC-MGC interface
> why define new one (extension of SIP etc.) for such an interface?
>
> The solution/problem that we were trying to explore is - is
> SS7 good enough
> for MGC-MGC interface, may be it require little modification
> to protocol or to a
> new
> definition to the network architecture (new definitions of
> CIC in packet
> network). But
> it does give lot many advantages as well.
>
> I haven't seen/read Q.BICC/Q.1901, can you give me pointers
> to where can i get
> these drafts or standards? are these trying to address
> MGC-MGC communication
> or rather a more generic problem which addresses MGC-MGC part
> as well? How
> soon do you think we will get it as standard, as we may need MGC-MGC
> interface fixed soon after we start building MGCs and MGs
> based on MEGACO
> (MGC do need to talk).
>
> Regards,
> Sunil Mahajan
>
>
>
>
>
>
>
> "Rosen, Brian" <brosen@FORE.COM> on 04/05/2000 01:21:43 AM
>
> Please respond to "Rosen, Brian" <brosen@FORE.COM>
>
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> cc:    (bcc: Sunil Mahajan/HSS)
>
> Subject:  Re: MGC-MGC communication
>
>
>
>
> I'd second this.  If you want maximum ISUP compatibility, use
> Q.BICC.  If you want more "flexibility", consider SIP (or H.323).
> Another standard is, IMHO, unwarranted at this time.  I think
> such an attempt would not get support in IETF, or ITU at this time.
>
> Brian
>
> > -----Original Message-----
> > From: Stephen Terrill [mailto:stephen.terrill@ERICSSON.COM]
> > Sent: Tuesday, April 04, 2000 3:41 PM
> > To: MEGACO@standards.nortelnetworks.com
> > Subject: Re: MGC-MGC communication
> >
> >
> > Hi Sunril,
> >
> > I think that you have overlooked the Q.BICC work which is
> > being designed to support the ISDN service set over
> > technologies other than STM - and it is a standardised
> > interface..  The first phase is completed (supporting ATM
> > bearers) - see Q.1901, and Q.765.5 (I think).
> >
> > The second phase will support IP bearers (both in the
> > signalling and for the voice transport) and that is
> > activively ongoing now.  There have certainly been
> > discussions of using SCTP for the signalling transport, and
> > for using H.248/megaco beteween the call and the
> > bearer/transport level.
> >
> > Regards,
> >
> > ..//steve
> >
> > smahajan@HSS.HNS.COM wrote:
> >
> > > Hi All,
> > > As there exists multiple protocol options for MGC-MGC
> > interface but nothing yet
> > > standardized,
> > > attached white paper proposes an interface definition
> > (protocol) for MGC to MGC
> > > communication
> > > in SS7 networks based on MEGACOP, SIGTRAN and Packet-SS7
> protocols.
> > > Another attached document gives backgound on the Packet-SS7
> > architecture.
> > > Regards,
> > > Sunil Mahajan
> > > (looking for comments and feedback.............)
> > >
> > > (See attached file: packet-ss74mgc-mgc.zip)(See attached
> > file: packet-ss7.zip)
> > >
> > >
> > --------------------------------------------------------------
> > --------------------------------------------------------------
> > --------------------------------------------------------------
> > --------------------------------------------------------------
> > --------------------------------------------------------------
> > --------------------------------------------------------------
> > --------------------------------------------------------------
> > --------------------------------------------------------------
> > --------------------------------------------------------------
> > --------------------------------------------------------------
> > --------------------------------------------------------------
> > --------------------------------------------------------------
> > --------------------------------------------------------------
> > --------------------------------------------------------------
> > -------------------------------
> > >                                 Name: packet-ss74mgc-mgc.zip
> > >    packet-ss74mgc-mgc.zip       Type: Winzip32 File
> > (application/zip)
> > >                             Encoding: base64
> > >                          Description: .ZIP File
> > >
> > >                         Name: packet-ss7.zip
> > >    packet-ss7.zip       Type: Winzip32 File (application/zip)
> > >                     Encoding: base64
> > >                  Description: .ZIP File
> >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr  6 10:36:45 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09097
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 6 Apr 2000 10:36:45 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F1AB1760@standards.nortelnetworks.com>; Thu, 6 Apr 2000 10:29:09 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 120400 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Apr 2000 10:28:08 -0400
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.6796B120@standards.nortelnetworks.com>; Thu, 6 Apr 2000 10:18:08
          -0400
Message-ID:  <MEGACO%2000040610280846@STANDARDS.NORTELNETWORKS.COM>
Date:         Thu, 6 Apr 2000 10:16:50 -0400
Reply-To: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Subject:      Re: Choosing of ephemeral / physical Termination.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Tom,

I was searching through the archives but I am not sure this issue was
settled.
Have you make a final decision on this issue yet?
Is it reflected somewhere in the latest version of the Standard?


Thanks
Chuong


On Thu, 27 Jan 2000 15:09:24 -0600, Tom-PT Taylor
<taylor@NORTELNETWORKS.COM> wrote:

>I think one could interpret Context=${Add=${}} as follows:
>
>"Create a new context.  Allocate a terminationID and any software resources
>required to hold more information about that termination when that
>information is provided.  Return an error if there is any attempt to
>activate a media flow before there is enough information to do so."  Not
>sure why you'd do this really -- it means extra messaging to follow up.
>
>
>> -----Original Message-----
>> From: Rosen, Brian [SMTP:brosen@FORE.COM]
>> Sent: Wednesday, January 26, 2000 4:07 PM
>> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
>> Subject:      Re: Choosing of ephemeral / physical Termination.
>>
>> Generally determined by the "kind" of termination requested.
>> Which is in turn, easily discernable from the Media command.
>>
>> However, upon reflection, I think it's not a good answer.
>> I'd propose that we not allow selection of a physical termination,
>> in which case choose is always create an ephemeral.  In particular,
>> the following is perfectly legal:
>> Context=${Add=${}}
>> What do you get?
>>
>> Brian
>>
>> > -----Original Message-----
>> > From: Sachin Mittal [mailto:samittal@hss.hns.com]
>> > Sent: Tuesday, January 25, 2000 9:01 AM
>> > To: MEGACO@standards.nortelnetworks.com
>> > Subject: Choosing of ephemeral / physical Termination.
>> >
>> >
>> > Annex B.1 says that "The CHOOSE TerminationID $ may be used
>> > to signal to the MG
>> > that it has to create an
>> > ephemeral Termination or select an idle physical Termination".
>> > How can MG determine when to create an ephemeral termination
>> > and when to choose
>> > idle physical termination.??
>> > What is the logic behind this decision making?
>> >
>> > regards
>> > -Sachin Mittal
>> >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr  6 10:58:03 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09406
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 6 Apr 2000 10:58:02 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2CFFF760@standards.nortelnetworks.com>; Thu, 6 Apr 2000 10:52:17 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 120494 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Apr 2000 10:50:35 -0400
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.8A3AEB30@standards.nortelnetworks.com>; Thu, 6 Apr 2000 10:40:35
          -0400
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id KAA22373; Thu, 6 Apr
          2000 10:45:50 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id KAA25891; Thu, 6 Apr
          2000 10:45:52 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <2MSFS5H1>; Thu, 6 Apr 2000 10:40:59 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF678125@whq-msgusr-02.fore.com>
Date:         Thu, 6 Apr 2000 10:45:50 -0400
Reply-To: "Rosen, Brian" <brosen@FORE.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <brosen@FORE.COM>
Subject:      Re: Choosing of ephemeral / physical Termination.
X-To:         Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I'm okay with this interpretation.  I'll note that there is
no way to address this termination for media to flow,
so you can't get an error from that.  What might be a
problem is doing something to it before using a media
descriptor.  For example, putting a signal on it.

I will note that allowing this DOES complicate the design
of an MG.  Probably not too much.

Brian

> -----Original Message-----
> From: Chuong Nguyen [mailto:Chuong.Nguyen@USA.ALCATEL.COM]
> Sent: Thursday, April 06, 2000 10:17 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: Choosing of ephemeral / physical Termination.
>
>
> Tom,
>
> I was searching through the archives but I am not sure this issue was
> settled.
> Have you make a final decision on this issue yet?
> Is it reflected somewhere in the latest version of the Standard?
>
>
> Thanks
> Chuong
>
>
> On Thu, 27 Jan 2000 15:09:24 -0600, Tom-PT Taylor
> <taylor@NORTELNETWORKS.COM> wrote:
>
> >I think one could interpret Context=${Add=${}} as follows:
> >
> >"Create a new context.  Allocate a terminationID and any
> software resources
> >required to hold more information about that termination when that
> >information is provided.  Return an error if there is any attempt to
> >activate a media flow before there is enough information to
> do so."  Not
> >sure why you'd do this really -- it means extra messaging to
> follow up.
> >
> >
> >> -----Original Message-----
> >> From: Rosen, Brian [SMTP:brosen@FORE.COM]
> >> Sent: Wednesday, January 26, 2000 4:07 PM
> >> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> >> Subject:      Re: Choosing of ephemeral / physical Termination.
> >>
> >> Generally determined by the "kind" of termination requested.
> >> Which is in turn, easily discernable from the Media command.
> >>
> >> However, upon reflection, I think it's not a good answer.
> >> I'd propose that we not allow selection of a physical termination,
> >> in which case choose is always create an ephemeral.  In particular,
> >> the following is perfectly legal:
> >> Context=${Add=${}}
> >> What do you get?
> >>
> >> Brian
> >>
> >> > -----Original Message-----
> >> > From: Sachin Mittal [mailto:samittal@hss.hns.com]
> >> > Sent: Tuesday, January 25, 2000 9:01 AM
> >> > To: MEGACO@standards.nortelnetworks.com
> >> > Subject: Choosing of ephemeral / physical Termination.
> >> >
> >> >
> >> > Annex B.1 says that "The CHOOSE TerminationID $ may be used
> >> > to signal to the MG
> >> > that it has to create an
> >> > ephemeral Termination or select an idle physical Termination".
> >> > How can MG determine when to create an ephemeral termination
> >> > and when to choose
> >> > idle physical termination.??
> >> > What is the logic behind this decision making?
> >> >
> >> > regards
> >> > -Sachin Mittal
> >> >
> >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Apr  7 09:33:36 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07916
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 7 Apr 2000 09:33:35 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.28E0FD60@standards.nortelnetworks.com>; Fri, 7 Apr 2000 9:25:05 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 121034 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Apr 2000 09:23:15 -0400
Received: from titanium.noida.hclt.com (204.160.248.252) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.7F30B3B0@standards.nortelnetworks.com>; Fri, 7 Apr 2000 9:13:11
          -0400
Received: from nilesh (nileshs [204.160.252.48]) by titanium.noida.hclt.com
          (8.8.7/8.8.7) with SMTP id SAA28897 for
          <MEGACO@standards.nortelnetworks.com>; Fri, 7 Apr 2000 18:48:27 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_008A_01BFA0C2.8085DFA0"
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:  <008d01bfa094$6ba1c0f0$30fca0cc@noida.hclt.com>
Date:         Fri, 7 Apr 2000 18:53:03 +0530
Reply-To: nilesh <nilesh@NOIDA.HCLT.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: nilesh <nilesh@NOIDA.HCLT.COM>
Subject:      subscribe
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_008A_01BFA0C2.8085DFA0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



------=_NextPart_000_008A_01BFA0C2.8085DFA0
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_008A_01BFA0C2.8085DFA0--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Apr  7 12:55:41 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12395
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 7 Apr 2000 12:55:41 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B621A910@standards.nortelnetworks.com>; Fri, 7 Apr 2000 12:49:28 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 121314 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Apr 2000 12:47:37 -0400
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.0E2A5A00@standards.nortelnetworks.com>; Fri, 7 Apr 2000 12:37:37
          -0400
Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com
          (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id JAA14667 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 7 Apr 2000 09:42:57 -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:  <38EE3AE4.63FE012E@cisco.com>
Date:         Fri, 7 Apr 2000 12:45:40 -0700
Reply-To: Flemming Andreasen <fandreas@CISCO.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Flemming Andreasen <fandreas@CISCO.COM>
Organization: Cisco Systems
Subject:      EventBufferDescriptor question
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Considering the definition given in Section 7.1.10, can somebody explain
why EventBufferDescriptor is defined as "sequence of ObservedEvent" ?

Thanks

        Flemming

--
Flemming Andreasen                Phone: +1 732 452 1667
Cisco Systems                     Fax:   +1 240 359 5839


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Apr  7 12:55:42 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12397
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 7 Apr 2000 12:55:42 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B6A4BBC0@standards.nortelnetworks.com>; Fri, 7 Apr 2000 12:49:29 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 121315 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Apr 2000 12:48:14 -0400
Received: from fw7.usa.alcatel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.23C5A9A0@standards.nortelnetworks.com>; Fri, 7 Apr 2000 12:38:13
          -0400
Received: (from uucp@localhost) by fw7.usa.alcatel.com (8.8.8+Sun/8.8.8) id
          LAA26783 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 7 Apr 2000
          11:42:46 -0500 (CDT)
Received: from <Chuong.Nguyen@usa.alcatel.com> (relay2.usa.alcatel.com
          [143.209.238.7]) by fw7 via smap (V2.1) id xma026707; Fri, 7 Apr 00
          11:42:35 -0500
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 LAA15413 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 7 Apr 2000 11:44:35 -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 LAA02593 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 7
          Apr 2000 11:42:40 -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 LAA19788
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 7 Apr 2000 11:42:40
          -0500 (CDT)
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="------------9AACEF1FE313D12BFEDDB218"
Message-ID:  <38EE0FFF.39125FDA@usa.alcatel.com>
Date:         Fri, 7 Apr 2000 11:42:40 -0500
Reply-To: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Subject:      LocalControl Descriptor
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--------------9AACEF1FE313D12BFEDDB218
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi

I asked this question before maybe in a different but I don't think that
I got a response or
clarification in the latest version.

Maybe I will try again w/an example.


Section 7.1.7 LocalControl Descriptor
"The allowed values for the mode property are send-only, receive-only,
send/receive,
inactive and loop-back.  "Send" and "receive" are with respect to the
exterior of the context,
so that, for example, a stream set to mode=sendonly does not pass
received media
into the context.  Signals and Events are not affected by mode."

If I have the following sceanrio


         MG1
MG2                                            CO
    _________________
_________________              _______________
    |                                |
|                                   |
|                             |
    | TDM--*--RTP  |--------|  RTP--*--TDM
------|                             |
    |                                |
|                                   |
|                             |
    |------------|                     |-------------|
|-----------|


MG1 TDM termination is set to sendrecv.
MG1 RTP termination is set to receive only.

MG1 TDM termination is set to inactive.
MG1 RTP termination is set to inactive.

MGC sends the following transaction to MG2 to do a Continuity Test:

Transaction=1{Context=1{Modify=TDM{Signals={ct/ct}, Events=123{ct/cmp}
}}}

The questions that I have are (keep in mind of the definition of mode
and the relationship
of signal and mode as described in Section 7.1.7 above):

1) Since the MG2 TDM termination mode is inactive, does a ct signal get
send to CO?
     The answer should be yes since "Signals and Events are not affected
by mode.".

2) Since the MG2 RTP termination mode is inactive, does a ct signal gets
propagated to
     MG1 RTP terminaiton?
     The answer should be no since the termination mode is inactive.

3) Even though MG2 TDM termination is inactive, with the above
transaction would I
     still have performed a valid COT between the TDM termination and
CO?

4) Does signal get propagated out of the context regardless of mode via
whatever terminations
     are in the context?
     If there is a link between 2 MGs contexts, does a signal applied to
MG2 termination get
     propagate out of MG2 context and into MG1 context?

5) What does loopback really mean?  Can someone provide an example?
      " "Send" and "receive" are with respect to the exterior of the
context, ...."
      Does loopback on a RTP termination mean that media flows into the
context via
      the RTP termination and flows back out of the context.? That media
does not flow
      into the TDM termination.  Thus that same media does not flow out
of context via
      the TDM termination.
      Was loopback intended for COT initiated by CO?  But with the
definition that signal
       is not affected by mode, how is loopback used with COT signal?

Am I even approaching this COT correctly?



Thanks
Chuong



--
  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 ****



--------------9AACEF1FE313D12BFEDDB218
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi
<p>I asked this question before maybe in a different but I don't think
that I got a response or
<br>clarification in the latest version.
<p>Maybe I&nbsp;will try again w/an example.
<br>&nbsp;
<p>Section 7.1.7 LocalControl Descriptor
<br>"The allowed values for the mode property are send-only, receive-only,
send/receive,
<br>inactive and loop-back.&nbsp; "Send" and "receive" are with respect
to the exterior of the context,
<br>so that, for example, a stream set to mode=sendonly does not pass received
media
<br>into the context.&nbsp; Signals and Events are not affected by mode."
<p>If I have the following sceanrio
<br>&nbsp;
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MG1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
MG2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
CO
<br>&nbsp;&nbsp;&nbsp; _________________&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
_________________&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
_______________
<br>&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|
<br>&nbsp;&nbsp;&nbsp; | TDM--*--RTP&nbsp; |--------|&nbsp; RTP--*--TDM
------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|
<br>&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|
<br>&nbsp;&nbsp;&nbsp; |------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|-------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|-----------|
<br>&nbsp;
<p>MG1 TDM termination is set to sendrecv.
<br>MG1 RTP termination is set to receive only.
<p>MG1 TDM termination is set to inactive.
<br>MG1 RTP termination is set to inactive.
<p>MGC sends the following transaction to MG2 to do a Continuity Test:
<p>Transaction=1{Context=1{Modify=TDM{Signals={ct/ct}, Events=123{ct/cmp}
}}}
<p>The questions that I have are (keep in mind of the definition of mode
and the relationship
<br>of signal and mode as described in Section 7.1.7 above):
<p>1) Since the MG2 TDM termination mode is inactive, does a ct signal
get send to CO?
<br>&nbsp;&nbsp;&nbsp;&nbsp; The answer should be yes since "Signals and
Events are not affected by mode.".
<p>2) Since the MG2 RTP termination mode is inactive, does a ct signal
gets propagated to
<br>&nbsp;&nbsp;&nbsp;&nbsp; MG1 RTP terminaiton?
<br>&nbsp;&nbsp;&nbsp;&nbsp; The answer should be no since the termination
mode is inactive.
<p>3) Even though MG2 TDM termination is inactive, with the above transaction
would I
<br>&nbsp;&nbsp;&nbsp;&nbsp; still have performed a valid COT between the
TDM termination and CO?
<p>4) Does signal get propagated out of the context regardless of mode
via whatever terminations
<br>&nbsp;&nbsp;&nbsp;&nbsp; are in the context?
<br>&nbsp;&nbsp;&nbsp;&nbsp; If there is a link between 2 MGs contexts,
does a signal applied to MG2 termination get
<br>&nbsp;&nbsp;&nbsp;&nbsp; propagate out of MG2 context and into MG1
context?
<p>5) What does loopback really mean?&nbsp; Can someone provide an example?
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; " "Send" and "receive" are with respect
to the exterior of the context, ...."
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Does loopback on a RTP termination mean
that media flows into the context via
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the RTP termination and flows back out
of the context.? That media does not flow
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; into the TDM termination.&nbsp; Thus
that same media does not flow out of context via
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the TDM termination.
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Was loopback intended for COT initiated
by CO?&nbsp; But with the definition that signal
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; is not affected by mode, how is
loopback used with COT signal?
<p>Am I&nbsp;even approaching this COT correctly?
<br>&nbsp;
<br>&nbsp;
<p>Thanks
<br>Chuong
<br>&nbsp;
<br>&nbsp;
<pre>--&nbsp;
&nbsp; Alcatel USA, Inc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Internet: Chuong.Nguyen@usa.alcatel.com
&nbsp; 1000 Coit Road Plano, Texas 75075&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Phone:&nbsp;&nbsp;&nbsp; (972) 519-4613
&nbsp; **** The opinions expressed are not those of Alcatel USA, Inc ****</pre>
&nbsp;</html>

--------------9AACEF1FE313D12BFEDDB218--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Apr  7 15:44:29 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16606
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 7 Apr 2000 15:44:29 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5A1B89C0@standards.nortelnetworks.com>; Fri, 7 Apr 2000 15:38:42 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 121488 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Apr 2000 15:37:28 -0400
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.C86678B0@standards.nortelnetworks.com>; Fri, 7 Apr 2000 15:27:28
          -0400
Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com
          (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id MAA23813 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 7 Apr 2000 12:32:49 -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:  <38EE62B3.DFE94BAA@cisco.com>
Date:         Fri, 7 Apr 2000 15:35:31 -0700
Reply-To: Flemming Andreasen <fandreas@CISCO.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Flemming Andreasen <fandreas@CISCO.COM>
Organization: Cisco Systems
Subject:      Brief == TimeOut ?
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

As the spec currently reads (incl. Tom's list), it seems to me that the
signalTypes Brief and TimeOut are semantically identical.- am I missing
something ?


Thanks

        Flemming

--
Flemming Andreasen                Phone: +1 732 452 1667
Cisco Systems                     Fax:   +1 240 359 5839


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Apr  7 17:32:37 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19434
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 7 Apr 2000 17:32:37 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.74F57A80@standards.nortelnetworks.com>; Fri, 7 Apr 2000 17:26:49 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 121578 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Apr 2000 17:25:36 -0400
Received: from email2.chelmsford.castlenetworks.com (38.165.85.52) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.E3DDBAE0@standards.nortelnetworks.com>; Fri, 7 Apr 2000
          17:15:36 -0400
Received: by EMAIL2 with Internet Mail Service (5.5.2650.21) id <HSG5BPDM>;
          Fri, 7 Apr 2000 17: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:  <9DCB6C9DC7C3D311B835009027DE069F245BBE@EMAIL2>
Date:         Fri, 7 Apr 2000 17:22:04 -0400
Reply-To: "Dalias, Robert" <RDalias@UNISPHERESOLUTIONS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Dalias, Robert" <RDalias@UNISPHERESOLUTIONS.COM>
Subject:      unsubscribe
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

-----Original Message-----
From: Juha Heinanen
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Sent: 3/30/00 3:46 AM
Subject: Re: Appeal to SIGTRAN WG Chair

henry,

i'm not a sigtran expert, but i see sigtran important in order to be
able to place the signaling gateway anywhere on the internet.  correct
me if i'm wrong, but without sigtran, i would need to integrate the
signaling gw with the media gw or connect the signaling gw directly to
telephone switch using a separate physical interface.

so i see sigtran simply as a way to tunnel itu signaling over the
internet to a properly placed signaling gw, which then turns itu
signaling to sip and/or mgcp.

-- juha


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Apr  7 17:49:34 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19829
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 7 Apr 2000 17:49:33 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D880A780@standards.nortelnetworks.com>; Fri, 7 Apr 2000 17:43:55 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 121645 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Apr 2000 17:42:04 -0400
Received: from mail.vsys.com by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1a) with SMTP id <0.95C86C70@standards.nortelnetworks.com>;
          Fri, 7 Apr 2000 17:42:03 -0400
Received: from bobpc (internal.vsys.com [63.93.241.17]) by mail.vsys.com
          (8.9.3/8.9.3) with SMTP id PAA11596; Fri, 7 Apr 2000 15:47:36 -0600
          (MDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Message-ID:  <NCBBLJLAODAODLNMKMOGAEMFEGAA.rmwise@vsys.com>
Date:         Fri, 7 Apr 2000 15:46:59 -0600
Reply-To: Bob Wise <rmwise@VSYS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Bob Wise <rmwise@VSYS.COM>
Subject:      Re: unsubscribe
X-To:         "Dalias, Robert" <RDalias@UNISPHERESOLUTIONS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <9DCB6C9DC7C3D311B835009027DE069F245BBE@EMAIL2>
Content-Transfer-Encoding: 7bit

Alternately, the signalling gateway can be attached directly to the
SS7 cloud (A-link) instead of the switch (F-link). This works best
in North America, BTW.

-Bob Wise
Chief Architect
Vsys


-----Original Message-----
From: Media Gateway Control (megaco)
[mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Dalias, Robert
Sent: Friday, April 07, 2000 3:22 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: unsubscribe


-----Original Message-----
From: Juha Heinanen
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Sent: 3/30/00 3:46 AM
Subject: Re: Appeal to SIGTRAN WG Chair

henry,

i'm not a sigtran expert, but i see sigtran important in order to be
able to place the signaling gateway anywhere on the internet.  correct
me if i'm wrong, but without sigtran, i would need to integrate the
signaling gw with the media gw or connect the signaling gw directly to
telephone switch using a separate physical interface.

so i see sigtran simply as a way to tunnel itu signaling over the
internet to a properly placed signaling gw, which then turns itu
signaling to sip and/or mgcp.

-- juha


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sat Apr  8 16:04:08 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13853
	for <megaco-archive@LISTS.IETF.ORG>; Sat, 8 Apr 2000 16:04:08 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.247399D0@standards.nortelnetworks.com>; Sat, 8 Apr 2000 15:57:29 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 122003 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 8 Apr 2000 15:55:53 -0400
Received: from hercules.acsu.buffalo.edu by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.85A199C0@standards.nortelnetworks.com>; Sat, 8 Apr 2000 15:45:53
          -0400
Received: (qmail 25305 invoked by uid 58411); 8 Apr 2000 19:51:18 -0000
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID:  <Pine.GSO.4.05.10004081544290.21234-100000@hercules.acsu.buffalo.edu>
Date:         Sat, 8 Apr 2000 15:51:18 -0400
Reply-To: Medha Vedaprakash <mv1@ACSU.BUFFALO.EDU>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Medha Vedaprakash <mv1@ACSU.BUFFALO.EDU>
Subject:      Conferencing and MEGACO!!!!
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi,

I'm looking for some information on providing conferencing support in the
MG,MGC. The Architecture and requirements document mentions the need to
support MP functionality in the MG and MC functionality in the MGC.

How're these related to the Context properties which is supposed to
contain "Media mixing and Switching properties" . However, there's no
formal representation of these Context properties anywhere in the
protocol spec.

Is there any other document that can be useful to me?

Thanks,
Medha


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Apr  9 09:52:53 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08253
	for <megaco-archive@LISTS.IETF.ORG>; Sun, 9 Apr 2000 09:52:53 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.88A05430@standards.nortelnetworks.com>; 9 Apr 2000 9:46:52 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 122324 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 9 Apr 2000 09:44:52 -0400
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.DB84F310@standards.nortelnetworks.com>; 9 Apr 2000 9:34:52 -0400
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id JAA13831; Sun, 9 Apr
          2000 09:40:18 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id JAA23672; Sun, 9 Apr
          2000 09:40:19 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <2MSFTZ0N>; Sun, 9 Apr 2000 09:35: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:  <4FBEA8857476D311A03300204840E1CF67815B@whq-msgusr-02.fore.com>
Date:         Sun, 9 Apr 2000 09:40:15 -0400
Reply-To: "Rosen, Brian" <brosen@FORE.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <brosen@FORE.COM>
Subject:      Re: Conferencing and MEGACO!!!!
X-To:         Medha Vedaprakash <mv1@acsu.buffalo.edu>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

There is one explicit mechanism to support conferencing in Megaco,
and there are all the pieces to support another.

Look at the Topology mechanism.  If you had all of the legs of a
conference in a single context, topology can be used to control
who hears/sees/... whom.  That is enough to make a pretty straightforward
audio conference bridge.

It is also very reasonable to build a conference bridge with a set
of terminations, and make each leg a separate context.  That would
probably take a package definition, but I suspect that it would be pretty
simple to make one.

Brian

-----Original Message-----
From: Medha Vedaprakash
To: MEGACO@standards.nortelnetworks.com
Sent: 4/8/00 3:51 PM
Subject: Conferencing and MEGACO!!!!

Hi,

I'm looking for some information on providing conferencing support in
the
MG,MGC. The Architecture and requirements document mentions the need to
support MP functionality in the MG and MC functionality in the MGC.

How're these related to the Context properties which is supposed to
contain "Media mixing and Switching properties" . However, there's no
formal representation of these Context properties anywhere in the
protocol spec.

Is there any other document that can be useful to me?

Thanks,
Medha


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Apr  9 21:23:18 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15746
	for <megaco-archive@LISTS.IETF.ORG>; Sun, 9 Apr 2000 21:23:17 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F7981160@standards.nortelnetworks.com>; 9 Apr 2000 21:17:10 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 122527 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 9 Apr 2000 21:15:11 -0400
Received: from smtprtp1.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.B0CB8690@standards.nortelnetworks.com>; 9 Apr 2000 21:15:11 -0400
Received: from zrtpd00y.us.nortel.com (actually zrtpd00y) by
          smtprtp1.ntcom.nortel.net; Sun, 9 Apr 2000 21:03:51 -0400
Received: by zrtpd00y.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <24DYG4M3>; Sun, 9 Apr 2000 21:03:41 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFA288.9B89E220"
Message-ID:  <5F68FAE98163D21193750000F81AC9BE010FDFEC@zrtpd00x.us.nortel.com>
Date:         Sun, 9 Apr 2000 13:21:09 -0400
Reply-To: David Cromwell <cromwell@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: David Cromwell <cromwell@NORTELNETWORKS.COM>
Subject:      Re: Conferencing and MEGACO!!!!
X-To:         "Rosen, Brian" <brosen@FORE.COM>
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_01BFA288.9B89E220
Content-Type: text/plain

Brian,

If as you suggest you built a conference bridge with a set of terminations
and made each leg a separate context where would the mixing take place? Are
you suggesting a mixing context which contains ephemeral terminations, each
of which is connected to an ephemeral termination in one of the leg
contexts?  If so, you could control the conference topology by using the
topology descriptor in the mixing context, however I am not clear what you
would gain by using multiple contexts v.s. using a single context.

Regards,
David
--
cromwell@nortelnetworks.com                   Nortel Networks Cable
Solutions
ESN:            351-8870                              35 Davis Dr
Public:    919-991-8870                              RTP, NC 27709

> -----Original Message-----
> From: Rosen, Brian [SMTP:brosen@FORE.COM]
> Sent: Sunday, April 09, 2000 9:40 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: Conferencing and MEGACO!!!!
>
> There is one explicit mechanism to support conferencing in Megaco,
> and there are all the pieces to support another.
>
> Look at the Topology mechanism.  If you had all of the legs of a
> conference in a single context, topology can be used to control
> who hears/sees/... whom.  That is enough to make a pretty straightforward
> audio conference bridge.
>
> It is also very reasonable to build a conference bridge with a set
> of terminations, and make each leg a separate context.  That would
> probably take a package definition, but I suspect that it would be pretty
> simple to make one.
>
> Brian
>
> -----Original Message-----
> From: Medha Vedaprakash
> To: MEGACO@standards.nortelnetworks.com
> Sent: 4/8/00 3:51 PM
> Subject: Conferencing and MEGACO!!!!
>
> Hi,
>
> I'm looking for some information on providing conferencing support in
> the
> MG,MGC. The Architecture and requirements document mentions the need to
> support MP functionality in the MG and MC functionality in the MGC.
>
> How're these related to the Context properties which is supposed to
> contain "Media mixing and Switching properties" . However, there's no
> formal representation of these Context properties anywhere in the
> protocol spec.
>
> Is there any other document that can be useful to me?
>
> Thanks,
> Medha

------_=_NextPart_001_01BFA288.9B89E220
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: Conferencing and MEGACO!!!!</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Brian,</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">If as you suggest =
you built a conference bridge with a set of terminations and made each =
leg a separate context where would the mixing take place? Are you =
suggesting a mixing context which contains ephemeral terminations, each =
of which is connected to an ephemeral termination in one of the leg =
contexts?&nbsp; If so, you could control the conference topology by =
using the topology descriptor in the mixing context, however I am not =
clear what you would gain by using multiple contexts v.s. using a =
single context.</FONT></P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Regards,</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">David</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">--</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">cromwell@nortelnetworks.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; Nortel Networks Cable Solutions&nbsp; </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">ESN:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; =
351-8870&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 35 Davis Dr</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">Public:&nbsp;&nbsp;&nbsp; =
919-991-8870&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RTP, NC 27709</FONT>
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Rosen, Brian [SMTP:brosen@FORE.COM]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Sunday, April 09, 2000 9:40 AM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Re: Conferencing and =
MEGACO!!!!</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">There is one explicit mechanism to =
support conferencing in Megaco,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">and there are all the pieces to =
support another.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Look at the Topology mechanism.&nbsp; =
If you had all of the legs of a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">conference in a single context, =
topology can be used to control</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">who hears/sees/... whom.&nbsp; That =
is enough to make a pretty straightforward</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">audio conference bridge.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">It is also very reasonable to build a =
conference bridge with a set</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">of terminations, and make each leg a =
separate context.&nbsp; That would</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">probably take a package definition, =
but I suspect that it would be pretty</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">simple to make one.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Brian</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">From: Medha Vedaprakash</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">To: =
MEGACO@standards.nortelnetworks.com</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Sent: 4/8/00 3:51 PM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Subject: Conferencing and =
MEGACO!!!!</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I'm looking for some information on =
providing conferencing support in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">MG,MGC. The Architecture and =
requirements document mentions the need to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">support MP functionality in the MG =
and MC functionality in the MGC.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">How're these related to the Context =
properties which is supposed to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">contain &quot;Media mixing and =
Switching properties&quot; . However, there's no</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">formal representation of these =
Context properties anywhere in the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">protocol spec.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Is there any other document that can =
be useful to me?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Medha</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFA288.9B89E220--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Apr 10 00:00:16 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19190
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 10 Apr 2000 00:00:16 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E91BB770@standards.nortelnetworks.com>; 9 Apr 2000 23:54:15 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 122577 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 9 Apr 2000 23:52:56 -0400
Received: from ish7.ericsson.com.au (203.61.155.111) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.51B5E4B0@standards.nortelnetworks.com>; 9 Apr 2000 23:42:51
          -0400
Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id NAA26200; Mon,
          10 Apr 2000 13:47:14 +1000 (EST)
Received: from mcsi00.epa.ericsson.se (mcsi00 [146.11.8.201]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id NAA19744; Mon, 10
          Apr 2000 13:47:36 +1000 (EST)
Received: from ericsson.com (mcdh183.epa.ericsson.se [146.11.81.183]) by
          mcsi00.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id NAA02962; Mon,
          10 Apr 2000 13:47:10 +1000 (EST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <C51ED84B6F47D211917A0000F8BCBD11033227DB@zcard00g.ca.nortel.com>
            <38E8A2F1.C5114CF5@lucent.com> <38EAF51A.6CCD1887@ericsson.com>
            <38EC1037.4F563AEC@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38F14EB7.AC8EB5CA@ericsson.com>
Date:         Mon, 10 Apr 2000 13:47:03 +1000
Reply-To: Christian Groves <Christian.Groves@ERICSSON.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Christian Groves <Christian.Groves@ERICSSON.COM>
Subject:      Re: Summary of Issues Raised On the List
X-To:         Flemming Andreasen <fandreas@cisco.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Flemming,

Please below [CHG2]

Cheers, Christian

Flemming Andreasen wrote:
>
> Hi Christian
>
> A couple of comments below
>
> Christian Groves wrote:
>
> > G'Day John, Tom, all,
> >
> > I've gone through the issues list and have a few comments and
> > suggestions. I've also added a few more items on the bottom of the
> > email. Please see [CHG] below.
> >
> > Cheers, Christian
> >
> > ..snip..
> > > > 4. Issues Identified But Not Yet Resolved
> > > >
> > > >    Section                              Issue
> > > >
> > > >    6.2.2      Not clear what wildcard union responses look like.
> > [CHG]  A suggestion:
> >         Add "ie. Given termination Ta with properties p1=a, p2=b, and
> >                termination Tb with properties p2=c, p3=d a UNION
> >                resonse would be T* p1=a, p2=b,c, p3=d"
> > > >
> > > >    7.1.1      Third para (discussing unspecified parameters): not clear
> > > >               which parameters are mandatory.
> > [CHG] This depends on the application I would imagine. Can we really
> > give an
> > example of a mandatory parameter. Isn't this a statement of behaviour
> > rather than what a mandatory parameter is?
>
> I don't think so. The application would reside in the MGC, however the MG would
> need to know what to when a parameter is omitted, i.e. either retain previous
> value or use default value. We really need a table or something that clearly
> shows what will happen for each parameter.
>
[CHG2] I agree that somewhere you'll need to specify what the MG does
with a mandatory property but is H248 really the place. I would like
that a profile or much document would be the place for this.

> >
> >
> > > >
> > > >    7.1.9      Not clear whether events trigger side effects (e.g.
> > > >               signal termination) at time of detection, at time of
> > > >               processing (whether or not in active Events Descriptor)
> > > >               or at time of notification.
> > [CHG] The current text states that "Normally, detection of an event
> > shall cause active signals to stop". So this is covered.
> >
>
> Indeed it does, however it's "only" specified under EventsDescriptor. Consider
> the case of lockstep, where you are currently waiting for a new EvetsDescriptor,
> and a signal is playing (say because of KeepActive). An event specified in
> EventBuffer Descriptor is now detected. On one hand, you could argue, that by
> specifying the event in EventBufferDescriptor you would want the synchronization
> to occur (although I'm not convinced that holds) regardless of whether that
> event is specified in a subsequent Events Descriptor. However, now consider that
> the event in the new Events Descriptor is specified with a KeepActive parameter
> - you probably didn't want the syncrhonization to occur then.
>
> I spent a fair amount of time going over this earlier today and ended up
> convincing myself that the synchronization should occur at time of processing,
> although I'll gladly admit that it's not obvious.
>
[CHG] After going through the logic above I see what has happened when
we didn't have the event buffer in H248 it was the time of detection at
the media GW. With the introduction of the eventBuffer its the time of
detection in the eventBuffer (otherwise known as processing) :-). To me
its still detection but if people want to clarify it I don't have a
problem.

> >
..snip..
> > Chp 8 Last Paragraph
> > Change:
> > Applications SHOULD implement an application level timer per
> > transaction.
> > to:
> > Applications SHOULD implement a protocol timer per transaction.
> > Reason:
> > Its not really timing the application but the protocol
>
> I disagree. It really is an application level timer so I don't see anything
> wrong with the sentence.
[CHG] OK. Dropped.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Apr 10 00:52:33 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19629
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 10 Apr 2000 00:52:32 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3C8A57C0@standards.nortelnetworks.com>; Mon, 10 Apr 2000 0:46:41 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 122821 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Apr 2000 00:44:49 -0400
Received: from ish7.ericsson.com.au (203.61.155.111) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.93A72210@standards.nortelnetworks.com>; Mon, 10 Apr 2000
          0:34:48 -0400
Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id OAA00421 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 10 Apr 2000 14:39:34
          +1000 (EST)
Received: from mcsi00.epa.ericsson.se (mcsi00 [146.11.8.201]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id OAA25910 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 10 Apr 2000 14:39:59
          +1000 (EST)
Received: from ericsson.com (mcdh183.epa.ericsson.se [146.11.81.183]) by
          mcsi00.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id OAA03562 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 10 Apr 2000 14:39:33
          +1000 (EST)
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:  <38F15AFD.CD9513A0@ericsson.com>
Date:         Mon, 10 Apr 2000 14:39:25 +1000
Reply-To: Christian Groves <Christian.Groves@ERICSSON.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Christian Groves <Christian.Groves@ERICSSON.COM>
Subject:      7.1.18 Topology Clarification
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day all,

Given that the default for the TopologyDescriptor is "bothway" do people
find  the diagram and table confusing?
ie.
Step 3: T3, T2, oneway
Could be
a) as shown or
b) bothway between T1 and T2, bothway between T1 and T3 and oneway
between T3 and T2

Is it worth clarifying?

Cheers, Christian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Apr 10 06:17:55 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04308
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 10 Apr 2000 06:17:55 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A91255A0@standards.nortelnetworks.com>; Mon, 10 Apr 2000 6:11:50 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 122936 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Apr 2000 06:10:16 -0400
Received: from tama5.ecl.ntt.co.jp by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.0A667B30@standards.nortelnetworks.com>; Mon, 10 Apr 2000 6:00:15
          -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
          TAA22958; Mon, 10 Apr 2000 19:05:37 +0900 (JST) (envelope-from
          makinae.naoto@lab.ntt.co.jp)
Received: from ima.m.ecl.ntt.co.jp by nttmail3.ecl.ntt.co.jp
          (8.9.3+3.2W/3.7W/01/18/00) with ESMTP id TAA26499; Mon, 10 Apr 2000
          19:05:32 +0900 (JST) (envelope-from makinae.naoto@lab.ntt.co.jp)
Received: from idc (ksk-p22.pflab.ecl.ntt.co.jp [129.60.18.196]) by
          ima.m.ecl.ntt.co.jp (8.9.3/3.7W) with SMTP id TAA10580; Mon, 10 Apr
          2000 19:05:32 +0900 (JST)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal
Message-ID:  <NDBBKGPMCLCCPKPNAOBEGEHICJAA.makinae.naoto@lab.ntt.co.jp>
Date:         Mon, 10 Apr 2000 19:07:48 +0900
Reply-To: makinae.naoto@lab.ntt.co.jp
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Naoto MAKINAE <makinae.naoto@lab.ntt.co.jp>
Subject:      Re: 7.1.18 Topology Clarification
X-To:         Christian Groves <Christian.Groves@ERICSSON.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <38F15AFD.CD9513A0@ericsson.com>
Content-Transfer-Encoding: 7bit

Hi Christian

> Given that the default for the TopologyDescriptor is "bothway" do people
> find  the diagram and table confusing?
> ie.
> Step 3: T3, T2, oneway
> Could be
> a) as shown or
> b) bothway between T1 and T2, bothway between T1 and T3 and oneway
> between T3 and T2

The last sentence in the paragraph just above the figure 4 states that
"it is assumed that the topology descriptors are applied in sequence."
The third diagram is obtained by applying  (T3, T2, oneway) to the
second diagram. So, the third diagram should remain as it is.

The figure, howerver, is confusing in the following senses:
 - The six diagrams show different states of the same context, but the phrases
   "Context 1", "Context 2", and "Context 3" give the wrong impression that they
   are different contexts.
 - Each diagram should be labeled as 1, 2, 3, 4, 5, and 6, but they are labeled
  1, 2, 3, 1,2, and 3.

Naoto
--
Naoto MAKINAE
Information Sharing Platform Laboratories
Nippon Telegram and Telephone Corporation
Email:makinae.naoto@lab.ntt.co.jp


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Apr 10 08:04:57 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06593
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 10 Apr 2000 08:04:57 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9FB8D970@standards.nortelnetworks.com>; Mon, 10 Apr 2000 7:58:57 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 123014 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Apr 2000 07:57:40 -0400
Received: from web1905.mail.yahoo.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.0BF75690@standards.nortelnetworks.com>; Mon, 10 Apr 2000 7:47:40
          -0400
Received: (qmail 5941 invoked by uid 60001); 10 Apr 2000 11:53:10 -0000
Received: from [202.41.72.173] by web1905.mail.yahoo.com; Mon, 10 Apr 2000
          04:53:10 PDT
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID:  <20000410115310.5940.qmail@web1905.mail.yahoo.com>
Date:         Mon, 10 Apr 2000 04:53:10 -0700
Reply-To: Priya A <priyaa_in@YAHOO.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Priya A <priyaa_in@YAHOO.COM>
Subject:      Re: Conferencing and MEGACO!!!!
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi,

*) If  Topology Descriptor is to be used to support
conferencing how to distinguish between multiple
streams , e.g. if a Termination is part of
Audio and Video conferences and  the topology of both
are different (i.e.  if "who hears whom" has to be
different from "who sees whom" ).

*) A Termination can be part of only one Context at a
time. That means if a Termination wants to be part of
two conferences simultaneously both the conferences
have to be part of the same context ?

Priya A
priya@cdotb.ernet.in

"Rosen, Brian" wrote:

> There is one explicit mechanism to support
conferencing in Megaco,
> and there are all the pieces to support another.
>
> Look at the Topology mechanism.  If you had all of
the legs of a
> conference in a single context, topology can be used
to control
> who hears/sees/... whom.  That is enough to make a
pretty
straightforward
> audio conference bridge.
>
> It is also very reasonable to build a conference
bridge with a set
> of terminations, and make each leg a separate
context.  That would
> probably take a package definition, but I suspect
that it would be
pretty
> simple to make one.
>
> Brian



__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Apr 10 08:53:56 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08598
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 10 Apr 2000 08:53:56 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7A794F80@standards.nortelnetworks.com>; Mon, 10 Apr 2000 8:48:01 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 123063 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Apr 2000 08:46:33 -0400
Received: from ihemlsrv.firewall.lucent.com (192.11.222.161) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.45AAF060@standards.nortelnetworks.com>; Mon, 10 Apr 2000
          8:46:33 -0400
Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by
          ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA05967
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 10 Apr 2000 08:52:03
          -0400 (EDT)
Received: from cbsignal.cb.lucent.com (h135-7-16-5.lucent.com [135.7.16.5]) by
          ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id
          IAA05960; Mon, 10 Apr 2000 08:52:02 -0400 (EDT)
Received: from oh0012mmcgrew.cb.lucent.com by cbsignal.cb.lucent.com
          (8.8.8+Sun/EMS-1.5 sol2) id IAA17342; Mon, 10 Apr 2000 08:51:57 -0400
          (EDT)
Received: by localhost with Microsoft MAPI; Mon, 10 Apr 2000 08:51:56 -0400
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID:  <01BFA2CA.062EFF20.mmcgrew@lucent.com>
Date:         Mon, 10 Apr 2000 08:51:54 -0400
Reply-To: Mike McGrew <mmcgrew@LUCENT.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Mike McGrew <mmcgrew@LUCENT.COM>
Subject:      Re: Appeal to SIGTRAN WG Chair
X-To:         Bob Wise <rmwise@VSYS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

just like to add a little detail to this interesting thread...

Actually, "by definition" the signaling gateway is on the edge
of the SS7 cloud.  The SG can have SS7 links to STPs
(in North America "A-links") or handle direct
switch-to-switch signaling links
(in North America "F-links", used to mean "facility associated",
but that thinking is lost in this environment).
It can also support STP-to-STP links
(in North America, "B-links or D-links").

The signaling gateway may have MTP Level 3
(network layer) or may even have only MTP Level 2.
In either case, sigtran (SCTP with the appropriate
adaptation layer; its flexible -- "tunneling" is one of
the options) make it possible to transport
the SS7 MSUs and primitives to the MTP "user"
(e.g., ISUP, SCCP) via IP.
It is still being discussed whether "IP"
includes "the internet" because of performance concerns.

Its more complicated than this, but I think this is
a fair summary at a high level.
Regards,
Mike McGrew
Lucent Technologies
----
On Friday, April 07, 2000 5:47 PM, Bob Wise [SMTP:rmwise@VSYS.COM]
wrote:
> Alternately, the signalling gateway can be attached directly to the
> SS7 cloud (A-link) instead of the switch (F-link). This works best
> in North America, BTW.
>
> -Bob Wise
> Chief Architect
> Vsys
>
>
> -----Original Message-----
> From: Juha Heinanen
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Sent: 3/30/00 3:46 AM
> Subject: Re: Appeal to SIGTRAN WG Chair
>
> henry,
>
> i'm not a sigtran expert, but i see sigtran important in order to be
> able to place the signaling gateway anywhere on the internet.
> correct me if i'm wrong, but without sigtran, i would need to
integrate the
> signaling gw with the media gw or connect the signaling gw directly
> to telephone switch using a separate physical interface.
>
> so i see sigtran simply as a way to tunnel itu signaling over the
> internet to a properly placed signaling gw, which then turns itu
> signaling to sip and/or mgcp.
>
> -- juha


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Apr 10 09:49:09 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11613
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 10 Apr 2000 09:49:09 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2EF58490@standards.nortelnetworks.com>; Mon, 10 Apr 2000 9:43:10 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 123167 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Apr 2000 09:41:28 -0400
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.8C2E2E70@standards.nortelnetworks.com>; Mon, 10 Apr 2000 9:31:28
          -0400
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id JAA20962; Mon, 10 Apr
          2000 09:36:56 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id JAA28293; Mon, 10 Apr
          2000 09:36:57 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <2MSF4AK2>; Mon, 10 Apr 2000 09:31: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:  <4FBEA8857476D311A03300204840E1CF67815E@whq-msgusr-02.fore.com>
Date:         Mon, 10 Apr 2000 09:36:51 -0400
Reply-To: "Rosen, Brian" <brosen@FORE.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <brosen@FORE.COM>
Subject:      Re: Conferencing and MEGACO!!!!
X-To:         Priya A <priyaa_in@yahoo.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

> *) If  Topology Descriptor is to be used to support
> conferencing how to distinguish between multiple
> streams , e.g. if a Termination is part of
> Audio and Video conferences and  the topology of both
> are different (i.e.  if "who hears whom" has to be
> different from "who sees whom" ).
Since topology is stream independent, if this was
a requirement, you could not use topology to control
the conference bridge.

>
> *) A Termination can be part of only one Context at a
> time. That means if a Termination wants to be part of
> two conferences simultaneously both the conferences
> have to be part of the same context ?
You can only have one stream per media running to the user.
Therefore, you have to have all the audio or video for
one user in one stream.  I suppose the other end could mix,
but I assume you don't want that behavior.  It is certainly
possible to build such a media gateway.  The device
would have n ports, the ports can be combined any way your
hardware is capable of combining them.  Each port is one
termination.  The control of the bridge would have to be
by properties, which would be defined in a package.  There
is no such package designed yet, and I suspect that it
would be some time before we could get agreement on some
standard way to do this. In this design, each user is in
a separate context.

Brian



From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Apr 10 10:06:18 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12621
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 10 Apr 2000 10:06:18 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.91592180@standards.nortelnetworks.com>; Mon, 10 Apr 2000 10:00:15 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 123208 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Apr 2000 09:58:46 -0400
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.F6FAA830@standards.nortelnetworks.com>; Mon, 10 Apr 2000 9:48:46
          -0400
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id JAA22793; Mon, 10 Apr
          2000 09:54:15 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id JAA01644; Mon, 10 Apr
          2000 09:54:16 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <2MSF4AZX>; Mon, 10 Apr 2000 09:49:17 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFA2F3.9099ACEA"
Message-ID:  <4FBEA8857476D311A03300204840E1CF67815F@whq-msgusr-02.fore.com>
Date:         Mon, 10 Apr 2000 09:54:12 -0400
Reply-To: "Rosen, Brian" <brosen@FORE.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <brosen@FORE.COM>
Subject:      Re: Conferencing and MEGACO!!!!
X-To:         David Cromwell <cromwell@nortelnetworks.com>
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_01BFA2F3.9099ACEA
Content-Type: text/plain;
        charset="iso-8859-1"

If all you want is a simple mixing bridge, then you don't need the second
alternative I proposed.  However, as was pointed out, using the controls in
the protocol, you have some limits on how flexible you can make the
bridge.

If you want to go beyond the capabilities that the protocol provides, no
problem.  We have a very nice extension mechanism, the package.

I build a media gateway with n ports into a mixing bridge that has some
arbitrary capability.  Each user is connected to one port, and there are
a set of controls (properties) that define what that user hears/sees/etc.
We had the example of separate audio/video topology suggested for
example.  You could make a video mixer which showed the last four
speakers other than "yourself" in a grid.  Anything you want.
It's a completely general way to build any kind of bridge.  All I need do
is define a package with the controls I need for the bridge.  Of course,
I have to get some MGC(s) to implement the package!

     +------------+
 ----|            |---
     |            |
 ----|  Arbitrary |---
     |  Mixing    |
 ----|  Bridge    |---
     |            |
 ----|            |---
     +------------+

If you can use the protocol mechanisms, including topology, to get what
you want, I would think that would be the best way to control the MG,
when you can't, you can use the n termination, lots of properties
approach.

Brian

-----Original Message-----
From: David Cromwell [mailto:cromwell@nortelnetworks.com]
Sent: Sunday, April 09, 2000 1:21 PM
To: Rosen, Brian; megaco@standards.nortelnetworks.com
Subject: RE: Conferencing and MEGACO!!!!



Brian,

If as you suggest you built a conference bridge with a set of terminations
and made each leg a separate context where would the mixing take place? Are
you suggesting a mixing context which contains ephemeral terminations, each
of which is connected to an ephemeral termination in one of the leg
contexts?  If so, you could control the conference topology by using the
topology descriptor in the mixing context, however I am not clear what you
would gain by using multiple contexts v.s. using a single context.

Regards,
David
--
cromwell@nortelnetworks.com                   Nortel Networks Cable
Solutions
ESN:            351-8870                              35 Davis Dr
Public:    919-991-8870                              RTP, NC 27709

        -----Original Message-----
From:   Rosen, Brian [SMTP:brosen@FORE.COM]
Sent:   Sunday, April 09, 2000 9:40 AM
To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject:        Re: Conferencing and MEGACO!!!!

        There is one explicit mechanism to support conferencing in Megaco,
and there are all the pieces to support another.

        Look at the Topology mechanism.  If you had all of the legs of a
conference in a single context, topology can be used to control
who hears/sees/... whom.  That is enough to make a pretty straightforward
audio conference bridge.

        It is also very reasonable to build a conference bridge with a set
of terminations, and make each leg a separate context.  That would
probably take a package definition, but I suspect that it would be pretty
simple to make one.

        Brian

        -----Original Message-----
From: Medha Vedaprakash
To: MEGACO@standards.nortelnetworks.com
Sent: 4/8/00 3:51 PM
Subject: Conferencing and MEGACO!!!!

        Hi,

        I'm looking for some information on providing conferencing support
in
the
MG,MGC. The Architecture and requirements document mentions the need to
support MP functionality in the MG and MC functionality in the MGC.

        How're these related to the Context properties which is supposed to
contain "Media mixing and Switching properties" . However, there's no
formal representation of these Context properties anywhere in the
protocol spec.

        Is there any other document that can be useful to me?

        Thanks,
Medha


------_=_NextPart_001_01BFA2F3.9099ACEA
Content-Type: text/html;
        charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: Conferencing and MEGACO!!!!</TITLE>

<META content="MSHTML 5.00.2919.6307" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=110071413-10042000>If all
you want is a simple mixing bridge, then you don't need the
second</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=110071413-10042000>alternative I proposed.&nbsp; However, as was pointed
out, using the controls in</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=110071413-10042000>the
protocol, you have some limits on how flexible you can make
the</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=110071413-10042000>bridge.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=110071413-10042000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=110071413-10042000>If you
want to go beyond the capabilities that the protocol provides,
no</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=110071413-10042000>problem.&nbsp; We have a very nice extension mechanism,
the package.</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=110071413-10042000>I
build a media </SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN
class=110071413-10042000>gateway with n ports into a mixing bridge that has
some</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=110071413-10042000>arbitrary capability.&nbsp; Each user is connected to
one port, and there are</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=110071413-10042000>a set
of controls (properties) that define what that user
hears/sees/etc.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=110071413-10042000>We had
the example of separate audio/video topology suggested for</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=110071413-10042000>example.&nbsp; You could make a video mixer which
showed the last four</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=110071413-10042000>speakers other than "yourself" in a grid.&nbsp;
Anything you want.</SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN
class=110071413-10042000></SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=110071413-10042000>It's a
completely general way to build any kind of bridge.&nbsp; All I need
do</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=110071413-10042000>is
define a package with the controls I need for the bridge.&nbsp; Of
course,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=110071413-10042000>I have
to get some MGC(s) to implement the package!</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=#0000ff face="Courier New" size=2><SPAN
class=110071413-10042000>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+------------+</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Courier New" size=2><SPAN
class=110071413-10042000>&nbsp;----|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|---</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Courier New" size=2><SPAN
class=110071413-10042000>&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;
|</SPAN></FONT></DIV>
<DIV><FONT face=Arial><SPAN class=110071413-10042000>
<DIV><FONT color=#0000ff face="Courier New" size=2><SPAN
class=110071413-10042000>&nbsp;----|&nbsp;&nbsp;Arbitrary
|---</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Courier New" size=2><SPAN
class=110071413-10042000>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;Mixing&nbsp;&nbsp;&nbsp;
|</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face="Courier New" size=2><SPAN
class=110071413-10042000>&nbsp;----|&nbsp;&nbsp;Bridge&nbsp;&nbsp;&nbsp;
|---</SPAN></FONT></DIV>
<DIV><FONT face=Arial><SPAN class=110071413-10042000>
<DIV><FONT face="Courier New"><SPAN class=110071413-10042000>
<DIV><FONT face="Courier New"><SPAN class=110071413-10042000>
<DIV><FONT color=#0000ff face="Courier New" size=2><SPAN
class=110071413-10042000>&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;
|</SPAN></FONT></DIV>
<DIV><FONT face=Arial><SPAN class=110071413-10042000>
<DIV></SPAN></FONT><FONT size=2><FONT color=#0000ff><SPAN
class=110071413-10042000>&nbsp;</SPAN>----|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|---</FONT></FONT></DIV></SPAN></FONT></DIV></DIV><FONT
size=2><FONT color=#0000ff>
<DIV>
<DIV><SPAN
class=110071413-10042000>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</SPAN>+------------+</SPAN></FONT></FONT></FONT></DIV></DIV></DIV>
<DIV></SPAN></FONT><FONT color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff size=2>If you can use the protocol mechanisms,
including topology, to get what</FONT></SPAN></FONT></DIV></DIV></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=110071413-10042000>you
want, I would think that would be the best way to control the
MG,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=110071413-10042000>when
you can't, you can use the n termination, lots of properties</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=110071413-10042000>approach.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=110071413-10042000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=110071413-10042000>Brian</SPAN></FONT></DIV>
<BLOCKQUOTE
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma
  size=2>-----Original Message-----<BR><B>From:</B> David Cromwell
  [mailto:cromwell@nortelnetworks.com]<BR><B>Sent:</B> Sunday, April 09, 2000
  1:21 PM<BR><B>To:</B> Rosen, Brian;
  megaco@standards.nortelnetworks.com<BR><B>Subject:</B> RE: Conferencing and
  MEGACO!!!!<BR><BR></DIV></FONT>
  <P><FONT color=#000000 face=Arial size=2>Brian,</FONT> <BR><FONT color=#000000
  face=Arial size=2>&nbsp;</FONT> <BR><FONT color=#000000 face=Arial size=2>If
  as you suggest you built a conference bridge with a set of terminations and
  made each leg a separate context where would the mixing take place? Are you
  suggesting a mixing context which contains ephemeral terminations, each of
  which is connected to an ephemeral termination in one of the leg
  contexts?&nbsp; If so, you could control the conference topology by using the
  topology descriptor in the mixing context, however I am not clear what you
  would gain by using multiple contexts v.s. using a single context.</FONT></P>
  <P><FONT color=#000000 face=Arial size=2>Regards,</FONT> <BR><FONT
  color=#000000 face=Arial size=2>David</FONT> <BR><FONT color=#000000
  face=Arial size=2>--</FONT> <BR><FONT color=#000000 face=Arial
  size=2>cromwell@nortelnetworks.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  Nortel Networks Cable Solutions&nbsp; </FONT><BR><FONT color=#000000
  face=Arial
  size=2>ESN:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  351-8870&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  35 Davis Dr</FONT> <BR><FONT color=#000000 face=Arial
  size=2>Public:&nbsp;&nbsp;&nbsp;
  919-991-8870&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  RTP, NC 27709</FONT> </P>
  <UL>
    <P><FONT face=Arial size=1>-----Original Message-----</FONT> <BR><B><FONT
    face=Arial size=1>From:&nbsp;&nbsp;</FONT></B> <FONT face=Arial
    size=1>Rosen, Brian [SMTP:brosen@FORE.COM]</FONT> <BR><B><FONT face=Arial
    size=1>Sent:&nbsp;&nbsp;</FONT></B> <FONT face=Arial size=1>Sunday, April
    09, 2000 9:40 AM</FONT> <BR><B><FONT face=Arial
    size=1>To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT face=Arial
    size=1>MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><B><FONT face=Arial
    size=1>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT
    face=Arial size=1>Re: Conferencing and MEGACO!!!!</FONT> </P>
    <P><FONT face=Arial size=2>There is one explicit mechanism to support
    conferencing in Megaco,</FONT> <BR><FONT face=Arial size=2>and there are all
    the pieces to support another.</FONT> </P>
    <P><FONT face=Arial size=2>Look at the Topology mechanism.&nbsp; If you had
    all of the legs of a</FONT> <BR><FONT face=Arial size=2>conference in a
    single context, topology can be used to control</FONT> <BR><FONT face=Arial
    size=2>who hears/sees/... whom.&nbsp; That is enough to make a pretty
    straightforward</FONT> <BR><FONT face=Arial size=2>audio conference
    bridge.</FONT> </P>
    <P><FONT face=Arial size=2>It is also very reasonable to build a conference
    bridge with a set</FONT> <BR><FONT face=Arial size=2>of terminations, and
    make each leg a separate context.&nbsp; That would</FONT> <BR><FONT
    face=Arial size=2>probably take a package definition, but I suspect that it
    would be pretty</FONT> <BR><FONT face=Arial size=2>simple to make
    one.</FONT> </P>
    <P><FONT face=Arial size=2>Brian</FONT> </P>
    <P><FONT face=Arial size=2>-----Original Message-----</FONT> <BR><FONT
    face=Arial size=2>From: Medha Vedaprakash</FONT> <BR><FONT face=Arial
    size=2>To: MEGACO@standards.nortelnetworks.com</FONT> <BR><FONT face=Arial
    size=2>Sent: 4/8/00 3:51 PM</FONT> <BR><FONT face=Arial size=2>Subject:
    Conferencing and MEGACO!!!!</FONT> </P>
    <P><FONT face=Arial size=2>Hi,</FONT> </P>
    <P><FONT face=Arial size=2>I'm looking for some information on providing
    conferencing support in</FONT> <BR><FONT face=Arial size=2>the</FONT>
    <BR><FONT face=Arial size=2>MG,MGC. The Architecture and requirements
    document mentions the need to</FONT> <BR><FONT face=Arial size=2>support MP
    functionality in the MG and MC functionality in the MGC.</FONT> </P>
    <P><FONT face=Arial size=2>How're these related to the Context properties
    which is supposed to</FONT> <BR><FONT face=Arial size=2>contain "Media
    mixing and Switching properties" . However, there's no</FONT> <BR><FONT
    face=Arial size=2>formal representation of these Context properties anywhere
    in the</FONT> <BR><FONT face=Arial size=2>protocol spec.</FONT> </P>
    <P><FONT face=Arial size=2>Is there any other document that can be useful to
    me?</FONT> </P>
    <P><FONT face=Arial size=2>Thanks,</FONT> <BR><FONT face=Arial
    size=2>Medha</FONT> </P></UL></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01BFA2F3.9099ACEA--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Apr 10 10:31:29 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14167
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 10 Apr 2000 10:31:28 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1233B470@standards.nortelnetworks.com>; Mon, 10 Apr 2000 10:25:19 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 123265 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Apr 2000 10:24:13 -0400
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.DF8C2CF0@standards.nortelnetworks.com>; Mon, 10 Apr 2000 10:23:54
          -0400
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id TAA18537; Mon, 10 Apr
          2000 19:50:07 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          652568BD.004B038A ; Mon, 10 Apr 2000 19:09:21 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: multipart/mixed;
              Boundary="0__=2BGeRJftTEkn65OEJnJvmqAsgagQ7CMtD48sWHWQjjrXM9GgRaylh7OG"
Content-Disposition: inline
Message-ID:  <652568BD.004B02E0.00@sandesh.hss.hns.com>
Date:         Mon, 10 Apr 2000 19:12:37 +0530
Reply-To: vbajaj@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: vbajaj@HSS.HNS.COM
Subject:      R1 & R2 Package drafts
X-cc:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--0__=2BGeRJftTEkn65OEJnJvmqAsgagQ7CMtD48sWHWQjjrXM9GgRaylh7OG
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



Hi,
         Please find attached in Zip form the updated version of the R2-package
draft and  a new draft for R1 package.
     These are as per the new format specified in the protocol for packages.
These are based on the ITU-T specifications
     (i.e. Q.310-331 for R1 signaling and Q.400-Q.490 for R2 signaling). Any
country variants are expected to be covered by
      Extension packages to these basic packages. Please send comments, if any.

Regards,

Vikas Bajaj
Kushnava Laha

(See attached file: R1R2_Package_drafts.zip)

--0__=2BGeRJftTEkn65OEJnJvmqAsgagQ7CMtD48sWHWQjjrXM9GgRaylh7OG
Content-type: application/zip;
        name="R1R2_Package_drafts.zip"
Content-Disposition: attachment; filename="R1R2_Package_drafts.zip"
Content-Description: .ZIP File
Content-Transfer-Encoding: base64

UEsDBBQAAAAIAMiViigkR7LJFTMAAAD8AAAmAAAAZHJhZnQtaWV0Zi1tZWdhY28tcjJwYWNrYWdl
LTAxLnR4dC5kb2PsXc1vG0l258xORhhge/MBZBAECVDLTbBSlqQlWvbYQhBE1oetXYnSiPIEwWIC
FLuLZFvNbk5XtyROLvsvJNdFECRA9pTD5pLrIn9AkEWA5JIckmuw2EOQ8zrvvfro6mZTkiXbM+M1
AZlkd328eu/3PurVa/qn//Lr//U3//Db/92ovP6o8bXGL55/0HjfufYO/M3Ml19rNP5cX/vF8+fP
8dIF/D1/+/pKvX72d//U+KzxwXsgut/4iZUsvODKX0aNxjcag2eDZ9l3su805l4fvPdh49MfNRof
br5Df787VNf/2mnzb+8Un58//9UrP5vXp/TvP36tYd/dz/j6n5r333NG+MZ7i9+P4P3P4P3r8P4M
3v/euf/jZqPRAqq/+yvqO74vw3uqv1ffD96vf89hnHfh/bypvl/nHen/z281Gv8H8//09xuNH8D3
H8L132zMv8y6D1wVdV6L6DLvP9Tz/oVmPvL1d+D9X+H9txrF+swLv/9Ho+CL6Vd9x/H//f2CPjNO
9Xuu56++qvK6Su4uv/GFdPzh+wU9/wzM+xHw85vfbDRW35nvf9OXmc+s50N4X4f3H/z4r/7353/7
k3eq6/iW12jEAIiPm2WcfrGvvTgTaSwythOPwliINIxH7ITLU7abpL5Y+qTziD/jz7x+55jHz8Y8
9o463+Vh7D3qHMCtQe59r7PPx3xpyY60nfJhtvQkH42FZP1kmJ3zVLD+TGZiIpeWthM/n4g422AB
NmyHIhu2J2LE/aR93J1y/5SPRHt1rZNdZEub0zSMWHd1dXVpaYtnYpSksw22Fw+TdMKzMIl5tLS0
5HkH1P/Ok053/QE77rIjNYznef2MZ7lkyZBl41CyAzFJPO8EPwaaEAafecwM/W2iH64EeCOM2TCP
IuYnas7YF+w8zMaMw8VpmpyFEqig8fvCR4rY2ip+O97d6q5277Pvv/tph3leeXSYEFhynqSnyG5D
iKZSsCuEwpb3dk52V1osVANx2VLkwlcz5ihN8qnssF6SCRiTZyyBkVN9nU34DFYgExaEMkvDQZ7V
kcNlhSswYN1CSJBOvzMehQEDfjEOM12Ek3yCS5PhBZskcTaWRC7SMBAsnwYg2KDFUjGNuI+foGMy
kEkk4DobzDTpDl0onhnLwokAgjIlJz4FcQBcOC44Ybks+NhmhlgJswxFKlCMACDgLI9wOujgh8Qp
MdHTAdNi7NBEviAOYPhRKqTsNBkiSLAIeIfr8vM0RRxVWePDALBA7vvQC1YCZI+zbLpx5875+XkH
cd9J0tEd/HBnLQzafACy4D5wGaDPSlNUwNkf8yA5Z9thCphL0lBcezJJPTvjbBJ1PG+twzb1pDVK
UV04SS0QQ4CkJJyComl9xWZcysQPSSuVimCTkmIepUmW+EmkAKkpzpFa5D8gI4V7HPoEIWePQTzn
AJHlg8crbJgmE1RScYF84JFpHYm0BQPBezDXsWiCY2ytFFDJRByoSSWQK4czIjUVn+XAUAUxWI80
+tw1ellajNO84Bpqu+d1O2wric/gAtkGWiEMmLkMVhA6FTNkcwAwO3jaP2m21DvrHdLn452Pn+4d
72zj5/6Tzf19+8G06D85fLq/XXwqem4dHhzs9LapM4y6+adNZSWah0cne4e9zf3mHE2kzMCVgSAm
pdOUNBCUIBDSBzOh1gGmrd1dW3uoV+vd7TBj1NlhOuJx+DmhQC1R5gMJrMKb0yQljhpjrOwGfEhU
Lxoe5kdeD0FyyTnaowl/BhqqpSE3PO8PUB3SJMiVfKADAFGGI8AFtIfbm1Lmkyk1h2/bRPu0mNkF
Ltw/NhYBG2/m2ThJvy3ZZhAg5mF5653L5/P65qN2cng71GLn5FuIm7F2WEVXJlV71Jaw2ioVI1xA
i+wo3hqlaCfLre7UDIpCxj6DBN1UniXoKX26LMUkLK5og096wZHbkvqlfArWG5UK2mftfEpdydcB
DECew2HohyhPNScpC00WkD0izAOTpiKdhBnxGyxMLCehlFoGMYAlDWEKGlrZ27Bw6rD2CD7AWjQY
jIbHii5iHcCKIJlKsJJokfAutA9jH10i6HOS0xhD7odRmIGRREe8D20dZoGQSELQtj3AEYAN7Uic
CTBSSSzaSdwOg0gwr+gyEQAR7d7gUjLKRcFKcNDsaOuAJbB6WgsIkDiQEImpsG4OHdsgzNp+EijK
UFlIuG0UPQAjdejEGAUs2mQqiBOTPMrC9jAlxfLR1gVII8FJ++gFowBdyGcYA4xgO0va8AZcIOCw
bhv5kAzb94ESxQ+aiVVmIvMOw0Bkp6QyAG2iLwWJdtYOOyHrWkfNkNM1Tv4EmAOX4kQ3wS4i1mxk
Rj8maOPBU4sLHxz0CFl3eCbSiE8LniPEuNJfZ7oJPwURACL1pOTgD3bbx2sYAQTC50HoK2IL42PH
BHqGAkLJVIsRkBbzCThcuHzOzsehP6brWk8MT+sEBSaMwavNtjSWpzzNZqgUA9SDAP0GqJiyoXUt
fR0J17ftEZXG1Plh6udhpu8dg2YAfxC7OCSwIoygsb67DwzN0ZsH4QiDSWN5CqOE2id16906+RuT
gF2NRwdKhD8GseYQomF0AipLL8+71ykZa6/MfOUfODbQEQcOAU6EQqKTp+0TwlsUcnS965866KMV
AMGupWZJHM067ElyDvqdasShzDgGxBBQnvFUxS9k0kpd0VUC+KSKYwmegIBCrhMIP43xtb7TglFw
QIcSiDTWB4N26RDhJzmwi6yUilPoFvBRaA4EKmyiQOQxqbLZfsAtG3BBKJcDcQe7ZfoNpRgqgs2C
K6ZHCOqHPMzyQLTITrEg13qkDG5A4TKZV2peXp/SmKhsVqc8Q9hIpjVYBaRI33Q8k2T5Iz7D4A0N
G25E7Bop/HCXZtesZlJrFxdTcDWqvTZpCu4KASQKvxyKjkU0JfElE5xAtN1JwIyDR4TBToWYqvl2
Hm9uHarFggvRTgwUED0fRv0krxkYjimYUERgCGykeFBhCKHNJioIRHPL0yjEFTtk4urm7JSKlnyh
lin8PKsyAYNYgihE+xA80qYUSNcUT8dhlMgEGF0CjI+hMGwujHKrvtrJ0jUEMYkZXBQoGSFwYlww
RNDgMdqDKAEbuTesrKJk1APEUA4hdor6KlLFZBtEw0DwHlvHXkT+mW1wHsL1gfBRVKCrM6Xn4gL9
JHAVoG32Ibh99TMcA/cxIe2i43o/ihtGRaLMBe2ZZ7qhwFid9pPQFoAFJtWE7NoYAmuMUSM2Et/w
ppDwWWmLNuCwxSLiWXKGNOSR8vUEfrMB0pP4ak4JUfSWhpO9U0YTpRRchS528MQIFoMXIiVUAiwt
HJ1qphvaZSn7CSTKuuFVIJWkAAT0ttb1yRz9HG6j26AN55SaAEineXwKYwz1d7irPij3icEoxGSn
bZhaZICfPo5SjGkYBm0i2gXABLgeQz0uiUREoPernCqieakQrwbEvSLZLIDkgMtSw47Z7qrMhcYS
ZoGIK8gKPbrivnEuytU0i4Ga2vWbeB/3lCJjEDSTq0QslvmKnKIMBiqJidKBTpv8+STZO4LVZxhS
arjby2Zri+ZOXVb4NambPAYtHkBfofXrqH/SU+E7kAt06XHVrPM+zXgwCrJaxtxqdobokIBkUIcY
MYFpEwzx6UtpkcokKo8L/BHUESgTEA1BY0W5GYiapYQ20k4RW4hqtQVnMian6PMYgQyGnfZVLANa
wULRqlU47ga1JZLUGJ53v+OkB92tId5aK/KGpkUPYrwNN6Nobuxtb7C0y5ZPyF/h9sknN5eNYd8x
GrO9zd7miudMsKEMt02YFICBOBS3GDVoT2LLYopKdPiDCyps73G3XaxzmQC8UgJBOS2i/biChsGZ
94myAxtszdshvZEbrAcQRbZ0MXEDioxbKM/rUYSgbQnZtWJV2Pou2yHi6TOw1KOvmpF9EX6O8SZd
QxbKz9ny6sXq6mp3jlnCtFbccM0EMgGDHnQjtL3W2AE5NbGTCJoGPInv56niJIzocJMYgYhRrA70
5AhFSbHDmZYn6CoFT1J5xDJVKibRQRds50zkw/gInJHMtHnAflXKYBqwvtrVlKM5jX/w9p5ildwu
yDviKfASJpEbXnyZMJh3OIBg+0wENx+DhNitkyHb9E/j5BwQOHLlybU8714iT6fnC8nWCTIVNyuD
AW8XizvEtIKcghpRsKT2/KMEh65KhkfgiQLwMJQTuyVM5hb7opCZX+SLAehyBNnPjnRL801MaATs
clqHwQZlTyda3msVeZswSjHDnALYnYVOeV25VFfkbthfkabp3QQMzZI4sANjnzLCglCOkxi2VTYq
05axY02kajvmZ6QXHLbweKSRC3IyNCaFbR3vZDYFllFyjvYyMZtA4BpKCFzBgnpHiZThAEw79QaL
ukpoyqfey9LMuyXN3KSIrFBGiNC0dNZrtFG1vrkCqv6XKx1EVzBFKnwRnllNm5eyOip6JWrorvJF
NK9Y3VfOXK+XQLEVwc6zwIQfpRoT92owQY1vDgnq3taJwSaGdfoS5ocuxYkOSm4iYYfmDvsTHW1e
RYpanApUDUEq8gyzkNvtndqfYr/QJDKvB5+rpn+FFnzPSCcVESXCRzlm5upNeOino+sacWu8UV2L
tRqrGQ4BLGA0aRMhSzgBzrbAB4ChREZRrzJxNucxUBkvsO14rhnbE4DmHoTITdzmByHS0FJgrPKZ
0iIkwcK8q+MFFO6y9fjwbQUP6VLlRAJp5jnp6jQAHXrZDfPibeFtnEBVcoeGvOtILhm5kquGz7eU
nMuoVyo5pQ5XiM3F0QKxrb0+sb00O32vZKcfwQ7ytLDTg+hUi/Z+jZ2mxje309S97LmhuZaUa5eB
vamgTF7VYot4BAsJbuyXnRW8iF21lH/lvPL9krSfxoOyvPNC4B/VCFy3v7nISbZ3msdKecuid9g6
J/xJcia0d1QCt4p8Y9GX1vIiwp9bw8t0o68HBR+VA3ZdZFBE7HBBo+BBBQXbMIevOaiy4SrtZg4Q
KCmLcbYoklBFkmj++FUxfhGeVOBeSXbbac2c+ihBN1NrPgvTLBfqhGTx7CbZ72alrsaShpGhR7PP
AAmPzWI/ygNB3EiIcZQ/NBJS7sLuCXEMmeSpPt0K5nP5aoHqzKaoOLAHsK3ywSZ5N5OepoNyqigo
naoyt86h7K2+/+6nLQ33GoFIOvw1WeJEw1FzTAmzZgF2oEJGnIoAQOvNwUZJBe2RZsuc/LXK54H2
sFB7xhpFrR56q+IHVfSFdVHKwRsQlRiSClU9qI4MU/EKLPr1VLkam23P87Zog6obhAuCaGRuqfLJ
FUaNyIqbRo2N7i1SJoMaYKI/FoEGSko1qlgKAXyNMnWKf2ZV3sRt9eddeBZoYiQ8YsMk/dDo+/JU
BUczJibTbLYCJGV5GitscfZZniD1qluniKQ+0ZEULyY3/BhzrEFEDW2uNu26mw+b80FyjSBcp6Wq
c6qiyRbFySE4M9+eSaRFeQR+dcpPNKFNd/Yezd4s7Ivml6DyJmozt3jvg+bTg6ZFCvhCPhmEozzJ
JTtA8UGDI9ugu4KYzLBIlW62jAnG6QczHfOKi2kIBgeIzmMDARIyjLVrx7q7wnaxkvlGAzE2J4e+
Mpy1uiBDO+m8LhT4lqUh5pzJdeH/5cRpv3AXpnK9wiR/QXLOFPug6GfflkW5D6/jzmWcuQYgGYCk
d+QgspfE7Wkawh4umzk+D3F57OKytslB78TBmyoxwtJd2kGKmCoVsG52OlHwPDzqHe7aLutuF3t0
jKli2I/aejOqwxjCMnVh3wzG2bZj3NNjSBD1lDQZfAkvVSDSvMWs9xfOeumUhwU7Plphh6YfZoyQ
pZvm5oMV93kFOonnZzyMOAoBjfQU/KmP3+YxtIPRRb+ILtyRymAS0q6/DCZ3bp3nMjPSSuaqs5JU
XhM2xx87sLG5Cwg4hu1qWMR0tXSArCn6AY52KnMTg5zWe72+g6hLZsG+EIcIjJZKAli/hQBMVcYW
1VeWOO77Fj8V9XUDQDe4KYVgvBTOvU7zZhIam7cyb7ZWsMIWjHYX7GNtl5fIlKswunvsYLRc38h2
seobHe5OzwFkpdFOPIpCia0eHztArLR6LPDZINSJpw7sKo2Oc6CPWvWtwb0316o/5TFOOMfxoq5z
S9V0VlkfcwPJ6t7RKeiCVmYYXRqKanOWRGdFBAhBeqwffpAJ2LwUNnWfd9TmylQLSXBK4KYyKv07
NeLYuUIc/c2Tvd6WI5J+aRizfwtU096h07g71xg12Xag3fWD0u66p4tdYDkjDNuAJrvRjs99i9OH
FW4da24V/UqIDYew+8J0qMFspfhVORLapGU6hXn5XtvkbmAzXx0K38LhDPU+nlsN2nP7IEC5Thf5
g49VlNdgAmX0jpEWMLShTFBqDYHKNpNlHMS46simfFWVmNFGqkK0OYfyYSruGd20QbVMUBdnvvC2
X9WfxTW5o1e1cXX3rSb7UouL6+9dvwyJqIflmo4iWN3HrKF6atIp64hMfMEXKAsuTiUcnQcu7ZMb
RZB4uSqEw7mBSqonHddtC3ttDmmxA7k98HC8ei59QekTJx21iF1fJkResj0iXm6ZtHIlnMCkcX1e
hbrZbPRixF0zUnjac9wSbMttRZ/anqJH2n/kOqMK/we5nFGj3S0nTqi2AqkCIjDQAtZR697hlhMy
1LePE6fL4aETPDjtyWiDb0oDRe2eu8Pp40EapXowX+5gBMGF4fL3nM2MM6hGFbpaLNiIW+aZMBgL
wm+qq9SVfqsli7KN2jBX7hcYYQ4uMSMBZbpNnBGiOvBYYIZE6uoRTGpRDWsb9R5ckipAxieqEm0U
sIRR18pf6neLyqEx2I8B1kzaehO3yMg9Wyn6hFJTS/oETpEHSFxdmQvueJu3dXhfCtextlaS9K5+
hsgKGR8q0mL2F4iZmyePCgU29sjUMif2UU1SBIplLjtPuIlB16S/PubObfDTlBYWiMp23kTyVaOn
FjbQ+UrDRJW3vK6h2++XLJ2tqXPOC7HZcd+xdk6zCvOh6f7JoWPy9p1jR1O6ABujog2YueP5JzN0
u/7BjmPe7BPj6GqxjNAf4+gQkw7zmGyEh5hcZ30ah4qO17HoWH2vVB2ri5eWHW9iMgC9sqPkmkad
PUFrU+SblfN3zy3JTyvQgQmMdPma7myffnKGuOTIUq9CyXX58HAFxrmTDIfM29YxBVZpZ24KYzNQ
6gTdHODZWu71TreWN6Vq3ho+VRO583yqr1F9Q5h2t8w0XWhZ8GlxpaVlVFxTU/iGcGe9zJ1rVxw6
IJqvl+O1FXO1j5a4mwDw7uCzyQngZVvIlDiPmMgwEPaQh0r8Epv48AVl0Gq5umwijZXXKaMTkNGJ
to+FjI6KrosE9MtaGahqF0A25uFTWQ+mFykAxFv11WTyilKyDtsu1ZA7Mq9Jyv7SFwdeJjxrHl6n
/ORNBYiW8V7ZMqoav8JtLC7yc0xjteTtDXEa98usMQVxBXMuqYhzneqiorA3hE0fVSIPXTHmhB6L
S8YKNs3M46aUW5pGtIUOFtc71Z3Mt65XAeVmF8rVUK1LS6FAa+aOJkotlsk2CfzpBpSX5eEK2CGf
TyU9WxqYJ4s4w9/fiIqdSOJaNYUDmzjUfDIG7Iye5nfzjkrGeKFc2FZ6xtRBHAYJt8wLmvjkdsVU
10Lqo+MV9igNxfCW8cX2rWqkdOJu6v4YikLeogPQl16yceOSFl7zQy6GyNdF/MuvN7lWQuFtQcnb
gpK3BSVfSEHJ6zItL6vW423NxgvUbLgnzm9uzcZ650E5wK0p2ihi3cuqNjadIK4mQFMRE9ld/Rsk
SV1JhQPXjq5WrT3s1z9e+iYWZbzWuPWSWopXGboW+6uHlXR4fSGEkxFfWAlxAwDOnVUvOsp/jTIJ
zW+RfbF7ibf1AW9UfcA90iSwUKFPh3T36JDOXjLREYbNBjfObQqPggVyPjK/TOvn9PtS+IyLVQdt
O0nybhJnzAN12I+pAp/62N+iExdZUcM3heiQ+IZRHRbi3XF+zWLuQCfD360rdTNWmi1f8ZsAK8z8
9gCou/cUPgPutpMcYEgpSZONRO7dx0X7IsCfT1O/yOR53kcd96eMv+496Mz9mjG2/iQ85ZKpX/Vf
8CP9rf0s6HiP83TEk7j1hKczHvPWHmgS77C1bnd17V7HOxqDtj9cW2mvrbXv312/D6/OzkW7+2B1
vePt8gtzt7uOt7sP8GfxU/Zgba3jTXZg+xZtsLMBUvHHYyk741h2wGjC6vpgwcIpM//dwKsgsbv+
4AoKNYEyVVRUSDxKuRxjjoj+J4RXQeHDh11DwzR9BrNUKDjgwThn9P8vvOLpB5MBzFKZ/v/ZuxP4
KMq7geP/2U1IAoQEMAlHgA1nAklIuEFBckBCCCRcWiGF3BAgJCaEQwRD5WOrFuV4FVFBUevbw7aI
fRUvqBevYrVUfcELsG/Verx5OQzhTOjvmZnd7G6ydA2BYMvk883O+cwzM881szszEyvU9nPSY1Pv
frgUURgcN2KwPQoLFrIStxgE6vcyJZWULi8rmjtvsfH7AOO56j3rx0YmRekV5wT7CxWmleQVFXCO
GpmgXiwRrV4sEUU2IaipaoFycpDxKw7zp0P1T0ZflO+ou+21iX6X3HLj5spSdQOdmqmwokydChTo
T3bTfwBsvp2BUlf9CEWVNKrJ6Kh2i4vNC86q0afmX1pUrh5vXLqQw67Wodp8VEflquGsv+PB7cmQ
Zhw4Zy1l5+dHm7GJtpVSdhhR0dfveNNDvl6eLJ1XYpyu0q+uW0U7rouob2nUQzXN8lNdPV5QpL7q
KbU/29jxXNGcXHV7eJ5jh1MPFDmeFav/PKYsZ25ZTqnxbGR7w1+/6VxdUlG/bdJjW97oLnI8qzfa
CK3+5QSLaSsX6luuah62vrgk33ETo4owrd1ox8Mqc9XXwsUlS+rbvm7xLVHPKLIXnfZLxQ0Sjf0A
1U8pcXraPYe5YFleQeli4+mVBWo77e2u0oqy0pJy86L7koKFJfqzgh3BlKsHGeaotwAU2R+Jlafq
DH1RR0FvPn7UjHrDb7cc0XWEpi9bXk6zr1zfScaTlc03bOj3ixtXRfQttjdMbfpl98UlgfYuwMPL
VQISHC9nCQy0Beo1SrRZbEerkjE6wOVFLTEZeYtLaDPouS6goy0zIWWc7ZpBIYGqGIvWC5LGg3FM
D3AsFR9CxCw2Wpo5+YtU+pgWG23rOb3x3ZBp7oYY9fxr82G0g3tG2xKTMm0jo9XrDGzqVS3RNjOC
tviRI4fF6uEbr9uYWmBk03wjwxk7InJ8QW5ZBYWavgeiom3TC4rV01IZ4XgbwuDhtsjM9HGTmTqN
9vhyW4p6/YotnnXpX0aqEz5CrlhkfzKJPdJmmtLfKcOxijSeiqw/uFa/6aDhq3NKzV9KxcQNV68P
iWpk90x0vGxCpST1gpQi/WUOeoqfYN4Iy8bWv9ciXSXWcnNXxQ8x91V8PHttUk4ZyZQ9NVytaZrL
N6oqnU9znFU6XooQbZsSOyQuTq2NnpFxBKu+T00sKVkQbUtKmjB9ukpu//ydRVe7Zux8RHJ9RfKQ
GSAyBdMwHWNai1yPxDYiSUjGqmCR2/D0NSI7cDpU5AzWxojcg+XzRW5BJVbjJ7gda/B7bMezeA47
8TxewssIXyDSDZ/gU4xbKDJ+ofEeOjnFXw2qa8T4OyVV31R9UfWN8aFPV3//tp1/XFoHKU7lgPqo
Pgm0zlejVf8Mf83atr+fdaj/asfYTmqsRKnjb0MkBmEkEjEBabgJN6MMj+DX+A1ew+t4A3vw3ziM
z/BXnEAN5pKu5uGcc1RPOg8cb8LAl486DXgO+svPvZttnnezOQ84h+w6cNi72T71OOVj54EPxa3T
QhAm1lAZ25fcGyrW3prq00LV2wxDe2thvTXL/QvFf7+/WP7jfGbnNyPFJ4S5LEwz5ld9LK+GO4vT
cX2GvK6Rx9shAj3RyynvH2UFxxBFGX0X7sY7WBIkshTb8A6+hh9lxNDg+vLiHtwbbJQZz+BnbMad
IfXlx7YwkcdwpBPrQevOIm0Qhk6Ixxz4dxHpiAj0RDwGIQOZmIUs5GEpfo5tXQkbu/EpDsEaTrpH
BPohBVn4324if8Pn0LqLDEQ6xvQQ+TGWYhm24AW8iFfwAb5BZgRlKBbhbqzFDvwZ+7AfX6EOT/QS
+QWeRJ3n7pyjO8PfuXOnVN+ZU6f0oVOnTtXUnKupMXrpV925GqdJZi9Jx2rpgs4gFVhCxKJpOSpv
DvcTGYGHUIs6tPZn//sb9cAM3IIVSCSNJCEZP8bs1ka6+QPex1+9SEO1zunZy4HTzgMu2dLLAJqy
TPMG0LwDXkbHraOUEGuIBK0RoyQJb6k83fI7sCkDZ72b7QqLm8sUo1PpQB3/bi1Rvl7Cne1STLgM
uITmMuAym+fQvIyo5wGXHOs5+3qerSnRceu0Luax72zm/5ao75py/C96wHNi8Fy1eE5NF70Jlys6
bp093+vpgDQQbm9/vIbjaN+buroP54S4FSvxFN7GGZqZnfuJDMZQzMRSLMMqrMOT+DJS5O/wiSL/
oxdSUYDCqMt3yK8moAZdg+N/uY/9QlRiE77tL/J/qELrAdQTiMJkLMBClOEObMHOWJHnsR/foRqd
B4qMxg3oHke9hG14DB/iO0yOF8nGzdiAQ+g3SKQ/JiAXe9BmMMNIwyL8FIdxDNYhzI9JWIk3cAIj
hrJurMU9eBEfIHQY59QYhZvxCA6g3XCRIMRgPH6BbxA5giN/1qk7ffb0ydOna2trnXpr3UZ/j86Y
2d7yt58JSG5LHJOmpHAvBzxXnp6rYpcpzRu3pkSneQfcOnu+18sAyoLwlsojXpZ/Vweae6C+U2mh
28WUV1FIxhy8gD/hEKwjmYbJWIwH8RB24yNMGHX5Ntdz5m750FokOkZnbwN0u9jjOAvFeABvYS/2
4Qj8rmW50SIVWIKN2I4dOIBqnMBZdB8jMgStxrIc/NEHiUhGETbid/gcNWqeBMobZGAltuNDtEoU
GYfxmIRCrMD2JJGn8S6+RRU6JHPOgzgMx0TkInAcaR8DkIo0lOAuPI53cBjH0Gk87SbMxb14Fa/h
dezDX/AhqmBNEdmKnfgLqqDX+6f0zt4EqK2pra2mo8+l36kzRzvN4TJDLSPNBdUBt1/386XmD9SM
+p80kN0Sx/Cik7rntu9FV6tNyWxXctzcOr3udzoHCG+JPNWU438JBy7h4Wv51OTWNTj+l6uM+39U
IyT1QpvblG2/XANetvK9nOIycNFJ2PN63LoG5//ux2YA3kcVWk0Q6YleiMJoTMcxtEkT6Y2xSEAK
ZqIU900U+T3ewEG0TSdcjJskchs240G8ha/gm0E4mIlZyMFi3I2+mUzDTajAEtyK9fgVJk0hTaIS
D2MLHsdO7MPJabRfp1MPYTRycAuexC6cQy3CZ4gMRR5W4Hm8gEM4ie43UJ4hEdOxAlvxLkJvpFzE
nfhPHMJhtP0R68VcLMfdeBVHEXkT7S1k36Tqf+Ps/rTb50mn7kKznHaesdrs6sfo6cG13jeuA3D8
s1vimHuZ/z0PuATgZU66ktfTlMaAlwNuXYPr/y2RBy9hje259PVywHOl88Ncj1vnfO1Hr/9bqkxs
3jTQvA3Cf+kBo3Oc/3tTP63CJuzCflwzk7YC4jARi1CJDXgOB2GZRRiYjAyUYy1qEZR1SbeweVPG
FZbOLjo6Ruc4/pfq+EYgHSuxCmvwBF7Gjtkie/EZzqEW1jki/TAGSdnUQbgZd+IZvAufHMoVRCIN
JdiCfTiFvrkiBShEBZZgJR7Gs3ggj7DwB7yG1/EW9uJtfISP8QmO4Tjq0DVfZBRuRAXWYwO2YRcO
4jTCCkSGYCiSkI3b8BCexXN4FYdRh1r9Kx31z7j4o/eqUTVnz+oXfMzPWqeupkYfe1b9599xPo8Y
F3xcPvivDrMvbT1f9TuvBtd/jO+AZHZLHKumJHXP9eVFt6Qu13papLxw6xqc/7dE3mnK8ffyIHnZ
ePI8m5ehXXQAnmer9jilKQP2zhqi/164QfuvucqyLoXMi2EYV6i+WBZZjS14DjvxPN4rdDvKZ5wH
mjftN2/QV3JoLgMXaP8bvxq3pwV1/vd9j9376DqfBdEN3dEDNkSgJ3ohBalIm19/H4i6B+Qe3Du/
/v6PF+cb93+o+zzuxTqsN+/5oLo7Y9R6J1X/CbM7bqI7cuTEhUq7f/vO1xJGbe9rac9/1QrwVS0A
s1Wgf//Tt6nH1PlYrscLTsey6wLjXp6PFxj38iQvNO7lsR9fL0t5z0WkSwCep3iZRbysGbyMgZfR
OXGZBpw6LQzBaG/WAYwLd8lvznO77P2r3b9YZz/+lgHSOk7rm6lJj+37Btq2Zw+L2E6G357p12vd
Z1rvdSJ9GA5DJ8RKQNz3mf9qd8V3HaSrtCYpzJIgsZjjeouMPXbeoj6llUyWEimTYskRdRummsdH
ilMDfFJZSmM4lTEB/C9gjnwpkkUyV2wSz9hgprfqrXV84qhc88R1qs3RUYb6r05KC5eJqeGSkWaR
KZDxhKJCGt9oSIP0kCyuIWkdVEjDVGCd6gNy6a6ThLHHz2/jkzNRSSbUQsKtYCsWE2om/WWYq/8v
lXmMG8+WLmKqcxcnM4nbcT6F/ZTJ0jl6zGwynRCX6XNb2Hf+xMJKLKwyRnqMZWu0MaL2nn1rCliP
sP3B0iE/+LxI4B5/sWzvmN1Ps0hbMbbCvryN5TuYy6s4lbAW+/Lt/+nyfSVq7GMSodHCkzb6ds5l
aRvHsYKjmGuGJDJCbmLLBmkj6G/L/imRPH2OAn0f2GSSvl9UHDpKTLJNU1vowxp8JFJmsIYELVKM
47Wc+VSoC/U9s0BfZkx/LbG/ZZTUZWgyVRvFOH+ZytYkuey5tqLuRdquGdvkuh3Xmctep2+HfVnX
1KFCDZXGlh4iA8ZO0cq0IfpaxjF3Pow96RyD1hJGDNpK+zVnCGOY9CfNrNaGMaV9g6Wm6mlIbana
R3n8p0Utqf3VcnUZU7QN+nKBDbazPrWp9XVmfY/6tl8z9pyx3HrtMX25oAssZ+SnVtKFeH5WRwud
sjvTV2RMK5G1UdTe80TPjZpeqHO2hh703okPcMAYLR/PMeb1EXlSDZ+n85EYR7+4dUZuV2s2DDCV
mbZewDYxFlYti+Fmv7rbUN1xpu46UneeqLsP1C+Q1a9Q1S8R1a+R1C9S1K8S1DeT6tsp9Q2Fukqt
rlSpqxXqjFW1WteZrRaVflX6ulZEz+ujofIOwUgCEpEMgtRLGFVeTUAaJoJVkDdEMjAFU824ql/G
q1/HqW/I1VVSdaak1jeSydcjCUySdGSC6JEmRE8VG7AZD4mxHzpGVJ+/r9L4H8QuUHFmj6qb4sTi
b+xnzYkaHivdj9FaE+OonJfKykrVVA1WBfVRtYJg8T/qb1/IRyUg61FVTAWJz9FIfXzA0WBp2Fmk
tb6c2khfc361kzqY41VY0k5kmrQ52p3e3Zpa19t6EjqvqSznYw2g/3qrkdzaH/UxY6E6G/pBxUAl
WlV8q81Vu81+ONQheIBt3IaANoSOXrRKo7E0VGQVKvGTUOMGwh04hBqksM8mIxNT8TlJqRqjuxA2
lnUlaeADfIKD+AxTSG45WKuSHb7CERxDNZ7sIfJsD2MD/PBChMgrGEoymIR12ITNeBh/p3Y8iV59
SHqoxE9xJ9aiivK3FlHsjATcgbW4FxtxjmTvQ9HxPN5CNdqSt0YjFWlIx4fRIn/DF/gaE2JFpuMG
/AiLBoosxwqsxIvs9D14E3sRM5j9j2RKwgxMwQzsJrvtxZ/wZxyhDKrBKdRiCQfsDuzAXnQnj/VB
P/SHP3mtE5KRhY3YikdBFS2F5MFilOBmPE2eeQVV8B1L1sNUtCNRdEcacnEX7sMmbEYVCeYETuI0
QsjL3dADERhNvh6HlHHGD5hmksdzkIdCdCGxReAAef4QFpPnb8UqrMZ68u9mPIRHsJPy4I94FXuQ
Q95eiEUoRThlRD9EYQAO4Wt8iyq0pbgKQ2d0xaoZpIkZxhel12I0ElB+I9NQidvxBEXcU/gdnkG/
WSIDEY8heIbyZRf+iNfx8GyRX+LXeArtslknuiIOo3AdKrACG/AANuNRPI2XsAvv4yAOYyhF7GiM
QSKmYTayUYHbsBrP4SW8jFfwHg7iMKpRB1obMgPZyMVSrMbt6FZo6G7qYbIhAj3RC2nIwhqsxXr8
Fi/iJezGHhyiNfAFNKo3X2yEn4RfdZUbH53F/DQ4T7e4DatumUYuQgI1VjKiqAAH4R28j9XUl49h
NzXUa7BSM/lhS1fj9uhF1DBl2IFnMZMaZDZ8qCn8kYp0tKZmaIfJmKpqC6rR+7Cf2uFjzKMltYvq
dOJI42f5G7EJB/AJ+lDyRuFdStn30IESNhT7sB8DKFEHwppm/JxrAyXaJoSQ87ugJ+KdSo2deBlv
4APMJFfPwVwswUc4hC9xAlnk7BwUYRlqYaFV1AVbabg9km9cbvY292eYuf9nZu6/3y33G7m8yw9E
YynPebpKeefPXyOq+TWRk7FyTktzONXIkSX6SUA6/9WY0TRoR9HgTKFfnZos5XM50/P1k7hypkxi
7FzG5jEmi/HqJKKQeWM4cSrgs5C+Yqd5Ymj2DuI0Tg0tME8ZYzjpjZdY5lYnI7Fm6FdjdjVmLR+z
FNaWpY8rYy41PUtfR30ssxyxnKOfsC/RY7SU8aWsea6XsS1rlthez8mi2o/TOQmdxMliFmdCFSxd
ol9SUGtaIuqygtq35frS6nJDCfGxNUssf8ixu9KOdBu5gTDUPOXEMpHP+boEcy+65pUsvT+PLVEX
rAr1XOK83uaNW5AcuG1U63V5hRnng9z/qC+DPml3f/us3zY27fH0NT3DJMCn4TRNPgodMiDIw7S8
iP6DjWni1mnil/j24Ad3P5DQ2Pr+q6hovKcwv2uXkL61dP+8xqY93bVTxvHo169tbNqZmC8yNQ9x
SQl/b8ZTdb+sa2y54QODSpM7/7xvY9Pqlp5d/uqKd29obNqnfv9zi6dtr152zuM0X/PTvbMGiwSt
2WdpvyauNmSPr2j7LK1KIh3XhPhv9XIRNV+s42KgZvX1bjFfc7FY/Xq8uahfY4uO8Gm/5s2z+qIj
fNSifk6LxrL++sUDvFk8wG3xWJpGTkG0aRiEuoKafUYP4lFfFUSbRoKIZZOcgwn8R3tXFxtVEYW/
e/eny4+4rWnFgqYYrCCwtjSN5UWL3UAwgda0Qv3BFqHQBstCu9UoGPtQfx54qJHEPpBgCBqNhkQh
8cWEvvCmjzz4ojyYaBNjDDERHmQ938yd7t1792534UXjfMnZmblz58zM7pnZOTPnnhtik6qrn7l5
U7FJ1ZHNPRFsMkiWsvL9sBGs7q3AKiPfWCm7+gC746n6mdm/FLvjKbKrX4JdhhtzmiWC0CxHnfqZ
uduK5ahDlq7HUhCvWrjiMO0wBasUryT8HVgsXJ2ApRDsfZFBORELycfyEIN4KZNqhGxlWSaJAKMq
xGxVJKNkkFlI0EKSka7IrC7EcElRa1iSYcpjaoapHxWEbSO0lN2JhJYphDKFdIka51g7EOxAuPOB
cEcyXbnQoMjMZ1pmBoMSGllodWyxptWx4pDj7feHigAryjSv9xkHzwqpdcc3f1Sub1jq69NFh331
JSsWiujZ8oqFKg3YmuaF2ktQ6rg69t/MlaY/zRWrP80VpT/NFbQ/zdWvP82Vsj/NVbw/zZW7P81V
qT/N1a0/zVWyP83VqD/NVbs/zZWsP124K4SWvCEUumPTjnKUTBpeWADXqj95uSZ0016EJ9bdPHfs
1geWO5tm5Rd03WQsEU+4sfh7bin7c144IAoVFSkqanuUSsYz/JyyZTkm+Z3Cx0Ui4bhOXdJdnH9N
tcQ0P/pFkaPlRE5ZwHS0qtpXJOMuEVn7dlHbxqCtZp7qVGXqYstcN+HGI8v0SB1TqhwVbtNqaeli
ndLluNSpf67plFfOHNwPKKVZ9xB4WGar9tT7q+VGnr0rqb84kG0lfdWRfVev8q+KaHUMcFBQRuOY
Tl8qNgxaiTADZl0M8BaZFjXjk+R83WVcFqFqaKOYPSBqO+QTOHJkqbLVolBo8GKNSnryIj+03zoq
0rTPixnLqp2SoryZuWoFdqutjRGVR0makDsnI7c8LP77uF3ggA5MR9Aj/vo7527c6h1Nf/FBCpse
vfSDCC3OOFCrIubPQVuqfCzEiWEeenL4Dnqevg5tNfQboDYIbgJq+ZpyoDT+tR6vDQ7U/3/WgVLj
+xyoBeZLDpQ+zpmL/395CfnncsrRk/SMQ4s44LSj2/GzVE6DlSYh8xrRffLBl5CoF6+gS+Wr2Uzy
GWc9u8eO8hWZoxPHJov5ci0YZx/2qHdvYtSU9b1NTZVlO7bi6AHG71O8D07kJnOH82zJoZauTBum
uslzB71uqv81oPnk+s/PXXFU/NeFhd/Pl8ZjXjsYcrZmyBk7pKhYWFhYWFhYWFhYWFhYWEQgSv/n
Fffa99fOZtakP/xI9P/Nty7yKZpE4Fq3o1+ZR12YOuootI7OPSXuAZyC3gOYAdQJ9mnow4gz0Lr+
WWhd/gK0vvwltP5+GVr3/9bj/SNKdXzGWzChdGDuVzLc5IXcTWPY3piCOcyKCh9K63ZH7xmsTOva
WCt7MjCWf3UERiefQ1EPb/Gu8WkulnjSSzPO/Y2hvl3ZoZ3P7cou9mQ79LNHJyWWxVZ0okuoQ1Jb
JOxEu1zdIp8M2yTWhR14Qq7T/KdN7mpDD7ZJLsvw/qfxFiwsLCwsLCwsLCwsLCwswjD6qTHsoc5O
LZdn3Tyr5zk9dVfqy9TDqZPzLJ46PvV26vQ8w6fuzgcXG6F1aer49G5B65ZmoTVCa4UehNakPU8L
WAfaKQE8DF8v9IhQK4ouJDYKPQat228W2gIa5QGPA8onj3ExQXs2+nrphNa/6XHEuJ0o5x2EHjy6
UXRJ0YNSLyH07BH0FEIbP7+3ENoAGo8h/eBeSqFAO7y9QvuEBoWeF3pB6EVoDyH7hV4WGhIaFjoA
9ZQ8DgrRGojeQw4LHfH4jUlISxt61aEl2bgQbddyXv4JaE8sk0L0ZzMl9JrQ617+30JvenFDftAe
jv5tWpS3m7x6zKsWNCHhGF6UoeQyvZc0r7OVmeNw895frp6/4sy+XbhBewbuCU175duVzdor0reR
IOuqsEqk19+fpUvQSk5+u1Yd1zZRh0L+j6pFM1yHY6aW+on9n+owIZLDWsfVA25viLzpx8S0x608
xpBTv3cUNkj9/MY5dqutn3t0xsoxEep5be3pkvpr/f6VvZlXv6NsHsflWq9IQe02ZQ3Ku7Wes2r5
/k1NulY+opeX8ZzzbDyrR5P0YKn+G7k3Ybl77ga1fv9+sDHBOcHi/wNHfv3Yci1Dwbmb/98B+7Vs
7uDU+MixvFoT7O7nNbmkBjPjGZOf6cKf274+UV7mLP49+AdQSwMEFAAAAAgAOpiKKNY24NMWJgAA
AKoAACUAAABkcmFmdC1oc3MtbWVnYWNvLXIxcGFja2FnZS0wMC50eHQuZG9j7Ft7cFzVeb+ybGQF
1mkINo8aOGxNI8HuWivJL2WGIOthO0iW0MpASmhz9967u9fevXe5D8nLtDNJm7b/JNPSZtKmnTZp
Z0gnpJ1MZzpt8w+0k2lDmnYSaB03hZmY8OoQGKBQHjWg/r7zuI9drZFlJSQzLPx8z733PL7zvc73
nXv03e984Myf/fVVj2ttv5u0Xu3tlX7tosSzHmBe3fycpi3IZ2+vrKzQozlg5b3fz9Tvufv+Ubtb
698M0V36YCRZ/PBkeo+mbdPKx8vHgxuDG7WOX//mHdpdd2jajvEejtcL4vmvJuo83BOXV1be/45l
9buL//u3vVp0TZbp9+wq112JHrZt7n4lLf5lXC/B9TiuH0+833ytpuVA9bPynq4DuF66Rdy3X5/v
cv3WNZq2CddvXyPu13Il+oeYpr2C8XdlNe2TuH8Bz7drnT81bzVe+68bXer6ghz3wYvFlfi6E9dH
cL1Ci+enfnT/qBbzRbVrv1L/M70xfaqf9vtvyfHbf+3yeie5P9/WH9FRviim57pLNe3L4Gd4NXjb
09l+vT81nprPP28W8mPzf3HtS3/+YE/7PA70a9pvQSHuuyatp+/u74gTWJ5jBWzKqdqOZXm2U2WL
un+CTbueYfXdVjioH9ePZ24pzOg1va8vqj/p6ZWg73BYrVk+K7mVYFn3LFZq+YHV8Pv6Jl0jbFhO
MMZMqpi3raCSb1hV3XDzXrGpGyf0qpUfGioEJ4O+8aZn19nw0NBQX9+EHlhV12uNsSNOxfUaemC7
jl7v6+vLZGZ5+92HC8Oj+9lCkc2LbjKZTCnQg9BnboUFNdtns1bDzWQWqWhKQhjKusMU/XlOP56Y
9MJ2WCWs15nhijEdw2LLdlBjOh42PXfJ9kEF779kGUQRKw7R3cL0xPDQ8F5256a7CiyTSfeOAcGS
Zdc7QUxVhEgqLfYOrGcDR6YWpwdzzBYd6X5OkItb1WfVc8OmX2BH3cBCn3rAXPTsyeesobcwA99l
pu0Hnl0Og9XI0f02rqDD1SbCBZlot6TXbZOBX0zHSCftRtigqfn2SdZwnaDmc3KJhrLFwqYJwZo5
5lnNum5QCQ3dsu/WLTxn5ZYkPUEXiafFArthgaBAyElvQhxQF50m7LLQj/mYZ4pYH6NULM8iMUKB
wFm9TsOhgWFzTlkNORyY5lCDLPGF9ADdVz3L9wtZRhpksTp4R/MyQs8jPWpnjYEOMEHdMNAKMwHZ
tSBoju3evby8XCC9L7hedTcVdhdtM6+XIQvdAJeh+iw1RJtylmq66S6zSduDzrmeba15MJ+3LNSC
Rr2QyRQLbFwOuopRtE+cS820KlBJn+vp7DST9krVdN93DZtbpTARXiVpmPOeG7iGWxcKKSkOiVri
PzTDwzsdbUxbZ4cgnmWoyMDsoUFW8dwGGal1kvig11XtuuXl0BGuZkfDuAr1MTEYq0pgOaYY1Ae5
fqXFSfWsu0MwVKgY5uMrex5WdpmaTKJ6zDWy9kxmuMAmXGcJD7hv4DNEh0GSwUKFTlgtYrMJNZs9
VlrM5sSVHZ3j5YWpW48dWZiapHLp8PjMTFRQNUqH547NTMaluOXE3Ozs1NFJ3hi9jn8sK7xEdm5+
8cjc0fGZbAdN3JjBlbLFmeQ1PW6BMALT8g24CTEPuLb8cLF4QM42M1JgyqmzOa+qO/Y9XAvEFP2w
7INV9LLpepyjyhkLv4GCK1rx7jE+8boCybnL5I8a+nFYqJSGP5bJ3EDm4LlmKOSDBvD4vl2FXqA+
Xo/7ftho8uq4m+S0N+ORLaovFRfvF5RHoMrjYVBzvQ/5bNw0SecxvdHCucfLlFRRLnL0GqxRDg6O
qW5b0h+GgUsLl8FF4VsNOx8/cpuWpysyXcfKkxajURkOiZcN2zNCePkcty8yOUcIypFrIZSyigLX
dKvRrLstn7eGH3EsPiRVAI1eTL+0vSVooh+CAqxoWGR5ZV3wQNYl3+k3SQxLVr1VWH3e8CWO36CV
KNmZ7CBHdJzIl1t5uuZgGNRYZ3SpQ+Qe1xOjhUnly0QAmbDthC4W8AAMESxET241jNarAiMtg6r6
3KtTjbIsSjWL+yXpca/qkIabtgFX4RMBmJZdgQgEoaJLXitmE9rOT8wyX8QxpLUGVgjHqkeOzzIL
cmVYhctwAn5q+qwR1gM7HxM3MDs9GM28Gdb95Og0cyJd8tf3pZq0iUhQ3i43YUuY53DeDYO8W8nv
TTDFcBtlW2gQsRErsFh1wZZA93h1ooaokDyjmgO3zA9yJcE0G9RcNoKPdsxubUqLg+Qw9hRSJspZ
Ftu78Ao6VZDrDFSJXAdfCBeP5ReJZNiUTg539K6UNUJM0E2IAQ/VUqWzrGnV9VYeqwPVybIyjB9R
qZmUMdkBHjvuMhaTKg8FWNa37Ht4C/CfN5B1xUqIPnk1PQh0o8b9H0hUwudxCr0Gz6su0WYRu+x6
PVnFU83Fmk31bQfzU/VJ8AatYrA7MpZ2ed9es5zz6U8EiqS+CBzNFs2aZA6bbu8719kYdmX6kjNc
NxRHd2cRJBiWZeYDN0+1sgmutvNAKGlbD6q+TeNDui3h3CLdocWaGlBPkW4Fqyh7PEE/rMCmbRIL
DzjEdOS6Fjla7iLk4FjOdRsrNkX70AweIsweUrmA4wYM0bgMHeDZEUsHqtIELZOk/bTsF9hh7oFo
RP6Aglta/EBzuy7K1uifAgqEzpxel/pKqGNDPuXmIDlLc6paDi0a0PJYV+V76ewCL3ROKMd0yzyf
DCIMxa7lmm3USMsavDZYk9cb5bpYLZquH8hbuXJy/uU7/VuOh3M8pQBj2vgnxoBQpGbSgs8o70Am
AipptXCXRdAIjopQCywp80Cca31ZPfd1ivkXZQ0y9oRSmnaVJB9nh0wsItx6/Ki9iCZnDxFT9hYS
6WIyVKBXiTxS1TiK9mPJDFO9ODI5xrwiG1jkDEBE6hrcJwY1aEm1xo6MHx0fzCQGGGM84I4CaD+K
hLGsmHUrpdBciTizlLvlkaV0jHwJXmUxLlvBsmUJNUjHxtxx4+l8afEodDqgtbSQuQ0ehFNWzEyd
pCDZH0MC6VjEi2GK3rGiB0g2Mhl6Kv0rd/tBYipUe4RNcYp5GXzM8FvJvRIUNfQs8Yz45t/DBoZO
IskvdnDIUrWlHSF/gf8k2+MGhdGXyQFyXyEdFSaeLbXbgoEkzY9MIuahiHMcxWBTjg79pF0BinWk
FPWAR/yWLxUpRVZHwEAWYNpigCq5lEAaAfed7dRhqCUoeoWiROKj2lZQaQMpO9ZNwdLJmMR53QND
ye+PZaJygskRNTwhl34USXOism0S+/GwiwRkZCQXYnCNJ/NmKANVWp3OMbFGiIk3SatwVSEMN0Hp
QJUQU75TKamQdU1f4qqmI1yiiYSW7Amcosl4hcxiq4kZk2uqUj4InjWwytpIGSAFPzPvIlwiH8Zb
Q6eHuNTDZoZl5hArekuWeU7eOu+k7YXh1RScjcf+O6HsumT18DmUPdHyvBQ/qYLtC013G7AdHtrD
o1hy5YmW6w6R6nURN/g8X7xA4+mY5nkaUtsMz8+czm1P55b5BqnNSEptxh1/2fJiTUGkL1VlZBVV
EbXXrx2i/bnUYr3STVJ2ngJVRG2gYzynFDbMAYymJDlRt/SEII26JwU5uoogeeX1y5E3z8v8JEuR
lXxESc47iZeerUfECZp5CkKBGstO2j6k6yDYEnQc1p1qPmxm5bRMq0lJhCSFilhOAtoxlKE8beSB
WejaVnk9n2o3lbFsPq4MTVW8tCHm376cpri8tmXVqFc2aF1VC6JdgWpgPeQhsZ/SCnAzp+iRnWaN
tGZIossWnpA2G3XOZx6XU5Kc1EOhfjotmiI/KYhotW3GiLgrFUo7hWhtsU2yLPUhzkr5Gl6mUDTK
TTFB5FM/ycV+I0yd2/qetNeWG4Wx28YDKfU9bVKfxCAqE+F7GLgng1Y5bCp18VViHicRnXmXsJJu
zkOvUOXE9kFqYDUqT5v8Nbp76QZUZ3L2SWff1m1ElSRDRHsICqFyvEpDb8qGRhBCQaOdKcopTcqj
c7FhcCJp8ycITSXjVRaS9r012j30hR+Te51BgtIU2z0rsiOT3238qrM2TWx3QZM8uy0F3Gjjt6Ry
pn+OBCq1654SQ1pQgntgA7fPJt9r8fh3TtpnpOQ+EDvNS5HCCfZakTeLGCQycZKstFdfkI2e5GgD
TWGoLdqoDlqDUKwg9ByZC7C7Q5dIFM0KsVXfJq1ajwdX86rp9B2L3E12KBuZTPZANtPBysXEMjgL
Z+WaaX4GjS4xerxpTEPSp1fprOlW7sUkeJ22DskKywkbsl7HvDL92WOz2UiY7JijN8p2le+Az5Jk
UGE+qjA8SAoT0DdM/jKnbJtIKIsPpPDoJ5u2xz8khI6SLicIfU1HfY0Msmn60L2ujhgTnnFvyjNO
63Y9ledX8EAOt7eNsQvcZZHkK6JVYtGXOqW+T8ffcHhw4HqruMUobDo/byYpVvL68QeW7Yo55Xku
OWzTSiukZXQxcDGxslRIxTuhmGvQN0YKN1NKaRzELPxDIsxEtZnFuYTezSQ3zqEdSBhRZyGuA31a
SIslUa80O6XqjQ7Gn4XprAZ9lzdq1HtDr1dCh39z4wvvqNzj4ptKo7SpJO7bdpXEw3NuK43zL3L8
w0DHRpGjlCsRKncmMXwlEZqEJasu02HZuFlr+fAS9XSO3TUSlbMQwhqYmxtEP7vdSoVlJuWqR7tw
gfiOaFBMloFf4aaBZgltivbqRgvDq/ImtSGR4FO3HQnFp/Y8u22/oGPnmX9mbtved9V+ePpbRcdH
iOS6LJaKVROBn3YBjKQFIFP7mOfdc/tIOZ2OdFgp53AX5fzZYc9omj1rzpcTltuZ9+rpzFcybdXU
hOamMg9Ey/zjsYzLo60vWitUeuXbphWt8zxNlbw0SK952LIqVwf4J/HQOTH4rogpDzElpDQftxQe
FalMWk1lLpPQ0+7JjJJF0mKjHFzQxT8rYb2enc6LCDzhXsVnKWLKuuN+JZALi/bXxM+DC4PsoGdb
3djZRePPGcSfRwwv4mkZRPOJ0YdIX26ji71Yv+PjcJfY+4LDaajOHr5Yw5Hbhi8iIXq6l3hiWJCa
+kiEyvsKySM2l2T2FzpO2VDt2+wTmII4U9rl8GhuJjALmUOhV9VdJ3dY91q6o+eOwJr0AisODw8V
92BuNYjrQHEwXyzm946M7sWvMHUyP7x/aLSQmdZPqrfDo/R6eD8d1/TY/mKxkGlMNRBAjbGlMlFx
c833CzXHL8AH0H7RLSFSWUdf0hkdeP1x0DgytH8kI2k4Uccg7STwCH3CbbY8u1oLRLwkDpNl46cD
E4NcZ6JTpCXXsK2gxQb4adocnaaFOxpHVwvUwId4RKgqN3ni42C0Q0gHTupc4/n5VJ7WtUQ+36SM
jypVkLnZPuUDUEj+1VYeSTUtjyJtWtgpfI+MstGQjg6s5/WXbcQSiDzryORpDHLnPv9sZIsPxHQm
gM9VGK6kAZ4biSqdGRXU5FgzLNcFKXz86HirybeKlmtu3RKenWe4ueijM9QQNcUJL57vthiyDeqQ
rNxUu6DckZTdJT59yXDHhRVYcj+V5wCeXvX0Zo27F6wh9ZDak7sBz/0QWTan1l+VRQV22F1GAuLl
WPpwHrhg1St85nQSAbNvuGaUdRPBWM1yon9YUplWtoa7FG/7tNHLEydll+psQYfSKAHFb9zEET+I
2TppWE3ufuTZCOWVm6GHHJ87FBPzqWPKICXqBvGhY+p09JHLhfYeDN0XAWAz8iLy/Isk3Y/yLemo
Y3Kj3nhbOEH+7bGsDhbJY8V8U42f2+SqqpTb4idGnMDNqF9/lxPl/fGJ9AySPO6uctwh9KdOpefn
jMAtQ4hUs/+DbH780BS7bN/29kbRqyJeZTYxLDK66ZDwS4Ucyy6uPsd5Ocd8HrYr1iA2ks2xgxPz
7ECODmgyOnyeY5IKVjxwYG+B9y8OEC9YwgblXq6Y5cC0VfZCeCw+vcEcW7QayMrpQXS+c2QfG5if
mTqKtyUsxS12iA6UsyLG4kezrDrvOXTUuR1FtFQYfkoeghiQx0x9PxRbPp1/DNCUaWF+aB8diB5c
hT23RMdnSU3oyLc4nsrV+Yjcq8Fk45O6M6SJvmRVcVTyqlgE12Z1DzoITu2jkUrySGDs+UrR5kJ0
wiLHbi2MFIfy+HcENwdpv/qg657IsYmJI4uLkOg7/53Fe7/3fj+Vv82adniLph0B9vZr2r5+8ZdK
Y8Cu92na9cDAxZo2CNwAfAS4GfilbZp2JzAzommzQAlYBI4BtwG3A1WgBjiACzSBu4EACIH/AE4B
vz+qaZ8D3gLeHhV/d6i9jv9eBV55lReef/b5p55/Vlz4O/rvvV/it3Xoo5dqjcMQ6GYqaZne4/SY
yse29vReckNf756tn4qeXkFPtetJ/oz+whHYDQwBHwFuB+4AfhP4XeBe4CvA/cBXgb8E/gr4p83i
L9++CTwKPAbMQpeOAlf3ado1wKeAN5Okvpa8+Z/kzdNfStx0b/P0k2urVltbteRNsuf0zQ/WVu2x
rm/+K3nzn+u4oV/PduByrXeHdvMvwnp3aL27eqjUs4P+mnXHrp7Ld/Vs+nxd2/q9rdqmz63MX/nQ
gLZ5O2ptwjtRn0poT/dX/qTk/wTwJPAi8FKf8C8fBj4B6MAA/MwgcAMwAUwCXwD+CPg68E3gGeDs
2df+9+xZ+f/LL7/4o6dffPyx04/820PfeODrf/O1++/70h9//t7P/Pav/9pJ39G2btquXaT938qK
KG2LSvmoVIhKvxGVPi1KO7SL/iR69qdR6YtRqXJWlapnVYvPRM8+G5W+96YqnX5T1XsievZkVJp+
S5W+EpXuj0qtFVW6R5Qu1y760Yrq77mo9ExU+m8qbUFpi9aLfzf19mh9aN/bs+V9fbinq3bjRsrm
FaAPa8NWoD+xZlwHxcwC+xAn7QfeSurzG8mblFmmqnW/WU+bje1gY282lpy2H7yE1rtde/+nNeFJ
dp6P3D62LV73jwMngAeAB4HvfkDTHgaewsrzNKB9EAMAGWAb8CHgGPAy8DZwyWV4B+wErgbGgA8D
08Ah4ChQBpaBe0Ho7wFfAx4D3gC+ion8C/Ak8DRw8eXQU2AQ2A3MASZw5gpNexz4IbAC7LwS4wEH
gV8BPgFUgBbwO8D9V6Fv4CHgKeAZ4JKfR7/ADcAQcBC4A/jBTvQPPA68DZx99aXnnvnhmUfP0O/7
Z87IK5VOU+n7p0/zu9OnT586deqRR06dOXWK334H92dORa+i4uktm67UMj1bNl2Ff3vxby/uyZa5
H/jy67DvXpSEh3pD2f0DbyhP8WBU+oeo9O9R6QxKC++WXNeovmfXVu2Cb7qPsx4KUj5tPRSkblK9
pW7WQzXEd6XwA2T/V78bNrbGea+RCeu56S6t9SxHa5zCGuezRk1aI21tPy73q6QOkP+/UJ83crWm
3Qr84TWa9nfAw8AjwGvAZddq2nZgB7ATGAIOXbvRFtH9TYpFa2T4BdN2wcqwRjVZ4+TafsrulQ7s
XK8M2XWID4CbgDuBjwOfAr4I/D1wOKtpnwW+Dfwr8AKw9Rc0rQRYwBLwB8ATQG4X/AkwBOwFPgro
QO/1SHCA64CbgJsBC/gk8AXgG8Ap4Bng/9s7F+AqqjOOf3sfuTcJklzCS0C9+ABMzCUQAhF5JCEk
vBMgasRUguGRlEdiEl6V2tjG1k6xIlLFllardsa2StHaEa0O1nEcO1rH0WrrVC3t1NGhjo2IIiTk
9v8/Z2+y95XchAgys1/mt7tnd7/vnLP7nXPP2bN7MhhdoMlgBbgD/BjcCX4G9oGHwEHwGqgbL/I9
sA8cBE+DQ+Aw+AIcmYB4L0cdBq4E00EBqADrQXKmyCVgBqgE14GVoBHcDg5kifwZ/BMcBv8CH4IO
MPQK3IVskZEgAErAKSXtp9rbT6B7c/w4t8MlxgGerPceP67Wx461h62Ph7SUp+iWRKj9wFYD2xNS
fTbu5VdY/s/NwFdYa0VIVPk/G2UrwVven3r5tAOnXUnHNxB2Y/sT6E88EWJt+9EHxpzpuq4mu3+3
IsG8n/YtH9h4wm7FmcpPj/d/lOX+s/yH7skO8CJ4F4wKiIwGY0AWmAQmg0JQBErBPDAfXAsqwXWg
HjSAHeA+cBC8BT4DaRNF0oEP+MFMUAW2gd3gbrAHPAb2gy8mIyPgS3ACnATtoAOcAp3g4lz4Jrgs
t3vsgeMOlWCFZcyhETSZ4w4cYyjOE5mbp8cZzJ/XE+q3F4svsP6sXYu5bhMsPtHy348+6ZYPPgm7
V2dZ3I4R6lmBTy3TsXQYhvn8z43fe71Mdob9/s8+G/d+YAtpgiXptNsMpx3PF3GPDGwgLB6rOIeJ
OVLQXf9/FWXRWgatZe/NXD3mN7C/2CetgbAxwQQNhF2vMAPxj8QPHIsbCLPWn0D8SMPG0MICSowR
IB34hBP2mmNHqv/P+7F7ih6D7ZgSo3602hnYgmvL2RFV9kV7hSdLUnKMceWGXHTg9Yn+A9VTxx5A
YT5Q7rlk12Hj0l0o0AiPACNBQJJz+nK+LV97GSKjJQXucL2kqdmKKeiuF3wadKhZapNkidRLo2yU
VbJB9IzGLtk4L9k1D1oGwvOwJxnLNThjtdTJJlknfpkknEjakKRLjYyH22TowzNY52RInvfWOQvG
yMJ5Y6RsgUOWAimBFVoqiWlpsrLkCLdkDKGlqTQ2sttQmMyQwoKjwV9iLTJcimF1LexuRi6aYbUc
241gnVo2SC32lSCnm3DUKjmyAmk7irXgOpVDe5VKmV8qYHGbOtuBa+dFKpxIhVNmyUUFyI0xS3j1
QrlZg3g4eJIuQ1anB0XOe8krjgMZ1eMNhwwSnYuQvh/6Q0x9pqkesYT0fb3qj5PLCx6UsQZqeElV
+VwHbT/u42bcxRtNSyL5ch1yNtnIF86DXYxYatQZa9Q18MtidV2YhgzJLvYbzKELMbhkglyNGAoN
zorN+7Ud59HqBnVl1iudWZlGUaZjunSWGbLMmI59XlmG3MwJu3KDhGORBwydp/B8zDB1Z6h8hHTD
vYNWh0ss7SmSVbDUaDSmqFjm4uzVQF9JawpSZARSMEh8rSdhY6pkwmduNabiiC9Ka5nyIeaU16gG
S/yWyrxM6nWWLTV2K73zovLZ7W2M73zE94Db11rQofXuMh5Uemk96OnylCSjkM7DnWiBo/6e6kZJ
TUIT3oMSNElUaTRUxS5SDS7C5g/B6+BNvVv14Hku1CoZ5gzwSZLdtS0Roku7Ol+RZVJtcnMP3CLS
NYv8GHObbxtwxJGjThx54NNHPoHiUwj2RNgaZYuEOhdABYdlLLgYXAJwqtCvx4PLQaaZHtrmSDaf
ZrNHS31Oz+0XPdc2PbUCXC96Zvl6sAVsM9OZMfZY8Cctepkm0sYygRy3cR50h1dfB8MCwwVy4aec
Kl9ftaC0tLSw653OirRtt3DL2+YNKbl4g51trEbSxNU2Qe1PbtNz7YeLQ1KUHjPlNs8vElbVej9t
yWCR5ZLaxkweMhjXK+oWBw0WCZczGduzndodfG0uMxUUv+jLxxSgbya3IC8/ADciKXVgPdgIdqOt
+CA4Av7n04O/naAsQ+QaUAlWgH/jVh7lYC9aFXlgO2gB3wW3mYOIfwQfgiAoQqtjPlgIlozQA4ef
gkK6A3gDvZIjo/Sg0zRwJZgJVuPWbgBj4ReTQBVoBveD34BHwf4L9LT2J0EH6AQLkOGlwAU/GgoK
QCVoAT8Cd4A7wUH42PPgBfAiOAx/+wgcAR+DCvheFbgBrAKN8MPt4GZwC+jARXXhoiaBFLoz/HMT
aACNXMNXN4Mt4GawE9wL7gP7wUHwDPgMnAA58OurwEywDFSBGwD/yQI5YXLSpB10gFOgE1yGopQJ
FoFrwAqwEqwDN4Em0Ay2glvAPXDNn4OnwXOgGNVEKfCg8J55PANopzdbLoXDXGusaeCfI8ouZQkK
1Q1gFXgJjEA5Gg8ywSPgOZz2Nngf+FF0n0Kx/Cv4CFSiuqoaJLIXPARmoVpMRXlKy9AvVbCc1YDg
UNVxl9GgCJSAG8DLKEuvmoPzg1CO0s3B+eMoO+0gA2XmEfA56AR5KDuzUD6KwApwEBwBTpSR0gv1
ANBlYCag738ODsCnXwAvgyz45ET6JdgB7gZ7Tf99APyOD4Mt/jsYvuoH08AM04+LwXJQAfaDv4P3
zAfHn4PtqLq/BT4PJO7nJfDdhRY/j/Tvbj/24OfTk8A6FAoPRy97DoW2Yx3tTZ/E8kqrbYdaBuke
+DFYiKZbExqxq9AwWYWfNjYZFmHJPbPRqJguVfgBnItGXTm2CnF2M34E2aCpwXqLatRsh06T0mZj
px5NHT+aP2x+rMXZ2WhyrcF6LbbYSFyH/dRlaC0agAytNxub2Wgu5+DXpVk1Y87l1M1Ew5ipK8U2
G4Fbsd6uYmZzuQlHFltiqxqQFAVM63bKBjplpYitSu1rxFk8XqXi6E5lVVcqV6pm/haVoq3Y34CY
1yWY2kY01+3U2qlNPLWpcg1s8JwmpLII628qCszaMbwsVantGuSE3eC1qhRZ4w1PWy1sNvU7ZWny
t+9MT9lVs7YsmBb5J/Js2j8G3+OreizWsYcWtV48QpJd0ccMeWf4lKy0OMdqxmbm6mMSIYZ4il7J
/emhvYWx4vtDXV1JPJufDS5c9IuGt2tjHXt89Miyo1e8eFWsYyezPyg34qSldMwbVz/a+UhnLL1p
E9Mais/fOS7Wsc6t7dtfuPm1a2Ide9fz1rfi5f3Yto64x9zmOlKc6Mmltb7u8LXmnBr2kluM1x1J
9RO6+rFYOhNU4XmBrgcMhtOdmJrbVAuoZ3ymqieWar7L1/pyu1LNd1HVY1ENIP5u9eRE1JMj1ANo
QllMpEab4FOZ6pPKxANumkiNYSKALFnNWL/91Ga8Hl/rl18qM14PzZwXx0xAksJNWW5sHFNpPZgK
4IqFm/NFmGvw+lp3HVfmGrw05+vFXIAPE7RJiRRtstbwte7tVCZrDZp0mCYhroSdyyWhdIQUE3Sv
JLFmoEs5MQfzSmTuuw3EcrEo/0iJMuAKN5KIkw2KacQdYSgBNxsc11BSpLEoR4vyjPQejXmiDPbq
akN6Neg1jYaKqVV6cLbLRXtZfzw0hpLEUNIafaxj7YJgF4T+F4R++XTPSpXwmUe0z1RGemhcpZHO
rphGOruLHE8fEaUikhojeWULDFkKVLvjqbae46tGfOVatdoSX1KPSnFyltKjUk8Ftk/1Qt816HVs
HVtPZkvTGmaL1Rpmi9IaZgvaGmbr1xpmS9kaZiveGmbL3Rpmq9QaZuvWGmYr2Rpma9QaZqvdGmZL
1hqO9w+IE5OoJm+UBAucLYYa4CLb3jsibKtymxJaO9LN0zkKVs2xkgI9yFI6fBfuoMOR5HS73A6n
i0MiVrnfXFegy8WOFLtpS1SHjOOC9Wp8fBOO58GOQ9xuw2F4khxd9W8oWkoLF8vRjeNobL0aVc8d
p2JPTXI5KHFjL0S3rU70SPzsPKXjcSY7HG6HK67OHMSxWenxMVoo1UhpV5zIsgtx6tvV4jX1QoOB
FarLrHPIkTiXTPLePhIn4reqVnn9nyqKx5Encou/rxPxCsrrM3zFiJ8LQqMlfZl0i+5EhArMWKeI
2ci0pc/yq6TnPU/Kk3CqITl0s/PRbRcsRe6c2JtuohIMDjG3hinvaYb/8J2Q9fCma82t0NsapQjR
30J1VaosVg821qhj9KRGnNkU94GHLWdWOoMsfBFVh+jSefi2+4+eKKtN/+1dXska//t34GCyxxDV
guHxvaJHwh8ALMTPiy7Ir4quUw+LfmvgYxHVmecri6xdvIao3vkY09YEQ9RvdbEhqstdbuj/zF5l
iOo7s5bhb1Uz1vwh2GHoCrXVUJ8jy05Dp+M/Lj3qPxws0f/tyn+tOZ20msBK8tVxVfPgOLcZz+K6
9ZwntLZxU1P3ceyL3GYelnDyrw1SG9K1zGeodJmOybJ+FbczlO2axvqm+rXNTMlqf34gRzYXSLeo
7epZ8359/yFDbTuud/C/h1u3nWY6uGbNyjVr16hOhS222GKLLbbYYosttthiiy22xJF4/X/ucbz1
l7f2BUan330v+v9XnNhfjH3uiH0Fhp5Zk31h9lE54yb76Hz+w2cAO0Q/A2gVUaPNO0UPHOwR3dff
J7ov/7Do/vKjovvvT4ru+z9r2n5fwvv43PZLo+oD89mi09Tnmk++uJ40zCuhgad46wvTdbrjPzMY
lK5jY6zMSUVd84Y1EuqT75Xufrjf3MevOagxywxzm883VpbPL15ZevX84q6cFDJW4fcShVIskyVP
8kEuQtlY58kk7M3GkuscbOVLiUzDfv2qTiGYI1fiKHV4fpF8W2yxxRZbbLHFFltsscUWW2yxJVpC
/dPQSzjss7OXy7FujtVznJ59V/aX2Q9nn5xj8ezjs9/OPj3H8Nn35qeIw0T3pdnH59fzfBNlFBgt
ehYAftXPnjS/7PdL+Nf9/FLf+oU/P1G3fuXP6QQ7g8EgP1vnyy18H4HzInCGEL57xrke8kT3v6cJ
Z7gQ9I5FOPvEVSJqJpCZovvltFMgugdeJHxLSoTPN+aKqHlIeJwzm8wHC8BCwPfxFovusfP4KbDU
3A5xrgnfXeP8Fn4120Wz+tCyLzJc3EbIFn0oKVk/S3peH1avJBYkP34h32Mo31Po53q5mC/BCe8f
3y+7UTbImkjTCclgeK81P71rqCkp5WHz5Uv9/tLqqPlPEpVR4jBYZvoSP+UblXrtluUq1o3qU7Tt
8Df9QZeecadZ6qRevVcYTyYgfl5xlt1E45/NhflGojsq531LTz7i7+v1L+XCjN9Q7ydulAYpgxf0
/f2vIcJZDnWd1ZfrH4pJx8qP6ZqlXJWFDT3qRcpw5KC3/If8PrSOdc7pSF+vv1WYmHOx3rJlYMTA
3XemmDMBRdTd/P2OeH8t9B8iVZtg8XLuwy5VmLkdCB0P5MuxK5+4KbbP2fL1kf8DUEsBAhQAFAAA
AAgAyJWKKCRHsskVMwAAAPwAACYAAAAAAAAAAQAgALaBAAAAAGRyYWZ0LWlldGYtbWVnYWNvLXIy
cGFja2FnZS0wMS50eHQuZG9jUEsBAhQAFAAAAAgAOpiKKNY24NMWJgAAAKoAACUAAAAAAAAAAQAg
ALaBWTMAAGRyYWZ0LWhzcy1tZWdhY28tcjFwYWNrYWdlLTAwLnR4dC5kb2NQSwUGAAAAAAIAAgCn
AAAAslkAAAAA

--0__=2BGeRJftTEkn65OEJnJvmqAsgagQ7CMtD48sWHWQjjrXM9GgRaylh7OG--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Apr 10 10:34:40 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14418
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 10 Apr 2000 10:34:39 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7E83D2E0@standards.nortelnetworks.com>; Mon, 10 Apr 2000 10:28:21 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 123285 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Apr 2000 10:26:35 -0400
Received: from smtprtp.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.3F0DF190@standards.nortelnetworks.com>; Mon, 10 Apr 2000 10:26:34
          -0400
Received: from zrtpd00y.us.nortel.com (actually zrtpd00y) by
          smtprtp.ntcom.nortel.net; Mon, 10 Apr 2000 10:32:04 -0400
Received: by zrtpd00y.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <24DYG60J>; Mon, 10 Apr 2000 10:32:04 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFA2F9.8962463E"
Message-ID:  <5F68FAE98163D21193750000F81AC9BE010FDFEF@zrtpd00x.us.nortel.com>
Date:         Mon, 10 Apr 2000 10:31:58 -0400
Reply-To: David Cromwell <cromwell@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: David Cromwell <cromwell@NORTELNETWORKS.COM>
Subject:      Re: Conferencing and MEGACO!!!!
X-To:         "Rosen, Brian" <brosen@FORE.COM>
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_01BFA2F9.8962463E
Content-Type: text/plain;
        charset="iso-8859-1"

Comments below.

David
--
cromwell@nortelnetworks.com                   Nortel Networks
ESN:            351-8870                              35 Davis Dr
Public:    919-991-8870                              RTP, NC 27709

> -----Original Message-----
> From: Rosen, Brian [SMTP:brosen@FORE.COM]
> Sent: Monday, April 10, 2000 9:54 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: Conferencing and MEGACO!!!!
>
> If all you want is a simple mixing bridge, then you don't need the second
> alternative I proposed.
>
        [<dcc>]  Agreed.  I see most audio only conferencing inplementations
using this approach.

> However, as was pointed out, using the controls in
> the protocol, you have some limits on how flexible you can make the
> bridge.
>
        [<dcc>]  I'm still unclear about how the context per leg thing
works.  Could you give an example?


> If you want to go beyond the capabilities that the protocol provides, no
> problem.  We have a very nice extension mechanism, the package.
>
> I build a media gateway with n ports into a mixing bridge that has some
> arbitrary capability.  Each user is connected to one port, and there are
> a set of controls (properties) that define what that user hears/sees/etc.
>
        [<dcc>]  So in this case the entire MG would support a single
context with individual conferences being defined by a really big topology
descriptor?

> We had the example of separate audio/video topology suggested for
> example.  You could make a video mixer which showed the last four
> speakers other than "yourself" in a grid.  Anything you want.
> It's a completely general way to build any kind of bridge.  All I need do
> is define a package with the controls I need for the bridge.  Of course,
> I have to get some MGC(s) to implement the package!
>
>      +------------+
>  ----|            |---
>      |            |
>  ----|  Arbitrary |---
>      |  Mixing    |
>  ----|  Bridge    |---
>      |            |
>  ----|            |---
>      +------------+
>
> If you can use the protocol mechanisms, including topology, to get what
> you want, I would think that would be the best way to control the MG,
> when you can't, you can use the n termination, lots of properties
> approach.
>
> Brian
>
>       -----Original Message-----
>       From: David Cromwell [mailto:cromwell@nortelnetworks.com]
>       Sent: Sunday, April 09, 2000 1:21 PM
>       To: Rosen, Brian; megaco@standards.nortelnetworks.com
>       Subject: RE: Conferencing and MEGACO!!!!
>
>
>
>       Brian,
>
>       If as you suggest you built a conference bridge with a set of
> terminations and made each leg a separate context where would the mixing
> take place? Are you suggesting a mixing context which contains ephemeral
> terminations, each of which is connected to an ephemeral termination in
> one of the leg contexts?  If so, you could control the conference topology
> by using the topology descriptor in the mixing context, however I am not
> clear what you would gain by using multiple contexts v.s. using a single
> context.
>
>       Regards,
>       David
>       --
>       cromwell@nortelnetworks.com                   Nortel Networks Cable
> Solutions
>       ESN:            351-8870                              35 Davis Dr
>       Public:    919-991-8870                              RTP, NC 27709
>
>               -----Original Message-----
>       From:   Rosen, Brian [SMTP:brosen@FORE.COM]
>       Sent:   Sunday, April 09, 2000 9:40 AM
>       To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
>       Subject:        Re: Conferencing and MEGACO!!!!
>
>               There is one explicit mechanism to support conferencing in
> Megaco,
>       and there are all the pieces to support another.
>
>               Look at the Topology mechanism.  If you had all of the legs
> of a
>       conference in a single context, topology can be used to control
>       who hears/sees/... whom.  That is enough to make a pretty
> straightforward
>       audio conference bridge.
>
>               It is also very reasonable to build a conference bridge with
> a set
>       of terminations, and make each leg a separate context.  That would
>       probably take a package definition, but I suspect that it would be
> pretty
>       simple to make one.
>
>               Brian
>
>               -----Original Message-----
>       From: Medha Vedaprakash
>       To: MEGACO@standards.nortelnetworks.com
>       Sent: 4/8/00 3:51 PM
>       Subject: Conferencing and MEGACO!!!!
>
>               Hi,
>
>               I'm looking for some information on providing conferencing
> support in
>       the
>       MG,MGC. The Architecture and requirements document mentions the need
> to
>       support MP functionality in the MG and MC functionality in the MGC.
>
>               How're these related to the Context properties which is
> supposed to
>       contain "Media mixing and Switching properties" . However, there's
> no
>       formal representation of these Context properties anywhere in the
>       protocol spec.
>
>               Is there any other document that can be useful to me?
>
>               Thanks,
>       Medha
>

------_=_NextPart_001_01BFA2F9.8962463E
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: Conferencing and MEGACO!!!!</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Comments =
below.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">David</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">--</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">cromwell@nortelnetworks.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; Nortel Networks </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">ESN:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; =
351-8870&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 35 Davis Dr</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">Public:&nbsp;&nbsp;&nbsp; =
919-991-8870&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RTP, NC 27709</FONT>
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Rosen, Brian [SMTP:brosen@FORE.COM]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Monday, April 10, 2000 9:54 AM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Re: Conferencing and =
MEGACO!!!!</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">If all you want is a =
simple mixing bridge, then you don't need the second</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">alternative I =
proposed.=A0 </FONT>
</P>

<P><B><I><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">[&lt;dcc&gt;]</FONT></I></B><I></I>&nbsp;<FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial"> Agreed.&nbsp; I see most =
audio only conferencing inplementations using this approach.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">However, as was =
pointed out, using the controls in</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">the protocol, you =
have some limits on how flexible you can make the</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">bridge.</FONT>
</P>

<P><B><I><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">[&lt;dcc&gt;]</FONT></I></B><I></I>&nbsp;<FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial"> I'm still unclear about how =
the context per leg thing works.&nbsp; Could you give an =
example?</FONT><FONT FACE=3D"Arial">=A0</FONT>
</P>
<BR>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">If you want to go =
beyond the capabilities that the protocol provides, no</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">problem.=A0 We have =
a very nice extension mechanism, the package.</FONT>
<BR><FONT FACE=3D"Arial">=A0</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I build a media =
gateway with n ports into a mixing bridge that has some</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">arbitrary =
capability.=A0 Each user is connected to one port, and there are</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">a set of controls =
(properties) that define what that user hears/sees/etc.</FONT>
</P>

<P><B><I><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">[&lt;dcc&gt;]</FONT></I></B><I></I>&nbsp;<FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial"> So in this case the entire =
MG would support a single context with individual conferences being =
defined by a really big topology descriptor?</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">We had the example =
of separate audio/video topology suggested for</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">example.=A0 You =
could make a video mixer which showed the last four</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">speakers other than =
&quot;yourself&quot; in a grid.=A0 Anything you want.</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">It's a completely =
general way to build any kind of bridge.=A0 All I need do</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">is define a package =
with the controls I need for the bridge.=A0 Of course,</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I have to get some =
MGC(s) to implement the package!</FONT>
<BR><FONT FACE=3D"Arial">=A0</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">=A0=A0=A0=A0=A0+------------+</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">=A0----|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0|---</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">=A0=A0=A0=A0 =
|=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0 |</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">=A0----|=A0=A0Arbitrary |---</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">=A0=A0=A0=A0=A0|=A0=A0Mixing=A0=A0=A0 |</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">=A0----|=A0=A0Bridge=A0=A0=A0 |---</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New">=A0=A0=A0=A0 =
|=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0 |</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">=A0----|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0|---</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">=A0=A0=A0=A0=A0+------------+</FONT>
<BR><FONT FACE=3D"Arial">=A0</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">If you can use the =
protocol mechanisms, including topology, to get what</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">you want, I would =
think that would be the best way to control the MG,</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">when you can't, you =
can use the n termination, lots of properties</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">approach.</FONT>
<BR><FONT FACE=3D"Arial">=A0</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Brian</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Tahoma">-----Original Message-----<BR>
</FONT><B><FONT SIZE=3D2 FACE=3D"Tahoma">From:</FONT></B><FONT SIZE=3D2 =
FACE=3D"Tahoma"> David Cromwell [<U></U></FONT><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Tahoma"><A =
HREF=3D"mailto:cromwell@nortelnetworks.com">mailto:cromwell@nortelnetwor=
ks.com</A></FONT></U><FONT SIZE=3D2 FACE=3D"Tahoma">]<BR>
</FONT><B><FONT SIZE=3D2 FACE=3D"Tahoma">Sent:</FONT></B><FONT SIZE=3D2 =
FACE=3D"Tahoma"> Sunday, April 09, 2000 1:21 PM<BR>
</FONT><B><FONT SIZE=3D2 FACE=3D"Tahoma">To:</FONT></B><FONT SIZE=3D2 =
FACE=3D"Tahoma"> Rosen, Brian; megaco@standards.nortelnetworks.com<BR>
</FONT><B><FONT SIZE=3D2 FACE=3D"Tahoma">Subject:</FONT></B><FONT =
SIZE=3D2 FACE=3D"Tahoma"> RE: Conferencing and MEGACO!!!!<BR>
<BR>
</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Brian,</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">=A0</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">If as you =
suggest you built a conference bridge with a set of terminations and =
made each leg a separate context where would the mixing take place? Are =
you suggesting a mixing context which contains ephemeral terminations, =
each of which is connected to an ephemeral termination in one of the =
leg contexts?=A0 If so, you could control the conference topology by =
using the topology descriptor in the mixing context, however I am not =
clear what you would gain by using multiple contexts v.s. using a =
single context.</FONT></P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Regards,</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">David</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">--</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">cromwell@nortelnetworks.com=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0 Nortel Networks Cable Solutions=A0</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">ESN:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
351-8870=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 35 Davis Dr</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Public:=A0=A0=A0 =
919-991-8870=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 RTP, NC 27709</FONT><FONT FACE=3D"Arial"> =
</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D1 =
FACE=3D"Arial">-----Original Message-----</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><B><FONT SIZE=3D1 FACE=3D"Arial">From:=A0=A0</FONT></B><FONT =
FACE=3D"Arial"> </FONT><FONT SIZE=3D1 FACE=3D"Arial">Rosen, Brian =
[SMTP:brosen@FORE.COM]</FONT><FONT FACE=3D"Arial"><BR>
</FONT><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:=A0=A0</FONT></B><FONT =
FACE=3D"Arial"> </FONT><FONT SIZE=3D1 FACE=3D"Arial">Sunday, April 09, =
2000 9:40 AM</FONT><FONT FACE=3D"Arial"><BR>
</FONT><B><FONT SIZE=3D1 FACE=3D"Arial">To:=A0=A0=A0=A0</FONT></B><FONT =
FACE=3D"Arial"> </FONT><FONT SIZE=3D1 =
FACE=3D"Arial">MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:=A0=A0=A0=A0=A0=A0=A0</FONT></B><FONT =
FACE=3D"Arial"> </FONT><FONT SIZE=3D1 FACE=3D"Arial">Re: Conferencing =
and MEGACO!!!!</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">There is one explicit mechanism to support conferencing =
in Megaco,</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">and there are all the pieces to =
support another.</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Look at the Topology mechanism.=A0 If you had all of the =
legs of a</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">conference in a single context, =
topology can be used to control</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">who hears/sees/... whom.=A0 That =
is enough to make a pretty straightforward</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">audio conference =
bridge.</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">It is also very reasonable to build a conference bridge =
with a set</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">of terminations, and make each leg =
a separate context.=A0 That would</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">probably take a package =
definition, but I suspect that it would be pretty</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">simple to make one.</FONT><FONT =
FACE=3D"Arial"> </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Brian</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">-----Original Message-----</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">From: Medha =
Vedaprakash</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">To: =
MEGACO@standards.nortelnetworks.com</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">Sent: 4/8/00 3:51 PM</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">Subject: Conferencing and =
MEGACO!!!!</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Hi,</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">I'm looking for some information on providing =
conferencing support in</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">the</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">MG,MGC. The Architecture and =
requirements document mentions the need to</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">support MP functionality in the MG =
and MC functionality in the MGC.</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">How're these related to the Context properties which is =
supposed to</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">contain &quot;Media mixing and =
Switching properties&quot; . However, there's no</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">formal representation of these =
Context properties anywhere in the</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">protocol spec.</FONT><FONT =
FACE=3D"Arial"> </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Is there any other document that can be useful to =
me?</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Thanks,</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT SIZE=3D2 FACE=3D"Arial">Medha</FONT><FONT FACE=3D"Arial"> =
</FONT>
</P>
</UL></UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFA2F9.8962463E--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Apr 10 11:02:30 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16084
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 10 Apr 2000 11:02:30 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6A86F430@standards.nortelnetworks.com>; Mon, 10 Apr 2000 10:56:25 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 123332 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Apr 2000 10:54:43 -0400
Received: from fw7.usa.alcatel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.C7900290@standards.nortelnetworks.com>; Mon, 10 Apr 2000 10:44:42
          -0400
Received: (from uucp@localhost) by fw7.usa.alcatel.com (8.8.8+Sun/8.8.8) id
          JAA09232 for <megaco@standards.nortelnetworks.com>; Mon, 10 Apr 2000
          09:49:24 -0500 (CDT)
Received: from <murtymsn@axes-mach01.dsccc.com> (relay1.usa.alcatel.com
          [143.209.238.6]) by fw7 via smap (V2.1) id xma009072; Mon, 10 Apr 00
          09:48:28 -0500
Received: from multi1.usa.alcatel.com (localhost [127.0.0.1]) by
          relay1.usa.alcatel.com (8.9.3/8.9.3) with ESMTP id JAA20688 for
          <megaco@standards.nortelnetworks.com>; Mon, 10 Apr 2000 09:49:21
          -0500 (CDT)
Received: from axes-mach01.axes-mach01.usa.alcatel.com
          (axes-mach01.usa.alcatel.com [130.202.9.90]) by
          multi1.usa.alcatel.com (8.8.8+Sun/8.8.8) with SMTP id JAA00229 for
          <megaco@standards.nortelnetworks.com>; Mon, 10 Apr 2000 09:47:20
          -0500 (CDT)
Received: from murty by axes-mach01.axes-mach01.usa.alcatel.com
          (SMI-8.6/SMI-SVR4) id UAA10632; Mon, 10 Apr 2000 20:19:15 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_000D_01BFA32A.47D29440"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Message-ID:  <001001bfa2fc$2f26e640$8709ca82@murty>
Date:         Mon, 10 Apr 2000 20:20:57 +0530
Reply-To: M S N Murthy <murtymsn@AXES-MACH01.DSCCC.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: M S N Murthy <murtymsn@AXES-MACH01.DSCCC.COM>
Organization: Axes Technologies (India) Pvt Ltd
Subject:      DIgit Map specification with Reset Dialing
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_000D_01BFA32A.47D29440
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Problem 1.   Is there a way for the MGC to request the MG to detect   =
'#' and notify while specifying a Digit Map?
     This is necessary when MGC wants to cancel the previous user dialed =
digits on '#' dialing.

Problem 2.  MGC specifies a list of Digit Strings  in a Digit Map to MG. =
The MG notifies to the MGC when a matching digit string=20
     is dialed. Is there a way for the MGC to find out the matching =
digit string notified by the MG without performing the string =
comparisons?
   =20


Thanks,
Murthy



------=_NextPart_000_000D_01BFA32A.47D29440
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Problem 1.&nbsp;&nbsp; Is there a way for the MGC to request the MG =
to=20
detect &nbsp; '#' and notify while specifying a Digit Map?</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp; This is necessary when MGC wants to cancel =
the=20
previous user dialed digits on '#' dialing.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Problem 2.&nbsp; MGC specifies&nbsp;a list of Digit Strings&nbsp; =
in a=20
Digit Map to MG. The MG notifies to the MGC when a matching digit string =
</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp; is dialed. Is there a way for the MGC to =
find out=20
the matching digit string notified by the MG without performing the =
string=20
comparisons?</DIV>
<DIV>&nbsp;&nbsp;&nbsp; </DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thanks,</DIV>
<DIV>Murthy</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_000D_01BFA32A.47D29440--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Apr 10 16:06:15 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02322
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 10 Apr 2000 16:06:14 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D452E6B0@standards.nortelnetworks.com>; Mon, 10 Apr 2000 16:00:02 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 123715 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Apr 2000 15:59:01 -0400
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.47305610@standards.nortelnetworks.com>; Mon, 10 Apr 2000 15:48:55
          -0400
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id PAA14848; Mon, 10 Apr
          2000 15:54:20 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id PAA20781; Mon, 10 Apr
          2000 15:54:21 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <2MSF4JTX>; Mon, 10 Apr 2000 15:49:22 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFA325.DDFA99AE"
Message-ID:  <4FBEA8857476D311A03300204840E1CF678169@whq-msgusr-02.fore.com>
Date:         Mon, 10 Apr 2000 15:54:15 -0400
Reply-To: "Rosen, Brian" <brosen@FORE.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <brosen@FORE.COM>
Subject:      Re: Conferencing and MEGACO!!!!
X-To:         David Cromwell <cromwell@nortelnetworks.com>
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_01BFA325.DDFA99AE
Content-Type: text/plain;
        charset="iso-8859-1"

Okay, I'll make a contrived example.  Suppose I wished to do what the
previous message did - allow users of my bridge to have a different set of
who hears whom from who sees whom.  Another example is a bridge that
allows user selection of multiple simultaneous translations, or allowing
users
to listen to an arbitrary set of conferences but speaking in only one at a
time.
Note that it is possible to use topology to do the latter two, by having all
users
in the same context and subsetting separate conferences by using topology
to make disjoint sets, it really is warping the mechanism to do so.

Anyway, let's take the first of those.  So, we build an MG that has a set of
(physical) terminations, one per port.  When a user wants to join, his call
control assigns him to one of the ports, so an ephemeral RTP termination is
created,
and we have a set of two terminations contexts (the bridge termination and
the
RTP termination).  We implement a package that has a stream dependent (i.e.
defined in LocalControl) parameter called "conferenceID".  The bridge is
built such that ports that have the same conferenceIDs have THAT STREAM
mixed with other ports with the same conferenceID.  Since it is stream
dependent,
you can be in a different audio conference than video conference.  The MGC
manages conference participation by manipulating the conferenceID parameter
in LocalControl.  Topology is normally set to BOTHWAYS for all streams.

Does that help?

Brian

-----Original Message-----
From: David Cromwell [mailto:cromwell@nortelnetworks.com]
Sent: Monday, April 10, 2000 10:32 AM
To: MEGACO@standards.nortelnetworks.com
Subject: Re: Conferencing and MEGACO!!!!



Comments below.

David
--
cromwell@nortelnetworks.com                   Nortel Networks
ESN:            351-8870                              35 Davis Dr
Public:    919-991-8870                              RTP, NC 27709

        -----Original Message-----
From:   Rosen, Brian [SMTP:brosen@FORE.COM]
Sent:   Monday, April 10, 2000 9:54 AM
To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject:        Re: Conferencing and MEGACO!!!!

        If all you want is a simple mixing bridge, then you don't need the
second
alternative I proposed.

        [<dcc>]  Agreed.  I see most audio only conferencing inplementations
using this approach.

        However, as was pointed out, using the controls in
the protocol, you have some limits on how flexible you can make the
bridge.

        [<dcc>]  I'm still unclear about how the context per leg thing
works.  Could you give an example?


        If you want to go beyond the capabilities that the protocol
provides, no
problem.  We have a very nice extension mechanism, the package.

I build a media gateway with n ports into a mixing bridge that has some
arbitrary capability.  Each user is connected to one port, and there are
a set of controls (properties) that define what that user hears/sees/etc.

        [<dcc>]  So in this case the entire MG would support a single
context with individual conferences being defined by a really big topology
descriptor?

        We had the example of separate audio/video topology suggested for
example.  You could make a video mixer which showed the last four
speakers other than "yourself" in a grid.  Anything you want.
It's a completely general way to build any kind of bridge.  All I need do
is define a package with the controls I need for the bridge.  Of course,
I have to get some MGC(s) to implement the package!

     +------------+
 ----|            |---
     |            |
 ----|  Arbitrary |---
     |  Mixing    |
 ----|  Bridge    |---
     |            |
 ----|            |---
     +------------+

If you can use the protocol mechanisms, including topology, to get what
you want, I would think that would be the best way to control the MG,
when you can't, you can use the n termination, lots of properties
approach.

Brian

        -----Original Message-----
From: David Cromwell [ mailto:cromwell@nortelnetworks.com
<mailto:cromwell@nortelnetworks.com> ]
Sent: Sunday, April 09, 2000 1:21 PM
To: Rosen, Brian; megaco@standards.nortelnetworks.com
Subject: RE: Conferencing and MEGACO!!!!



        Brian,

If as you suggest you built a conference bridge with a set of terminations
and made each leg a separate context where would the mixing take place? Are
you suggesting a mixing context which contains ephemeral terminations, each
of which is connected to an ephemeral termination in one of the leg
contexts?  If so, you could control the conference topology by using the
topology descriptor in the mixing context, however I am not clear what you
would gain by using multiple contexts v.s. using a single context.

        Regards,
David
--
cromwell@nortelnetworks.com                   Nortel Networks Cable
Solutions
ESN:            351-8870                              35 Davis Dr
Public:    919-991-8870                              RTP, NC 27709

                -----Original Message-----
From:   Rosen, Brian [SMTP:brosen@FORE.COM]
Sent:   Sunday, April 09, 2000 9:40 AM
To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject:        Re: Conferencing and MEGACO!!!!

                There is one explicit mechanism to support conferencing in
Megaco,
and there are all the pieces to support another.

                Look at the Topology mechanism.  If you had all of the legs
of a
conference in a single context, topology can be used to control
who hears/sees/... whom.  That is enough to make a pretty straightforward
audio conference bridge.

                It is also very reasonable to build a conference bridge with
a set
of terminations, and make each leg a separate context.  That would
probably take a package definition, but I suspect that it would be pretty
simple to make one.

                Brian

                -----Original Message-----
From: Medha Vedaprakash
To: MEGACO@standards.nortelnetworks.com
Sent: 4/8/00 3:51 PM
Subject: Conferencing and MEGACO!!!!

                Hi,

                I'm looking for some information on providing conferencing
support in
the
MG,MGC. The Architecture and requirements document mentions the need to
support MP functionality in the MG and MC functionality in the MGC.

                How're these related to the Context properties which is
supposed to
contain "Media mixing and Switching properties" . However, there's no
formal representation of these Context properties anywhere in the
protocol spec.

                Is there any other document that can be useful to me?

                Thanks,
Medha


------_=_NextPart_001_01BFA325.DDFA99AE
Content-Type: text/html;
        charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: Conferencing and MEGACO!!!!</TITLE>

<META content="MSHTML 5.00.2919.6307" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=470034319-10042000>Okay,
I'll make a contrived example.&nbsp; Suppose I wished to do what the
</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=470034319-10042000>previous message did - allow users of my bridge to have
a different set of</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=470034319-10042000>who
hears whom from who sees whom.&nbsp; Another example is a bridge
that</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=470034319-10042000>allows
user selection of multiple simultaneous translations, or allowing
users</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=470034319-10042000>to
listen to an arbitrary set&nbsp;of&nbsp;conferences but speaking&nbsp;in only
one at a time.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=470034319-10042000>Note
that it is </SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN
class=470034319-10042000>possible to use topology to do the latter two, by
having all users </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=470034319-10042000>in the
same context and subsetting separate conferences by using
topology</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=470034319-10042000>to
make disjoint sets, it really is warping the mechanism to do
so.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=470034319-10042000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=470034319-10042000>Anyway, let's take the first of those.&nbsp; So, we
build an MG that has a set of</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=470034319-10042000>(physical) terminations, one per port.&nbsp; When a
user wants to join, his call</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=470034319-10042000>control assigns him to one of the ports, so an
ephemeral RTP termination is created,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=470034319-10042000>and we
have a set of two terminations contexts (the bridge termination and
the</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=470034319-10042000>RTP
termination).&nbsp; We implement a package that has a stream dependent
(i.e.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=470034319-10042000>defined in LocalControl) parameter called
"conferenceID".&nbsp; The bridge is</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=470034319-10042000>built
such that ports that have the same conferenceIDs have THAT
STREAM</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=470034319-10042000>mixed
with other ports with the same conferenceID.&nbsp; Since it is stream
dependent,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=470034319-10042000>you
can be in a different audio conference than video conference.&nbsp; The
MGC</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=470034319-10042000>manages conference participation by manipulating the
conferenceID parameter</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=470034319-10042000>in
LocalControl.&nbsp; Topology is normally set to BOTHWAYS for all
streams.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=470034319-10042000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=470034319-10042000>Does
that help?</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=470034319-10042000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=470034319-10042000>Brian</SPAN></FONT></DIV>
<BLOCKQUOTE
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma
  size=2>-----Original Message-----<BR><B>From:</B> David Cromwell
  [mailto:cromwell@nortelnetworks.com]<BR><B>Sent:</B> Monday, April 10, 2000
  10:32 AM<BR><B>To:</B> MEGACO@standards.nortelnetworks.com<BR><B>Subject:</B>
  Re: Conferencing and MEGACO!!!!<BR><BR></DIV></FONT>
  <P><FONT color=#000000 face=Arial size=2>Comments below.</FONT> </P>
  <P><FONT color=#000000 face=Arial size=2>David</FONT> <BR><FONT color=#000000
  face=Arial size=2>--</FONT> <BR><FONT color=#000000 face=Arial
  size=2>cromwell@nortelnetworks.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  Nortel Networks </FONT><BR><FONT color=#000000 face=Arial
  size=2>ESN:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  351-8870&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  35 Davis Dr</FONT> <BR><FONT color=#000000 face=Arial
  size=2>Public:&nbsp;&nbsp;&nbsp;
  919-991-8870&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  RTP, NC 27709</FONT> </P>
  <UL>
    <P><FONT face=Arial size=1>-----Original Message-----</FONT> <BR><B><FONT
    face=Arial size=1>From:&nbsp;&nbsp;</FONT></B> <FONT face=Arial
    size=1>Rosen, Brian [SMTP:brosen@FORE.COM]</FONT> <BR><B><FONT face=Arial
    size=1>Sent:&nbsp;&nbsp;</FONT></B> <FONT face=Arial size=1>Monday, April
    10, 2000 9:54 AM</FONT> <BR><B><FONT face=Arial
    size=1>To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT face=Arial
    size=1>MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><B><FONT face=Arial
    size=1>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT
    face=Arial size=1>Re: Conferencing and MEGACO!!!!</FONT> </P>
    <P><FONT color=#0000ff face=Arial size=2>If all you want is a simple mixing
    bridge, then you don't need the second</FONT> <BR><FONT color=#0000ff
    face=Arial size=2>alternative I proposed.&nbsp; </FONT></P>
    <P><B><I><FONT color=#000000 face=Arial
    size=2>[&lt;dcc&gt;]</FONT></I></B><I></I>&nbsp;<FONT color=#000000
    face=Arial size=2> Agreed.&nbsp; I see most audio only conferencing
    inplementations using this approach.</FONT> </P>
    <P><FONT color=#0000ff face=Arial size=2>However, as was pointed out, using
    the controls in</FONT> <BR><FONT color=#0000ff face=Arial size=2>the
    protocol, you have some limits on how flexible you can make the</FONT>
    <BR><FONT color=#0000ff face=Arial size=2>bridge.</FONT> </P>
    <P><B><I><FONT color=#000000 face=Arial
    size=2>[&lt;dcc&gt;]</FONT></I></B><I></I>&nbsp;<FONT color=#000000
    face=Arial size=2> I'm still unclear about how the context per leg thing
    works.&nbsp; Could you give an example?</FONT><FONT face=Arial>&nbsp;</FONT>
    </P><BR>
    <P><FONT color=#0000ff face=Arial size=2>If you want to go beyond the
    capabilities that the protocol provides, no</FONT> <BR><FONT color=#0000ff
    face=Arial size=2>problem.&nbsp; We have a very nice extension mechanism,
    the package.</FONT> <BR><FONT face=Arial>&nbsp;</FONT> <BR><FONT
    color=#0000ff face=Arial size=2>I build a media gateway with n ports into a
    mixing bridge that has some</FONT> <BR><FONT color=#0000ff face=Arial
    size=2>arbitrary capability.&nbsp; Each user is connected to one port, and
    there are</FONT> <BR><FONT color=#0000ff face=Arial size=2>a set of controls
    (properties) that define what that user hears/sees/etc.</FONT> </P>
    <P><B><I><FONT color=#000000 face=Arial
    size=2>[&lt;dcc&gt;]</FONT></I></B><I></I>&nbsp;<FONT color=#000000
    face=Arial size=2> So in this case the entire MG would support a single
    context with individual conferences being defined by a really big topology
    descriptor?</FONT></P>
    <P><FONT color=#0000ff face=Arial size=2>We had the example of separate
    audio/video topology suggested for</FONT> <BR><FONT color=#0000ff face=Arial
    size=2>example.&nbsp; You could make a video mixer which showed the last
    four</FONT> <BR><FONT color=#0000ff face=Arial size=2>speakers other than
    "yourself" in a grid.&nbsp; Anything you want.</FONT> <BR><FONT
    color=#0000ff face=Arial size=2>It's a completely general way to build any
    kind of bridge.&nbsp; All I need do</FONT> <BR><FONT color=#0000ff
    face=Arial size=2>is define a package with the controls I need for the
    bridge.&nbsp; Of course,</FONT> <BR><FONT color=#0000ff face=Arial size=2>I
    have to get some MGC(s) to implement the package!</FONT> <BR><FONT
    face=Arial>&nbsp;</FONT> <BR><FONT color=#0000ff face="Courier New"
    size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+------------+</FONT> <BR><FONT
    color=#0000ff face="Courier New"
    size=2>&nbsp;----|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|---</FONT>
    <BR><FONT color=#0000ff face="Courier New" size=2>&nbsp;&nbsp;&nbsp;&nbsp;
    |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
    <BR><FONT color=#0000ff face="Courier New"
    size=2>&nbsp;----|&nbsp;&nbsp;Arbitrary |---</FONT> <BR><FONT color=#0000ff
    face="Courier New"
    size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;Mixing&nbsp;&nbsp;&nbsp;
    |</FONT> <BR><FONT color=#0000ff face="Courier New"
    size=2>&nbsp;----|&nbsp;&nbsp;Bridge&nbsp;&nbsp;&nbsp; |---</FONT> <BR><FONT
    color=#0000ff face="Courier New" size=2>&nbsp;&nbsp;&nbsp;&nbsp;
    |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
    <BR><FONT color=#0000ff face="Courier New"
    size=2>&nbsp;----|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|---</FONT>
    <BR><FONT color=#0000ff face="Courier New"
    size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+------------+</FONT> <BR><FONT
    face=Arial>&nbsp;</FONT> <BR><FONT color=#0000ff face=Arial size=2>If you
    can use the protocol mechanisms, including topology, to get what</FONT>
    <BR><FONT color=#0000ff face=Arial size=2>you want, I would think that would
    be the best way to control the MG,</FONT> <BR><FONT color=#0000ff face=Arial
    size=2>when you can't, you can use the n termination, lots of
    properties</FONT> <BR><FONT color=#0000ff face=Arial size=2>approach.</FONT>
    <BR><FONT face=Arial>&nbsp;</FONT> <BR><FONT color=#0000ff face=Arial
    size=2>Brian</FONT> </P>
    <UL>
      <P><FONT face=Tahoma size=2>-----Original Message-----<BR></FONT><B><FONT
      face=Tahoma size=2>From:</FONT></B><FONT face=Tahoma size=2> David
      Cromwell [<U></U></FONT><U><FONT color=#0000ff face=Tahoma size=2><A
      href="mailto:cromwell@nortelnetworks.com">mailto:cromwell@nortelnetworks.com</A></FONT></U><FONT
      face=Tahoma size=2>]<BR></FONT><B><FONT face=Tahoma
      size=2>Sent:</FONT></B><FONT face=Tahoma size=2> Sunday, April 09, 2000
      1:21 PM<BR></FONT><B><FONT face=Tahoma size=2>To:</FONT></B><FONT
      face=Tahoma size=2> Rosen, Brian;
      megaco@standards.nortelnetworks.com<BR></FONT><B><FONT face=Tahoma
      size=2>Subject:</FONT></B><FONT face=Tahoma size=2> RE: Conferencing and
      MEGACO!!!!<BR><BR></FONT></P>
      <P><FONT color=#000000 face=Arial size=2>Brian,</FONT><FONT
      face=Arial><BR></FONT><FONT color=#000000 face=Arial
      size=2>&nbsp;</FONT><FONT face=Arial><BR></FONT><FONT color=#000000
      face=Arial size=2>If as you suggest you built a conference bridge with a
      set of terminations and made each leg a separate context where would the
      mixing take place? Are you suggesting a mixing context which contains
      ephemeral terminations, each of which is connected to an ephemeral
      termination in one of the leg contexts?&nbsp; If so, you could control the
      conference topology by using the topology descriptor in the mixing
      context, however I am not clear what you would gain by using multiple
      contexts v.s. using a single context.</FONT></P>
      <P><FONT color=#000000 face=Arial size=2>Regards,</FONT><FONT
      face=Arial><BR></FONT><FONT color=#000000 face=Arial
      size=2>David</FONT><FONT face=Arial><BR></FONT><FONT color=#000000
      face=Arial size=2>--</FONT><FONT face=Arial><BR></FONT><FONT color=#000000
      face=Arial
      size=2>cromwell@nortelnetworks.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      Nortel Networks Cable Solutions&nbsp;</FONT><BR><FONT color=#000000
      face=Arial
      size=2>ESN:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      351-8870&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      35 Davis Dr</FONT><FONT face=Arial><BR></FONT><FONT color=#000000
      face=Arial size=2>Public:&nbsp;&nbsp;&nbsp;
      919-991-8870&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      RTP, NC 27709</FONT><FONT face=Arial> </FONT></P>
      <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial
      size=1>-----Original Message-----</FONT><FONT
      face=Arial><BR></FONT><B><FONT face=Arial
      size=1>From:&nbsp;&nbsp;</FONT></B><FONT face=Arial> </FONT><FONT
      face=Arial size=1>Rosen, Brian [SMTP:brosen@FORE.COM]</FONT><FONT
      face=Arial><BR></FONT><B><FONT face=Arial
      size=1>Sent:&nbsp;&nbsp;</FONT></B><FONT face=Arial> </FONT><FONT
      face=Arial size=1>Sunday, April 09, 2000 9:40 AM</FONT><FONT
      face=Arial><BR></FONT><B><FONT face=Arial
      size=1>To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B><FONT face=Arial>
      </FONT><FONT face=Arial
      size=1>MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT><FONT
      face=Arial><BR></FONT><B><FONT face=Arial
      size=1>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B><FONT
      face=Arial> </FONT><FONT face=Arial size=1>Re: Conferencing and
      MEGACO!!!!</FONT><FONT face=Arial> </FONT></P>
      <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial
      size=2>There is one explicit mechanism to support conferencing in
      Megaco,</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>and
      there are all the pieces to support another.</FONT><FONT face=Arial>
      </FONT></P>
      <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial size=2>Look
      at the Topology mechanism.&nbsp; If you had all of the legs of
      a</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>conference in
      a single context, topology can be used to control</FONT><FONT
      face=Arial><BR></FONT><FONT face=Arial size=2>who hears/sees/...
      whom.&nbsp; That is enough to make a pretty straightforward</FONT><FONT
      face=Arial><BR></FONT><FONT face=Arial size=2>audio conference
      bridge.</FONT><FONT face=Arial> </FONT></P>
      <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial size=2>It
      is also very reasonable to build a conference bridge with a
      set</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>of
      terminations, and make each leg a separate context.&nbsp; That
      would</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>probably
      take a package definition, but I suspect that it would be
      pretty</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>simple to
      make one.</FONT><FONT face=Arial> </FONT></P>
      <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial
      size=2>Brian</FONT><FONT face=Arial> </FONT></P>
      <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial
      size=2>-----Original Message-----</FONT><FONT face=Arial><BR></FONT><FONT
      face=Arial size=2>From: Medha Vedaprakash</FONT><FONT
      face=Arial><BR></FONT><FONT face=Arial size=2>To:
      MEGACO@standards.nortelnetworks.com</FONT><FONT
      face=Arial><BR></FONT><FONT face=Arial size=2>Sent: 4/8/00 3:51
      PM</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>Subject:
      Conferencing and MEGACO!!!!</FONT><FONT face=Arial> </FONT></P>
      <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial
      size=2>Hi,</FONT><FONT face=Arial> </FONT></P>
      <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial size=2>I'm
      looking for some information on providing conferencing support
      in</FONT><FONT face=Arial><BR></FONT><FONT face=Arial
      size=2>the</FONT><FONT face=Arial><BR></FONT><FONT face=Arial
      size=2>MG,MGC. The Architecture and requirements document mentions the
      need to</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>support
      MP functionality in the MG and MC functionality in the MGC.</FONT><FONT
      face=Arial> </FONT></P>
      <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial
      size=2>How're these related to the Context properties which is supposed
      to</FONT><FONT face=Arial><BR></FONT><FONT face=Arial size=2>contain
      "Media mixing and Switching properties" . However, there's no</FONT><FONT
      face=Arial><BR></FONT><FONT face=Arial size=2>formal representation of
      these Context properties anywhere in the</FONT><FONT
      face=Arial><BR></FONT><FONT face=Arial size=2>protocol spec.</FONT><FONT
      face=Arial> </FONT></P>
      <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial size=2>Is
      there any other document that can be useful to me?</FONT><FONT face=Arial>
      </FONT></P>
      <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial
      size=2>Thanks,</FONT><FONT face=Arial><BR></FONT><FONT face=Arial
      size=2>Medha</FONT><FONT face=Arial>
</FONT></P></UL></UL></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01BFA325.DDFA99AE--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Apr 10 18:08:21 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05659
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 10 Apr 2000 18:08:20 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E87457D0@standards.nortelnetworks.com>; Mon, 10 Apr 2000 18:02:17 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 123889 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Apr 2000 18:00:32 -0400
Received: from smtprtp1.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.440E45D0@standards.nortelnetworks.com>; Mon, 10 Apr 2000 17:50:32
          -0400
Received: from zcard015.ca.nortel.com (actually zcard015) by
          smtprtp1.ntcom.nortel.net; Mon, 10 Apr 2000 16:30:19 -0400
Received: from zrtpd00z.us.nortel.com ([47.140.224.110]) by
          zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id H6NP2WBL; Mon, 10 Apr 2000 16:30:15
          -0400
Received: from nortelnetworks.com (pnc1m006.us.nortel.com [47.142.208.218]) by
          zrtpd00z.us.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id HSZ91SKF; Mon, 10 Apr 2000 16:30:14
          -0400
X-Sybari-Space: 00000000 00000000 00000000
X-Sender: "Michael Brown" <mahubard@zrtpd00z>
X-Mailer: Mozilla 4.7 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <NDBBKGPMCLCCPKPNAOBEGEHICJAA.makinae.naoto@lab.ntt.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38F23A98.8448E601@nortelnetworks.com>
Date:         Mon, 10 Apr 2000 16:33:28 -0400
Reply-To: Michael Brown <C.Michael.Brown@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Michael Brown <C.Michael.Brown@NORTELNETWORKS.COM>
Organization: Nortel Networks
Subject:      Re: 7.1.18 Topology Clarification
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Initially, I was puzzled by the following, because I went to look at the document
and found it to be as Naoto described that it needed to be... I was looking at the
Word doc version of the spec. Looking at the  actual draft,
http://www.ietf.org/internet-drafts/draft-ietf-megaco-protocol-07.txt , the problems
as indicated are indeed there. They definitely need to be cleaned up as Naoto
suggests.

Christian,

   Regarding your initial question, I don't find the diagrams/table to be
confusing... as long as we fix the stuff that Naoto pointed out in the actual IETF
draft.

Cheers,

Michael

Naoto MAKINAE wrote:

> Hi Christian
>
> > Given that the default for the TopologyDescriptor is "bothway" do people
> > find  the diagram and table confusing?
> > ie.
> > Step 3: T3, T2, oneway
> > Could be
> > a) as shown or
> > b) bothway between T1 and T2, bothway between T1 and T3 and oneway
> > between T3 and T2
>
> The last sentence in the paragraph just above the figure 4 states that
> "it is assumed that the topology descriptors are applied in sequence."
> The third diagram is obtained by applying  (T3, T2, oneway) to the
> second diagram. So, the third diagram should remain as it is.
>
> The figure, howerver, is confusing in the following senses:
>  - The six diagrams show different states of the same context, but the phrases
>    "Context 1", "Context 2", and "Context 3" give the wrong impression that they
>    are different contexts.
>  - Each diagram should be labeled as 1, 2, 3, 4, 5, and 6, but they are labeled
>   1, 2, 3, 1,2, and 3.
>
> Naoto
> --
> Naoto MAKINAE
> Information Sharing Platform Laboratories
> Nippon Telegram and Telephone Corporation
> Email:makinae.naoto@lab.ntt.co.jp


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Apr 10 18:56:35 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06242
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 10 Apr 2000 18:56:34 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A6858310@standards.nortelnetworks.com>; Mon, 10 Apr 2000 18:50:33 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 124078 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Apr 2000 18:49:13 -0400
Received: from smtprtp1.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.76A6B880@standards.nortelnetworks.com>; Mon, 10 Apr 2000 18:49:12
          -0400
Received: from zrtpd00y.us.nortel.com (actually zrtpd00y) by
          smtprtp1.ntcom.nortel.net; Mon, 10 Apr 2000 18:29:31 -0400
Received: by zrtpd00y.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <24DYH2WZ>; Mon, 10 Apr 2000 18:29:30 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFA33C.3C4545A2"
Message-ID:  <5F68FAE98163D21193750000F81AC9BE010FDFF7@zrtpd00x.us.nortel.com>
Date:         Mon, 10 Apr 2000 18:29:25 -0400
Reply-To: David Cromwell <cromwell@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: David Cromwell <cromwell@NORTELNETWORKS.COM>
Subject:      Re: Conferencing and MEGACO!!!!
X-To:         "Rosen, Brian" <brosen@FORE.COM>
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_01BFA33C.3C4545A2
Content-Type: text/plain;
        charset="iso-8859-1"

Brian,

See comment below.

Regards,
David
--
cromwell@nortelnetworks.com                   Nortel Networks Cable
Solutions
ESN:            351-8870                              35 Davis Dr
Public:    919-991-8870                              RTP, NC 27709

> -----Original Message-----
> From: Rosen, Brian [SMTP:brosen@FORE.COM]
> Sent: Monday, April 10, 2000 3:54 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: Conferencing and MEGACO!!!!
>
> Okay, I'll make a contrived example.  Suppose I wished to do what the
> previous message did - allow users of my bridge to have a different set of
> who hears whom from who sees whom.  Another example is a bridge that
> allows user selection of multiple simultaneous translations, or allowing
> users
> to listen to an arbitrary set of conferences but speaking in only one at a
> time.
> Note that it is possible to use topology to do the latter two, by having
> all users
> in the same context and subsetting separate conferences by using topology
> to make disjoint sets, it really is warping the mechanism to do so.
>
> Anyway, let's take the first of those.  So, we build an MG that has a set
> of
> (physical) terminations, one per port.  When a user wants to join, his
> call
> control assigns him to one of the ports, so an ephemeral RTP termination
> is created,
> and we have a set of two terminations contexts (the bridge termination and
> the
> RTP termination).  We implement a package that has a stream dependent
> (i.e.
> defined in LocalControl) parameter called "conferenceID".  The bridge is
> built such that ports that have the same conferenceIDs have THAT STREAM
> mixed with other ports with the same conferenceID.  Since it is stream
> dependent,
> you can be in a different audio conference than video conference.  The MGC
> manages conference participation by manipulating the conferenceID
> parameter
> in LocalControl.  Topology is normally set to BOTHWAYS for all streams.
>
> Does that help?

        [<dcc>]  Yes it does, particularly after we talked on the phone
about it!  Previously I was a little unclear that what you were talking
about was a whole bunch of two context terminations, each containing a
mixing termination and an RTP termination.  The n termination with lots of
properties on the non-RTP termination model makes sense for
hardware/application functionality that stretches the bounds of the normal
MEGACO connection model.  Thanks for talking the time to make this clear.

> Brian
>
>       -----Original Message-----
>       From: David Cromwell [mailto:cromwell@nortelnetworks.com]
>       Sent: Monday, April 10, 2000 10:32 AM
>       To: MEGACO@standards.nortelnetworks.com
>       Subject: Re: Conferencing and MEGACO!!!!
>
>
>
>       Comments below.
>
>       David
>       --
>       cromwell@nortelnetworks.com                   Nortel Networks
>       ESN:            351-8870                              35 Davis Dr
>       Public:    919-991-8870                              RTP, NC 27709
>
>               -----Original Message-----
>       From:   Rosen, Brian [SMTP:brosen@FORE.COM]
>       Sent:   Monday, April 10, 2000 9:54 AM
>       To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
>       Subject:        Re: Conferencing and MEGACO!!!!
>
>               If all you want is a simple mixing bridge, then you don't
> need the second
>       alternative I proposed.
>
>               [<dcc>]  Agreed.  I see most audio only conferencing
> inplementations using this approach.
>
>               However, as was pointed out, using the controls in
>       the protocol, you have some limits on how flexible you can make the
>       bridge.
>
>               [<dcc>]  I'm still unclear about how the context per leg
> thing works.  Could you give an example?
>
>
>               If you want to go beyond the capabilities that the protocol
> provides, no
>       problem.  We have a very nice extension mechanism, the package.
>
>       I build a media gateway with n ports into a mixing bridge that has
> some
>       arbitrary capability.  Each user is connected to one port, and there
> are
>       a set of controls (properties) that define what that user
> hears/sees/etc.
>
>               [<dcc>]  So in this case the entire MG would support a
> single context with individual conferences being defined by a really big
> topology descriptor?
>
>               We had the example of separate audio/video topology
> suggested for
>       example.  You could make a video mixer which showed the last four
>       speakers other than "yourself" in a grid.  Anything you want.
>       It's a completely general way to build any kind of bridge.  All I
> need do
>       is define a package with the controls I need for the bridge.  Of
> course,
>       I have to get some MGC(s) to implement the package!
>
>            +------------+
>        ----|            |---
>            |            |
>        ----|  Arbitrary |---
>            |  Mixing    |
>        ----|  Bridge    |---
>            |            |
>        ----|            |---
>            +------------+
>
>       If you can use the protocol mechanisms, including topology, to get
> what
>       you want, I would think that would be the best way to control the
> MG,
>       when you can't, you can use the n termination, lots of properties
>       approach.
>
>       Brian
>
>                       -----Original Message-----
>               From: David Cromwell [ <mailto:cromwell@nortelnetworks.com>]
>               Sent: Sunday, April 09, 2000 1:21 PM
>               To: Rosen, Brian; megaco@standards.nortelnetworks.com
>               Subject: RE: Conferencing and MEGACO!!!!
>
>
>
>                       Brian,
>
>               If as you suggest you built a conference bridge with a set
> of terminations and made each leg a separate context where would the
> mixing take place? Are you suggesting a mixing context which contains
> ephemeral terminations, each of which is connected to an ephemeral
> termination in one of the leg contexts?  If so, you could control the
> conference topology by using the topology descriptor in the mixing
> context, however I am not clear what you would gain by using multiple
> contexts v.s. using a single context.
>
>                       Regards,
>               David
>               --
>               cromwell@nortelnetworks.com                   Nortel
> Networks Cable Solutions
>               ESN:            351-8870                              35
> Davis Dr
>               Public:    919-991-8870                              RTP, NC
> 27709
>
>                               -----Original Message-----
>               From:   Rosen, Brian [SMTP:brosen@FORE.COM]
>               Sent:   Sunday, April 09, 2000 9:40 AM
>               To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
>               Subject:        Re: Conferencing and MEGACO!!!!
>
>                               There is one explicit mechanism to support
> conferencing in Megaco,
>               and there are all the pieces to support another.
>
>                               Look at the Topology mechanism.  If you had
> all of the legs of a
>               conference in a single context, topology can be used to
> control
>               who hears/sees/... whom.  That is enough to make a pretty
> straightforward
>               audio conference bridge.
>
>                               It is also very reasonable to build a
> conference bridge with a set
>               of terminations, and make each leg a separate context.  That
> would
>               probably take a package definition, but I suspect that it
> would be pretty
>               simple to make one.
>
>                               Brian
>
>                               -----Original Message-----
>               From: Medha Vedaprakash
>               To: MEGACO@standards.nortelnetworks.com
>               Sent: 4/8/00 3:51 PM
>               Subject: Conferencing and MEGACO!!!!
>
>                               Hi,
>
>                               I'm looking for some information on
> providing conferencing support in
>               the
>               MG,MGC. The Architecture and requirements document mentions
> the need to
>               support MP functionality in the MG and MC functionality in
> the MGC.
>
>                               How're these related to the Context
> properties which is supposed to
>               contain "Media mixing and Switching properties" . However,
> there's no
>               formal representation of these Context properties anywhere
> in the
>               protocol spec.
>
>                               Is there any other document that can be
> useful to me?
>
>                               Thanks,
>               Medha
>

------_=_NextPart_001_01BFA33C.3C4545A2
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: Conferencing and MEGACO!!!!</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Brian,</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">See comment =
below.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Regards,</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">David</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">--</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">cromwell@nortelnetworks.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; Nortel Networks Cable Solutions&nbsp; </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">ESN:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; =
351-8870&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 35 Davis Dr</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">Public:&nbsp;&nbsp;&nbsp; =
919-991-8870&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RTP, NC 27709</FONT>
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Rosen, Brian [SMTP:brosen@FORE.COM]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Monday, April 10, 2000 3:54 PM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Re: Conferencing and =
MEGACO!!!!</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Okay, I'll make a =
contrived example.=A0 Suppose I wished to do what the</FONT>=20
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">previous message =
did - allow users of my bridge to have a different set of</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">who hears whom from =
who sees whom.=A0 Another example is a bridge that</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">allows user =
selection of multiple simultaneous translations, or allowing =
users</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">to listen to an =
arbitrary set=A0of=A0conferences but speaking=A0in only one at a =
time.</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Note that it is =
possible to use topology to do the latter two, by having all =
users</FONT>=20
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">in the same context =
and subsetting separate conferences by using topology</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">to make disjoint =
sets, it really is warping the mechanism to do so.</FONT>
<BR><FONT FACE=3D"Arial">=A0</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Anyway, let's take =
the first of those.=A0 So, we build an MG that has a set of</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">(physical) =
terminations, one per port.=A0 When a user wants to join, his =
call</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">control assigns him =
to one of the ports, so an ephemeral RTP termination is created,</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">and we have a set =
of two terminations contexts (the bridge termination and the</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">RTP =
termination).=A0 We implement a package that has a stream dependent =
(i.e.</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">defined in =
LocalControl) parameter called &quot;conferenceID&quot;.=A0 The bridge =
is</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">built such that =
ports that have the same conferenceIDs have THAT STREAM</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">mixed with other =
ports with the same conferenceID.=A0 Since it is stream =
dependent,</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">you can be in a =
different audio conference than video conference.=A0 The MGC</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">manages conference =
participation by manipulating the conferenceID parameter</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">in LocalControl.=A0 =
Topology is normally set to BOTHWAYS for all streams.</FONT>
<BR><FONT FACE=3D"Arial">=A0</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Does that =
help?</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial"></FONT>&nbsp;
<BR><B><I><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">[&lt;dcc&gt;]</FONT></I></B><I></I>&nbsp;<FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial"> Yes it does, particularly =
after we talked on the phone about it!&nbsp; Previously I was a little =
unclear that what you were talking about was a whole bunch of two =
context terminations, each containing a mixing termination and an RTP =
termination.&nbsp; The n termination with lots of properties on the =
non-RTP termination model makes sense for hardware/application =
functionality that stretches the bounds of the normal MEGACO connection =
model.&nbsp; Thanks for talking the time to make this clear.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Brian</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Tahoma">-----Original Message-----<BR>
</FONT><B><FONT SIZE=3D2 FACE=3D"Tahoma">From:</FONT></B><FONT SIZE=3D2 =
FACE=3D"Tahoma"> David Cromwell [<U></U></FONT><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Tahoma"><A =
HREF=3D"mailto:cromwell@nortelnetworks.com">mailto:cromwell@nortelnetwor=
ks.com</A></FONT></U><FONT SIZE=3D2 FACE=3D"Tahoma">]<BR>
</FONT><B><FONT SIZE=3D2 FACE=3D"Tahoma">Sent:</FONT></B><FONT SIZE=3D2 =
FACE=3D"Tahoma"> Monday, April 10, 2000 10:32 AM<BR>
</FONT><B><FONT SIZE=3D2 FACE=3D"Tahoma">To:</FONT></B><FONT SIZE=3D2 =
FACE=3D"Tahoma"> MEGACO@standards.nortelnetworks.com<BR>
</FONT><B><FONT SIZE=3D2 FACE=3D"Tahoma">Subject:</FONT></B><FONT =
SIZE=3D2 FACE=3D"Tahoma"> Re: Conferencing and MEGACO!!!!<BR>
<BR>
</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Comments =
below.</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">David</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">--</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">cromwell@nortelnetworks.com=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0 Nortel Networks</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">ESN:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
351-8870=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 35 Davis Dr</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Public:=A0=A0=A0 =
919-991-8870=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 RTP, NC 27709</FONT><FONT FACE=3D"Arial"> =
</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D1 =
FACE=3D"Arial">-----Original Message-----</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><B><FONT SIZE=3D1 FACE=3D"Arial">From:=A0=A0</FONT></B><FONT =
FACE=3D"Arial"> </FONT><FONT SIZE=3D1 FACE=3D"Arial">Rosen, Brian =
[SMTP:brosen@FORE.COM]</FONT><FONT FACE=3D"Arial"><BR>
</FONT><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:=A0=A0</FONT></B><FONT =
FACE=3D"Arial"> </FONT><FONT SIZE=3D1 FACE=3D"Arial">Monday, April 10, =
2000 9:54 AM</FONT><FONT FACE=3D"Arial"><BR>
</FONT><B><FONT SIZE=3D1 FACE=3D"Arial">To:=A0=A0=A0=A0</FONT></B><FONT =
FACE=3D"Arial"> </FONT><FONT SIZE=3D1 =
FACE=3D"Arial">MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:=A0=A0=A0=A0=A0=A0=A0</FONT></B><FONT =
FACE=3D"Arial"> </FONT><FONT SIZE=3D1 FACE=3D"Arial">Re: Conferencing =
and MEGACO!!!!</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Arial">If all you want is a simple mixing bridge, then =
you don't need the second</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">alternative I =
proposed.=A0</FONT>=20
</P>

<P><B><I>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">[&lt;dcc&gt;]</FONT></I></B><I></I><FONT =
FACE=3D"Arial">=A0</FONT><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial"> Agreed.=A0 I see most audio only conferencing =
inplementations using this approach.</FONT><FONT FACE=3D"Arial"> =
</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Arial">However, as was pointed out, using the controls =
in</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">the protocol, =
you have some limits on how flexible you can make the</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">bridge.</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P><B><I>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">[&lt;dcc&gt;]</FONT></I></B><I></I><FONT =
FACE=3D"Arial">=A0</FONT><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial"> I'm still unclear about how the context per leg thing =
works.=A0 Could you give an example?</FONT><FONT FACE=3D"Arial">=A0 =
</FONT>
</P>
<BR>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Arial">If you want to go beyond the capabilities that =
the protocol provides, no</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">problem.=A0 We =
have a very nice extension mechanism, the package.</FONT><FONT =
FACE=3D"Arial"><BR>
=A0<BR>
</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I build a media =
gateway with n ports into a mixing bridge that has some</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">arbitrary =
capability.=A0 Each user is connected to one port, and there =
are</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">a set of =
controls (properties) that define what that user =
hears/sees/etc.</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P><B><I>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">[&lt;dcc&gt;]</FONT></I></B><I></I><FONT =
FACE=3D"Arial">=A0</FONT><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial"> So in this case the entire MG would support a single =
context with individual conferences being defined by a really big =
topology descriptor?</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Arial">We had the example of separate audio/video =
topology suggested for</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">example.=A0 You =
could make a video mixer which showed the last four</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">speakers other =
than &quot;yourself&quot; in a grid.=A0 Anything you want.</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">It's a =
completely general way to build any kind of bridge.=A0 All I need =
do</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">is define a =
package with the controls I need for the bridge.=A0 Of =
course,</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I have to get =
some MGC(s) to implement the package!</FONT><FONT FACE=3D"Arial"><BR>
=A0<BR>
</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">=A0=A0=A0=A0=A0+------------+</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">=A0----|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0|---</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0 |</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">=A0----|=A0=A0Arbitrary |---</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">=A0=A0=A0=A0=A0|=A0=A0Mixing=A0=A0=A0 |</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">=A0----|=A0=A0Bridge=A0=A0=A0 |---</FONT><FONT FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0 |</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">=A0----|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0|---</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
New">=A0=A0=A0=A0=A0+------------+</FONT><FONT FACE=3D"Arial"><BR>
=A0<BR>
</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">If you can use =
the protocol mechanisms, including topology, to get what</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">you want, I =
would think that would be the best way to control the MG,</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">when you can't, =
you can use the n termination, lots of properties</FONT><FONT =
FACE=3D"Arial"><BR>
</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">approach.</FONT><FONT FACE=3D"Arial"><BR>
=A0<BR>
</FONT><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">Brian</FONT><FONT FACE=3D"Arial"> </FONT>
</P>
<UL>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Tahoma">-----Original Message-----<BR>
</FONT><B><FONT SIZE=3D2 FACE=3D"Tahoma">From:</FONT></B><FONT SIZE=3D2 =
FACE=3D"Tahoma"> David Cromwell [</FONT><U><FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Tahoma"></FONT> <FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Tahoma">&lt;<A =
HREF=3D"mailto:cromwell@nortelnetworks.com">mailto:cromwell@nortelnetwor=
ks.com</A>&gt;</FONT></U><FONT SIZE=3D2 FACE=3D"Tahoma">]<BR>
</FONT><B><FONT SIZE=3D2 FACE=3D"Tahoma">Sent:</FONT></B><FONT SIZE=3D2 =
FACE=3D"Tahoma"> Sunday, April 09, 2000 1:21 PM<BR>
</FONT><B><FONT SIZE=3D2 FACE=3D"Tahoma">To:</FONT></B><FONT SIZE=3D2 =
FACE=3D"Tahoma"> Rosen, Brian; megaco@standards.nortelnetworks.com<BR>
</FONT><B><FONT SIZE=3D2 FACE=3D"Tahoma">Subject:</FONT></B><FONT =
SIZE=3D2 FACE=3D"Tahoma"> RE: Conferencing and MEGACO!!!!<BR>
<BR>
</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT COLOR=3D"#000000" =
SIZE=3D2 FACE=3D"Arial">Brian,</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">=A0</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">If as you suggest you =
built a conference bridge with a set of terminations and made each leg =
a separate context where would the mixing take place? Are you =
suggesting a mixing context which contains ephemeral terminations, each =
of which is connected to an ephemeral termination in one of the leg =
contexts?=A0 If so, you could control the conference topology by using =
the topology descriptor in the mixing context, however I am not clear =
what you would gain by using multiple contexts v.s. using a single =
context.</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT COLOR=3D"#000000" =
SIZE=3D2 FACE=3D"Arial">Regards,</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">David</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">--</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">cromwell@nortelnetworks.com=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0 Nortel Networks Cable Solutions=A0</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">ESN:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
351-8870=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 35 Davis Dr</FONT><BR>
<FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Public:=A0=A0=A0 =
919-991-8870=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 RTP, NC 27709</FONT><FONT FACE=3D"Arial"> =
</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
FACE=3D"Arial">=A0=A0=A0=A0=A0=A0=A0 </FONT><FONT SIZE=3D1 =
FACE=3D"Arial">-----Original Message-----</FONT><BR>
<B></B><B><FONT SIZE=3D1 FACE=3D"Arial">From:=A0=A0</FONT></B><FONT =
FACE=3D"Arial"> </FONT><FONT SIZE=3D1 FACE=3D"Arial">Rosen, Brian =
[SMTP:brosen@FORE.COM]</FONT><BR>
<B></B><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:=A0=A0</FONT></B><FONT =
FACE=3D"Arial"> </FONT><FONT SIZE=3D1 FACE=3D"Arial">Sunday, April 09, =
2000 9:40 AM</FONT><BR>
<B></B><B><FONT SIZE=3D1 FACE=3D"Arial">To:=A0=A0=A0=A0</FONT></B><FONT =
FACE=3D"Arial"> </FONT><FONT SIZE=3D1 =
FACE=3D"Arial">MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT><BR>
<B></B><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:=A0=A0=A0=A0=A0=A0=A0</FONT></B><FONT =
FACE=3D"Arial"> </FONT><FONT SIZE=3D1 FACE=3D"Arial">Re: Conferencing =
and MEGACO!!!!</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
FACE=3D"Arial">=A0=A0=A0=A0=A0=A0=A0 </FONT><FONT SIZE=3D2 =
FACE=3D"Arial">There is one explicit mechanism to support conferencing =
in Megaco,</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Arial">and there are all the pieces to support =
another.</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
FACE=3D"Arial">=A0=A0=A0=A0=A0=A0=A0 </FONT><FONT SIZE=3D2 =
FACE=3D"Arial">Look at the Topology mechanism.=A0 If you had all of the =
legs of a</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Arial">conference in a single context, topology =
can be used to control</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Arial">who hears/sees/... whom.=A0 That is =
enough to make a pretty straightforward</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Arial">audio conference bridge.</FONT><FONT =
FACE=3D"Arial"> </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
FACE=3D"Arial">=A0=A0=A0=A0=A0=A0=A0 </FONT><FONT SIZE=3D2 =
FACE=3D"Arial">It is also very reasonable to build a conference bridge =
with a set</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Arial">of terminations, and make each leg a =
separate context.=A0 That would</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Arial">probably take a package definition, but I =
suspect that it would be pretty</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Arial">simple to make one.</FONT><FONT =
FACE=3D"Arial"> </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
FACE=3D"Arial">=A0=A0=A0=A0=A0=A0=A0 </FONT><FONT SIZE=3D2 =
FACE=3D"Arial">Brian</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
FACE=3D"Arial">=A0=A0=A0=A0=A0=A0=A0 </FONT><FONT SIZE=3D2 =
FACE=3D"Arial">-----Original Message-----</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Arial">From: Medha Vedaprakash</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Arial">To: =
MEGACO@standards.nortelnetworks.com</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Arial">Sent: 4/8/00 3:51 PM</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Arial">Subject: Conferencing and =
MEGACO!!!!</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
FACE=3D"Arial">=A0=A0=A0=A0=A0=A0=A0 </FONT><FONT SIZE=3D2 =
FACE=3D"Arial">Hi,</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
FACE=3D"Arial">=A0=A0=A0=A0=A0=A0=A0 </FONT><FONT SIZE=3D2 =
FACE=3D"Arial">I'm looking for some information on providing =
conferencing support in</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Arial">the</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Arial">MG,MGC. The Architecture and requirements =
document mentions the need to</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Arial">support MP functionality in the MG and MC =
functionality in the MGC.</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
FACE=3D"Arial">=A0=A0=A0=A0=A0=A0=A0 </FONT><FONT SIZE=3D2 =
FACE=3D"Arial">How're these related to the Context properties which is =
supposed to</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Arial">contain &quot;Media mixing and Switching =
properties&quot; . However, there's no</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Arial">formal representation of these Context =
properties anywhere in the</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Arial">protocol spec.</FONT><FONT =
FACE=3D"Arial"> </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
FACE=3D"Arial">=A0=A0=A0=A0=A0=A0=A0 </FONT><FONT SIZE=3D2 =
FACE=3D"Arial">Is there any other document that can be useful to =
me?</FONT><FONT FACE=3D"Arial"> </FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
FACE=3D"Arial">=A0=A0=A0=A0=A0=A0=A0 </FONT><FONT SIZE=3D2 =
FACE=3D"Arial">Thanks,</FONT><BR>
<FONT SIZE=3D2 FACE=3D"Arial">Medha</FONT><FONT FACE=3D"Arial"> </FONT>
</P>
</UL></UL></UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFA33C.3C4545A2--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Apr 10 19:33:36 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06811
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 10 Apr 2000 19:33:36 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D69FDDC0@standards.nortelnetworks.com>; Mon, 10 Apr 2000 19:27:41 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 124162 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Apr 2000 19:25:42 -0400
Received: from ish7.ericsson.com.au (203.61.155.111) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.29312C80@standards.nortelnetworks.com>; Mon, 10 Apr 2000
          19:15:41 -0400
Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id JAA05498; Tue,
          11 Apr 2000 09:20:35 +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 JAA08569; Tue, 11
          Apr 2000 09:20:58 +1000 (EST)
Received: from ericsson.com.au (brdhcp201-104.epa.ericsson.se [146.11.201.104])
          by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet
          Mail Service Version 5.5.2448.0) id H00D0FCN; Tue, 11 Apr 2000
          09:20:30 +1000
X-Mailer: Mozilla 4.6 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <NDBBKGPMCLCCPKPNAOBEGEHICJAA.makinae.naoto@lab.ntt.co.jp>
            <38F23A98.8448E601@nortelnetworks.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38F27DDF.F05B671D@ericsson.com.au>
Date:         Tue, 11 Apr 2000 09:20:31 +0800
Reply-To: Paul Hollis <paul.hollis@ERICSSON.COM.AU>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Paul Hollis <paul.hollis@ERICSSON.COM.AU>
Organization: Ericsson Australia
Subject:      Re: 7.1.18 Topology Clarification
X-To:         Michael Brown <C.Michael.Brown@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi,

OK, so if we apply the topology descriptors in the example in sequence what
is the expected outcome at each step (taking into account the text: "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)")??

I would guess the following:

Step 1: As shown

Step 2: As shown

Step 3: Could be as shown OR could be (botway between T1 and T2), (bothway
between T1 and T3) and (oneway between T3 and T2). Due to the fact that T1 is not
mentioned in the topology.

Step 4: (botway between T1 and T2), (bothway between T1 and T3) and (oneway
between T2 and T3)

Step 5: all terminations connected bothway.

Step 6: as shown


Perhaps this text "The default association when a termination is not mentioned in the
Topology descriptor is bothway.." should be clarified that it is only relevant when
Adding new terminations, not modifying existing terminations. For the case of existing
terminations the topology remains unchanged if the termination is not mentioned.

Regards Paul.

Michael Brown wrote:

> Initially, I was puzzled by the following, because I went to look at the document
> and found it to be as Naoto described that it needed to be... I was looking at the
> Word doc version of the spec. Looking at the  actual draft,
> http://www.ietf.org/internet-drafts/draft-ietf-megaco-protocol-07.txt , the problems
> as indicated are indeed there. They definitely need to be cleaned up as Naoto
> suggests.
>
> Christian,
>
>    Regarding your initial question, I don't find the diagrams/table to be
> confusing... as long as we fix the stuff that Naoto pointed out in the actual IETF
> draft.
>
> Cheers,
>
> Michael
>
> Naoto MAKINAE wrote:
>
> > Hi Christian
> >
> > > Given that the default for the TopologyDescriptor is "bothway" do people
> > > find  the diagram and table confusing?
> > > ie.
> > > Step 3: T3, T2, oneway
> > > Could be
> > > a) as shown or
> > > b) bothway between T1 and T2, bothway between T1 and T3 and oneway
> > > between T3 and T2
> >
> > The last sentence in the paragraph just above the figure 4 states that
> > "it is assumed that the topology descriptors are applied in sequence."
> > The third diagram is obtained by applying  (T3, T2, oneway) to the
> > second diagram. So, the third diagram should remain as it is.
> >
> > The figure, howerver, is confusing in the following senses:
> >  - The six diagrams show different states of the same context, but the phrases
> >    "Context 1", "Context 2", and "Context 3" give the wrong impression that they
> >    are different contexts.
> >  - Each diagram should be labeled as 1, 2, 3, 4, 5, and 6, but they are labeled
> >   1, 2, 3, 1,2, and 3.
> >
> > Naoto
> > --
> > Naoto MAKINAE
> > Information Sharing Platform Laboratories
> > Nippon Telegram and Telephone Corporation
> > Email:makinae.naoto@lab.ntt.co.jp


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr 11 09:17:26 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02748
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 11 Apr 2000 09:17:26 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E069D4F0@standards.nortelnetworks.com>; Tue, 11 Apr 2000 9:11:10 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 125290 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Apr 2000 09:09:41 -0400
Received: from ficon-tech.com (12.10.198.190) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.AA86F890@standards.nortelnetworks.com>; Tue, 11 Apr 2000 9:09:39
          -0400
Received: from ficon-tech.com (sphilip.india.ficon-tech.com [172.25.1.104]) by
          ficon-tech.com (8.9.3/8.8.7) with ESMTP id SAA20005 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 11 Apr 2000 18:45:07
          +0530 (IST) (envelope-from sphilip@ficon-tech.com)
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38F324F5.4CAA45E0@ficon-tech.com>
Date:         Tue, 11 Apr 2000 18:43:28 +0530
Reply-To: Shalini Philip <sphilip@FICON-TECH.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Shalini Philip <sphilip@FICON-TECH.COM>
Organization: Ficon Technology
Subject:      Responses to Commands.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello all,
    In the mail sent by Tom Taylor on "Summary of Issues Raised On the
List", there was an item in the section on "Errors for which corrections
are stated" :

   D.1        Even in the case of handoff     In the last sentence of
              or failover, the originating          the first paragraph,

              MGC needs confirmation that   delete the excepting
              its command was received.       clause, so that the
                                                              sentence
reads:
                                                              "Responses
must be sent
                                                              to the
address and port
                                                              from which
the

corresponding commands
                                                              were
sent."

    I think we are right in saying that the response to handoff/failover
should be sent to the originator of the command. However we also need to
add the information of what to do about the responses to outstanding
commands when an MGC performs a handoff. They should be sent to the new
(to which handoff happened) MGC only. Thus IMO, the above sentence
should be changed to :

"Responses must be sent to the address and port from which the
corresponding commands were sent, except in the case of outstanding
commands after a handoff, where the responses must be sent to the new
MGC".



Regards,

Shalini Philip
Ficon Technology
E-Mail : mailto:sphilip@ficon-tech.com
Web    : http://www.ficon-tech.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr 11 15:12:10 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17711
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 11 Apr 2000 15:12:05 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.723E05F0@standards.nortelnetworks.com>; Tue, 11 Apr 2000 15:06:00 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 125837 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Apr 2000 15:04:05 -0400
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.2DEE13E0@standards.nortelnetworks.com>; Tue, 11 Apr 2000
          15:04:05 -0400
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Tue, 11 Apr 2000 12:28:20 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <2V3DGJ4L>; Tue, 11 Apr 2000 12:28:17 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B654@zcard00g.ca.nortel.com>
Date:         Tue, 11 Apr 2000 12:28:17 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      I'm Back, Sort Of
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Apologies for leaving the list to meander on its own for so long, but my
hard drive crashed a week ago in Australia, it was only yesterday that I
could get it repaired, and I'm still operating without any memory of the
past pending data recovery.  I do have the messages accumulated since the
Adelaide meeting to work with.

Double apologies for the fact that my summary of the Adelaide meeting didn't
make it to the list, although it did make it to the Study Group 16 list.
Could someone who got it by that route please forward it to Megaco?

Tom Taylor


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr 11 15:29:13 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18182
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 11 Apr 2000 15:29:12 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D43D62D0@standards.nortelnetworks.com>; Tue, 11 Apr 2000 15:23:03 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 125876 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Apr 2000 15:21:27 -0400
Received: from dnsmx1pya.telcordia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.9AAA76C0@standards.nortelnetworks.com>; Tue, 11 Apr 2000 15:21:26
          -0400
Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com
          [128.96.246.8]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with SMTP id
          PAA18899 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 11 Apr 2000
          15:25:53 -0400 (EDT)
Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4  (830.2
          3-23-1999))  id 852568BE.006AB8F4 ; Tue, 11 Apr 2000 15:25:41 -0400
X-Lotus-FromDomain: TELCORDIA
Mime-Version: 1.0
Content-type: multipart/mixed;
              Boundary="0__=h1XQGbZkSCRSacATfon16uriCQxqS4YriFkMeH3Litottsl7Zme3TE0d"
Content-Disposition: inline
Message-ID:  <852568BE.006AB722.00@notes949.cc.telcordia.com>
Date:         Tue, 11 Apr 2000 15:24:26 -0400
Reply-To: Seshadri Mohan <smohan@TELCORDIA.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Seshadri Mohan <smohan@TELCORDIA.COM>
Subject:      Megaco Meeting Summary - Posted to Megaco Per Tom's request
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--0__=h1XQGbZkSCRSacATfon16uriCQxqS4YriFkMeH3Litottsl7Zme3TE0d
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline




---------------------- Forwarded by Seshadri Mohan/Telcordia on 04/11/2000 03:24
PM ---------------------------


Tom-PT Taylor <taylor@NORTELNETWORKS.COM> on 03/30/2000 08:37:17 PM

Please respond to Mailing list for parties associated with ITU-T Study Group 16
      <ITU-SG16@mailbag.cps.intel.com>

To:   ITU-SG16@mailbag.cps.intel.com
cc:    (bcc: Seshadri Mohan/Telcordia)
Subject:  Megaco Meeting Summary




Apologies to Alison -- I don't have her E-mail address.

Megaco met for one session on Thursday morning.  The agenda included a
review of status, a discussion of the future of work on development of
Megaco/H.248, review of work items in progress, and review of potential new
work items.  The main points out of the status review were that we must
close on Last Call items within the next week to make the base protocol
documentation available for the April IESG meeting, and that only MIB
development remains out of the original charter work items.

Discussion of how the IETF wishes to relate to future development of the
Megaco/H.248 protocol brought out the following points:
 -- painful as it has been, we wish to remain fully involved in development
of the base protocol at every stage
 -- leaving that aside, it is desirable for interoperability that package
development be coordinated to minimize unnecessary proliferation
 -- there was a strong consensus that in future work, ITU-T determination of
jointly developed documents should truly indicate that these documents are
technically stable, with rigorous change control applied thereafter to
ensure that changes are restricted to clarifications and error corrections.

The consensus was therefore that Megaco should continue to operate, though
perhaps at a lower level of activity.  It will be necessary to draw up a new
charter for the Working Group, and the Chair has been tasked with drawing up
a process document to form the basis of a permanent agreement with the ITU
groups with whom we cooperate.  (This document will be offered to the list
for discussion before being passed to the AD.)  It was noted in later
discussion that within the present organization of the ITU-T we will need to
work with Study Group 11 as well as SG 16.

A first engineer-to-engineer interoperability event is being planned,
tentatively set for August, somewhere in North America.  Nortel will set up
an implementor's E-mail list and web site.  We welcome any TIPHON initiative
to develop an H.248 PICS.

Notes on existing work items:
 -- the suggestion from discussion was that each package (including those
currently in H.248 Annex E) will be published as a separate RFC.  Megaco- or
ITU-initiated packages will typically be standards-track, but this decision
can be made on a per-package basis.
 -- discussion of the IPPhone profile brought out the following points:
Megaco will not initiate the development of profiles, but will typically
become involved as technical consultants in the final stages of turning
mature documents into Informational RFCs.  The IPPhone draft itself will
probably be recycled once more in response to list comments, then sent to WG
Last Call, around mid-April.
 -- the NAS package work continues to be a matter both of controversy and of
an apparently low level of general interest.  It will be fleshed out to meet
the published Megaco requirements.  We are looking to WG Last Call in mid-
to late April.
 -- MIB work has begun to take off.  A recycled draft with a substantial
amount of content should be available within the next couple of weeks.  We
are looking toward WG Last Call toward the end of the month.  It was noted
that each package will probably engender a corresponding MIB.

A number of potential new work areas were reviewed.  These will be discussed
on the list, with a view to identifying specific WG work items over the next
month.
  -- ISDN-related work should be coordinated with Study Group 11
  -- additional packages proposed in draft-brown-supplpkgs-00.txt will be
generic in intent, although in detail some aspects may be specific to North
America.  The work should be coordinated with Study Group 16 in particular,
and possibly also Study Group 11.

Work on adding ATM capability to SDP is in progress.  The work is being
taken to MMUSIC (who are prepared to supervise it -- there was a question of
whether they would refer it back to Megaco.)

A final presentation on the potential application of H.248 to the control of
UMTS terminals included a request for help in development of the implied
call flows.  An I-D will be submitted and can be discussed on the list.

As a personal note, I cannot guarantee E-mail connectivity over the next
week -- my modem does not seem to agree with most Australian telephone
circuits.  I will be back in full operation April 8.

Tom Taylor
Advisor -- Emerging Carrier IP Standards
E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
Phone and FAX: +1 613 736 0961



--0__=h1XQGbZkSCRSacATfon16uriCQxqS4YriFkMeH3Litottsl7Zme3TE0d
Content-type: text/html;
        name="att1.htm"
Content-Disposition: attachment; filename="att1.htm"
Content-Description: Internet HTML
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+
DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o
dG1sOyBjaGFyc2V0PXVzLWFzY2lpIj4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0i
TVMgRXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNS41LjI2NTEuNjUiPg0KPFRJVExFPk1lZ2FjbyBN
ZWV0aW5nIFN1bW1hcnk8L1RJVExFPg0KPC9IRUFEPg0KPEJPRFk+DQoNCjxQPjxGT05UIFNJWkU9
MiBGQUNFPSJBcmlhbCI+QXBvbG9naWVzIHRvIEFsaXNvbiAtLSBJIGRvbid0IGhhdmUgaGVyIEUt
bWFpbCBhZGRyZXNzLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFs
Ij5NZWdhY28gbWV0IGZvciBvbmUgc2Vzc2lvbiBvbiBUaHVyc2RheSBtb3JuaW5nLiZuYnNwOyBU
aGUgYWdlbmRhIGluY2x1ZGVkIGEgcmV2aWV3IG9mIHN0YXR1cywgYSBkaXNjdXNzaW9uIG9mIHRo
ZSBmdXR1cmUgb2Ygd29yayBvbiBkZXZlbG9wbWVudCBvZiBNZWdhY28vSC4yNDgsIHJldmlldyBv
ZiB3b3JrIGl0ZW1zIGluIHByb2dyZXNzLCBhbmQgcmV2aWV3IG9mIHBvdGVudGlhbCBuZXcgd29y
ayBpdGVtcy4mbmJzcDsgVGhlIG1haW4gcG9pbnRzIG91dCBvZiB0aGUgc3RhdHVzIHJldmlldyB3
ZXJlIHRoYXQgd2UgbXVzdCBjbG9zZSBvbiBMYXN0IENhbGwgaXRlbXMgd2l0aGluIHRoZSBuZXh0
IHdlZWsgdG8gbWFrZSB0aGUgYmFzZSBwcm90b2NvbCBkb2N1bWVudGF0aW9uIGF2YWlsYWJsZSBm
b3IgdGhlIEFwcmlsIElFU0cgbWVldGluZywgYW5kIHRoYXQgb25seSBNSUIgZGV2ZWxvcG1lbnQg
cmVtYWlucyBvdXQgb2YgdGhlIG9yaWdpbmFsIGNoYXJ0ZXIgd29yayBpdGVtcy48L0ZPTlQ+PC9Q
Pg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkRpc2N1c3Npb24gb2YgaG93IHRoZSBJ
RVRGIHdpc2hlcyB0byByZWxhdGUgdG8gZnV0dXJlIGRldmVsb3BtZW50IG9mIHRoZSBNZWdhY28v
SC4yNDggcHJvdG9jb2wgYnJvdWdodCBvdXQgdGhlIGZvbGxvd2luZyBwb2ludHM6PC9GT05UPjwv
UD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mbmJzcDstLSBwYWluZnVsIGFzIGl0
IGhhcyBiZWVuLCB3ZSB3aXNoIHRvIHJlbWFpbiBmdWxseSBpbnZvbHZlZCBpbiBkZXZlbG9wbWVu
dCBvZiB0aGUgYmFzZSBwcm90b2NvbCBhdCBldmVyeSBzdGFnZTwvRk9OVD4NCjxCUj48Rk9OVCBT
SVpFPTIgRkFDRT0iQXJpYWwiPiZuYnNwOy0tIGxlYXZpbmcgdGhhdCBhc2lkZSwgaXQgaXMgZGVz
aXJhYmxlIGZvciBpbnRlcm9wZXJhYmlsaXR5IHRoYXQgcGFja2FnZSBkZXZlbG9wbWVudCBiZSBj
b29yZGluYXRlZCB0byBtaW5pbWl6ZSB1bm5lY2Vzc2FyeSBwcm9saWZlcmF0aW9uPC9GT05UPjwv
UD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mbmJzcDstLSB0aGVyZSB3YXMgYSBz
dHJvbmcgY29uc2Vuc3VzIHRoYXQgaW4gZnV0dXJlIHdvcmssIElUVS1UIGRldGVybWluYXRpb24g
b2Ygam9pbnRseSBkZXZlbG9wZWQgZG9jdW1lbnRzIHNob3VsZCB0cnVseSBpbmRpY2F0ZSB0aGF0
IHRoZXNlIGRvY3VtZW50cyBhcmUgdGVjaG5pY2FsbHkgc3RhYmxlLCB3aXRoIHJpZ29yb3VzIGNo
YW5nZSBjb250cm9sIGFwcGxpZWQgdGhlcmVhZnRlciB0byBlbnN1cmUgdGhhdCBjaGFuZ2VzIGFy
ZSByZXN0cmljdGVkIHRvIGNsYXJpZmljYXRpb25zIGFuZCBlcnJvciBjb3JyZWN0aW9ucy48L0ZP
TlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPlRoZSBjb25zZW5zdXMgd2Fz
IHRoZXJlZm9yZSB0aGF0IE1lZ2FjbyBzaG91bGQgY29udGludWUgdG8gb3BlcmF0ZSwgdGhvdWdo
IHBlcmhhcHMgYXQgYSBsb3dlciBsZXZlbCBvZiBhY3Rpdml0eS4mbmJzcDsgSXQgd2lsbCBiZSBu
ZWNlc3NhcnkgdG8gZHJhdyB1cCBhIG5ldyBjaGFydGVyIGZvciB0aGUgV29ya2luZyBHcm91cCwg
YW5kIHRoZSBDaGFpciBoYXMgYmVlbiB0YXNrZWQgd2l0aCBkcmF3aW5nIHVwIGEgcHJvY2VzcyBk
b2N1bWVudCB0byBmb3JtIHRoZSBiYXNpcyBvZiBhIHBlcm1hbmVudCBhZ3JlZW1lbnQgd2l0aCB0
aGUgSVRVIGdyb3VwcyB3aXRoIHdob20gd2UgY29vcGVyYXRlLiZuYnNwOyAoVGhpcyBkb2N1bWVu
dCB3aWxsIGJlIG9mZmVyZWQgdG8gdGhlIGxpc3QgZm9yIGRpc2N1c3Npb24gYmVmb3JlIGJlaW5n
IHBhc3NlZCB0byB0aGUgQUQuKSZuYnNwOyBJdCB3YXMgbm90ZWQgaW4gbGF0ZXIgZGlzY3Vzc2lv
biB0aGF0IHdpdGhpbiB0aGUgcHJlc2VudCBvcmdhbml6YXRpb24gb2YgdGhlIElUVS1UIHdlIHdp
bGwgbmVlZCB0byB3b3JrIHdpdGggU3R1ZHkgR3JvdXAgMTEgYXMgd2VsbCBhcyBTRyAxNi48L0ZP
TlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkEgZmlyc3QgZW5naW5lZXIt
dG8tZW5naW5lZXIgaW50ZXJvcGVyYWJpbGl0eSBldmVudCBpcyBiZWluZyBwbGFubmVkLCB0ZW50
YXRpdmVseSBzZXQgZm9yIEF1Z3VzdCwgc29tZXdoZXJlIGluIE5vcnRoIEFtZXJpY2EuJm5ic3A7
IE5vcnRlbCB3aWxsIHNldCB1cCBhbiBpbXBsZW1lbnRvcidzIEUtbWFpbCBsaXN0IGFuZCB3ZWIg
c2l0ZS4mbmJzcDsgV2Ugd2VsY29tZSBhbnkgVElQSE9OIGluaXRpYXRpdmUgdG8gZGV2ZWxvcCBh
biBILjI0OCBQSUNTLjwvRk9OVD48L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+
Tm90ZXMgb24gZXhpc3Rpbmcgd29yayBpdGVtczo8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZB
Q0U9IkFyaWFsIj4mbmJzcDstLSB0aGUgc3VnZ2VzdGlvbiBmcm9tIGRpc2N1c3Npb24gd2FzIHRo
YXQgZWFjaCBwYWNrYWdlIChpbmNsdWRpbmcgdGhvc2UgY3VycmVudGx5IGluIEguMjQ4IEFubmV4
IEUpIHdpbGwgYmUgcHVibGlzaGVkIGFzIGEgc2VwYXJhdGUgUkZDLiZuYnNwOyBNZWdhY28tIG9y
IElUVS1pbml0aWF0ZWQgcGFja2FnZXMgd2lsbCB0eXBpY2FsbHkgYmUgc3RhbmRhcmRzLXRyYWNr
LCBidXQgdGhpcyBkZWNpc2lvbiBjYW4gYmUgbWFkZSBvbiBhIHBlci1wYWNrYWdlIGJhc2lzLjwv
Rk9OVD48L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jm5ic3A7LS0gZGlzY3Vz
c2lvbiBvZiB0aGUgSVBQaG9uZSBwcm9maWxlIGJyb3VnaHQgb3V0IHRoZSBmb2xsb3dpbmcgcG9p
bnRzOiBNZWdhY28gd2lsbCBub3QgaW5pdGlhdGUgdGhlIGRldmVsb3BtZW50IG9mIHByb2ZpbGVz
LCBidXQgd2lsbCB0eXBpY2FsbHkgYmVjb21lIGludm9sdmVkIGFzIHRlY2huaWNhbCBjb25zdWx0
YW50cyBpbiB0aGUgZmluYWwgc3RhZ2VzIG9mIHR1cm5pbmcgbWF0dXJlIGRvY3VtZW50cyBpbnRv
IEluZm9ybWF0aW9uYWwgUkZDcy4mbmJzcDsgVGhlIElQUGhvbmUgZHJhZnQgaXRzZWxmIHdpbGwg
cHJvYmFibHkgYmUgcmVjeWNsZWQgb25jZSBtb3JlIGluIHJlc3BvbnNlIHRvIGxpc3QgY29tbWVu
dHMsIHRoZW4gc2VudCB0byBXRyBMYXN0IENhbGwsIGFyb3VuZCBtaWQtQXByaWwuPC9GT05UPjwv
UD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mbmJzcDstLSB0aGUgTkFTIHBhY2th
Z2Ugd29yayBjb250aW51ZXMgdG8gYmUgYSBtYXR0ZXIgYm90aCBvZiBjb250cm92ZXJzeSBhbmQg
b2YgYW4gYXBwYXJlbnRseSBsb3cgbGV2ZWwgb2YgZ2VuZXJhbCBpbnRlcmVzdC4mbmJzcDsgSXQg
d2lsbCBiZSBmbGVzaGVkIG91dCB0byBtZWV0IHRoZSBwdWJsaXNoZWQgTWVnYWNvIHJlcXVpcmVt
ZW50cy4mbmJzcDsgV2UgYXJlIGxvb2tpbmcgdG8gV0cgTGFzdCBDYWxsIGluIG1pZC0gdG8gbGF0
ZSBBcHJpbC48L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZuYnNw
Oy0tIE1JQiB3b3JrIGhhcyBiZWd1biB0byB0YWtlIG9mZi4mbmJzcDsgQSByZWN5Y2xlZCBkcmFm
dCB3aXRoIGEgc3Vic3RhbnRpYWwgYW1vdW50IG9mIGNvbnRlbnQgc2hvdWxkIGJlIGF2YWlsYWJs
ZSB3aXRoaW4gdGhlIG5leHQgY291cGxlIG9mIHdlZWtzLiZuYnNwOyBXZSBhcmUgbG9va2luZyB0
b3dhcmQgV0cgTGFzdCBDYWxsIHRvd2FyZCB0aGUgZW5kIG9mIHRoZSBtb250aC4mbmJzcDsgSXQg
d2FzIG5vdGVkIHRoYXQgZWFjaCBwYWNrYWdlIHdpbGwgcHJvYmFibHkgZW5nZW5kZXIgYSBjb3Jy
ZXNwb25kaW5nIE1JQi48L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwi
PkEgbnVtYmVyIG9mIHBvdGVudGlhbCBuZXcgd29yayBhcmVhcyB3ZXJlIHJldmlld2VkLiZuYnNw
OyBUaGVzZSB3aWxsIGJlIGRpc2N1c3NlZCBvbiB0aGUgbGlzdCwgd2l0aCBhIHZpZXcgdG8gaWRl
bnRpZnlpbmcgc3BlY2lmaWMgV0cgd29yayBpdGVtcyBvdmVyIHRoZSBuZXh0IG1vbnRoLjwvRk9O
VD48L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jm5ic3A7IC0tIElTRE4tcmVs
YXRlZCB3b3JrIHNob3VsZCBiZSBjb29yZGluYXRlZCB3aXRoIFN0dWR5IEdyb3VwIDExPC9GT05U
Pg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jm5ic3A7IC0tIGFkZGl0aW9uYWwgcGFj
a2FnZXMgcHJvcG9zZWQgaW4gZHJhZnQtYnJvd24tc3VwcGxwa2dzLTAwLnR4dCB3aWxsIGJlIGdl
bmVyaWMgaW4gaW50ZW50LCBhbHRob3VnaCBpbiBkZXRhaWwgc29tZSBhc3BlY3RzIG1heSBiZSBz
cGVjaWZpYyB0byBOb3J0aCBBbWVyaWNhLiZuYnNwOyBUaGUgd29yayBzaG91bGQgYmUgY29vcmRp
bmF0ZWQgd2l0aCBTdHVkeSBHcm91cCAxNiBpbiBwYXJ0aWN1bGFyLCBhbmQgcG9zc2libHkgYWxz
byBTdHVkeSBHcm91cCAxMS48L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJp
YWwiPldvcmsgb24gYWRkaW5nIEFUTSBjYXBhYmlsaXR5IHRvIFNEUCBpcyBpbiBwcm9ncmVzcy4m
bmJzcDsgVGhlIHdvcmsgaXMgYmVpbmcgdGFrZW4gdG8gTU1VU0lDICh3aG8gYXJlIHByZXBhcmVk
IHRvIHN1cGVydmlzZSBpdCAtLSB0aGVyZSB3YXMgYSBxdWVzdGlvbiBvZiB3aGV0aGVyIHRoZXkg
d291bGQgcmVmZXIgaXQgYmFjayB0byBNZWdhY28uKTwvRk9OVD48L1A+DQoNCjxQPjxGT05UIFNJ
WkU9MiBGQUNFPSJBcmlhbCI+QSBmaW5hbCBwcmVzZW50YXRpb24gb24gdGhlIHBvdGVudGlhbCBh
cHBsaWNhdGlvbiBvZiBILjI0OCB0byB0aGUgY29udHJvbCBvZiBVTVRTIHRlcm1pbmFscyBpbmNs
dWRlZCBhIHJlcXVlc3QgZm9yIGhlbHAgaW4gZGV2ZWxvcG1lbnQgb2YgdGhlIGltcGxpZWQgY2Fs
bCBmbG93cy4mbmJzcDsgQW4gSS1EIHdpbGwgYmUgc3VibWl0dGVkIGFuZCBjYW4gYmUgZGlzY3Vz
c2VkIG9uIHRoZSBsaXN0LjwvRk9OVD48L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlh
bCI+QXMgYSBwZXJzb25hbCBub3RlLCBJIGNhbm5vdCBndWFyYW50ZWUgRS1tYWlsIGNvbm5lY3Rp
dml0eSBvdmVyIHRoZSBuZXh0IHdlZWsgLS0gbXkgbW9kZW0gZG9lcyBub3Qgc2VlbSB0byBhZ3Jl
ZSB3aXRoIG1vc3QgQXVzdHJhbGlhbiB0ZWxlcGhvbmUgY2lyY3VpdHMuJm5ic3A7IEkgd2lsbCBi
ZSBiYWNrIGluIGZ1bGwgb3BlcmF0aW9uIEFwcmlsIDguJm5ic3A7IDwvRk9OVD48L1A+DQoNCjxQ
PjxGT05UIFNJWkU9MiBGQUNFPSJUYWhvbWEiPlRvbSBUYXlsb3I8L0ZPTlQ+DQo8QlI+PEZPTlQg
U0laRT0yIEZBQ0U9IlRhaG9tYSI+QWR2aXNvciAtLSBFbWVyZ2luZyBDYXJyaWVyIElQIFN0YW5k
YXJkczwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iVGFob21hIj5FLW1haWw6IHRheWxv
ckBub3J0ZWxuZXR3b3Jrcy5jb20gKGludGVybmFsbHksIFRvbS1QVCBUYXlsb3IpPC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9MiBGQUNFPSJUYWhvbWEiPlBob25lIGFuZCBGQVg6ICsxIDYxMyA3MzYg
MDk2MTwvRk9OVD4NCjwvUD4NCg0KPC9CT0RZPg0KPC9IVE1MPg0K

--0__=h1XQGbZkSCRSacATfon16uriCQxqS4YriFkMeH3Litottsl7Zme3TE0d--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr 11 16:53:18 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20108
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 11 Apr 2000 16:53:18 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.93EB0DC0@standards.nortelnetworks.com>; Tue, 11 Apr 2000 16:47:09 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 125933 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Apr 2000 16:46:06 -0400
Received: from smtprtp.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.6E2E68C0@standards.nortelnetworks.com>; Tue, 11 Apr 2000 16:46:06
          -0400
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          smtprtp.ntcom.nortel.net; Tue, 11 Apr 2000 16:48:19 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <2K7T6NN0>; Tue, 11 Apr 2000 16:48:20 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B65F@zcard00g.ca.nortel.com>
Date:         Tue, 11 Apr 2000 16:48:16 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Modify Request Syntax
X-To:         Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

It's not a syntax error, so it must be a no-op.  Same with your second
example.

> -----Original Message-----
> From: Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]
> Sent: Saturday, April 01, 2000 3:29 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Modify Request Syntax
>
>
> Hi
>
> In ABNF,
> ammRequest = (AddToken / MoveToken / ModifyToken) EQUAL TerminationID
>                            [LBRKT ammParameter *(COMMA ammParameter)
> RBRKT]
>
> If an MGC send a Modify w/o any ammParameter should MG reply with error
> code 442,
> "Syntax Error in Command" even thought ABNF allows it.
>
> Transaction = 1 {Context=1{Modify=t1}}
>
> Or should the MG treats this modify as a no-op operation and reply with
> the following?
> Reply = 1 {context = 1{Modify=t1}}
>
> If MG should reply w/error descriptor, can I do the following to do a
> no-op Modify
> Transaction = 1 { Context =1 {Modify=t1{Audit{} }}}
>
> and expect MG to reply with the following:
> Reply = 1 {Context = 1{Modify=t1}}
>
>
> Thanks
> Chuong
> --
>   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 Apr 12 07:24:04 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15423
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 12 Apr 2000 07:24:04 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.37DF0E80@standards.nortelnetworks.com>; Wed, 12 Apr 2000 7:17:53 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 126460 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Apr 2000 07:16:22 -0400
Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.9B611090@standards.nortelnetworks.com>; Wed, 12 Apr 2000 7:06:21
          -0400
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id HAA15217; Wed, 12 Apr 2000 07:11:56
          -0400 (EDT)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Message-ID:  <200004121111.HAA15217@ietf.org>
Date:         Wed, 12 Apr 2000 07:11:56 -0400
Reply-To: Internet-Drafts@ietf.org
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and
              ignored.
From: Internet-Drafts@ietf.org
Subject:      I-D ACTION:draft-ietf-megaco-r2package-01.txt
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Media Gateway Control Working Group of the IETF.

        Title           : Megaco/H.248 R2 Package
        Author(s)       : V. Bajaj, S. Ranjhan, P. Jain, M. Babu, K. Laha
        Filename        : draft-ietf-megaco-r2package-01.txt
        Pages           : 15
        Date            : 11-Apr-00

This document  defines a R2 package in association with the MEGACO
Protocol that can be used to control a Media Gateway (MG) from an
external controller, called a Media Gateway controller (MGC).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-megaco-r2package-01.txt

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

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


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

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE /internet-drafts/draft-ietf-megaco-r2package-01.txt".

NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.


Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
        access-type="mail-server";
        server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:     <20000411131657.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-megaco-r2package-01.txt

--OtherAccess
Content-Type: Message/External-body;
        name="draft-ietf-megaco-r2package-01.txt";
        site="ftp.ietf.org";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <20000411131657.I-D@ietf.org>

--OtherAccess--

--NextPart--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Apr 12 10:17:22 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21509
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 12 Apr 2000 10:17:22 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.024D4B70@standards.nortelnetworks.com>; Wed, 12 Apr 2000 10:08:11 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 126665 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Apr 2000 10:07:38 -0400
Received: from smtprtp1.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.EE914320@standards.nortelnetworks.com>; Wed, 12 Apr 2000 10:07:38
          -0400
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          smtprtp1.ntcom.nortel.net; Wed, 12 Apr 2000 10:11:14 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <2K7T6Y4B>; Wed, 12 Apr 2000 10:11:15 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFA488.F5CC8B96"
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B66D@zcard00g.ca.nortel.com>
Date:         Wed, 12 Apr 2000 10:11:12 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: R1 & R2 Package drafts
X-To:         "vbajaj@hss.hns.com" <vbajaj@hss.hns.com>
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_01BFA488.F5CC8B96
Content-Type: text/plain

After the R1 package has come out and people have had time to look at it,
could I have opinions on whether it becomes a WG work item?  I already
accepted R2 last spring.

> -----Original Message-----
> From: vbajaj@hss.hns.com [SMTP:vbajaj@hss.hns.com]
> Sent: Monday, April 10, 2000 9:43 AM
> To:   megaco@standards.nortelnetworks.com
> Cc:   Taylor, Tom-PT [CAR:B901:EXCH]
> Subject:      R1 & R2 Package drafts
>
>
>
> Hi,
>          Please find attached in Zip form the updated version of the
> R2-package
> draft and  a new draft for R1 package.
>      These are as per the new format specified in the protocol for
> packages.
> These are based on the ITU-T specifications
>      (i.e. Q.310-331 for R1 signaling and Q.400-Q.490 for R2 signaling).
> Any
> country variants are expected to be covered by
>       Extension packages to these basic packages. Please send comments, if
> any.
>
> Regards,
>
> Vikas Bajaj
> Kushnava Laha
>
> (See attached file: R1R2_Package_drafts.zip) << File: .ZIP File >>

------_=_NextPart_001_01BFA488.F5CC8B96
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: R1 &amp; R2 Package drafts</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">After the R1 package =
has come out and people have had time to look at it, could I have =
opinions on whether it becomes a WG work item?&nbsp; I already accepted =
R2 last spring.</FONT></P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">vbajaj@hss.hns.com =
[SMTP:vbajaj@hss.hns.com]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Monday, April 10, 2000 9:43 AM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">megaco@standards.nortelnetworks.com</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">Taylor, Tom-PT [CAR:B901:EXCH]</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">R1 &amp; R2 Package drafts</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi,</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Please =
find attached in Zip form the updated version of the R2-package</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">draft and&nbsp; a new draft for R1 =
package.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; These are as =
per the new format specified in the protocol for packages.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">These are based on the ITU-T =
specifications</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; (i.e. =
Q.310-331 for R1 signaling and Q.400-Q.490 for R2 signaling). =
Any</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">country variants are expected to be =
covered by</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Extension packages to these basic packages. Please send comments, if =
any.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Regards,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Vikas Bajaj</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Kushnava Laha</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">(See attached file: =
R1R2_Package_drafts.zip) &lt;&lt; File: .ZIP File &gt;&gt; </FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFA488.F5CC8B96--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Apr 12 10:34:29 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22413
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 12 Apr 2000 10:34:28 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D1D2AEB0@standards.nortelnetworks.com>; Wed, 12 Apr 2000 10:28:18 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 126740 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Apr 2000 10:27:09 -0400
Received: from fw7.usa.alcatel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.42B6E620@standards.nortelnetworks.com>; Wed, 12 Apr 2000 10:17:09
          -0400
Received: (from uucp@localhost) by fw7.usa.alcatel.com (8.8.8+Sun/8.8.8) id
          JAA07315 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 12 Apr 2000
          09:21:54 -0500 (CDT)
Received: from <pchakrav@ssd.usa.alcatel.com> (relay2.usa.alcatel.com
          [143.209.238.7]) by fw7 via smap (V2.1) id xma007203; Wed, 12 Apr 00
          09:21:11 -0500
Received: from multi1.usa.alcatel.com (localhost [127.0.0.1]) by
          relay2.usa.alcatel.com (8.9.3/8.9.3) with ESMTP id JAA17818 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 12 Apr 2000 09:19:54
          -0500 (CDT)
Received: from axes-mach01.axes-mach01.usa.alcatel.com
          (axes-mach01.usa.alcatel.com [130.202.9.90]) by
          multi1.usa.alcatel.com (8.8.8+Sun/8.8.8) with SMTP id JAA24761 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 12 Apr 2000 09:16:42
          -0500 (CDT)
Received: from chak by axes-mach01.axes-mach01.usa.alcatel.com
          (SMI-8.6/SMI-SVR4) id TAA00921; Wed, 12 Apr 2000 19:48:35 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Message-ID:  <007e01bfa486$c1fb2d60$1d09ca82@chak>
Date:         Wed, 12 Apr 2000 19:22:41 +0530
Reply-To: Chakravarthi PSK <pchakrav@SSD.USA.ALCATEL.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chakravarthi PSK <pchakrav@SSD.USA.ALCATEL.COM>
Subject:      Digit Map clarification required
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

  Hi,

    I have one doubt regarding digits received while processing digitmap.
    If digits 0 and 1 are invalid at digit position 7, but digit 0 or 1 is
received at digit position 7, will MG forwards the invalid digit (0 or 1) in
the digit string to MGC?  If not, how MGC will know which invalid digit is
dialed.  This is required if MGC needs to takedifferent actions based on
invalid digit value.

Regards
Chak


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Apr 12 14:47:53 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01000
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 12 Apr 2000 14:47:53 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.39234520@standards.nortelnetworks.com>; Wed, 12 Apr 2000 14:41:44 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 127091 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Apr 2000 14:39:58 -0400
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.F9CA1390@standards.nortelnetworks.com>; Wed, 12 Apr 2000
          14:39:58 -0400
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Wed, 12 Apr 2000 11:42:56 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <2V3DHCFX>; Wed, 12 Apr 2000 11:31:53 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B66E@zcard00g.ca.nortel.com>
Date:         Wed, 12 Apr 2000 11:31:55 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      H.248 Package Coordination
X-To:         SG16 <itu-sg16@mailbag.intel.com>, Greg Ratta <gratta@lucent.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

We have a number of proposed new packages in Megaco, and I'm looking for
thoughts on the process for agreeing amongst the various interested parties
about which should become Megaco work items and which should be worked
elsewhere.  I should say that this should be a two-way street -- work
introduced elsewhere may be something Megaco wants to get into.

Currently, I suggest that interested parties take a look at the following
drafts, all available at
http://www.ietf.org/internet-drafts/<draft-name>

draft-bouwen-megaco-isdn-00.txt
Issues for Megaco - Sigtran Interworking in ISDN Access Gateways

draft-brown-supplpkgs-00.txt
Supplemental Packages for Megaco/H.248

Very shortly these will be joined by packages having to do with R1 and R2
signalling.  I can pass the file names along if there is interest.

Tom Taylor


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Apr 12 16:41:35 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02945
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 12 Apr 2000 16:41:35 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1ED24260@standards.nortelnetworks.com>; Wed, 12 Apr 2000 16:35:32 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0063 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Apr 2000 16:34:20 -0400
Received: from cat01s2.catenanet.com (209.135.116.34) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.8E12B4E0@standards.nortelnetworks.com>; Wed, 12 Apr 2000
          16:24:20 -0400
Received: by CAT01S2 with Internet Mail Service (5.5.2448.0) id <2NJZ8RWK>;
          Wed, 12 Apr 2000 16:30:00 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <310508EDF557D31188FA0050DA0A3752264583@CAT01S2>
Date:         Wed, 12 Apr 2000 16:29:59 -0400
Reply-To: John Donak <JDonak@CATENANET.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: John Donak <JDonak@CATENANET.COM>
Subject:      MEGACO and Dial Pulse Lines
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

All Call Flows I have seen use DTMF for digit dialing. The MG collects the
digits from the originator, based on the DigitMap, and then contacts the
MGC.

How about for Dial Pulse (Rotary) phones behind a Residential Gateway? They
still exist.

Is each individual onhook/offhook reported to the MGC, which performs the
timing/collection? This seems very message intensive.

Or is the Gateway expected to perform the timing/collection? If so, how does
it know the required timing characteristics for the market it is in; I have
not seen a "Dial Pulse" Package.


        Regards,

                        John

John Donak
Catena Networks
Voice:  (613) 599-6430 x488     Email: jdonak@catenanet.com
Fax:    (613) 599-6433          URL:  www.catenanet.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Apr 12 16:59:36 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03266
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 12 Apr 2000 16:59:35 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A5881EE0@standards.nortelnetworks.com>; Wed, 12 Apr 2000 16:53:37 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0096 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Apr 2000 16:52:48 -0400
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.22CF4420@standards.nortelnetworks.com>; Wed, 12 Apr 2000 16:42:48
          -0400
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id QAA25557; Wed, 12 Apr
          2000 16:48:21 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id QAA16969; Wed, 12 Apr
          2000 16:48:24 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <2MSFVSXD>; Wed, 12 Apr 2000 16:43:21 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF67819C@whq-msgusr-02.fore.com>
Date:         Wed, 12 Apr 2000 16:48:21 -0400
Reply-To: "Rosen, Brian" <brosen@FORE.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <brosen@FORE.COM>
Subject:      Re: MEGACO and Dial Pulse Lines
X-To:         John Donak <JDonak@catenanet.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Well you are correct that there is no dial pulse package yet.
I imagine that if there was:
        It would assume the MG does the timing, not the MGC
                This means digitmaps should work, and the call flows
                are really close to what you would see
        It would have properties defining the timing with some
                provisioned defaults

Why don't you propose one along these lines!

Brian


> -----Original Message-----
> From: John Donak [mailto:JDonak@catenanet.com]
> Sent: Wednesday, April 12, 2000 4:30 PM
> To: MEGACO@standards.nortelnetworks.com
> Subject: MEGACO and Dial Pulse Lines
>
>
> All Call Flows I have seen use DTMF for digit dialing. The MG
> collects the
> digits from the originator, based on the DigitMap, and then
> contacts the
> MGC.
>
> How about for Dial Pulse (Rotary) phones behind a Residential
> Gateway? They
> still exist.
>
> Is each individual onhook/offhook reported to the MGC, which
> performs the
> timing/collection? This seems very message intensive.
>
> Or is the Gateway expected to perform the timing/collection?
> If so, how does
> it know the required timing characteristics for the market it
> is in; I have
> not seen a "Dial Pulse" Package.
>
>
>         Regards,
>
>                         John
>
> John Donak
> Catena Networks
> Voice:  (613) 599-6430 x488     Email: jdonak@catenanet.com
> Fax:    (613) 599-6433          URL:  www.catenanet.com
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Apr 12 17:01:53 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03412
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 12 Apr 2000 17:01:53 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EE5A16A0@standards.nortelnetworks.com>; Wed, 12 Apr 2000 16:55:39 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0133 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Apr 2000 16:55:26 -0400
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.E638A310@standards.nortelnetworks.com>; Wed, 12 Apr 2000
          16:55:25 -0400
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Wed, 12 Apr 2000 14:39:54 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <2Z5JX134>; Wed, 12 Apr 2000 14:39:34 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFA4B6.D4576A48"
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B671@zcard00g.ca.nortel.com>
Date:         Wed, 12 Apr 2000 14:39:29 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Digit Map clarification required
X-To:         Chakravarthi PSK <pchakrav@SSD.USA.ALCATEL.COM>
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_01BFA4B6.D4576A48
Content-Type: text/plain

This has been a point of discussion between me and Flemming Andreassen on
the list.  The current situation is this: the extra digit is held back and
the current dial string is reported, typically as a partial match.  The
extra digit is then processed against the next event descriptor to take
effect.  To get the extra digit back to the MGC, that descriptor can include
either another digit map or a request to report the raw digits as they come,
depending on requirements.

> -----Original Message-----
> From: Chakravarthi PSK [SMTP:pchakrav@SSD.USA.ALCATEL.COM]
> Sent: Wednesday, April 12, 2000 9:53 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Digit Map clarification required
>
>   Hi,
>
>     I have one doubt regarding digits received while processing digitmap.
>     If digits 0 and 1 are invalid at digit position 7, but digit 0 or 1 is
> received at digit position 7, will MG forwards the invalid digit (0 or 1)
> in
> the digit string to MGC?  If not, how MGC will know which invalid digit is
> dialed.  This is required if MGC needs to takedifferent actions based on
> invalid digit value.
>
> Regards
> Chak

------_=_NextPart_001_01BFA4B6.D4576A48
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: Digit Map clarification required</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">This has been a =
point of discussion between me and Flemming Andreassen on the =
list.&nbsp; The current situation is this: the extra digit is held back =
and the current dial string is reported, typically as a partial =
match.&nbsp; The extra digit is then processed against the next event =
descriptor to take effect.&nbsp; To get the extra digit back to the =
MGC, that descriptor can include either another digit map or a request =
to report the raw digits as they come, depending on requirements. =
</FONT></P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Chakravarthi PSK =
[SMTP:pchakrav@SSD.USA.ALCATEL.COM]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Wednesday, April 12, 2000 9:53 AM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Digit Map clarification =
required</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; Hi,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; I have one doubt =
regarding digits received while processing digitmap.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; If digits 0 and 1 =
are invalid at digit position 7, but digit 0 or 1 is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">received at digit position 7, will MG =
forwards the invalid digit (0 or 1) in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the digit string to MGC?&nbsp; If =
not, how MGC will know which invalid digit is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">dialed.&nbsp; This is required if MGC =
needs to takedifferent actions based on</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">invalid digit value.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Regards</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Chak</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFA4B6.D4576A48--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Apr 12 17:40:41 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04057
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 12 Apr 2000 17:40:41 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.65EF1670@standards.nortelnetworks.com>; Wed, 12 Apr 2000 17:34:47 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0216 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Apr 2000 17:33:43 -0400
Received: from sj-msg-core-1.cisco.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.3FBD8F90@standards.nortelnetworks.com>; Wed, 12 Apr 2000 17:33:43
          -0400
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by
          sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA11478; Wed, 12
          Apr 2000 14:39:23 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List
          Logging/CISCO.WS.1.2) id OAA02102; Wed, 12 Apr 2000 14:39:19 -0700
          (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <4FBEA8857476D311A03300204840E1CF67819C@whq-msgusr-02.fore.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
        @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
        bUcI'1!
Message-ID:  <14580.60679.421633.117094@thomasm-u1.cisco.com>
Date:         Wed, 12 Apr 2000 14:39:19 -0700
Reply-To: Michael Thomas <mat@CISCO.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Michael Thomas <mat@CISCO.COM>
Subject:      Re: MEGACO and Dial Pulse Lines
X-To:         "Rosen, Brian" <brosen@FORE.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <4FBEA8857476D311A03300204840E1CF67819C@whq-msgusr-02.fore.com>
Content-Transfer-Encoding: 7bit

Having the MG do the digit collection even for
pulse seems completely reasonable. If I recall
correctly, the only difference between pulse and
DTMF is that the switch has a different dial plan
for pulse phones vs. DTMF phones. I don't know
whether that's a statically provisioned thing
within the switch's profile for the line, or
whether it dynamically determines whether it's
a rotary phone given the first pulse dial
digit it sees for the call.

If it's the former, I don't think you need any
difference in digit packages at all. If it's the
latter, the MGC would need to differentiate pulse
from DTMF and send down a different digit map
once it can decide.

I hope it's the former. The latter is a whole lot
of work for not much gain.

        Mike

Rosen, Brian writes:
 > Well you are correct that there is no dial pulse package yet.
 > I imagine that if there was:
 >         It would assume the MG does the timing, not the MGC
 >                 This means digitmaps should work, and the call flows
 >                 are really close to what you would see
 >         It would have properties defining the timing with some
 >                 provisioned defaults
 >
 > Why don't you propose one along these lines!
 >
 > Brian
 >
 >
 > > -----Original Message-----
 > > From: John Donak [mailto:JDonak@catenanet.com]
 > > Sent: Wednesday, April 12, 2000 4:30 PM
 > > To: MEGACO@standards.nortelnetworks.com
 > > Subject: MEGACO and Dial Pulse Lines
 > >
 > >
 > > All Call Flows I have seen use DTMF for digit dialing. The MG
 > > collects the
 > > digits from the originator, based on the DigitMap, and then
 > > contacts the
 > > MGC.
 > >
 > > How about for Dial Pulse (Rotary) phones behind a Residential
 > > Gateway? They
 > > still exist.
 > >
 > > Is each individual onhook/offhook reported to the MGC, which
 > > performs the
 > > timing/collection? This seems very message intensive.
 > >
 > > Or is the Gateway expected to perform the timing/collection?
 > > If so, how does
 > > it know the required timing characteristics for the market it
 > > is in; I have
 > > not seen a "Dial Pulse" Package.
 > >
 > >
 > >         Regards,
 > >
 > >                         John
 > >
 > > John Donak
 > > Catena Networks
 > > Voice:  (613) 599-6430 x488     Email: jdonak@catenanet.com
 > > Fax:    (613) 599-6433          URL:  www.catenanet.com
 > >
 >
 >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Apr 12 18:02:55 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04308
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 12 Apr 2000 18:02:54 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.568DFC70@standards.nortelnetworks.com>; Wed, 12 Apr 2000 17:55:50 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0244 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Apr 2000 17:55:42 -0400
Received: from boca-isbu-nt04.boca.unisphere.com (207.36.128.43) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.51D7A050@standards.nortelnetworks.com>; Wed, 12 Apr 2000
          17:55:42 -0400
Received: by boca-isbu-nt04.boca.unisphere.com with Internet Mail Service
          (5.5.2650.21) id <2VG7PPFL>; Wed, 12 Apr 2000 18:01: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:  <153BDA136259D311859900A0C99B5263052E25@boca-isbu-nt04.boca.unisphere.com>
Date:         Wed, 12 Apr 2000 18:01:23 -0400
Reply-To: "Glasgow, George" <gGlasgow@UNISPHERESOLUTIONS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Glasgow, George" <gGlasgow@UNISPHERESOLUTIONS.COM>
Subject:      Re: MEGACO and Dial Pulse Lines
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Mike,
Typically a class 5 switch will use the same dial plan for rotary and DTMF.
Of course dial-pulse phones can't dial "*" or "#", so their access codes are
typically preceded by "11". There is nothing to prevent a DTMF subscriber
also using "11" instead of the "*" or "#". The main difference between
dial-pulse and DTMF is usually at the line interface, which is programmable.
Also, dial-pulse subscribers pay a lower line rental for some obscure
reason.

So, a dial-pulse subscriber is provisioned as such via MML, and this in turn
leads to the line interface being programmed accordingly.

When a dial-pulse subscriber dials, the line interface circuitry handles the
dial pulse timing and, hence, digit detection. Once a digit has been dialed,
the digit info is then passed on for further processing in the switch.

Note that dial-pulse subscribers can actually connect DTMF phones to their
lines, but if they use them, then the switch will detect that they are using
DTMF on a dial-pulse provisioned port. This is flagged at the switch as a
"DTMF violation". As mentioned, since dial-pulse subscribers typically pay a
lower line rental cost, flagging this allows the switch operator to recover
potential lost revenue.

With respect to the discussion, I agree with the MG handling the dial-pulse
timing, but it must also be able to detect DTMF even though dial-pulse is
provisioned. I expect that we will have to do this to remain transparent
with existing class 5 switches. I hope that we can utilize the same digit
map for both.

Regards,

George Glasgow
Senior Engineer - SRX-3000 Development
Unisphere Solutions,
900 Broken Sound Parkway, B12S,
Boca Raton, FL 33487,
USA
1-561-955-6555 Voice
1-561-955-6477 Fax

gglasgow@unispheresolutions.com <mailto:gglasgow@unispheresolutions.com>


Visit us on the web at: http://www.unispheresolutions.com





-----Original Message-----
From: Michael Thomas [mailto:mat@CISCO.COM]
Sent: Wednesday, April 12, 2000 5:39 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: MEGACO and Dial Pulse Lines


Having the MG do the digit collection even for
pulse seems completely reasonable. If I recall
correctly, the only difference between pulse and
DTMF is that the switch has a different dial plan
for pulse phones vs. DTMF phones. I don't know
whether that's a statically provisioned thing
within the switch's profile for the line, or
whether it dynamically determines whether it's
a rotary phone given the first pulse dial
digit it sees for the call.

If it's the former, I don't think you need any
difference in digit packages at all. If it's the
latter, the MGC would need to differentiate pulse
from DTMF and send down a different digit map
once it can decide.

I hope it's the former. The latter is a whole lot
of work for not much gain.

        Mike

Rosen, Brian writes:
 > Well you are correct that there is no dial pulse package yet.
 > I imagine that if there was:
 >         It would assume the MG does the timing, not the MGC
 >                 This means digitmaps should work, and the call flows
 >                 are really close to what you would see
 >         It would have properties defining the timing with some
 >                 provisioned defaults
 >
 > Why don't you propose one along these lines!
 >
 > Brian
 >
 >
 > > -----Original Message-----
 > > From: John Donak [mailto:JDonak@catenanet.com]
 > > Sent: Wednesday, April 12, 2000 4:30 PM
 > > To: MEGACO@standards.nortelnetworks.com
 > > Subject: MEGACO and Dial Pulse Lines
 > >
 > >
 > > All Call Flows I have seen use DTMF for digit dialing. The MG
 > > collects the
 > > digits from the originator, based on the DigitMap, and then
 > > contacts the
 > > MGC.
 > >
 > > How about for Dial Pulse (Rotary) phones behind a Residential
 > > Gateway? They
 > > still exist.
 > >
 > > Is each individual onhook/offhook reported to the MGC, which
 > > performs the
 > > timing/collection? This seems very message intensive.
 > >
 > > Or is the Gateway expected to perform the timing/collection?
 > > If so, how does
 > > it know the required timing characteristics for the market it
 > > is in; I have
 > > not seen a "Dial Pulse" Package.
 > >
 > >
 > >         Regards,
 > >
 > >                         John
 > >
 > > John Donak
 > > Catena Networks
 > > Voice:  (613) 599-6430 x488     Email: jdonak@catenanet.com
 > > Fax:    (613) 599-6433          URL:  www.catenanet.com
 > >
 >
 >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Apr 12 21:06:59 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06112
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 12 Apr 2000 21:06:59 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.345E9E10@standards.nortelnetworks.com>; Wed, 12 Apr 2000 21:00:59 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0352 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Apr 2000 20:59:51 -0400
Received: from tama5.ecl.ntt.co.jp by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.A5A6EE80@standards.nortelnetworks.com>; Wed, 12 Apr 2000 20:49:50
          -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
          JAA04838 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 13 Apr 2000
          09:55:26 +0900 (JST) (envelope-from furukawa.satoru@lab.ntt.co.jp)
Received: from ima.m.ecl.ntt.co.jp by nttmail3.ecl.ntt.co.jp
          (8.9.3+3.2W/3.7W/01/18/00) with ESMTP id JAA04258 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 13 Apr 2000 09:55:26
          +0900 (JST) (envelope-from furukawa.satoru@lab.ntt.co.jp)
Received: from sakura.nslab.ecl.ntt.co.jp (sakura.nslab.ecl.ntt.co.jp
          [129.60.13.159]) by ima.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id
          JAA14548 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 13 Apr 2000
          09:55:25 +0900 (JST)
User-Agent: Wanderlust/1.1.0 (Overjoyed) SEMI/1.13.7 (Awazu) FLIM/1.13.2
            (Kasanui) Emacs/20.6 (i586-kondara-linux-gnu) MULE/4.0 (HANANOEN)
MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu")
Content-Type: text/plain; charset=US-ASCII
Message-ID:  <m3aeiy95vl.wl@sakura.nslab.ecl.ntt.co.jp>
Date:         Thu, 13 Apr 2000 09:55:26 +0900
Reply-To: FURUKAWA Satoru <furukawa.satoru@LAB.NTT.CO.JP>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: FURUKAWA Satoru <furukawa.satoru@LAB.NTT.CO.JP>
Subject:      an ephemeral Termination and the null Context
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi,

Does it allowed to Add an ephemeral Termination to the null Context ?
My understanding is that the Addition is not prohibitted explicitly
but I really wonder whether the semantic validity of that has been
recognized.

I would like to create an new ephemeral Termination Adding to the null
Context, Modify it in order to provide some LocalDescriptors (VPI/VCI,
etc.), and then Move it to another 'real' Context, which other
Terminations have been already added to.

A real Context instead of the null Context may bring same results but
I feel like doing without it if possible.

Regards,
Satoru Furukawa


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr 13 00:30:19 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10865
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 13 Apr 2000 00:30:18 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9767CB00@standards.nortelnetworks.com>; Thu, 13 Apr 2000 0:24:11 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0497 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Apr 2000 00:22:31 -0400
Received: from ficon-tech.com (12.10.198.190) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.F3DF47C0@standards.nortelnetworks.com>; Thu, 13 Apr 2000 0:12:28
          -0400
Received: from hgupta (hkumar.india.ficon-tech.com [172.25.1.130]) by
          ficon-tech.com (8.9.3/8.8.7) with SMTP id JAA60142 for
          <megaco@standards.nortelnetworks.com>; Thu, 13 Apr 2000 09:48:02
          +0530 (IST) (envelope-from hkumar@ficon-tech.com)
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_00EB_01BFA52D.6064E6C0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Message-ID:  <00ee01bfa4ff$47761540$820119ac@india.ficontech.com>
Date:         Thu, 13 Apr 2000 09:48:09 +0530
Reply-To: Hemant <hkumar@FICON-TECH.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Hemant <hkumar@FICON-TECH.COM>
Subject:      Command Atomicity and Rollback
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_00EB_01BFA52D.6064E6C0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi everyone,

    The discussions till date on the issue of rollback of command in =
case of its failure do not seem to lead to a clear consensus. Lets look =
at the issue from the point of view of both the MG as well as the MGC.   =
 =20

    From an MG point of view, the MG will always have to maintain =
duplicate state information. One of the current state (after execution =
of descriptor) and another for what existed previous to it while =
executing the command. This would be a lot of overhead in terms of =
memory and implementation complexity. Also there might cases where =
rollback doesn't make sense (signals, event detection etc). Another =
clarification required is whether commands with embedded events and =
signals also be considered atomic? (in case the embedded signal or event =
encounters error, what will the MG rollback to)

     As far as the MGC is concerned, it wants to know the status of the =
termination on which command was executed. This can be determined by =
Auditing the termination.
    Another MGC concern may be that since the command can fail at any =
point, one would think that without rollback implementation, the MGC =
handling following a failed command would be very complex. The typical =
action of the MGC however in such cases is to follow up with an error =
treatment(like playing an error tone or taking the termination out of =
context or allocating some other termination etc). Will going back to =
the previous status really help the MGC implementation ? If the reason =
for rollback is to bring the termination into a state known to the MGC, =
it can be achieved by auditing the termination upon receiving the error =
response.

    Considering the above I would favour that rollback not be mandatory. =
Instead on encountering an error, the MG should stop further command =
processing.=20

Any Comments ??=20

Regards,
Hemant=20
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hemant Kumar
Ficon Technology
E-mail: mailto:hkumar@ficon-tech.com
Web: http://www.ficon-tech.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~


------=_NextPart_000_00EB_01BFA52D.6064E6C0
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#c0c0c0>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial><FONT size=3D-1>Hi=20
everyone,</FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; The discussions till =
date on the=20
issue of rollback of command in case of its failure do not seem to lead =
to a=20
clear consensus. Lets look at the issue from the point of view of both =
the MG as=20
well as the MGC.&nbsp;<FONT face=3DArial><FONT =
size=3D-1>&nbsp;&nbsp;&nbsp;=20
</FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D-1></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D-1>&nbsp;&nbsp;&nbsp; From an MG =
point of view,=20
the MG will always have to maintain duplicate state information. One of =
the=20
current state (after execution of descriptor) and another for what =
existed=20
previous to it while executing the command. This would be a lot of =
overhead in=20
terms of memory and implementation complexity. Also there might cases =
where=20
rollback doesn't make sense (signals, event detection etc). Another=20
clarification required is whether commands with embedded events and =
signals also=20
be considered atomic? (in case the embedded signal or event encounters =
error,=20
what will the MG rollback to)</FONT></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;<FONT face=3DArial><FONT size=3D-1>&nbsp;&nbsp;&nbsp; As far =
as the MGC=20
is concerned, it wants to know the status of the termination on which =
command=20
was executed. This can be determined by Auditing the=20
termination.</FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D-1>&nbsp;&nbsp;&nbsp; Another MGC =
concern may=20
be that since the command can fail at any point, one would think that =
without=20
rollback implementation, the MGC handling following a failed command =
would be=20
very complex. The typical action of the MGC however in such cases is to =
follow=20
up with an error treatment(like playing an error tone or taking the =
termination=20
out of context or allocating some other termination etc). Will going =
back to the=20
previous status really help the MGC implementation ?</FONT></FONT><FONT=20
face=3DArial><FONT size=3D-1> If the reason for rollback is to bring the =
termination=20
into a state known to the MGC, it can be achieved by auditing the =
termination=20
upon receiving the error response.</FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D-1></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D-1>&nbsp;&nbsp;&nbsp; Considering =
the above I=20
would favour that rollback not be mandatory. Instead on encountering an =
error,=20
the MG should stop further command processing.</FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D-1></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D-1>Any Comments =
??</FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D-1></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D-1>Regards,</FONT></FONT><FONT =
face=3DArial><FONT=20
size=3D-1></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D-1>Hemant</FONT></FONT>&nbsp;<FONT=20
face=3DArial><FONT size=3D-1></FONT></FONT></DIV></FONT>
<DIV><FONT face=3DArial size=3D2>~~~~~~~~~~~~~~~~~~~~~~~~~~~~<BR>Hemant=20
Kumar<BR>Ficon Technology<BR>E-mail: <A=20
href=3D"mailto:hkumar@ficon-tech.com">mailto:hkumar@ficon-tech.com</A><BR=
>Web: <A=20
href=3D"http://www.ficon-tech.com">http://www.ficon-tech.com</A><BR>~~~~~=
~~~~~~~~~~~~~~~~~~~~~~~<BR></FONT></DIV></BODY></HTML>

------=_NextPart_000_00EB_01BFA52D.6064E6C0--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr 13 02:57:38 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23566
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 13 Apr 2000 02:57:37 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.27DFA680@standards.nortelnetworks.com>; Thu, 13 Apr 2000 2:51:24 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0625 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Apr 2000 02:50:53 -0400
Received: from mail.axestech.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.AFED47A0@standards.nortelnetworks.com>; Thu, 13 Apr 2000 2:40:53
          -0400
Received: by maxip18.maxipro.com with Internet Mail Service (5.5.1960.3) id
          <HN49Q21B>; Thu, 13 Apr 2000 02:07:00 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Message-ID:  <C1AAB24F0C66D3118B5B0000E861BB710331C6@maxip18.maxipro.com>
Date:         Thu, 13 Apr 2000 02:06:54 -0500
Reply-To: J Ramachandra <JRamachandra@AXESTECH.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: J Ramachandra <JRamachandra@AXESTECH.COM>
Subject:      Transaction ID NULL
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi,

Section 8.2.2 Transaction Reply, specifies
"If the receiver encounters an error such that it cannot determine a
legal Transaction, it will return a TransactionReply with a null
TransactionID and a single error descriptor (403 Syntax Error in
Transaction)".

What is null TransactionID?
Is it 0 ?  e.g. Reply=0 {Error=403{error string} }
OR is it like Reply= {Error=403{error string}}?
As per ABNF, second one results in syntax error.

If it is 0, one is not expected to use transaction ID 0 for a valid
transaction request? (MGCP Implementation Guide by International
Softswitch Consortium suggests this for MGCP). If one uses it, how to
identify whether it is the Reply received for transaction Request 0
or an error response for one of your requests?

Finally,what purpose it serves to receive a reply like this, when you
can not determine for which transaction this reply is? Why not ignore
such a transaction Request, instead of sending an error Reply?


- J K Ramachandra
  AXES TECHNOLOGIES.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr 13 04:33:59 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24721
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 13 Apr 2000 04:33:59 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.931A9880@standards.nortelnetworks.com>; Thu, 13 Apr 2000 4:27:27 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0664 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Apr 2000 04:26:10 -0400
Received: from mel.alcatel.fr (212.208.74.132) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.FF2B9D00@standards.nortelnetworks.com>; Thu, 13 Apr 2000 4:16:09
          -0400
Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by
          mel.alcatel.fr (ALCANET/SMTP) with ESMTP id JAA11500 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 13 Apr 2000 09:12:05 +0200
Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by
          aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id KAA10753 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 13 Apr 2000 10:17:43
          +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 KAA10002 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 13 Apr 2000 10:16:45
          +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 KAA29769 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 13 Apr 2000 10:16:43
          +0200 (MET DST)
X-Mailer: Mozilla 4.5 [fr] (WinNT; I)
X-Accept-Language: en,fr
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38F582D7.D8608BE4@ms.alcatel.fr>
Date:         Thu, 13 Apr 2000 10:18:32 +0200
Reply-To: Thomas LEVY <thomas.levy@MS.ALCATEL.FR>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Thomas LEVY <thomas.levy@MS.ALCATEL.FR>
Organization: Alcatel
Subject:      Multiple streams per call,
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

    Hi,

Megaco supports multiple media streams per termination => so 1 call (or
conference) with multiple streams may corresponds to 1 context viewed
from a media gateway.
The reciprocal is not so clear to me: MUST all the media streams from 1
call be associated to 1 context.
In other term, is there a "one for one" relationship between Context and
Call?
In fact, I think no.
I was thinking about a case where terminal A and terminal B are trying
to establish an Audio/Video (with separate streams) call. But as audio
encoding supported by A and B are compatible, video encoding are not
compatible thus requiring the transcoding function of the media gateway
MG1. In such case, I think that the MGC should control the audio stream
in order to go from A to B directly, while video stream go from A to B
via MG1.
Does it seem to you to be a scenario in the scope of Megaco?
Comments welcome,

Thomas LEVY,
Alcatel Corporate Research Center


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr 13 09:30:16 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00854
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 13 Apr 2000 09:30:16 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F7220FB0@standards.nortelnetworks.com>; Thu, 13 Apr 2000 9:23:44 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0839 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Apr 2000 09:22:22 -0400
Received: from cat01s2.catenanet.com (209.135.116.34) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.C5ABB530@standards.nortelnetworks.com>; Thu, 13 Apr 2000
          9:22:21 -0400
Received: by CAT01S2 with Internet Mail Service (5.5.2448.0) id <2NJZ8S1L>;
          Thu, 13 Apr 2000 09:28:09 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <310508EDF557D31188FA0050DA0A3752264587@CAT01S2>
Date:         Thu, 13 Apr 2000 09:28:06 -0400
Reply-To: John Donak <JDonak@CATENANET.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: John Donak <JDonak@CATENANET.COM>
Subject:      Re: MEGACO and Dial Pulse Lines
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I agree with George, since POTS transparency is key.

It appears that a "Dial pulse" package is needed to inform the MG of the
dial pulse characteristics (PPS, Make/Break Ratio). What else?

What is the process for creating such a package? Can anyone create an IETF
draft?


                John


-----Original Message-----
From: Glasgow, George [mailto:gGlasgow@UNISPHERESOLUTIONS.COM]
Sent: Wednesday, April 12, 2000 6:01 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: MEGACO and Dial Pulse Lines


Mike,
Typically a class 5 switch will use the same dial plan for rotary and DTMF.
Of course dial-pulse phones can't dial "*" or "#", so their access codes are
typically preceded by "11". There is nothing to prevent a DTMF subscriber
also using "11" instead of the "*" or "#". The main difference between
dial-pulse and DTMF is usually at the line interface, which is programmable.
Also, dial-pulse subscribers pay a lower line rental for some obscure
reason.

So, a dial-pulse subscriber is provisioned as such via MML, and this in turn
leads to the line interface being programmed accordingly.

When a dial-pulse subscriber dials, the line interface circuitry handles the
dial pulse timing and, hence, digit detection. Once a digit has been dialed,
the digit info is then passed on for further processing in the switch.

Note that dial-pulse subscribers can actually connect DTMF phones to their
lines, but if they use them, then the switch will detect that they are using
DTMF on a dial-pulse provisioned port. This is flagged at the switch as a
"DTMF violation". As mentioned, since dial-pulse subscribers typically pay a
lower line rental cost, flagging this allows the switch operator to recover
potential lost revenue.

With respect to the discussion, I agree with the MG handling the dial-pulse
timing, but it must also be able to detect DTMF even though dial-pulse is
provisioned. I expect that we will have to do this to remain transparent
with existing class 5 switches. I hope that we can utilize the same digit
map for both.

Regards,

George Glasgow
Senior Engineer - SRX-3000 Development
Unisphere Solutions,
900 Broken Sound Parkway, B12S,
Boca Raton, FL 33487,
USA
1-561-955-6555 Voice
1-561-955-6477 Fax

gglasgow@unispheresolutions.com <mailto:gglasgow@unispheresolutions.com>


Visit us on the web at: http://www.unispheresolutions.com





-----Original Message-----
From: Michael Thomas [mailto:mat@CISCO.COM]
Sent: Wednesday, April 12, 2000 5:39 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: MEGACO and Dial Pulse Lines


Having the MG do the digit collection even for
pulse seems completely reasonable. If I recall
correctly, the only difference between pulse and
DTMF is that the switch has a different dial plan
for pulse phones vs. DTMF phones. I don't know
whether that's a statically provisioned thing
within the switch's profile for the line, or
whether it dynamically determines whether it's
a rotary phone given the first pulse dial
digit it sees for the call.

If it's the former, I don't think you need any
difference in digit packages at all. If it's the
latter, the MGC would need to differentiate pulse
from DTMF and send down a different digit map
once it can decide.

I hope it's the former. The latter is a whole lot
of work for not much gain.

        Mike

Rosen, Brian writes:
 > Well you are correct that there is no dial pulse package yet.
 > I imagine that if there was:
 >         It would assume the MG does the timing, not the MGC
 >                 This means digitmaps should work, and the call flows
 >                 are really close to what you would see
 >         It would have properties defining the timing with some
 >                 provisioned defaults
 >
 > Why don't you propose one along these lines!
 >
 > Brian
 >
 >
 > > -----Original Message-----
 > > From: John Donak [mailto:JDonak@catenanet.com]
 > > Sent: Wednesday, April 12, 2000 4:30 PM
 > > To: MEGACO@standards.nortelnetworks.com
 > > Subject: MEGACO and Dial Pulse Lines
 > >
 > >
 > > All Call Flows I have seen use DTMF for digit dialing. The MG
 > > collects the
 > > digits from the originator, based on the DigitMap, and then
 > > contacts the
 > > MGC.
 > >
 > > How about for Dial Pulse (Rotary) phones behind a Residential
 > > Gateway? They
 > > still exist.
 > >
 > > Is each individual onhook/offhook reported to the MGC, which
 > > performs the
 > > timing/collection? This seems very message intensive.
 > >
 > > Or is the Gateway expected to perform the timing/collection?
 > > If so, how does
 > > it know the required timing characteristics for the market it
 > > is in; I have
 > > not seen a "Dial Pulse" Package.
 > >
 > >
 > >         Regards,
 > >
 > >                         John
 > >
 > > John Donak
 > > Catena Networks
 > > Voice:  (613) 599-6430 x488     Email: jdonak@catenanet.com
 > > Fax:    (613) 599-6433          URL:  www.catenanet.com
 > >
 >
 >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr 13 09:53:11 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01882
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 13 Apr 2000 09:53:11 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2F536890@standards.nortelnetworks.com>; Thu, 13 Apr 2000 9:46:47 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0874 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Apr 2000 09:45:14 -0400
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.F76B1F40@standards.nortelnetworks.com>; Thu, 13 Apr 2000 9:45:13
          -0400
Received: from chsharp-tecra.cisco.com (chsharp-isdn.cisco.com
          [171.68.116.221]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2)
          with ESMTP id GAA04803; Thu, 13 Apr 2000 06:50:43 -0700 (PDT)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.3.1.2.20000413094541.00bf6930@dogwood.cisco.com>
Date:         Thu, 13 Apr 2000 09:50:12 -0400
Reply-To: Chip Sharp <chsharp@CISCO.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chip Sharp <chsharp@CISCO.COM>
Subject:      Re: Multiple streams per call
X-To:         Thomas LEVY <thomas.levy@MS.ALCATEL.FR>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <38F582D7.D8608BE4@ms.alcatel.fr>

At 10:18 AM 4/13/00 +0200, Thomas LEVY wrote:
>     Hi,
>
>Megaco supports multiple media streams per termination => so 1 call (or
>conference) with multiple streams may corresponds to 1 context viewed
>from a media gateway.
>The reciprocal is not so clear to me: MUST all the media streams from 1
>call be associated to 1 context.

I believe the answer is yes.

>In other term, is there a "one for one" relationship between Context and
>Call?
>In fact, I think no.

Since "call" isn't so well defined, this isn't so clear.

>I was thinking about a case where terminal A and terminal B are trying
>to establish an Audio/Video (with separate streams) call. But as audio
>encoding supported by A and B are compatible, video encoding are not
>compatible thus requiring the transcoding function of the media gateway
>MG1. In such case, I think that the MGC should control the audio stream
>in order to go from A to B directly, while video stream go from A to B
>via MG1.
>Does it seem to you to be a scenario in the scope of Megaco?

In order to do this, I believe you would have to add multiple terminations
to the context (from A's perspective, one for MG1 and one for B) and fiddle
with the topology parameter to get things to go to the correct place.  But
I'm not sure.  Since one of the primary design criteria for H.248 was to
support multimedia calls easier, I'm sure someone will answer with a simple
way to do this.

>Comments welcome,
>
>Thomas LEVY,
>Alcatel Corporate Research Center

http://www.netaid.org
-------------------------------------------------------------------------
Chip Sharp                 CTO Consulting Engineering
Cisco Systems
Reality - Love it or Leave it.
------------------------------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr 13 09:53:13 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01885
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 13 Apr 2000 09:53:12 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2FB2C6A0@standards.nortelnetworks.com>; Thu, 13 Apr 2000 9:46:48 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0879 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Apr 2000 09:45:16 -0400
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.F91F5EF0@standards.nortelnetworks.com>; Thu, 13 Apr 2000 9:45:16
          -0400
Received: from chsharp-tecra.cisco.com (chsharp-isdn.cisco.com
          [171.68.116.221]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2)
          with ESMTP id GAA04787; Thu, 13 Apr 2000 06:50:37 -0700 (PDT)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.3.1.2.20000413093808.00b63d00@dogwood.cisco.com>
Date:         Thu, 13 Apr 2000 09:44:37 -0400
Reply-To: Chip Sharp <chsharp@CISCO.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chip Sharp <chsharp@CISCO.COM>
Subject:      Re: MEGACO and Dial Pulse Lines
X-To:         "Glasgow, George" <gGlasgow@UNISPHERESOLUTIONS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <153BDA136259D311859900A0C99B5263052E25@boca-isbu-nt04.boca
              .unisphere.com>

At 06:01 PM 4/12/00 -0400, Glasgow, George wrote:
>Mike,
>Typically a class 5 switch will use the same dial plan for rotary and DTMF.
>Of course dial-pulse phones can't dial "*" or "#", so their access codes are
>typically preceded by "11". There is nothing to prevent a DTMF subscriber
>also using "11" instead of the "*" or "#". The main difference between
>dial-pulse and DTMF is usually at the line interface, which is programmable.
>Also, dial-pulse subscribers pay a lower line rental for some obscure
>reason.
>
>So, a dial-pulse subscriber is provisioned as such via MML, and this in turn
>leads to the line interface being programmed accordingly.
>
>When a dial-pulse subscriber dials, the line interface circuitry handles the
>dial pulse timing and, hence, digit detection. Once a digit has been dialed,
>the digit info is then passed on for further processing in the switch.
>
>Note that dial-pulse subscribers can actually connect DTMF phones to their
>lines, but if they use them, then the switch will detect that they are using
>DTMF on a dial-pulse provisioned port. This is flagged at the switch as a
>"DTMF violation". As mentioned, since dial-pulse subscribers typically pay a
>lower line rental cost, flagging this allows the switch operator to recover
>potential lost revenue.
>
>With respect to the discussion, I agree with the MG handling the dial-pulse
>timing, but it must also be able to detect DTMF even though dial-pulse is
>provisioned. I expect that we will have to do this to remain transparent
>with existing class 5 switches. I hope that we can utilize the same digit
>map for both.

While I don't see any reason why megaco couldn't support dial pulse
signaling, carrying over such ancient billing anomalies to the packet voice
world seems ridiculous (I know you don't necessarily approve of this, you
are just stating the facts :-).  I imagine that if everyone in an exchange
called their phone company and changed their line to dial pulse, the price
of DTMF dialing would suddenly and mysteriously drop. ;-)

While we are at it, shouldn't we define an SF signaling package?  We could
name it "cc" in honor of Cap'n Crunch.
;-)


>Regards,
>
>George Glasgow
>Senior Engineer - SRX-3000 Development
>Unisphere Solutions,
>900 Broken Sound Parkway, B12S,
>Boca Raton, FL 33487,
>USA
>1-561-955-6555 Voice
>1-561-955-6477 Fax
>
>gglasgow@unispheresolutions.com <mailto:gglasgow@unispheresolutions.com>
>
>
>Visit us on the web at: http://www.unispheresolutions.com
>
>
>
>
>
>-----Original Message-----
>From: Michael Thomas [mailto:mat@CISCO.COM]
>Sent: Wednesday, April 12, 2000 5:39 PM
>To: MEGACO@STANDARDS.NORTELNETWORKS.COM
>Subject: Re: MEGACO and Dial Pulse Lines
>
>
>Having the MG do the digit collection even for
>pulse seems completely reasonable. If I recall
>correctly, the only difference between pulse and
>DTMF is that the switch has a different dial plan
>for pulse phones vs. DTMF phones. I don't know
>whether that's a statically provisioned thing
>within the switch's profile for the line, or
>whether it dynamically determines whether it's
>a rotary phone given the first pulse dial
>digit it sees for the call.
>
>If it's the former, I don't think you need any
>difference in digit packages at all. If it's the
>latter, the MGC would need to differentiate pulse
>from DTMF and send down a different digit map
>once it can decide.
>
>I hope it's the former. The latter is a whole lot
>of work for not much gain.
>
>         Mike
>
>Rosen, Brian writes:
>  > Well you are correct that there is no dial pulse package yet.
>  > I imagine that if there was:
>  >         It would assume the MG does the timing, not the MGC
>  >                 This means digitmaps should work, and the call flows
>  >                 are really close to what you would see
>  >         It would have properties defining the timing with some
>  >                 provisioned defaults
>  >
>  > Why don't you propose one along these lines!
>  >
>  > Brian
>  >
>  >
>  > > -----Original Message-----
>  > > From: John Donak [mailto:JDonak@catenanet.com]
>  > > Sent: Wednesday, April 12, 2000 4:30 PM
>  > > To: MEGACO@standards.nortelnetworks.com
>  > > Subject: MEGACO and Dial Pulse Lines
>  > >
>  > >
>  > > All Call Flows I have seen use DTMF for digit dialing. The MG
>  > > collects the
>  > > digits from the originator, based on the DigitMap, and then
>  > > contacts the
>  > > MGC.
>  > >
>  > > How about for Dial Pulse (Rotary) phones behind a Residential
>  > > Gateway? They
>  > > still exist.
>  > >
>  > > Is each individual onhook/offhook reported to the MGC, which
>  > > performs the
>  > > timing/collection? This seems very message intensive.
>  > >
>  > > Or is the Gateway expected to perform the timing/collection?
>  > > If so, how does
>  > > it know the required timing characteristics for the market it
>  > > is in; I have
>  > > not seen a "Dial Pulse" Package.
>  > >
>  > >
>  > >         Regards,
>  > >
>  > >                         John
>  > >
>  > > John Donak
>  > > Catena Networks
>  > > Voice:  (613) 599-6430 x488     Email: jdonak@catenanet.com
>  > > Fax:    (613) 599-6433          URL:  www.catenanet.com
>  > >
>  >
>  >

http://www.netaid.org
-------------------------------------------------------------------------
Chip Sharp                 CTO Consulting Engineering
Cisco Systems
Reality - Love it or Leave it.
------------------------------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr 13 11:49:00 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05106
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 13 Apr 2000 11:49:00 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DBA64130@standards.nortelnetworks.com>; Thu, 13 Apr 2000 11:38:59 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0991 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Apr 2000 11:37:18 -0400
Received: from notes.relteccorp.com (208.43.60.85) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.39FD2C50@standards.nortelnetworks.com>; Thu, 13 Apr 2000
          11:27:18 -0400
X-MIMETrack: Serialize by Router on MHDGWY01/S/EXT/MC1(Release 5.0.2c (Intl)|2
             February 2000) at 13/04/2000 11:34:12
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Message-ID:  <OF056E07D1.CAD42695-ON862568C0.00549726@relteccorp.com>
Date:         Thu, 13 Apr 2000 10:24:16 -0500
Reply-To: david.k.brown@NA.MARCONICOMMS.COM
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: David K Brown <david.k.brown@NA.MARCONICOMMS.COM>
Subject:      Re: MEGACO and Dial Pulse Lines
X-To:         John Donak <JDonak@CATENANET.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Based on experience with CO development from years gone by:

It seems to me that there is a general issue here, that being whether the
MEGACO model is focusing on: 1) replicating current capabilities or 2)
opening the door to utilize legacy resources to access enhanced services in
an improved fashion.  As I understand, option 2 is the intention, whether
it is stated or not, I am not sure.

In either case, it is necessary to distinguish the stage or state of the
call to determine whether detection of DTMF tones on a DP subscriber port
represents a violation of contract.  Commonly (at least in the CO specs I
designed to X years ago), tone enabled subscribers could use tone or pulse
phones, however, if a pulse were received first, DTMF tones that appear
during the called number digit collection process were ignored.  Older
switches also switched tone detectors in order to share them between
subscribers (this is why tone service was allowed to be tariffed higher -
telcos have been careful to preserve this free profit even though DP
actually should cost more today since tone detectors are on line cards and
DP is done in software and is always a pain).

All of the forgoing history has a purpose in my questions vis: will MEGACO
permit mixed DP and tone dialing? and will MEGACO convert DP after
connection into tone codes to facilitate use of DP phones in customer
convenience services such as IVR?  could this actually simplify the
interaction model?  The question of recognizing flash to support service
initiation rises up again here.  Also, the conventional re-originate code
(1 sec of "#"  tone) would probably need to be translated to something else
for DP phones.

Dave Brown
Systems Engineering, Marconi Communications
8616 Freeport Pkwy
Irving TX 75063
(972)916-4787
david.k.brown@na.marconicomms.com





John Donak <JDonak@CATENANET.COM> on 04/13/2000 08:28:06 AM

Please respond to John Donak <JDonak@CATENANET.COM>

To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
cc:    (bcc: David K Brown/MAIN/MC1)

Subject:  Re: MEGACO and Dial Pulse Lines



I agree with George, since POTS transparency is key.

It appears that a "Dial pulse" package is needed to inform the MG of the
dial pulse characteristics (PPS, Make/Break Ratio). What else?

What is the process for creating such a package? Can anyone create an IETF
draft?


                John


-----Original Message-----
From: Glasgow, George [mailto:gGlasgow@UNISPHERESOLUTIONS.COM]
Sent: Wednesday, April 12, 2000 6:01 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: MEGACO and Dial Pulse Lines


Mike,
Typically a class 5 switch will use the same dial plan for rotary and DTMF.
Of course dial-pulse phones can't dial "*" or "#", so their access codes
are
typically preceded by "11". There is nothing to prevent a DTMF subscriber
also using "11" instead of the "*" or "#". The main difference between
dial-pulse and DTMF is usually at the line interface, which is
programmable.
Also, dial-pulse subscribers pay a lower line rental for some obscure
reason.

So, a dial-pulse subscriber is provisioned as such via MML, and this in
turn
leads to the line interface being programmed accordingly.

When a dial-pulse subscriber dials, the line interface circuitry handles
the
dial pulse timing and, hence, digit detection. Once a digit has been
dialed,
the digit info is then passed on for further processing in the switch.

Note that dial-pulse subscribers can actually connect DTMF phones to their
lines, but if they use them, then the switch will detect that they are
using
DTMF on a dial-pulse provisioned port. This is flagged at the switch as a
"DTMF violation". As mentioned, since dial-pulse subscribers typically pay
a
lower line rental cost, flagging this allows the switch operator to recover
potential lost revenue.

With respect to the discussion, I agree with the MG handling the dial-pulse
timing, but it must also be able to detect DTMF even though dial-pulse is
provisioned. I expect that we will have to do this to remain transparent
with existing class 5 switches. I hope that we can utilize the same digit
map for both.

Regards,

George Glasgow
Senior Engineer - SRX-3000 Development
Unisphere Solutions,
900 Broken Sound Parkway, B12S,
Boca Raton, FL 33487,
USA
1-561-955-6555 Voice
1-561-955-6477 Fax

gglasgow@unispheresolutions.com <mailto:gglasgow@unispheresolutions.com>


Visit us on the web at: http://www.unispheresolutions.com





-----Original Message-----
From: Michael Thomas [mailto:mat@CISCO.COM]
Sent: Wednesday, April 12, 2000 5:39 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: MEGACO and Dial Pulse Lines


Having the MG do the digit collection even for
pulse seems completely reasonable. If I recall
correctly, the only difference between pulse and
DTMF is that the switch has a different dial plan
for pulse phones vs. DTMF phones. I don't know
whether that's a statically provisioned thing
within the switch's profile for the line, or
whether it dynamically determines whether it's
a rotary phone given the first pulse dial
digit it sees for the call.

If it's the former, I don't think you need any
difference in digit packages at all. If it's the
latter, the MGC would need to differentiate pulse
from DTMF and send down a different digit map
once it can decide.

I hope it's the former. The latter is a whole lot
of work for not much gain.

        Mike

Rosen, Brian writes:
 > Well you are correct that there is no dial pulse package yet.
 > I imagine that if there was:
 >         It would assume the MG does the timing, not the MGC
 >                 This means digitmaps should work, and the call flows
 >                 are really close to what you would see
 >         It would have properties defining the timing with some
 >                 provisioned defaults
 >
 > Why don't you propose one along these lines!
 >
 > Brian
 >
 >
 > > -----Original Message-----
 > > From: John Donak [mailto:JDonak@catenanet.com]
 > > Sent: Wednesday, April 12, 2000 4:30 PM
 > > To: MEGACO@standards.nortelnetworks.com
 > > Subject: MEGACO and Dial Pulse Lines
 > >
 > >
 > > All Call Flows I have seen use DTMF for digit dialing. The MG
 > > collects the
 > > digits from the originator, based on the DigitMap, and then
 > > contacts the
 > > MGC.
 > >
 > > How about for Dial Pulse (Rotary) phones behind a Residential
 > > Gateway? They
 > > still exist.
 > >
 > > Is each individual onhook/offhook reported to the MGC, which
 > > performs the
 > > timing/collection? This seems very message intensive.
 > >
 > > Or is the Gateway expected to perform the timing/collection?
 > > If so, how does
 > > it know the required timing characteristics for the market it
 > > is in; I have
 > > not seen a "Dial Pulse" Package.
 > >
 > >
 > >         Regards,
 > >
 > >                         John
 > >
 > > John Donak
 > > Catena Networks
 > > Voice:  (613) 599-6430 x488     Email: jdonak@catenanet.com
 > > Fax:    (613) 599-6433          URL:  www.catenanet.com
 > >
 >
 >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr 13 12:20:19 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06098
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 13 Apr 2000 12:20:18 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C5074AF0@standards.nortelnetworks.com>; Thu, 13 Apr 2000 12:14:08 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1118 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Apr 2000 12:12:35 -0400
Received: from vambo.motivity.ca by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.2723A280@standards.nortelnetworks.com>; Thu, 13 Apr 2000 12:02:34
          -0400
Received: from desk (desk.motivity.ca [192.197.189.10]) by vambo.motivity.ca
          (8.9.3/8.9.3) with SMTP id QAA11041; Thu, 13 Apr 2000 16:07:48 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)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Message-ID:  <NBBBIOHCCJPPDNIBBIKCAEOICCAA.vances@motivity.ca>
Date:         Thu, 13 Apr 2000 12:03:03 -0400
Reply-To: Vance Shipley <vances@MOTIVITY.CA>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Vance Shipley <vances@MOTIVITY.CA>
Subject:      Re: MEGACO and Dial Pulse Lines
X-To:         david.k.brown@NA.MARCONICOMMS.COM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <OF056E07D1.CAD42695-ON862568C0.00549726@relteccorp.com>
Content-Transfer-Encoding: 7bit

David K Brown writes:
}  ....  Also, the conventional re-originate code (1 sec of "#"  tone)
}  would probably need to be translated to something else for DP phones.

By who's convention is that?  It's a pet peeve of mine that the practice
of using a prolonged '#' tone during an established call seems to be
acceptable to my collegues.  In my mind it is unnecessary, a '#' sent
when there is no called party connected (i.e. they haven't answered or
they have hung up) is common practice and acceptable.  To monitor a
connected call with tone receivers is expensive.  More importantly
though once you create this sort of escape sequence (it's really akin
to the Hayes modem command '+++') you have decided what is and is not
valid customer payload.  Just think about what happens when you tandem
through several networks with this function!

        -Vance


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr 13 12:36:07 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07000
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 13 Apr 2000 12:36:05 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BC0B6B00@standards.nortelnetworks.com>; Thu, 13 Apr 2000 12:28:12 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1159 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Apr 2000 12:27:59 -0400
Received: from smtprich.nortel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.B39B6240@standards.nortelnetworks.com>; Thu, 13 Apr 2000 12:27:58
          -0400
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprich.nortel.com; Thu, 13 Apr 2000 10:40:57 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <2Z5JXXFN>; Thu, 13 Apr 2000 10:39:50 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFA55E.805A3E90"
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B67B@zcard00g.ca.nortel.com>
Date:         Thu, 13 Apr 2000 10:39:44 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Interim AH in MEGACO
X-To:         "Rosen, Brian" <brosen@FORE.COM>
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_01BFA55E.805A3E90
Content-Type: text/plain

I will add this to the "resolved issues" section of my error document.  In
brief: change words in section 10.2, change ABNF.

> -----Original Message-----
> From: Rosen, Brian [SMTP:brosen@FORE.COM]
> Sent: Saturday, April 01, 2000 10:02 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: Interim AH in MEGACO
>
> I'll need to do some more checking, but at first glance I think you
> have found an error, and it should be 24 - 64 hex digits.
>
> The port number question is very interesting.  It's hard not to conclude
> that
> it's the destination port number, as that would be the one in the UDP
> header.
> However, the most useful one would be the source port, as it's more useful
> to aid in anti-spoofing.  I think we had better not go there, and say it's
> the destination port, just like it would be in the real IPSEC.
>
> Brian
>
> > -----Original Message-----
> > From: J Ramachandra [mailto:JRamachandra@axestech.com]
> > Sent: Thursday, March 30, 2000 7:25 AM
> > To: MEGACO@standards.nortelnetworks.com
> > Subject: Interim AH in MEGACO
> >
> >
> > Hello,
> >
> > I have a couple of questions on Interim AH Scheme.
> >
> > The MEGACO V16 document (section 10.2) refers to RFC 2402
> > Section 5. This in turn refers to RFC 2403 (HMAC-MD5-96)
> > and RFC 2404 (HMAC-SHA-1-96)as two possible options. These
> > two algorithms produce 128 and 160 bits authenticator value,
> > but over the network only truncated 96 bits are transmitted
> > to reduce the attack.
> > Now, the question is, MEGACO/H.248 ABNF specifies authData
> > as 32 to 64 Hex digits. Why is it not from 24 to 64
> > hex digits?  Where one has to fit in the 24 hex digits(96 bits)
> > in this 32 Hex digit space? OR am I missing something?
> >
> > Also, the same section specifies "synthesized IP header
> > consisting of a 32 bit source IP address, a 32 bit destination
> > address and an 16 bit UDP encoded as 10 hex digits". Which UDP
> > port number to be used  (Source or destination)?
> >
> >
> > - J.K.Ramachandra,
> >   AXES TECHNOLOGIES.
> >

------_=_NextPart_001_01BFA55E.805A3E90
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: Interim AH in MEGACO</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I will add this to =
the &quot;resolved issues&quot; section of my error document.&nbsp; In =
brief: change words in section 10.2, change ABNF.</FONT></P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Rosen, Brian [SMTP:brosen@FORE.COM]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Saturday, April 01, 2000 10:02 AM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Re: Interim AH in MEGACO</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I'll need to do some more checking, =
but at first glance I think you</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">have found an error, and it should be =
24 - 64 hex digits.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The port number question is very =
interesting.&nbsp; It's hard not to conclude</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">that</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">it's the destination port number, as =
that would be the one in the UDP</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">header.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">However, the most useful one would be =
the source port, as it's more useful</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">to aid in anti-spoofing.&nbsp; I =
think we had better not go there, and say it's</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the destination port, just like it =
would be in the real IPSEC.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Brian</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; From: J Ramachandra =
[<U></U></FONT><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"mailto:JRamachandra@axestech.com">mailto:JRamachandra@axestech.c=
om</A></FONT></U><FONT SIZE=3D2 FACE=3D"Arial">]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Sent: Thursday, March 30, 2000 =
7:25 AM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; To: =
MEGACO@standards.nortelnetworks.com</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Subject: Interim AH in =
MEGACO</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Hello,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; I have a couple of questions on =
Interim AH Scheme.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; The MEGACO V16 document (section =
10.2) refers to RFC 2402</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Section 5. This in turn refers =
to RFC 2403 (HMAC-MD5-96)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; and RFC 2404 (HMAC-SHA-1-96)as =
two possible options. These</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; two algorithms produce 128 and =
160 bits authenticator value,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; but over the network only =
truncated 96 bits are transmitted</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; to reduce the attack.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Now, the question is, =
MEGACO/H.248 ABNF specifies authData</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; as 32 to 64 Hex digits. Why is =
it not from 24 to 64</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; hex digits?&nbsp; Where one has =
to fit in the 24 hex digits(96 bits)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; in this 32 Hex digit space? OR =
am I missing something?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Also, the same section specifies =
&quot;synthesized IP header</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; consisting of a 32 bit source IP =
address, a 32 bit destination</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; address and an 16 bit UDP =
encoded as 10 hex digits&quot;. Which UDP</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; port number to be used&nbsp; =
(Source or destination)?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; - J.K.Ramachandra,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;&nbsp; AXES =
TECHNOLOGIES.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFA55E.805A3E90--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr 13 12:51:37 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07610
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 13 Apr 2000 12:51:36 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1ECBF500@standards.nortelnetworks.com>; Thu, 13 Apr 2000 12:45:17 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1213 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Apr 2000 12:43:58 -0400
Received: from notes.relteccorp.com (208.43.60.85) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.EFEEBBF0@standards.nortelnetworks.com>; Thu, 13 Apr 2000
          12:43:58 -0400
X-MIMETrack: Serialize by Router on MHDGWY01/S/EXT/MC1(Release 5.0.2c (Intl)|2
             February 2000) at 13/04/2000 12:50:52
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Message-ID:  <OF413F94C1.E7E9A84D-ON862568C0.005BA3D1@relteccorp.com>
Date:         Thu, 13 Apr 2000 11:45:24 -0500
Reply-To: david.k.brown@NA.MARCONICOMMS.COM
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: David K Brown <david.k.brown@NA.MARCONICOMMS.COM>
Subject:      Re: MEGACO and Dial Pulse Lines
X-To:         Vance Shipley <vances@MOTIVITY.CA>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I understand and agree, however, the function is useful and extensively
used - here we may have another opportunity for improvement in MEGACO.

Note that the intent of the extended tone is to allow shared tone detectors
within the servicing switch.  At least that was what was intended when the
idea was originated (by Gunnar Korpinen at DanRay or DSC?).

Dave Brown





Vance Shipley <vances@MOTIVITY.CA> on 04/13/2000 11:03:03 AM

Please respond to Vance Shipley <vances@MOTIVITY.CA>

To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
cc:    (bcc: David K Brown/MAIN/MC1)

Subject:  Re: MEGACO and Dial Pulse Lines



David K Brown writes:
}  ....  Also, the conventional re-originate code (1 sec of "#"  tone)
}  would probably need to be translated to something else for DP phones.

By who's convention is that?  It's a pet peeve of mine that the practice
of using a prolonged '#' tone during an established call seems to be
acceptable to my collegues.  In my mind it is unnecessary, a '#' sent
when there is no called party connected (i.e. they haven't answered or
they have hung up) is common practice and acceptable.  To monitor a
connected call with tone receivers is expensive.  More importantly
though once you create this sort of escape sequence (it's really akin
to the Hayes modem command '+++') you have decided what is and is not
valid customer payload.  Just think about what happens when you tandem
through several networks with this function!

        -Vance


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr 13 13:01:37 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07972
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 13 Apr 2000 13:01:36 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.85A04F00@standards.nortelnetworks.com>; Thu, 13 Apr 2000 12:55:19 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1235 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Apr 2000 12:53:42 -0400
Received: from boca-isbu-nt04.boca.unisphere.com (207.36.128.43) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.4BB04ED0@standards.nortelnetworks.com>; Thu, 13 Apr 2000
          12:53:42 -0400
Received: by boca-isbu-nt04.boca.unisphere.com with Internet Mail Service
          (5.5.2650.21) id <2VG7PP2Q>; Thu, 13 Apr 2000 12:59: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:  <153BDA136259D311859900A0C99B5263052E29@boca-isbu-nt04.boca.unisphere.com>
Date:         Thu, 13 Apr 2000 12:59:26 -0400
Reply-To: "Glasgow, George" <gGlasgow@UNISPHERESOLUTIONS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Glasgow, George" <gGlasgow@UNISPHERESOLUTIONS.COM>
Subject:      Re: MEGACO and Dial Pulse Lines
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

My experience with CO design (subscriber call processing) is that we
removed the tone receiver from the connection once we had received all
of the digits. It could be reconnected during a call, but only in special
circumstances. We never had any special code for handling this
re-origination
scenario.

So I don't see how the prolonged '#' will work under normal circumstances,
given that there is no tone receiver listening for it and current CO design
does not take it into consideration.

Also, if you are connected to an interactive response-type device such as
a voicemail system, they very often will respond to '#' by selecting a
particular option on that system. To have one of these systems connected
to the subscriber at the same time as a tone receiver could (would) be
rather
confusing, to say the least.

I agree with Vance that this re-origination code is not sensible.

Perhaps David was referring to a PBX feature?

Regards,

George Glasgow
Senior Engineer - SRX-3000 Development
Unisphere Solutions,
900 Broken Sound Parkway, B12S,
Boca Raton, FL 33487,
USA
1-561-955-6555 Voice
1-561-955-6477 Fax

gglasgow@unispheresolutions.com <mailto:gglasgow@unispheresolutions.com>


Visit us on the web at: http://www.unispheresolutions.com






-----Original Message-----
From: Vance Shipley [mailto:vances@MOTIVITY.CA]
Sent: Thursday, April 13, 2000 12:03 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: MEGACO and Dial Pulse Lines


David K Brown writes:
}  ....  Also, the conventional re-originate code (1 sec of "#"  tone)
}  would probably need to be translated to something else for DP phones.

By who's convention is that?  It's a pet peeve of mine that the practice
of using a prolonged '#' tone during an established call seems to be
acceptable to my collegues.  In my mind it is unnecessary, a '#' sent
when there is no called party connected (i.e. they haven't answered or
they have hung up) is common practice and acceptable.  To monitor a
connected call with tone receivers is expensive.  More importantly
though once you create this sort of escape sequence (it's really akin
to the Hayes modem command '+++') you have decided what is and is not
valid customer payload.  Just think about what happens when you tandem
through several networks with this function!

        -Vance


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr 13 13:07:35 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08221
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 13 Apr 2000 13:07:34 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5DA58460@standards.nortelnetworks.com>; Thu, 13 Apr 2000 13:01:21 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1260 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Apr 2000 12:59:49 -0400
Received: from vambo.motivity.ca by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.262D3AF0@standards.nortelnetworks.com>; Thu, 13 Apr 2000 12:59:48
          -0400
Received: from desk (desk.motivity.ca [192.197.189.10]) by vambo.motivity.ca
          (8.9.3/8.9.3) with SMTP id RAA11197; Thu, 13 Apr 2000 17:05:02 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)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Message-ID:  <NBBBIOHCCJPPDNIBBIKCMEOICCAA.vances@motivity.ca>
Date:         Thu, 13 Apr 2000 13:00:18 -0400
Reply-To: Vance Shipley <vances@MOTIVITY.CA>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Vance Shipley <vances@MOTIVITY.CA>
Subject:      Re: MEGACO and Dial Pulse Lines
X-To:         "Glasgow, George" <gGlasgow@UNISPHERESOLUTIONS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <153BDA136259D311859900A0C99B5263052E29@boca-isbu-nt04.boca.unisphere.com>
Content-Transfer-Encoding: 7bit

}  I agree with Vance that this re-origination code is not sensible.
}
}  Perhaps David was referring to a PBX feature?

It's something that is commonly used in debit card services.

        -Vance


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr 13 13:19:32 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08555
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 13 Apr 2000 13:19:32 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0C34C0D0@standards.nortelnetworks.com>; Thu, 13 Apr 2000 13:13:24 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1288 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Apr 2000 13:11:50 -0400
Received: from boca-isbu-nt04.boca.unisphere.com (207.36.128.43) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.D4182110@standards.nortelnetworks.com>; Thu, 13 Apr 2000
          13:11:49 -0400
Received: by boca-isbu-nt04.boca.unisphere.com with Internet Mail Service
          (5.5.2650.21) id <2VG7PP24>; Thu, 13 Apr 2000 13:17: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:  <153BDA136259D311859900A0C99B5263052E2B@boca-isbu-nt04.boca.unisphere.com>
Date:         Thu, 13 Apr 2000 13:17:26 -0400
Reply-To: "Glasgow, George" <gGlasgow@UNISPHERESOLUTIONS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Glasgow, George" <gGlasgow@UNISPHERESOLUTIONS.COM>
Subject:      Re: MEGACO and Dial Pulse Lines
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Vance,
I agree, but it is not the central office switch that is detecting the '#',
it is the equipment at the debit card company.

I suppose it depends on our perspective of where MEGACO will be used. I am
looking at it from the perspective (at least for this particular discussion
item) that the MG will have residential or business connections and it will
be using megaco to communicate with an MGC. If we then want to replace an
existing class 5 central office, then the key will be transparency.
Operating companies will not accept different operation of features just
because they are getting new technology. To them, the subscriber is king.
Nothing must change in how they use their telephone features.

The same thing happened a number of years ago when the new digital class 5
COs (e.g. Siemens' EWSD, Nortel's DMS100) were first installed. Although we
were compliant with the LSSGR from Bellcore (now Telcordia), we still had to
make our switches compliant with AT&T's 1AESS. This was called "1A
Transparency". We will face the very same pressure when we reach the stage
of replacing the existing COs.

I expect that debit card companies will retain their existing equipment
except that it will be connected to a softswitch. It will still operate the
same way as it does now.

Regards,

George Glasgow
Senior Engineer - SRX-3000 Development
Unisphere Solutions,
900 Broken Sound Parkway, B12S,
Boca Raton, FL 33487,
USA
1-561-955-6555 Voice
1-561-955-6477 Fax

gglasgow@unispheresolutions.com <mailto:gglasgow@unispheresolutions.com>


Visit us on the web at: http://www.unispheresolutions.com







-----Original Message-----
From: Vance Shipley [mailto:vances@motivity.ca]
Sent: Thursday, April 13, 2000 1:00 PM
To: Glasgow, George; MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: RE: MEGACO and Dial Pulse Lines


}  I agree with Vance that this re-origination code is not sensible.
}
}  Perhaps David was referring to a PBX feature?

It's something that is commonly used in debit card services.

        -Vance


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr 13 13:34:37 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09077
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 13 Apr 2000 13:34:37 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.26424CC0@standards.nortelnetworks.com>; Thu, 13 Apr 2000 13:28:26 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1319 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Apr 2000 13:26:36 -0400
Received: from smtprtp.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.E49C4500@standards.nortelnetworks.com>; Thu, 13 Apr 2000 13:26:36
          -0400
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          smtprtp.ntcom.nortel.net; Thu, 13 Apr 2000 13:31:10 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <2K7T7543>; Thu, 13 Apr 2000 13:31:09 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B67D@zcard00g.ca.nortel.com>
Date:         Thu, 13 Apr 2000 13:31:05 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: MEGACO and Dial Pulse Lines
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

The protocol provides a mechanism: the digit map, with the ability to
indicate if long tones are expected.  Megaco doesn't really have to concern
itself with whether that feature is used in a given implementation.

> -----Original Message-----
> From: Glasgow, George [SMTP:gGlasgow@UNISPHERESOLUTIONS.COM]
> Sent: Thursday, April 13, 2000 12:59 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: MEGACO and Dial Pulse Lines
>
> My experience with CO design (subscriber call processing) is that we
> removed the tone receiver from the connection once we had received all
> of the digits. It could be reconnected during a call, but only in special
> circumstances. We never had any special code for handling this
> re-origination
> scenario.
>
> So I don't see how the prolonged '#' will work under normal circumstances,
> given that there is no tone receiver listening for it and current CO
> design
> does not take it into consideration.
>
> Also, if you are connected to an interactive response-type device such as
> a voicemail system, they very often will respond to '#' by selecting a
> particular option on that system. To have one of these systems connected
> to the subscriber at the same time as a tone receiver could (would) be
> rather
> confusing, to say the least.
>
> I agree with Vance that this re-origination code is not sensible.
>
> Perhaps David was referring to a PBX feature?
>
> Regards,
>
> George Glasgow
> Senior Engineer - SRX-3000 Development
> Unisphere Solutions,
> 900 Broken Sound Parkway, B12S,
> Boca Raton, FL 33487,
> USA
> 1-561-955-6555 Voice
> 1-561-955-6477 Fax
>
> gglasgow@unispheresolutions.com <mailto:gglasgow@unispheresolutions.com>
>
>
> Visit us on the web at: http://www.unispheresolutions.com
>
>
>
>
>
>
> -----Original Message-----
> From: Vance Shipley [mailto:vances@MOTIVITY.CA]
> Sent: Thursday, April 13, 2000 12:03 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: MEGACO and Dial Pulse Lines
>
>
> David K Brown writes:
> }  ....  Also, the conventional re-originate code (1 sec of "#"  tone)
> }  would probably need to be translated to something else for DP phones.
>
> By who's convention is that?  It's a pet peeve of mine that the practice
> of using a prolonged '#' tone during an established call seems to be
> acceptable to my collegues.  In my mind it is unnecessary, a '#' sent
> when there is no called party connected (i.e. they haven't answered or
> they have hung up) is common practice and acceptable.  To monitor a
> connected call with tone receivers is expensive.  More importantly
> though once you create this sort of escape sequence (it's really akin
> to the Hayes modem command '+++') you have decided what is and is not
> valid customer payload.  Just think about what happens when you tandem
> through several networks with this function!
>
>         -Vance


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr 13 14:06:11 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09963
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 13 Apr 2000 14:06:10 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7C7F7DC0@standards.nortelnetworks.com>; Thu, 13 Apr 2000 13:59:29 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1351 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Apr 2000 13:58:57 -0400
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.69502510@standards.nortelnetworks.com>; Thu, 13 Apr 2000
          13:58:57 -0400
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Thu, 13 Apr 2000 12:36:01 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <2Z5JX50B>; Thu, 13 Apr 2000 12:33:57 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B67E@zcard00g.ca.nortel.com>
Date:         Thu, 13 Apr 2000 12:33:54 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: MEGACO and Dial Pulse Lines
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

It seems to me this is an implementation issue.  I assume someone will write
a DP lines package to enable collection of DP digits.  With this in place,
an MGC can include just the DP events in the eventsDescriptor or can include
both DP and DTMF events.

> -----Original Message-----
> From: David K Brown [SMTP:david.k.brown@NA.MARCONICOMMS.COM]
> Sent: Thursday, April 13, 2000 11:24 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: MEGACO and Dial Pulse Lines
>
> Based on experience with CO development from years gone by:
>
> It seems to me that there is a general issue here, that being whether the
> MEGACO model is focusing on: 1) replicating current capabilities or 2)
> opening the door to utilize legacy resources to access enhanced services
> in
> an improved fashion.  As I understand, option 2 is the intention, whether
> it is stated or not, I am not sure.
>
> In either case, it is necessary to distinguish the stage or state of the
> call to determine whether detection of DTMF tones on a DP subscriber port
> represents a violation of contract.  Commonly (at least in the CO specs I
> designed to X years ago), tone enabled subscribers could use tone or pulse
> phones, however, if a pulse were received first, DTMF tones that appear
> during the called number digit collection process were ignored.  Older
> switches also switched tone detectors in order to share them between
> subscribers (this is why tone service was allowed to be tariffed higher -
> telcos have been careful to preserve this free profit even though DP
> actually should cost more today since tone detectors are on line cards and
> DP is done in software and is always a pain).
>
> All of the forgoing history has a purpose in my questions vis: will MEGACO
> permit mixed DP and tone dialing? and will MEGACO convert DP after
> connection into tone codes to facilitate use of DP phones in customer
> convenience services such as IVR?  could this actually simplify the
> interaction model?  The question of recognizing flash to support service
> initiation rises up again here.  Also, the conventional re-originate code
> (1 sec of "#"  tone) would probably need to be translated to something
> else
> for DP phones.
>
> Dave Brown
> Systems Engineering, Marconi Communications
> 8616 Freeport Pkwy
> Irving TX 75063
> (972)916-4787
> david.k.brown@na.marconicomms.com
>
>
>
>
>
> John Donak <JDonak@CATENANET.COM> on 04/13/2000 08:28:06 AM
>
> Please respond to John Donak <JDonak@CATENANET.COM>
>
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> cc:    (bcc: David K Brown/MAIN/MC1)
>
> Subject:  Re: MEGACO and Dial Pulse Lines
>
>
>
> I agree with George, since POTS transparency is key.
>
> It appears that a "Dial pulse" package is needed to inform the MG of the
> dial pulse characteristics (PPS, Make/Break Ratio). What else?
>
> What is the process for creating such a package? Can anyone create an IETF
> draft?
>
>
>                 John
>
>
> -----Original Message-----
> From: Glasgow, George [mailto:gGlasgow@UNISPHERESOLUTIONS.COM]
> Sent: Wednesday, April 12, 2000 6:01 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: MEGACO and Dial Pulse Lines
>
>
> Mike,
> Typically a class 5 switch will use the same dial plan for rotary and
> DTMF.
> Of course dial-pulse phones can't dial "*" or "#", so their access codes
> are
> typically preceded by "11". There is nothing to prevent a DTMF subscriber
> also using "11" instead of the "*" or "#". The main difference between
> dial-pulse and DTMF is usually at the line interface, which is
> programmable.
> Also, dial-pulse subscribers pay a lower line rental for some obscure
> reason.
>
> So, a dial-pulse subscriber is provisioned as such via MML, and this in
> turn
> leads to the line interface being programmed accordingly.
>
> When a dial-pulse subscriber dials, the line interface circuitry handles
> the
> dial pulse timing and, hence, digit detection. Once a digit has been
> dialed,
> the digit info is then passed on for further processing in the switch.
>
> Note that dial-pulse subscribers can actually connect DTMF phones to their
> lines, but if they use them, then the switch will detect that they are
> using
> DTMF on a dial-pulse provisioned port. This is flagged at the switch as a
> "DTMF violation". As mentioned, since dial-pulse subscribers typically pay
> a
> lower line rental cost, flagging this allows the switch operator to
> recover
> potential lost revenue.
>
> With respect to the discussion, I agree with the MG handling the
> dial-pulse
> timing, but it must also be able to detect DTMF even though dial-pulse is
> provisioned. I expect that we will have to do this to remain transparent
> with existing class 5 switches. I hope that we can utilize the same digit
> map for both.
>
> Regards,
>
> George Glasgow
> Senior Engineer - SRX-3000 Development
> Unisphere Solutions,
> 900 Broken Sound Parkway, B12S,
> Boca Raton, FL 33487,
> USA
> 1-561-955-6555 Voice
> 1-561-955-6477 Fax
>
> gglasgow@unispheresolutions.com <mailto:gglasgow@unispheresolutions.com>
>
>
> Visit us on the web at: http://www.unispheresolutions.com
>
>
>
>
>
> -----Original Message-----
> From: Michael Thomas [mailto:mat@CISCO.COM]
> Sent: Wednesday, April 12, 2000 5:39 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: MEGACO and Dial Pulse Lines
>
>
> Having the MG do the digit collection even for
> pulse seems completely reasonable. If I recall
> correctly, the only difference between pulse and
> DTMF is that the switch has a different dial plan
> for pulse phones vs. DTMF phones. I don't know
> whether that's a statically provisioned thing
> within the switch's profile for the line, or
> whether it dynamically determines whether it's
> a rotary phone given the first pulse dial
> digit it sees for the call.
>
> If it's the former, I don't think you need any
> difference in digit packages at all. If it's the
> latter, the MGC would need to differentiate pulse
> from DTMF and send down a different digit map
> once it can decide.
>
> I hope it's the former. The latter is a whole lot
> of work for not much gain.
>
>         Mike
>
> Rosen, Brian writes:
>  > Well you are correct that there is no dial pulse package yet.
>  > I imagine that if there was:
>  >         It would assume the MG does the timing, not the MGC
>  >                 This means digitmaps should work, and the call flows
>  >                 are really close to what you would see
>  >         It would have properties defining the timing with some
>  >                 provisioned defaults
>  >
>  > Why don't you propose one along these lines!
>  >
>  > Brian
>  >
>  >
>  > > -----Original Message-----
>  > > From: John Donak [mailto:JDonak@catenanet.com]
>  > > Sent: Wednesday, April 12, 2000 4:30 PM
>  > > To: MEGACO@standards.nortelnetworks.com
>  > > Subject: MEGACO and Dial Pulse Lines
>  > >
>  > >
>  > > All Call Flows I have seen use DTMF for digit dialing. The MG
>  > > collects the
>  > > digits from the originator, based on the DigitMap, and then
>  > > contacts the
>  > > MGC.
>  > >
>  > > How about for Dial Pulse (Rotary) phones behind a Residential
>  > > Gateway? They
>  > > still exist.
>  > >
>  > > Is each individual onhook/offhook reported to the MGC, which
>  > > performs the
>  > > timing/collection? This seems very message intensive.
>  > >
>  > > Or is the Gateway expected to perform the timing/collection?
>  > > If so, how does
>  > > it know the required timing characteristics for the market it
>  > > is in; I have
>  > > not seen a "Dial Pulse" Package.
>  > >
>  > >
>  > >         Regards,
>  > >
>  > >                         John
>  > >
>  > > John Donak
>  > > Catena Networks
>  > > Voice:  (613) 599-6430 x488     Email: jdonak@catenanet.com
>  > > Fax:    (613) 599-6433          URL:  www.catenanet.com
>  > >
>  >
>  >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr 13 14:06:11 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09965
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 13 Apr 2000 14:06:11 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7CE396C0@standards.nortelnetworks.com>; Thu, 13 Apr 2000 13:59:30 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1356 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Apr 2000 13:58:58 -0400
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.69AF8320@standards.nortelnetworks.com>; Thu, 13 Apr 2000
          13:58:57 -0400
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Thu, 13 Apr 2000 10:22:25 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <2Z5JXWRA>; Thu, 13 Apr 2000 10:22:22 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFA55C.10A08DB8"
Message-ID:  <8E2783FA4E0CD411888D0000F8CD15D33C36CB@zcard00q.ca.nortel.com>
Date:         Thu, 13 Apr 2000 10:22:20 -0500
Reply-To: Peter Blatherwick <blather@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Peter Blatherwick <blather@NORTELNETWORKS.COM>
Subject:      Re: MEGACO and Dial Pulse Lines
X-To:         John Donak <JDonak@CATENANET.COM>
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_01BFA55C.10A08DB8
Content-Type: text/plain;
        charset="iso-8859-1"

John, list:

Given preceding discussion, I suggest a pulse dialling package should extend
the existing dtmf detection package, simply adding pulse-specific timing
parameters and the DTMF violation error event.  (Anything else?)  Actual
detection would be hidden in the MG, so the MGC would "see" tones.

Package creation is quite straight forward, thankfully.  Just have a look at
some of the existing examples, for instance in the Megaco/H.248 Protocol
document annexes, and follow the pattern.  See Protocol document section 12
for specifics.  Post as Internet-Draft to this list, and watch the fun.  If
IANA registration is not taken up through this WG, it can be done direct
with IANA as outlined in the Protocol doc.  If unfamiliar with I-D creation
and process, see the documentation elsewhere on the IETF web site (see esp.
http://www.ietf.org/ietf/1id-guidelines.txt).

(As an aside, I'm glad to see Megaco discussion of this, as I have a number
of historical phones at home, just 'cause they look sooo cool, and have
pulse service for this.  Also, just kinda fun to @#&& off the phone company
by paying less for something that costs more.  Call me twisted ... I'm quite
used to it ;-)

-- Peter

> -----Original Message-----
> From: John Donak [SMTP:JDonak@CATENANET.COM]
> Sent: 13 Apr, 2000 09:28
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: MEGACO and Dial Pulse Lines
>
> I agree with George, since POTS transparency is key.
>
> It appears that a "Dial pulse" package is needed to inform the MG of the
> dial pulse characteristics (PPS, Make/Break Ratio). What else?
>
> What is the process for creating such a package? Can anyone create an IETF
> draft?
>
>
>                 John
>
>
> -----Original Message-----
> From: Glasgow, George [mailto:gGlasgow@UNISPHERESOLUTIONS.COM]
> Sent: Wednesday, April 12, 2000 6:01 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: MEGACO and Dial Pulse Lines
>
>
> Mike,
> Typically a class 5 switch will use the same dial plan for rotary and
> DTMF.
> Of course dial-pulse phones can't dial "*" or "#", so their access codes
> are
> typically preceded by "11". There is nothing to prevent a DTMF subscriber
> also using "11" instead of the "*" or "#". The main difference between
> dial-pulse and DTMF is usually at the line interface, which is
> programmable.
> Also, dial-pulse subscribers pay a lower line rental for some obscure
> reason.
>
> So, a dial-pulse subscriber is provisioned as such via MML, and this in
> turn
> leads to the line interface being programmed accordingly.
>
> When a dial-pulse subscriber dials, the line interface circuitry handles
> the
> dial pulse timing and, hence, digit detection. Once a digit has been
> dialed,
> the digit info is then passed on for further processing in the switch.
>
> Note that dial-pulse subscribers can actually connect DTMF phones to their
> lines, but if they use them, then the switch will detect that they are
> using
> DTMF on a dial-pulse provisioned port. This is flagged at the switch as a
> "DTMF violation". As mentioned, since dial-pulse subscribers typically pay
> a
> lower line rental cost, flagging this allows the switch operator to
> recover
> potential lost revenue.
>
> With respect to the discussion, I agree with the MG handling the
> dial-pulse
> timing, but it must also be able to detect DTMF even though dial-pulse is
> provisioned. I expect that we will have to do this to remain transparent
> with existing class 5 switches. I hope that we can utilize the same digit
> map for both.
>
> Regards,
>
> George Glasgow
> Senior Engineer - SRX-3000 Development
> Unisphere Solutions,
> 900 Broken Sound Parkway, B12S,
> Boca Raton, FL 33487,
> USA
> 1-561-955-6555 Voice
> 1-561-955-6477 Fax
>
> gglasgow@unispheresolutions.com <mailto:gglasgow@unispheresolutions.com>
>
>
> Visit us on the web at: http://www.unispheresolutions.com
>
>
>
>
>
> -----Original Message-----
> From: Michael Thomas [mailto:mat@CISCO.COM]
> Sent: Wednesday, April 12, 2000 5:39 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: MEGACO and Dial Pulse Lines
>
>
> Having the MG do the digit collection even for
> pulse seems completely reasonable. If I recall
> correctly, the only difference between pulse and
> DTMF is that the switch has a different dial plan
> for pulse phones vs. DTMF phones. I don't know
> whether that's a statically provisioned thing
> within the switch's profile for the line, or
> whether it dynamically determines whether it's
> a rotary phone given the first pulse dial
> digit it sees for the call.
>
> If it's the former, I don't think you need any
> difference in digit packages at all. If it's the
> latter, the MGC would need to differentiate pulse
> from DTMF and send down a different digit map
> once it can decide.
>
> I hope it's the former. The latter is a whole lot
> of work for not much gain.
>
>         Mike
>
> Rosen, Brian writes:
>  > Well you are correct that there is no dial pulse package yet.
>  > I imagine that if there was:
>  >         It would assume the MG does the timing, not the MGC
>  >                 This means digitmaps should work, and the call flows
>  >                 are really close to what you would see
>  >         It would have properties defining the timing with some
>  >                 provisioned defaults
>  >
>  > Why don't you propose one along these lines!
>  >
>  > Brian
>  >
>  >
>  > > -----Original Message-----
>  > > From: John Donak [mailto:JDonak@catenanet.com]
>  > > Sent: Wednesday, April 12, 2000 4:30 PM
>  > > To: MEGACO@standards.nortelnetworks.com
>  > > Subject: MEGACO and Dial Pulse Lines
>  > >
>  > >
>  > > All Call Flows I have seen use DTMF for digit dialing. The MG
>  > > collects the
>  > > digits from the originator, based on the DigitMap, and then
>  > > contacts the
>  > > MGC.
>  > >
>  > > How about for Dial Pulse (Rotary) phones behind a Residential
>  > > Gateway? They
>  > > still exist.
>  > >
>  > > Is each individual onhook/offhook reported to the MGC, which
>  > > performs the
>  > > timing/collection? This seems very message intensive.
>  > >
>  > > Or is the Gateway expected to perform the timing/collection?
>  > > If so, how does
>  > > it know the required timing characteristics for the market it
>  > > is in; I have
>  > > not seen a "Dial Pulse" Package.
>  > >
>  > >
>  > >         Regards,
>  > >
>  > >                         John
>  > >
>  > > John Donak
>  > > Catena Networks
>  > > Voice:  (613) 599-6430 x488     Email: jdonak@catenanet.com
>  > > Fax:    (613) 599-6433          URL:  www.catenanet.com
>  > >
>  >
>  >

------_=_NextPart_001_01BFA55C.10A08DB8
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: MEGACO and Dial Pulse Lines</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">John, list: </FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Given preceding =
discussion, I suggest a pulse dialling package should extend the =
existing dtmf detection package, simply adding pulse-specific timing =
parameters and the DTMF violation error event.&nbsp; (Anything =
else?)&nbsp; Actual detection would be hidden in the MG, so the MGC =
would &quot;see&quot; tones.&nbsp; </FONT></P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Package creation is =
quite straight forward, thankfully.&nbsp; Just have a look at some of =
the existing examples, for instance in the Megaco/H.248 Protocol =
document annexes, and follow the pattern.&nbsp; See Protocol document =
section 12 for specifics.&nbsp; Post as Internet-Draft to this list, =
and watch the fun.&nbsp; If IANA registration is not taken up through =
this WG, it can be done direct with IANA as outlined in the Protocol =
doc.&nbsp; If unfamiliar with I-D creation and process, see the =
documentation elsewhere on the IETF web site (see esp.</FONT><U> <FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://www.ietf.org/ietf/1id-guidelines.txt" =
TARGET=3D"_blank">http://www.ietf.org/ietf/1id-guidelines.txt</A></FONT>=
</U><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">).&nbsp; =
</FONT></P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">(As an aside, I'm =
glad to see Megaco discussion of this, as I have a number of historical =
phones at home, just 'cause they look sooo cool, and have pulse service =
for this.&nbsp; Also, just kinda fun to @#&amp;&amp; off the phone =
company by paying less for something that costs more.&nbsp; Call me =
twisted ... I'm quite used to it ;-)</FONT></P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">-- Peter</FONT>
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">John Donak [SMTP:JDonak@CATENANET.COM]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">13 Apr, 2000 09:28</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Re: MEGACO and Dial Pulse =
Lines</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I agree with George, since POTS =
transparency is key.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">It appears that a &quot;Dial =
pulse&quot; package is needed to inform the MG of the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">dial pulse characteristics (PPS, =
Make/Break Ratio). What else?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">What is the process for creating such =
a package? Can anyone create an IETF</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">draft?</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; John</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">From: Glasgow, George =
[</FONT><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"mailto:gGlasgow@UNISPHERESOLUTIONS.COM">mailto:gGlasgow@UNISPHER=
ESOLUTIONS.COM</A></FONT></U><FONT SIZE=3D2 FACE=3D"Arial">]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Sent: Wednesday, April 12, 2000 6:01 =
PM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">To: =
MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Subject: Re: MEGACO and Dial Pulse =
Lines</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Mike,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Typically a class 5 switch will use =
the same dial plan for rotary and DTMF.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Of course dial-pulse phones can't =
dial &quot;*&quot; or &quot;#&quot;, so their access codes are</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">typically preceded by &quot;11&quot;. =
There is nothing to prevent a DTMF subscriber</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">also using &quot;11&quot; instead of =
the &quot;*&quot; or &quot;#&quot;. The main difference between</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">dial-pulse and DTMF is usually at the =
line interface, which is programmable.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Also, dial-pulse subscribers pay a =
lower line rental for some obscure</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">reason.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">So, a dial-pulse subscriber is =
provisioned as such via MML, and this in turn</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">leads to the line interface being =
programmed accordingly.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">When a dial-pulse subscriber dials, =
the line interface circuitry handles the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">dial pulse timing and, hence, digit =
detection. Once a digit has been dialed,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the digit info is then passed on for =
further processing in the switch.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Note that dial-pulse subscribers can =
actually connect DTMF phones to their</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">lines, but if they use them, then the =
switch will detect that they are using</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">DTMF on a dial-pulse provisioned =
port. This is flagged at the switch as a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&quot;DTMF violation&quot;. As =
mentioned, since dial-pulse subscribers typically pay a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">lower line rental cost, flagging this =
allows the switch operator to recover</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">potential lost revenue.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">With respect to the discussion, I =
agree with the MG handling the dial-pulse</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">timing, but it must also be able to =
detect DTMF even though dial-pulse is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">provisioned. I expect that we will =
have to do this to remain transparent</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">with existing class 5 switches. I =
hope that we can utilize the same digit</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">map for both.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Regards,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">George Glasgow</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Senior Engineer - SRX-3000 =
Development</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Unisphere Solutions,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">900 Broken Sound Parkway, =
B12S,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Boca Raton, FL 33487,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">USA</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">1-561-955-6555 Voice</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">1-561-955-6477 Fax</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">gglasgow@unispheresolutions.com =
&lt;</FONT><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"mailto:gglasgow@unispheresolutions.com">mailto:gglasgow@unispher=
esolutions.com</A></FONT></U><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Visit us on the web at:</FONT><U> =
<FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://www.unispheresolutions.com" =
TARGET=3D"_blank">http://www.unispheresolutions.com</A></FONT></U>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">From: Michael Thomas [</FONT><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"mailto:mat@CISCO.COM">mailto:mat@CISCO.COM</A></FONT></U><FONT =
SIZE=3D2 FACE=3D"Arial">]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Sent: Wednesday, April 12, 2000 5:39 =
PM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">To: =
MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Subject: Re: MEGACO and Dial Pulse =
Lines</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Having the MG do the digit collection =
even for</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">pulse seems completely reasonable. If =
I recall</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">correctly, the only difference =
between pulse and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">DTMF is that the switch has a =
different dial plan</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">for pulse phones vs. DTMF phones. I =
don't know</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">whether that's a statically =
provisioned thing</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">within the switch's profile for the =
line, or</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">whether it dynamically determines =
whether it's</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">a rotary phone given the first pulse =
dial</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">digit it sees for the call.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">If it's the former, I don't think you =
need any</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">difference in digit packages at all. =
If it's the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">latter, the MGC would need to =
differentiate pulse</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">from DTMF and send down a different =
digit map</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">once it can decide.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I hope it's the former. The latter is =
a whole lot</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">of work for not much gain.</FONT>
</P>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Mike</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Rosen, Brian writes:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; Well you are correct that =
there is no dial pulse package yet.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; I imagine that if there =
was:</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; It would assume the MG does the timing, not the MGC</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This means digitmaps =
should work, and the call flows</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; are really close to =
what you would see</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; It would have properties defining the timing with some</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; provisioned =
defaults</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; Why don't you propose one =
along these lines!</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; Brian</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt; -----Original =
Message-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt; From: John Donak =
[</FONT><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"mailto:JDonak@catenanet.com">mailto:JDonak@catenanet.com</A></FO=
NT></U><FONT SIZE=3D2 FACE=3D"Arial">]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt; Sent: Wednesday, =
April 12, 2000 4:30 PM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt; To: =
MEGACO@standards.nortelnetworks.com</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt; Subject: MEGACO and =
Dial Pulse Lines</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt; All Call Flows I have =
seen use DTMF for digit dialing. The MG</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt; collects the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt; digits from the =
originator, based on the DigitMap, and then</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt; contacts the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt; MGC.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt; How about for Dial =
Pulse (Rotary) phones behind a Residential</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt; Gateway? They</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt; still exist.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt; Is each individual =
onhook/offhook reported to the MGC, which</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt; performs the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt; timing/collection? =
This seems very message intensive.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt; Or is the Gateway =
expected to perform the timing/collection?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt; If so, how =
does</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt; it know the required =
timing characteristics for the market it</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt; is in; I have</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt; not seen a &quot;Dial =
Pulse&quot; Package.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Regards,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; John</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt; John Donak</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt; Catena =
Networks</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt; Voice:&nbsp; (613) =
599-6430 x488&nbsp;&nbsp;&nbsp;&nbsp; Email: =
jdonak@catenanet.com</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt; =
Fax:&nbsp;&nbsp;&nbsp; (613) =
599-6433&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
URL:&nbsp; www.catenanet.com</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&gt;</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFA55C.10A08DB8--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr 13 14:09:54 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10048
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 13 Apr 2000 14:09:53 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0E4721E0@standards.nortelnetworks.com>; Thu, 13 Apr 2000 14:03:34 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1401 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Apr 2000 14:02:10 -0400
Received: from smtprich.nortel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.DC7ADF30@standards.nortelnetworks.com>; Thu, 13 Apr 2000 14:02:10
          -0400
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprich.nortel.com; Thu, 13 Apr 2000 12:48:15 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <2Z5JX6P2>; Thu, 13 Apr 2000 12:46:59 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B67F@zcard00g.ca.nortel.com>
Date:         Thu, 13 Apr 2000 12:46:56 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Open Issue: When Side Effects Of Events Are Executed
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

We have an open issue on when the side effects of events happen.  Here are
the possibilities:

(a) when an event is detected.  Problem: "detection" in my mental model, at
least, is something that happens at the hardware level possibly
independently of the current content of the eventsDescriptor.  Thus the MGC
would have no control over which events cause signals to stop.

(b) when the event is recognized as being of interest because it is in the
eventsDescriptor (event buffering inactive) or is in the
eventBufferDescriptor (event buffering active).  Potential problems: events
may cause side effects but never get reported.  There are two cases: if the
event is processed against a digit map, is rejected as an "extra digit", but
gets thrown away because it is not in the eventsDescriptor activated by the
digit map completion event,  or if the event buffer is cleared by a change
of the control mode.

(c) This leaves the third possibility: events generate their side effects
when they are either notified or accepted into the current dial string of an
active digit map.

Comments?


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr 13 15:36:53 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12044
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 13 Apr 2000 15:36:52 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3970AB50@standards.nortelnetworks.com>; Thu, 13 Apr 2000 15:30:40 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1480 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Apr 2000 15:28:51 -0400
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.F892D590@standards.nortelnetworks.com>; Thu, 13 Apr 2000
          15:28:51 -0400
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Thu, 13 Apr 2000 14:19:50 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <265GAKB8>; Thu, 13 Apr 2000 14:12:21 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B685@zcard00g.ca.nortel.com>
Date:         Thu, 13 Apr 2000 14:12:19 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: V16 Review - Auditing contexts and their terminations
X-To:         Nancy-M Greene <ngreene@nortelnetworks.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I've gone back to the original message to keep things simple.  The
introduction of a new command to audit contexts is IMHO an optimization
rather than a bug fix, and cannot be considered for v1 -- could think about
it for v2.

Comments on your specific issues below:

> -----Original Message-----
> From: Greene, Nancy-M [CAR:5N40:EXCH]
> Sent: Thursday, March 23, 2000 12:54 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      V16 Review - Auditing contexts and their terminations
>
> Here are 2 issues with the ABNF that have come up on our review of
> section 7.2.5 AuditValue:
>
> 1) 7.2.5 Audit Value - auditing all matching terminations and their
> contexts
>
> Issue: The entry before the last in table we have
> "ContextID=ALL  , TerminationID= wildcard, Audit of all matching
> terminations and contexts to which they are associated."
>
> Comment: In the ABNF, the reply reads like this:
> AuditValue = contextID { t1,t2,...}
> We can't report all the contexts in this reply.
> The ABNF must be fixed to allow returning list of contexts
> rather than just one with a list of terminations.
        [PTT]
        As I see it, there is no problem here.  You're looking at the wrong
production.  Look at transactionReply and actionReplyList instead.  The
latter allows reporting of a series of action replies, matching the
"ContextID=ALL" specification.

> 2) 7.2.5 Audit Value - return all context ids
>
> Issue: The last entry in the table is:
> ContextID=All, TerminationID=Root, list of all contextIDs,
>
> Comment: The ABNF does not allow a list of contextIDs
> returned on the audit. This has to be fixed to allow list of
> contexts.
        [PTT]
        Same comment as the previous one.  The results are indeed rather
verbose and it would be nice to fix that, but not until v2.

        [PTT]  [snip]


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr 13 15:39:44 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12176
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 13 Apr 2000 15:39:44 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.827E4C80@standards.nortelnetworks.com>; Thu, 13 Apr 2000 15:32:42 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1504 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Apr 2000 15:32:29 -0400
Received: from mail.mediatrix.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.7A49C620@standards.nortelnetworks.com>; Thu, 13 Apr 2000 15:32:29
          -0400
Received: by mail.mediatrix.com with Internet Mail Service (5.5.2448.0) id
          <2VAWPCNS>; Thu, 13 Apr 2000 15:37:24 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <F1BED55F35F4D3118C0F00E0295CFF4D0151B4@mail.mediatrix.com>
Date:         Thu, 13 Apr 2000 15:37:24 -0400
Reply-To: Gordon Cutts <gcutts@MEDIATRIX.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Gordon Cutts <gcutts@MEDIATRIX.COM>
Subject:      unsubscribe
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

My apologies!!  I have long since flushed the email with the proper address
:(


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr 13 16:27:57 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13287
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 13 Apr 2000 16:27:57 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5D2212D0@standards.nortelnetworks.com>; Thu, 13 Apr 2000 16:21:46 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1551 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Apr 2000 16:19:50 -0400
Received: from witbier.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.17A7F8A0@standards.nortelnetworks.com>; Thu, 13 Apr 2000 16:19:50
          -0400
Received: from mramalho-nt1 (ssh.cisco.com [171.69.10.34]) by witbier.cisco.com
          (8.8.8-Cisco List Logging/8.8.8) with SMTP id NAA09074; Thu, 13 Apr
          2000 13:25:23 -0700 (PDT)
X-Sender: mramalho@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <4.1.20000413155254.00a88bd0@localhost>
Date:         Thu, 13 Apr 2000 15:56:51 -0400
Reply-To: "Michael A. Ramalho" <mramalho@CISCO.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Michael A. Ramalho" <mramalho@CISCO.COM>
Subject:      Re: H.248 Package Coordination
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <C51ED84B6F47D211917A0000F8BCBD1193B66E@zcard00g.ca.nortel. com>

Tom,

As discussed at the Adelaide WG meeting, I assume that you are
still working on the documentation of an agreement framework when
packages are being worked on by IETF/Megaco and other interested
standards bodies (i.e., the case of package overlap or the development
of substantially similar package functionality).

Any target date for a draft of that agreement framework?

Michael Ramalho

At 11:31 AM 4/12/00 -0500, Tom-PT Taylor wrote:
>We have a number of proposed new packages in Megaco, and I'm looking for
>thoughts on the process for agreeing amongst the various interested parties
>about which should become Megaco work items and which should be worked
>elsewhere.  I should say that this should be a two-way street -- work
>introduced elsewhere may be something Megaco wants to get into.
>
>Currently, I suggest that interested parties take a look at the following
>drafts, all available at
>http://www.ietf.org/internet-drafts/<draft-name>
>
>draft-bouwen-megaco-isdn-00.txt
>Issues for Megaco - Sigtran Interworking in ISDN Access Gateways
>
>draft-brown-supplpkgs-00.txt
>Supplemental Packages for Megaco/H.248
>
>Very shortly these will be joined by packages having to do with R1 and R2
>signalling.  I can pass the file names along if there is interest.
>
>Tom Taylor
>


Michael A. Ramalho, Ph.D.
Cisco Systems
1802 Rue de la Port
Wall Township, NJ 07719-3784
Office email: mramalho@cisco.com
Personal email: mar42@cornell.edu
Office: +1.732.449.5762
Cell: +1.732.809.0188
Pager: +1.800.365.4578


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr 13 16:41:19 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13543
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 13 Apr 2000 16:41:19 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2FE24B30@standards.nortelnetworks.com>; Thu, 13 Apr 2000 16:34:49 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1590 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Apr 2000 16:33:51 -0400
Received: from smtprtp1.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.0D386470@standards.nortelnetworks.com>; Thu, 13 Apr 2000 16:33:51
          -0400
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          smtprtp1.ntcom.nortel.net; Thu, 13 Apr 2000 16:19:53 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <2K7T8BFB>; Thu, 13 Apr 2000 16:19:51 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B696@zcard00g.ca.nortel.com>
Date:         Thu, 13 Apr 2000 16:19:43 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: an ephemeral Termination and the null Context
X-To:         FURUKAWA Satoru <furukawa.satoru@LAB.NTT.CO.JP>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

How do you destroy a termination so created?  Do you end up doing Subtract
from the null context?  Does the null context disappear (and what does this
mean?) if there are no more terminations in it?

It is possible to build a logically consistent story for this, but my own
reaction is to prefer leaving the null context as the place where
provisioned terminations exist when not in use.

Other comments?

> -----Original Message-----
> From: FURUKAWA Satoru [SMTP:furukawa.satoru@LAB.NTT.CO.JP]
> Sent: Wednesday, April 12, 2000 8:55 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      an ephemeral Termination and the null Context
>
> Hi,
>
> Does it allowed to Add an ephemeral Termination to the null Context ?
> My understanding is that the Addition is not prohibitted explicitly
> but I really wonder whether the semantic validity of that has been
> recognized.
>
> I would like to create an new ephemeral Termination Adding to the null
> Context, Modify it in order to provide some LocalDescriptors (VPI/VCI,
> etc.), and then Move it to another 'real' Context, which other
> Terminations have been already added to.
>
> A real Context instead of the null Context may bring same results but
> I feel like doing without it if possible.
>
> Regards,
> Satoru Furukawa


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr 13 16:41:19 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13545
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 13 Apr 2000 16:41:19 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.30466430@standards.nortelnetworks.com>; Thu, 13 Apr 2000 16:34:50 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1595 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Apr 2000 16:33:52 -0400
Received: from smtprtp1.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.0D7657D0@standards.nortelnetworks.com>; Thu, 13 Apr 2000 16:33:52
          -0400
Received: from zcard015.ca.nortel.com (actually zcard015) by
          smtprtp1.ntcom.nortel.net; Thu, 13 Apr 2000 15:49:02 -0400
Received: from zrtpd00z.us.nortel.com ([47.140.224.110]) by
          zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id H6NPJ1YR; Thu, 13 Apr 2000 15:48:06
          -0400
Received: from americasm10.nt.com (pnc1d070.us.nortel.com [47.142.209.170]) by
          zrtpd00z.us.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id HSZ9152Y; Thu, 13 Apr 2000 15:48:05
          -0400
X-Sybari-Space: 00000000 00000000 00000000
X-Sender: "Scoggins, Sophia [NCRTP:3T18-I:EXCH]" <scoggins@zrtpd00z>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF67819C@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38F62470.34470298@americasm10.nt.com>
Date:         Thu, 13 Apr 2000 15:48:00 -0400
Reply-To: Sophia Scoggins <scoggins@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Sophia Scoggins <scoggins@NORTELNETWORKS.COM>
Organization: Nortel Inc.
Subject:      Re: MEGACO and Dial Pulse Lines
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Although the MG processes the rotary phone different from the digital
phone, the number (digits or dialed number) will be reported just the
same (the MG just tells the MGC the dialed number are XXXXXXXX...). Most
of the phone company charges extra $1+ for rotary services with digital
services and that was what most of users paid for. So, I can use either
rotary phone or digital phone at home. In either way, I can make phone
calls.

In most cases, the MGC does not know what type of the phone (digital or
rotary) is at the user end, so, the MGC will ask for scanning both digit
detection and paulse detection at the same time. When the MG receives
the scan command, it starts scaning for both types of dialed numbers and
reports whichever are detected. Because of that, a MG may choose to use
one DTMF event package for both types of phone. However, if we want to
have another dial pulse package, that will work, too.


Regards, Sophia

"Rosen, Brian" wrote:
>
> Well you are correct that there is no dial pulse package yet.
> I imagine that if there was:
>         It would assume the MG does the timing, not the MGC
>                 This means digitmaps should work, and the call flows
>                 are really close to what you would see
>         It would have properties defining the timing with some
>                 provisioned defaults
>
> Why don't you propose one along these lines!
>
> Brian
>
> > -----Original Message-----
> > From: John Donak [mailto:JDonak@catenanet.com]
> > Sent: Wednesday, April 12, 2000 4:30 PM
> > To: MEGACO@standards.nortelnetworks.com
> > Subject: MEGACO and Dial Pulse Lines
> >
> >
> > All Call Flows I have seen use DTMF for digit dialing. The MG
> > collects the
> > digits from the originator, based on the DigitMap, and then
> > contacts the
> > MGC.
> >
> > How about for Dial Pulse (Rotary) phones behind a Residential
> > Gateway? They
> > still exist.
> >
> > Is each individual onhook/offhook reported to the MGC, which
> > performs the
> > timing/collection? This seems very message intensive.
> >
> > Or is the Gateway expected to perform the timing/collection?
> > If so, how does
> > it know the required timing characteristics for the market it
> > is in; I have
> > not seen a "Dial Pulse" Package.
> >
> >
> >         Regards,
> >
> >                         John
> >
> > John Donak
> > Catena Networks
> > Voice:  (613) 599-6430 x488     Email: jdonak@catenanet.com
> > Fax:    (613) 599-6433          URL:  www.catenanet.com
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr 13 16:49:02 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13677
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 13 Apr 2000 16:49:02 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.517A7E60@standards.nortelnetworks.com>; Thu, 13 Apr 2000 16:42:55 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1662 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Apr 2000 16:41:47 -0400
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.28A3EF30@standards.nortelnetworks.com>; Thu, 13 Apr 2000
          16:41:47 -0400
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Thu, 13 Apr 2000 15:31:51 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <269WQDV9>; Thu, 13 Apr 2000 15:24:54 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFA585.393838C4"
Message-ID:  <8E2783FA4E0CD411888D0000F8CD15D33C36CC@zcard00q.ca.nortel.com>
Date:         Thu, 13 Apr 2000 15:16:57 -0500
Reply-To: Peter Blatherwick <blather@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Peter Blatherwick <blather@NORTELNETWORKS.COM>
Subject:      Re: H.248 Package Coordination
X-To:         Tom-PT Taylor <taylor@nortelnetworks.com>
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_01BFA585.393838C4
Content-Type: text/plain

Tom, list:

Not sure how or where to draw the line, but as a goal I'd like to see both
IETF and ITU publish an equivalent (preferably identical) set of "starter
kit" packages, to allow construction of useful systems for PSTN interworking
and IP communication.  Both carrier and enterprise type systems should be
considered in this list.

In terms of document structure, it would be good if IETF documents could be
easily mapped to ITU ones and visa versa.  Each IETF RFC document or H.248
Annex should contain a set of packages which logically belong together, ie
we should not publish each package as a separate document (unless a single
package really captures a complete problem space) or pile large numbers of
unrelated packages together in big documents.

I strongly agree we a need a 2-way street process, where work in either IETF
or ITU can be seen and commented on by both.  I don't much care which group
takes up which items, as long as we end up with a decently rounded starter
kit strongly standardized under both.  If it becomes obvious that some
package sets are of interest to one group and not the other, perhaps this is
an indication that the particular items do not belong in the common starter
kit.

Personally, I think the package sets currently on the table make sense for
this, including the ones already in process, those listed below and the
recent R1 and R2 packages.  (Note that, as discussed at the meeting, the
Supplemental Packages doc should be broken into smaller logical pieces for
line side and trunk side.)  We may still be missing some, for example ADSI
(?) and pulse dialling.

Maybe a lot of the above is just stating the obvious.

-- Peter Blatherwick

> -----Original Message-----
> From: Taylor, Tom-PT [CAR:B901:EXCH]
> Sent: 12 Apr, 2000 12:32
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      H.248 Package Coordination
>
> We have a number of proposed new packages in Megaco, and I'm looking for
> thoughts on the process for agreeing amongst the various interested
> parties
> about which should become Megaco work items and which should be worked
> elsewhere.  I should say that this should be a two-way street -- work
> introduced elsewhere may be something Megaco wants to get into.
>
> Currently, I suggest that interested parties take a look at the following
> drafts, all available at
> http://www.ietf.org/internet-drafts/<draft-name>
>
> draft-bouwen-megaco-isdn-00.txt
> Issues for Megaco - Sigtran Interworking in ISDN Access Gateways
>
> draft-brown-supplpkgs-00.txt
> Supplemental Packages for Megaco/H.248
>
> Very shortly these will be joined by packages having to do with R1 and R2
> signalling.  I can pass the file names along if there is interest.
>
> Tom Taylor

------_=_NextPart_001_01BFA585.393838C4
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: H.248 Package Coordination</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Tom, list:</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Not sure how or =
where to draw the line, but as a goal I'd like to see both IETF and ITU =
publish an equivalent (preferably identical) set of &quot;starter =
kit&quot; packages, to allow construction of useful systems for PSTN =
interworking and IP communication.&nbsp; Both carrier and enterprise =
type systems should be considered in this list.&nbsp; </FONT></P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">In terms of document =
structure, it would be good if IETF documents could be easily mapped to =
ITU ones and visa versa.&nbsp; Each IETF RFC document or H.248 Annex =
should contain a set of packages which logically belong together, ie we =
should not publish each package as a separate document (unless a single =
package really captures a complete problem space) or pile large numbers =
of unrelated packages together in big documents.&nbsp; </FONT></P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">I strongly agree we =
a need a 2-way street process, where work in either IETF or ITU can be =
seen and commented on by both.&nbsp; I don't much care which group =
takes up which items, as long as we end up with a decently rounded =
starter kit strongly standardized under both.&nbsp; If it becomes =
obvious that some package sets are of interest to one group and not the =
other, perhaps this is an indication that the particular items do not =
belong in the common starter kit.&nbsp; </FONT></P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Personally, I think =
the package sets currently on the table make sense for this, including =
the ones already in process, those listed below and the recent R1 and =
R2 packages.&nbsp; (Note that, as discussed at the meeting, the =
Supplemental Packages doc should be broken into smaller logical pieces =
for line side and trunk side.)&nbsp; We may still be missing some, for =
example ADSI (?) and pulse dialling.&nbsp; </FONT></P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Maybe a lot of the =
above is just stating the obvious.&nbsp; </FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">-- Peter =
Blatherwick</FONT>
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Taylor, Tom-PT [CAR:B901:EXCH] </FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">12 Apr, 2000 12:32</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">H.248 Package Coordination</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">We have a number of proposed new =
packages in Megaco, and I'm looking for</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">thoughts on the process for agreeing =
amongst the various interested parties</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">about which should become Megaco work =
items and which should be worked</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">elsewhere.&nbsp; I should say that =
this should be a two-way street -- work</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">introduced elsewhere may be something =
Megaco wants to get into.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Currently, I suggest that interested =
parties take a look at the following</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">drafts, all available at</FONT>
<BR><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://www.ietf.org/internet-drafts/" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/</A>&lt;draft-name=
</FONT></U><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">draft-bouwen-megaco-isdn-00.txt</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Issues for Megaco - Sigtran =
Interworking in ISDN Access Gateways</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">draft-brown-supplpkgs-00.txt</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Supplemental Packages for =
Megaco/H.248</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Very shortly these will be joined by =
packages having to do with R1 and R2</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">signalling.&nbsp; I can pass the file =
names along if there is interest.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Tom Taylor</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFA585.393838C4--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr 13 17:42:06 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14664
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 13 Apr 2000 17:42:06 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BC983320@standards.nortelnetworks.com>; Thu, 13 Apr 2000 17:36:01 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1741 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Apr 2000 17:35:01 -0400
Received: from smtprich.nortel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.9845CC80@standards.nortelnetworks.com>; Thu, 13 Apr 2000 17:35:00
          -0400
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprich.nortel.com; Thu, 13 Apr 2000 15:34:23 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <269WQ1DA>; Thu, 13 Apr 2000 15:29:28 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B697@zcard00g.ca.nortel.com>
Date:         Thu, 13 Apr 2000 15:29:19 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: H.248 Package Coordination
X-To:         "Michael A. Ramalho" <mramalho@cisco.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Maybe late next week.  Closing off Last Call takes first priority, I have
several sets of minutes to complete, and I have a paper to write.  That's
besides my job.

Glad to say all of my archives were recovered from my crashed hard drive.

> -----Original Message-----
> From: Michael A. Ramalho [SMTP:mramalho@cisco.com]
> Sent: Thursday, April 13, 2000 3:57 PM
> To:   Taylor, Tom-PT [CAR:B901:EXCH]; MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: H.248 Package Coordination
>
> Tom,
>
> As discussed at the Adelaide WG meeting, I assume that you are
> still working on the documentation of an agreement framework when
> packages are being worked on by IETF/Megaco and other interested
> standards bodies (i.e., the case of package overlap or the development
> of substantially similar package functionality).
>
> Any target date for a draft of that agreement framework?
>
> Michael Ramalho
>
> At 11:31 AM 4/12/00 -0500, Tom-PT Taylor wrote:
> >We have a number of proposed new packages in Megaco, and I'm looking for
> >thoughts on the process for agreeing amongst the various interested
> parties
> >about which should become Megaco work items and which should be worked
> >elsewhere.  I should say that this should be a two-way street -- work
> >introduced elsewhere may be something Megaco wants to get into.
> >
> >Currently, I suggest that interested parties take a look at the following
> >drafts, all available at
> >http://www.ietf.org/internet-drafts/<draft-name>
> >
> >draft-bouwen-megaco-isdn-00.txt
> >Issues for Megaco - Sigtran Interworking in ISDN Access Gateways
> >
> >draft-brown-supplpkgs-00.txt
> >Supplemental Packages for Megaco/H.248
> >
> >Very shortly these will be joined by packages having to do with R1 and R2
> >signalling.  I can pass the file names along if there is interest.
> >
> >Tom Taylor
> >
>
>
> Michael A. Ramalho, Ph.D.
> Cisco Systems
> 1802 Rue de la Port
> Wall Township, NJ 07719-3784
> Office email: mramalho@cisco.com
> Personal email: mar42@cornell.edu
> Office: +1.732.449.5762
> Cell: +1.732.809.0188
> Pager: +1.800.365.4578


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr 13 21:19:28 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16896
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 13 Apr 2000 21:19:28 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1BA82780@standards.nortelnetworks.com>; Thu, 13 Apr 2000 21:13:26 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2051 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Apr 2000 21:11:45 -0400
Received: from smtprtp.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.DF831EE0@standards.nortelnetworks.com>; Thu, 13 Apr 2000 21:11:45
          -0400
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          smtprtp.ntcom.nortel.net; Thu, 13 Apr 2000 21:14:29 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <27B9JFLF>; Thu, 13 Apr 2000 21:14:29 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B69A@zcard00g.ca.nortel.com>
Date:         Thu, 13 Apr 2000 21:14:25 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Questions on V16.
X-To:         Shalini Philip <sphilip@FICON-TECH.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

It doesn't look like these questions have been answered, so I'll have a go.

> -----Original Message-----
> From: Shalini Philip [SMTP:sphilip@FICON-TECH.COM]
> Sent: Wednesday, March 29, 2000 7:37 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Questions on V16.
>
> Hello all,
>
>     I have a few questions on the V16 Draft of MEGACO.
>
> 1. How does an MGC know how many streams can be created on a
> termination? Is it from the packages supported by the termination?
        [PTT]
        Good question, but I suspect the answer is that every termination
can support an arbitrary number of streams.  The number that can be
simultaneously active is another matter, and depends both on the transport
type associated with the termination and the capabilities of the MG.  This
is aside from what media types are supported.

        Multiple simultaneously active media streams on a termination
require a multiplex.  The possible types of multiplex depend on the
transport technology.

> 2. Refer to Last paragraph of Sec 7.1.7.
> A new setting of Local Control Descriptor replaces the last setting."
> Does this change the default value of ReserveGroup & ReserveValue also,
> i.e., if RG and RV are set true in one command, then in the subsequent
> command if RG and RV are not specified, then MG would take their value
> as TRUE or FALSE?
        [PTT]
        My interpretation of that troublesome "unspecified mandatory
parameters" clause in 7.1.1 is that it applies here, so ReserveGroup and
ReserveValue retain their previously-set values.  There was a suggestion
that we tabulate the list of parameters behaving like this.  Maybe the trick
is to classify the possible behaviours, then specify for each parameter at
the appropriate point in the document which class it falls into.

> 3. Refer to last paragraph of Sec 7.1.7.
> How can MG delete some information from an existing descriptor? All the
> properties in the descriptor would have some default values.
        [PTT]
        Your point is well taken; the paragraph seems to contradict 7.1.1.
We need to straighten this out, and 7.1.1 is part of the problem.

> 4. Section 7.1.8, pt (a) talks about the possibility of no previously
> specified value, in which case the descriptor is ignored in further
> processing of the command.
> How can there be "no previously specified value"? All the properties in
> Local and Remote Descriptor would have some default value.
        [PTT]
        Actually they wouldn't necessarily have any default value.  What is
the default medium?  What is the default network type?  Address?


> Thanks & Regards,
>
> Shalini Philip
> Ficon Technology
> E-Mail : mailto:sphilip@ficon-tech.com
> Web    : http://www.ficon-tech.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Apr 14 11:44:30 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09234
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 14 Apr 2000 11:44:29 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E78FC6F0@standards.nortelnetworks.com>; Fri, 14 Apr 2000 11:38:07 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2526 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Apr 2000 11:36:59 -0400
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.590C94E0@standards.nortelnetworks.com>; Fri, 14 Apr 2000 11:26:59
          -0400
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id LAA05674; Fri, 14 Apr
          2000 11:32:34 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id LAA26085; Fri, 14 Apr
          2000 11:32:38 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <2MSFWSL1>; Fri, 14 Apr 2000 11:27: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:  <4FBEA8857476D311A03300204840E1CF6781AA@whq-msgusr-02.fore.com>
Date:         Fri, 14 Apr 2000 11:32:29 -0400
Reply-To: "Rosen, Brian" <brosen@FORE.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <brosen@FORE.COM>
Subject:      Re: an ephemeral Termination and the null Context
X-To:         FURUKAWA Satoru <furukawa.satoru@LAB.NTT.CO.JP>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

> Hi,
>
> Does it allowed to Add an ephemeral Termination to the null Context ?
> My understanding is that the Addition is not prohibitted explicitly
> but I really wonder whether the semantic validity of that has been
> recognized.
I would say, NO, it is NOT permitted to Add any termination to the
Null context.  I'd actually permit a move of a physical termination,
since that is what Subtract does, but if we decided to make that an
error for consistency, I wouldn't scream.


> I would like to create an new ephemeral Termination Adding to the null
> Context, Modify it in order to provide some LocalDescriptors (VPI/VCI,
> etc.), and then Move it to another 'real' Context, which other
> Terminations have been already added to.
You should create a context, adding the termination to it.  When you
want to, Move the termination to the "real context".  The temporary
context, now having zero terminations, will be deleted.

>
> A real Context instead of the null Context may bring same results but
> I feel like doing without it if possible.
Nevertheless, I believe that is the correct way.  I do not understand
why you would think that it would not be the best way.

Brian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Apr 14 11:46:51 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09270
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 14 Apr 2000 11:46:50 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.30832960@standards.nortelnetworks.com>; Fri, 14 Apr 2000 11:40:10 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2527 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Apr 2000 11:39:47 -0400
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.BD6D4C40@standards.nortelnetworks.com>; Fri, 14 Apr 2000 11:29:47
          -0400
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id LAA05970; Fri, 14 Apr
          2000 11:35:26 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id LAA26770; Fri, 14 Apr
          2000 11:35:30 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <2MSFWS3A>; Fri, 14 Apr 2000 11:30: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:  <4FBEA8857476D311A03300204840E1CF6781AB@whq-msgusr-02.fore.com>
Date:         Fri, 14 Apr 2000 11:35:24 -0400
Reply-To: "Rosen, Brian" <brosen@FORE.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <brosen@FORE.COM>
Subject:      Re: Transaction ID NULL
X-To:         J Ramachandra <JRamachandra@axestech.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

> Section 8.2.2 Transaction Reply, specifies
> "If the receiver encounters an error such that it cannot determine a
> legal Transaction, it will return a TransactionReply with a null
> TransactionID and a single error descriptor (403 Syntax Error in
> Transaction)".
>
> What is null TransactionID?
> Is it 0 ?  e.g. Reply=0 {Error=403{error string} }
> OR is it like Reply= {Error=403{error string}}?
> As per ABNF, second one results in syntax error.
>
> If it is 0, one is not expected to use transaction ID 0 for a valid
> transaction request? (MGCP Implementation Guide by International
> Softswitch Consortium suggests this for MGCP). If one uses it, how to
> identify whether it is the Reply received for transaction Request 0
> or an error response for one of your requests?
I think we SHOULD do what MGCP does, reserve 0, and use it for this
purpose.  I would prefer NOT to change the ABNF to allow an omitted
TransactionID -- I would prefer the scanner generate an error for this.

> Finally,what purpose it serves to receive a reply like this, when you
> can not determine for which transaction this reply is? Why not ignore
> such a transaction Request, instead of sending an error Reply?
Because the entity that sent the request is looking for a reply.
When it gets no reply, it will retry.  After it retries a number of
times, it might believe the link is down, or the other side is broken.
An error message is a much better answer.


Brian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Apr 14 14:46:07 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12852
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 14 Apr 2000 14:46:07 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4F680F80@standards.nortelnetworks.com>; Fri, 14 Apr 2000 14:39:59 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3120 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Apr 2000 14:38:07 -0400
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.A6B20450@standards.nortelnetworks.com>; Fri, 14 Apr 2000 14:28:07
          -0400
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id OAA24272; Fri, 14 Apr
          2000 14:33:46 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id OAA06016; Fri, 14 Apr
          2000 14:33:49 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <2MSFWW8R>; Fri, 14 Apr 2000 14:28:42 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF6781AF@whq-msgusr-02.fore.com>
Date:         Fri, 14 Apr 2000 14:33:45 -0400
Reply-To: "Rosen, Brian" <brosen@FORE.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <brosen@FORE.COM>
Subject:      Re: Multiple streams per call,
X-To:         Thomas LEVY <thomas.levy@MS.ALCATEL.FR>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

> Megaco supports multiple media streams per termination => so
> 1 call (or
> conference) with multiple streams may corresponds to 1 context viewed
> from a media gateway.
We have been very careful to not associate a "context" with a "call".
In particular, depending on how you want to look at the definition of
a call, a context could be less than a call, or more than one call.

A context supports more than one termination, and more than one
media stream.

> The reciprocal is not so clear to me: MUST all the media
> streams from 1
> call be associated to 1 context.
No, but you might have some difficulty with interoperability if you
built a gateway that assumed each stream was, for example, on a
separate termination.  The protocol would allow you to do this.
I suspect no package describing a multimedia termination would do so.

> In other term, is there a "one for one" relationship between
> Context and
> Call?
> In fact, I think no.
And we agree.

> I was thinking about a case where terminal A and terminal B are trying
> to establish an Audio/Video (with separate streams) call. But as audio
> encoding supported by A and B are compatible, video encoding are not
> compatible thus requiring the transcoding function of the
> media gateway
> MG1. In such case, I think that the MGC should control the
> audio stream
> in order to go from A to B directly, while video stream go from A to B
> via MG1.
> Does it seem to you to be a scenario in the scope of Megaco?
> Comments welcome,
Sure.  Look at it from the point of view of the MGs.  You have MG-A,
MG-B and MG1.  MG-A has a termination with two streams, video and
audio.  It is commanded by the MGC to set up a single context with
the termination and two RTP connections, call them RTP-A-Audio and
RTP-A-Video.  The address it assigns to RTP-A-Audio is MG-B.
The address it assigns RTP-A-Video is MG1.
Again, this is a single context, with the physical termination
having two streams, and each of the RTP terminations having one
stream each.

Look at MG1.  It has two terminations, with one stream each.  It
is asked to set up two contexts, one with an RTP connecting to
MG-A and the other with its RTP connection to MG-B.  That's
two contexts, each with two terminations, with one stream in
each of the contexts.

Of course, MG-B has a similar setup to MG-A -- it's audio connects
to MG-A, the video connects to MG1.

Now look at it from the MGC.  The "call" has 3 Megaco contexts.
The MG-A to MG-B audio, the MG-A to MG1 video and the MG1 to MG-B
video.

I'm still not thrilled with the whole stream idea, but it does work.

Brian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Apr 14 14:48:13 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12894
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 14 Apr 2000 14:48:13 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.98413330@standards.nortelnetworks.com>; Fri, 14 Apr 2000 14:42:01 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3121 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Apr 2000 14:41:32 -0400
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.214912D0@standards.nortelnetworks.com>; Fri, 14 Apr 2000 14:31:32
          -0400
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id OAA24608; Fri, 14 Apr
          2000 14:37:08 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id OAA06838; Fri, 14 Apr
          2000 14:37:12 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <2MSFWXA9>; Fri, 14 Apr 2000 14:32: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:  <4FBEA8857476D311A03300204840E1CF6781B1@whq-msgusr-02.fore.com>
Date:         Fri, 14 Apr 2000 14:37:07 -0400
Reply-To: "Rosen, Brian" <brosen@FORE.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <brosen@FORE.COM>
Subject:      Re: MEGACO and Dial Pulse Lines
X-To:         John Donak <JDonak@catenanet.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

> I agree with George, since POTS transparency is key.
>
> It appears that a "Dial pulse" package is needed to inform
> the MG of the
> dial pulse characteristics (PPS, Make/Break Ratio). What else?
>
> What is the process for creating such a package? Can anyone
> create an IETF
> draft?
>
Anyone can create a DRAFT.  Just write it up in the proper format
and email it to the Internet Drafts editor.

Now, if you want IETF to DO anything with it, some working group
(for example, Megaco) has to adopt it as a work item, and agree
to turn it into an rfc (through it's consensus process).  I'd
suspect we would be willing to do this for a dial pulse package,
but that is up to the group to decide.

Brian
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Apr 14 15:14:16 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13216
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 14 Apr 2000 15:14:16 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3D565F00@standards.nortelnetworks.com>; Fri, 14 Apr 2000 15:08:07 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3182 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Apr 2000 15:06:24 -0400
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.9A5F6D60@standards.nortelnetworks.com>; Fri, 14 Apr 2000 14:56:24
          -0400
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id PAA27255 for
          <MEGACO@standards.nortelnetworks.com>; Fri, 14 Apr 2000 15:02:03
          -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id PAA12224 for
          <MEGACO@standards.nortelnetworks.com>; Fri, 14 Apr 2000 15:02:07
          -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <2MSFWX4F>; Fri, 14 Apr 2000 14:57: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:  <4FBEA8857476D311A03300204840E1CF6781B3@whq-msgusr-02.fore.com>
Date:         Fri, 14 Apr 2000 15:02:01 -0400
Reply-To: "Rosen, Brian" <brosen@FORE.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <brosen@FORE.COM>
Subject:      Re: MEGACO and Dial Pulse Lines
X-To:         "Brown, David" <david.k.brown@na.marconicomms.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I would think the DP Package would permit a lot of things,
how the MGC chose to use them would be up to it.

Certainly, as has been suggested, an MG implementing DP Package
should be able to recognize digits, distinguishing them from flash
and hook state, and be able to create events the same as,
or equivalent to, DTMF digit detection, including digit maps.

Issues like allowing mixed DP/DTMF is the province of the MGC,
not the MG, and should be supported, but not required in Megaco.

Brian

> -----Original Message-----
> From: Brown, David
> Sent: Thursday, April 13, 2000 11:24 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: MEGACO and Dial Pulse Lines
>
>
> Based on experience with CO development from years gone by:
>
> It seems to me that there is a general issue here, that being
> whether the
> MEGACO model is focusing on: 1) replicating current capabilities or 2)
> opening the door to utilize legacy resources to access
> enhanced services in
> an improved fashion.  As I understand, option 2 is the
> intention, whether
> it is stated or not, I am not sure.
>
> In either case, it is necessary to distinguish the stage or
> state of the
> call to determine whether detection of DTMF tones on a DP
> subscriber port
> represents a violation of contract.  Commonly (at least in
> the CO specs I
> designed to X years ago), tone enabled subscribers could use
> tone or pulse
> phones, however, if a pulse were received first, DTMF tones
> that appear
> during the called number digit collection process were ignored.  Older
> switches also switched tone detectors in order to share them between
> subscribers (this is why tone service was allowed to be
> tariffed higher -
> telcos have been careful to preserve this free profit even though DP
> actually should cost more today since tone detectors are on
> line cards and
> DP is done in software and is always a pain).
>
> All of the forgoing history has a purpose in my questions
> vis: will MEGACO
> permit mixed DP and tone dialing? and will MEGACO convert DP after
> connection into tone codes to facilitate use of DP phones in customer
> convenience services such as IVR?  could this actually simplify the
> interaction model?  The question of recognizing flash to
> support service
> initiation rises up again here.  Also, the conventional
> re-originate code
> (1 sec of "#"  tone) would probably need to be translated to
> something else
> for DP phones.
>
> Dave Brown
> Systems Engineering, Marconi Communications
> 8616 Freeport Pkwy
> Irving TX 75063
> (972)916-4787
> david.k.brown@na.marconicomms.com
>
>
>
>
>
> John Donak <JDonak@CATENANET.COM> on 04/13/2000 08:28:06 AM
>
> Please respond to John Donak <JDonak@CATENANET.COM>
>
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> cc:    (bcc: David K Brown/MAIN/MC1)
>
> Subject:  Re: MEGACO and Dial Pulse Lines
>
>
>
> I agree with George, since POTS transparency is key.
>
> It appears that a "Dial pulse" package is needed to inform
> the MG of the
> dial pulse characteristics (PPS, Make/Break Ratio). What else?
>
> What is the process for creating such a package? Can anyone
> create an IETF
> draft?
>
>
>                 John
>
>
> -----Original Message-----
> From: Glasgow, George [mailto:gGlasgow@UNISPHERESOLUTIONS.COM]
> Sent: Wednesday, April 12, 2000 6:01 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: MEGACO and Dial Pulse Lines
>
>
> Mike,
> Typically a class 5 switch will use the same dial plan for
> rotary and DTMF.
> Of course dial-pulse phones can't dial "*" or "#", so their
> access codes
> are
> typically preceded by "11". There is nothing to prevent a
> DTMF subscriber
> also using "11" instead of the "*" or "#". The main difference between
> dial-pulse and DTMF is usually at the line interface, which is
> programmable.
> Also, dial-pulse subscribers pay a lower line rental for some obscure
> reason.
>
> So, a dial-pulse subscriber is provisioned as such via MML,
> and this in
> turn
> leads to the line interface being programmed accordingly.
>
> When a dial-pulse subscriber dials, the line interface
> circuitry handles
> the
> dial pulse timing and, hence, digit detection. Once a digit has been
> dialed,
> the digit info is then passed on for further processing in the switch.
>
> Note that dial-pulse subscribers can actually connect DTMF
> phones to their
> lines, but if they use them, then the switch will detect that they are
> using
> DTMF on a dial-pulse provisioned port. This is flagged at the
> switch as a
> "DTMF violation". As mentioned, since dial-pulse subscribers
> typically pay
> a
> lower line rental cost, flagging this allows the switch
> operator to recover
> potential lost revenue.
>
> With respect to the discussion, I agree with the MG handling
> the dial-pulse
> timing, but it must also be able to detect DTMF even though
> dial-pulse is
> provisioned. I expect that we will have to do this to remain
> transparent
> with existing class 5 switches. I hope that we can utilize
> the same digit
> map for both.
>
> Regards,
>
> George Glasgow
> Senior Engineer - SRX-3000 Development
> Unisphere Solutions,
> 900 Broken Sound Parkway, B12S,
> Boca Raton, FL 33487,
> USA
> 1-561-955-6555 Voice
> 1-561-955-6477 Fax
>
> gglasgow@unispheresolutions.com
> <mailto:gglasgow@unispheresolutions.com>
>
>
> Visit us on the web at: http://www.unispheresolutions.com
>
>
>
>
>
> -----Original Message-----
> From: Michael Thomas [mailto:mat@CISCO.COM]
> Sent: Wednesday, April 12, 2000 5:39 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: MEGACO and Dial Pulse Lines
>
>
> Having the MG do the digit collection even for
> pulse seems completely reasonable. If I recall
> correctly, the only difference between pulse and
> DTMF is that the switch has a different dial plan
> for pulse phones vs. DTMF phones. I don't know
> whether that's a statically provisioned thing
> within the switch's profile for the line, or
> whether it dynamically determines whether it's
> a rotary phone given the first pulse dial
> digit it sees for the call.
>
> If it's the former, I don't think you need any
> difference in digit packages at all. If it's the
> latter, the MGC would need to differentiate pulse
> from DTMF and send down a different digit map
> once it can decide.
>
> I hope it's the former. The latter is a whole lot
> of work for not much gain.
>
>         Mike
>
> Rosen, Brian writes:
>  > Well you are correct that there is no dial pulse package yet.
>  > I imagine that if there was:
>  >         It would assume the MG does the timing, not the MGC
>  >                 This means digitmaps should work, and the
> call flows
>  >                 are really close to what you would see
>  >         It would have properties defining the timing with some
>  >                 provisioned defaults
>  >
>  > Why don't you propose one along these lines!
>  >
>  > Brian
>  >
>  >
>  > > -----Original Message-----
>  > > From: John Donak [mailto:JDonak@catenanet.com]
>  > > Sent: Wednesday, April 12, 2000 4:30 PM
>  > > To: MEGACO@standards.nortelnetworks.com
>  > > Subject: MEGACO and Dial Pulse Lines
>  > >
>  > >
>  > > All Call Flows I have seen use DTMF for digit dialing. The MG
>  > > collects the
>  > > digits from the originator, based on the DigitMap, and then
>  > > contacts the
>  > > MGC.
>  > >
>  > > How about for Dial Pulse (Rotary) phones behind a Residential
>  > > Gateway? They
>  > > still exist.
>  > >
>  > > Is each individual onhook/offhook reported to the MGC, which
>  > > performs the
>  > > timing/collection? This seems very message intensive.
>  > >
>  > > Or is the Gateway expected to perform the timing/collection?
>  > > If so, how does
>  > > it know the required timing characteristics for the market it
>  > > is in; I have
>  > > not seen a "Dial Pulse" Package.
>  > >
>  > >
>  > >         Regards,
>  > >
>  > >                         John
>  > >
>  > > John Donak
>  > > Catena Networks
>  > > Voice:  (613) 599-6430 x488     Email: jdonak@catenanet.com
>  > > Fax:    (613) 599-6433          URL:  www.catenanet.com
>  > >
>  >
>  >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Apr 14 15:36:11 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13409
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 14 Apr 2000 15:36:11 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.52A6E2A0@standards.nortelnetworks.com>; Fri, 14 Apr 2000 15:30:11 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3229 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Apr 2000 15:28:16 -0400
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.A869E950@standards.nortelnetworks.com>; Fri, 14 Apr 2000 15:18:16
          -0400
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id PAA29561; Fri, 14 Apr
          2000 15:23:55 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id PAA16869; Fri, 14 Apr
          2000 15:23:59 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <2MSFWY1Z>; Fri, 14 Apr 2000 15:18:52 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF6781B5@whq-msgusr-02.fore.com>
Date:         Fri, 14 Apr 2000 15:23:50 -0400
Reply-To: "Rosen, Brian" <brosen@FORE.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <brosen@FORE.COM>
Subject:      Re: Open Issue: When Side Effects Of Events Are Executed
X-To:         Tom-PT Taylor <taylor@nortelnetworks.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

> We have an open issue on when the side effects of events
> happen.  Here are
> the possibilities:
>
> (a) when an event is detected.  Problem: "detection" in my
> mental model, at
> least, is something that happens at the hardware level possibly
> independently of the current content of the eventsDescriptor.
>  Thus the MGC
> would have no control over which events cause signals to stop.
I agree that there is a difference between detecting the event,
and some of the processing of it, in particular, notification.

The event buffer mechanism decouples detection from notification.
The question you are asking is, do side effects like stopping
signals happen on detection, or on notification?

>
> (b) when the event is recognized as being of interest because
> it is in the
> eventsDescriptor (event buffering inactive) or is in the
> eventBufferDescriptor (event buffering active).  Potential
> problems: events
> may cause side effects but never get reported.  There are two
> cases: if the
> event is processed against a digit map, is rejected as an
> "extra digit", but
> gets thrown away because it is not in the eventsDescriptor
> activated by the
> digit map completion event,  or if the event buffer is
> cleared by a change
> of the control mode.
If you are in "notify immediate" mode, then the event buffer
tells you what events to detect, and side effects should happen
on detection.  The only difference between detection and notification
is other pending activity and queuing.  I would want signal stopping,
for example, to happen "fast"

If you are in "lock step" mode, then you do have a complete decoupling
of detection from notification, but you do have a list of "potentially"
interesting events - eventBuffer descriptor.  The problem you are
worried about is an event in the eventBuffer descriptor (potentially
interesting) but not in eventsDescriptor (really interesting) when
that event is actually processed.

I would agree that it is not acceptable to have side effects without
the MGC being able to predict the state of the MG -- this is the
whole point of lock-step.  So, I would say side effects happen when
the event is processed out of the eventBuffer through the events
Descriptor.

>
> (c) This leaves the third possibility: events generate their
> side effects
> when they are either notified or accepted into the current
> dial string of an
> active digit map.
See above


Brian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Apr 14 15:42:16 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13446
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 14 Apr 2000 15:42:15 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2B2A6FC0@standards.nortelnetworks.com>; Fri, 14 Apr 2000 15:36:14 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3233 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Apr 2000 15:34:59 -0400
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.9860BA60@standards.nortelnetworks.com>; Fri, 14 Apr 2000 15:24:59
          -0400
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id PAA00190; Fri, 14 Apr
          2000 15:30:37 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id PAA18149; Fri, 14 Apr
          2000 15:30:41 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <2MSFWYJ4>; Fri, 14 Apr 2000 15:25: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:  <4FBEA8857476D311A03300204840E1CF6781B6@whq-msgusr-02.fore.com>
Date:         Fri, 14 Apr 2000 15:30:36 -0400
Reply-To: "Rosen, Brian" <brosen@FORE.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <brosen@FORE.COM>
Subject:      Re: Questions on V16.
X-To:         Tom-PT Taylor <taylor@nortelnetworks.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

> > Hello all,
> >
> >     I have a few questions on the V16 Draft of MEGACO.
> >
> > 1. How does an MGC know how many streams can be created on a
> > termination? Is it from the packages supported by the termination?
>         [PTT]
>         Good question, but I suspect the answer is that every
> termination
> can support an arbitrary number of streams.  The number that can be
> simultaneously active is another matter, and depends both on
> the transport
> type associated with the termination and the capabilities of
> the MG.  This
> is aside from what media types are supported.

You can certainly audit a termination and find out!

I don't really agree that a termination can support an arbitrary
number of streams.  That would be a big burden on an MG implementation.
I suspect rather that it is strictly a function of the capability of
the "physical" terminations.  Now, streamID should be arbitrary, so
if an audio termination had 5 channels of sound, which stream is what
ID should be arbitrary.  Might want to have a reasonable default for
the default audio (=1) stream.

Now, a real interesting question is whether there are circumstances where an
ephemeral termination actually has more than one stream.  For RTP,
the answer is No.  In fact, so far, I can't think of a case where
it is possible.  I see no reason to legislate that however.


>
>         Multiple simultaneously active media streams on a termination
> require a multiplex.  The possible types of multiplex depend on the
> transport technology.
>
> > 2. Refer to Last paragraph of Sec 7.1.7.
> > A new setting of Local Control Descriptor replaces the last
> setting."
> > Does this change the default value of ReserveGroup &
> ReserveValue also,
> > i.e., if RG and RV are set true in one command, then in the
> subsequent
> > command if RG and RV are not specified, then MG would take
> their value
> > as TRUE or FALSE?
>         [PTT]
>         My interpretation of that troublesome "unspecified mandatory
> parameters" clause in 7.1.1 is that it applies here, so
> ReserveGroup and
> ReserveValue retain their previously-set values.
I agree

> There was a  suggestion
> that we tabulate the list of parameters behaving like this.
> Maybe the trick
> is to classify the possible behaviours, then specify for each
> parameter at
> the appropriate point in the document which class it falls into.
>
> > 3. Refer to last paragraph of Sec 7.1.7.
> > How can MG delete some information from an existing
> descriptor? All the
> > properties in the descriptor would have some default values.
>         [PTT]
>         Your point is well taken; the paragraph seems to
> contradict 7.1.1.
> We need to straighten this out, and 7.1.1 is part of the problem.
>
> > 4. Section 7.1.8, pt (a) talks about the possibility of no
> previously
> > specified value, in which case the descriptor is ignored in further
> > processing of the command.
> > How can there be "no previously specified value"? All the
> properties in
> > Local and Remote Descriptor would have some default value.
>         [PTT]
>         Actually they wouldn't necessarily have any default
> value.  What is
> the default medium?  What is the default network type?  Address?
>
>
> > Thanks & Regards,
> >
> > Shalini Philip
> > Ficon Technology
> > E-Mail : mailto:sphilip@ficon-tech.com
> > Web    : http://www.ficon-tech.com
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Apr 14 16:08:33 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13774
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 14 Apr 2000 16:08:32 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D3715380@standards.nortelnetworks.com>; Fri, 14 Apr 2000 16:02:25 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3315 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Apr 2000 16:01:48 -0400
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.576F86E0@standards.nortelnetworks.com>; Fri, 14 Apr 2000 15:51:48
          -0400
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id PAA02789; Fri, 14 Apr
          2000 15:57:21 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id PAA23935; Fri, 14 Apr
          2000 15:57:25 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <2MSFWY05>; Fri, 14 Apr 2000 15:52:18 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFA64A.F043ED7C"
Message-ID:  <4FBEA8857476D311A03300204840E1CF6781B7@whq-msgusr-02.fore.com>
Date:         Fri, 14 Apr 2000 15:57:21 -0400
Reply-To: "Rosen, Brian" <brosen@FORE.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <brosen@FORE.COM>
Subject:      Re: Command Atomicity and Rollback
X-To:         Hemant <hkumar@ficon-tech.com>
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_01BFA64A.F043ED7C
Content-Type: text/plain;
        charset="iso-8859-1"

I've had this argument many times before, and always lost it, I think to the
determent of
both the protocol, and the resulting system.

First of all, you can't audit to find out the state of an MG to the level of
what happened on
a broken command without a pretty major amount of code.  I think it is
possible, but I think
it's hard.   There is transient state you would not reasonably be able to
figure out - a short
BRief signal, for example.

It is quite straightforward to build an MG to have "rollback" semantics,
even at the transaction
level.  It requires that you construct the code so that errors are
detectable before state is
changed, rather than after.  This is always possible - we only argue about
how hard it is.
It is also always possible to put state back, but I agree that it is
sometimes hard.

Certainly, at the level of a command:
    You should be parsing the whole command before executing any of it
    You should be checking availability of resources either simultaneously,
or
        prior to reserving them
    It should be straightforward to do all of the above before actually
doing state
        changes (reserving resources not counted as "state change")
    There are VERY few non-fatal errors that are not detected by the above,
that
        would cause a rollback problem.  Might be a couple, but special
casing them
        should not be very hard.

I believe that MGC out of sync with MG is a very bad problem
Audit to determine state at the level of a descriptor in a command is very
hard
Avoiding state change before determining almost all errors is pretty easy
Fixing the few cases where it isn't possible to determine the error is not
very hard.

I'll agree that it is harder to design MG code that does this, compared to
an MG that doesn't
care a whit what the MGC has to do to figure out what state it is in.

I don't think there are any cases where "roll back" doesn't make sense.  You
cited:
    Signals - if the command has an error, I don't want signals specified in
an earlier
        descriptor sent.  I want the whole command to fail
    Events - if the command has an error, I don't want events in a new
events descriptor
        to be detected - I want the old events descriptor to be active

You specifically raised the issue of embedded signals or events.  If the
syntax of the
descriptors is wrong, then that should be detected with the original
command.  Otherwise,
the detection has to be when the first event is detected, and the embedded
event is
activated.  If it fails, the prior signals and events descriptors should be
"restored".  Of course,
I would say they were never changed if there were, for example, insufficient
resources
available for the embedded events following detection of the original event.

I believe that there are many "recoverable" errors.  If there weren't, then
we should make
errors fatal, and specify that contexts are taken down, terminations set to
default state, etc.
Without the MGC knowing the MG state, recovery is very difficult.

Brian

-----Original Message-----
From: Hemant [mailto:hkumar@ficon-tech.com]
Sent: Thursday, April 13, 2000 12:18 AM
To: MEGACO@standards.nortelnetworks.com
Subject: Command Atomicity and Rollback


Hi everyone,

    The discussions till date on the issue of rollback of command in case of
its failure do not seem to lead to a clear consensus. Lets look at the issue
from the point of view of both the MG as well as the MGC.

    From an MG point of view, the MG will always have to maintain duplicate
state information. One of the current state (after execution of descriptor)
and another for what existed previous to it while executing the command.
This would be a lot of overhead in terms of memory and implementation
complexity. Also there might cases where rollback doesn't make sense
(signals, event detection etc). Another clarification required is whether
commands with embedded events and signals also be considered atomic? (in
case the embedded signal or event encounters error, what will the MG
rollback to)

     As far as the MGC is concerned, it wants to know the status of the
termination on which command was executed. This can be determined by
Auditing the termination.
    Another MGC concern may be that since the command can fail at any point,
one would think that without rollback implementation, the MGC handling
following a failed command would be very complex. The typical action of the
MGC however in such cases is to follow up with an error treatment(like
playing an error tone or taking the termination out of context or allocating
some other termination etc). Will going back to the previous status really
help the MGC implementation ? If the reason for rollback is to bring the
termination into a state known to the MGC, it can be achieved by auditing
the termination upon receiving the error response.

    Considering the above I would favour that rollback not be mandatory.
Instead on encountering an error, the MG should stop further command
processing.

Any Comments ??

Regards,
Hemant
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hemant Kumar
Ficon Technology
E-mail: mailto:hkumar@ficon-tech.com <mailto:hkumar@ficon-tech.com>
Web: http://www.ficon-tech.com <http://www.ficon-tech.com>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~



------_=_NextPart_001_01BFA64A.F043ED7C
Content-Type: text/html;
        charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.2919.6307" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560444019-14042000>I've
had this argument many times before, and always lost it, I think to the
determent of</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560444019-14042000>both
the protocol, and the resulting system.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=560444019-14042000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560444019-14042000>First
of all, you can't audit to find out the state of an MG to the level of what
happened on</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560444019-14042000>a
broken command without a pretty major amount of code.&nbsp; I think it is
possible, but I think</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560444019-14042000>it's
hard.&nbsp;&nbsp; There is transient state you would not reasonably be able to
figure out - a short</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560444019-14042000>BRief
signal, for example.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=560444019-14042000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560444019-14042000>It is
quite straightforward to build an MG to have "rollback" semantics, even at the
transaction</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=560444019-14042000>level.&nbsp; It requires that you construct the code so
that errors are detectable before state is</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=560444019-14042000>changed, rather than after.&nbsp; This is always
possible - we only argue about how hard it is.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560444019-14042000>It is
also always possible to put state back, but I agree that it is sometimes
hard.&nbsp; </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=560444019-14042000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=560444019-14042000>Certainly, at the level of a
command:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=560444019-14042000>&nbsp;&nbsp;&nbsp; You should be parsing the whole
command before executing any of it</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=560444019-14042000>&nbsp;&nbsp;&nbsp; You should be checking availability
of resources either simultaneously, or</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=560444019-14042000>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; prior to
reserving them</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=560444019-14042000>&nbsp;&nbsp;&nbsp; It should be straightforward to do
all of the above before actually doing state</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=560444019-14042000>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; changes
(reserving resources not counted as "state change")</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=560444019-14042000>&nbsp;&nbsp;&nbsp; There are VERY few non-fatal errors
that are not detected by the above, that </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=560444019-14042000>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; would cause
a rollback problem.&nbsp; Might be a couple, but special casing
them</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=560444019-14042000>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; should not
be very hard.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=560444019-14042000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560444019-14042000>I
believe that MGC out of sync with MG is a very bad problem</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560444019-14042000>Audit
to determine state at the level of a descriptor in a command is very
hard</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=560444019-14042000>Avoiding state change before determining almost all
errors is pretty easy</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560444019-14042000>Fixing
the few cases where it isn't possible to determine the error is not very
hard.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=560444019-14042000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560444019-14042000>I'll
agree that it is harder to design MG code that does this, compared to an MG that
doesn't</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560444019-14042000>care a
whit what the MGC has to do to figure out what state it is
in.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=560444019-14042000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560444019-14042000>I
don't think there are any cases where "roll back" doesn't make sense.&nbsp; You
cited:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=560444019-14042000>&nbsp;&nbsp;&nbsp; Signals - if the command has an
error, I don't want signals specified in an earlier</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=560444019-14042000>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; descriptor
sent.&nbsp; I want the whole command to fail</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=560444019-14042000>&nbsp;&nbsp;&nbsp; Events - if the command has an
error, I don't want events in a new events descriptor</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=560444019-14042000>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to be
detected - I want the old events descriptor to be active</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=560444019-14042000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560444019-14042000>You
specifically raised the issue of embedded signals or events.&nbsp; If the syntax
of the</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=560444019-14042000>descriptors is wrong, then that should be detected with
the original command.&nbsp; Otherwise,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560444019-14042000>the
detection has to be when the first event is detected, and the embedded event
is</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=560444019-14042000>activated.&nbsp; If it fails, the prior signals and
events descriptors should be "restored".&nbsp; Of course,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560444019-14042000>I
would say they were never changed if there were, for example, insufficient
resources</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=560444019-14042000>available for the embedded events following detection
of the original event.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=560444019-14042000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560444019-14042000>I
believe that there are many "recoverable" errors.&nbsp; If there weren't, then
we should make</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560444019-14042000>errors
fatal, and specify that contexts are taken down, terminations set to default
state, etc.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=560444019-14042000>Without the MGC knowing the MG state, recovery is very
difficult.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=560444019-14042000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=560444019-14042000>Brian</SPAN></FONT></DIV>
<BLOCKQUOTE
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma
  size=2>-----Original Message-----<BR><B>From:</B> Hemant
  [mailto:hkumar@ficon-tech.com]<BR><B>Sent:</B> Thursday, April 13, 2000 12:18
  AM<BR><B>To:</B> MEGACO@standards.nortelnetworks.com<BR><B>Subject:</B>
  Command Atomicity and Rollback<BR><BR></DIV></FONT>
  <DIV><FONT face=Arial size=2><FONT face=Arial><FONT size=-1>Hi
  everyone,</FONT></FONT></FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>&nbsp;&nbsp;&nbsp; The discussions till date on
  the issue of rollback of command in case of its failure do not seem to lead to
  a clear consensus. Lets look at the issue from the point of view of both the
  MG as well as the MGC.&nbsp;<FONT face=Arial><FONT size=-1>&nbsp;&nbsp;&nbsp;
  </FONT></FONT></DIV>
  <DIV><FONT face=Arial><FONT size=-1></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial><FONT size=-1>&nbsp;&nbsp;&nbsp; From an MG point of
  view, the MG will always have to maintain duplicate state information. One of
  the current state (after execution of descriptor) and another for what existed
  previous to it while executing the command. This would be a lot of overhead in
  terms of memory and implementation complexity. Also there might cases where
  rollback doesn't make sense (signals, event detection etc). Another
  clarification required is whether commands with embedded events and signals
  also be considered atomic? (in case the embedded signal or event encounters
  error, what will the MG rollback to)</FONT></FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;<FONT face=Arial><FONT size=-1>&nbsp;&nbsp;&nbsp; As far as the MGC
  is concerned, it wants to know the status of the termination on which command
  was executed. This can be determined by Auditing the
  termination.</FONT></FONT></DIV>
  <DIV><FONT face=Arial><FONT size=-1>&nbsp;&nbsp;&nbsp; Another MGC concern may
  be that since the command can fail at any point, one would think that without
  rollback implementation, the MGC handling following a failed command would be
  very complex. The typical action of the MGC however in such cases is to follow
  up with an error treatment(like playing an error tone or taking the
  termination out of context or allocating some other termination etc). Will
  going back to the previous status really help the MGC implementation
  ?</FONT></FONT><FONT face=Arial><FONT size=-1> If the reason for rollback is
  to bring the termination into a state known to the MGC, it can be achieved by
  auditing the termination upon receiving the error
response.</FONT></FONT></DIV>
  <DIV><FONT face=Arial><FONT size=-1></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial><FONT size=-1>&nbsp;&nbsp;&nbsp; Considering the above I
  would favour that rollback not be mandatory. Instead on encountering an error,
  the MG should stop further command processing.</FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial><FONT size=-1></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial><FONT size=-1>Any Comments ??</FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial><FONT size=-1></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial><FONT size=-1>Regards,</FONT></FONT><FONT
  face=Arial><FONT size=-1></FONT></FONT></DIV>
  <DIV><FONT face=Arial><FONT size=-1>Hemant</FONT></FONT>&nbsp;<FONT
  face=Arial><FONT size=-1></FONT></FONT></DIV></FONT>
  <DIV><FONT face=Arial size=2>~~~~~~~~~~~~~~~~~~~~~~~~~~~~<BR>Hemant
  Kumar<BR>Ficon Technology<BR>E-mail: <A
  href="mailto:hkumar@ficon-tech.com">mailto:hkumar@ficon-tech.com</A><BR>Web:
  <A
  href="http://www.ficon-tech.com">http://www.ficon-tech.com</A><BR>~~~~~~~~~~~~~~~~~~~~~~~~~~~~<BR></FONT></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01BFA64A.F043ED7C--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Apr 14 16:12:29 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13859
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 14 Apr 2000 16:12:28 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.64923050@standards.nortelnetworks.com>; Fri, 14 Apr 2000 16:06:29 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3438 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Apr 2000 16:04:40 -0400
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.2392EFE0@standards.nortelnetworks.com>; Fri, 14 Apr 2000 16:04:40
          -0400
Received: from chsharp-tecra.cisco.com (chsharp-isdn.cisco.com
          [171.68.116.221]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2)
          with ESMTP id NAA11823; Fri, 14 Apr 2000 13:10:17 -0700 (PDT)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.3.1.2.20000414152801.00b4dc10@dogwood.cisco.com>
Date:         Fri, 14 Apr 2000 15:58:28 -0400
Reply-To: Chip Sharp <chsharp@CISCO.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chip Sharp <chsharp@CISCO.COM>
Subject:      Re: Multiple streams per call,
X-To:         "Rosen, Brian" <brosen@FORE.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <4FBEA8857476D311A03300204840E1CF6781AF@whq-msgusr-02.fore. com>

At 02:33 PM 4/14/00 -0400, Rosen, Brian wrote:

...snip...

>Sure.  Look at it from the point of view of the MGs.  You have MG-A,
>MG-B and MG1.  MG-A has a termination with two streams, video and
>audio.  It is commanded by the MGC to set up a single context with
>the termination and two RTP connections, call them RTP-A-Audio and
>RTP-A-Video.  The address it assigns to RTP-A-Audio is MG-B.
>The address it assigns RTP-A-Video is MG1.
>Again, this is a single context, with the physical termination
>having two streams, and each of the RTP terminations having one
>stream each.

I assume when you say "RTP connections" above, you mean "RTP terminations"
since the word "connection" isn't allowed in megaco. (your MGCP is showing
;-) ).
I'm not sure what kind of termination you are talking about, but I'll call
it X.

In MG-A, Terminations X, RTP-A-Audio and RTP-A-Video all belong to the same
context, say Context A.  Termination X has 2 streams assigned to it.  One
stream contains the video, the other stream contains the audio (both in
send-receive).  Termination RTP-A-Audio would be configured with only the
Audio stream.  Termination RTP-A-Video would be configured with only the
Video stream.

Therefore the video stream goes to MG1 and the audio stream goes to MGB, as
described.


>Look at MG1.  It has two terminations, with one stream each.  It
>is asked to set up two contexts, one with an RTP connecting to
>MG-A and the other with its RTP connection to MG-B.  That's
>two contexts, each with two terminations, with one stream in
>each of the contexts.

I'm not sure what the two mystery terminations are again, but I'll call
them Y and Z.

Terminations Y and RTP-A belong to a context A and contain one stream.
Terminations Z and RTP-B belong to a context B and contain one stream.

The video stream from MGA comes into context A via Termination RTP-A and
ends up on Termination Y (and vice versa).

Whatever is on termination Z is transmitted out RTP-B via context B (and
vice versa).
 From the below, it seems video is connected to MG-B; however there is no
context containing Terminations Z & Y to allow them to communicate under
the control of megaco.  Therefore, I assume that some internal
implementation-specific mechanism connects terminations Y & Z in order to
get the video from Context A into context B.
MG1 could just have 2 RTP terminations with one stream in one context.  Of
course, H.248 forbids a termination from belonging to more than one
context, so you can't just create a context containing X & Y.



>Of course, MG-B has a similar setup to MG-A -- it's audio connects
>to MG-A, the video connects to MG1.
>
>Now look at it from the MGC.  The "call" has 3 Megaco contexts.
>The MG-A to MG-B audio, the MG-A to MG1 video and the MG1 to MG-B
>video.

Yes, but the MGC has no idea how the video gets from Termination X to
Termination Y in MG1.

Thanks for the illustration.  I haven't really thought about it in a while.


>I'm still not thrilled with the whole stream idea, but it does work.
>
>Brian

http://www.netaid.org
-------------------------------------------------------------------------
Chip Sharp                 CTO Consulting Engineering
Cisco Systems
Reality - Love it or Leave it.
------------------------------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Apr 14 16:46:37 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14269
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 14 Apr 2000 16:46:36 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.27564730@standards.nortelnetworks.com>; Fri, 14 Apr 2000 16:40:33 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3475 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Apr 2000 16:39:12 -0400
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.9136FE30@standards.nortelnetworks.com>; Fri, 14 Apr 2000 16:29:12
          -0400
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id QAA06147; Fri, 14 Apr
          2000 16:34:47 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id QAA00694; Fri, 14 Apr
          2000 16:34:51 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <2MSFWZ5F>; Fri, 14 Apr 2000 16:29:44 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF6781C2@whq-msgusr-02.fore.com>
Date:         Fri, 14 Apr 2000 16:34:40 -0400
Reply-To: "Rosen, Brian" <brosen@FORE.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <brosen@FORE.COM>
Subject:      Re: Multiple streams per call,
X-To:         Chip Sharp <chsharp@cisco.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

You seem to have everything correct!

You are worried about the video translator.  The problem statement
was MG-A and MG-B did not have a common video encoding, so the MGC
wanted to insert a translator to fix the problem.

I think this is very reasonable to do, and I would model the
translator as a set of pairs of terminations - The "A" side and
the "B" side.  Trying to push these into a single context, to
my way of thinking, is very weird.  Much cleaner to have two
separate contexts.  I waffled over whether to represent the "ports"
of the translator as physical terminations.  In reality, they could
be, if the translator was some hard wired fixed function.  It is
possible that it could just be a fancy DSP, and the number of translations
it could do was a variable, determined by what
translations were in use.  For example, it might be able to do
10 MPEG 1 to MPEG 2 translations, but only 3 MPEG2 to H.261 translations.
In this case, it might be better to model the ports as ephemeral
terminations.  I would still represent them as pairs of terminations,
which would go in pairs of two termination contexts, the other
termination being (for example) the RTP termination.

To help your thinking, instead of calling those terminations Y and Z,
call them XLate/A and XLate/B.  If the box could do more than one,
maybe we would call them XL/1/A and XL/1/B, so you could talk about
XL/4/A for example.  Then XL/1/A is in a context with RTP-A, and
XL/1/B is in context with RTP-B.

It is possible to have one termination that had two streams (the A
stream and the B stream) and then the context would have 3 terminations, the
translator, the "A" RTP and the "B" RTP.  Then you would use streamIDs to
keep the streams straight (no need to use topology).
This is one of the things I don't like about what we did, two ways to
do the same thing, nothing but "taste" to decide which to use,
guaranteed interoperability problems unless some package is standardized.
Oh well.  Anyway, I think modeling the translator as having two
terminations, an A termination and a B termination, each with one
stream, is the best way to do it.

In fact, you may have noticed that I used the same model for the
weird function bridge a few emails back -- I think whenever we have
odd-function devices, we should model the "ports" of the device
as a termination implementing a specific package.  In this specific
case the ports are symmetric (because the flows are send-receive),
but in the general case, they may not be.

Brian

> -----Original Message-----
> From: Chip Sharp [mailto:chsharp@cisco.com]
> Sent: Friday, April 14, 2000 3:58 PM
> To: Rosen, Brian; MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Multiple streams per call,
>
>
> At 02:33 PM 4/14/00 -0400, Rosen, Brian wrote:
>
> ...snip...
>
> >Sure.  Look at it from the point of view of the MGs.  You have MG-A,
> >MG-B and MG1.  MG-A has a termination with two streams, video and
> >audio.  It is commanded by the MGC to set up a single context with
> >the termination and two RTP connections, call them RTP-A-Audio and
> >RTP-A-Video.  The address it assigns to RTP-A-Audio is MG-B.
> >The address it assigns RTP-A-Video is MG1.
> >Again, this is a single context, with the physical termination
> >having two streams, and each of the RTP terminations having one
> >stream each.
>
> I assume when you say "RTP connections" above, you mean "RTP
> terminations"
> since the word "connection" isn't allowed in megaco. (your
> MGCP is showing
> ;-) ).
> I'm not sure what kind of termination you are talking about,
> but I'll call
> it X.
>
> In MG-A, Terminations X, RTP-A-Audio and RTP-A-Video all
> belong to the same
> context, say Context A.  Termination X has 2 streams assigned
> to it.  One
> stream contains the video, the other stream contains the
> audio (both in
> send-receive).  Termination RTP-A-Audio would be configured
> with only the
> Audio stream.  Termination RTP-A-Video would be configured
> with only the
> Video stream.
>
> Therefore the video stream goes to MG1 and the audio stream
> goes to MGB, as
> described.
>
>
> >Look at MG1.  It has two terminations, with one stream each.  It
> >is asked to set up two contexts, one with an RTP connecting to
> >MG-A and the other with its RTP connection to MG-B.  That's
> >two contexts, each with two terminations, with one stream in
> >each of the contexts.
>
> I'm not sure what the two mystery terminations are again, but
> I'll call
> them Y and Z.
>
> Terminations Y and RTP-A belong to a context A and contain one stream.
> Terminations Z and RTP-B belong to a context B and contain one stream.
>
> The video stream from MGA comes into context A via
> Termination RTP-A and
> ends up on Termination Y (and vice versa).
>
> Whatever is on termination Z is transmitted out RTP-B via
> context B (and
> vice versa).
>  From the below, it seems video is connected to MG-B; however
> there is no
> context containing Terminations Z & Y to allow them to
> communicate under
> the control of megaco.  Therefore, I assume that some internal
> implementation-specific mechanism connects terminations Y & Z
> in order to
> get the video from Context A into context B.
> MG1 could just have 2 RTP terminations with one stream in one
> context.  Of
> course, H.248 forbids a termination from belonging to more than one
> context, so you can't just create a context containing X & Y.
>
>
>
> >Of course, MG-B has a similar setup to MG-A -- it's audio connects
> >to MG-A, the video connects to MG1.
> >
> >Now look at it from the MGC.  The "call" has 3 Megaco contexts.
> >The MG-A to MG-B audio, the MG-A to MG1 video and the MG1 to MG-B
> >video.
>
> Yes, but the MGC has no idea how the video gets from Termination X to
> Termination Y in MG1.
>
> Thanks for the illustration.  I haven't really thought about
> it in a while.
>
>
> >I'm still not thrilled with the whole stream idea, but it does work.
> >
> >Brian
>
> http://www.netaid.org
> --------------------------------------------------------------
> -----------
> Chip Sharp                 CTO Consulting Engineering
> Cisco Systems
> Reality - Love it or Leave it.
> --------------------------------------------------------------
> ----------
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sat Apr 15 21:32:54 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08172
	for <megaco-archive@LISTS.IETF.ORG>; Sat, 15 Apr 2000 21:32:54 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4B516C90@standards.nortelnetworks.com>; Sat, 15 Apr 2000 21:26:42 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4342 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 15 Apr 2000 21:25:06 -0400
Received: from smtprtp.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.1195E9E0@standards.nortelnetworks.com>; Sat, 15 Apr 2000 21:25:06
          -0400
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          smtprtp.ntcom.nortel.net; Sat, 15 Apr 2000 21:30:51 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <27B9KDS8>; Sat, 15 Apr 2000 21:30:52 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFA743.66A05336"
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B6A2@zcard00g.ca.nortel.com>
Date:         Sat, 15 Apr 2000 21:30:49 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Questions on V16.
X-To:         "Rosen, Brian" <brosen@fore.com>
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_01BFA743.66A05336
Content-Type: text/plain

Again, to have multiple streams you need a multiplex or you need to
alternate activity between them.  I could conceive of alternating text and
voice on the same ephemeral termination, for example, but this is a
modeller's choice.  I knocked H.225.0 (which uses RTP as its multiplex
mechanism) off our list of possible multiplexes because I figured the more
straightforward way of using RTP worked and people were happy with it.

> -----Original Message-----
> From: Rosen, Brian [SMTP:brosen@fore.com]
> Sent: Friday, April 14, 2000 3:31 PM
        [PTT]  ...
> Now, a real interesting question is whether there are circumstances where
> an
> ephemeral termination actually has more than one stream.  For RTP,
> the answer is No.  In fact, so far, I can't think of a case where
> it is possible.  I see no reason to legislate that however.
>
> >

------_=_NextPart_001_01BFA743.66A05336
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: Questions on V16.</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Again, to have =
multiple streams you need a multiplex or you need to alternate activity =
between them.&nbsp; I could conceive of alternating text and voice on =
the same ephemeral termination, for example, but this is a modeller's =
choice.&nbsp; I knocked H.225.0 (which uses RTP as its multiplex =
mechanism) off our list of possible multiplexes because I figured the =
more straightforward way of using RTP worked and people were happy with =
it.</FONT></P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Rosen, Brian [SMTP:brosen@fore.com]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Friday, April 14, 2000 3:31 PM</FONT>
<BR><B><I><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">[PTT]</FONT></I></B><I></I>&nbsp;<FONT COLOR=3D"#0000FF" =
SIZE=3D2 FACE=3D"Arial"> ...</FONT><B></B><B></B><B><FONT SIZE=3D1 =
FACE=3D"Arial"></FONT></B>=20
<BR><FONT SIZE=3D2 FACE=3D"Arial">Now, a real interesting question is =
whether there are circumstances where an</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">ephemeral termination actually has =
more than one stream.&nbsp; For RTP,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the answer is No.&nbsp; In fact, so =
far, I can't think of a case where</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">it is possible.&nbsp; I see no reason =
to legislate that however.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFA743.66A05336--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sat Apr 15 22:26:47 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09286
	for <megaco-archive@LISTS.IETF.ORG>; Sat, 15 Apr 2000 22:26:47 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D8C0D5F0@standards.nortelnetworks.com>; Sat, 15 Apr 2000 22:20:46 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4387 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 15 Apr 2000 22:19:20 -0400
Received: from smtprich.nortel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.A57E46F0@standards.nortelnetworks.com>; Sat, 15 Apr 2000 22:19:20
          -0400
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprich.nortel.com; Sat, 15 Apr 2000 21:24:02 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <269WRKSV>; Sat, 15 Apr 2000 21:22:55 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B6A3@zcard00g.ca.nortel.com>
Date:         Sat, 15 Apr 2000 21:22:54 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      The Unspecified Parameter Issue
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

We have an issue with the contradiction both within the generic rules of
section 7.1.1 concerning unspecified parameters, and between them and other
sections.  The problem comes about because at different times we want to do
the following, but each time we are using the same syntax:

(a) retain information already specified on a termination without having to
send it down again;

(b) use default or provisioned values for parameters rather than specify the
values explicitly;

(c) delete information previously specified on a termination.

For any specific item, it may make sense to say that only one of (a), (b),
or (c) will ever apply.  For instance, an omitted event or signal parameter
always means that the default or provisioned value should be used for that
parameter.  Unfortunately, I don't think we have spelled out our intent for
every parameter or property in the standard, and I'm concerned that we may
not be able to do so because we may find cases where we want to have more
than one of (a), (b), or (c) apply to the same item in different contexts.
I therefore propose that we give up on (a) (which is an optimization) and
make the following changes to existing text:

In the general rules of section 7.1.1, say that unless otherwise specified
in subsequent sections, omission of a parameter or property from a command
means that that parameter or property is given the special value "no value".
The MG may report an error if "no value" is inconsistent with the values of
other parameters and properties of the termination concerned.

Also say in section 7.1.1 that if CHOOSE is specified for a property or
parameter, the MG should substitute the default or provisioned value of that
parameter where there is no reason to provide a different value.

In the sections on event and signal descriptors, say specifically that
omission of a signal or event parameter causes that parameter to take on its
default or provisioned value.

Comments?

Tom Taylor
Phone and FAX: +1 613 736 0961
E-mail: taylor@nortelnetworks.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Apr 16 08:43:15 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07037
	for <megaco-archive@LISTS.IETF.ORG>; Sun, 16 Apr 2000 08:43:15 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F2F120F0@standards.nortelnetworks.com>; 16 Apr 2000 8:37:07 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4640 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 16 Apr 2000 08:35:18 -0400
Received: from lucia.acsu.buffalo.edu (128.205.7.32) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.B1E388A0@standards.nortelnetworks.com>; 16 Apr 2000 8:35:18
          -0400
Received: (qmail 8593 invoked by uid 58411); 16 Apr 2000 12:41:05 -0000
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID:  <Pine.GSO.4.05.10004160838500.8120-100000@lucia.acsu.buffalo.edu>
Date:         Sun, 16 Apr 2000 08:41:05 -0400
Reply-To: Medha Vedaprakash <mv1@ACSU.BUFFALO.EDU>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Medha Vedaprakash <mv1@ACSU.BUFFALO.EDU>
Subject:      Conferencing!!!
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

In the case of a three way calling feature, does the following accurately
describe the sequence of operation, for a single Context approach ?

Single Context Approach :
step 1: endpoint1 calls endpoint2 via the MGC. MG adds two
terminations, say T1 and T2 in a Context (ContextID = 22)

step 2: endpoint1 presses flash.The MG puts endpoint2 on hold. Does this
mean that a new Context is created and Termination, T1 moved to it (Say,
this new Context has ContextID=33)???

step 3: endpoint1 now calls endpoint3. The MG adds a Termination T3 to
Context 33.

step 4: endpoint1 presses flash again. The MG, moves endpoint2 (which was
on hold) to Context 33. Hence, it implicitly deletes Context 22. It
connects the three endpoint to the ports of a Conference bridge since
there are now more than 2 Terminations in the Context, ContextID=22.



Multiple Contexts Approach :
The case of having one context per leg , would be create a Context and
place, Termination T1 and one of the ports of the Conference bridge,
Termination TA in a Context. Repeat the same with all the three endpoints
and define a package for the mixing and switching properties specified in
the Local Control Descriptor.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Apr 16 10:19:20 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07744
	for <megaco-archive@LISTS.IETF.ORG>; Sun, 16 Apr 2000 10:19:20 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5E037C50@standards.nortelnetworks.com>; 16 Apr 2000 10:13:10 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4680 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 16 Apr 2000 10:11:23 -0400
Received: from smtprtp.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.1E7CD220@standards.nortelnetworks.com>; 16 Apr 2000 10:11:23 -0400
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          smtprtp.ntcom.nortel.net; Sun, 16 Apr 2000 10:17:11 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <27B9K1Z3>; Sun, 16 Apr 2000 10:10:54 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFA7AD.93CC0D2C"
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B6A5@zcard00g.ca.nortel.com>
Date:         Sun, 16 Apr 2000 10:10:53 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Conferencing!!!
X-To:         Medha Vedaprakash <mv1@ACSU.BUFFALO.EDU>
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_01BFA7AD.93CC0D2C
Content-Type: text/plain

Looks right to me.

> -----Original Message-----
> From: Medha Vedaprakash [SMTP:mv1@ACSU.BUFFALO.EDU]
> Sent: Sunday, April 16, 2000 8:41 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Conferencing!!!
>
> In the case of a three way calling feature, does the following accurately
> describe the sequence of operation, for a single Context approach ?
>
> Single Context Approach :
> step 1: endpoint1 calls endpoint2 via the MGC. MG adds two
> terminations, say T1 and T2 in a Context (ContextID = 22)
>
> step 2: endpoint1 presses flash.The MG puts endpoint2 on hold. Does this
> mean that a new Context is created and Termination, T1 moved to it (Say,
> this new Context has ContextID=33)???
>
> step 3: endpoint1 now calls endpoint3. The MG adds a Termination T3 to
> Context 33.
>
> step 4: endpoint1 presses flash again. The MG, moves endpoint2 (which was
> on hold) to Context 33. Hence, it implicitly deletes Context 22. It
> connects the three endpoint to the ports of a Conference bridge since
> there are now more than 2 Terminations in the Context, ContextID=22.
>
>
>
> Multiple Contexts Approach :
> The case of having one context per leg , would be create a Context and
> place, Termination T1 and one of the ports of the Conference bridge,
> Termination TA in a Context. Repeat the same with all the three endpoints
> and define a package for the mixing and switching properties specified in
> the Local Control Descriptor.

------_=_NextPart_001_01BFA7AD.93CC0D2C
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: Conferencing!!!</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Looks right to =
me.</FONT>
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Medha Vedaprakash =
[SMTP:mv1@ACSU.BUFFALO.EDU]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Sunday, April 16, 2000 8:41 AM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Conferencing!!!</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In the case of a three way calling =
feature, does the following accurately</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">describe the sequence of operation, =
for a single Context approach ?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Single Context Approach :</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">step 1: endpoint1 calls endpoint2 via =
the MGC. MG adds two</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">terminations, say T1 and T2 in a =
Context (ContextID =3D 22)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">step 2: endpoint1 presses flash.The MG =
puts endpoint2 on hold. Does this</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">mean that a new Context is created =
and Termination, T1 moved to it (Say,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">this new Context has =
ContextID=3D33)???</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">step 3: endpoint1 now calls endpoint3. =
The MG adds a Termination T3 to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Context 33.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">step 4: endpoint1 presses flash again. =
The MG, moves endpoint2 (which was</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">on hold) to Context 33. Hence, it =
implicitly deletes Context 22. It</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">connects the three endpoint to the =
ports of a Conference bridge since</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">there are now more than 2 =
Terminations in the Context, ContextID=3D22.</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Multiple Contexts Approach :</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">The case of having one context per =
leg , would be create a Context and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">place, Termination T1 and one of the =
ports of the Conference bridge,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Termination TA in a Context. Repeat =
the same with all the three endpoints</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">and define a package for the mixing =
and switching properties specified in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the Local Control Descriptor.</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFA7AD.93CC0D2C--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Apr 17 02:31:07 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26745
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 17 Apr 2000 02:31:07 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1756F3D0@standards.nortelnetworks.com>; Mon, 17 Apr 2000 2:24:43 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5017 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 17 Apr 2000 02:23:07 -0400
Received: from mail.axestech.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.78470060@standards.nortelnetworks.com>; Mon, 17 Apr 2000 2:13:07
          -0400
Received: by maxip18.maxipro.com with Internet Mail Service (5.5.1960.3) id
          <HN49Q2MC>; Mon, 17 Apr 2000 01:38:52 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Message-ID:  <C1AAB24F0C66D3118B5B0000E861BB710331CA@maxip18.maxipro.com>
Date:         Mon, 17 Apr 2000 01:38:50 -0500
Reply-To: J Ramachandra <JRamachandra@AXESTECH.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: J Ramachandra <JRamachandra@AXESTECH.COM>
Subject:      Re: Transaction ID NULL
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

 Brian,

Thanks for the first part, but I have some difficulties with the 2nd
part.
See my comments marked as JK> below.

- J K Ramachandra

-----Original Message-----
From: Rosen, Brian
To: 'J Ramachandra'; MEGACO@standards.nortelnetworks.com
Sent: 4/14/00 10:35 AM
Subject: RE: Transaction ID NULL

> Section 8.2.2 Transaction Reply, specifies
> "If the receiver encounters an error such that it cannot determine a
> legal Transaction, it will return a TransactionReply with a null
> TransactionID and a single error descriptor (403 Syntax Error in
> Transaction)".
>
> What is null TransactionID?
> Is it 0 ?  e.g. Reply=0 {Error=403{error string} }
> OR is it like Reply= {Error=403{error string}}?
> As per ABNF, second one results in syntax error.
>
> If it is 0, one is not expected to use transaction ID 0 for a valid
> transaction request? (MGCP Implementation Guide by International
> Softswitch Consortium suggests this for MGCP). If one uses it, how to
> identify whether it is the Reply received for transaction Request 0
> or an error response for one of your requests?
I think we SHOULD do what MGCP does, reserve 0, and use it for this
purpose.  I would prefer NOT to change the ABNF to allow an omitted
TransactionID -- I would prefer the scanner generate an error for this.

> Finally,what purpose it serves to receive a reply like this, when you
> can not determine for which transaction this reply is? Why not ignore
> such a transaction Request, instead of sending an error Reply?
Because the entity that sent the request is looking for a reply.
When it gets no reply, it will retry.  After it retries a number of
times, it might believe the link is down, or the other side is broken.
An error message is a much better answer.

JK> How the receiving entity associates this Reply with its Request?
    Say, there are 'n' number of transaction Request sent towards the
    same destination, how the receiver will decide to which Request (of
    n transaction requests)it should associate this with? The only way
    you can correlate is through the TransactionID which is missing
    (or to be precise, not same) in this error message.

Brian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Apr 17 06:53:40 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28620
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 17 Apr 2000 06:53:40 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.94A772A0@standards.nortelnetworks.com>; Mon, 17 Apr 2000 6:45:55 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5109 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 17 Apr 2000 06:45:23 -0400
Received: from ficon-tech.com (12.10.198.190) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.19D43AF0@standards.nortelnetworks.com>; Mon, 17 Apr 2000 6:35:19
          -0400
Received: from hgupta (hkumar.india.ficon-tech.com [172.25.1.130]) by
          ficon-tech.com (8.9.3/8.8.7) with SMTP id QAA43230 for
          <megaco@standards.nortelnetworks.com>; Mon, 17 Apr 2000 16:11:13
          +0530 (IST) (envelope-from hkumar@ficon-tech.com)
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_0221_01BFA887.8ACCEB80"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Message-ID:  <022401bfa859$733e9460$820119ac@india.ficontech.com>
Date:         Mon, 17 Apr 2000 16:11:08 +0530
Reply-To: Hemant <hkumar@FICON-TECH.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Hemant <hkumar@FICON-TECH.COM>
Subject:      Service State Property "Out of Service"
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_0221_01BFA887.8ACCEB80
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Brian, list,

    I wish to discuss some issues with handling of service state =
property value "Out of Service" (OOS). The draft mentions "The state =
"out of service" indicates that the termination cannot be used for =
traffic" (sec 7.1.5 para 2). This is fine for the terminations which are =
made OOS in null context as terminations can only be Added with non "out =
of service" state. But what about the following :=20

1) Is a command specifying Service State as OOS valid for a termination =
in a non null context ?=20
If it is valid, what is the MG expected to do ? Should it stop traffic =
and deallocate all the resources allocated for that termination and let =
the termination remain in non null context? What will happen if this =
termination is made "in-service" again. The MG would have to allocate =
all the resources (according to the command in which the termination =
state change is specified as in service) for this termination and add it =
to the context. That is the MG would do all the handling that is =
required to "Add" the termination in the context. Then what is being =
gained by keeping a OOS termination in a non-NULL context ?=20

Suggestion : I would suggest that operation should be made invalid. The =
MGC should first bring the termination out of context by explicitly =
subtracting the termination. Another option is specifying that setting =
state to OOS does an implicit subtract (just like mux results in an =
implicit Add). But in this option what would a command containing Stream =
desc. with non null Local or Remote mean ? Should resource reservation =
implied by these be neglected ? I don't know why one would like to make =
a temination OOS and then hold resources for that same termination.=20

2) Assume that the state of a termination in null context is In service. =
An add command for that termination is received and in that command the =
termination state set to OOS. Is that a valid command ?=20

Suggestion : I think this should also be considered invalid going by the =
logic which prevents an already OOS termination to be added to a =
context.=20

Can it be said then that changing the state of a termination to OOS is =
valid only under following circumstances :   =20
    - In null context.   =20
    - By Modify command.   =20
    - Without any Local and Remote Descriptor.=20

comments please ....=20

Regards,
Hemant Kumar

~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hemant Kumar
Ficon Technology
E-mail: mailto:hkumar@ficon-tech.com
Web: http://www.ficon-tech.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~


------=_NextPart_000_0221_01BFA887.8ACCEB80
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#c0c0c0>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial><FONT size=3D-1>Hi Brian, =
list,</FONT></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D-1>&nbsp;&nbsp;&nbsp; I wish to =
discuss some=20
issues with handling of service state property value "Out of Service" =
(OOS). The=20
draft mentions "The state "out of service" indicates that the =
termination cannot=20
be used for traffic" (sec 7.1.5 para 2). This is fine for the =
terminations which=20
are made OOS in null context as terminations can only be Added with non =
"out of=20
service" state. But what about the following :</FONT></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D-1>1) Is a command specifying =
Service State as=20
OOS valid for a termination in a non null context ? </FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D-1>If it is valid, what is the MG =
expected to=20
do</FONT></FONT><FONT face=3DArial><FONT =
size=3D-1></FONT></FONT>&nbsp;<FONT=20
face=3DArial><FONT size=3D-1>?&nbsp;Should it stop traffic and =
deallocate all the=20
resources allocated for that termination and let the termination remain =
in non=20
null context? What will happen if this termination is&nbsp;made =
"in-service"=20
again.&nbsp;The MG would have to allocate all the resources (according =
to the=20
command in which the termination state change is specified as in =
service) for=20
this termination and add it to the context. That is the MG would do all =
the=20
handling that is required to "Add" the termination in the=20
context.</FONT></FONT>&nbsp;Then what is being gained by keeping a OOS=20
termination in a non-NULL context ? <FONT face=3DArial><FONT=20
size=3D-1></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D-1></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D-1>Suggestion : I would suggest =
that operation=20
should be made invalid. The MGC should first bring the termination out =
of=20
context by explicitly subtracting the termination. Another option is =
specifying=20
that setting state to OOS does an implicit subtract (just like mux =
results in an=20
implicit Add). But in this option what would a command containing Stream =
desc.=20
with non null Local or Remote mean ? Should resource reservation implied =
by=20
these be neglected ? I don't know why one would like to make a =
temination OOS=20
and then hold resources for that same =
termination.</FONT></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D-1>2) Assume that the state of a =
termination in=20
null context is In service. An add command for that termination is =
received and=20
in that command the termination state set to OOS. Is that a valid =
command=20
?</FONT></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D-1>Suggestion : I think this should =
also be=20
considered invalid going by the logic which prevents an already OOS =
termination=20
to be added to a context.</FONT></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D-1>Can it be said then that =
changing the state=20
of a termination&nbsp;to OOS is valid only under following circumstances =

:</FONT></FONT><FONT face=3DArial><FONT size=3D-1>&nbsp;&nbsp;&nbsp;=20
</FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D-1>&nbsp;&nbsp;&nbsp; - In null=20
context.</FONT></FONT><FONT face=3DArial><FONT =
size=3D-1>&nbsp;&nbsp;&nbsp;=20
</FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D-1>&nbsp;&nbsp;&nbsp; - By Modify=20
command.</FONT></FONT><FONT face=3DArial><FONT =
size=3D-1>&nbsp;&nbsp;&nbsp;=20
</FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D-1>&nbsp;&nbsp;&nbsp; - Without any =
Local and=20
Remote Descriptor.</FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D-1></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D-1>comments please=20
....</FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D-1></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT size=3D-1>Regards,</FONT></FONT><FONT =
face=3DArial><FONT=20
size=3D-1></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D-1>Hemant =
Kumar</FONT></FONT></FONT><FONT=20
face=3DArial size=3D2></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>~~~~~~~~~~~~~~~~~~~~~~~~~~~~<BR>Hemant=20
Kumar<BR>Ficon Technology<BR>E-mail: <A=20
href=3D"mailto:hkumar@ficon-tech.com">mailto:hkumar@ficon-tech.com</A><BR=
>Web: <A=20
href=3D"http://www.ficon-tech.com">http://www.ficon-tech.com</A><BR>~~~~~=
~~~~~~~~~~~~~~~~~~~~~~~<BR></DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_0221_01BFA887.8ACCEB80--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Apr 17 07:11:11 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28945
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 17 Apr 2000 07:11:10 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3F019B70@standards.nortelnetworks.com>; Mon, 17 Apr 2000 7:05:00 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5182 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 17 Apr 2000 07:03:08 -0400
Received: from ficon-tech.com (12.10.198.190) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.92E55AD0@standards.nortelnetworks.com>; Mon, 17 Apr 2000 6:53:02
          -0400
Received: from hemantag (vacant4.india.ficon-tech.com [172.25.1.131]) by
          ficon-tech.com (8.9.3/8.8.7) with SMTP id QAA44295 for
          <megaco@standards.nortelnetworks.com>; Mon, 17 Apr 2000 16:28:47
          +0530 (IST) (envelope-from hemantag@ficon-tech.com)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Message-ID:  <011501bfa85b$eee2e240$830119ac@india.ficontech.com>
Date:         Mon, 17 Apr 2000 16:28:46 +0530
Reply-To: Hemant Agrawal <hemantag@FICON-TECH.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Hemant Agrawal <hemantag@FICON-TECH.COM>
Organization: Ficon Technology
Subject:      Test ServiceState in  Termination State Descriptor
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi All,
        I have few questions related to serviceState in
terminationStatedDescriptor.
TerminationStateDescriptor has three values for serviceState : In Service,
Out Of Service and Test.
The draft mentions "The state "test" indicates that the termination is being
tested" (sec 7.1.5 para 2).

How is "test" state different from "in service"? Is their any special action
to be taken by MG, when it receives a termination state to be set as test.

Does it mean that if the said termination supports test packages, the events
, signals etc pertaining to these can be applied only in test state. Also in
that case what happens to the non "test" package events and signals. Are
they stopped by the MG on getting service state property as "test" and vice
versa.

I think this differentiation between what constitutes test and what not
should not be done at MG level. But in that case how from an MG point of
view, are the service states "test" and "in service" different ?

Another question in this regards. Should the MG "prefer" allocating  "in
service" terminations over terminations with service state "test" while
resolving CHOOSE in Add.

Thanks in advance,
Hemant Agrawal

________________________________________
Hemant Agrawal
Ficon Technology
E-mail: hemantag@ficon-tech.com
Web: http://www.ficon-tech.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Apr 17 07:28:14 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29194
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 17 Apr 2000 07:28:13 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A0496820@standards.nortelnetworks.com>; Mon, 17 Apr 2000 7:22:02 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5211 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 17 Apr 2000 07:20:51 -0400
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.75CA5910@standards.nortelnetworks.com>; Mon, 17 Apr 2000
          7:20:51 -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id
          NAA21346 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 17 Apr 2000
          13:26:38 +0200 (MET DST)
Received: from ericsson.com (kipe152.eraj.ericsson.se [147.214.68.152]) by
          al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id
          NAA23481 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 17 Apr 2000
          13:26:37 +0200 (MET DST)
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF6781B1@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Message-ID:  <38FABBCC.6BDEB790@ericsson.com>
Date:         Mon, 17 Apr 2000 09:22:52 +0200
Reply-To: Stephen Terrill <stephen.terrill@ERICSSON.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Stephen Terrill <stephen.terrill@ERICSSON.COM>
Organization: L.M. Ericsson
Subject:      Re: MEGACO and Dial Pulse Lines
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit

Hi,

I was trying to find the correct message from this thread to respond to, so I would hitch it onto this.

I would think that MGC shouldn´t be concerned with how the digits were detected.  The MGC is requesting to detect digits, and wether they are pulsed or DTMF shouldn´t matter - this is matter of hardware.

Of course there is an issue of configuration, to have the terminal adapter (or line card) to be set for the type of subcriber, however I haven´t viewed H.248 as a configuration protocol - I understood that was done in other ways.

Regards,

..//steve

"Rosen, Brian" wrote:

> > I agree with George, since POTS transparency is key.
> >
> > It appears that a "Dial pulse" package is needed to inform
> > the MG of the
> > dial pulse characteristics (PPS, Make/Break Ratio). What else?
> >
> > What is the process for creating such a package? Can anyone
> > create an IETF
> > draft?
> >
> Anyone can create a DRAFT.  Just write it up in the proper format
> and email it to the Internet Drafts editor.
>
> Now, if you want IETF to DO anything with it, some working group
> (for example, Megaco) has to adopt it as a work item, and agree
> to turn it into an rfc (through it's consensus process).  I'd
> suspect we would be willing to do this for a dial pulse package,
> but that is up to the group to decide.
>
> Brian
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Apr 17 07:42:17 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29573
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 17 Apr 2000 07:42:17 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9649D3D0@standards.nortelnetworks.com>; Mon, 17 Apr 2000 7:36:04 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5236 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 17 Apr 2000 07:35:00 -0400
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.0A2D8FA0@standards.nortelnetworks.com>; Mon, 17 Apr 2000 7:25:00
          -0400
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id HAA14940; Mon, 17 Apr
          2000 07:30:49 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id HAA28949; Mon, 17 Apr
          2000 07:30:50 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <2MSFX1A6>; Mon, 17 Apr 2000 07:25: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:  <4FBEA8857476D311A03300204840E1CF64D3B3@whq-msgusr-02.fore.com>
Date:         Mon, 17 Apr 2000 07:30:48 -0400
Reply-To: "Rosen, Brian" <brosen@FORE.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <brosen@FORE.COM>
Subject:      Re: Conferencing!!!
X-To:         Medha Vedaprakash <mv1@acsu.buffalo.edu>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Essentially right, but possibly confusing to some.

> In the case of a three way calling feature, does the
> following accurately
> describe the sequence of operation, for a single Context approach ?
Confusion comes because of naming.  Let's call MG-A with T1, MGB with
T2 and MGC with T3.  Each MG creates RTP ephemeral terminations A1, A2,
B1...

> Single Context Approach :
> step 1: endpoint1 calls endpoint2 via the MGC. MG adds two
> terminations, say T1 and T2 in a Context (ContextID = 22)
MG-A has T1.  It adds it to a new context with an ephemeral RTP termination,

call it A1, so this is a two termination context T1 and A1.  On MG-B
we do the same, with T2 and B1.  A1 and B1 have bidirectional RTP flows
between them, and thus T1 and T2 can talk together.

>
> step 2: endpoint1 presses flash.The MG puts endpoint2 on
> hold. Does this
> mean that a new Context is created and Termination, T1 moved
> to it (Say,
> this new Context has ContextID=33)???
There are a couple of ways to do hold.  I like the one you describe,
create a new, one termination context for A1 (the RTP flow).  It would let
you use a signal, or another termination, for "music on hold".
So Context 22 has T1, context 33 has A1.

Notice that on MG-B, nothing changes

> step 3: endpoint1 now calls endpoint3. The MG adds a Termination T3 to
> Context 33.
So now we add a new ephemeral termination, call it A2 into context 22.
It now has two terminations, T1 and A2.  Over on MG-C, it creates a
two termination context with T3 and C1.  A bidirectional RTP flow is
established between A2 and C1.

>
> step 4: endpoint1 presses flash again. The MG, moves
> endpoint2 (which was
> on hold) to Context 33. Hence, it implicitly deletes Context 22. It
> connects the three endpoint to the ports of a Conference bridge since
> there are now more than 2 Terminations in the Context, ContextID=22.
Yep.  Depending on the way the conference bridge is built, but some will be
built using context (and topology).  Those with that point a view should
consider if you just Move A1 back to Context 22, and the mere fact that
there
is more than two terminations implies conference behavior, or whether it
takes something else.


>
>
>
> Multiple Contexts Approach :
> The case of having one context per leg , would be create a Context and
> place, Termination T1 and one of the ports of the Conference bridge,
> Termination TA in a Context. Repeat the same with all the
> three endpoints
> and define a package for the mixing and switching properties
> specified in
> the Local Control Descriptor.
Then MG-A would:
        Create a new context (44) with TC and Move A3 into it.
        Add TA to context 22 with T1
        Add TB to context 33 with A2

Finally, suppose the conference facility is not on MG-C but is on MG-Conf.
Then the MGC has to have MG-Conf set up 3 new RTP flows, to which MG-A,
MG-B and MG-C must connect.  The old RTP terminations would all be taken
down.

Brian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Apr 17 09:49:45 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02754
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 17 Apr 2000 09:49:44 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5BA1A200@standards.nortelnetworks.com>; Mon, 17 Apr 2000 9:43:17 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5367 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 17 Apr 2000 09:42:40 -0400
Received: from tama5.ecl.ntt.co.jp by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.459FC860@standards.nortelnetworks.com>; Mon, 17 Apr 2000 9:42:40
          -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
          WAA10058; Mon, 17 Apr 2000 22:47:44 +0900 (JST) (envelope-from
          makinae.naoto@lab.ntt.co.jp)
Received: from ima.m.ecl.ntt.co.jp by nttmail3.ecl.ntt.co.jp
          (8.9.3+3.2W/3.7W/01/18/00) with ESMTP id WAA04294; Mon, 17 Apr 2000
          22:47:39 +0900 (JST) (envelope-from makinae.naoto@lab.ntt.co.jp)
Received: from idc (ksk-p22.pflab.ecl.ntt.co.jp [129.60.18.196]) by
          ima.m.ecl.ntt.co.jp (8.9.3/3.7W) with SMTP id WAA21146; Mon, 17 Apr
          2000 22:47:38 +0900 (JST)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Message-ID:  <NDBBKGPMCLCCPKPNAOBEIELDCJAA.makinae.naoto@lab.ntt.co.jp>
Date:         Mon, 17 Apr 2000 22:50:43 +0900
Reply-To: makinae.naoto@lab.ntt.co.jp
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Naoto MAKINAE <makinae.naoto@lab.ntt.co.jp>
Subject:      Re: Transaction ID NULL
X-To:         J Ramachandra <JRamachandra@AXESTECH.COM>, brosen@FORE.COM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <C1AAB24F0C66D3118B5B0000E861BB710331CA@maxip18.maxipro.com>
Content-Transfer-Encoding: 7bit

Hi,  JK and Brian.

> > Finally,what purpose it serves to receive a reply like this, when you
> > can not determine for which transaction this reply is? Why not ignore
> > such a transaction Request, instead of sending an error Reply?
> Because the entity that sent the request is looking for a reply.
> When it gets no reply, it will retry.  After it retries a number of
> times, it might believe the link is down, or the other side is broken.
> An error message is a much better answer.
>
> JK> How the receiving entity associates this Reply with its Request?
>     Say, there are 'n' number of transaction Request sent towards the
>     same destination, how the receiver will decide to which Request (of
>     n transaction requests)it should associate this with? The only way
>     you can correlate is through the TransactionID which is missing
>     (or to be precise, not same) in this error message.
>
> Brian

Returning a TransactionReply with a null TransactionID on receipt of an
illegal transaction seems to cause problems.

Because, an illegal transaction may turn out to be a TransactionReply.

Consider the following scenario:

(STEP 1) A MG sends a legal TransactionRequest to a MGC and
         starts a retransmission timer.

(STEP 2) The MGC responds with several TransactionPendings and a
         TransactionReply, which happens to be illegal in the format.

(STEP 3) The MG receives the message which contains the illegal
         TransactionReply and responds with a TransactionReply with a null
         TransactionID.

(STEP 4) If the MGC has no unanswered Transaction, it would simply ignore
         the TransactionReply. If it has any, it would resend them just in
         case.

(STEP 5) After a while, the retransmission timer of the MG expires.
         The MG resends the TransactionReqeust.

(STEP 6) The MGC processes the request again.

If the original TransactionRequest can be processed twice without
any side-effects, there would be no problem.

But, duplicated Notifications likely to cause side-effects.
If you introduce the policy which restricts the reuse of
recently-relinquished TransactionIDs in order to avoid the side-effects,
the STEP 5 or STEP 6 would fail and the MG would never know the response.

Moreover, let's consider another scenario, in which the roles of MG and MGC
are interchanged from the original scenario.

I'll write down the second scenario for clarity:

(STEP 1) A MGC sends a legal TransactionRequest to a MG and
         starts a retransmission timer.

(STEP 2) The MG responds with several TransactionPendings and a
         TransactionReply, which happens to be illegal in the format.

(STEP 3) The MGC receives the message which contains the illegal
         TransactionReply and responds with a TransactionReply with a null
         TransactionID.

(STEP 4) If the MG has no unanswered Transaction, it would simply ignore
         the TransactionReply. If it has any, it would resend them just in
         case.

(STEP 5) After a while, the retransmission timer of the MGC expires.
         The MGC resends the TransactionReqeust.

(STEP 6) The MG processes the request again.

The MGC issues commands, like Add, Modify, Subtract, or Move, which are more
likely to cause side-effects if the contain wildcards. So, they should not be resent.

How do you think?

One alternative for returning the null TransactionID is to reject the message
which contains the illegal transaction. This apparently requires the message-
level acknowledgement scheme.

Naoto
--
Naoto MAKINAE
Information Sharing Platform Laboratories
Nippon Telegram and Telephone Corporation
Email:makinae.naoto@lab.ntt.co.jp


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Apr 17 18:45:14 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11013
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 17 Apr 2000 18:45:14 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.33036BD0@standards.nortelnetworks.com>; Mon, 17 Apr 2000 18:39:01 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5863 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 17 Apr 2000 18:38:19 -0400
Received: from smtprtp1.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.B4612AC0@standards.nortelnetworks.com>; Mon, 17 Apr 2000 18:28:19
          -0400
Received: from zcard015.ca.nortel.com (actually zcard015) by
          smtprtp1.ntcom.nortel.net; Mon, 17 Apr 2000 18:33:48 -0400
Received: from zrtpd00z.us.nortel.com ([47.140.224.110]) by
          zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id H6NPJTH2; Mon, 17 Apr 2000 18:33:48
          -0400
Received: from americasm10.nt.com (pnc1m006.us.nortel.com [47.142.208.218]) by
          zrtpd00z.us.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id HSZ9FCAT; Mon, 17 Apr 2000 18:33:47
          -0400
X-Sybari-Space: 00000000 00000000 00000000
X-Sender: "Brown, Michael [NC1:3T19:EXCH]" <mahubard@zrtpd00z>
X-Mailer: Mozilla 4.7 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <022401bfa859$733e9460$820119ac@india.ficontech.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38FB9229.A1CBCD47@americasm10.nt.com>
Date:         Mon, 17 Apr 2000 18:37:29 -0400
Reply-To: Michael Brown <C.Michael.Brown@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Michael Brown <C.Michael.Brown@NORTELNETWORKS.COM>
Organization: Nortel Networks
Subject:      Re: Service State Property "Out of Service"
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Comments inserted inline with <MB>.

Hemant wrote:

> Hi Brian, list,     I wish to discuss some issues with handling of
> service state property value "Out of Service" (OOS). The draft
> mentions "The state "out of service" indicates that the termination
> cannot be used for traffic" (sec 7.1.5 para 2). This is fine for the
> terminations which are made OOS in null context as terminations can
> only be Added with non "out of service" state. But what about the
> following : 1) Is a command specifying Service State as OOS valid for
> a termination in a non null context ?If it is valid, what is the MG
> expected to do ? Should it stop traffic and deallocate all the
> resources allocated for that termination and let the termination
> remain in non null context? What will happen if this termination is
> made "in-service" again. The MG would have to allocate all the
> resources (according to the command in which the termination state
> change is specified as in service) for this termination and add it to
> the context. That is the MG would do all the handling that is required
> to "Add" the termination in the context. Then what is being gained by
> keeping a OOS termination in a non-NULL context ?
>
> <MB> Actually, I would expect that the MG would continue to do what it
> is told to do either through control of the MGC or perhaps a
> maintenance interface. The decision as to whether/when the termination
> would stop traffic and deallocate resources would be based on the type
> of service change requested (e.g., forced, etc.) The use for an OOS
> termination in a non-null context is that that there are a number of
> OOS tests which could be performed which would be easier modelled by
> placing the termination into a context and potentially adding test
> terminations to the context to perform those functions such as making
> a test call to or from the OOS termination. I do not believe that the
> operation should be made invalid.
>
>   Suggestion : I would suggest that operation should be made invalid.
> The MGC should first bring the termination out of context by
> explicitly subtracting the termination. Another option is specifying
> that setting state to OOS does an implicit subtract (just like mux
> results in an implicit Add). But in this option what would a command
> containing Stream desc. with non null Local or Remote mean ? Should
> resource reservation implied by these be neglected ? I don't know why
> one would like to make a temination OOS and then hold resources for
> that same termination. 2) Assume that the state of a termination in
> null context is In service. An add command for that termination is
> received and in that command the termination state set to OOS. Is that
> a valid command ? Suggestion : I think this should also be considered
> invalid going by the logic which prevents an already OOS termination
> to be added to a context. Can it be said then that changing the state
> of a termination to OOS is valid only under following circumstances
> :    - In null context.    - By Modify command.    - Without any Local
> and Remote Descriptor.
>
> <MB> I would say that the command you have suggested is indeed
> invalid. I think you meant to suggest that a transaction might contain
> both an ADD command and a ServiceChange command and that this
> combination should be invalid. I again do not agree that this should
> be considered invalid, although I would think it somewhat unlikely
> that one would want to do so.
>
>   comments please .... Regards,Hemant
> Kumar ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Hemant Kumar
> Ficon Technology
> E-mail: mailto:hkumar@ficon-tech.com
> Web: http://www.ficon-tech.com
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Apr 17 19:13:11 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11359
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 17 Apr 2000 19:13:11 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1DDA4220@standards.nortelnetworks.com>; Mon, 17 Apr 2000 19:07:03 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5894 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 17 Apr 2000 19:05:24 -0400
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.7C67CDA0@standards.nortelnetworks.com>; Mon, 17 Apr 2000
          18:55:23 -0400
Received: from zcard015.ca.nortel.com (actually zcard015) by
          smtprch1.nortel.com; Mon, 17 Apr 2000 17:57:56 -0500
Received: from zrtpd00z.us.nortel.com ([47.140.224.110]) by
          zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id H6NPJT2K; Mon, 17 Apr 2000 18:57:53
          -0400
Received: from americasm10.nt.com (pnc1m006.us.nortel.com [47.142.208.218]) by
          zrtpd00z.us.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id HSZ9FCB8; Mon, 17 Apr 2000 18:57:52
          -0400
X-Sybari-Space: 00000000 00000000 00000000
X-Sender: "Brown, Michael [NC1:3T19:EXCH]" <mahubard@zrtpd00z>
X-Mailer: Mozilla 4.7 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <011501bfa85b$eee2e240$830119ac@india.ficontech.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38FB97CE.1C64B619@americasm10.nt.com>
Date:         Mon, 17 Apr 2000 19:01:34 -0400
Reply-To: Michael Brown <C.Michael.Brown@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Michael Brown <C.Michael.Brown@NORTELNETWORKS.COM>
Organization: Nortel Networks
Subject:      Re: Test ServiceState in Termination State Descriptor
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

The test state is different from "in service" in that a termination can be "in
service", "OOS", "in service - test" or "OOS - test". I would say that there are
no specific actions which would be applied simply by placing the line in the
test state.

In my opinion, it would be something of a flag to indicate that the signals and
events associated with test package could be applied to a termination. The
behavior associated with those signals and events would be defined as part of
the package and may be different depending on whether the termination is  IS or
OOS.  I would think that the intelligence to determine whether or not to apply a
particular signal or event would be under the control of the MGC or a
maintenance interface, but it might be desirable for an implementation in the MG
to do some minimal defensive coding to prevent MGC or maintenance request
"mistakes".

I do agree that the intelligence for handling the test state should be driven by
the MGC and actions taken in the MG implemented in packages. One of the reasons
I believe that the test state is needed is to have this knowledge available
associated with the termination in the event of the MG performing a failover to
a secondary MGC. The MGC could determine those terminations which were under
test using audit mechanisms and could then take action accordingly.

Regarding your last question, I would say that the MG would behave no
differently in allocating a termination on a CHOOSE when it is IS-test or IS.
The point is that the termination should be used as IS except that specified
test functions will be performed (under MGC control) during normal use.

I am currently in process of working with Nortel development groups on producing
a test package for line test functions. This will be coming out in the near
future and I think it will help to further clarify my comments.

Michael Brown

Hemant Agrawal wrote:

> Hi All,
>         I have few questions related to serviceState in
> terminationStatedDescriptor.
> TerminationStateDescriptor has three values for serviceState : In Service,
> Out Of Service and Test.
> The draft mentions "The state "test" indicates that the termination is being
> tested" (sec 7.1.5 para 2).
>
> How is "test" state different from "in service"? Is their any special action
> to be taken by MG, when it receives a termination state to be set as test.
>
> Does it mean that if the said termination supports test packages, the events
> , signals etc pertaining to these can be applied only in test state. Also in
> that case what happens to the non "test" package events and signals. Are
> they stopped by the MG on getting service state property as "test" and vice
> versa.
>
> I think this differentiation between what constitutes test and what not
> should not be done at MG level. But in that case how from an MG point of
> view, are the service states "test" and "in service" different ?
>
> Another question in this regards. Should the MG "prefer" allocating  "in
> service" terminations over terminations with service state "test" while
> resolving CHOOSE in Add.
>
> Thanks in advance,
> Hemant Agrawal
>
> ________________________________________
> Hemant Agrawal
> Ficon Technology
> E-mail: hemantag@ficon-tech.com
> Web: http://www.ficon-tech.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Apr 17 19:41:36 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11566
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 17 Apr 2000 19:41:35 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.08696110@standards.nortelnetworks.com>; Mon, 17 Apr 2000 19:35:05 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5916 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 17 Apr 2000 19:33:14 -0400
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.5FE31870@standards.nortelnetworks.com>; Mon, 17 Apr 2000 19:23:13
          -0400
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id TAA27729; Mon, 17 Apr
          2000 19:29:03 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id TAA02275; Mon, 17 Apr
          2000 19:29:05 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <2MSFXWTC>; Mon, 17 Apr 2000 19:23: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:  <4FBEA8857476D311A03300204840E1CF64D3FC@whq-msgusr-02.fore.com>
Date:         Mon, 17 Apr 2000 19:29:03 -0400
Reply-To: "Rosen, Brian" <brosen@FORE.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <brosen@FORE.COM>
Subject:      Re: Transaction ID NULL
X-To:         J Ramachandra <JRamachandra@axestech.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

There is of course no way to reliably determine the offending command,
but in most practical cases it can be determined by holding commands
until other commands are acknowledged, and resending any missing commands
one at a time.

Of course, this kind of problem is either a symptom of a seriously broken
implementation, or a broken computer (checksums should find noisy network
problems).

Brian

> -----Original Message-----
> From: J Ramachandra [mailto:JRamachandra@axestech.com]
> Sent: Monday, April 17, 2000 2:39 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: Transaction ID NULL
>
>
>  Brian,
>
> Thanks for the first part, but I have some difficulties with the 2nd
> part.
> See my comments marked as JK> below.
>
> - J K Ramachandra
>
> -----Original Message-----
> From: Rosen, Brian
> To: 'J Ramachandra'; MEGACO@standards.nortelnetworks.com
> Sent: 4/14/00 10:35 AM
> Subject: RE: Transaction ID NULL
>
> > Section 8.2.2 Transaction Reply, specifies
> > "If the receiver encounters an error such that it cannot determine a
> > legal Transaction, it will return a TransactionReply with a null
> > TransactionID and a single error descriptor (403 Syntax Error in
> > Transaction)".
> >
> > What is null TransactionID?
> > Is it 0 ?  e.g. Reply=0 {Error=403{error string} }
> > OR is it like Reply= {Error=403{error string}}?
> > As per ABNF, second one results in syntax error.
> >
> > If it is 0, one is not expected to use transaction ID 0 for a valid
> > transaction request? (MGCP Implementation Guide by International
> > Softswitch Consortium suggests this for MGCP). If one uses
> it, how to
> > identify whether it is the Reply received for transaction Request 0
> > or an error response for one of your requests?
> I think we SHOULD do what MGCP does, reserve 0, and use it for this
> purpose.  I would prefer NOT to change the ABNF to allow an omitted
> TransactionID -- I would prefer the scanner generate an error
> for this.
>
> > Finally,what purpose it serves to receive a reply like
> this, when you
> > can not determine for which transaction this reply is? Why
> not ignore
> > such a transaction Request, instead of sending an error Reply?
> Because the entity that sent the request is looking for a reply.
> When it gets no reply, it will retry.  After it retries a number of
> times, it might believe the link is down, or the other side is broken.
> An error message is a much better answer.
>
> JK> How the receiving entity associates this Reply with its Request?
>     Say, there are 'n' number of transaction Request sent towards the
>     same destination, how the receiver will decide to which
> Request (of
>     n transaction requests)it should associate this with? The only way
>     you can correlate is through the TransactionID which is missing
>     (or to be precise, not same) in this error message.
>
> Brian
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Apr 17 19:41:36 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11568
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 17 Apr 2000 19:41:36 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.08EC9AD0@standards.nortelnetworks.com>; Mon, 17 Apr 2000 19:35:06 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5917 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 17 Apr 2000 19:33:16 -0400
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.619C3A20@standards.nortelnetworks.com>; Mon, 17 Apr 2000 19:23:16
          -0400
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id TAA27733; Mon, 17 Apr
          2000 19:29:05 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id TAA02280; Mon, 17 Apr
          2000 19:29:08 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <2MSFXWTD>; Mon, 17 Apr 2000 19:23: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:  <4FBEA8857476D311A03300204840E1CF64D3FD@whq-msgusr-02.fore.com>
Date:         Mon, 17 Apr 2000 19:29:06 -0400
Reply-To: "Rosen, Brian" <brosen@FORE.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <brosen@FORE.COM>
Subject:      Re: MEGACO and Dial Pulse Lines
X-To:         Stephen Terrill <stephen.terrill@ERICSSON.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA11568

This is another "provision vs. program" argument.
Yes, you could provision the timing characteristics.
Since I think provisioning is evil, I'd prefer the MGC do it.
As was pointed out, the MGC has to know if DTMF is "enabled"
on the line, possibly for billing.  Having to have two parts
with the same information is a cause of confusion and error.

I would think almost all of the MGC code wouldn't know the
difference.

Brian

> -----Original Message-----
> From: Stephen Terrill [mailto:stephen.terrill@ERICSSON.COM]
> Sent: Monday, April 17, 2000 3:23 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: MEGACO and Dial Pulse Lines
> 
> 
> Hi,
> 
> I was trying to find the correct message from this thread to 
> respond to, so I would hitch it onto this.
> 
> I would think that MGC shouldn´t be concerned with how the 
> digits were detected.  The MGC is requesting to detect 
> digits, and wether they are pulsed or DTMF shouldn´t matter - 
> this is matter of hardware.
> 
> Of course there is an issue of configuration, to have the 
> terminal adapter (or line card) to be set for the type of 
> subcriber, however I haven´t viewed H.248 as a configuration 
> protocol - I understood that was done in other ways.
> 
> Regards,
> 
> ..//steve
> 
> "Rosen, Brian" wrote:
> 
> > > I agree with George, since POTS transparency is key.
> > >
> > > It appears that a "Dial pulse" package is needed to inform
> > > the MG of the
> > > dial pulse characteristics (PPS, Make/Break Ratio). What else?
> > >
> > > What is the process for creating such a package? Can anyone
> > > create an IETF
> > > draft?
> > >
> > Anyone can create a DRAFT.  Just write it up in the proper format
> > and email it to the Internet Drafts editor.
> >
> > Now, if you want IETF to DO anything with it, some working group
> > (for example, Megaco) has to adopt it as a work item, and agree
> > to turn it into an rfc (through it's consensus process).  I'd
> > suspect we would be willing to do this for a dial pulse package,
> > but that is up to the group to decide.
> >
> > Brian
> > >
> 


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Apr 17 19:41:37 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11575
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 17 Apr 2000 19:41:36 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.09721E80@standards.nortelnetworks.com>; Mon, 17 Apr 2000 19:35:07 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5918 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 17 Apr 2000 19:33:29 -0400
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.69169840@standards.nortelnetworks.com>; Mon, 17 Apr 2000 19:23:29
          -0400
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id TAA27748; Mon, 17 Apr
          2000 19:29:14 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id TAA02295; Mon, 17 Apr
          2000 19:29:16 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <2MSFXWTF>; Mon, 17 Apr 2000 19:24:05 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFA8C4.04D56114"
Message-ID:  <4FBEA8857476D311A03300204840E1CF64D3FF@whq-msgusr-02.fore.com>
Date:         Mon, 17 Apr 2000 19:29:13 -0400
Reply-To: "Rosen, Brian" <brosen@FORE.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <brosen@FORE.COM>
Subject:      Re: Service State Property "Out of Service"
X-To:         Hemant <hkumar@ficon-tech.com>
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_01BFA8C4.04D56114
Content-Type: text/plain;
        charset="iso-8859-1"

I'd think you should not set a termination out of service unless it was in
null context (and thus would
not have any media streams).  Whether it should be illegal is another
question.  I don't care.  I would not
want setting the property to have side effects like moving to null, etc.

A line with at least "SHOULD" is needed I think.

Brian

-----Original Message-----
From: Hemant [mailto:hkumar@ficon-tech.com]
Sent: Monday, April 17, 2000 6:41 AM
To: MEGACO@standards.nortelnetworks.com
Subject: Service State Property "Out of Service"



Hi Brian, list,

    I wish to discuss some issues with handling of service state property
value "Out of Service" (OOS). The draft mentions "The state "out of service"
indicates that the termination cannot be used for traffic" (sec 7.1.5 para
2). This is fine for the terminations which are made OOS in null context as
terminations can only be Added with non "out of service" state. But what
about the following :

1) Is a command specifying Service State as OOS valid for a termination in a
non null context ?
If it is valid, what is the MG expected to do ? Should it stop traffic and
deallocate all the resources allocated for that termination and let the
termination remain in non null context? What will happen if this termination
is made "in-service" again. The MG would have to allocate all the resources
(according to the command in which the termination state change is specified
as in service) for this termination and add it to the context. That is the
MG would do all the handling that is required to "Add" the termination in
the context. Then what is being gained by keeping a OOS termination in a
non-NULL context ?

Suggestion : I would suggest that operation should be made invalid. The MGC
should first bring the termination out of context by explicitly subtracting
the termination. Another option is specifying that setting state to OOS does
an implicit subtract (just like mux results in an implicit Add). But in this
option what would a command containing Stream desc. with non null Local or
Remote mean ? Should resource reservation implied by these be neglected ? I
don't know why one would like to make a temination OOS and then hold
resources for that same termination.

2) Assume that the state of a termination in null context is In service. An
add command for that termination is received and in that command the
termination state set to OOS. Is that a valid command ?

Suggestion : I think this should also be considered invalid going by the
logic which prevents an already OOS termination to be added to a context.

Can it be said then that changing the state of a termination to OOS is valid
only under following circumstances :
    - In null context.
    - By Modify command.
    - Without any Local and Remote Descriptor.

comments please ....

Regards,
Hemant Kumar

~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hemant Kumar
Ficon Technology
E-mail: mailto:hkumar@ficon-tech.com <mailto:hkumar@ficon-tech.com>
Web: http://www.ficon-tech.com <http://www.ficon-tech.com>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~



------_=_NextPart_001_01BFA8C4.04D56114
Content-Type: text/html;
        charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.2919.6307" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=500060916-17042000>I'd
think you should not set a termination out of service unless it was in null
context (and thus would</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=500060916-17042000>not
have any media streams).&nbsp; Whether it should be illegal is another
question.&nbsp; I don't care.&nbsp; I would not</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=500060916-17042000>want
setting the property to have side effects like moving to null,
etc.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=500060916-17042000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=500060916-17042000>A line
with at least "SHOULD" is needed I think.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=500060916-17042000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=500060916-17042000>Brian</SPAN></FONT></DIV>
<BLOCKQUOTE
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma
  size=2>-----Original Message-----<BR><B>From:</B> Hemant
  [mailto:hkumar@ficon-tech.com]<BR><B>Sent:</B> Monday, April 17, 2000 6:41
  AM<BR><B>To:</B> MEGACO@standards.nortelnetworks.com<BR><B>Subject:</B>
  Service State Property "Out of Service"<BR><BR></DIV></FONT>
  <DIV><FONT face=Arial size=2>
  <DIV><FONT face=Arial><FONT size=-1>Hi Brian, list,</FONT></FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=Arial><FONT size=-1>&nbsp;&nbsp;&nbsp; I wish to discuss some
  issues with handling of service state property value "Out of Service" (OOS).
  The draft mentions "The state "out of service" indicates that the termination
  cannot be used for traffic" (sec 7.1.5 para 2). This is fine for the
  terminations which are made OOS in null context as terminations can only be
  Added with non "out of service" state. But what about the following
  :</FONT></FONT>&nbsp;</DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=Arial><FONT size=-1>1) Is a command specifying Service State
  as OOS valid for a termination in a non null context ? </FONT></FONT></DIV>
  <DIV><FONT face=Arial><FONT size=-1>If it is valid, what is the MG expected to
  do</FONT></FONT><FONT face=Arial><FONT size=-1></FONT></FONT>&nbsp;<FONT
  face=Arial><FONT size=-1>?&nbsp;Should it stop traffic and deallocate all the
  resources allocated for that termination and let the termination remain in non
  null context? What will happen if this termination is&nbsp;made "in-service"
  again.&nbsp;The MG would have to allocate all the resources (according to the
  command in which the termination state change is specified as in service) for
  this termination and add it to the context. That is the MG would do all the
  handling that is required to "Add" the termination in the
  context.</FONT></FONT>&nbsp;Then what is being gained by keeping a OOS
  termination in a non-NULL context ? <FONT face=Arial><FONT
  size=-1></FONT></FONT></DIV>
  <DIV><FONT face=Arial><FONT size=-1></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial><FONT size=-1>Suggestion : I would suggest that
  operation should be made invalid. The MGC should first bring the termination
  out of context by explicitly subtracting the termination. Another option is
  specifying that setting state to OOS does an implicit subtract (just like mux
  results in an implicit Add). But in this option what would a command
  containing Stream desc. with non null Local or Remote mean ? Should resource
  reservation implied by these be neglected ? I don't know why one would like to
  make a temination OOS and then hold resources for that same
  termination.</FONT></FONT>&nbsp;</DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=Arial><FONT size=-1>2) Assume that the state of a termination
  in null context is In service. An add command for that termination is received
  and in that command the termination state set to OOS. Is that a valid command
  ?</FONT></FONT>&nbsp;</DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=Arial><FONT size=-1>Suggestion : I think this should also be
  considered invalid going by the logic which prevents an already OOS
  termination to be added to a context.</FONT></FONT>&nbsp;</DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=Arial><FONT size=-1>Can it be said then that changing the
  state of a termination&nbsp;to OOS is valid only under following circumstances
  :</FONT></FONT><FONT face=Arial><FONT size=-1>&nbsp;&nbsp;&nbsp;
  </FONT></FONT></DIV>
  <DIV><FONT face=Arial><FONT size=-1>&nbsp;&nbsp;&nbsp; - In null
  context.</FONT></FONT><FONT face=Arial><FONT size=-1>&nbsp;&nbsp;&nbsp;
  </FONT></FONT></DIV>
  <DIV><FONT face=Arial><FONT size=-1>&nbsp;&nbsp;&nbsp; - By Modify
  command.</FONT></FONT><FONT face=Arial><FONT size=-1>&nbsp;&nbsp;&nbsp;
  </FONT></FONT></DIV>
  <DIV><FONT face=Arial><FONT size=-1>&nbsp;&nbsp;&nbsp; - Without any Local and
  Remote Descriptor.</FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial><FONT size=-1></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial><FONT size=-1>comments please
  ....</FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial><FONT size=-1></FONT></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial><FONT size=-1>Regards,</FONT></FONT><FONT
  face=Arial><FONT size=-1></FONT></FONT></DIV>
  <DIV><FONT face=Arial><FONT size=-1>Hemant Kumar</FONT></FONT></FONT><FONT
  face=Arial size=2></FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>~~~~~~~~~~~~~~~~~~~~~~~~~~~~<BR>Hemant
  Kumar<BR>Ficon Technology<BR>E-mail: <A
  href="mailto:hkumar@ficon-tech.com">mailto:hkumar@ficon-tech.com</A><BR>Web:
  <A
  href="http://www.ficon-tech.com">http://www.ficon-tech.com</A><BR>~~~~~~~~~~~~~~~~~~~~~~~~~~~~<BR></DIV></FONT></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01BFA8C4.04D56114--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr 18 00:14:49 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15722
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 18 Apr 2000 00:14:49 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.361095E0@standards.nortelnetworks.com>; Tue, 18 Apr 2000 0:08:23 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6088 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 18 Apr 2000 00:06:36 -0400
Received: from ish7.ericsson.com.au (203.61.155.111) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.8FBCE4B0@standards.nortelnetworks.com>; Mon, 17 Apr 2000
          23:56:34 -0400
Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id OAA24114 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 18 Apr 2000 14:02:11
          +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 OAA19804 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 18 Apr 2000 14:02:34
          +1000 (EST)
Received: from ericsson.com.au (brdhcp014-017.epa.ericsson.se [146.11.14.17])
          by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet
          Mail Service Version 5.5.2448.0) id H001C627; Tue, 18 Apr 2000
          14:02:09 +1000
X-Mailer: Mozilla 4.6 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38FBFA5F.8EB6205E@ericsson.com.au>
Date:         Tue, 18 Apr 2000 14:02:07 +0800
Reply-To: Paul Hollis <paul.hollis@ERICSSON.COM.AU>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Paul Hollis <paul.hollis@ERICSSON.COM.AU>
Organization: Ericsson Australia
Subject:      Wildcarded context ID?
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi,

just a quick question:

Does the wildcard "ALL" for a context ID include the NULL context, or does it
only cover non-Null contexts?

Regards Paul.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr 18 00:31:42 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16510
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 18 Apr 2000 00:31:41 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.97134340@standards.nortelnetworks.com>; Tue, 18 Apr 2000 0:25:25 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6120 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 18 Apr 2000 00:24:18 -0400
Received: from ficon-tech.com (12.10.198.190) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.6E3C8D00@standards.nortelnetworks.com>; Tue, 18 Apr 2000 0:24:16
          -0400
Received: from ficon-tech.com (skylab.india.ficon-tech.com [172.25.2.100]) by
          ficon-tech.com (8.9.3/8.8.7) with ESMTP id JAA59843; Tue, 18 Apr 2000
          09:59:41 +0530 (IST) (envelope-from hsanand@ficon-tech.com)
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <38FBFA5F.8EB6205E@ericsson.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38FBE3C1.9EFD052C@ficon-tech.com>
Date:         Tue, 18 Apr 2000 09:55:37 +0530
Reply-To: hsanand@ficon-tech.com
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Harpreet Singh Anand <hsanand@ficon-tech.com>
Organization: Ficon Technology
Subject:      Re: Wildcarded context ID?
X-To:         Paul Hollis <paul.hollis@ERICSSON.COM.AU>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi Paul,

Paul Hollis wrote:

> Hi,
>
> just a quick question:
>
> Does the wildcard "ALL" for a context ID include the NULL context,

Yes it includes the NULL context also.


> or does it
> only cover non-Null contexts?
>
> Regards Paul.

--

Regards,
Harpreet

_________________________________
Harpreet Singh Anand
Ficon Technology
E-mail :  mailto:hsanand@ficon-tech.com
Web    :  http://www.ficon-tech.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr 18 01:59:44 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21892
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 18 Apr 2000 01:59:44 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E3DBAC10@standards.nortelnetworks.com>; Tue, 18 Apr 2000 1:53:27 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6156 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 18 Apr 2000 01:52:08 -0400
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.B4364100@standards.nortelnetworks.com>; Tue, 18 Apr 2000
          1:52:07 -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id
          HAA09085; Tue, 18 Apr 2000 07:57:59 +0200 (MET DST)
Received: from ericsson.com (kipe152.eraj.ericsson.se [147.214.68.152]) by
          al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id
          HAA26832; Tue, 18 Apr 2000 07:57:59 +0200 (MET DST)
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF64D3FD@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Message-ID:  <38FBF947.F92FD866@ericsson.com>
Date:         Tue, 18 Apr 2000 07:57:28 +0200
Reply-To: Stephen Terrill <stephen.terrill@ERICSSON.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Stephen Terrill <stephen.terrill@ERICSSON.COM>
Organization: L.M. Ericsson
Subject:      Re: MEGACO and Dial Pulse Lines
X-To:         "Rosen, Brian" <brosen@fore.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit

Hi Brian,

Now you are just argueing where to do the provisoning, not that provisoning can be avoided.  As it has to be done somewhere, why the MGC?

..//steve

"Rosen, Brian" wrote:

> This is another "provision vs. program" argument.
> Yes, you could provision the timing characteristics.
> Since I think provisioning is evil, I'd prefer the MGC do it.
> As was pointed out, the MGC has to know if DTMF is "enabled"
> on the line, possibly for billing.  Having to have two parts
> with the same information is a cause of confusion and error.
>
> I would think almost all of the MGC code wouldn't know the
> difference.
>
> Brian
>
> > -----Original Message-----
> > From: Stephen Terrill [mailto:stephen.terrill@ERICSSON.COM]
> > Sent: Monday, April 17, 2000 3:23 AM
> > To: MEGACO@standards.nortelnetworks.com
> > Subject: Re: MEGACO and Dial Pulse Lines
> >
> >
> > Hi,
> >
> > I was trying to find the correct message from this thread to
> > respond to, so I would hitch it onto this.
> >
> > I would think that MGC shouldn´t be concerned with how the
> > digits were detected.  The MGC is requesting to detect
> > digits, and wether they are pulsed or DTMF shouldn´t matter -
> > this is matter of hardware.
> >
> > Of course there is an issue of configuration, to have the
> > terminal adapter (or line card) to be set for the type of
> > subcriber, however I haven´t viewed H.248 as a configuration
> > protocol - I understood that was done in other ways.
> >
> > Regards,
> >
> > ..//steve
> >
> > "Rosen, Brian" wrote:
> >
> > > > I agree with George, since POTS transparency is key.
> > > >
> > > > It appears that a "Dial pulse" package is needed to inform
> > > > the MG of the
> > > > dial pulse characteristics (PPS, Make/Break Ratio). What else?
> > > >
> > > > What is the process for creating such a package? Can anyone
> > > > create an IETF
> > > > draft?
> > > >
> > > Anyone can create a DRAFT.  Just write it up in the proper format
> > > and email it to the Internet Drafts editor.
> > >
> > > Now, if you want IETF to DO anything with it, some working group
> > > (for example, Megaco) has to adopt it as a work item, and agree
> > > to turn it into an rfc (through it's consensus process).  I'd
> > > suspect we would be willing to do this for a dial pulse package,
> > > but that is up to the group to decide.
> > >
> > > Brian
> > > >
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr 18 03:23:58 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28832
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 18 Apr 2000 03:23:58 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A2288E80@standards.nortelnetworks.com>; Tue, 18 Apr 2000 3:17:31 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6198 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 18 Apr 2000 03:15:39 -0400
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.F9C38980@standards.nortelnetworks.com>; Tue, 18 Apr 2000 3:05:39
          -0400
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id DAA15385; Tue, 18 Apr
          2000 03:11:29 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id DAA02505; Tue, 18 Apr
          2000 03:11:32 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <2MSFXZA9>; Tue, 18 Apr 2000 03:06: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:  <4FBEA8857476D311A03300204840E1CF6781C8@whq-msgusr-02.fore.com>
Date:         Tue, 18 Apr 2000 03:11:30 -0400
Reply-To: "Rosen, Brian" <brosen@FORE.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <brosen@FORE.COM>
Subject:      Re: MEGACO and Dial Pulse Lines
X-To:         Stephen Terrill <stephen.terrill@ericsson.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA28832

Since the MGC needs it, and the MG needs it, you do it in the MGC and
let it program the MG.

Provisioning might be evil, but it's not totally unavoidable yet!

Brian

> -----Original Message-----
> From: Stephen Terrill [mailto:stephen.terrill@ericsson.com]
> Sent: Tuesday, April 18, 2000 1:57 AM
> To: Rosen, Brian
> Cc: MEGACO@standards.nortelnetworks.com
> Subject: Re: MEGACO and Dial Pulse Lines
> 
> 
> Hi Brian,
> 
> Now you are just argueing where to do the provisoning, not 
> that provisoning can be avoided.  As it has to be done 
> somewhere, why the MGC?
> 
> ..//steve
> 
> "Rosen, Brian" wrote:
> 
> > This is another "provision vs. program" argument.
> > Yes, you could provision the timing characteristics.
> > Since I think provisioning is evil, I'd prefer the MGC do it.
> > As was pointed out, the MGC has to know if DTMF is "enabled"
> > on the line, possibly for billing.  Having to have two parts
> > with the same information is a cause of confusion and error.
> >
> > I would think almost all of the MGC code wouldn't know the
> > difference.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Stephen Terrill [mailto:stephen.terrill@ERICSSON.COM]
> > > Sent: Monday, April 17, 2000 3:23 AM
> > > To: MEGACO@standards.nortelnetworks.com
> > > Subject: Re: MEGACO and Dial Pulse Lines
> > >
> > >
> > > Hi,
> > >
> > > I was trying to find the correct message from this thread to
> > > respond to, so I would hitch it onto this.
> > >
> > > I would think that MGC shouldn´t be concerned with how the
> > > digits were detected.  The MGC is requesting to detect
> > > digits, and wether they are pulsed or DTMF shouldn´t matter -
> > > this is matter of hardware.
> > >
> > > Of course there is an issue of configuration, to have the
> > > terminal adapter (or line card) to be set for the type of
> > > subcriber, however I haven´t viewed H.248 as a configuration
> > > protocol - I understood that was done in other ways.
> > >
> > > Regards,
> > >
> > > ..//steve
> > >
> > > "Rosen, Brian" wrote:
> > >
> > > > > I agree with George, since POTS transparency is key.
> > > > >
> > > > > It appears that a "Dial pulse" package is needed to inform
> > > > > the MG of the
> > > > > dial pulse characteristics (PPS, Make/Break Ratio). What else?
> > > > >
> > > > > What is the process for creating such a package? Can anyone
> > > > > create an IETF
> > > > > draft?
> > > > >
> > > > Anyone can create a DRAFT.  Just write it up in the 
> proper format
> > > > and email it to the Internet Drafts editor.
> > > >
> > > > Now, if you want IETF to DO anything with it, some working group
> > > > (for example, Megaco) has to adopt it as a work item, and agree
> > > > to turn it into an rfc (through it's consensus process).  I'd
> > > > suspect we would be willing to do this for a dial pulse package,
> > > > but that is up to the group to decide.
> > > >
> > > > Brian
> > > > >
> > >
> 


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr 18 07:57:07 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01513
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 18 Apr 2000 07:57:06 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CB279800@standards.nortelnetworks.com>; Tue, 18 Apr 2000 7:50:41 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6302 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 18 Apr 2000 07:49:00 -0400
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.8F09BB50@standards.nortelnetworks.com>; Tue, 18 Apr 2000
          7:49:00 -0400
Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id
          NAB12422; Tue, 18 Apr 2000 13:54:53 +0200 (MET DST)
Received: from ericsson.com (kipe152.eraj.ericsson.se [147.214.68.152]) by
          al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id
          NAA15644; Tue, 18 Apr 2000 13:54:52 +0200 (MET DST)
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF6781C8@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Message-ID:  <38FC4CEF.1059BFD1@ericsson.com>
Date:         Tue, 18 Apr 2000 13:54:24 +0200
Reply-To: Stephen Terrill <stephen.terrill@ERICSSON.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Stephen Terrill <stephen.terrill@ERICSSON.COM>
Organization: L.M. Ericsson
Subject:      Re: MEGACO and Dial Pulse Lines
X-To:         "Rosen, Brian" <brosen@fore.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit

The only reason that I saw suggested that the MGC needed it was for "billling" - not charging, but billing (and that is  very operator dependant).  It is not necessary that the billing is done on the MGC, but maybe another system again (this is quite common), as such I don´t see why the MGC needs to be bothered with such hardware details.

Regards,

..//steve

"Rosen, Brian" wrote:

> Since the MGC needs it, and the MG needs it, you do it in the MGC and
> let it program the MG.
>
> Provisioning might be evil, but it's not totally unavoidable yet!
>
> Brian
>
> > -----Original Message-----
> > From: Stephen Terrill [mailto:stephen.terrill@ericsson.com]
> > Sent: Tuesday, April 18, 2000 1:57 AM
> > To: Rosen, Brian
> > Cc: MEGACO@standards.nortelnetworks.com
> > Subject: Re: MEGACO and Dial Pulse Lines
> >
> >
> > Hi Brian,
> >
> > Now you are just argueing where to do the provisoning, not
> > that provisoning can be avoided.  As it has to be done
> > somewhere, why the MGC?
> >
> > ..//steve
> >
> > "Rosen, Brian" wrote:
> >
> > > This is another "provision vs. program" argument.
> > > Yes, you could provision the timing characteristics.
> > > Since I think provisioning is evil, I'd prefer the MGC do it.
> > > As was pointed out, the MGC has to know if DTMF is "enabled"
> > > on the line, possibly for billing.  Having to have two parts
> > > with the same information is a cause of confusion and error.
> > >
> > > I would think almost all of the MGC code wouldn't know the
> > > difference.
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Stephen Terrill [mailto:stephen.terrill@ERICSSON.COM]
> > > > Sent: Monday, April 17, 2000 3:23 AM
> > > > To: MEGACO@standards.nortelnetworks.com
> > > > Subject: Re: MEGACO and Dial Pulse Lines
> > > >
> > > >
> > > > Hi,
> > > >
> > > > I was trying to find the correct message from this thread to
> > > > respond to, so I would hitch it onto this.
> > > >
> > > > I would think that MGC shouldn´t be concerned with how the
> > > > digits were detected.  The MGC is requesting to detect
> > > > digits, and wether they are pulsed or DTMF shouldn´t matter -
> > > > this is matter of hardware.
> > > >
> > > > Of course there is an issue of configuration, to have the
> > > > terminal adapter (or line card) to be set for the type of
> > > > subcriber, however I haven´t viewed H.248 as a configuration
> > > > protocol - I understood that was done in other ways.
> > > >
> > > > Regards,
> > > >
> > > > ..//steve
> > > >
> > > > "Rosen, Brian" wrote:
> > > >
> > > > > > I agree with George, since POTS transparency is key.
> > > > > >
> > > > > > It appears that a "Dial pulse" package is needed to inform
> > > > > > the MG of the
> > > > > > dial pulse characteristics (PPS, Make/Break Ratio). What else?
> > > > > >
> > > > > > What is the process for creating such a package? Can anyone
> > > > > > create an IETF
> > > > > > draft?
> > > > > >
> > > > > Anyone can create a DRAFT.  Just write it up in the
> > proper format
> > > > > and email it to the Internet Drafts editor.
> > > > >
> > > > > Now, if you want IETF to DO anything with it, some working group
> > > > > (for example, Megaco) has to adopt it as a work item, and agree
> > > > > to turn it into an rfc (through it's consensus process).  I'd
> > > > > suspect we would be willing to do this for a dial pulse package,
> > > > > but that is up to the group to decide.
> > > > >
> > > > > Brian
> > > > > >
> > > >
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr 18 08:30:12 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02649
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 18 Apr 2000 08:30:11 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6D5C91D0@standards.nortelnetworks.com>; Tue, 18 Apr 2000 8:23:51 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6367 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 18 Apr 2000 08:22:02 -0400
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.2C21A7F0@standards.nortelnetworks.com>; Tue, 18 Apr 2000
          8:22:01 -0400
Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.201.16]) by
          penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id
          OAA05521 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 18 Apr 2000
          14:27:51 +0200 (MET DST)
Received: from uabs28 (uabs28i3 [134.138.201.3]) by ms.uab.ericsson.se
          (8.10.0/8.10.0/uab-2.25) with ESMTP id e3ICRpb06129; Tue, 18 Apr 2000
          14:27:51 +0200 (MET DST)
Received: from uab.ericsson.se by uabs28 (8.8.8+Sun/client-1.3uab2) id
          OAA11307; Tue, 18 Apr 2000 14:27:50 +0200 (MET DST)
X-Mailer: Mozilla 4.05 [en] (Win95; I)
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF6781C8@whq-msgusr-02.fore.com>
            <38FC4CEF.1059BFD1@ericsson.com>
Content-Type: multipart/mixed; boundary="------------C6F0B6870B0ECE8D5E2F7DD2"
Message-ID:  <38FC54C6.72F45F08@uab.ericsson.se>
Date:         Tue, 18 Apr 2000 14:27:50 +0200
Reply-To: Alf Heidermark <Alf.Heidermark@UAB.ERICSSON.SE>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Alf Heidermark <Alf.Heidermark@UAB.ERICSSON.SE>
Organization: Ericsson Utvecklings AB
Subject:      Re: MEGACO and Dial Pulse Lines
X-To:         Stephen Terrill <stephen.terrill@ERICSSON.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.
--------------C6F0B6870B0ECE8D5E2F7DD2
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

This requriment for billing of the feature cannot be manndatory in all
networks. This means that the MGC does not have to be aware of whether
it is pulse or DTMF. The MG must be able to find out itself.

Stephen Terrill wrote:
>
> The only reason that I saw suggested that the MGC needed it was for "billling" - not charging, but billing (and that is  very operator dependant).  It is not necessary that the billing is done on the MGC, but maybe another system again (this is quite common), as such I don´t see why the MGC needs to be bothered with such hardware details.
>
> Regards,
>
> ..//steve
>
> "Rosen, Brian" wrote:
>
> > Since the MGC needs it, and the MG needs it, you do it in the MGC and
> > let it program the MG.
> >
> > Provisioning might be evil, but it's not totally unavoidable yet!
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Stephen Terrill [mailto:stephen.terrill@ericsson.com]
> > > Sent: Tuesday, April 18, 2000 1:57 AM
> > > To: Rosen, Brian
> > > Cc: MEGACO@standards.nortelnetworks.com
> > > Subject: Re: MEGACO and Dial Pulse Lines
> > >
> > >
> > > Hi Brian,
> > >
> > > Now you are just argueing where to do the provisoning, not
> > > that provisoning can be avoided.  As it has to be done
> > > somewhere, why the MGC?
> > >
> > > ..//steve
> > >
> > > "Rosen, Brian" wrote:
> > >
> > > > This is another "provision vs. program" argument.
> > > > Yes, you could provision the timing characteristics.
> > > > Since I think provisioning is evil, I'd prefer the MGC do it.
> > > > As was pointed out, the MGC has to know if DTMF is "enabled"
> > > > on the line, possibly for billing.  Having to have two parts
> > > > with the same information is a cause of confusion and error.
> > > >
> > > > I would think almost all of the MGC code wouldn't know the
> > > > difference.
> > > >
> > > > Brian
> > > >
> > > > > -----Original Message-----
> > > > > From: Stephen Terrill [mailto:stephen.terrill@ERICSSON.COM]
> > > > > Sent: Monday, April 17, 2000 3:23 AM
> > > > > To: MEGACO@standards.nortelnetworks.com
> > > > > Subject: Re: MEGACO and Dial Pulse Lines
> > > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > I was trying to find the correct message from this thread to
> > > > > respond to, so I would hitch it onto this.
> > > > >
> > > > > I would think that MGC shouldn´t be concerned with how the
> > > > > digits were detected.  The MGC is requesting to detect
> > > > > digits, and wether they are pulsed or DTMF shouldn´t matter -
> > > > > this is matter of hardware.
> > > > >
> > > > > Of course there is an issue of configuration, to have the
> > > > > terminal adapter (or line card) to be set for the type of
> > > > > subcriber, however I haven´t viewed H.248 as a configuration
> > > > > protocol - I understood that was done in other ways.
> > > > >
> > > > > Regards,
> > > > >
> > > > > ..//steve
> > > > >
> > > > > "Rosen, Brian" wrote:
> > > > >
> > > > > > > I agree with George, since POTS transparency is key.
> > > > > > >
> > > > > > > It appears that a "Dial pulse" package is needed to inform
> > > > > > > the MG of the
> > > > > > > dial pulse characteristics (PPS, Make/Break Ratio). What else?
> > > > > > >
> > > > > > > What is the process for creating such a package? Can anyone
> > > > > > > create an IETF
> > > > > > > draft?
> > > > > > >
> > > > > > Anyone can create a DRAFT.  Just write it up in the
> > > proper format
> > > > > > and email it to the Internet Drafts editor.
> > > > > >
> > > > > > Now, if you want IETF to DO anything with it, some working group
> > > > > > (for example, Megaco) has to adopt it as a work item, and agree
> > > > > > to turn it into an rfc (through it's consensus process).  I'd
> > > > > > suspect we would be willing to do this for a dial pulse package,
> > > > > > but that is up to the group to decide.
> > > > > >
> > > > > > Brian
> > > > > > >
> > > > >
> > >
--------------C6F0B6870B0ECE8D5E2F7DD2
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


--------------C6F0B6870B0ECE8D5E2F7DD2--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr 18 08:46:17 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03138
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 18 Apr 2000 08:46:17 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AAB3C6F0@standards.nortelnetworks.com>; Tue, 18 Apr 2000 8:39:53 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6388 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 18 Apr 2000 08:38:00 -0400
Received: from ficon-tech.com (12.10.198.190) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.6695E160@standards.nortelnetworks.com>; Tue, 18 Apr 2000 8:37:59
          -0400
Received: from ficon-tech.com (sphilip.india.ficon-tech.com [172.25.1.104]) by
          ficon-tech.com (8.9.3/8.8.7) with ESMTP id SAA84749 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 18 Apr 2000 18:14:00
          +0530 (IST) (envelope-from sphilip@ficon-tech.com)
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38FC5814.6E6F872D@ficon-tech.com>
Date:         Tue, 18 Apr 2000 18:11:57 +0530
Reply-To: Shalini Philip <sphilip@FICON-TECH.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Shalini Philip <sphilip@FICON-TECH.COM>
Organization: Ficon Technology
Subject:      Context Termination Audit
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello all,

    In the last summary of issues mail sent by Tom Taylor, there was an
item as the following:

   7.2.5,     Text and ASN.1 allow return     Fix production
   B.2        of results involving multiple
contextTerminationAudit
              contexts, but ABNF does not.       by allowing return of
                                                                   list
of context-specific

results as an

alternative.

Can anyone please give the ABNF fix for this, or a pointer to some
earlier mail containing the required information? Are we going by the
solution proposed by Nancy and Abdallah in their mail on 23rd March 2000
with subject "V16 Review - Auditing Contexts and their terminations".


Thanks & Regards,

Shalini Philip
Ficon Technology
E-Mail : mailto:sphilip@ficon-tech.com
Web    : http://www.ficon-tech.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr 18 09:20:25 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03984
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 18 Apr 2000 09:20:25 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6BEC0DB0@standards.nortelnetworks.com>; Tue, 18 Apr 2000 9:13:55 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6408 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 18 Apr 2000 09:12:00 -0400
Received: from smtprtp.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.2792A5C0@standards.nortelnetworks.com>; Tue, 18 Apr 2000 9:12:00
          -0400
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          smtprtp.ntcom.nortel.net; Tue, 18 Apr 2000 09:17:53 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <27B9L2BT>; Tue, 18 Apr 2000 09:17:53 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFA938.7F933600"
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B6B5@zcard00g.ca.nortel.com>
Date:         Tue, 18 Apr 2000 09:17:49 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: MEGACO and Dial Pulse Lines
X-To:         Alf Heidermark <Alf.Heidermark@UAB.ERICSSON.SE>
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_01BFA938.7F933600
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I think there are differences in technology that have to be accounted =
for,
so we may not escape having to distinguish DTMF from DP in separate
packages.  The MGC can't expect a DP set to dial * or #, for instance.  =
The
billing issue is clearly one of operator policy.  That means we have to
supply the option to support it, not restrict operator actions.

Anyway, the whole question is moot until someone submits a DP package.

> -----Original Message-----
> From: Alf Heidermark [SMTP:Alf.Heidermark@UAB.ERICSSON.SE]
> Sent: Tuesday, April 18, 2000 8:28 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: MEGACO and Dial Pulse Lines
>=20
> This requriment for billing of the feature cannot be manndatory in =
all
> networks. This means that the MGC does not have to be aware of =
whether
> it is pulse or DTMF. The MG must be able to find out itself.
>=20
> Stephen Terrill wrote:
> >
> > The only reason that I saw suggested that the MGC needed it was for
> "billling" - not charging, but billing (and that is  very operator
> dependant).  It is not necessary that the billing is done on the MGC, =
but
> maybe another system again (this is quite common), as such I don=B4t =
see why
> the MGC needs to be bothered with such hardware details.
> >
> > Regards,
> >
> > ..//steve
> >
> > "Rosen, Brian" wrote:
> >
> > > Since the MGC needs it, and the MG needs it, you do it in the MGC =
and
> > > let it program the MG.
> > >
> > > Provisioning might be evil, but it's not totally unavoidable yet!
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Stephen Terrill [mailto:stephen.terrill@ericsson.com]
> > > > Sent: Tuesday, April 18, 2000 1:57 AM
> > > > To: Rosen, Brian
> > > > Cc: MEGACO@standards.nortelnetworks.com
> > > > Subject: Re: MEGACO and Dial Pulse Lines
> > > >
> > > >
> > > > Hi Brian,
> > > >
> > > > Now you are just argueing where to do the provisoning, not
> > > > that provisoning can be avoided.  As it has to be done
> > > > somewhere, why the MGC?
> > > >
> > > > ..//steve
> > > >
> > > > "Rosen, Brian" wrote:
> > > >
> > > > > This is another "provision vs. program" argument.
> > > > > Yes, you could provision the timing characteristics.
> > > > > Since I think provisioning is evil, I'd prefer the MGC do it.
> > > > > As was pointed out, the MGC has to know if DTMF is "enabled"
> > > > > on the line, possibly for billing.  Having to have two parts
> > > > > with the same information is a cause of confusion and error.
> > > > >
> > > > > I would think almost all of the MGC code wouldn't know the
> > > > > difference.
> > > > >
> > > > > Brian
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Stephen Terrill [mailto:stephen.terrill@ERICSSON.COM]
> > > > > > Sent: Monday, April 17, 2000 3:23 AM
> > > > > > To: MEGACO@standards.nortelnetworks.com
> > > > > > Subject: Re: MEGACO and Dial Pulse Lines
> > > > > >
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I was trying to find the correct message from this thread =
to
> > > > > > respond to, so I would hitch it onto this.
> > > > > >
> > > > > > I would think that MGC shouldn=B4t be concerned with how =
the
> > > > > > digits were detected.  The MGC is requesting to detect
> > > > > > digits, and wether they are pulsed or DTMF shouldn=B4t =
matter -
> > > > > > this is matter of hardware.
> > > > > >
> > > > > > Of course there is an issue of configuration, to have the
> > > > > > terminal adapter (or line card) to be set for the type of
> > > > > > subcriber, however I haven=B4t viewed H.248 as a =
configuration
> > > > > > protocol - I understood that was done in other ways.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > ..//steve
> > > > > >
> > > > > > "Rosen, Brian" wrote:
> > > > > >
> > > > > > > > I agree with George, since POTS transparency is key.
> > > > > > > >
> > > > > > > > It appears that a "Dial pulse" package is needed to =
inform
> > > > > > > > the MG of the
> > > > > > > > dial pulse characteristics (PPS, Make/Break Ratio). =
What
> else?
> > > > > > > >
> > > > > > > > What is the process for creating such a package? Can =
anyone
> > > > > > > > create an IETF
> > > > > > > > draft?
> > > > > > > >
> > > > > > > Anyone can create a DRAFT.  Just write it up in the
> > > > proper format
> > > > > > > and email it to the Internet Drafts editor.
> > > > > > >
> > > > > > > Now, if you want IETF to DO anything with it, some =
working
> group
> > > > > > > (for example, Megaco) has to adopt it as a work item, and
> agree
> > > > > > > to turn it into an rfc (through it's consensus process).  =
I'd
> > > > > > > suspect we would be willing to do this for a dial pulse
> package,
> > > > > > > but that is up to the group to decide.
> > > > > > >
> > > > > > > Brian
> > > > > > > >
> > > > > >
> > > > << File: Card for Alf  Heidermark >>=20

------_=_NextPart_001_01BFA938.7F933600
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: MEGACO and Dial Pulse Lines</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I think there are =
differences in technology that have to be accounted for, so we may not =
escape having to distinguish DTMF from DP in separate packages.&nbsp; =
The MGC can't expect a DP set to dial * or #, for instance.&nbsp; The =
billing issue is clearly one of operator policy.&nbsp; That means we =
have to supply the option to support it, not restrict operator =
actions.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Anyway, the whole =
question is moot until someone submits a DP package.</FONT>
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Alf Heidermark =
[SMTP:Alf.Heidermark@UAB.ERICSSON.SE]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Tuesday, April 18, 2000 8:28 AM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Re: MEGACO and Dial Pulse =
Lines</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">This requriment for billing of the =
feature cannot be manndatory in all</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">networks. This means that the MGC =
does not have to be aware of whether</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">it is pulse or DTMF. The MG must be =
able to find out itself.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Stephen Terrill wrote:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; The only reason that I saw =
suggested that the MGC needed it was for &quot;billling&quot; - not =
charging, but billing (and that is&nbsp; very operator =
dependant).&nbsp; It is not necessary that the billing is done on the =
MGC, but maybe another system again (this is quite common), as such I =
don=B4t see why the MGC needs to be bothered with such hardware =
details.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Regards,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; ..//steve</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &quot;Rosen, Brian&quot; =
wrote:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; Since the MGC needs it, and =
the MG needs it, you do it in the MGC and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; let it program the =
MG.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; Provisioning might be evil, =
but it's not totally unavoidable yet!</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; Brian</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; -----Original =
Message-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; From: Stephen Terrill =
[<U></U></FONT><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"mailto:stephen.terrill@ericsson.com">mailto:stephen.terrill@eric=
sson.com</A></FONT></U><FONT SIZE=3D2 FACE=3D"Arial">]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; Sent: Tuesday, April =
18, 2000 1:57 AM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; To: Rosen, =
Brian</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; Cc: =
MEGACO@standards.nortelnetworks.com</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; Subject: Re: MEGACO =
and Dial Pulse Lines</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; Hi Brian,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; Now you are just =
argueing where to do the provisoning, not</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; that provisoning can =
be avoided.&nbsp; As it has to be done</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; somewhere, why the =
MGC?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; ..//steve</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &quot;Rosen, =
Brian&quot; wrote:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; This is another =
&quot;provision vs. program&quot; argument.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; Yes, you could =
provision the timing characteristics.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; Since I think =
provisioning is evil, I'd prefer the MGC do it.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; As was pointed =
out, the MGC has to know if DTMF is &quot;enabled&quot;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; on the line, =
possibly for billing.&nbsp; Having to have two parts</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; with the same =
information is a cause of confusion and error.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; I would think =
almost all of the MGC code wouldn't know the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; =
difference.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; Brian</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt; =
-----Original Message-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt; From: =
Stephen Terrill [</FONT><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial"><A =
HREF=3D"mailto:stephen.terrill@ERICSSON.COM">mailto:stephen.terrill@ERIC=
SSON.COM</A></FONT></U><FONT SIZE=3D2 FACE=3D"Arial">]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt; Sent: =
Monday, April 17, 2000 3:23 AM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt; To: =
MEGACO@standards.nortelnetworks.com</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt; Subject: Re: =
MEGACO and Dial Pulse Lines</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt; Hi,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt; I was trying =
to find the correct message from this thread to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt; respond to, =
so I would hitch it onto this.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt; I would =
think that MGC shouldn=B4t be concerned with how the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt; digits were =
detected.&nbsp; The MGC is requesting to detect</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt; digits, and =
wether they are pulsed or DTMF shouldn=B4t matter -</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt; this is =
matter of hardware.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt; Of course =
there is an issue of configuration, to have the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt; terminal =
adapter (or line card) to be set for the type of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt; subcriber, =
however I haven=B4t viewed H.248 as a configuration</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt; protocol - I =
understood that was done in other ways.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt; =
Regards,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt; =
..//steve</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt; &quot;Rosen, =
Brian&quot; wrote:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt; &gt; &gt; I =
agree with George, since POTS transparency is key.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt; &gt; =
&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt; &gt; &gt; It =
appears that a &quot;Dial pulse&quot; package is needed to =
inform</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt; &gt; &gt; =
the MG of the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt; &gt; &gt; =
dial pulse characteristics (PPS, Make/Break Ratio). What else?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt; &gt; =
&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt; &gt; &gt; =
What is the process for creating such a package? Can anyone</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt; &gt; &gt; =
create an IETF</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt; &gt; &gt; =
draft?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt; &gt; =
&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt; &gt; Anyone =
can create a DRAFT.&nbsp; Just write it up in the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; proper format</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt; &gt; and =
email it to the Internet Drafts editor.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt; &gt; Now, if =
you want IETF to DO anything with it, some working group</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt; &gt; (for =
example, Megaco) has to adopt it as a work item, and agree</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt; &gt; to turn =
it into an rfc (through it's consensus process).&nbsp; I'd</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt; &gt; suspect =
we would be willing to do this for a dial pulse package,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt; &gt; but =
that is up to the group to decide.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt; &gt; =
Brian</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt; &gt; =
&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; &lt;&lt; File: Card =
for Alf&nbsp; Heidermark &gt;&gt; </FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFA938.7F933600--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr 18 09:25:28 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04085
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 18 Apr 2000 09:25:28 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1F9A4890@standards.nortelnetworks.com>; Tue, 18 Apr 2000 9:18:56 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6424 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 18 Apr 2000 09:17:50 -0400
Received: from smtprtp1.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.F82210E0@standards.nortelnetworks.com>; Tue, 18 Apr 2000 9:17:50
          -0400
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          smtprtp1.ntcom.nortel.net; Tue, 18 Apr 2000 09:23:27 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <27B9L2JW>; Tue, 18 Apr 2000 09:23:27 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFA939.4725EDA2"
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B6B6@zcard00g.ca.nortel.com>
Date:         Tue, 18 Apr 2000 09:23:24 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Context Termination Audit
X-To:         Shalini Philip <sphilip@FICON-TECH.COM>
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_01BFA939.4725EDA2
Content-Type: text/plain

I realized on re-examination of the question that it was not an issue.  See
my detailed comments in the message I sent in thread "Re: V16 Review -
Auditing contexts and their terminations" on Thu 4/13/00 3:12 PM EDT.

> -----Original Message-----
> From: Shalini Philip [SMTP:sphilip@FICON-TECH.COM]
> Sent: Tuesday, April 18, 2000 8:42 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Context Termination Audit
>
> Hello all,
>
>     In the last summary of issues mail sent by Tom Taylor, there was an
> item as the following:
>
>    7.2.5,     Text and ASN.1 allow return     Fix production
>    B.2        of results involving multiple
> contextTerminationAudit
>               contexts, but ABNF does not.       by allowing return of
>                                                                    list
> of context-specific
>
> results as an
>
> alternative.
>
> Can anyone please give the ABNF fix for this, or a pointer to some
> earlier mail containing the required information? Are we going by the
> solution proposed by Nancy and Abdallah in their mail on 23rd March 2000
> with subject "V16 Review - Auditing Contexts and their terminations".
>
>
> Thanks & Regards,
>
> Shalini Philip
> Ficon Technology
> E-Mail : mailto:sphilip@ficon-tech.com
> Web    : http://www.ficon-tech.com

------_=_NextPart_001_01BFA939.4725EDA2
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: Context Termination Audit</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I realized on =
re-examination of the question that it was not an issue.&nbsp; See my =
detailed comments in the message I sent in thread &quot;Re: V16 Review =
- Auditing contexts and their terminations&quot; on Thu 4/13/00 3:12 PM =
EDT.</FONT></P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Shalini Philip =
[SMTP:sphilip@FICON-TECH.COM]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Tuesday, April 18, 2000 8:42 AM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Context Termination Audit</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hello all,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; In the last summary =
of issues mail sent by Tom Taylor, there was an</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">item as the following:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; =
7.2.5,&nbsp;&nbsp;&nbsp;&nbsp; Text and ASN.1 allow =
return&nbsp;&nbsp;&nbsp;&nbsp; Fix production</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; =
B.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of results involving =
multiple</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">contextTerminationAudit</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; contexts, but ABNF does =
not.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; by allowing return of</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; list</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">of context-specific</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">results as an</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">alternative.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Can anyone please give the ABNF fix =
for this, or a pointer to some</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">earlier mail containing the required =
information? Are we going by the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">solution proposed by Nancy and =
Abdallah in their mail on 23rd March 2000</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">with subject &quot;V16 Review - =
Auditing Contexts and their terminations&quot;.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks &amp; Regards,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Shalini Philip</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Ficon Technology</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">E-Mail :<U> </U></FONT><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"mailto:sphilip@ficon-tech.com">mailto:sphilip@ficon-tech.com</A>=
</FONT></U>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Web&nbsp;&nbsp;&nbsp; :</FONT><U> =
<FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://www.ficon-tech.com" =
TARGET=3D"_blank">http://www.ficon-tech.com</A></FONT></U>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFA939.4725EDA2--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr 18 09:31:24 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04355
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 18 Apr 2000 09:31:23 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F7793140@standards.nortelnetworks.com>; Tue, 18 Apr 2000 9:24:59 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6444 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 18 Apr 2000 09:23:35 -0400
Received: from ficon-tech.com (12.10.198.190) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.BD5E5080@standards.nortelnetworks.com>; Tue, 18 Apr 2000 9:23:21
          -0400
Received: from hemantag (vacant4.india.ficon-tech.com [172.25.1.131]) by
          ficon-tech.com (8.9.3/8.8.7) with SMTP id SAA86562 for
          <megaco@standards.nortelnetworks.com>; Tue, 18 Apr 2000 18:58:58
          +0530 (IST) (envelope-from hemantag@ficon-tech.com)
References: <38FBE1C0.7133B244@ficon-tech.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Message-ID:  <127c01bfa93a$1189bce0$830119ac@india.ficontech.com>
Date:         Tue, 18 Apr 2000 18:58:50 +0530
Reply-To: Hemant Agrawal <hemantag@FICON-TECH.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Hemant Agrawal <hemantag@FICON-TECH.COM>
Organization: Ficon Technology
Subject:      Re: Test ServiceState in Termination State Descriptor]
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi Brown, list,

 My comments are inserted inline with HA>


> The test state is different from "in service" in that a termination can be
"in
> service", "OOS", "in service - test" or "OOS - test".
>

HA>  In TerminationStateDescriptor, ServiceState has only three valid
states, IS, OOS and Test. There is no state as "IS-TEST" or "OOS-TEST". The
state "test" is independent of the IS or OOS state.

> I would say that there are no specific actions which would be applied
simply by placing the line in the
> test state.
>
 HA> Agreed. (In fact that's what we have said)
>
> In my opinion, it would be something of a flag to indicate that the
signals and
> events associated with test package could be applied to a termination.
>
> The behavior associated with those signals and events would be defined as
part of
> the package and may be different depending on whether the termination is
IS or
> OOS.
>
> I would think that the intelligence to determine whether or not to apply a
> particular signal or event would be under the control of the MGC or a
> maintenance interface, but it might be desirable for an implementation in
the MG
> to do some minimal defensive coding to prevent MGC or maintenance request
> "mistakes".
>
 HA> is it that when the termination is not in test state, then the MG
should  not allow test events and signals to be applied ? What happens to
the test  signals & events when a termination which is in test state moves
to a IS state -
 does the MG stop those signals and events ?

>I do agree that the intelligence for handling the test state should be
driven by
> the MGC and actions taken in the MG implemented in packages. One of the
reasons
> I believe that the test state is needed is to have this knowledge
available
> associated with the termination in the event of the MG performing a
failover to
> a secondary MGC. The MGC could determine those terminations which were
under
> test using audit mechanisms and could then take action accordingly.
>
> Regarding your last question, I would say that the MG would behave no
> differently in allocating a termination on a CHOOSE when it is IS-test or
IS.
> The point is that the termination should be used as IS except that
specified
> test functions will be performed (under MGC control) during normal use.

HA> Agreed

> I am currently in process of working with Nortel development groups on
producing
> a test package for line test functions. This will be coming out in the
near
> future and I think it will help to further clarify my comments.
>

Regards,
Hemant Agrawal

>
> Hemant Agrawal wrote:
>
> > Hi All,
> >         I have few questions related to serviceState in
> > terminationStatedDescriptor.
> > TerminationStateDescriptor has three values for serviceState : In
Service,
> > Out Of Service and Test.
> > The draft mentions "The state "test" indicates that the termination is
being
> > tested" (sec 7.1.5 para 2).
> >
> > How is "test" state different from "in service"? Is their any special
action
> > to be taken by MG, when it receives a termination state to be set as
test.
> >
> > Does it mean that if the said termination supports test packages, the
events
> > , signals etc pertaining to these can be applied only in test state.
Also in
> > that case what happens to the non "test" package events and signals. Are
> > they stopped by the MG on getting service state property as "test" and
vice
> > versa.
> >
> > I think this differentiation between what constitutes test and what not
> > should not be done at MG level. But in that case how from an MG point of
> > view, are the service states "test" and "in service" different ?
> >
> > Another question in this regards. Should the MG "prefer" allocating  "in
> > service" terminations over terminations with service state "test" while
> > resolving CHOOSE in Add.
> >
> > Thanks in advance,
> > Hemant Agrawal
> >
> > ________________________________________
> > Hemant Agrawal
> > Ficon Technology
> > E-mail: hemantag@ficon-tech.com
> > Web: http://www.ficon-tech.com
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr 18 09:39:29 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04495
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 18 Apr 2000 09:39:28 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.16738810@standards.nortelnetworks.com>; Tue, 18 Apr 2000 9:33:00 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6460 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 18 Apr 2000 09:31:23 -0400
Received: from smtprtp.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.DC72E610@standards.nortelnetworks.com>; Tue, 18 Apr 2000 9:31:23
          -0400
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          smtprtp.ntcom.nortel.net; Tue, 18 Apr 2000 09:37:16 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <27B9L27R>; Tue, 18 Apr 2000 09:37:16 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFA93B.35CD302C"
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B6B9@zcard00g.ca.nortel.com>
Date:         Tue, 18 Apr 2000 09:37:14 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Test ServiceState in Termination State Descriptor]
X-To:         Hemant Agrawal <hemantag@FICON-TECH.COM>
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_01BFA93B.35CD302C
Content-Type: text/plain;
        charset="iso-8859-1"

I'd say the states are mainly useful to coordinate between multiple entities
-- in failover cases, as Brian has mentioned, and when maintenance access to
the MG has to be reflected to the MGC.  I guess we do need discussions such
as the one you have initiated to decide on the operational significance of
these states.

> -----Original Message-----
> From: Hemant Agrawal [SMTP:hemantag@FICON-TECH.COM]
> Sent: Tuesday, April 18, 2000 9:29 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: Test ServiceState in Termination State Descriptor]
>
> Hi Brown, list,
>
>  My comments are inserted inline with HA>
>
>
> > The test state is different from "in service" in that a termination can
> be
> "in
> > service", "OOS", "in service - test" or "OOS - test".
> >
>
> HA>  In TerminationStateDescriptor, ServiceState has only three valid
> states, IS, OOS and Test. There is no state as "IS-TEST" or "OOS-TEST".
> The
> state "test" is independent of the IS or OOS state.
>
> > I would say that there are no specific actions which would be applied
> simply by placing the line in the
> > test state.
> >
>  HA> Agreed. (In fact that's what we have said)
> >
> > In my opinion, it would be something of a flag to indicate that the
> signals and
> > events associated with test package could be applied to a termination.
> >
> > The behavior associated with those signals and events would be defined
> as
> part of
> > the package and may be different depending on whether the termination is
> IS or
> > OOS.
> >
> > I would think that the intelligence to determine whether or not to apply
> a
> > particular signal or event would be under the control of the MGC or a
> > maintenance interface, but it might be desirable for an implementation
> in
> the MG
> > to do some minimal defensive coding to prevent MGC or maintenance
> request
> > "mistakes".
> >
>  HA> is it that when the termination is not in test state, then the MG
> should  not allow test events and signals to be applied ? What happens to
> the test  signals & events when a termination which is in test state moves
> to a IS state -
>  does the MG stop those signals and events ?
>
> >I do agree that the intelligence for handling the test state should be
> driven by
> > the MGC and actions taken in the MG implemented in packages. One of the
> reasons
> > I believe that the test state is needed is to have this knowledge
> available
> > associated with the termination in the event of the MG performing a
> failover to
> > a secondary MGC. The MGC could determine those terminations which were
> under
> > test using audit mechanisms and could then take action accordingly.
> >
> > Regarding your last question, I would say that the MG would behave no
> > differently in allocating a termination on a CHOOSE when it is IS-test
> or
> IS.
> > The point is that the termination should be used as IS except that
> specified
> > test functions will be performed (under MGC control) during normal use.
>
> HA> Agreed
>
> > I am currently in process of working with Nortel development groups on
> producing
> > a test package for line test functions. This will be coming out in the
> near
> > future and I think it will help to further clarify my comments.
> >
>
> Regards,
> Hemant Agrawal
>
> >
> > Hemant Agrawal wrote:
> >
> > > Hi All,
> > >         I have few questions related to serviceState in
> > > terminationStatedDescriptor.
> > > TerminationStateDescriptor has three values for serviceState : In
> Service,
> > > Out Of Service and Test.
> > > The draft mentions "The state "test" indicates that the termination is
> being
> > > tested" (sec 7.1.5 para 2).
> > >
> > > How is "test" state different from "in service"? Is their any special
> action
> > > to be taken by MG, when it receives a termination state to be set as
> test.
> > >
> > > Does it mean that if the said termination supports test packages, the
> events
> > > , signals etc pertaining to these can be applied only in test state.
> Also in
> > > that case what happens to the non "test" package events and signals.
> Are
> > > they stopped by the MG on getting service state property as "test" and
> vice
> > > versa.
> > >
> > > I think this differentiation between what constitutes test and what
> not
> > > should not be done at MG level. But in that case how from an MG point
> of
> > > view, are the service states "test" and "in service" different ?
> > >
> > > Another question in this regards. Should the MG "prefer" allocating
> "in
> > > service" terminations over terminations with service state "test"
> while
> > > resolving CHOOSE in Add.
> > >
> > > Thanks in advance,
> > > Hemant Agrawal
> > >
> > > ________________________________________
> > > Hemant Agrawal
> > > Ficon Technology
> > > E-mail: hemantag@ficon-tech.com
> > > Web: http://www.ficon-tech.com
> >

------_=_NextPart_001_01BFA93B.35CD302C
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: Test ServiceState in Termination State Descriptor]</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I'd say the states =
are mainly useful to coordinate between multiple entities -- in =
failover cases, as Brian has mentioned, and when maintenance access to =
the MG has to be reflected to the MGC.&nbsp; I guess we do need =
discussions such as the one you have initiated to decide on the =
operational significance of these states.</FONT></P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Hemant Agrawal =
[SMTP:hemantag@FICON-TECH.COM]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Tuesday, April 18, 2000 9:29 AM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Re: Test ServiceState in Termination =
State Descriptor]</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi Brown, list,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;My comments are inserted inline =
with HA&gt;</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; The test state is different from =
&quot;in service&quot; in that a termination can be</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&quot;in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; service&quot;, &quot;OOS&quot;, =
&quot;in service - test&quot; or &quot;OOS - test&quot;.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">HA&gt;&nbsp; In =
TerminationStateDescriptor, ServiceState has only three valid</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">states, IS, OOS and Test. There is no =
state as &quot;IS-TEST&quot; or &quot;OOS-TEST&quot;. The</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">state &quot;test&quot; is independent =
of the IS or OOS state.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; I would say that there are no =
specific actions which would be applied</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">simply by placing the line in =
the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; test state.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;HA&gt; Agreed. (In fact that's =
what we have said)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; In my opinion, it would be =
something of a flag to indicate that the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">signals and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; events associated with test =
package could be applied to a termination.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; The behavior associated with =
those signals and events would be defined as</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">part of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; the package and may be different =
depending on whether the termination is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">IS or</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; OOS.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; I would think that the =
intelligence to determine whether or not to apply a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; particular signal or event would =
be under the control of the MGC or a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; maintenance interface, but it =
might be desirable for an implementation in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the MG</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; to do some minimal defensive =
coding to prevent MGC or maintenance request</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &quot;mistakes&quot;.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;HA&gt; is it that when the =
termination is not in test state, then the MG</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">should&nbsp; not allow test events =
and signals to be applied ? What happens to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the test&nbsp; signals &amp; events =
when a termination which is in test state moves</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">to a IS state -</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;does the MG stop those signals =
and events ?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt;I do agree that the intelligence =
for handling the test state should be</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">driven by</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; the MGC and actions taken in the =
MG implemented in packages. One of the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">reasons</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; I believe that the test state is =
needed is to have this knowledge</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">available</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; associated with the termination =
in the event of the MG performing a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">failover to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; a secondary MGC. The MGC could =
determine those terminations which were</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">under</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; test using audit mechanisms and =
could then take action accordingly.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Regarding your last question, I =
would say that the MG would behave no</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; differently in allocating a =
termination on a CHOOSE when it is IS-test or</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">IS.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; The point is that the =
termination should be used as IS except that</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">specified</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; test functions will be performed =
(under MGC control) during normal use.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">HA&gt; Agreed</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; I am currently in process of =
working with Nortel development groups on</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">producing</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; a test package for line test =
functions. This will be coming out in the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">near</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; future and I think it will help =
to further clarify my comments.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Regards,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Hemant Agrawal</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Hemant Agrawal wrote:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; Hi All,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; =
&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I have few =
questions related to serviceState in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; =
terminationStatedDescriptor.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; TerminationStateDescriptor =
has three values for serviceState : In</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Service,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; Out Of Service and =
Test.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; The draft mentions =
&quot;The state &quot;test&quot; indicates that the termination =
is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">being</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; tested&quot; (sec 7.1.5 =
para 2).</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; How is &quot;test&quot; =
state different from &quot;in service&quot;? Is their any =
special</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">action</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; to be taken by MG, when it =
receives a termination state to be set as</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">test.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; Does it mean that if the =
said termination supports test packages, the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">events</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; , signals etc pertaining to =
these can be applied only in test state.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Also in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; that case what happens to =
the non &quot;test&quot; package events and signals. Are</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; they stopped by the MG on =
getting service state property as &quot;test&quot; and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">vice</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; versa.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; I think this =
differentiation between what constitutes test and what not</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; should not be done at MG =
level. But in that case how from an MG point of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; view, are the service =
states &quot;test&quot; and &quot;in service&quot; different ?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; Another question in this =
regards. Should the MG &quot;prefer&quot; allocating&nbsp; =
&quot;in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; service&quot; terminations =
over terminations with service state &quot;test&quot; while</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; resolving CHOOSE in =
Add.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; Thanks in advance,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; Hemant Agrawal</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; =
________________________________________</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; Hemant Agrawal</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; Ficon Technology</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; E-mail: =
hemantag@ficon-tech.com</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; Web:<U> </U></FONT><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://www.ficon-tech.com" =
TARGET=3D"_blank">http://www.ficon-tech.com</A></FONT></U>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFA93B.35CD302C--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr 18 10:28:37 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05208
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 18 Apr 2000 10:28:36 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F0E9FCD0@standards.nortelnetworks.com>; Tue, 18 Apr 2000 10:22:04 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6496 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 18 Apr 2000 10:20:43 -0400
Received: from ficon-tech.com (12.10.198.190) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.59D07550@standards.nortelnetworks.com>; Tue, 18 Apr 2000 10:10:41
          -0400
Received: from hgupta (hkumar.india.ficon-tech.com [172.25.1.130]) by
          ficon-tech.com (8.9.3/8.8.7) with SMTP id TAA88468 for
          <megaco@standards.nortelnetworks.com>; Tue, 18 Apr 2000 19:46:43
          +0530 (IST) (envelope-from hkumar@ficon-tech.com)
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_0049_01BFA96E.CD2F7780"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Message-ID:  <004c01bfa940$b53c6b20$820119ac@india.ficontech.com>
Date:         Tue, 18 Apr 2000 19:46:33 +0530
Reply-To: Hemant Kumar <hkumar@FICON-TECH.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Hemant Kumar <hkumar@FICON-TECH.COM>
Subject:      Re: Service State Property "Out of Service"
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_0049_01BFA96E.CD2F7780
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Michael, list,

    I please find my commnet below (marked <HKG> below)

Regards,
Hemant

----- Original Message -----
From: Michael Brown <C.Michael.Brown@NORTELNETWORKS.COM>
To: <MEGACO@standards.nortelnetworks.com>
Sent: Tuesday, April 18, 2000 4:07 AM
Subject: Re: Service State Property "Out of Service"


> Comments inserted inline with <MB>.
>
> Hemant wrote:
>
> > Hi Brian, list,     I wish to discuss some issues with handling of
> > service state property value "Out of Service" (OOS). The draft
> > mentions "The state "out of service" indicates that the termination
> > cannot be used for traffic" (sec 7.1.5 para 2). This is fine for the
> > terminations which are made OOS in null context as terminations can
> > only be Added with non "out of service" state. But what about the
> > following : 1) Is a command specifying Service State as OOS valid =
for
> > a termination in a non null context ?If it is valid, what is the MG
> > expected to do ? Should it stop traffic and deallocate all the
> > resources allocated for that termination and let the termination
> > remain in non null context? What will happen if this termination is
> > made "in-service" again. The MG would have to allocate all the
> > resources (according to the command in which the termination state
> > change is specified as in service) for this termination and add it =
to
> > the context. That is the MG would do all the handling that is =
required
> > to "Add" the termination in the context. Then what is being gained =
by
> > keeping a OOS termination in a non-NULL context ?
> >
> > <MB> Actually, I would expect that the MG would continue to do what =
it
> > is told to do either through control of the MGC or perhaps a
> > maintenance interface. The decision as to whether/when the =
termination
> > would stop traffic and deallocate resources would be based on the =
type
> > of service change requested (e.g., forced, etc.)

    <HKG>  What I meant to ask was what does the MG do on receiving =
service state OOS in Termination state descriptor. Service change =
handling is already specified in the draft.

The use for an OOS
> > termination in a non-null context is that that there are a number of
> > OOS tests which could be performed which would be easier modelled by
> > placing the termination into a context and potentially adding test
> > terminations to the context to perform those functions such as =
making
> > a test call to or from the OOS termination. I do not believe that =
the
> > operation should be made invalid.
> >
    <HKG> If tests have to be performed, I think that the MGC should set =
the
service state (in Termination State Descriptor) to Test rather than OOS.

> >   Suggestion : I would suggest that operation should be made =
invalid.
> > The MGC should first bring the termination out of context by
> > explicitly subtracting the termination. Another option is specifying
> > that setting state to OOS does an implicit subtract (just like mux
> > results in an implicit Add). But in this option what would a command
> > containing Stream desc. with non null Local or Remote mean ? Should
> > resource reservation implied by these be neglected ? I don't know =
why
> > one would like to make a temination OOS and then hold resources for
> > that same termination. 2) Assume that the state of a termination in
> > null context is In service. An add command for that termination is
> > received and in that command the termination state set to OOS. Is =
that
> > a valid command ? Suggestion : I think this should also be =
considered
> > invalid going by the logic which prevents an already OOS termination
> > to be added to a context. Can it be said then that changing the =
state
> > of a termination to OOS is valid only under following circumstances
> > :    - In null context.    - By Modify command.    - Without any =
Local
> > and Remote Descriptor.
> >
> > <MB> I would say that the command you have suggested is indeed
> > invalid. I think you meant to suggest that a transaction might =
contain
> > both an ADD command and a ServiceChange command and that this
> > combination should be invalid. I again do not agree that this should
> > be considered invalid, although I would think it somewhat unlikely
> > that one would want to do so.
> >

    <HKG> Please note that here I am referring to setting service state =
property in Termination state descriptor and what is meant is that an =
add command may contain service state OOS which I think is invalid. As =
for the case you have mentioned above I don't think that validation =
falls within the purview of the MG. Within an action, the MG should =
consider commands according to their priority.
Apologies for any underspecifications.

> >   comments please ....

Regards,
Hemant Kumar

~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hemant Kumar
Ficon Technology
E-mail: mailto:hkumar@ficon-tech.com
Web: http://www.ficon-tech.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

------=_NextPart_000_0049_01BFA96E.CD2F7780
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#c0c0c0>
<DIV><FONT face=3DArial size=3D2>Hi Michael, =
list,<BR><BR>&nbsp;&nbsp;&nbsp; I=20
please find my commnet below (marked &lt;HKG&gt;=20
below)<BR><BR>Regards,<BR>Hemant<BR><BR>----- Original Message =
-----<BR>From:=20
Michael Brown &lt;<A=20
href=3D"mailto:C.Michael.Brown@NORTELNETWORKS.COM">C.Michael.Brown@NORTEL=
NETWORKS.COM</A>&gt;<BR>To:=20
&lt;<A=20
href=3D"mailto:MEGACO@standards.nortelnetworks.com">MEGACO@standards.nort=
elnetworks.com</A>&gt;<BR>Sent:=20
Tuesday, April 18, 2000 4:07 AM<BR>Subject: Re: Service State Property =
"Out of=20
Service"<BR><BR><BR>&gt; Comments inserted inline with=20
&lt;MB&gt;.<BR>&gt;<BR>&gt; Hemant wrote:<BR>&gt;<BR>&gt; &gt; Hi Brian, =

list,&nbsp;&nbsp;&nbsp;&nbsp; I wish to discuss some issues with =
handling=20
of<BR>&gt; &gt; service state property value "Out of Service" (OOS). The =

draft<BR>&gt; &gt; mentions "The state "out of service" indicates that =
the=20
termination<BR>&gt; &gt; cannot be used for traffic" (sec 7.1.5 para 2). =
This is=20
fine for the<BR>&gt; &gt; terminations which are made OOS in null =
context as=20
terminations can<BR>&gt; &gt; only be Added with non "out of service" =
state. But=20
what about the<BR>&gt; &gt; following : 1) Is a command specifying =
Service State=20
as OOS valid for<BR>&gt; &gt; a termination in a non null context ?If it =
is=20
valid, what is the MG<BR>&gt; &gt; expected to do ? Should it stop =
traffic and=20
deallocate all the<BR>&gt; &gt; resources allocated for that termination =
and let=20
the termination<BR>&gt; &gt; remain in non null context? What will =
happen if=20
this termination is<BR>&gt; &gt; made "in-service" again. The MG would =
have to=20
allocate all the<BR>&gt; &gt; resources (according to the command in =
which the=20
termination state<BR>&gt; &gt; change is specified as in service) for =
this=20
termination and add it to<BR>&gt; &gt; the context. That is the MG would =
do all=20
the handling that is required<BR>&gt; &gt; to "Add" the termination in =
the=20
context. Then what is being gained by<BR>&gt; &gt; keeping a OOS =
termination in=20
a non-NULL context ?<BR>&gt; &gt;<BR>&gt; &gt; &lt;MB&gt; Actually, I =
would=20
expect that the MG would continue to do what it<BR>&gt; &gt; is told to =
do=20
either through control of the MGC or perhaps a<BR>&gt; &gt; maintenance=20
interface. The decision as to whether/when the termination<BR>&gt; &gt; =
would=20
stop traffic and deallocate resources would be based on the type<BR>&gt; =
&gt; of=20
service change requested (e.g., forced, etc.)<BR><BR>&nbsp;&nbsp;&nbsp;=20
&lt;HKG&gt;&nbsp;&nbsp;What I meant to ask was what does the MG&nbsp;do =
on=20
receiving service state OOS in Termination state descriptor. Service =
change=20
handling is already specified in the draft.<BR><BR>The use for an =
OOS<BR>&gt;=20
&gt; termination in a non-null context is that that there are a number=20
of<BR>&gt; &gt; OOS tests which could be performed which would be easier =

modelled by<BR>&gt; &gt; placing the termination into a context and =
potentially=20
adding test<BR>&gt; &gt; terminations to the context to perform those =
functions=20
such as making<BR>&gt; &gt; a test call to or from the OOS termination. =
I do not=20
believe that the<BR>&gt; &gt; operation should be made invalid.<BR>&gt;=20
&gt;<BR>&nbsp;&nbsp;&nbsp; &lt;HKG&gt; If tests have to be performed, I =
think=20
that the MGC should set the<BR>service state (in Termination State =
Descriptor)=20
to Test rather than OOS.<BR><BR>&gt; &gt;&nbsp;&nbsp; Suggestion : I =
would=20
suggest that operation should be made invalid.<BR>&gt; &gt; The MGC =
should first=20
bring the termination out of context by<BR>&gt; &gt; explicitly =
subtracting the=20
termination. Another option is specifying<BR>&gt; &gt; that setting =
state to OOS=20
does an implicit subtract (just like mux<BR>&gt; &gt; results in an =
implicit=20
Add). But in this option what would a command<BR>&gt; &gt; containing =
Stream=20
desc. with non null Local or Remote mean ? Should<BR>&gt; &gt; resource=20
reservation implied by these be neglected ? I don't know why<BR>&gt; =
&gt; one=20
would like to make a temination OOS and then hold resources for<BR>&gt; =
&gt;=20
that same termination. 2) Assume that the state of a termination =
in<BR>&gt; &gt;=20
null context is In service. An add command for that termination =
is<BR>&gt; &gt;=20
received and in that command the termination state set to OOS. Is =
that<BR>&gt;=20
&gt; a valid command ? Suggestion : I think this should also be=20
considered<BR>&gt; &gt; invalid going by the logic which prevents an =
already OOS=20
termination<BR>&gt; &gt; to be added to a context. Can it be said then =
that=20
changing the state<BR>&gt; &gt; of a termination to OOS is valid only =
under=20
following circumstances<BR>&gt; &gt; :&nbsp;&nbsp;&nbsp; - In null=20
context.&nbsp;&nbsp;&nbsp; - By Modify command.&nbsp;&nbsp;&nbsp; - =
Without any=20
Local<BR>&gt; &gt; and Remote Descriptor.<BR>&gt; &gt;<BR>&gt; &gt; =
&lt;MB&gt; I=20
would say that the command you have suggested is indeed<BR>&gt; &gt; =
invalid. I=20
think you meant to suggest that a transaction might contain<BR>&gt; &gt; =
both an=20
ADD command and a ServiceChange command and that this<BR>&gt; &gt; =
combination=20
should be invalid. I again do not agree that this should<BR>&gt; &gt; be =

considered invalid, although I would think it somewhat unlikely<BR>&gt; =
&gt;=20
that one would want to do so.<BR>&gt; &gt;<BR><BR>&nbsp;&nbsp;&nbsp; =
&lt;HKG&gt;=20
Please note that here I am referring to setting service state property =
in=20
Termination state descriptor and what is meant is that an add command =
may=20
contain service state OOS which I think is invalid.&nbsp;</FONT><FONT =
face=3DArial=20
size=3D2>As for the case you have mentioned above I don't think that =
validation=20
falls within the purview of the MG. Within an action, the MG should =
consider=20
commands according to their priority.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Apologies for any =
underspecifications.<BR><BR>&gt;=20
&gt;&nbsp;&nbsp; comments please ....<BR><BR>Regards,<BR>Hemant=20
Kumar</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>~~~~~~~~~~~~~~~~~~~~~~~~~~~~<BR>Hemant=20
Kumar<BR>Ficon Technology<BR>E-mail: <A=20
href=3D"mailto:hkumar@ficon-tech.com">mailto:hkumar@ficon-tech.com</A><BR=
>Web: <A=20
href=3D"http://www.ficon-tech.com">http://www.ficon-tech.com</A><BR>~~~~~=
~~~~~~~~~~~~~~~~~~~~~~~</FONT></DIV></BODY></HTML>

------=_NextPart_000_0049_01BFA96E.CD2F7780--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr 18 10:46:36 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05459
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 18 Apr 2000 10:46:35 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.76605470@standards.nortelnetworks.com>; Tue, 18 Apr 2000 10:40:06 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6519 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 18 Apr 2000 10:38:27 -0400
Received: from ficon-tech.com (12.10.198.190) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.D3E08EA0@standards.nortelnetworks.com>; Tue, 18 Apr 2000 10:28:24
          -0400
Received: from hgupta (hkumar.india.ficon-tech.com [172.25.1.130]) by
          ficon-tech.com (8.9.3/8.8.7) with SMTP id UAA88705 for
          <megaco@standards.nortelnetworks.com>; Tue, 18 Apr 2000 20:04:27
          +0530 (IST) (envelope-from hkumar@ficon-tech.com)
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_0066_01BFA971.474B9EC0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Message-ID:  <006901bfa943$2f4642e0$820119ac@india.ficontech.com>
Date:         Tue, 18 Apr 2000 20:04:17 +0530
Reply-To: Hemant Kumar <hkumar@FICON-TECH.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Hemant Kumar <hkumar@FICON-TECH.COM>
Subject:      Re: Service State Property "Out of Service"
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_0066_01BFA971.474B9EC0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Brian, Tom, list,

    Pls consider the following comments ( inlined <HKG> )

Regards and thanks,
Hemant Kumar

    ----- Original Message -----
From: Rosen, Brian
To: Hemant ; MEGACO@standards.nortelnetworks.com
Sent: Tuesday, April 18, 2000 4:59 AM
Subject: RE: Service State Property "Out of Service"


I'd think you should not set a termination out of service unless it was =
in
null context (and thus would not have any media streams).

<HKG> I Agree. Regarding what Michael mentioned test might have to be
carried out in OOS state. I think that should be done in the service =
state
"Test" rather than "OOS"

Whether it should be illegal is another question.  I don't care.  I =
would
not
want setting the property to have side effects like moving to null, etc.

A line with at least "SHOULD" is needed I think.

<HKG>
(case : termination in non null context receives a command with service =
state OOS)
Think "SHALL" would me more appropriate and the MG NEEDS to send an =
error
code to indicate to the MGC that the termination is in a non null =
context
 and so its service state can't be changed to OOS). The error code can =
be
    433 - TerminationID is already in a Context

Another Error condition that needs to be identified here is the case =
when an
MGC attempts to Add an OOS terminaiton (Explicitly prohobited according =
to
the draft) but error code is not specified. An error code should be =
allocated here.
    4xx - TerminationId in OOS state

Third condition : A termination is presently in service and in null =
context. An Add commnad specifying service state OOS is received. Either =
of the above errore code should be used.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hemant Kumar
Ficon Technology
E-mail: mailto:hkumar@ficon-tech.com
Web: http://www.ficon-tech.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hemant Kumar
Ficon Technology
E-mail: mailto:hkumar@ficon-tech.com
Web: http://www.ficon-tech.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~


------=_NextPart_000_0066_01BFA971.474B9EC0
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#c0c0c0>
<DIV><FONT face=3DArial size=3D2>Hi Brian, Tom, =
list,<BR><BR>&nbsp;&nbsp;&nbsp; Pls=20
consider the following comments ( inlined &lt;HKG&gt; )<BR><BR>Regards =
and=20
thanks,<BR>Hemant Kumar<BR><BR>&nbsp;&nbsp;&nbsp; ----- Original Message =

-----<BR>From: Rosen, Brian<BR>To: Hemant ; <A=20
href=3D"mailto:MEGACO@standards.nortelnetworks.com">MEGACO@standards.nort=
elnetworks.com</A><BR>Sent:=20
Tuesday, April 18, 2000 4:59 AM<BR>Subject: RE: Service State Property =
"Out of=20
Service"<BR><BR><BR>I'd think you should not set a termination out of =
service=20
unless it was in<BR>null context (and thus would not have any media=20
streams).<BR><BR>&lt;HKG&gt; I Agree. Regarding what Michael mentioned =
test=20
might have to be<BR>carried out in OOS state. I think that should be =
done in the=20
service state<BR>"Test" rather than "OOS"<BR><BR>Whether it should be =
illegal is=20
another question.&nbsp; I don't care.&nbsp; I would<BR>not<BR>want =
setting the=20
property to have side effects like moving to null, etc.<BR><BR>A line =
with at=20
least "SHOULD" is needed I think.<BR><BR>&lt;HKG&gt;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>(case :&nbsp;termination in non null =
context=20
receives a command with service state OOS)<BR>Think "SHALL" would me =
more=20
appropriate and the MG NEEDS to send an error<BR>code to indicate to the =
MGC=20
that the termination is in a non null context<BR>&nbsp;and so its =
service state=20
can't be changed to OOS). The error code can be<BR>&nbsp;&nbsp;&nbsp; =
433 -=20
TerminationID is already in a Context<BR><BR>Another Error condition =
that needs=20
to be identified here is the case when an<BR>MGC attempts to Add an OOS=20
terminaiton (Explicitly prohobited according to<BR>the draft) but error =
code is=20
not specified. An error code should be allocated =
here.<BR>&nbsp;&nbsp;&nbsp; 4xx=20
- TerminationId in OOS state<BR><BR>Third condition : A =
termination&nbsp;is=20
presently in service and in null context. An Add commnad specifying =
service=20
state OOS is received.&nbsp;Either of the&nbsp;above errore code should =
be=20
used.</FONT><FONT face=3DArial=20
size=3D2><BR><BR>~~~~~~~~~~~~~~~~~~~~~~~~~~~~<BR>Hemant Kumar<BR>Ficon=20
Technology<BR>E-mail: <A=20
href=3D"mailto:hkumar@ficon-tech.com">mailto:hkumar@ficon-tech.com</A><BR=
>Web: <A=20
href=3D"http://www.ficon-tech.com">http://www.ficon-tech.com</A><BR>~~~~~=
~~~~~~~~~~~~~~~~~~~~~~~</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>~~~~~~~~~~~~~~~~~~~~~~~~~~~~<BR>Hemant=20
Kumar<BR>Ficon Technology<BR>E-mail: <A=20
href=3D"mailto:hkumar@ficon-tech.com">mailto:hkumar@ficon-tech.com</A><BR=
>Web: <A=20
href=3D"http://www.ficon-tech.com">http://www.ficon-tech.com</A><BR>~~~~~=
~~~~~~~~~~~~~~~~~~~~~~~<BR></FONT></DIV></BODY></HTML>

------=_NextPart_000_0066_01BFA971.474B9EC0--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr 18 13:59:47 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09105
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 18 Apr 2000 13:59:47 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.70628FF0@standards.nortelnetworks.com>; Tue, 18 Apr 2000 13:53:13 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6612 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 18 Apr 2000 13:51:58 -0400
Received: from smtprtp1.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.438A9CC0@standards.nortelnetworks.com>; Tue, 18 Apr 2000 13:51:58
          -0400
Received: from zcard00n.ca.nortel.com (actually zcard00n) by
          smtprtp1.ntcom.nortel.net; Tue, 18 Apr 2000 13:57:22 -0400
Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com
          with SMTP (Microsoft Exchange Internet Mail Service Version
          5.5.2650.21) id J1Q1YTGZ; Tue, 18 Apr 2000 13:57:23 -0400
Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) by
          zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id HNNLW7HX; Tue, 18 Apr 2000 13:57:23
          -0400
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <C1AAB24F0C66D3118B5B0000E861BB710331CA@maxip18.maxipro.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38FCA281.E77813B3@americasm01.nt.com>
Date:         Tue, 18 Apr 2000 13:59:29 -0400
Reply-To: Abdallah Rayhan <arayhan@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Abdallah Rayhan <arayhan@NORTELNETWORKS.COM>
Organization: Nortel Networks
Subject:      Re: Transaction ID NULL
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

There seems to be a misunderstanding here on handling such errors.
Firstly, MEGACO grammar specifies the proper way of doing media
transactions. If MGC/MG abuses the grammar then it must suffer the
consequences of being disconnected and even banned of participating
in talking to the peer device. This is obviously an implementation and
a vendor decision which is beyond the scope of the protocol.

Secondly, if MGC/MG parser decides to be syntax-error friendly,
then it can perform some diagnostic operations to figure out what
is missing and report the error back using error message at either the
message or the transaction levels and report its diagnosis on the
cause of error. Again, this is an implementation issue.

The bottom line is that if MGC/MG generates syntax errors, IMO
if MGC/MG generates many null transactions then it should not
be even out in there, then a high level error message should be
enough to pin point the error but it is up to the implementer to
figure it out and fix it and not the parser who generates no errors.

Reserving TID 0 for such cases as Brian indicated, is a matter of
flexibility for recovery and should be enough to handle all such
cases.



Abdallah


J Ramachandra wrote:

>  Brian,
>
> Thanks for the first part, but I have some difficulties with the 2nd
> part.
> See my comments marked as JK> below.
>
> - J K Ramachandra
>
> -----Original Message-----
> From: Rosen, Brian
> To: 'J Ramachandra'; MEGACO@standards.nortelnetworks.com
> Sent: 4/14/00 10:35 AM
> Subject: RE: Transaction ID NULL
>
> > Section 8.2.2 Transaction Reply, specifies
> > "If the receiver encounters an error such that it cannot determine a
> > legal Transaction, it will return a TransactionReply with a null
> > TransactionID and a single error descriptor (403 Syntax Error in
> > Transaction)".
> >
> > What is null TransactionID?
> > Is it 0 ?  e.g. Reply=0 {Error=403{error string} }
> > OR is it like Reply= {Error=403{error string}}?
> > As per ABNF, second one results in syntax error.
> >
> > If it is 0, one is not expected to use transaction ID 0 for a valid
> > transaction request? (MGCP Implementation Guide by International
> > Softswitch Consortium suggests this for MGCP). If one uses it, how to
> > identify whether it is the Reply received for transaction Request 0
> > or an error response for one of your requests?
> I think we SHOULD do what MGCP does, reserve 0, and use it for this
> purpose.  I would prefer NOT to change the ABNF to allow an omitted
> TransactionID -- I would prefer the scanner generate an error for this.
>
> > Finally,what purpose it serves to receive a reply like this, when you
> > can not determine for which transaction this reply is? Why not ignore
> > such a transaction Request, instead of sending an error Reply?
> Because the entity that sent the request is looking for a reply.
> When it gets no reply, it will retry.  After it retries a number of
> times, it might believe the link is down, or the other side is broken.
> An error message is a much better answer.
>
> JK> How the receiving entity associates this Reply with its Request?
>     Say, there are 'n' number of transaction Request sent towards the
>     same destination, how the receiver will decide to which Request (of
>     n transaction requests)it should associate this with? The only way
>     you can correlate is through the TransactionID which is missing
>     (or to be precise, not same) in this error message.
>
> Brian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr 18 18:16:31 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13263
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 18 Apr 2000 18:16:31 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.293C9020@standards.nortelnetworks.com>; Tue, 18 Apr 2000 18:08:55 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6708 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 18 Apr 2000 18:07:14 -0400
Received: from hvmta01-stg.us.psimail.psi.net (38.202.36.29) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.868F9FD0@standards.nortelnetworks.com>; Tue, 18 Apr 2000
          17:57:13 -0400
Received: from Jacksonville ([209.214.98.125]) by
          hvmta01-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111)
          with SMTP id <20000418220307.UFGH20160.hvmta01-stg@Jacksonville>;
          Tue, 18 Apr 2000 18:03:07 -0400
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID:  <NetContact.4/18/00.65358.05.jeffallen@acninc.net>
Date:         Tue, 18 Apr 2000 18:03:07 -0400
Reply-To: jeffallen@ACNINC.NET
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: jeffallen@ACNINC.NET
Subject:      Re: Saving up to 30% on Your Utilities, FREE Signup
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

A month ago you had requested more information on saving up to 30% on your long distance. I made the mistake of sending you, instead, information about becoming Rep's for the company i joined instead of giving you the information you originally requested.

I was so Excited about joining up with ACN I thought everybody else would  want to also.

If you want to save: We can help you save money on your gas, electric, phone, and interent. This is available worldwide. We can save you on your long distance and internet everywhere throughout the Unite States and depending on where you live, in most countries. Regarding Gas and electric, currently available in most states and in many countries. Eventually Deregulation will be Worldwide, and everybody will have a choice.

Email me your information and i'll mail you the info.

If you are interested in hearing more about the opportunities with ACN call: 248-975-6021 for a recorded message.

Jeff
912-826-1311
solochek@themail.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr 18 21:00:50 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15293
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 18 Apr 2000 21:00:49 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.43524CE0@standards.nortelnetworks.com>; Tue, 18 Apr 2000 20:54:18 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6969 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 18 Apr 2000 20:53:51 -0400
Received: from turin.trillium.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.CD7AB7B0@standards.nortelnetworks.com>; Tue, 18 Apr 2000 20:43:50
          -0400
Received: from aiglos.trillium.com (unverified) by turin.trillium.com (Content
          Technologies SMTPRS 4.1.2) with ESMTP id
          <Bced86cda4ba743a318@turin.trillium.com> for
          <megaco@standards.nortelnetworks.com>; Tue, 18 Apr 2000 17:59:34 -0700
Received: from aega.trillium.com (aega.trillium.com [192.168.1.19]) by
          aiglos.trillium.com (8.9.3/8.9.3) with ESMTP id RAA25648 for
          <megaco@standards.nortelnetworks.com>; Tue, 18 Apr 2000 17:49:35
          -0700 (PDT)
Received: by aega.trillium.com with Internet Mail Service (5.5.2650.21) id
          <G688P51Z>; Tue, 18 Apr 2000 17:48:13 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <8BBD33A986C5D311804000902719FF5D320028@aega.trillium.com>
Date:         Tue, 18 Apr 2000 17:48:13 -0700
Reply-To: Bharat Kaul <bharat@TRILLIUM.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Bharat Kaul <bharat@TRILLIUM.COM>
Subject:      Responses to Commands
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi Folks,

  There seems to be some conflicticting statements in the document.

 In section 9.0, last line of the section says that the "responses to the
command should be sent to the source address". Similar statement occurs in
section D.1.5 , paragraph 4.

However in section 11.5 of the document, following statement appears
The MGC and MG may take the following steps when Handoff occurs. When the
MGC initiates a HandOff, the handover should be tran- sparent to Operations
on the Media Gateway. Transactions can be exe- cuted in any order, and could
be in progress when the ServiceChange is executed. Accordingly, commands in
progress continue, transaction replies are sent to the new MGC (after a new
control association is established), and the MG should expect outstanding
transaction replies from the new MGC.

So, is there a conflict or is it me ? Clarification is appreciated.

Thanks
Bharat

----------------------------------------------------------------------------
-----------
Bharat Kaul;                                      Trillium Digital Systems
Inc.
mailto:bharat@trillium.com          12100 Wilshire Blvd,
Phone: +1-310-442-9222                Los Angeles, CA - 90025.
Fax:     +1-310-442-1162                  http://www.trillium.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr 18 23:53:49 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18680
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 18 Apr 2000 23:53:49 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.73C75010@standards.nortelnetworks.com>; Tue, 18 Apr 2000 23:47:27 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 7075 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 18 Apr 2000 23:46:12 -0400
Received: from centauri.starcon.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.E19FCE20@standards.nortelnetworks.com>; Tue, 18 Apr 2000 23:36:12
          -0400
Received: from dashaus.hothaus.com (g210-hothaus.att-g.starcon.com
          [216.13.167.210]) by centauri.starcon.com (Post.Office MTA v3.5.3
          release 223 ID# 0-0U10L2S100V35) with ESMTP id com for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 18 Apr 2000 20:42:01 -0700
Received: by DASHAUS with Internet Mail Service (5.5.2448.0) id <JC67MZ9W>;
          Tue, 18 Apr 2000 20:41:19 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <5713E3714F03D4118AB9009027D5B3A20139C0@NT-RMNA-EXCH>
Date:         Tue, 18 Apr 2000 20:39:54 -0700
Reply-To: Bob Lukas <blukas@BROADCOM.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Bob Lukas <blukas@BROADCOM.COM>
Subject:      draft-ietf-megaco-ipphone-02.txt: hookswitch/ringer?
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I've been looking at draft-ietf-megaco-ipphone-02.  One thing that isn't
clear to me is in which termination would I expect to find the package that
supports the hookswitch and ringer?

In Megaco, Annex E Basic Packages define hook and ring only in the analog
line supervision package, which is a misnomer if nothing else for an IP
phone.
You could make an argument that each of the audio transducer terminations
has the equivalent of a "hook" event (e.g. hookswitch for handset and
spkr/release button for handsfree), or that hook and ring should be part of
the user interface termination, independent of transducer. Or, to be
extreme, you could even say hook is just another function key and ring is
just another tone applied to the speaker transducer.
And something has to figure out when I switch to handsfree and hang up the
handset that I'm not terminating the call - which argues either for more
intelligence in the IP Phone (if there is a single "onhook" event, or more
intelligence in the MGC (if each transducer has it's own "onhook" event).
It is certainly important that there is clear concensus for
interoperability.

Can anyone shine some light on this?

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


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Apr 19 07:17:03 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03404
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 19 Apr 2000 07:17:03 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5A8ED350@standards.nortelnetworks.com>; Wed, 19 Apr 2000 7:10:33 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 7957 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 19 Apr 2000 07:08:59 -0400
Received: from fw7.usa.alcatel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.BC5EDFA0@standards.nortelnetworks.com>; Wed, 19 Apr 2000 6:58:58
          -0400
Received: (from uucp@localhost) by fw7.usa.alcatel.com (8.8.8+Sun/8.8.8) id
          GAA21460 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 19 Apr 2000
          06:03:58 -0500 (CDT)
Received: from <chak@axes-mach01.dsccc.com> (relay2.usa.alcatel.com
          [143.209.238.7]) by fw7 via smap (V2.1) id xma021432; Wed, 19 Apr 00
          06:03:55 -0500
Received: from multi1.usa.alcatel.com (localhost [127.0.0.1]) by
          relay2.usa.alcatel.com (8.9.3/8.9.3) with ESMTP id GAA04215 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 19 Apr 2000 06:06:08
          -0500 (CDT)
Received: from axes-mach01.axes-mach01.usa.alcatel.com
          (axes-mach01.usa.alcatel.com [130.202.9.90]) by
          multi1.usa.alcatel.com (8.8.8+Sun/8.8.8) with SMTP id GAA21077 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 19 Apr 2000 06:02:37
          -0500 (CDT)
Received: from chak by axes-mach01.axes-mach01.usa.alcatel.com
          (SMI-8.6/SMI-SVR4) id QAA11771; Wed, 19 Apr 2000 16:34:43 -0500
References:  <4FBEA8857476D311A03300204840E1CF6781C8@whq-msgusr-02.fore.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.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Message-ID:  <00cf01bfa9ef$62fd2b60$1d09ca82@chak>
Date:         Wed, 19 Apr 2000 16:36:59 +0530
Reply-To: Chakravarthi PSK <chak@AXES-MACH01.DSCCC.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chakravarthi PSK <chak@AXES-MACH01.DSCCC.COM>
Subject:      Subtract commnand
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit

Hellow,

    One doubt on sending subtract command to MG.

    Can MGC send subtract commnad to MG to get statistics when

1. call is released and prior to call release MGC received a service change
command with service change method set to GRACEFUL and service change delay
is not NULL also GRACFUL TIMEOUT  is not occured.

2. call is released and prior to call release MGC received a service change
command with service change method set to GRACEFUL and service change delay
is NULL.

Thanks & Regards
Chak


----- Original Message -----
From: Rosen, Brian <brosen@FORE.COM>
To: <MEGACO@STANDARDS.NORTELNETWORKS.COM>
Sent: Tuesday, April 18, 2000 12:41 PM
Subject: Re: MEGACO and Dial Pulse Lines


Since the MGC needs it, and the MG needs it, you do it in the MGC and
let it program the MG.

Provisioning might be evil, but it's not totally unavoidable yet!

Brian

> -----Original Message-----
> From: Stephen Terrill [mailto:stephen.terrill@ericsson.com]
> Sent: Tuesday, April 18, 2000 1:57 AM
> To: Rosen, Brian
> Cc: MEGACO@standards.nortelnetworks.com
> Subject: Re: MEGACO and Dial Pulse Lines
>
>
> Hi Brian,
>
> Now you are just argueing where to do the provisoning, not
> that provisoning can be avoided.  As it has to be done
> somewhere, why the MGC?
>
> ..//steve
>
> "Rosen, Brian" wrote:
>
> > This is another "provision vs. program" argument.
> > Yes, you could provision the timing characteristics.
> > Since I think provisioning is evil, I'd prefer the MGC do it.
> > As was pointed out, the MGC has to know if DTMF is "enabled"
> > on the line, possibly for billing.  Having to have two parts
> > with the same information is a cause of confusion and error.
> >
> > I would think almost all of the MGC code wouldn't know the
> > difference.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Stephen Terrill [mailto:stephen.terrill@ERICSSON.COM]
> > > Sent: Monday, April 17, 2000 3:23 AM
> > > To: MEGACO@standards.nortelnetworks.com
> > > Subject: Re: MEGACO and Dial Pulse Lines
> > >
> > >
> > > Hi,
> > >
> > > I was trying to find the correct message from this thread to
> > > respond to, so I would hitch it onto this.
> > >
> > > I would think that MGC shouldn´t be concerned with how the
> > > digits were detected.  The MGC is requesting to detect
> > > digits, and wether they are pulsed or DTMF shouldn´t matter -
> > > this is matter of hardware.
> > >
> > > Of course there is an issue of configuration, to have the
> > > terminal adapter (or line card) to be set for the type of
> > > subcriber, however I haven´t viewed H.248 as a configuration
> > > protocol - I understood that was done in other ways.
> > >
> > > Regards,
> > >
> > > ..//steve
> > >
> > > "Rosen, Brian" wrote:
> > >
> > > > > I agree with George, since POTS transparency is key.
> > > > >
> > > > > It appears that a "Dial pulse" package is needed to inform
> > > > > the MG of the
> > > > > dial pulse characteristics (PPS, Make/Break Ratio). What else?
> > > > >
> > > > > What is the process for creating such a package? Can anyone
> > > > > create an IETF
> > > > > draft?
> > > > >
> > > > Anyone can create a DRAFT.  Just write it up in the
> proper format
> > > > and email it to the Internet Drafts editor.
> > > >
> > > > Now, if you want IETF to DO anything with it, some working group
> > > > (for example, Megaco) has to adopt it as a work item, and agree
> > > > to turn it into an rfc (through it's consensus process).  I'd
> > > > suspect we would be willing to do this for a dial pulse package,
> > > > but that is up to the group to decide.
> > > >
> > > > Brian
> > > > >
> > >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Apr 19 09:01:18 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05726
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 19 Apr 2000 09:01:18 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.ECBF4300@standards.nortelnetworks.com>; Wed, 19 Apr 2000 8:54:51 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8177 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 19 Apr 2000 08:53:31 -0400
Received: from boca-isbu-nt04.boca.unisphere.com (207.36.128.43) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.BCAC2200@standards.nortelnetworks.com>; Wed, 19 Apr 2000
          8:53:31 -0400
Received: by boca-isbu-nt04.boca.unisphere.com with Internet Mail Service
          (5.5.2650.21) id <2VG7PP81>; Wed, 19 Apr 2000 08:59: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:  <153BDA136259D311859900A0C99B5263052E3B@boca-isbu-nt04.boca.unisphere.com>
Date:         Wed, 19 Apr 2000 08:59:19 -0400
Reply-To: "Glasgow, George" <gGlasgow@UNISPHERESOLUTIONS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Glasgow, George" <gGlasgow@UNISPHERESOLUTIONS.COM>
Subject:      Re: draft-ietf-megaco-ipphone-02.txt: hookswitch/ringer?
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Bob,
To the best of my knowledge, the task of distinguishing between hang-up and
switching to handsfree mode, has always been in the telephone. All of my
speaker phones at home and in my office work that way.

I don't see that it would be to our advantage to change this operation,
given that legacy systems will be expected to work identically in a
softswitch environment to the way they work now.

Consistency of operation is important here. Achieving this will mean that
someone can have a regular POTS or ISDN phone alongside an IP phone, and
they will all operate the same way.

I suppose I'm saying that, in my opinion, the "intelligence" should be in
the IP phone, not the MGC.

Regards,

George Glasgow
Senior Engineer - SRX-3000 Development
Unisphere Solutions,
900 Broken Sound Parkway, B12S,
Boca Raton, FL 33487,
USA
1-561-955-6555 Voice
1-561-955-6477 Fax

gglasgow@unispheresolutions.com <mailto:gglasgow@unispheresolutions.com>


Visit us on the web at: http://www.unispheresolutions.com




-----Original Message-----
From: Bob Lukas [mailto:blukas@BROADCOM.COM]
Sent: Tuesday, April 18, 2000 11:40 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: draft-ietf-megaco-ipphone-02.txt: hookswitch/ringer?


I've been looking at draft-ietf-megaco-ipphone-02.  One thing that isn't
clear to me is in which termination would I expect to find the package that
supports the hookswitch and ringer?

In Megaco, Annex E Basic Packages define hook and ring only in the analog
line supervision package, which is a misnomer if nothing else for an IP
phone.
You could make an argument that each of the audio transducer terminations
has the equivalent of a "hook" event (e.g. hookswitch for handset and
spkr/release button for handsfree), or that hook and ring should be part of
the user interface termination, independent of transducer. Or, to be
extreme, you could even say hook is just another function key and ring is
just another tone applied to the speaker transducer.
And something has to figure out when I switch to handsfree and hang up the
handset that I'm not terminating the call - which argues either for more
intelligence in the IP Phone (if there is a single "onhook" event, or more
intelligence in the MGC (if each transducer has it's own "onhook" event).
It is certainly important that there is clear concensus for
interoperability.

Can anyone shine some light on this?

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


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Apr 19 10:16:49 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06961
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 19 Apr 2000 10:16:49 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DEED5050@standards.nortelnetworks.com>; Wed, 19 Apr 2000 10:06:03 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8278 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 19 Apr 2000 10:05:17 -0400
Received: from fw7.usa.alcatel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.5DD33170@standards.nortelnetworks.com>; Wed, 19 Apr 2000 9:55:17
          -0400
Received: (from uucp@localhost) by fw7.usa.alcatel.com (8.8.8+Sun/8.8.8) id
          IAA25513; Wed, 19 Apr 2000 09:00:01 -0500 (CDT)
Received: from <chak@axes-mach01.dsccc.com> (relay2.usa.alcatel.com
          [143.209.238.7]) by fw7 via smap (V2.1) id xmaa25436; Wed, 19 Apr 00
          08:59:21 -0500
Received: from multi1.usa.alcatel.com (localhost [127.0.0.1]) by
          relay2.usa.alcatel.com (8.9.3/8.9.3) with ESMTP id JAA18248; Wed, 19
          Apr 2000 09:01:33 -0500 (CDT)
Received: from axes-mach01.axes-mach01.usa.alcatel.com
          (axes-mach01.usa.alcatel.com [130.202.9.90]) by
          multi1.usa.alcatel.com (8.8.8+Sun/8.8.8) with SMTP id IAA14971; Wed,
          19 Apr 2000 08:58:02 -0500 (CDT)
Received: from chak by axes-mach01.axes-mach01.usa.alcatel.com
          (SMI-8.6/SMI-SVR4) id TAA13629; Wed, 19 Apr 2000 19:30:11 -0500
References:  <4FBEA8857476D311A03300204840E1CF64D3FF@whq-msgusr-02.fore.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_0150_01BFAA35.FCA62A00"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Message-ID:  <015301bfaa07$e446c740$1d09ca82@chak>
Date:         Wed, 19 Apr 2000 19:32:23 +0530
Reply-To: Chakravarthi PSK <chak@AXES-MACH01.DSCCC.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chakravarthi PSK <chak@AXES-MACH01.DSCCC.COM>
Subject:      Re: Service State Property "Out of Service"
X-To:         "Rosen, Brian" <brosen@FORE.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_0150_01BFAA35.FCA62A00
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Brian,

    What happens If craft person at MG side, wants put a circuit which =
is not in NULL context to "Out Of Service" for maintenance purpose?

Thanks & Regards
Chak

  ----- Original Message -----=20
  From: Rosen, Brian=20
  To: MEGACO@STANDARDS.NORTELNETWORKS.COM=20
  Sent: Tuesday, April 18, 2000 4:59 AM
  Subject: Re: Service State Property "Out of Service"


  I'd think you should not set a termination out of service unless it =
was in null context (and thus would
  not have any media streams).  Whether it should be illegal is another =
question.  I don't care.  I would not
  want setting the property to have side effects like moving to null, =
etc.
  =20
  A line with at least "SHOULD" is needed I think.
  =20
  Brian
    -----Original Message-----
    From: Hemant [mailto:hkumar@ficon-tech.com]
    Sent: Monday, April 17, 2000 6:41 AM
    To: MEGACO@standards.nortelnetworks.com
    Subject: Service State Property "Out of Service"


    Hi Brian, list,

        I wish to discuss some issues with handling of service state =
property value "Out of Service" (OOS). The draft mentions "The state =
"out of service" indicates that the termination cannot be used for =
traffic" (sec 7.1.5 para 2). This is fine for the terminations which are =
made OOS in null context as terminations can only be Added with non "out =
of service" state. But what about the following :=20

    1) Is a command specifying Service State as OOS valid for a =
termination in a non null context ?=20
    If it is valid, what is the MG expected to do ? Should it stop =
traffic and deallocate all the resources allocated for that termination =
and let the termination remain in non null context? What will happen if =
this termination is made "in-service" again. The MG would have to =
allocate all the resources (according to the command in which the =
termination state change is specified as in service) for this =
termination and add it to the context. That is the MG would do all the =
handling that is required to "Add" the termination in the context. Then =
what is being gained by keeping a OOS termination in a non-NULL context =
?=20
    =20
    Suggestion : I would suggest that operation should be made invalid. =
The MGC should first bring the termination out of context by explicitly =
subtracting the termination. Another option is specifying that setting =
state to OOS does an implicit subtract (just like mux results in an =
implicit Add). But in this option what would a command containing Stream =
desc. with non null Local or Remote mean ? Should resource reservation =
implied by these be neglected ? I don't know why one would like to make =
a temination OOS and then hold resources for that same termination.=20

    2) Assume that the state of a termination in null context is In =
service. An add command for that termination is received and in that =
command the termination state set to OOS. Is that a valid command ?=20

    Suggestion : I think this should also be considered invalid going by =
the logic which prevents an already OOS termination to be added to a =
context.=20

    Can it be said then that changing the state of a termination to OOS =
is valid only under following circumstances :   =20
        - In null context.   =20
        - By Modify command.   =20
        - Without any Local and Remote Descriptor.=20
    =20
    comments please ....=20
    =20
    Regards,
    Hemant Kumar
    =20
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Hemant Kumar
    Ficon Technology
    E-mail: mailto:hkumar@ficon-tech.com
    Web: http://www.ficon-tech.com
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~


------=_NextPart_000_0150_01BFAA35.FCA62A00
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Brian,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; What happens If =
craft person at=20
MG side, wants put a circuit which is not in NULL context to "Out Of =
Service"=20
for maintenance purpose?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks &amp; Regards</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Chak</FONT></DIV>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A href=3D"mailto:brosen@FORE.COM" title=3Dbrosen@FORE.COM>Rosen, =
Brian</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
  href=3D"mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM"=20
  =
title=3DMEGACO@STANDARDS.NORTELNETWORKS.COM>MEGACO@STANDARDS.NORTELNETWOR=
KS.COM</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, April 18, 2000 =
4:59=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: Service State =
Property "Out=20
  of Service"</DIV>
  <DIV><BR></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D500060916-17042000>I'd=20
  think you should not set a termination out of service unless it was in =
null=20
  context (and thus would</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D500060916-17042000>not=20
  have any media streams).&nbsp; Whether it should be illegal is another =

  question.&nbsp; I don't care.&nbsp; I would not</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D500060916-17042000>want=20
  setting the property to have side effects like moving to null,=20
  etc.</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D500060916-17042000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D500060916-17042000>A=20
  line with at least "SHOULD" is needed I think.</SPAN></FONT></DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D500060916-17042000></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
  class=3D500060916-17042000>Brian</SPAN></FONT></DIV>
  <BLOCKQUOTE=20
  style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; =
MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
    <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> Hemant=20
    [mailto:hkumar@ficon-tech.com]<BR><B>Sent:</B> Monday, April 17, =
2000 6:41=20
    AM<BR><B>To:</B> =
MEGACO@standards.nortelnetworks.com<BR><B>Subject:</B>=20
    Service State Property "Out of Service"<BR><BR></DIV></FONT>
    <DIV><FONT face=3DArial size=3D2>
    <DIV><FONT face=3DArial><FONT size=3D-1>Hi Brian, =
list,</FONT></FONT></DIV>
    <DIV>&nbsp;</DIV>
    <DIV><FONT face=3DArial><FONT size=3D-1>&nbsp;&nbsp;&nbsp; I wish to =
discuss=20
    some issues with handling of service state property value "Out of =
Service"=20
    (OOS). The draft mentions "The state "out of service" indicates that =
the=20
    termination cannot be used for traffic" (sec 7.1.5 para 2). This is =
fine for=20
    the terminations which are made OOS in null context as terminations =
can only=20
    be Added with non "out of service" state. But what about the =
following=20
    :</FONT></FONT>&nbsp;</DIV>
    <DIV>&nbsp;</DIV>
    <DIV><FONT face=3DArial><FONT size=3D-1>1) Is a command specifying =
Service State=20
    as OOS valid for a termination in a non null context ? =
</FONT></FONT></DIV>
    <DIV><FONT face=3DArial><FONT size=3D-1>If it is valid, what is the =
MG expected=20
    to do</FONT></FONT><FONT face=3DArial><FONT =
size=3D-1></FONT></FONT>&nbsp;<FONT=20
    face=3DArial><FONT size=3D-1>?&nbsp;Should it stop traffic and =
deallocate all=20
    the resources allocated for that termination and let the termination =
remain=20
    in non null context? What will happen if this termination =
is&nbsp;made=20
    "in-service" again.&nbsp;The MG would have to allocate all the =
resources=20
    (according to the command in which the termination state change is =
specified=20
    as in service) for this termination and add it to the context. That =
is the=20
    MG would do all the handling that is required to "Add" the =
termination in=20
    the context.</FONT></FONT>&nbsp;Then what is being gained by keeping =
a OOS=20
    termination in a non-NULL context ? <FONT face=3DArial><FONT=20
    size=3D-1></FONT></FONT></DIV>
    <DIV><FONT face=3DArial><FONT size=3D-1></FONT></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial><FONT size=3D-1>Suggestion : I would suggest =
that=20
    operation should be made invalid. The MGC should first bring the =
termination=20
    out of context by explicitly subtracting the termination. Another =
option is=20
    specifying that setting state to OOS does an implicit subtract (just =
like=20
    mux results in an implicit Add). But in this option what would a =
command=20
    containing Stream desc. with non null Local or Remote mean ? Should =
resource=20
    reservation implied by these be neglected ? I don't know why one =
would like=20
    to make a temination OOS and then hold resources for that same=20
    termination.</FONT></FONT>&nbsp;</DIV>
    <DIV>&nbsp;</DIV>
    <DIV><FONT face=3DArial><FONT size=3D-1>2) Assume that the state of =
a=20
    termination in null context is In service. An add command for that=20
    termination is received and in that command the termination state =
set to=20
    OOS. Is that a valid command ?</FONT></FONT>&nbsp;</DIV>
    <DIV>&nbsp;</DIV>
    <DIV><FONT face=3DArial><FONT size=3D-1>Suggestion : I think this =
should also be=20
    considered invalid going by the logic which prevents an already OOS=20
    termination to be added to a context.</FONT></FONT>&nbsp;</DIV>
    <DIV>&nbsp;</DIV>
    <DIV><FONT face=3DArial><FONT size=3D-1>Can it be said then that =
changing the=20
    state of a termination&nbsp;to OOS is valid only under following=20
    circumstances :</FONT></FONT><FONT face=3DArial><FONT=20
    size=3D-1>&nbsp;&nbsp;&nbsp; </FONT></FONT></DIV>
    <DIV><FONT face=3DArial><FONT size=3D-1>&nbsp;&nbsp;&nbsp; - In null =

    context.</FONT></FONT><FONT face=3DArial><FONT =
size=3D-1>&nbsp;&nbsp;&nbsp;=20
    </FONT></FONT></DIV>
    <DIV><FONT face=3DArial><FONT size=3D-1>&nbsp;&nbsp;&nbsp; - By =
Modify=20
    command.</FONT></FONT><FONT face=3DArial><FONT =
size=3D-1>&nbsp;&nbsp;&nbsp;=20
    </FONT></FONT></DIV>
    <DIV><FONT face=3DArial><FONT size=3D-1>&nbsp;&nbsp;&nbsp; - Without =
any Local=20
    and Remote Descriptor.</FONT></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial><FONT size=3D-1></FONT></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial><FONT size=3D-1>comments please=20
    ....</FONT></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial><FONT size=3D-1></FONT></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial><FONT size=3D-1>Regards,</FONT></FONT><FONT=20
    face=3DArial><FONT size=3D-1></FONT></FONT></DIV>
    <DIV><FONT face=3DArial><FONT size=3D-1>Hemant =
Kumar</FONT></FONT></FONT><FONT=20
    face=3DArial size=3D2></FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial =
size=3D2>~~~~~~~~~~~~~~~~~~~~~~~~~~~~<BR>Hemant=20
    Kumar<BR>Ficon Technology<BR>E-mail: <A=20
    =
href=3D"mailto:hkumar@ficon-tech.com">mailto:hkumar@ficon-tech.com</A><BR=
>Web:=20
    <A=20
    =
href=3D"http://www.ficon-tech.com">http://www.ficon-tech.com</A><BR>~~~~~=
~~~~~~~~~~~~~~~~~~~~~~~<BR></DIV></FONT></DIV></BLOCKQUOTE></BLOCKQUOTE><=
/BODY></HTML>

------=_NextPart_000_0150_01BFAA35.FCA62A00--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Apr 19 10:47:42 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07399
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 19 Apr 2000 10:47:41 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C975EA20@standards.nortelnetworks.com>; Wed, 19 Apr 2000 10:41:15 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8456 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 19 Apr 2000 10:39:45 -0400
Received: from pop-rocks.shoretel.com (208.163.34.3) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.93E1A2F0@standards.nortelnetworks.com>; Wed, 19 Apr 2000
          10:39:45 -0400
Received: by pop-rocks.shoretel.com with Internet Mail Service (5.5.2650.21) id
          <JFZ0LQXF>; Wed, 19 Apr 2000 07:45:41 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <1A1B8F0BB483D311B139005004744834402813@pop-rocks.shoretel.com>
Date:         Wed, 19 Apr 2000 07:45:40 -0700
Reply-To: Jeff Ridley <jridley@SHORETEL.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Jeff Ridley <jridley@SHORETEL.COM>
Subject:      Re: draft-ietf-megaco-ipphone-02.txt: hookswitch/ringer?
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

George and Bob,

I think there are conflicts in some features if the hook-switch were to be a
hard feature in the phone.  There are some cases where a system actually
wants the audio paths to turn on / off independently of the hook switch.  A
person using a headset for example is not using the hook switch but would
still like their headset to turn on/off based on their calls.

If there were local smarts to switch handset to hansfree, it would have to
be done in such a way as to avoid blocking the situations where the phone
needs to be controlled more directly.  Turning the hook switch into another
feature key seems to make it easier to get this level of control.

Jeff


Jeffrey Ridley, Sr. Product Manager
Phone: 408-331-3413, FAX: 408-331-3333
For Shoreline See: www.goshoreline.com


-----Original Message-----
From: Glasgow, George [mailto:gGlasgow@UNISPHERESOLUTIONS.COM]
Sent: Wednesday, April 19, 2000 5:59 AM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: draft-ietf-megaco-ipphone-02.txt: hookswitch/ringer?


Bob,
To the best of my knowledge, the task of distinguishing between hang-up and
switching to handsfree mode, has always been in the telephone. All of my
speaker phones at home and in my office work that way.

I don't see that it would be to our advantage to change this operation,
given that legacy systems will be expected to work identically in a
softswitch environment to the way they work now.

Consistency of operation is important here. Achieving this will mean that
someone can have a regular POTS or ISDN phone alongside an IP phone, and
they will all operate the same way.

I suppose I'm saying that, in my opinion, the "intelligence" should be in
the IP phone, not the MGC.

Regards,

George Glasgow
Senior Engineer - SRX-3000 Development
Unisphere Solutions,
900 Broken Sound Parkway, B12S,
Boca Raton, FL 33487,
USA
1-561-955-6555 Voice
1-561-955-6477 Fax

gglasgow@unispheresolutions.com <mailto:gglasgow@unispheresolutions.com>


Visit us on the web at: http://www.unispheresolutions.com




-----Original Message-----
From: Bob Lukas [mailto:blukas@BROADCOM.COM]
Sent: Tuesday, April 18, 2000 11:40 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: draft-ietf-megaco-ipphone-02.txt: hookswitch/ringer?


I've been looking at draft-ietf-megaco-ipphone-02.  One thing that isn't
clear to me is in which termination would I expect to find the package that
supports the hookswitch and ringer?

In Megaco, Annex E Basic Packages define hook and ring only in the analog
line supervision package, which is a misnomer if nothing else for an IP
phone.
You could make an argument that each of the audio transducer terminations
has the equivalent of a "hook" event (e.g. hookswitch for handset and
spkr/release button for handsfree), or that hook and ring should be part of
the user interface termination, independent of transducer. Or, to be
extreme, you could even say hook is just another function key and ring is
just another tone applied to the speaker transducer.
And something has to figure out when I switch to handsfree and hang up the
handset that I'm not terminating the call - which argues either for more
intelligence in the IP Phone (if there is a single "onhook" event, or more
intelligence in the MGC (if each transducer has it's own "onhook" event).
It is certainly important that there is clear concensus for
interoperability.

Can anyone shine some light on this?

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


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Apr 19 11:26:01 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08196
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 19 Apr 2000 11:26:00 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1F412A00@standards.nortelnetworks.com>; Wed, 19 Apr 2000 11:19:26 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8563 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 19 Apr 2000 11:19:09 -0400
Received: from smtprtp1.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.AEF67AD0@standards.nortelnetworks.com>; Wed, 19 Apr 2000 11:09:08
          -0400
Received: from zcard015.ca.nortel.com (actually zcard015) by
          smtprtp1.ntcom.nortel.net; Wed, 19 Apr 2000 10:54:57 -0400
Received: from zrtpd00z.us.nortel.com ([47.140.224.110]) by
          zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id H6NPJ53M; Wed, 19 Apr 2000 10:54:56
          -0400
Received: from americasm10.nt.com (pnc1m006.us.nortel.com [47.142.208.218]) by
          zrtpd00z.us.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id HSZ9FGAZ; Wed, 19 Apr 2000 10:54:56
          -0400
X-Sybari-Space: 00000000 00000000 00000000
X-Sender: "Brown, Michael [NC1:3T19:EXCH]" <mahubard@zrtpd00z>
X-Mailer: Mozilla 4.7 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <38FBE1C0.7133B244@ficon-tech.com>
            <127c01bfa93a$1189bce0$830119ac@india.ficontech.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38FDC9A7.BD0ECDD8@americasm10.nt.com>
Date:         Wed, 19 Apr 2000 10:58:47 -0400
Reply-To: Michael Brown <C.Michael.Brown@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Michael Brown <C.Michael.Brown@NORTELNETWORKS.COM>
Organization: Nortel Networks
Subject:      Re: Test ServiceState in Termination State Descriptor]
X-To:         Hemant Agrawal <hemantag@FICON-TECH.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Overall, was glad that mostly we are agreeing. Reading your reply I realized
that I didn't state a couple of my underlying assumptions which led to some
confusion.

In particular, the statement about IS, OOS, IS-TEST and OOS-TEST is misleading
without the assumptions. That is, of course, you are correct that there are 3
defined states. My assumption was that in defining a test package there would be
a property which would be used to indicate whether the line is IS or OOS as a
substate of TEST. So, that when the termination is placed in the TEST state, the
property would be set to reflect the underlying IS or OOS state of the
termination. The MGC and/or maintenance system would also have the knowledge of
this termination as either IS or OOS and would allow or disallow use of the
termination as appropriate.

I put one other comment inline with <MB>.

Mike

Hemant Agrawal wrote:

> Hi Brown, list,
>
>  My comments are inserted inline with HA>
>
> > The test state is different from "in service" in that a termination can be
> "in
> > service", "OOS", "in service - test" or "OOS - test".
> >
>
> HA>  In TerminationStateDescriptor, ServiceState has only three valid
> states, IS, OOS and Test. There is no state as "IS-TEST" or "OOS-TEST". The
> state "test" is independent of the IS or OOS state.
>
> > I would say that there are no specific actions which would be applied
> simply by placing the line in the
> > test state.
> >
>  HA> Agreed. (In fact that's what we have said)
> >
> > In my opinion, it would be something of a flag to indicate that the
> signals and
> > events associated with test package could be applied to a termination.
> >
> > The behavior associated with those signals and events would be defined as
> part of
> > the package and may be different depending on whether the termination is
> IS or
> > OOS.
> >
> > I would think that the intelligence to determine whether or not to apply a
> > particular signal or event would be under the control of the MGC or a
> > maintenance interface, but it might be desirable for an implementation in
> the MG
> > to do some minimal defensive coding to prevent MGC or maintenance request
> > "mistakes".
> >
>  HA> is it that when the termination is not in test state, then the MG
> should  not allow test events and signals to be applied ? What happens to
> the test  signals & events when a termination which is in test state moves
> to a IS state -
>  does the MG stop those signals and events ?

<MB> I would say that the answers to your questions would be yes and no
respectively, assuming that the transactions requesting these functions only
contained the command to do the requests specified. I would suggest, however,
that the scenario described suggests a somewhat confused or less than aware MGC
or maintenance craft person. In my opinion, this type of error checking should
be performed by the MGC or maintenance interface which is why I said that "it
might be desirable" to provide some defensive coding in the MG. I think that it
is not unreasonable to expect that the MG recognize the suggested operations as
errors and report them to the MGC as such but don't think it should be
required..

>
>
> >I do agree that the intelligence for handling the test state should be
> driven by
> > the MGC and actions taken in the MG implemented in packages. One of the
> reasons
> > I believe that the test state is needed is to have this knowledge
> available
> > associated with the termination in the event of the MG performing a
> failover to
> > a secondary MGC. The MGC could determine those terminations which were
> under
> > test using audit mechanisms and could then take action accordingly.
> >
> > Regarding your last question, I would say that the MG would behave no
> > differently in allocating a termination on a CHOOSE when it is IS-test or
> IS.
> > The point is that the termination should be used as IS except that
> specified
> > test functions will be performed (under MGC control) during normal use.
>
> HA> Agreed
>
> > I am currently in process of working with Nortel development groups on
> producing
> > a test package for line test functions. This will be coming out in the
> near
> > future and I think it will help to further clarify my comments.
> >
>
> Regards,
> Hemant Agrawal
>
> >
> > Hemant Agrawal wrote:
> >
> > > Hi All,
> > >         I have few questions related to serviceState in
> > > terminationStatedDescriptor.
> > > TerminationStateDescriptor has three values for serviceState : In
> Service,
> > > Out Of Service and Test.
> > > The draft mentions "The state "test" indicates that the termination is
> being
> > > tested" (sec 7.1.5 para 2).
> > >
> > > How is "test" state different from "in service"? Is their any special
> action
> > > to be taken by MG, when it receives a termination state to be set as
> test.
> > >
> > > Does it mean that if the said termination supports test packages, the
> events
> > > , signals etc pertaining to these can be applied only in test state.
> Also in
> > > that case what happens to the non "test" package events and signals. Are
> > > they stopped by the MG on getting service state property as "test" and
> vice
> > > versa.
> > >
> > > I think this differentiation between what constitutes test and what not
> > > should not be done at MG level. But in that case how from an MG point of
> > > view, are the service states "test" and "in service" different ?
> > >
> > > Another question in this regards. Should the MG "prefer" allocating  "in
> > > service" terminations over terminations with service state "test" while
> > > resolving CHOOSE in Add.
> > >
> > > Thanks in advance,
> > > Hemant Agrawal
> > >
> > > ________________________________________
> > > Hemant Agrawal
> > > Ficon Technology
> > > E-mail: hemantag@ficon-tech.com
> > > Web: http://www.ficon-tech.com
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Apr 19 12:57:10 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09957
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 19 Apr 2000 12:57:10 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E06F16E0@standards.nortelnetworks.com>; Wed, 19 Apr 2000 12:50:44 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8789 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 19 Apr 2000 12:49:06 -0400
Received: from smtprich.nortel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.A5826730@standards.nortelnetworks.com>; Wed, 19 Apr 2000 12:49:05
          -0400
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprich.nortel.com; Wed, 19 Apr 2000 11:52:22 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <269WTVZ6>; Wed, 19 Apr 2000 11:51:15 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFAA1F.784DF9EC"
X-Orig: <blather@americasm01.nt.com>
Message-ID:  <8E2783FA4E0CD411888D0000F8CD15D33C36D7@zcard00q.ca.nortel.com>
Date:         Wed, 19 Apr 2000 11:51:09 -0500
Reply-To: Peter Blatherwick <blather@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Peter Blatherwick <blather@NORTELNETWORKS.COM>
Subject:      Re: draft-ietf-megaco-ipphone-02.txt: hookswitch/ringer?
X-To:         Bob Lukas <blukas@BROADCOM.COM>
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_01BFAA1F.784DF9EC
Content-Type: text/plain;
        charset="iso-8859-1"

Bob, list:

You query is partly specific, partly philosophical, hence the
longish reply.

Specific answers to your queries:

- All user interface related packages (as opposed to audio),
including hookswitch and ringer, are found in the User Interface
termination.  Hookswitch is a well known name within the
Function Key Package, and Ringer is a well known name in
the Indicator Package (see Annex G).   Analog line
supervision is not used, nor is hookswitch attached to
an audio transducer.  See reasoning below.

- If you wish to model handset and handsfree invisibly to the MGC
application, you certainly can.  In that case it is up to the MG
implementation to model this and map to a logical hookswitch key.

- Normally, one would expect to see events from a handsfree key
to initiate a switch from handset to handsfree.  This feature level
mapping belongs at the MGC since it owns the user interface
application for Megaco IP Phone MG end devices.

Philosophically speaking, Megaco IP Phone takes full advantage
of Megaco/H.248's master/slave control model to remove as much
application intelligence from the end device as possible.  The
reason all these elements are kept separate is to allow us to
provide for a very high degree of user interface flexibility,
well beyond what fixed function telephones can do today.  Well
know names help identify the intended purpose of a particular
element on the physical device, removing the need for
device-specific knowledge at the MGC application.

For example, consider group listening (1 person talking on handset
or headset, others listening on handsfree with mute on).  If the real
transducers were hidden behind a single termination this feature
needs to be added to the phone, while if the MGC can "see" each
transducer separately an application running at the MGC can pretty
much do whatever it wants.  Similarly, keeping the various function
keys, indicators, etc separate, the MGC application has complete
control over the user interface.  There are many, many applications
which can be easily modeled in this way, and provide an extremely
flexible and cost-effective system.  This is good for innovation on a
master/slave controlled device.

I believe the above is actually spelled out in the Megaco IP Phone
document, though it may be a bit terse in places.  If it is unclear
in some way, please suggest what I can to make it clear, and I
will certainly do so.

Before the religious war starts (yet again), I would like to make it
very clear that I do not see Megaco/H.248 master/slave as being in
conflict with peer approaches such as SIP or H.323.  On the contrary,
I believe master/slave and peer approaches are complementary in the
marketplace and are both extremely helpful, even necessary, in
creating truly useful and flexible Internet communication systems.
Certainly, the two models are fully compatible at the system level.
Its NOT about one "versus" the other.

-- Peter Blatherwick



-----Original Message-----
From: Bob Lukas [mailto:blukas@BROADCOM.COM]
Sent: Tuesday, April 18, 2000 23:40
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: draft-ietf-megaco-ipphone-02.txt: hookswitch/ringer?


I've been looking at draft-ietf-megaco-ipphone-02.  One thing that isn't
clear to me is in which termination would I expect to find the package that
supports the hookswitch and ringer?

In Megaco, Annex E Basic Packages define hook and ring only in the analog
line supervision package, which is a misnomer if nothing else for an IP
phone.
You could make an argument that each of the audio transducer terminations
has the equivalent of a "hook" event (e.g. hookswitch for handset and
spkr/release button for handsfree), or that hook and ring should be part of
the user interface termination, independent of transducer. Or, to be
extreme, you could even say hook is just another function key and ring is
just another tone applied to the speaker transducer.
And something has to figure out when I switch to handsfree and hang up the
handset that I'm not terminating the call - which argues either for more
intelligence in the IP Phone (if there is a single "onhook" event, or more
intelligence in the MGC (if each transducer has it's own "onhook" event).
It is certainly important that there is clear concensus for
interoperability.

Can anyone shine some light on this?

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

------_=_NextPart_001_01BFAA1F.784DF9EC
Content-Type: text/html;
        charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2651.65">
<TITLE>RE: draft-ietf-megaco-ipphone-02.txt: hookswitch/ringer?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Bob, list: </FONT>
</P>

<P><FONT SIZE=2>You query is partly specific, partly philosophical, hence the </FONT>
<BR><FONT SIZE=2>longish reply.&nbsp; </FONT>
</P>

<P><FONT SIZE=2>Specific answers to your queries:</FONT>
</P>

<P><FONT SIZE=2>- All user interface related packages (as opposed to audio), </FONT>
<BR><FONT SIZE=2>including hookswitch and ringer, are found in the User Interface </FONT>
<BR><FONT SIZE=2>termination.&nbsp; Hookswitch is a well known name within the </FONT>
<BR><FONT SIZE=2>Function Key Package, and Ringer is a well known name in </FONT>
<BR><FONT SIZE=2>the Indicator Package (see Annex G).&nbsp;&nbsp; Analog line </FONT>
<BR><FONT SIZE=2>supervision is not used, nor is hookswitch attached to </FONT>
<BR><FONT SIZE=2>an audio transducer.&nbsp; See reasoning below.&nbsp; </FONT>
</P>

<P><FONT SIZE=2>- If you wish to model handset and handsfree invisibly to the MGC </FONT>
<BR><FONT SIZE=2>application, you certainly can.&nbsp; In that case it is up to the MG </FONT>
<BR><FONT SIZE=2>implementation to model this and map to a logical hookswitch key.&nbsp;&nbsp; </FONT>
</P>

<P><FONT SIZE=2>- Normally, one would expect to see events from a handsfree key </FONT>
<BR><FONT SIZE=2>to initiate a switch from handset to handsfree.&nbsp; This feature level </FONT>
<BR><FONT SIZE=2>mapping belongs at the MGC since it owns the user interface </FONT>
<BR><FONT SIZE=2>application for Megaco IP Phone MG end devices.&nbsp; </FONT>
</P>

<P><FONT SIZE=2>Philosophically speaking, Megaco IP Phone takes full advantage </FONT>
<BR><FONT SIZE=2>of Megaco/H.248's master/slave control model to remove as much </FONT>
<BR><FONT SIZE=2>application intelligence from the end device as possible.&nbsp; The </FONT>
<BR><FONT SIZE=2>reason all these elements are kept separate is to allow us to </FONT>
<BR><FONT SIZE=2>provide for a very high degree of user interface flexibility, </FONT>
<BR><FONT SIZE=2>well beyond what fixed function telephones can do today.&nbsp; Well </FONT>
<BR><FONT SIZE=2>know names help identify the intended purpose of a particular </FONT>
<BR><FONT SIZE=2>element on the physical device, removing the need for </FONT>
<BR><FONT SIZE=2>device-specific knowledge at the MGC application.&nbsp; </FONT>
</P>

<P><FONT SIZE=2>For example, consider group listening (1 person talking on handset </FONT>
<BR><FONT SIZE=2>or headset, others listening on handsfree with mute on).&nbsp; If the real </FONT>
<BR><FONT SIZE=2>transducers were hidden behind a single termination this feature </FONT>
<BR><FONT SIZE=2>needs to be added to the phone, while if the MGC can &quot;see&quot; each </FONT>
<BR><FONT SIZE=2>transducer separately an application running at the MGC can pretty </FONT>
<BR><FONT SIZE=2>much do whatever it wants.&nbsp; Similarly, keeping the various function </FONT>
<BR><FONT SIZE=2>keys, indicators, etc separate, the MGC application has complete </FONT>
<BR><FONT SIZE=2>control over the user interface.&nbsp; There are many, many applications </FONT>
<BR><FONT SIZE=2>which can be easily modeled in this way, and provide an extremely </FONT>
<BR><FONT SIZE=2>flexible and cost-effective system.&nbsp; This is good for innovation on a </FONT>
<BR><FONT SIZE=2>master/slave controlled device.&nbsp;&nbsp; </FONT>
</P>

<P><FONT SIZE=2>I believe the above is actually spelled out in the Megaco IP Phone </FONT>
<BR><FONT SIZE=2>document, though it may be a bit terse in places.&nbsp; If it is unclear </FONT>
<BR><FONT SIZE=2>in some way, please suggest what I can to make it clear, and I </FONT>
<BR><FONT SIZE=2>will certainly do so.&nbsp; </FONT>
</P>

<P><FONT SIZE=2>Before the religious war starts (yet again), I would like to make it </FONT>
<BR><FONT SIZE=2>very clear that I do not see Megaco/H.248 master/slave as being in </FONT>
<BR><FONT SIZE=2>conflict with peer approaches such as SIP or H.323.&nbsp; On the contrary, </FONT>
<BR><FONT SIZE=2>I believe master/slave and peer approaches are complementary in the </FONT>
<BR><FONT SIZE=2>marketplace and are both extremely helpful, even necessary, in </FONT>
<BR><FONT SIZE=2>creating truly useful and flexible Internet communication systems.&nbsp; Certainly, the two models are fully compatible at the system level.&nbsp; </FONT></P>

<P><FONT SIZE=2>Its NOT about one &quot;versus&quot; the other.&nbsp; </FONT>
</P>

<P><FONT SIZE=2>-- Peter Blatherwick</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Bob Lukas [<A HREF="mailto:blukas@BROADCOM.COM">mailto:blukas@BROADCOM.COM</A>]</FONT>
<BR><FONT SIZE=2>Sent: Tuesday, April 18, 2000 23:40</FONT>
<BR><FONT SIZE=2>To: MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><FONT SIZE=2>Subject: draft-ietf-megaco-ipphone-02.txt: hookswitch/ringer?</FONT>
</P>
<BR>

<P><FONT SIZE=2>I've been looking at draft-ietf-megaco-ipphone-02.&nbsp; One thing that isn't</FONT>
<BR><FONT SIZE=2>clear to me is in which termination would I expect to find the package that</FONT>
<BR><FONT SIZE=2>supports the hookswitch and ringer?</FONT>
</P>

<P><FONT SIZE=2>In Megaco, Annex E Basic Packages define hook and ring only in the analog</FONT>
<BR><FONT SIZE=2>line supervision package, which is a misnomer if nothing else for an IP</FONT>
<BR><FONT SIZE=2>phone.</FONT>
<BR><FONT SIZE=2>You could make an argument that each of the audio transducer terminations</FONT>
<BR><FONT SIZE=2>has the equivalent of a &quot;hook&quot; event (e.g. hookswitch for handset and</FONT>
<BR><FONT SIZE=2>spkr/release button for handsfree), or that hook and ring should be part of</FONT>
<BR><FONT SIZE=2>the user interface termination, independent of transducer. Or, to be</FONT>
<BR><FONT SIZE=2>extreme, you could even say hook is just another function key and ring is</FONT>
<BR><FONT SIZE=2>just another tone applied to the speaker transducer.</FONT>
<BR><FONT SIZE=2>And something has to figure out when I switch to handsfree and hang up the</FONT>
<BR><FONT SIZE=2>handset that I'm not terminating the call - which argues either for more</FONT>
<BR><FONT SIZE=2>intelligence in the IP Phone (if there is a single &quot;onhook&quot; event, or more</FONT>
<BR><FONT SIZE=2>intelligence in the MGC (if each transducer has it's own &quot;onhook&quot; event).</FONT>
<BR><FONT SIZE=2>It is certainly important that there is clear concensus for</FONT>
<BR><FONT SIZE=2>interoperability.</FONT>
</P>

<P><FONT SIZE=2>Can anyone shine some light on this?</FONT>
</P>

<P><FONT SIZE=2>_____________________________________________________</FONT>
<BR><FONT SIZE=2>Bob Lukas</FONT>
<BR><FONT SIZE=2>Broadcom Canada</FONT>
<BR><FONT SIZE=2>Richmond B.C.</FONT>
<BR><FONT SIZE=2>blukas@broadcom.com</FONT>
<BR><FONT SIZE=2>604-233-8665</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFAA1F.784DF9EC--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Apr 19 13:10:15 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10227
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 19 Apr 2000 13:10:13 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B3151080@standards.nortelnetworks.com>; Wed, 19 Apr 2000 13:03:47 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8823 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 19 Apr 2000 13:02:13 -0400
Received: from smtprtp1.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.7AF5FFC0@standards.nortelnetworks.com>; Wed, 19 Apr 2000 13:02:13
          -0400
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          smtprtp1.ntcom.nortel.net; Wed, 19 Apr 2000 13:07:43 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <27B9MMR6>; Wed, 19 Apr 2000 13:07:43 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFAA21.C6A92600"
Message-ID:  <8E2783FA4E0CD411888D0000F8CD15D33C36D8@zcard00q.ca.nortel.com>
Date:         Wed, 19 Apr 2000 13:07:35 -0400
Reply-To: Peter Blatherwick <blather@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Peter Blatherwick <blather@NORTELNETWORKS.COM>
Subject:      Re: draft-ietf-megaco-ipphone-02.txt: hookswitch/ringer?
X-To:         "Glasgow, George" <gGlasgow@UNISPHERESOLUTIONS.COM>
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_01BFAA21.C6A92600
Content-Type: text/plain;
        charset="iso-8859-1"

See reply just sent to Bob.  Additional comment in line below.
-- Peter

-----Original Message-----
From: Glasgow, George [mailto:gGlasgow@UNISPHERESOLUTIONS.COM]
Sent: Wednesday, April 19, 2000 08:59
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: draft-ietf-megaco-ipphone-02.txt: hookswitch/ringer?


Bob,
To the best of my knowledge, the task of distinguishing between hang-up and
switching to handsfree mode, has always been in the telephone. All of my
speaker phones at home and in my office work that way.

[PB] Yes, this is generally the situation now.  However it is not nearly as
flexible as separating the elements and allowing full control by the MGC
application.  With separated elements, the MGC application can make the end
device behave as phones do now, but can also easily implement a very much
wider range of applications as well.

I don't see that it would be to our advantage to change this operation,
given that legacy systems will be expected to work identically in a
softswitch environment to the way they work now.

Consistency of operation is important here. Achieving this will mean that
someone can have a regular POTS or ISDN phone alongside an IP phone, and
they will all operate the same way.

[PB] This is beyond legacy.  We can do much better, and still map to legacy
where we want to.

I suppose I'm saying that, in my opinion, the "intelligence" should be in
the IP phone, not the MGC.

[PB] If you want lots of intelligence in the end device, use a peer approach
such as SIP.  Its the other valid model.  Or, you could use Megaco IP Phone
and choose to hide some aspects in the implementation if you want to.  As
long as they are logically organized (in the protocol sense) as a Megaco IP
Phone, interoperability will be good.

Regards,

George Glasgow
Senior Engineer - SRX-3000 Development
Unisphere Solutions,
900 Broken Sound Parkway, B12S,
Boca Raton, FL 33487,
USA
1-561-955-6555 Voice
1-561-955-6477 Fax

gglasgow@unispheresolutions.com <mailto:gglasgow@unispheresolutions.com>


Visit us on the web at: http://www.unispheresolutions.com




-----Original Message-----
From: Bob Lukas [mailto:blukas@BROADCOM.COM]
Sent: Tuesday, April 18, 2000 11:40 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: draft-ietf-megaco-ipphone-02.txt: hookswitch/ringer?


I've been looking at draft-ietf-megaco-ipphone-02.  One thing that isn't
clear to me is in which termination would I expect to find the package that
supports the hookswitch and ringer?

In Megaco, Annex E Basic Packages define hook and ring only in the analog
line supervision package, which is a misnomer if nothing else for an IP
phone.
You could make an argument that each of the audio transducer terminations
has the equivalent of a "hook" event (e.g. hookswitch for handset and
spkr/release button for handsfree), or that hook and ring should be part of
the user interface termination, independent of transducer. Or, to be
extreme, you could even say hook is just another function key and ring is
just another tone applied to the speaker transducer.
And something has to figure out when I switch to handsfree and hang up the
handset that I'm not terminating the call - which argues either for more
intelligence in the IP Phone (if there is a single "onhook" event, or more
intelligence in the MGC (if each transducer has it's own "onhook" event).
It is certainly important that there is clear concensus for
interoperability.

Can anyone shine some light on this?

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

------_=_NextPart_001_01BFAA21.C6A92600
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: draft-ietf-megaco-ipphone-02.txt: hookswitch/ringer?</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Arial">See reply just sent to =
Bob.&nbsp; Additional comment in line below.&nbsp; </FONT>
<BR><FONT COLOR=3D"#0000FF" FACE=3D"Arial">-- Peter</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">From: Glasgow, George [<A =
HREF=3D"mailto:gGlasgow@UNISPHERESOLUTIONS.COM">mailto:gGlasgow@UNISPHER=
ESOLUTIONS.COM</A>]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Sent: Wednesday, April 19, 2000 =
08:59</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">To: =
MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Subject: Re: =
draft-ietf-megaco-ipphone-02.txt: hookswitch/ringer?</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Bob,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">To the best of my knowledge, the task =
of distinguishing between hang-up and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">switching to handsfree mode, has =
always been in the telephone. All of my</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">speaker phones at home and in my =
office work that way.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Arial">[PB] Yes, this is generally =
the situation now.&nbsp; However it is not nearly as flexible as =
separating the elements and allowing full control by the MGC =
application.&nbsp; With separated elements, the MGC application can =
make the end device behave as phones do now, but can also easily =
implement a very much wider range of application</FONT><FONT =
COLOR=3D"#0000FF" FACE=3D"Arial">s</FONT><FONT COLOR=3D"#0000FF" =
FACE=3D"Arial"> as well.&nbsp; </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I don't see that it would be to our =
advantage to change this operation,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">given that legacy systems will be =
expected to work identically in a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">softswitch environment to the way =
they work now.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Consistency of operation is important =
here. Achieving this will mean that</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">someone can have a regular POTS or =
ISDN phone alongside an IP phone, and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">they will all operate the same =
way.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Arial">[PB] This is beyond =
legacy.&nbsp;</FONT> <FONT COLOR=3D"#0000FF" FACE=3D"Arial">We can do =
much better, and still map to legacy where we want to.&nbsp;</FONT>=20
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I suppose I'm saying that, in my =
opinion, the &quot;intelligence&quot; should be in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the IP phone, not the MGC.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" FACE=3D"Arial">[PB] If you want</FONT><FONT =
COLOR=3D"#0000FF" FACE=3D"Arial"> lots of</FONT><FONT COLOR=3D"#0000FF" =
FACE=3D"Arial"> intelligence in the end device, use a peer approach =
such as SIP.&nbsp; Its the other valid model.&nbsp;</FONT> <FONT =
COLOR=3D"#0000FF" FACE=3D"Arial">Or, you could use Megaco IP Phone and =
choose to hide some aspects in the implementation if you want to.&nbsp; =
As long as they are logically organized (in the protocol sense) as a =
Megaco IP Phone, interoperability will be good.&nbsp;</FONT> </P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Regards,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">George Glasgow</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Senior Engineer - SRX-3000 =
Development</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Unisphere Solutions,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">900 Broken Sound Parkway, =
B12S,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Boca Raton, FL 33487,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">USA</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">1-561-955-6555 Voice</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">1-561-955-6477 Fax</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">gglasgow@unispheresolutions.com &lt;<A =
HREF=3D"mailto:gglasgow@unispheresolutions.com">mailto:gglasgow@unispher=
esolutions.com</A>&gt;</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Visit us on the web at: <A =
HREF=3D"http://www.unispheresolutions.com" =
TARGET=3D"_blank">http://www.unispheresolutions.com</A></FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">From: Bob Lukas [<A =
HREF=3D"mailto:blukas@BROADCOM.COM">mailto:blukas@BROADCOM.COM</A>]</FON=
T>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Sent: Tuesday, April 18, 2000 11:40 =
PM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">To: =
MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Subject: =
draft-ietf-megaco-ipphone-02.txt: hookswitch/ringer?</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">I've been looking at =
draft-ietf-megaco-ipphone-02.&nbsp; One thing that isn't</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">clear to me is in which termination =
would I expect to find the package that</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">supports the hookswitch and =
ringer?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In Megaco, Annex E Basic Packages =
define hook and ring only in the analog</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">line supervision package, which is a =
misnomer if nothing else for an IP</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">phone.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">You could make an argument that each =
of the audio transducer terminations</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">has the equivalent of a =
&quot;hook&quot; event (e.g. hookswitch for handset and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">spkr/release button for handsfree), =
or that hook and ring should be part of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the user interface termination, =
independent of transducer. Or, to be</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">extreme, you could even say hook is =
just another function key and ring is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">just another tone applied to the =
speaker transducer.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">And something has to figure out when =
I switch to handsfree and hang up the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">handset that I'm not terminating the =
call - which argues either for more</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">intelligence in the IP Phone (if =
there is a single &quot;onhook&quot; event, or more</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">intelligence in the MGC (if each =
transducer has it's own &quot;onhook&quot; event).</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">It is certainly important that there =
is clear concensus for</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">interoperability.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Can anyone shine some light on =
this?</FONT>
</P>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">_____________________________________________________</FO=
NT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Bob Lukas</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Broadcom Canada</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Richmond B.C.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">blukas@broadcom.com</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">604-233-8665</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BFAA21.C6A92600--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Apr 19 16:17:37 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13562
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 19 Apr 2000 16:17:37 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E03335A0@standards.nortelnetworks.com>; Wed, 19 Apr 2000 16:11:10 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 9123 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 19 Apr 2000 16:09:59 -0400
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.B5C00D70@standards.nortelnetworks.com>; Wed, 19 Apr 2000
          16:09:58 -0400
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Wed, 19 Apr 2000 15:10:57 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <269WT826>; Wed, 19 Apr 2000 15:10:51 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B6C4@zcard00g.ca.nortel.com>
Date:         Wed, 19 Apr 2000 15:10:50 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Unspecified Properties, Defaults and Value Replacement
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I have done some further thinking and research on the "unspecified value"
issue.  Here are my new thoughts.  I would very much welcome comments.

Section 6.2.4 presents a data model which is not an accurate representation
of subsequent parts of the protocol document.  There are several statements:
 -- most properties have default values
 -- when a termination is created, unspecified properties are given their
default values
 -- when a termination is modified, unspecified properties retain their
previous values.

As noted in a previous thread, a lot of our data behaviour is actually
specified at the descriptor level.  In addition, the sensible initial state
for most descriptors is either "no value" or "empty", although this could be
modified by provisioning for specific terminations.  Here's a complete list
of descriptors and the initial values I think we intend:

Descriptor              Initial Value When Termination Created
----------------
--------------------------------------------------------
Modem                  No value
Multiplex                No value

Media                    See components
TerminationState    ServiceStates=InService; EventBufferControl=Off
Stream                  See components
Local                     Empty
Remote                 Empty
LocalControl          Mode=inactive[?]; Reservexx=Off

Events                  Empty, RequestID=0[?]
EventBuffer            Empty
Signals                 Empty
Audit                    Empty
DigitMap               Empty

I propose that the above table be added to section 6.2.4 and and the text on
initial values for properties be modified to refer to the table instead
(with suitable reference to packages where applicable).  The question marks
for Mode and RequestID are because we do not actually specify those defaults
in our text.

The other point to be straightened out is the fact that descriptor-level
semantics are important.  I think the following are true statements of our
intent.  If so, sections 6.2.4 and 7.1.1 should be modified to reflect them:

 (1) When a specific descriptor is specified in a command, the contents of
that descriptor completely replace any previous settings of properties
within that descriptor.  THERE ARE THREE EXCEPTIONS: DigitMap does its
replacement at the level of the individual named digit map, and we probably
want unspecified properties in TerminationState and LocalControl to retain
their previous values.

 (2) If a specific descriptor is omitted from a command, its previous
contents are retained.



Tom Taylor
Phone and FAX: +1 613 736 0961
E-mail: taylor@nortelnetworks.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Apr 19 19:34:41 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15965
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 19 Apr 2000 19:34:41 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6BB0A2F0@standards.nortelnetworks.com>; Wed, 19 Apr 2000 19:28:20 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 9254 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 19 Apr 2000 19:26:55 -0400
Received: from centauri.starcon.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.D34BAFB0@standards.nortelnetworks.com>; Wed, 19 Apr 2000 19:16:55
          -0400
Received: from dashaus.hothaus.com (g210-hothaus.att-g.starcon.com
          [216.13.167.210]) by centauri.starcon.com (Post.Office MTA v3.5.3
          release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Wed, 19 Apr 2000
          16:22:44 -0700
Received: by DASHAUS with Internet Mail Service (5.5.2448.0) id <JC67M5TZ>;
          Wed, 19 Apr 2000 16:21:59 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFAA56.0F6E48D0"
Message-ID:  <5713E3714F03D4118AB9009027D5B3A20139C4@NT-RMNA-EXCH>
Date:         Wed, 19 Apr 2000 16:20:43 -0700
Reply-To: Bob Lukas <blukas@BROADCOM.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Bob Lukas <blukas@BROADCOM.COM>
Subject:      Re: draft-ietf-megaco-ipphone-02.txt: hookswitch/ringer?
X-To:         Peter Blatherwick <blather@NORTELNETWORKS.COM>
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_01BFAA56.0F6E48D0
Content-Type: text/plain;
        charset="iso-8859-1"

Peter,
Thanks for the reply. I agree with your philosophy.
I think the source of my problem is the missing Annex G.
It's not part of MegacoH248v16.doc, nor  draft-ietf-megaco-protocol-07.txt.
I guess you are referring to draft-ietf-megaco-otherpkgs-00.txt?

-----Original Message-----
From: Peter Blatherwick [mailto:blather@NORTELNETWORKS.COM]
Sent: Wednesday, April 19, 2000 9:51 AM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: draft-ietf-megaco-ipphone-02.txt: hookswitch/ringer?



Bob, list:

You query is partly specific, partly philosophical, hence the
longish reply.

Specific answers to your queries:

- All user interface related packages (as opposed to audio),
including hookswitch and ringer, are found in the User Interface
termination.  Hookswitch is a well known name within the
Function Key Package, and Ringer is a well known name in
the Indicator Package (see Annex G).   Analog line
supervision is not used, nor is hookswitch attached to
an audio transducer.  See reasoning below.

<snip>


------_=_NextPart_001_01BFAA56.0F6E48D0
Content-Type: text/html;
        charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: draft-ietf-megaco-ipphone-02.txt: hookswitch/ringer?</TITLE>

<META content="MSHTML 5.00.2920.0" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=158001423-19042000>Peter,
</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=158001423-19042000>Thanks
for the reply. I agree with your philosophy.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=158001423-19042000>I
think the source of my problem is the missing Annex G.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=158001423-19042000>It's
not part of MegacoH248v16.doc, nor&nbsp;
draft-ietf-megaco-protocol-07.txt.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=158001423-19042000>I
guess you are referring to
draft-ietf-megaco-otherpkgs-00.txt?</SPAN></FONT></DIV>
<BLOCKQUOTE
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma
  size=2>-----Original Message-----<BR><B>From:</B> Peter Blatherwick
  [mailto:blather@NORTELNETWORKS.COM]<BR><B>Sent:</B> Wednesday, April 19, 2000
  9:51 AM<BR><B>To:</B> MEGACO@STANDARDS.NORTELNETWORKS.COM<BR><B>Subject:</B>
  Re: draft-ietf-megaco-ipphone-02.txt: hookswitch/ringer?<BR><BR></DIV></FONT>
  <P><FONT size=2>Bob, list: </FONT></P>
  <P><FONT size=2>You query is partly specific, partly philosophical, hence the
  </FONT><BR><FONT size=2>longish reply.&nbsp; </FONT></P>
  <P><FONT size=2>Specific answers to your queries:</FONT> </P>
  <P><FONT size=2>- All user interface related packages (as opposed to audio),
  </FONT><BR><FONT size=2>including hookswitch and ringer, are found in the User
  Interface </FONT><BR><FONT size=2>termination.&nbsp; Hookswitch is a well
  known name within the </FONT><BR><FONT size=2>Function Key Package, and Ringer
  is a well known name in </FONT><BR><FONT size=2>the Indicator Package (see
  Annex G).&nbsp;&nbsp; Analog line </FONT><BR><FONT size=2>supervision is not
  used, nor is hookswitch attached to </FONT><BR><FONT size=2>an audio
  transducer.&nbsp; See reasoning below.&nbsp; </FONT></P>
  <P><FONT size=2><SPAN
class=158001423-19042000>&lt;snip&gt;</SPAN></FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01BFAA56.0F6E48D0--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Apr 19 19:43:40 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16051
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 19 Apr 2000 19:43:39 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AF12BD20@standards.nortelnetworks.com>; Wed, 19 Apr 2000 19:37:23 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 9255 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 19 Apr 2000 19:35:34 -0400
Received: from boreas.isi.edu by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.0821BA80@standards.nortelnetworks.com>; Wed, 19 Apr 2000 19:25:33
          -0400
Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu
          (8.8.7/8.8.6) with ESMTP id QAA12767; Wed, 19 Apr 2000 16:31:25 -0700
          (PDT)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Message-ID:  <200004192331.QAA12767@boreas.isi.edu>
Date:         Wed, 19 Apr 2000 16:31:25 -0700
Reply-To: RFC Editor <rfc-ed@ISI.EDU>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and
              ignored.
From: RFC Editor <rfc-ed@ISI.EDU>
Subject:      RFC 2805 on MG Control Protocol Requirements
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--NextPart


A new Request for Comments is now available in online RFC libraries.


        RFC 2805

        Title:      Media Gateway Control Protocol Architecture and
                    Requirements
        Author(s):  N. Greene, M. Ramalho, B. Rosen
        Status:     Informational
        Date:       April 2000
        Mailbox:    ngreene@nortelnetworks.com, mramalho@cisco.com,
                    brosen@eng.fore.com
        Pages:      45
        Characters: 88190
        Updates/Obsoletes/SeeAlso: None

        I-D Tag:    draft-ietf-megaco-reqs-10.txt

        URL:        ftp://ftp.isi.edu/in-notes/rfc2805.txt


This document describes protocol requirements for the Media Gateway
Control Protocol between a Media Gateway Controller and a Media
Gateway.

This document is a product of the Media Gateway Control Working Group
of the IETF.

This memo provides information for the Internet community.  It does
not specify an Internet standard of any kind.  Distribution of this
memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
help: ways_to_get_rfcs.  For example:

        To: rfc-info@RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo
Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="RFC-INFO@RFC-EDITOR.ORG"

Content-Type: text/plain
Content-ID: <000419162835.RFC@RFC-EDITOR.ORG>

RETRIEVE: rfc
DOC-ID: rfc2805

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc2805.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

Content-Type: text/plain
Content-ID: <000419162835.RFC@RFC-EDITOR.ORG>

--OtherAccess--
--NextPart--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr 20 06:25:21 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05065
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 20 Apr 2000 06:25:20 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4B5D4700@standards.nortelnetworks.com>; Thu, 20 Apr 2000 6:18:50 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 9601 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 20 Apr 2000 06:17:12 -0400
Received: from ficon-tech.com (12.10.198.190) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.0F014FE0@standards.nortelnetworks.com>; Thu, 20 Apr 2000 6:17:09
          -0400
Received: from hemantag (vacant4.india.ficon-tech.com [172.25.1.131]) by
          ficon-tech.com (8.9.3/8.8.7) with SMTP id PAA46836 for
          <megaco@standards.nortelnetworks.com>; Thu, 20 Apr 2000 15:53:13
          +0530 (IST) (envelope-from hemantag@ficon-tech.com)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Message-ID:  <031e01bfaab2$7238f820$830119ac@india.ficontech.com>
Date:         Thu, 20 Apr 2000 15:53:04 +0530
Reply-To: Hemant Agrawal <hemantag@FICON-TECH.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Hemant Agrawal <hemantag@FICON-TECH.COM>
Organization: Ficon Technology
Subject:      Event and Signal descriptor on Subtract
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

 Hi Brian, Tom, list,

 In ref to section 7.2.3 for Subtract command
 "When a provisioned Termination is Subtracted from a context, its property
 values shall revert to:
 *    the default value, if specified for the property and not overridden by
provisioning,
 *    otherwise, the provisioned value."


  Is this action also valid for signal and event descriptor, that is, after
a  termination
 is subtracted from a context, MG stops playing signals and stop listening
for
 events (since the default value of Event & Signal Descriptor is NULL).



 thanks
 Hemant Agrawal



 ________________________________________
 Hemant Agrawal
 Ficon Technology
 E-mail: hemantag@ficon-tech.com
 Web: http://www.ficon-tech.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr 20 09:19:31 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09891
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 20 Apr 2000 09:19:31 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A35B23B0@standards.nortelnetworks.com>; Thu, 20 Apr 2000 9:13:06 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 9767 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 20 Apr 2000 09:11:49 -0400
Received: from smtprich.nortel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.759993D0@standards.nortelnetworks.com>; Thu, 20 Apr 2000 9:11:49
          -0400
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprich.nortel.com; Thu, 20 Apr 2000 08:17:16 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <269W4JT1>; Thu, 20 Apr 2000 08:16:09 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFAACA.9725E6E4"
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B6C7@zcard00g.ca.nortel.com>
Date:         Thu, 20 Apr 2000 08:16:10 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Event and Signal descriptor on Subtract
X-To:         Hemant Agrawal <hemantag@FICON-TECH.COM>
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_01BFAACA.9725E6E4
Content-Type: text/plain

Based on the E-mail I just put out yesterday, this would be so, but the
default values of these descriptors (in the absence of provisioned values)
would be "empty".

> -----Original Message-----
> From: Hemant Agrawal [SMTP:hemantag@FICON-TECH.COM]
> Sent: Thursday, April 20, 2000 6:23 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Event and Signal descriptor on Subtract
>
>  Hi Brian, Tom, list,
>
>  In ref to section 7.2.3 for Subtract command
>  "When a provisioned Termination is Subtracted from a context, its
> property
>  values shall revert to:
>  *    the default value, if specified for the property and not overridden
> by
> provisioning,
>  *    otherwise, the provisioned value."
>
>
>   Is this action also valid for signal and event descriptor, that is,
> after
> a  termination
>  is subtracted from a context, MG stops playing signals and stop listening
> for
>  events (since the default value of Event & Signal Descriptor is NULL).
>
>
>
>  thanks
>  Hemant Agrawal
>
>
>
>  ________________________________________
>  Hemant Agrawal
>  Ficon Technology
>  E-mail: hemantag@ficon-tech.com
>  Web: http://www.ficon-tech.com

------_=_NextPart_001_01BFAACA.9725E6E4
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: Event and Signal descriptor on Subtract</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Based on the E-mail =
I just put out yesterday, this would be so, but the default values of =
these descriptors (in the absence of provisioned values) would be =
&quot;empty&quot;.</FONT></P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Hemant Agrawal =
[SMTP:hemantag@FICON-TECH.COM]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Thursday, April 20, 2000 6:23 AM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Event and Signal descriptor on =
Subtract</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;Hi Brian, Tom, list,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;In ref to section 7.2.3 for =
Subtract command</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&quot;When a provisioned =
Termination is Subtracted from a context, its property</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;values shall revert to:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;*&nbsp;&nbsp;&nbsp; the default =
value, if specified for the property and not overridden by</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">provisioning,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;*&nbsp;&nbsp;&nbsp; otherwise, =
the provisioned value.&quot;</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; Is this action also valid for =
signal and event descriptor, that is, after</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">a&nbsp; termination</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;is subtracted from a context, =
MG stops playing signals and stop listening</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">for</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;events (since the default value =
of Event &amp; Signal Descriptor is NULL).</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;thanks</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;Hemant Agrawal</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;________________________________________</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;Hemant Agrawal</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;Ficon Technology</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;E-mail: =
hemantag@ficon-tech.com</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;Web:<U> </U></FONT><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://www.ficon-tech.com" =
TARGET=3D"_blank">http://www.ficon-tech.com</A></FONT></U>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFAACA.9725E6E4--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr 20 09:56:04 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10606
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 20 Apr 2000 09:56:00 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.ACC0E4D0@standards.nortelnetworks.com>; Thu, 20 Apr 2000 9:49:09 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 9801 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 20 Apr 2000 09:48:59 -0400
Received: from smtprtp.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.A6FF8150@standards.nortelnetworks.com>; Thu, 20 Apr 2000 9:48:59
          -0400
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          smtprtp.ntcom.nortel.net; Thu, 20 Apr 2000 09:54:41 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <27B9M01N>; Thu, 20 Apr 2000 09:54:41 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BFAACF.F8CC384E"
Message-ID:  <8E2783FA4E0CD411888D0000F8CD15D33C36DA@zcard00q.ca.nortel.com>
Date:         Thu, 20 Apr 2000 09:54:32 -0400
Reply-To: Peter Blatherwick <blather@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Peter Blatherwick <blather@NORTELNETWORKS.COM>
Subject:      Re: draft-ietf-megaco-ipphone-02.txt: hookswitch/ringer?
X-To:         Bob Lukas <blukas@broadcom.com>
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_01BFAACF.F8CC384E
Content-Type: multipart/alternative;
        boundary="----_=_NextPart_001_01BFAACF.F8CC384E"


------_=_NextPart_001_01BFAACF.F8CC384E
Content-Type: text/plain;
        charset="iso-8859-1"

I guess this is one of those problems of working in two standards bodies at
once.  Annex G is currently in TD form available in ITU, but does not
currently exist in the form of an IETF I-D or RFC.  I'm very glad to see the
2 bodies working together so closely, but it is a pain sometimes.  Tom is
currently trying to figure out process for the package documents in general,
on a different thread in this e-list.

I've attached the latest Annex G TD I have (UI package TD.doc), output from
the Geneva ITU meeting in Feb, but not sure it will make it through the
reflector (I think not).  I will get it posted in the Megaco repository
(oops, should be there).

The user interface related packages detailed as part of
draft-ietf-megaco-otherpkgs-00.txt (Display, Keypad, Function Key,
Indicator, Soft Key, Ancillary Input) are very close to the Annex G TD, but
not quite the same and missing a few details found in review.  Explanatory
text is also improved in Annex G.  Certainly the general form is the same
between the two.

-- Peter

-----Original Message-----
From: Bob Lukas [mailto:blukas@broadcom.com]
Sent: Wednesday, April 19, 2000 19:21
To: Blatherwick, Peter [CAR:AT14:EXCH]; MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: RE: draft-ietf-megaco-ipphone-02.txt: hookswitch/ringer?


Peter,
Thanks for the reply. I agree with your philosophy.
I think the source of my problem is the missing Annex G.
It's not part of MegacoH248v16.doc, nor  draft-ietf-megaco-protocol-07.txt.
I guess you are referring to draft-ietf-megaco-otherpkgs-00.txt?

-----Original Message-----
From: Peter Blatherwick [mailto:blather@NORTELNETWORKS.COM]
Sent: Wednesday, April 19, 2000 9:51 AM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: draft-ietf-megaco-ipphone-02.txt: hookswitch/ringer?



Bob, list:

You query is partly specific, partly philosophical, hence the
longish reply.

Specific answers to your queries:

- All user interface related packages (as opposed to audio),
including hookswitch and ringer, are found in the User Interface
termination.  Hookswitch is a well known name within the
Function Key Package, and Ringer is a well known name in
the Indicator Package (see Annex G).   Analog line
supervision is not used, nor is hookswitch attached to
an audio transducer.  See reasoning below.

<snip>


------_=_NextPart_001_01BFAACF.F8CC384E
Content-Type: text/html;
        charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: draft-ietf-megaco-ipphone-02.txt: hookswitch/ringer?</TITLE>

<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=310232713-20042000>I
guess this is one of those problems of working in two standards bodies at
once.&nbsp; Annex G is currently in TD form available in ITU, but does not
currently exist in the form of an IETF I-D or RFC.&nbsp; I'm very glad to see
the 2 bodies working together so closely, but it is a pain sometimes.&nbsp;
<FONT color=#0000ff face=Arial size=2><SPAN class=310232713-20042000>Tom is
currently trying to figure out process for the package documents in general, on
a different thread in this e-list.&nbsp; </SPAN></FONT></SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=310232713-20042000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=310232713-20042000>I've
attached the latest Annex G TD I have (UI package TD.doc), output from the
Geneva ITU meeting in Feb, but not sure it will make it through the reflector (I
think not).&nbsp; I will get it posted in the Megaco repository (oops, should be
there).&nbsp; </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=310232713-20042000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=310232713-20042000>The
user interface related packages detailed as part of
draft-ietf-megaco-otherpkgs-00.txt (Display, Keypad, Function Key, Indicator,
Soft Key, Ancillary Input) are very close to the Annex G TD, but not quite the
same and missing a few details found in review.&nbsp; Explanatory text is also
improved in Annex G.&nbsp; Certainly the general form is the same between the
two.&nbsp; </SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=310232713-20042000>--
Peter</SPAN></FONT></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma
  size=2>-----Original Message-----<BR><B>From:</B> Bob Lukas
  [mailto:blukas@broadcom.com]<BR><B>Sent:</B> Wednesday, April 19, 2000
  19:21<BR><B>To:</B> Blatherwick, Peter [CAR:AT14:EXCH];
  MEGACO@STANDARDS.NORTELNETWORKS.COM<BR><B>Subject:</B> RE:
  draft-ietf-megaco-ipphone-02.txt: hookswitch/ringer?<BR><BR></DIV></FONT>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=158001423-19042000>Peter, </SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=158001423-19042000>Thanks for the reply. I agree with your
  philosophy.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=158001423-19042000>I
  think the source of my problem is the missing Annex G.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=158001423-19042000>It's
  not part of MegacoH248v16.doc, nor&nbsp;
  draft-ietf-megaco-protocol-07.txt.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=158001423-19042000>I
  guess you are referring to
  draft-ietf-megaco-otherpkgs-00.txt?</SPAN></FONT></DIV>
  <BLOCKQUOTE
  style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
    <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma
    size=2>-----Original Message-----<BR><B>From:</B> Peter Blatherwick
    [mailto:blather@NORTELNETWORKS.COM]<BR><B>Sent:</B> Wednesday, April 19,
    2000 9:51 AM<BR><B>To:</B>
    MEGACO@STANDARDS.NORTELNETWORKS.COM<BR><B>Subject:</B> Re:
    draft-ietf-megaco-ipphone-02.txt: hookswitch/ringer?<BR><BR></DIV></FONT>
    <P><FONT size=2>Bob, list: </FONT></P>
    <P><FONT size=2>You query is partly specific, partly philosophical, hence
    the </FONT><BR><FONT size=2>longish reply.&nbsp; </FONT></P>
    <P><FONT size=2>Specific answers to your queries:</FONT> </P>
    <P><FONT size=2>- All user interface related packages (as opposed to audio),
    </FONT><BR><FONT size=2>including hookswitch and ringer, are found in the
    User Interface </FONT><BR><FONT size=2>termination.&nbsp; Hookswitch is a
    well known name within the </FONT><BR><FONT size=2>Function Key Package, and
    Ringer is a well known name in </FONT><BR><FONT size=2>the Indicator Package
    (see Annex G).&nbsp;&nbsp; Analog line </FONT><BR><FONT size=2>supervision
    is not used, nor is hookswitch attached to </FONT><BR><FONT size=2>an audio
    transducer.&nbsp; See reasoning below.&nbsp; </FONT></P>
    <P><FONT size=2><SPAN
  class=158001423-19042000>&lt;snip&gt;</SPAN></FONT></P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01BFAACF.F8CC384E--

------_=_NextPart_000_01BFAACF.F8CC384E
Content-Type: application/msword;
        name="UI package TD.doc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
        filename="UI package TD.doc"
Content-Transfer-Encoding: base64

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAggAAAAAAAAAA
EAAAhAAAAAEAAAD+////AAAAAIAAAACBAAAA////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////s
pcEAWQAJBAAAABK/AAAAAAAAEAAAAAAABAAA0ToAAA4AYmpiavNX81cAAAAAAAAAAAAAAAAAAAAA
AAAJBBYANHYAAJE9AQCRPQEAYDUAAAAAAABwAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA
AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAF0AAAAAAGoRAAAAAAAAahEAAGoR
AAAAAAAAahEAAAAAAABqEQAAAAAAAGoRAAAAAAAAahEAABQAAAAAAAAAAAAAAJoRAAAAAAAAmhEA
AAAAAACaEQAAAAAAAJoRAAA4AAAA0hEAAAwAAADeEQAAhAAAAJoRAAAAAAAAckwAANIBAAC+EgAA
AAAAAL4SAABeAAAAHBMAAAAAAAAcEwAAAAAAABwTAAAAAAAAHBMAAOYAAAACFAAARAAAAEYUAAAk
AAAAnUMAAAIAAACfQwAAAAAAAJ9DAAAAAAAAn0MAAFYAAAD1QwAAIgQAABdIAAAiBAAAOUwAACQA
AABETgAA9AEAADhQAADcAAAAXUwAABUAAAAAAAAAAAAAAAAAAAAAAAAAahEAAAAAAABqFAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAcEwAAAAAAABwTAAAAAAAAahQAAAAAAABqFAAAAAAAAF1MAAAAAAAA
migAAAAAAABqEQAAAAAAAGoRAAAAAAAAHBMAAAAAAAAAAAAAAAAAABwTAAAAAAAAvhIAAAAAAACa
KAAAAAAAAJooAAAAAAAAmigAAAAAAABqFAAA8ggAAGoRAAAAAAAAHBMAAAAAAABqEQAAAAAAABwT
AAAAAAAAnUMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfhEAAA4AAACMEQAADgAAAGoRAAAAAAAAahEA
AAAAAABqEQAAAAAAAGoRAAAAAAAAahQAAAAAAACdQwAAAAAAAJooAAB2BAAAmigAAAAAAAAQLQAA
ZgMAAKZAAACzAgAAahEAAAAAAABqEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnUMAAAAAAAAcEwAAAAAAAGISAABcAAAAAN4Tj/V3
vwGaEQAAAAAAAJoRAAAAAAAAXB0AAD4LAABZQwAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASVRV
IC0gVGVsZWNvbW11bmljYXRpb24gU3RhbmRhcmRpemF0aW9uIFNlY3RvcglUZW1wb3JhcnkgRG9j
dW1lbnQgWFhYL1BMRU4NU1RVRFkgR1JPVVAgMTYNDUdlbmV2YSwgNy0xOCBGZWJydWFyeSAyMDAw
DQ1RdWVzdGlvbihzKToJMTQvMTYNDVNPVVJDRSo6CVJhcHBvcnRldXINDVRJVExFOglILjI0OCBB
bm5leCBHOiBVc2VyIEludGVyZmFjZSBFbGVtZW50cyBhbmQgQWN0aW9ucyBQYWNrYWdlcyBmb3Ig
RGV0ZXJtaW5hdGlvbg1fX19fX19fX19fX19fX19fX18NDUludHJvZHVjdGlvbg1UaGUgZm9sbG93
aW5nIHBhY2thZ2VzIGRlZmluZSBhIGZyYW1ld29yayBmb3Igc3BlY2lmeWluZyBjYXBhYmlsaXRp
ZXMgYXNzb2NpYXRlZCB3aXRoIHVzZXIgaW50ZXJmYWNlIGVsZW1lbnRzLCBzdWNoIGFzIHRleHQg
ZGlzcGxheSwga2V5cywgZHluYW1pY2FsbHkgbGFiZWxlZCBrZXlzLCBpbmRpY2F0b3JzIGFuZCBh
bHBoYW51bWVyaWMgaW5wdXQuIEluIGFkZGl0aW9uLCBzcGVjaWZpYyBleHRlbnNpb24gcGFja2Fn
ZXMgZm9yIHRlbGVwaG9uZSBrZXlwYWRzIGFuZCB0ZWxlcGhvbmUgZnVuY3Rpb24ga2V5cyBhcmUg
ZGVmaW5lZC4NUHJvcG9zZWQgUGFja2FnZXMNRGlzcGxheSBQYWNrYWdlDVBhY2thZ2VJRDogZGlz
LCAweDAwMjUNVmVyc2lvbjogMQ1FeHRlbmRzOiBOb25lDQ1UaGlzIHBhY2thZ2UgZGVmaW5lcyBw
cm9wZXJ0aWVzIGFuZCBzaWduYWxzIGFzc29jaWF0ZWQgd2l0aCB0ZXh0IGRpc3BsYXkgdXNlciBp
bnRlcmZhY2UgZWxlbWVudHMuICBTZWUgUHJvY2VkdXJlcyBmb3IgZGV0YWlscyBvZiBvcGVyYXRp
b24uICANDVByb3BlcnRpZXMNTnVtYmVyIG9mIHJvd3MNUHJvcGVydHlJRDogbnJvd3MgKDB4MDAw
MSkNRGVzY3JpcHRpb246IE1heGltdW0gbnVtYmVyIG9mIHJvd3Mgb24gdGhlIGRpc3BsYXkgDVR5
cGU6IGludGVnZXINRGVmaW5lZCBpbjogVGVybWluYXRpb25TdGF0ZS4gDUNoYXJhY3RlcmlzdGlj
czogcmVhZCBvbmx5Og0NTnVtYmVyIG9mIGNvbHVtbnMNUHJvcGVydHlJRDogbmNvbHMgKDB4MDAw
MikNRGVzY3JpcHRpb246IE1heGltdW0gbnVtYmVyIG9mIGNvbHVtbnMgb24gdGhlIGRpc3BsYXkg
DVR5cGU6IGludGVnZXINRGVmaW5lZCBpbjogVGVybWluYXRpb25TdGF0ZS4gDUNoYXJhY3Rlcmlz
dGljczogcmVhZCBvbmx5Og0NU3VwcG9ydGVkIHVuaWNvZGUgY29kZSBwYWdlcw1Qcm9wZXJ0eUlE
OiBjZHBncyAoMHgwMDAzKQ1EZXNjcmlwdGlvbjogYSBsaXN0IG9mIHN1cHBvcnRlZCB1bmljb2Rl
IHBhZ2VzIA1UeXBlOiBsaXN0IG9mIGVudW1lcmF0ZWQgdHlwZQ1EZWZpbmVkIGluOiBUZXJtaW5h
dGlvblN0YXRlLiANQ2hhcmFjdGVyaXN0aWNzOiByZWFkIG9ubHk6DUV4YW1wbGU6IGlmIHRoZSB0
ZXh0IGRpc3BsYXkgZWxlbWVudCBzdXBwb3J0cyBVKzI1MDAgLT5VKzI1ZmYsIFUrMjYwMCAtPlUr
MjZmZiBhbmQgVSsyNzAwIC0+IFUrMjc3ZiwgdGhpcyBwcm9wZXJ0eSB3b3VsZCByZXR1cm4gIjI1
MCwgMjU4LCAyNjAsIDI2OCwgMjcwIiBpbiBjZHBncy4NVW5pY29kZSBwYWdlIFUrMDAwMCAtPiBV
KzAwZmYgc2hhbGwgYmUgc3VwcG9ydGVkIGluIGFsbCBpbXBsZW1lbnRhdGlvbnMuDQ1DdXJzb3Ig
cm93IHBvc2l0aW9uDVByb3BlcnR5SUQ6IGNyICgweDAwMDQpDVR5cGU6IGludGVnZXINRGVmaW5l
ZCBpbjogVGVybWluYXRpb25TdGF0ZS4gDUNoYXJhY3RlcmlzdGljczogcmVhZCBhbmQgd3JpdGU6
DQ1DdXJzb3IgY29sdW1uIHBvc2l0aW9uDVByb3BlcnR5SUQ6IGNjICgweDAwMDUpDVR5cGU6IGlu
dGVnZXINRGVmaW5lZCBpbjogVGVybWluYXRpb25TdGF0ZS4gDUNoYXJhY3RlcmlzdGljczogcmVh
ZCBhbmQgd3JpdGUuDQ1Ob3RlOiByb3cgYW5kIGNvbHVtbiBudW1iZXJpbmcgYmVnaW4gYXQgMC4g
IEEgZGlzcGxheSdzIG9yaWdpbiBpcyByb3cgMCwgY29sdW1uIDAuICBUaGUgb3JpZ2luIGlzIGF0
IHRoZSB0b3AgbGVmdCBjb3JuZXINDUV2ZW50cw1Ob25lDQ1TaWduYWxzDURpc3BsYXkNDVNpZ25h
bElEOiBkaSAoMHgwMDAxKQ1EZXNjcmlwdGlvbjogRGlzcGxheSB0ZXh0LiAgDVBhcmFtZXRlcnMg
DVJvdw1QYXJhbWV0ZXJJRDogciAoMHgwMDAxKQ1UeXBlOiBJbnRlZ2VyDUluc2VydGlvbiBwb2lu
dCByb3csIHJlbGF0aXZlIHRvIDAsMC4gIERlZmF1bHQgaXMgY3VycmVudCBjdXJzb3IgcG9zaXRp
b24uDQ1Db2x1bW4NUGFyYW1ldGVySUQ6IGMgKDB4MDAwMikNVHlwZTogSW50ZWdlcg1JbnNlcnRp
b24gcG9pbnQgY29sdW1uLCByZWxhdGl2ZSB0byAwLDAuICBEZWZhdWx0IGlzIGN1cnJlbnQgY3Vy
c29yIHBvc2l0aW9uLg0NU3RyaW5nDVBhcmFtZXRlcklEOiBzdCAoMHgwMDAzKQ1UeXBlOiBTdHJp
bmcNRGVmYXVsdCBpcyBlbXB0eSBzdHJpbmcgKG1vdmVzIGN1cnNvciBwb3NpdGlvbikuICANDUF0
dHJpYnV0ZQ1QYXJhbWV0ZXJJRDogYSAoMHgwMDA0KQ1UeXBlOiBlbnVtZXJhdGVkIG9yIGxpc3Qg
b2YgZW51bWVyYXRlZA1Qb3NzaWJsZSB2YWx1ZXM6IHBsYWluICgweDAwMDEpLCBibGluayAoMHgw
MDAyKSwgaW52ZXJ0ICgweDAwMDMpLA0gICB1bmRlcmxpbmUgKDB4MDAwNCkNRGVmYXVsdCBWYWx1
ZTogUGxhaW4NDUNsZWFyIERpc3BsYXkNU2lnbmFsSUQ6IGNsZCwgMHgwMDAyDQ1EZXNjcmlwdGlv
bjoNVGhpcyBzaWduYWwgY2xlYXJzIHRoZSBlbnRpcmUgZGlzcGxheSBhbmQgcmVzZXRzIHRoZSBj
dXJyZW50IGN1cnNvciBwb3NpdGlvbiB0byB0aGUgb3JpZ2luIChyb3cgMCwgY29sdW1uIDApLg0N
UGFyYW1ldGVyczogDU5vbmUNDVN0YXRpc3RpY3MNTm9uZQ0NUHJvY2VkdXJlcw1Vbmljb2RlIGlz
IHN1cHBvcnRlZCB0byBwcm92aWRlIGZvciBtdWx0aXBsZSBsYW5ndWFnZXMuICBUaGUgVW5pY29k
ZSBTdGFuZGFyZCwgVmVyc2lvbiAyLjAgb3IgSVNPL0lFQyAxMDY0Ni0xOjE5OTMgW3h4eF0gc2hh
bGwgYmUgdGhlIGRlZmluaXRpdmUgc3RhbmRhcmQgaW50ZW5kZWQgd2hlbiB0aGUgdGVybSBVbmlj
b2RlIGlzIHVzZWQgd2l0aGluIHRoZSBjb250ZXh0IG9mIHRoaXMgZG9jdW1lbnQuICBBbGwgdGV4
dCBkaXNwbGF5IGVsZW1lbnRzIHNoYWxsIGF0IGxlYXN0IHN1cHBvcnQgdGhlIFVuaWNvZGUgcGFn
ZXMgVSswMDAwIC0+IFUrMDBmZiBhcyB0aGUgYmFzaWMgY2hhcmFjdGVyIHNldC4gIEFsbCB0ZXh0
IHN0cmluZ3Mgc2hhbGwgYmUgZW5jb2RlZCB1c2luZyBVVEYtOCBhcyBkZWZpbmVkIGluIElTTy9J
RUMgMTA2NDYgQU0xIFt4eHhdLiAgDUluIHRoZSBEaXNwbGF5IHNpZ25hbCwgdGV4dCB3aWxsIGJl
IGluc2VydGVkIGJlZ2lubmluZyBhdCB0aGUgcm93IGFuZCBjb2x1bW4gZ2l2ZW4gaW4gdGhlIHNp
Z25hbCBwYXJhbWV0ZXJzLCByZWxhdGl2ZSB0byAwLDAuICBJZiBubyByb3cgYW5kIGNvbHVtbiBw
YXJhbWV0ZXJzIGFyZSBnaXZlbiwgdGhlIHRleHQgd2lsbCBiZSBpbnNlcnRlZCBzdGFydGluZyBh
dCB0aGUgY3VycmVudCBjdXJzb3IgcG9zaXRpb24uICBUaGUgY3VycmVudCBjdXJzb3IgcG9zaXRp
b24gd2lsbCBhbHdheXMgYmUgYWR2YW5jZWQgdG8gdGhlIHBvc2l0aW9uIGltbWVkaWF0ZWx5IGFm
dGVyIHRoZSBsYXN0IGNoYXJhY3RlciBpbnNlcnRlZC4NQ2FycmlhZ2UgcmV0dXJuIDxVbmljb2Rl
IFUrMDAwRD4gaXMgc3VwcG9ydGVkIGluLXN0cmluZywgYW5kIG1vdmVzIHRoZSB0ZXh0IGlucHV0
IHRvIHRoZSBiZWdpbm5pbmcgb2YgdGhlIG5leHQgbGluZSwgY2xlYXJpbmcgdGhlIHJlbWFpbmRl
ciAoaWYgYW55KSBvZiB0aGUgY3VycmVudCBsaW5lLiANVGV4dCB3cmFwcGluZyBpcyBub3QgcHJv
dmlkZWQuIEEgc3RyaW5nIHdpbGwgbm90IHdvcmQgd3JhcCB0byB0aGUgbmV4dCByb3cuICBJZiBh
IHN0cmluZyBjYW5ub3QgZml0IGludG8gdGhlIGN1cnJlbnQgcm93LCBpdCB3aWxsIGJlIHRydW5j
YXRlZCB3aXRob3V0IHdhcm5pbmcuDVRoZSBhdHRyaWJ1dGUgcGFyYW1ldGVyIGFwcGxpZXMgdG8g
YWxsIGNoYXJhY3RlcnMgY29udGFpbmVkIGluIHRoZSBjdXJyZW50IHNpZ25hbC4gIElmIG5vIGF0
dHJpYnV0ZSBpcyBwcm92aWRlZCwgcGxhaW4gdGV4dCB3aWxsIGJlIGRpc3BsYXllZC4gIEZvciBl
eGFtcGxlLCB0byB0dXJuIG9uIGFuIGF0dHJpYnV0ZSBpbiB0aGUgbWlkZGxlIG9mIGEgc3RyaW5n
LCBvbmUgd291bGQgc2VuZCBhIHNpZ25hbCB3aXRoIGEgYmVnaW5uaW5nIHN1Yi1zdHJpbmcgb2Yg
cGxhaW4gdGV4dCwgZm9sbG93IGJ5IGEgc2lnbmFsIHdpdGggdGhlIGRlc2lyZWQgYXR0cmlidXRl
KHMpIGZvciB0aGUgbWlkZGxlIHN1Yi1zdHJpbmcsIGFuZCBmaW5pc2hpbmcgd2l0aCB0aGUgc2ln
bmFsIGNvbnRhaW5pbmcgdGhlIHJlbWFpbmluZyBzdWItc3RyaW5nIG9mIHBsYWluIHRleHQuICAN
S2V5IFBhY2thZ2UNUGFja2FnZUlEOiBrZXksIDB4MDAyNg1WZXJzaW9uOiAxDUV4dGVuZHM6IG5v
bmUNVGhpcyBwYWNrYWdlIGRlZmluZXMgdGhlIGJhc2ljIGJlaGF2aW9yIG9mIGtleSB1c2VyIGlu
dGVyZmFjZSBlbGVtZW50cy4gU3BlY2lmaWMga2V5IElEcyBhcmUgc2VsZWN0ZWQgYnkgbmFtZSAo
a2V5aWQpIGZyb20gdGhlIGxpc3Qgb2Yga2V5cy4gIFRoaXMgcGFja2FnZSBkb2VzIG5vdCBzcGVj
aWZ5IHBhcmFtZXRlciB2YWx1ZXMgZm9yIGtleXMuIA1JbnRlbmRlZCB0byBiZSBleHRlbmRlZCBi
eSBvdGhlciBwYWNrYWdlcyB3aGljaCBoYXZlIGtleSBiZWhhdmlvci4NDVByb3BlcnRpZXMNTm9u
ZS4gDQ1FdmVudHMNa2V5ZG93bg0NRXZlbnRJRDoga2QgKDB4MDAwMSkNRGV0ZWN0cyBrZXkgd2Fz
IHByZXNzZWQuICANRXZlbnREZXNjcmlwdG9yIHBhcmFtZXRlcnM6DU5vbmUuIA1PYnNlcnZlZEV2
ZW50RGVzY3JpcHRvciBwYXJhbWV0ZXJzOg1rZXlpZCAoMHgwMDAxKQ1UeXBlOiBFbnVtZXJhdGlv
bg1Qb3NzaWJsZSB2YWx1ZXM6IE5vIHZhbHVlcyBhcmUgc3BlY2lmaWVkIGluIHRoaXMgcGFja2Fn
ZS4gRXh0ZW5zaW9ucyB0byB0aGlzIHBhY2thZ2UgYWRkIHBvc3NpYmxlIHZhbHVlcyBmb3Iga2V5
aWQuDWtleXVwDUV2ZW50SUQ6IGt1ICgweDAwMDIpDURldGVjdHMga2V5IHVwLiAgDUV2ZW50RGVz
Y3JpcHRvciBwYXJhbWV0ZXJzOg1Ob25lLiANDU9ic2VydmVkRXZlbnREZXNjcmlwdG9yIHBhcmFt
ZXRlcnM6DWtleWlkICgweDAwMDEpDVR5cGU6IEVudW1lcmF0aW9uDVBvc3NpYmxlIHZhbHVlczog
Tm8gcG9zc2libGUgdmFsdWVzIGFyZSBzcGVjaWZpZWQgaW4gdGhpcyBwYWNrYWdlLiBFeHRlbnNp
b25zIHRvIHRoaXMgcGFja2FnZSB3b3VsZCBhZGQgcG9zc2libGUgdmFsdWVzIGZvciBrZXlpZC4N
DWR1cmF0aW9uICgweDAwMDIpDVR5cGU6IEludGVnZXIgDVVuaXRzOiBtaWxpc2Vjb25kcw1EZXNj
cmlwdGlvbjogS2V5IHByZXNzIGR1cmF0aW9uIChrZXkgZG93biB0byBrZXkgdXApLiANDVNpZ25h
bHMNTm9uZQ0NU3RhdGlzdGljcw1Ob25lDQ1Qcm9jZWR1cmVzDU5vbmUNDUtleXBhZCBQYWNrYWdl
DVBhY2thZ2VJRDoga3AsIDB4MDAyNw1WZXJzaW9uOiAxDUV4dGVuZHM6IGtleSB2ZXJzaW9uIDEN
VGhpcyBwYWNrYWdlIGRlZmluZXMgdGhlIGtleXBhZCB1c2VyIGludGVyZmFjZSBlbGVtZW50LiAg
VGhlIGtleXBhZCBwYWNrYWdlIGlzIHVzZWQgdG8gcmVwcmVzZW50IGEgc3RhbmRhcmQgMTAgZGln
aXQga2V5IHBhZCBwbHVzIHRoZSAnKicsICcjJywgQSwgQiwgQywgYW5kIEQga2V5cy4gICANDUFk
ZGl0aW9uYWwgS2V5aWQgdmFsdWVzOg0NCU5hbWUJCQkJRGVzY3JpcHRpb24NDQlrMCAoMHgwMDAx
KQkJCUtleXBhZCBkaWdpdCAwDQlrMSAoMHgwMDAyKQkJCUtleXBhZCBkaWdpdCAxDQlrMiAoMHgw
MDAzKQkJCUtleXBhZCBkaWdpdCAyDQlrMyAoMHgwMDA0KQkJCUtleXBhZCBkaWdpdCAzDQlrNCAo
MHgwMDA1KQkJCUtleXBhZCBkaWdpdCA0DQlrNSAoMHgwMDA2KQkJCUtleXBhZCBkaWdpdCA1DQlr
NiAoMHgwMDA3KQkJCUtleXBhZCBkaWdpdCA2DQlrNyAoMHgwMDA4KQkJCUtleXBhZCBkaWdpdCA3
DQlrOCAoMHgwMDA5KQkJCUtleXBhZCBkaWdpdCA4DQlrOSAoMHgwMDBhKQkJCUtleXBhZCBkaWdp
dCA5DQlrKiAoMHgwMDBiKQkJCUtleXBhZCBkaWdpdCAqDQlrIyAoMHgwMDBjKQkJCUtleXBhZCBk
aWdpdCAjDQlrQSAoMHgwMDBkKQkJCUtleXBhZCBkaWdpdCBBDQlrQiAoMHgwMDBlKQkJCUtleXBh
ZCBkaWdpdCBCDQlrQyAoMHgwMDBmKQkJCUtleXBhZCBkaWdpdCBDDQlrRCAoMHgwMDEwKQkJCUtl
eXBhZCBkaWdpdCBEDQ1BZGRpdGlvbmFsIFByb3BlcnRpZXM6IA1Ob25lLiAgDQ1MYWJlbCBLZXkg
UGFja2FnZQ1QYWNrYWdlSUQ6IGxhYmVsa2V5LCAweDAwMjgNVmVyc2lvbjogMQ1FeHRlbmRzOiBr
ZXkgdmVyc2lvbiAxDVRoaXMgcGFja2FnZSBkZWZpbmVzIHRoZSBiYXNpYyBiZWhhdmlvciBvZiBs
YWJlbGVkIGtleSB1c2VyIGludGVyZmFjZSBlbGVtZW50cy4gS2V5IGxhYmVscyBtYXkgYmUgdXNl
ZCwgZm9yIGV4YW1wbGUsIHRvIHByb3ZpZGUgaW5mb3JtYXRpb24gdG8gdGhlIE1HQyByZWdhcmRp
bmcgcHJlLWNvbmZpZ3VyZWQgdGVsZXBob25lIGtleSBhc3NpZ25tZW50cywgYWxsb3dpbmcgdGVs
ZXBob25lIG1vdmVzIGFuZCBjaGFuZ2VzIG91dHNpZGUgdGhlIGluaXRpYWwgYWRtaW5pc3RyYXRp
dmUgZG9tYWluIHdpdGhvdXQgcmVxdWlyaW5nIHJlLWNvbmZpZ3VyYXRpb24gb2Yga2V5cy4gIE1h
eSBhbHNvIGJlIHVzZWQgdG8gcHJvdmlkZSBzdGF0aWMgbGFiZWwgaW5mb3JtYXRpb24gb24gdGhl
IHRlbGVwaG9uZSB1c2VyIGludGVyZmFjZSwgaWRlbnRpZnlpbmcga2V5IGZ1bmN0aW9uIHRvIHRo
ZSB1c2VyIHdpdGhvdXQgdGhlIG5lZWQgZm9yIG1hbnVhbCBsYWJlbGluZy4gIA1TcGVjaWZpYyBr
ZXlzIGFyZSBhZGRyZXNzZWQgYnkgbmFtZSAoa2V5aWQpIGZyb20gdGhlIGxpc3Qgb2Yga2V5cy4g
IFRoaXMgcGFja2FnZSBkb2VzIG5vdCBzcGVjaWZ5IHBhcmFtZXRlciB2YWx1ZXMgZm9yIGtleXMu
IA1JbnRlbmRlZCB0byBiZSBleHRlbmRlZCBieSBvdGhlciBwYWNrYWdlcyB3aGljaCBoYXZlIGtl
eSBiZWhhdmlvci4NDVByb3BlcnRpZXMNa2V5bGlzdA0JVHlwZTogU3RyaW5nLCB1c2luZyB0aGUg
Zm9sbG93aW5nIGZvcm1hdA0JCXt7a2V5aWQsIGxhYmVsLCBsYWJlbF9zaXplfSwgLi4ufQ0NRGVz
Y3JpcHRpb246IA1LZXlsaXN0IHByb3BlcnR5IGFsbG93cyBhdWRpdGluZyBhbmQgc2V0dGluZyBv
ZiBrZXlpZC9sYWJlbCBtYXBwaW5nLiAgTGFiZWwgc2l6ZSBpcyBhbHNvIGdpdmVuLiBUaGlzIHBh
Y2thZ2UgZGVmaW5lcyBzeW50YXggb25seTsgbm8gc3BlY2lmaWMga2V5cyBhcmUgZGVmaW5lZC4g
IFNlZSBkZXJpdmVkIHBhY2thZ2VzIGZvciB0aGUgYWN0dWFsIGtleWlkIGxpc3RzLiAgDQ1TaWdu
YWxzDU5vbmUuDQ1Qcm9jZWR1cmVzDU5vbmUuICANDUZ1bmN0aW9uIEtleSBQYWNrYWdlDVBhY2th
Z2VJRDoga2YsIDB4MDAyOQ1WZXJzaW9uOiAxDUV4dGVuZHM6IGxhYmVsa2V5IHZlcnNpb24gMQ1D
b21tb24gdGVsZXBob25lIGZ1bmN0aW9uIGtleXMgYXJlIGRlZmluZWQgaW4gdGhpcyBwYWNrYWdl
LiAgVGhpcyBhbGxvd3MsIGZvciBleGFtcGxlLCBsaW5lIGtleXMgYW5kIG90aGVyIGZ1bmN0aW9u
IGtleXMgdG8gYmUgaW1wbGVtZW50ZWQgd2l0aG91dCBzcGVjaWZpYyBrbm93bGVkZ2Ugb2YgdGhl
IHBoeXNpY2FsIGxheW91dCBvZiB0aGUgdGVsZXBob25lLiAgDUFkZGl0aW9uYWwga2V5aWQgdmFs
dWVzIGluIGtleXVwIGFuZCBrZXlkb3duIGV2ZW50cyBhbmQga2V5bGlzdCBwcm9wZXJ0eToNDQlO
YW1lCQkJCURlc2NyaXB0aW9uDQ0Ja2ggKDB4MDAxMSkJCQlIb29rc3dpdGNoDQlrbCAoMHgwMDEy
KSAJCQlIb2xkDQlrYyAoMHgwMDEzKQkJCUNvbmZlcmVuY2UNCWt0ICgweDAwMTQpCQkJVHJhbnNm
ZXINCWwwMDEgLSBsOTk5ICgweDAwMTUtMHgwM2ZiKQlTZXQgb2YgbGluZSBrZXlzCQkJDQlmMDAx
IC0gZjk5OSAoMHgwM2ZjLTB4MDdlMikJU2V0IG9mIGFzc2lnbmFibGUgZnVuY3Rpb24ga2V5cw0N
UHJvY2VkdXJlcw1GdW5jdGlvbiBrZXlzIG1heSBoYXZlIHdlbGwga25vd24gbmFtZXMgKGtleWlk
KSBhc3NvY2lhdGVkIHdpdGggZnVuY3Rpb24sIGZvciBleGFtcGxlICJob29rc3dpdGNoIiwgImhv
bGQiLCBldGMuICBUaGVzZSB3ZWxsIGtub3cgbmFtZXMgaWRlbnRpZnkgdGhlIHB1cnBvc2Ugb2Yg
dGhlIHBhcnRpY3VsYXIga2V5IG9uIHRoZSBhY3R1YWwgZGV2aWNlLiAgRnVuY3Rpb24ga2V5cyBt
YXkgYWxzbyBiZSBhc3NpZ25lZCBhIGxhYmVsIGlkZW50aWZpZXIgYnkgdGhlIE1HQy4gIFRoaXMg
YXBwcm9hY2ggYXZvaWRzIGFzc3VtcHRpb25zIGFuZC9vciB0aGUgcmVxdWlyZW1lbnQgZm9yIGFw
cGxpY2F0aW9uIGxldmVsIGtub3dsZWRnZSBvZiBkZXZpY2Utc3BlY2lmaWMgY29uZmlndXJhdGlv
biBvZiB0aGUgcGh5c2ljYWwgcmVzb3VyY2VzIHRvIGRlcml2ZSBpbnRlbmRlZCBmdW5jdGlvbiBv
ZiBrZXlzLiAgDUZ1bmN0aW9uIEtleXMgY2FuIGJlIGNvLXJlbGF0ZWQgd2l0aCBwaHlzaWNhbGx5
IGFzc29jaWF0ZWQgSW5kaWNhdG9ycyB1c2luZyBGdW5jdGlvbiBLZXkga2V5aWQgYW5kIEluZGlj
YXRvciBpbmRpZC4gIElmIHRoZSBJRHMgYXJlIGlkZW50aWNhbCwgdGhlIE1HQyBhcHBsaWNhdGlv
biBjYW4gc2FmZWx5IGFzc3VtZSB0aGF0IHRoZSBrZXkgYW5kIGluZGljYXRvciBhcmUgcGh5c2lj
YWxseSAob3Igb3RoZXJ3aXNlKSBhc3NvY2lhdGVkIG9uIHRoZSBhY3R1YWwgZGV2aWNlLiAgQWdh
aW4sIHRoaXMgYXZvaWRzIGFzc3VtcHRpb25zIGFuZC9vciB0aGUgcmVxdWlyZW1lbnQgZm9yIGFw
cGxpY2F0aW9uIGxldmVsIGtub3dsZWRnZSBvZiBkZXZpY2Utc3BlY2lmaWMgbGF5b3V0IG9mIHRo
ZSBwaHlzaWNhbCByZXNvdXJjZXMuICBTZWUgYWxzbyB0aGUgSW5kaWNhdG9yIHBhY2thZ2UgKGlu
ZCkuDU5PVEU6IFRoZSBrZXkgc2Vuc2Ugb2YgaG9va3N3aXRjaCAoa2V5aWQ9a2gpIGlzIGEgc3Bl
Y2lhbCBjYXNlLiAgS2V5IHVwIGluZGljYXRlcyB0aGUgaG9va3N3aXRjaCBpcyBkZXByZXNzZWQg
KGkuZS4gaGFuZHNldCBpcyBub21pbmFsbHkgb24gaG9vaykuICBLZXkgZG93biBpbmRpY2F0ZXMg
dGhlIGhvb2tzd2l0Y2ggaXMgbGlmdGVkIChpLmUuIGhhbmRzZXQgaXMgbm9taW5hbGx5IG9mZiBo
b29rKS4gIFRoaXMgYWxsb3dzIGZvciBzZW5zaWJsZSB1c2Ugb2YgdGhlIGR1cmF0aW9uIHBhcmFt
ZXRlciBpbiB0aGUga2V5dXAgZXZlbnQgd2hpY2ggd2lsbCBub3JtYWxseSBnaXZlIHRoZSBkdXJh
dGlvbiB0aGUgaGFuZHNldCB3YXMgb2ZmLWhvb2suICANDUluZGljYXRvciBQYWNrYWdlDVBhY2th
Z2VJRDogaW5kLCAweDAwMmENVmVyc2lvbjogMQ1FeHRlbmRzOiBOb25lDVRoaXMgcGFja2FnZSBk
ZWZpbmVzIHRoZSBiYXNpYyBiZWhhdmlvciBvZiBpbmRpY2F0b3IgdXNlciBpbnRlcmZhY2UgZWxl
bWVudHMuIFNwZWNpZmljIGluZGljYXRvcnMgYXJlIGFkZHJlc3NlZCBieSBuYW1lIChpbmRpZCkg
ZnJvbSB0aGUgbGlzdCBvZiBpbmRpY2F0b3JzLiBJbmRpY2F0b3JzIG1heSBoYXZlIHdlbGwtIGtu
b3duIG5hbWVzIChpbmRpZCkgYXNzb2NpYXRlZCB3aXRoIGZ1bmN0aW9uLCBmb3IgZXhhbXBsZSAi
bWVzc2FnZSB3YWl0aW5nIiwgImhvbGQiLCAibGluZSBhY3RpdmUiLCBldGMuIFRoaXMgYWxsb3dz
LCBmb3IgZXhhbXBsZSwgaW5kaWNhdG9ycyB0byBiZSBpbXBsZW1lbnRlZCB3aXRob3V0IHNwZWNp
ZmljIGtub3dsZWRnZSBvZiB0aGUgcGh5c2ljYWwgbGF5b3V0IG9mIHRoZSB0ZWxlcGhvbmUuICAN
SW50ZW5kZWQgdG8gYmUgcG9zc2libGUgdG8gZXh0ZW5kIGJ5IG90aGVyIHBhY2thZ2VzIHdoaWNo
IGhhdmUgaW5kaWNhdG9yIGJlaGF2aW9yLiANUHJvcGVydGllcw1pbmRpY2F0b3JsaXN0DQlUeXBl
OiBTdHJpbmcsIHVzaW5nIHRoZSBmb2xsb3dpbmcgZm9ybWF0DQkJe3tpbmRpZCwgbGFiZWwsIGxh
YmVsX3NpemV9LCAuLi59DQ1FdmVudHMNTm9uZQ0NU2lnbmFscw1TZXRJbmRhY3Rvcg0NU2lnbmFs
SUQ6IGlzICgweDAwMDEpDVNldCBpbmRpY2F0b3Igc3RhdGUuIA1QYXJhbWV0ZXJzOg0NSW5kaWQg
KDB4MDAwMSkJDVR5cGU6IEVudW1lcmF0aW9uLg0JUG9zc2libGUgdmFsdWVzOg0NCU5hbWUJIAkJ
CURlc2NyaXB0aW9uDQ0JaWwgKDB4MDAwMSkJCQlIb2xkDQlpYyAoMHgwMDAyKQkJCUNvbmZlcmVu
Y2UNCWwwMDEtbDk5OSAoMHgwMDAzLTB4MDNmOSkJU2V0IG9mIGxpbmUgaW5kaWNhdG9ycwkJCQ0J
ZjAwMS1mOTk5ICgweDAzZmEtMHgwN2UwKQlTZXQgb2YgYXNzaWduYWJsZSBmdW5jdGlvbiBpbmRp
Y2F0b3JzDQlpciAoMHgwN2UxKQkJCQlSaW5nZXIvQWxlcnRlciBpbmRpY2F0aW9uDQlpbSAoMHgw
N2UyKQkJCQlNZXNzYWdlIHdhaXRpbmcgaW5kaWNhdG9yDQ1zdGF0ZSAoMHgwMDAyKQkNVHlwZTog
RW51bWVyYXRpb24uIA0JUG9zc2libGUgdmFsdWVzOiBPbiAoMHgwMDAxKSwgb2ZmICgweDAwMDIp
LCBibGluayAoMHgwMDAzKSwNICAgZmFzdF9ibGluayAoMHgwMDA0KSwgc2xvd19ibGluayAoMHgw
MDA1KS4NICAgRGVmYXVsdCBpcyBvZmYuICANU3RhdGlzdGljcw1Ob25lDQ1Qcm9jZWR1cmVzDUlu
ZGljYXRvcnMgY2FuIGJlIGNvLXJlbGF0ZWQgd2l0aCBwaHlzaWNhbGx5IGFzc29jaWF0ZWQgRnVu
Y3Rpb24gS2V5cyB1c2luZyBJbmRpY2F0b3IgaW5kaWQgYW5kIEZ1bmN0aW9uIEtleSBrZXlpZC4g
IElmIHRoZSBJRHMgYXJlIGlkZW50aWNhbCwgdGhlIE1HQyBhcHBsaWNhdGlvbiBjYW4gc2FmZWx5
IGFzc3VtZSB0aGF0IHRoZSBrZXkgYW5kIGluZGljYXRvciBhcmUgcGh5c2ljYWxseSAob3Igb3Ro
ZXJ3aXNlKSBhc3NvY2lhdGVkIG9uIHRoZSBhY3R1YWwgZGV2aWNlLiAgVGhpcyBhdm9pZHMgYXNz
dW1wdGlvbnMgYW5kL29yIHRoZSByZXF1aXJlbWVudCBmb3IgYXBwbGljYXRpb24gbGV2ZWwga25v
d2xlZGdlIG9mIGRldmljZS1zcGVjaWZpYyBsYXlvdXQgb2YgdGhlIHBoeXNpY2FsIHJlc291cmNl
cy4gIFNlZSBhbHNvIHRoZSBGdW5jdGlvbiBLZXlzIHBhY2thZ2UgKGtmKS4gIA1Tb2Z0IEtleSBQ
YWNrYWdlDQ1QYWNrYWdlSUQ6IGtzLCAweDAwMmINDVZlcnNpb246IDENDUV4dGVuZHM6IGxhYmVs
a2V5IHZlcnNpb24gMQ0NU29mdGtleXMgYXJlIGEgY29tYmluYXRpb24gb2YgYSBmdW5jdGlvbiBr
ZXkgYW5kIGEgZGlzcGxheSB1c2VyIGludGVyZmFjZSBlbGVtZW50LCBzaGFyaW5nIHNvbWUgYmVo
YXZpb3Igb2YgZWFjaC4gIFNvZnRrZXlzIGFyZSBpbnRlbmRlZCB0byBiZSBkeW5hbWljYWxseSB1
cGRhdGVkIGJ5IHRoZSBNR0MsIGJhc2VkIG9uIHRoZSBjdXJyZW50IHN0YXRlIGFuZCBjb250ZXh0
IG9mIHRoZSBhcHBsaWNhdGlvbiBjb250cm9sbGluZyB0aGUgTUcuICBTaW5jZSB0aGUgZGlzcGxh
eSBhc3BlY3QgYW5kIHRoZSBrZXkgYXNwZWN0IGFyZSBleHBsaWNpdGVseSBib3VuZCB0b2dldGhl
ciwgdGhpcyBhdm9pZHMgYXNzdW1wdGlvbnMgYW5kL29yIHRoZSByZXF1aXJlbWVudCBmb3IgYXBw
bGljYXRpb24gbGV2ZWwga25vd2xlZGdlIG9mIGRldmljZS1zcGVjaWZpYyBsYXlvdXQgb2YgdGhl
IHBoeXNpY2FsIHJlc291cmNlcy4gDQ1TZWUgUHJvY2VkdXJlcyBmb3IgZGV0YWlscy4gIA0NUHJv
cGVydGllcw0NTnVtYmVyIG9mIHNvZnRrZXlzDVByb3BlcnR5SUQ6IG5za2V5cyAoMHgwMDAxKQ1Q
cm9wZXJ0eVR5cGU6IEludGVnZXINQ2hhcmFjdGVyaXN0aWNzOiByZWFkIG9ubHkNRGVmaW5lZCBp
bjogVGVybWluYXRpb25TdGF0ZSANRGVzY3JpcHRpb246IE1heGltdW0gbnVtYmVyIG9mIGluZGl2
aWR1YWwgc29mdCBrZXlzLiANDURpc3BsYXkgc2l6ZQ1Qcm9wZXJ0eUlEOiBzeiAoMHgwMDAyKQ1U
eXBlOiBJbnRlZ2VyDUNoYXJhY3RlcmlzdGljczogcmVhZCBvbmx5DURlZmluZWQgaW46IFRlcm1p
bmF0aW9uU3RhdGUgDURlc2NyaXB0aW9uOiBNYXhpbXVtIG51bWJlciBvZiBjaGFyYWN0ZXJzIHRo
YXQgY2FuIGJlIGRpc3BsYXllZCBpbiBlYWNoIHNvZnRrZXkuIA0NU3VwcG9ydGVkIHVuaWNvZGUg
Y29kZSBwYWdlcw1Qcm9wZXJ0eUlEOiBjZHBncyAoMHgwMDAzKQ1EZXNjcmlwdGlvbjogYSBsaXN0
IG9mIHN1cHBvcnRlZCB1bmljb2RlIHBhZ2VzIA1UeXBlOiBsaXN0IG9mIGVudW1lcmF0ZWQgdHlw
ZQ1EZWZpbmVkIGluOiBUZXJtaW5hdGlvblN0YXRlLiANQ2hhcmFjdGVyaXN0aWNzOiByZWFkIG9u
bHkNDVNpZ25hbHMNDVNldERpc3BsYXkNDVNpZ25hbElEOiBzZCAoMHgwMDAxKQ0NRGVzY3JpcHRp
b246IFNldCBzb2Z0a2V5IGR5bmFtaWMgZGlzcGxheSBjb250ZW50LiAgDQ1QYXJhbWV0ZXJzOg0N
a2V5aWQJCQ1QYXJhbWV0ZXIgSUQ6IGsgKDB4MDAwMSkNVHlwZTogRW51bWVyYXRpb24NUG9zc2li
bGUgdmFsdWVzOiBzazEtc2s5OTkgKDB4MDAwMS0weDAzZTcpDQ1kaXNwbGF5Q29udGVudA1QYXJh
bWV0ZXIgSUQ6IGQgKDB4MDAwMikNVHlwZTogU3RyaW5nDQ1Qcm9jZWR1cmVzDVRoZSBkaXNwbGF5
IGFzcGVjdCBpcyBhIHN1YnNldCBvZiB0aGUgRGlzcGxheSAoZGlzKSBwYWNrYWdlLiAgVW5pY29k
ZSBpcyBzdXBwb3J0ZWQgdG8gcHJvdmlkZSBmb3IgbXVsdGlwbGUgbGFuZ3VhZ2VzIFt4eHhdLCBh
bmQgYWxsIFNvZnRLZXkgZWxlbWVudHMgc2hhbGwgYXQgbGVhc3Qgc3VwcG9ydCB0aGUgVW5pY29k
ZSBwYWdlcyBVKzAwMDAgLT4gVSswMGZmIGFzIHRoZSBiYXNpYyBjaGFyYWN0ZXIgc2V0LiAgQWxs
IHRleHQgc3RyaW5ncyBzaGFsbCBiZSBlbmNvZGVkIHVzaW5nIFVURi04LiAgSWYgYSBzdHJpbmcg
Y2Fubm90IGZpdCBpbnRvIHRoZSBkaXNwbGF5IGFyZWEsIGl0IHdpbGwgYmUgdHJ1bmNhdGVkIHdp
dGhvdXQgd2FybmluZy4gIA1UaGUga2V5IGFzcGVjdCwgaW5jbHVkaW5nIEV2ZW50cyBhbmQgbGFi
ZWxpbmcsIGRlcml2ZXMgZGlyZWN0bHkgZnJvbSBMYWJlbCBLZXkgYW5kIEtleSBwYWNrYWdlcy4g
U29mdGtleSBpZGVudGlmaWVycyAoa2V5aWQpIGFyZSBpbmRleGVkIDEsMi4uLk4uICBOIChuc2tl
eXMpIGlzIHRoZSBtYXhpbXVtIG51bWJlciBvZiBzb2Z0a2V5cyBzdXBwb3J0ZWQgYnkgdGhlIE1H
IGltcGxlbWVudGF0aW9uLiAgUmVmZXIgdG8gdGhlIExhYmVsIEtleSAobGFiZWxrZXkpIGFuZCBL
ZXkgKGtleSkgcGFja2FnZXMgZm9yIGZ1cnRoZXIgZGV0YWlscy4gIA0NQW5jaWxsYXJ5IElucHV0
IFBhY2thZ2UNUGFja2FnZUlEOiBhbmNpLCAweDAwMmMNVmVyc2lvbjogMQ1FeHRlbmRzOiBub25l
DVRoZSBhbmNpbGxhcnkgaW5wdXQgcGFja2FnZSBpcyB1c2VkIHRvIGVudGVyIHVzZXIgYWxwaGFu
dW1lcmljIGluZm9ybWF0aW9uIHN1Y2ggYXMgdGV4dCBpbnB1dCBvciBzY2FuIGRhdGEsIHdoaWNo
IGlzIGZvcndhcmRlZCB0byB0aGUgTUdDIGZvciBwcm9jZXNzaW5nLiAgVGhlIGluZm9ybWF0aW9u
IGlzIHByZXNlbnRlZCBhcyBhIFVuaWNvZGUgY2hhcmFjdGVyIGVuY29kZWQgaW4gVVRGLTggZm9y
bWF0IFt4eHhdLg1Qcm9wZXJ0aWVzDU5vbmUuICANRXZlbnRzDUNoYXJhY3RlciBpbnB1dA1FdmVu
dElEOiBjaCAoMHgwMDAxKQ1EZXNjcmlwdGlvbjogQSBjaGFyYWN0ZXIgaGFzIGJlZW4gaW5wdXQu
DUV2ZW50RGVzY3JpcHRvciBwYXJhbWV0ZXJzDU5vbmUNT2JzZXJ2ZWRFdmVudERlc2NyaXB0b3Ig
cGFyYW1ldGVyczoNaWQgKDB4MDAwMSkNVHlwZTogQ2hhcmFjdGVyIChVVEYtOCBjaGFyYWN0ZXIp
DQ1TaWduYWxzDU5vbmUuICANDVN0YXRpc3RpY3MNTm9uZS4gIA0NUHJvY2VkdXJlcw1Ob25lLiAg
DQ0NUmVmZXJlbmNlcw0NDQ1fX19fX19fX19fX19fX19fX19fXw1fX19fX19fX19fX19fX19fX19f
Xw0NLSATIFBBR0UgFDIVIC0NDRMgRklMRU5BTUUgXHAgXCogTUVSR0VGT1JNQVQgFEM6XFdJTkRP
V1NcREVTS1RPUFxTRzE2XFVJIHBhY2thZ2UgVEQuZG9jFQkTIHNhdmVkYXRlIFxAIGRkLk1NLnl5
IBQxNS4wMi4wMBUNDSBDb250YWN0OiAHUGV0ZXIgQmxhdGhlcndpY2sNTm9ydGVsIE5ldHdvcmtz
B1RlbDogKDYxMyk3NjMgNzUzOQkNRmF4OgkNRS1tYWlsOiBibGF0aGVyQG5vcnRlbG5ldHdvcmtz
LmNvbQcHBwcHBw0TIEZJTEVOQU1FIFxwIFwqIE1FUkdFRk9STUFUIBRDOlxXSU5ET1dTXERFU0tU
T1BcU0cxNlxVSSBwYWNrYWdlIFRELmRvYxUJEyBzYXZlZGF0ZSBcQCBkZC5NTS55eSAUMTUuMDIu
MDAVCQ0NDQ0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAuBAAALwQAADAEAAA5BAAAOgQAAEIEAABKBAAA
SwQAAFcEAABZBAAA3SwAAOgsAABJOQAAXzkAAHY5AAB4OQAAeTkAAH85AACAOQAAgTkAAII5AACE
OQAAhTkAAIY5AACHOQAAozkAAKQ5AADNOQAAzjkAAM85AADQOQAA5jkAAOc5AADvOQAA8DkAAPI5
AADzOQAA/DkAAFw6AABdOgAAYDoAAGE6AABiOgAAYzoAAH86AACAOgAAqToAAKo6AACrOgAArDoA
AMI6AADDOgAAyzoAAMw6AADROgAA/QD5/fn9+f0A+QD9AP0A9uvk69vr5PYA1gDW09YA1gDW09YA
0MzQANAAydYA1tPWANYA1tPWAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARDShAAAAc1CIFDShIABENKEgAABG1IAAQACQNq
AAAAAFUIARAwSkMAQ0oYAE9KAABtSAAEAAwwSkMAQ0oYAE9KAAAAFQNqAAAAADBKQwBDShgAT0oA
AFUIAQRDShgAAAc1CIFDSiAAAzUIgQA3AAQAAEsEAABaBAAAWwQAAHYEAAB3BAAAigQAAIsEAACf
BAAAoAQAAPUEAAAIBQAACQUAABYFAABGBgAAWAYAAGgGAAB/BgAAigYAAJgGAACZBgAAJwcAAPgA
AAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAAAOAAAAAAAAAAAAAAAADbAAAAAAAA
AAAAAAAA1AAAAAAAAAAAAAAAANsAAAAAAAAAAAAAAADSAAAAAAAAAAAAAAAA0gAAAAAAAAAAAAAA
ANIAAAAAAAAAAAAAAADIAAAAAAAAAAAAAAAAvgAAAAAAAAAAAAAAALwAAAAAAAAAAAAAAAC6AAAA
AAAAAAAAAAAAvAAAAAAAAAAAAAAAALwAAAAAAAAAAAAAAAC2AAAAAAAAAAAAAAAAtgAAAAAAAAAA
AAAAALYAAAAAAAAAAAAAAAC2AAAAAAAAAAAAAAAAtgAAAAAAAAAAAAAAAAAAAAADUAATpHgAAAEA
AAABAQAKAAATpAAADcYKBBoDpwQ0BsEHAAAJAAADJAENxgoEGgOnBDQGwQcAAAFAAAAGOgANxgcB
BxoBigVABToADcYEAQcaAAc6ABOkyAANxgQBBxoACjoADoTTGSZkBgEAAQ3GBAEHGgAHOgATpOMA
DcYEAQcaAAAGOgANxgcBBxoBpyXCABUABAAASwQAAFoEAABbBAAAdgQAAHcEAACKBAAAiwQAAJ8E
AACgBAAA9QQAAAgFAAAJBQAAFgUAAEYGAABYBgAAaAYAAH8GAACKBgAAmAYAAJkGAAAnBwAAKAcA
ADMHAABCBwAAXQcAAJEHAACfBwAAvgcAANoHAADbBwAA7QcAAAgIAAA/CAAATQgAAGwIAACICAAA
iQgAAKYIAADBCAAA8QgAAA8JAAAuCQAA/f39/f39/fv7+wAA+PX4+PDr5uHc19HMx8K9uLOuqaSf
mpWQi4aBfHdyAAAAAAAAAAAAAAAAAAAIAlAABhn+//8ACAJQAAY3/v//AAgCUAAGZ/7//wAIAlAA
BoL+//8ACAJQAAaf/v//AAgCUAAGoP7//wAIAlAABrz+//8ACAJQAAbb/v//AAgCUAAG6f7//wAI
AlAABiD///8ACAJQAAY7////AAgCUAAGTf///wAIAlAABk7///8ACAJQAAZq////AAgCUAAGif//
/wAIAlAABpf///8ACAJQAAbL////AAgCUAAG5v///wAIAlAABvX///8ACgICAAUBBjD///8ACAJQ
AAYx////AAgCUAAGv////wAIAlAABsD///8ACAJQAAbO////AAgCUAAG2f///wAIAlAABvD///8A
BQbz////BQIBAAUAAwJAAAMCOgAAKicHAAAoBwAAMwcAAEIHAABdBwAAkQcAAJ8HAAC+BwAA2gcA
ANsHAADtBwAACAgAAD8IAABNCAAAbAgAAIgIAACJCAAApggAAMEIAADxCAAADwkAAC4JAABKCQAA
7gkAADcKAAA4CgAATAoAAGQKAAByCgAA+wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD7AAAAAAAA
AAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAA
APEAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAA
AAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA+wAAAAAAAAAA
AAAAAPsAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADx
AAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA+wAAAAAA
AAAAAAAAAPsAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAAAAAAVQAA+E0AIT
pHgAAAMCABOkeAAAA1AAE6R4AAAcLgkAAEoJAADuCQAANwoAADgKAABMCgAAZAoAAHIKAACRCgAA
sgoAALMKAADKCgAA4goAAPAKAAAPCwAAMAsAADELAACqCwAAqwsAALILAAC3CwAAuAsAAMALAADI
CwAAyQsAAN8LAAD8CwAACAwAAAwMAAAkDAAAMgwAAH0MAAB+DAAAhQwAAPv28ezn4t3Y087JxL+6
tbCrpqCblpCLhoF8d3JtaGNeWQAAAAAAAAAAAAgCUAAGOv///wAIAlAABjv///8ACAJQAAaG////
AAgCUAAGlP///wAIAlAABqz///8ACAJQAAaw////AAgCUAAGvP///wAIAlAABtn///8ACAJQAAbv
////AAgCUAAG8P///wAIAlAABvj///8ACgICAAUBBqD6//8ACAJQAAb0////AAgCUAAG+f///wAK
AgIABQEGrfr//wAIAlAABn77//8ACAJQAAb3+///AAgCUAAG+Pv//wAIAlAABhn8//8ACAJQAAY4
/P//AAgCUAAGRvz//wAIAlAABl78//8ACAJQAAZ1/P//AAgCUAAGdvz//wAIAlAABpf8//8ACAJQ
AAa2/P//AAgCUAAGxPz//wAIAlAABtz8//8ACAJQAAbw/P//AAgCUAAG8fz//wAIAlAABjr9//8A
CAJQAAbe/f//AAgCUAAG+v3//yFyCgAAkQoAALIKAACzCgAAygoAAOIKAADwCgAADwsAADALAAAx
CwAAqgsAAKsLAACyCwAAtwsAALgLAADACwAAyAsAAMkLAADfCwAA/AsAAAgMAAAMDAAAJAwAADIM
AAB9DAAAfgwAAIUMAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAA
AAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAA
AAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAAD1
AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAA
AAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAOsAAAAAAAAAAAAA
AADlAAAAAAAAAAAAAAAA5QAAAAAAAAAAAAAAAOUAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA6wAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFUAAPhHAIE6R4AAAFUAAPhKAFE6R4AAADAgATpHgAAANQ
ABOkeAAABVAAD4TQAhOkeAAAGoUMAACdDAAAqwwAAPkMAAD6DAAAAQ0AABoNAAAnDQAAWg0AAFsN
AABlDQAAfQ0AAKQNAADmDQAA/A0AABEOAAASDgAAIA4AADYOAAA3DgAARA4AALIOAACzDgAAwA4A
AMUOAADGDgAA0Q4AANYOAADXDgAA4g4AAJEQAADyEQAAnRIAAD0TAADvFAAA+/bx7Ofi3djTzsnE
v7q1sKumoZyXko2Ig314c214aGNeWQAAAAAIAlAABpr7//8ACAJQAAY6/P//AAgCUAAG5fz//wAI
AlAABkb+//8ACgICAAUBBoH3//8ACAJQAAbw////AAgCUAAG9f///wAKAgIABQEGkvf//wAIAlAA
BvP8//8ACAJQAAb4/P//AAgCUAAGBf3//wAIAlAABgb9//8ACAJQAAZ0/f//AAgCUAAGgf3//wAI
AlAABoL9//8ACAJQAAaY/f//AAgCUAAGpv3//wAIAlAABqf9//8ACAJQAAa8/f//AAgCUAAG0v3/
/wAIAlAABhT+//8ACAJQAAY7/v//AAgCUAAGU/7//wAIAlAABl3+//8ACAJQAAZe/v//AAgCUAAG
kf7//wAIAlAABp7+//8ACAJQAAa3/v//AAgCUAAGvv7//wAIAlAABr/+//8ACAJQAAYN////AAgC
UAAGG////wAIAlAABjP///8ihQwAAJ0MAACrDAAA+QwAAPoMAAABDQAAGg0AACcNAABaDQAAWw0A
AGUNAAB9DQAApA0AAOYNAAD8DQAAEQ4AABIOAAAgDgAANg4AADcOAABEDgAAsg4AALMOAADADgAA
xQ4AAMYOAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAADzAAAAAAAAAAAA
AAAA8wAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPMA
AAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAA
AAAAAAAA6wAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAADnAAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAA
AOEAAAAAAAAAAAAAAADhAAAAAAAAAAAAAAAA4QAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADhAAAA
AAAAAAAAAAAA4QAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADnAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAVQAA+E0AITpHgAAANQABOkeAAAB1AAD4RACxGE0AITpHgAAAVQAA+EoAUT
pHgAAAVQAA+EcAgTpHgAABnGDgAA0Q4AANYOAADXDgAA4g4AAJEQAADyEQAAnRIAAD0TAADvFAAA
+xQAABIVAAAdFQAAKxUAAPMVAAA2FgAANxYAAEIWAABJFgAAShYAAFEWAABZFgAAWhYAAG8WAACK
FgAAphYAAK0WAAD7AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD7AAAAAAAA
AAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAA
APcAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAA
AAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA+wAAAAAAAAAA
AAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3
AAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA5wAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABVAAD4SgBROkeAAABVAAD4TQAhOkeAAAAwEAE6R4AAAD
UAATpHgAAAMCABOkeAAAGu8UAAD7FAAAEhUAAB0VAAArFQAA8xUAADYWAAA3FgAAQhYAAEkWAABK
FgAAURYAAFkWAABaFgAAbxYAAIoWAACmFgAArRYAANEWAADgFgAA8hYAAGYXAABsFwAAgRcAAJMX
AACvFwAAthcAALcXAADbFwAA6hcAAPwXAAB/GAAAgBgAAJIYAAD89/Lt6OPe2NPOyMO+ubSvqqWg
m5aRjIeCfXhzbmlkX1oAAAAAAAAAAAAAAAgCUAAGyv3//wAIAlAABsv9//8ACAJQAAZO/v//AAgC
UAAGYP7//wAIAlAABm/+//8ACAJQAAaT/v//AAgCUAAGlP7//wAIAlAABpv+//8ACAJQAAa3/v//
AAgCUAAGyf7//wAIAlAABt7+//8ACAJQAAbk/v//AAgCUAAGWP///wAIAlAABmr///8ACAJQAAZ5
////AAgCUAAGnf///wAIAlAABqT///8ACAJQAAbA////AAgCUAAG2////wAIAlAABvD///8ACAJQ
AAbx////AAgCUAAG+f///wAKAgIABQEGpf7//wAIAlAABu7///8ACAJQAAb1////AAoCAgAFAQa4
/v//AAgCUAAGuf7//wAIAlAABvz+//8ACAJQAAbE////AAgCUAAG0v///wAIAlAABt3///8ACAJQ
AAb0////AAUCAQAFAAAhrRYAANEWAADgFgAA8hYAAGYXAABsFwAAgRcAAJMXAACvFwAAthcAALcX
AADbFwAA6hcAAPwXAAB/GAAAgBgAAJIYAAChGAAAtBgAAOsYAADsGAAA9BgAAPkYAAD6GAAABRkA
AAoZAAALGQAA+QAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA7QAAAAAAAAAA
AAAAAOkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAADz
AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA7QAAAAAA
AAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAO0AAAAAAAAAAAAA
AADtAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADlAAAAAAAAAAAAAAAA6QAA
AAAAAAAAAAAAAOkAAAAAAAAAAAAAAADlAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAwIAE6R4AAADUAATpHgAAAVQAA+EcAgTpHgAAAVQAA+EoAUTpHgA
AAVQAA+E0AITpHgAABqSGAAAoRgAALQYAADrGAAA7BgAAPQYAAD5GAAA+hgAAAUZAAAKGQAACxkA
ABYZAAAbGQAAHBkAACsZAABBGQAATBkAAGMZAAALGgAADBoAACUaAAAmGgAAOxoAADwaAABaGgAA
eBoAAJYaAAC0GgAA0hoAAPAaAAAOGwAALBsAAEobAABoGwAAhhsAAKQbAAD79vHs5uHc1tHMxtHM
w765tK+qpaCblpGMh4J9eHNuaWRf8QAAAAAAAAAAAAAACAJQAAa0/f//AAgCUAAG0v3//wAIAlAA
BvD9//8ACAJQAAYO/v//AAgCUAAGLP7//wAIAlAABkr+//8ACAJQAAZo/v//AAgCUAAGhv7//wAI
AlAABqT+//8ACAJQAAbC/v//AAgCUAAG4P7//wAIAlAABuH+//8ACAJQAAb2/v//AAgCUAAG9/7/
/wAIAlAABhD///8ACAJQAAYR////AAgCUAAGuf///wAIAlAABtD///8ACAJQAAbb////AAgCUAAG
8f///wAFAgEABQAKAgIABQEG5Pv//wAIAlAABvD///8ACAJQAAb1////AAoCAgAFAQb1+///AAgC
UAAG8////wAIAlAABvj///8ACgICAAUBBgP8//8ACAJQAAZf/f//AAgCUAAGlv3//wAIAlAABqn9
//8ACAJQAAa4/f//IwsZAAAWGQAAGxkAABwZAAArGQAAQRkAAEwZAABjGQAACxoAAAwaAAAlGgAA
JhoAADsaAAA8GgAAWhoAAHgaAACWGgAAtBoAANIaAADwGgAADhsAACwbAABKGwAAaBsAAIYbAACk
GwAAwhsAAOAbAAD+GwAA+wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA8wAA
AAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAA
AAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA
8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAA
AAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAA
AAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEA
AAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAAAAAAFQAAADAQATpHgAAANQABOk
eAAAAwIAE6R4AAAcpBsAAMIbAADgGwAA/hsAABwcAAAdHAAANRwAAD0cAAA+HAAAUBwAAGwcAAB3
HAAAjhwAAHgeAAD2HgAAOR8AADofAABFHwAATR8AAHcfAACbHwAAnB8AAKofAAB+IAAAfyAAAIcg
AACNIAAAjiAAAJkgAAChIAAAoiAAALcgAADNIAAA2CAAAPQgAADFIQAA+/bx7Ofh3NfUz8rFwLu2
saumoZyXko2Ign14cqah1G1oY14AAAAAAAAAAAAIAlAABq7///8ACAJQAAbK////AAgCUAAG1f//
/wAIAlAABuv///8ACgICAAUBBrD7//8ACAJQAAby////AAgCUAAG+P///wAKAgIABQEGv/v//wAI
AlAABrz+//8ACAJQAAaQ////AAgCUAAGnv///wAIAlAABp////8ACAJQAAbD////AAgCUAAG7f//
/wAIAlAABvX///8ACgICAAUBBgT9//8ACAJQAAYF/f//AAgCUAAGSP3//wAIAlAABsb9//8ACAJQ
AAaw////AAgCUAAGx////wAIAlAABtL///8ACAJQAAbu////AAUCAQAFAAgCUAAG4P///wAIAlAA
Buj///8ACgICAAUBBv/8//8ACAJQAAYA/f//AAgCUAAGHv3//wAIAlAABjz9//8ACAJQAAZa/f//
AAgCUAAGeP3//yP+GwAAHBwAAB0cAAA1HAAAPRwAAD4cAABQHAAAbBwAAHccAACOHAAAeB4AAPYe
AAA5HwAAOh8AAEUfAABNHwAAdx8AAJsfAACcHwAAqh8AAH4gAAB/IAAAhyAAAI0gAACOIAAAmSAA
AKEgAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA
9wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAA
AAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD9AAAAAAAAAAAA
AAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A
AAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAADnAAAAAAAA
AAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAADnAAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAwIAE6R4AAADUAAPhKAFAANQAA+E0AIAAwEAE6R4AAADUAATpHgA
AAECAAABUAAAGqEgAACiIAAAtyAAAM0gAADYIAAA9CAAAMUhAAAPIgAAECIAACUiAAAmIgAAQCIA
AFUiAABvIgAAhyIAALgiAAD1IgAA9iIAAAEjAADIJAAAiiYAAP0nAAD+JwAAECgAACcoAAAyKAAA
QCgAAN0pAAAxKgAA+wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAA
AAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPUAAAAAAAAAAAAA
AAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAA
AAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAA
AAAAAADzAAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA
+wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAA
AAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAAAAAAAAAAABAgAAAVAAAAMBABOkeAAA
A1AAE6R4AAAcxSEAAA8iAAAQIgAAJSIAACYiAABAIgAAVSIAAG8iAACHIgAAuCIAAPUiAAD2IgAA
ASMAAMgkAACKJgAA/ScAAP4nAAAQKAAAJygAADIoAABAKAAA3SkAADEqAAA8KgAASioAAHQqAACY
KgAAmSoAAKAqAAClKgAApioAAK4qAAC6KgAAuyoAANEqAAD79vHs5+Ld2NPOycO+ubSvrKeinZiT
jb6Ig354c25oY15ZAAAAAAgCUAAG6////wAIAlAABuz///8ACAJQAAb4////AAoCAgAFAQZY/f//
AAgCUAAG9P///wAIAlAABvn///8ACgICAAUBBmX9//8ACAJQAAaZ////AAgCUAAGvf///wAIAlAA
Buf///8ACgICAAUBBs39//8ACAJQAAYh/v//AAgCUAAGvv///wAIAlAABsz///8ACAJQAAbX////
AAgCUAAG7v///wAFAgEABQAIAlAABvn6//8ACAJQAAZs/P//AAgCUAAGLv7//wAIAlAABvX///8A
CgICAAUBBqz9//8ACAJQAAat/f//AAgCUAAG6v3//wAIAlAABhv+//8ACAJQAAYz/v//AAgCUAAG
Tf7//wAIAlAABmL+//8ACAJQAAZ8/v//AAgCUAAGff7//wAIAlAABpL+//8ACAJQAAaT/v//AAgC
UAAG3f7//yIxKgAAPCoAAEoqAAB0KgAAmCoAAJkqAACgKgAApSoAAKYqAACuKgAAuioAALsqAADR
KgAA5yoAAPMqAAD0KgAABCsAABcrAAApKwAAKisAAEArAABBKwAAVSsAAG8rAACkKwAA5SsAAA8s
AAD7AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAA
AAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPsAAAAAAAAA
AAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA
8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA5QAAAAAAAAAAAAAAAOEAAAAA
AAAAAAAAAADhAAAAAAAAAAAAAAAA4QAAAAAAAAAAAAAAAOEAAAAAAAAAAAAAAADhAAAAAAAAAAAA
AAAA4QAAAAAAAAAAAAAAAOEAAAAAAAAAAAAAAADhAAAAAAAAAAAAAAAA4QAAAAAAAAAAAAAAAAAA
AAAAA1AAD4SgBQAFUAAPhKAFEYTQAgAFUAAPhKAFE6R4AAAFUAAPhNACE6R4AAADUAATpHgAAAMC
ABOkeAAAGtEqAADnKgAA8yoAAPQqAAAEKwAAFysAACkrAAAqKwAAQCsAAEErAABVKwAAbysAAKQr
AADlKwAADywAADksAAA6LAAASiwAAF4sAACbLAAAyCwAAN0sAADoLAAA7SwAAO4sAAD5LAAAuS4A
AMouAADLLgAA4S4AAOIuAADtLgAA7i4AAAovAAALLwAA+/bx7Ofi3djTzsnEv7q1sKumoZyXko2I
gn16dXBrZmFcVwgCUAAGr////wAIAlAABsv///8ACAJQAAbM////AAgCUAAG1////wAIAlAABtj/
//8ACAJQAAbu////AAgCUAAG7////wAFAgEABQAIAlAABvX///8ACgICAAUBBhD7//8ACAJQAAa5
/f//AAgCUAAGvv3//wAIAlAABsn9//8ACAJQAAbe/f//AAgCUAAGC/7//wAIAlAABkj+//8ACAJQ
AAZc/v//AAgCUAAGbP7//wAIAlAABm3+//8ACAJQAAaX/v//AAgCUAAGwf7//wAIAlAABgL///8A
CAJQAAY3////AAgCUAAGUf///wAIAlAABmX///8ACAJQAAZm////AAgCUAAGfP///wAIAlAABn3/
//8ACAJQAAaP////AAgCUAAGov///wAIAlAABrL///8ACAJQAAaz////AAgCUAAGv////wAIAlAA
BtX///8iDywAADksAAA6LAAASiwAAF4sAACbLAAAyCwAAN0sAADoLAAA7SwAAO4sAAD5LAAAuS4A
AMouAADLLgAA4S4AAOIuAADtLgAA7i4AAAovAAALLwAA2jAAANswAAD5MAAA+jAAAAUxAAAGMQAA
+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPsAAAAA
AAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAA
AAAA7wAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOcA
AAAAAAAAAAAAAADnAAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAADnAAAAAAAA
AAAAAAAA5wAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAADnAAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAA
AOcAAAAAAAAAAAAAAADnAAAAAAAAAAAAAAAA4wAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAAAAAAAA
AAAAAAADAgATpHgAAANQABOkeAAAAQEAAAECAAABUAAAA1AAD4QQDgAFUAAPhKAFEYTQAgADUAAP
hKAFABoLLwAA2jAAANswAAD5MAAA+jAAAAUxAAAGMQAAGTEAADUxAABLMQAAZjEAAIQxAAC6MQAA
uzEAAMgxAADgMQAA7jEAAAkyAAAnMgAAeTIAAHoyAACXMgAAsjIAAOIyAAAAMwAAHzMAADozAAA7
MwAAQzMAAEQzAABPMwAAUDMAAGYzAABnMwAAmzMAAPv28ezm4dzX0s3Iw765tK+qpaCblpGMh4J9
7HdybWhjXlkAAAAACAJQAAbU////AAgCUAAG1f///wAIAlAABuv///8ACAJQAAbs////AAgCUAAG
9////wAIAlAABvj///8ACgICAAUBBn77//8ACAJQAAbb/f//AAgCUAAG+v3//wAIAlAABhj+//8A
CAJQAAZI/v//AAgCUAAGY/7//wAIAlAABoD+//8ACAJQAAaB/v//AAgCUAAG0/7//wAIAlAABvH+
//8ACAJQAAYM////AAgCUAAGGv///wAIAlAABjL///8ACAJQAAY/////AAgCUAAGQP///wAIAlAA
Bnb///8ACAJQAAaU////AAgCUAAGr////wAIAlAABsX///8ACAJQAAbh////AAgCUAAG9P///wAI
AlAABvX///8ACgICAAUBBr/9//8ACAJQAAbA/f//AAgCUAAG3v3//wAIAlAABt/9//8ACAJQAAau
////IgYxAAAZMQAANTEAAEsxAABmMQAAhDEAALoxAAC7MQAAyDEAAOAxAADuMQAACTIAACcyAAB5
MgAAejIAAJcyAACyMgAA4jIAAAAzAAAfMwAAOjMAADszAABDMwAARDMAAE8zAABQMwAAZjMAAGcz
AACbMwAA+wAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAA
APUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD1AAAA
AAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAA
AAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1
AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA8QAAAAAA
AAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPUAAAAAAAAAAAAA
AAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAAAAAAMCABOkeAAABVAAD4TQAhOkeAAAA1AAE6R4
AAAcmzMAAJwzAACoMwAAqTMAALEzAADKMwAA3DMAAAc0AAAINAAAFzQAADA0AAA9NAAAPjQAAEk0
AAC7NQAA8DYAAPE2AAAJNwAAITcAACw3AAA6NwAAKDgAADM4AAA7OAAAQjgAAFI4AABnOAAAkDgA
AKs4AACwOAAA1DgAAOA4AAACOQAAAzkAAAs5AAD79vHs5+Ld2NPOycS+ubSvrKeinZiSuYyHgn14
c25pZF9ZAAAAAAoCAgAFAQbu/f//AAgCUQAGOf///wAIAlAABlv///8ACAJQAAZn////AAgCUAAG
i////wAIAlAABpD///8ACAJQAAar////AAgCUAAG1P///wAIAlAABun///8ACAJQAAb5////AAoC
AgAFAQa2/v//AAoCAgAFAQbJ/v//AAgCUAAGt////wAIAlAABsX///8ACAJQAAbQ////AAgCUAAG
6P///wAFAgEABQAIAlAABk79//8ACAJQAAaD/v//AAgCUAAG9f///wAKAgIABQEGe/r//wAIAlAA
Bv7+//8ACAJQAAYL////AAgCUAAGJP///wAIAlAABjP///8ACAJQAAY0////AAgCUAAGX////wAI
AlAABnH///8ACAJQAAaK////AAgCUAAGkv///wAIAlAABpP///8ACAJQAAaf////AAgCUAAGoP//
/yKbMwAAnDMAAKgzAACpMwAAsTMAAMozAADcMwAABzQAAAg0AAAXNAAAMDQAAD00AAA+NAAASTQA
ALs1AADwNgAA8TYAAAk3AAAhNwAALDcAADo3AAAoOAAAMzgAADs4AABCOAAAUjgAAGc4AAD5AAAA
AAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA7QAAAAAAAAAA
AAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADt
AAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA5QAAAAAA
AAAAAAAAAOUAAAAAAAAAAAAAAADlAAAAAAAAAAAAAAAA4QAAAAAAAAAAAAAAAOUAAAAAAAAAAAAA
AADlAAAAAAAAAAAAAAAA5QAAAAAAAAAAAAAAAOUAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA5QAA
AAAAAAAAAAAAAOkAAAAAAAAAAAAAAADlAAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAAAAAAAAAwEA
E6R4AAADUAATpHgAAAMCABOkeAAABVAAD4RwCBOkeAAABVAAD4SgBROkeAAABVAAD4TQAhOkeAAA
Gmc4AACQOAAAqzgAALA4AADUOAAA4DgAAAI5AAADOQAACzkAABM5AAAUOQAAHzkAACc5AAAoOQAA
MzkAADs5AAA8OQAAPTkAAEg5AABJOQAASjkAAEs5AABgOQAAdTkAAPkAAAAAAAAAAAAAAAD5AAAA
AAAAAAAAAAAA8wAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA7QAAAAAAAAAA
AAAAAOkAAAAAAAAAAAAAAADlAAAAAAAAAAAAAAAA4QAAAAAAAAAAAAAAAOEAAAAAAAAAAAAAAADl
AAAAAAAAAAAAAAAA4QAAAAAAAAAAAAAAAOEAAAAAAAAAAAAAAADlAAAAAAAAAAAAAAAA4QAAAAAA
AAAAAAAAAOEAAAAAAAAAAAAAAADhAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAANsAAAAAAAAAAAAA
AADRAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAAMcAAAAAAAAAAAAAAADbAAAAAAAAAAAAAAAAAAAA
CgAAE6QAAA3GCgQaA6cENAbBBwAACQAAAyQBDcYKBBoDpwQ0BsEHAAABAAAAAwEAE6R4AAADUAAT
pHgAAAMCABOkeAAAA1EAE6R4AAAFUAAPhHAIE6R4AAAFUAAPhKAFE6R4AAAFUAAPhNACE6R4AAAX
CzkAABM5AAAUOQAAHzkAACc5AAAoOQAAMzkAADs5AAA8OQAAPTkAAEg5AABJOQAASjkAAEs5AABg
OQAAdTkAAHY5AACAOQAAgTkAAIU5AACGOQAApDkAAL45AADNOQAA5zkAAOk5AADqOQAA7DkAAO05
AADvOQAA8TkAAPI5AAD9OQAADzoAAB86AAAzOgAAOToAAFw6AABdOgAAXjoAAF86AABgOgAAYToA
AGI6AADOOgAAzzoAANA6AADROgAA+/bw6+bg6+bb2NXSz8zKysrKysrKysrKysrKysrKysrGxsbG
xsPGxsbDwMDKyswAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQIgAA0BBAMBDQEABgMB
BQoNAQACAQEABQby////BQbz////BQb0////BQb1////BQIBAAUACAJQAAbs////AAoCAgAFAQbJ
/f//AAgCUAAG7f///wAIAlAABvX///8ACgICAAUBBt39//8ACAJQAAbw////AAgCUAAG+P///y91
OQAAdjkAAIU5AACGOQAA8TkAAPI5AAD9OQAADzoAAB86AAAzOgAAOToAAFw6AABdOgAAXjoAAF86
AABgOgAAYToAAGI6AADOOgAAzzoAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAA
AAAAAPMAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAAANoAAAAAAAAAAAAAAADa
AAAAAAAAAAAAAAAAzQAAAAAAAAAAAAAAAM0AAAAAAAAAAAAAAADNAAAAAAAAAAAAAAAAsRAAAAAA
AAAAAAAAAOcAAAAAAAAAAAAAAADaAAAAAAAAAAAAAAAAzQAAAAAAAAAAAAAAALEAAAAAAAAAAAAA
AACqAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYg
AA3GBwFCFwF9FAAcAAAWJAEXJAEClmwAAzQBBdYYBgEAAAAAAAAAAAAAAAAAAAAAAAAAAAAACNYK
AAOU/yoDfgmnJQ0AABOkAAAWJAENxg0EGgOnBDQGwQcBxQIADQAAE6QAABYkAQ3GDQQaA6cENAbB
BwE+HIEACwAAE6QAABYkAQ3GCgQaA6cENAbBBwAAByAADcYJAkIXpyUBjCQCAAEhAAABAAAAE886
AADQOgAA0ToAAP0AAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAABOkAAANxgoEGgOnBDQGwQcAAAEAAAACMgAK
MAEUMCoHUAUBCFAFAR+whS4gsMJBIbByBCKwcgQjkIMFJJCDBSWwAAAXsDICGLAyAgAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAFIA
CgABAFsADwACAAMAAAADAEoAAEDx/wIASgAAAAYATgBvAHIAbQBhAGwAAAAXAAAAE6R4AA3GDgAE
GgOnBDQGwQfAwMDAABQAQ0oYAE9KAABRSgAAa0jkBG1ICQhUAAFAAQACAFQAAAAJAEgAZQBhAGQA
aQBuAGcAIAAxAAAAKwABAAUkAQYkAQ+EGgMRhOb8E6TgAQ3GFAOnBDQGwQcETwhqCWkLvQzAwMDA
AAMANQiBACoAAkARAAIAKgAAAAkASABlAGEAZABpAG4AZwAgADIAAAAGAAIAE6RAAQAAKgADQBEA
AgAqAAAACQBIAGUAYQBkAGkAbgBnACAAMwAAAAYAAwATpMgAAAA4AARAMQACADgAAAAJAEgAZQBh
AGQAaQBuAGcAIAA0AAAAFAAEAA+E4QMRhB/8DcYHARoDAacEwAAAMAAFQDEAAgAwAAAACQBIAGUA
YQBkAGkAbgBnACAANQAAAAwABQANxgcBGgMBpwTAAAAwAAZAMQACADAAAAAJAEgAZQBhAGQAaQBu
AGcAIAA2AAAADAAGAA3GBwEaAwGnBMAAADAAB0AxAAIAMAAAAAkASABlAGEAZABpAG4AZwAgADcA
AAAMAAcADcYHARoDAacEwAAAMAAIQDEAAgAwAAAACQBIAGUAYQBkAGkAbgBnACAAOAAAAAwACAAN
xgcBGgMBpwTAAAAwAAlAMQACADAAAAAJAEgAZQBhAGQAaQBuAGcAIAA5AAAADAAJAA3GBwEaAwGn
BMAAADwAQUDy/6EAPAAAABYARABlAGYAYQB1AGwAdAAgAFAAYQByAGEAZwByAGEAcABoACAARgBv
AG4AdAAAAAAAAAAAAAAAAAAeABpAAQECAB4AAAAFAFQATwBDACAAOAAAAAIADwAAACIAFUARAQIA
IgAAAAUAVABPAEMAIAAzAAAABgAQABOkUAAAACIAFEAhAQIAIgAAAAUAVABPAEMAIAAyAAAABgAR
ABOkeAAAADwAE0ABACIBPAAAAAUAVABPAEMAIAAxAAAAHwASAA+EGgMRhOb8E6TIAA3GDgOnBDQG
wQcCVSKnJcjCAAAAHgAZQAEBAgAeAAAABQBUAE8AQwAgADcAAAACABMAAAAeABhAAQECAB4AAAAF
AFQATwBDACAANgAAAAIAFAAAAB4AF0ABAQIAHgAAAAUAVABPAEMAIAA1AAAAAgAVAAAAHgAWQAEB
AgAeAAAABQBUAE8AQwAgADQAAAACABYAAAAqABBAAQACACoAAAAHAEkAbgBkAGUAeAAgADcAAAAK
ABcAD4SiBhOkeAAAACoAD0ABAAIAKgAAAAcASQBuAGQAZQB4ACAANgAAAAoAGAAPhIcFE6R4AAAA
KgAOQAEAAgAqAAAABwBJAG4AZABlAHgAIAA1AAAACgAZAA+EbAQTpHgAAAA8AA1AAQACADwAAAAH
AEkAbgBkAGUAeAAgADQAAAAbABoAD4RTAxOkeAANxg4ABBoDpwQ0BsEHgICAgAAAACoADEABAAIA
KgAAAAcASQBuAGQAZQB4ACAAMwAAAAoAGwAPhDcCE6R4AAAAKgALQAEAAgAqAAAABwBJAG4AZABl
AHgAIAAyAAAACgAcAA+EHAETpHgAAAAmAApAAQACACYAAAAHAEkAbgBkAGUAeAAgADEAAAAGAB0A
E6R4AAAAJgAoQKIA4QEmAAAACwBMAGkAbgBlACAATgB1AG0AYgBlAHIAAAAAADIAIUABAAIAMgAA
AA0ASQBuAGQAZQB4ACAASABlAGEAZABpAG4AZwAAAAYAHwATpHgAAABAACBAAQACAkAAAAAGAEYA
bwBvAHQAZQByAAAAGQAgABOkAAANxhAEGgOnBDQGwQcCQhenJQACAAcAOwiBQ0oSAAA4AB9AAQAS
AjgAAAAGAEgAZQBhAGQAZQByAAAAFgAhAAMkAROkAAANxgoEGgOnBDQGwQcABABDShYAPAAmQKIA
IQI8AAAAEgBGAG8AbwB0AG4AbwB0AGUAIABSAGUAZgBlAHIAZQBuAGMAZQAAAAgAQ0oQAEVIBgBG
AB1AAQAyAkYAAAANAEYAbwBvAHQAbgBvAHQAZQAgAFQAZQB4AHQAAAAZACMABSQBD4QAARGEAP8T
pHgADcYFAAEAAcAAAAAyABxAAQBCAjIAAAANAE4AbwByAG0AYQBsACAASQBuAGQAZQBuAHQAAAAG
ACQAD4QaAwAANAD+T2ECUgI0AAAADABUAGEAYgBsAGUAXwBMAGUAZwBlAG4AZAAAAAoAJQATpHgA
FKQoAAAAagD+TwEAYgJqAAAACgBUAGEAYgBsAGUAXwBUAGUAeAB0AAAAPwAmABOkKAAUpCgADcYy
AxoDpwQ0Bg4cATcCUwNuBIoFpQbBB9wI+AkTCy8MSg1mDoEPAAAAAAAAAAAAAAAAAAAABABDShYA
OAD+T4ECYgI4AAAACwBUAGEAYgBsAGUAXwBUAGkAdABsAGUAAAAJACcABSQBE6QAAAAGADUIgTsI
gTQA/k8BAHICNAAAAAcAVABhAGIAbABlAF8AIwAAABAAKAADJAEGJAETpDACFKR4AAMAOwiBADAA
/k8BAJICMAAAAAgAZQBuAHUAbQBsAGUAdgAxAAAADgApAA+EGgMRhOb8E6RQAAAALAD+T5ECogIs
AAAACABlAG4AdQBtAGwAZQB2ADIAAAAKACoAD4SnBBGEc/4AACgA/k+hArICKAAAAAgAZQBuAHUA
bQBsAGUAdgAzAAAABgArAA+ENAYAADoA/k9hAsICOgAAAAoAVABhAGIAbABlAF8ASABlAGEAZAAA
ABAALAADJAEGJAETpFAAFKRQAAMANQiBAE4A/k8BANICTgAAAA0ARgBpAGcAdQByAGUAXwBMAGUA
ZwBlAG4AZAAAAB0ALQAFJAEGJAETpBQAFKQUAA3GCgQaA6cENAbBBwAABABDShIALAD+T4EC8gIs
AAAACABGAGkAZwB1AHIAZQBfACMAAAAKAC4AE6TgARSkeAAAADQA/k9xAgIANAAAAAwARgBpAGcA
dQByAGUAXwBUAGkAdABsAGUAAAAJAC8ABiQAFKTgAQAAADgA/k8BABIDOAAAAAcAQQBuAG4AZQB4
AF8AIwAAABMAMAADJAEFJAEGJAETpOABFKRQAAADADsIgQA0AP5PAQAiAzQAAAAJAEEAbgBuAGUA
eABfAFIAZQBmAAAADwAxAAMkAQUkAQYkAROkeAAAAABAAP5PAQAyA0AAAAALAEEAbgBuAGUAeABf
AFQAaQB0AGwAZQAAABMAMgADJAEFJAEGJAETpPAAFKQYAQADADUIgQA8AP5PAQACADwAAAASAE4A
bwByAG0AYQBsACAAYQBmAHQAZQByACAAdABpAHQAbABlAAAABgAzABOkQAEAACgA/k8BA1IDKAAA
AAoAQQBwAHAAZQBuAGQAaQB4AF8AIwAAAAIANAAAACwA/k8RA2IDLAAAAAwAQQBwAHAAZQBuAGQA
aQB4AF8AUgBlAGYAAAACADUAAAAwAP5PIQMyAzAAAAAOAEEAcABwAGUAbgBkAGkAeABfAFQAaQB0
AGwAZQAAAAIANgAAADIA/k8BAIIDMgAAAAkAUgBlAGYAXwBUAGkAdABsAGUAAAAJADcAAyQBE6Tg
AQADADsIgQAsAP5PAQCCAywAAAAIAFIAZQBmAF8AVABlAHgAdAAAAAoAOAAPhBoDEYTm/AAAOgD+
TwEAkgM6AAAACABFAHEAdQBhAHQAaQBvAG4AAAAXADkAE6R4AA3GDgOnBDQGwQcCDBMYJsHCAAAA
MAD+TwEAogMwAAAABABIAGUAYQBkAAAAFgA6ABOkAAANxg0EGgOnBDQGwQcBBxrAAAA6AP5PAQAS
ADoAAAAJAFIAZQBjAF8AVABpAHQAbABlAAAADwA7AAMkAQUkAQYkAROk8AAABgA1CIE7CIEuAP5P
AQACAC4AAAAEAGMAYQBsAGwAAAAQADwABSQBBiQBD4QaAxOkoAADADYIgQAwAP5PAQCyAzAAAAAF
AFIAZQBjAF8AIwAAAA8APQADJAEFJAEGJAETpOABAAMAOwiBADIA/k8BACIBMgAAAAUAdABvAGMA
IAAwAAAAEgA+AA3GDQQaA6cENAbBBwE1JsIDADUIgQA8AC9AAQDyAzwAAAAEAEwAaQBzAHQAAAAh
AD8AD4RPCBGEsfcTpHgADcYQBBoDpwQ0BsEHAqUGTwjAwAAAAD4A/k8BAAIEPgAAAAcASQBuAGYA
bwBkAG8AYwAAAB4AQAAPhIoFEYR2+hOkAAANxg0EGgOnBDQGwQcBigXAAABAAP5PAQASBEAAAAAE
AFAAYQByAHQAAAAhAEEAD4SlBhGEW/kTpMgADcYQBBoDpwQ0BsEHAvwEpQbAwAADADsIgQA+AP5P
AQAiBD4AAAAHAEEAZABkAHIAZQBzAHMAAAAdAEIAD4QaAxOkeAANxhAEGgOnBDQGwQcC1BKZFcDA
AAAAMgApQKIAMQQyAAAACwBQAGEAZwBlACAATgB1AG0AYgBlAHIAAAAMAE9KBABQSgQAa0ikAzoA
/k8BAEIEOgAAAAgASwBlAHkAdwBvAHIAZABzAAAAFwBEAA+EGgMRhOb8E6R4AA3GBgKnBDQGAAAA
AF4A/k8BAFIEXgAAAAUAQQBTAE4ALgAxAAAAMQBFABOkAAANxigEGgOnBDQGwQcKNwJuBKUG3AgT
C0oNgQ+4Ee8TJhbAwMDAwMDAwMDAAA8ANQiBQ0oUAG1IAARuSAAEAFIA/k8BAGIEUgAAAA8ARQBx
AHUAYQB0AGkAbwBuAF8ATABlAGcAZQBuAGQAAAAhAEYAD4SlBhGEW/kTpFAADcYQBBoDpwQ0BsEH
AvsFpQbCwAAAAD4A/k8BAHIEPgAAAAUAUQBsAGkAcwB0AAAAHQBHAA+E3AgRhCT3DcYQBBoDpwQ0
BsEHAjMH3AjAwAADADUIgQAuAP5PoQOiAy4AAAAHAG0AZQBlAHQAaQBuAGcAAAAOAEgAFKQwAg3G
BQAByxwAAAAkAP5PAQCSBCQAAAAEAE4AbwB0AGUAAAAKAEkADcYFAAGNAcAAAB4AG0ABAQIAHgAA
AAUAVABPAEMAIAA5AAAAAgBKAAAANgD+TzEAAgA2AAAACQBoAGUAYQBkAGkAbgBnAF8AYgAAABEA
SwAPhAAAEYQAABOkoABAJgkAAAA8AP5PMQACADwAAAAJAGgAZQBhAGQAaQBuAGcAXwBpAAAAEQBM
AA+EAAARhAAAE6SgAEAmCQAGADUIgTYIgUYA/k8BANIERgAMAAkAQgBvAGQAeQAgAEwAaQBzAHQA
AAAaAE0ACiYAC0YNABOkAAANxgoEGgOnBDQGwQcACABDShYAbUgdBEQAMkDxA+IERAAAAAYATABp
AHMAdAAgADIAAAAdAE4ACiYAC0YQABOkAAAUpDwADcYJAqUGTwgBCAcAAAgAQ0oWAG1IHQTaADBA
8QPyBNoAAQALAEwAaQBzAHQAIABCAHUAbABsAGUAdAAAAKoATwAKJgALRhEAD4RuBBGEV/4TpAAA
FKR4AA3GCwOlBggHTwgBbgQGRcaAAAABAFucOkYAAAAAAAAAAAAXFxcXFxcXFxcAACEAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAt/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAENKFgBtSB0EPgBaQAEAAgU+AAAA
CgBQAGwAYQBpAG4AIABUAGUAeAB0AAAAEwBQABOkAAANxgoEGgOnBDQGwQcAAAQAbUgdBEQAQkAB
ABIFRAAAAAkAQgBvAGQAeQAgAFQAZQB4AHQAAAAXAFEAE6QAABSkeAANxgoEGgOnBDQGwQcAAAgA
Q0oWAG1IHQQAAAAA0TYAABYAAHYAABUA/////wEAAAACCAAAAAAAAAAAAAAAANE2AAAAAAAAAAAA
AAAAFgAAABYAAAAWAAAAFgAAABYAAAAWAAAAFgAAACYAAAAmAAAAkgAAAJIAAABvAQAAcgEAAAAE
AADROgAAHwAAAAAEAAAnBwAAcgoAAIUMAADGDgAArRYAAAsZAAD+GwAAoSAAADEqAAAPLAAABjEA
AJszAABnOAAAdTkAAM86AADROgAAIAAAACIAAAAkAAAAJgAAACcAAAApAAAAKwAAAC0AAAAuAAAA
MAAAADIAAAA0AAAANgAAADcAAAA5AAAAOgAAAAAEAAAuCQAAhQwAAO8UAACSGAAApBsAAMUhAADR
KgAACy8AAJszAAALOQAA0ToAACEAAAAjAAAAJQAAACgAAAAqAAAALAAAAC8AAAAxAAAAMwAAADUA
AAA4AAAAGAAAAB8AAAAhAAAAJgAAAEMAAABtAAAAbwAAAIYAAACPAAAAAgEAAB8BAABJAQAASwEA
AGIBAABrAQAAcgEAABMhFP+VgBMdFP+VgBMWFP+VgBMdFP+VgBMWFP+VgP//CAAAAA0AXwBUAG8A
YwA0ADcAMgAzADUANgAzADkAMAANAF8AVABvAGMANAA3ADIAMwA1ADYAMwA5ADEADQBfAFQAbwBj
ADQANwAyADMANQA2ADMAOQAyAA0AXwBUAG8AYwA0ADcAMgAzADUANgAzADkAMwANAF8AVABvAGMA
NAA3ADIAMwA1ADYAMwA5ADQADQBfAFQAbwBjADQANwAyADMANQA2ADMAOQA1AA0AXwBUAG8AYwA0
ADcAMgAzADUANgAzADkANgANAF8AVABvAGMANAA3ADIAMwA1ADYANAAwADEAVwIAAO8QAAAcFQAA
PhgAAKIcAAD+IwAAuSoAAD01AADSNgAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAABn
AgAA+hAAACoVAABPGAAAthwAAA8kAADJKgAARzUAANI2AAAAAAAAGAAAACcAAACUAAAAngAAAK0B
AAC0AQAAaAIAAHECAAByAgAAmAIAAJkCAAC8AgAAvQIAACcDAAAzAwAAvAMAAL4DAADaAwAA2wMA
AIgEAACJBAAAvAUAAL0FAAA3BgAAOAYAALIGAACzBgAAMAcAADEHAACqBwAAsgcAALcHAADABwAA
yAcAAMkHAADWBwAA1wcAAN0HAADfBwAAfQgAAH4IAAD5CAAA+ggAAFoJAABbCQAAugkAALwJAADD
CQAAxQkAAMoJAADMCQAA0wkAANUJAADbCQAA3QkAAOQJAADpCQAAEQoAABIKAAA2CgAANwoAALIK
AACzCgAAxQoAANEKAADWCgAA4goAAOMMAADkDAAA4w4AAOQOAADvEAAA+xAAADYSAABCEgAASRIA
AFESAABZEgAAWhIAALYTAAC3EwAAfxQAAIAUAADrFAAA9BQAAPkUAAAFFQAAChUAABYVAAAbFQAA
KxUAAAsWAAAMFgAAJRYAACcWAAA7FgAAPRYAAD8WAABBFgAARxYAAEsWAABaFgAAWxYAAF4WAABf
FgAAZRYAAGkWAAB4FgAAeRYAAHwWAAB9FgAAgxYAAIcWAACWFgAAlxYAAJoWAACbFgAAoRYAAKUW
AAC0FgAAtRYAALgWAAC5FgAAvxYAAMMWAADSFgAA0xYAAN0WAADhFgAA8BYAAPEWAAD7FgAA/xYA
AA4XAAAPFwAAGRcAAB0XAAAsFwAALRcAADcXAAA7FwAAShcAAEsXAABOFwAATxcAAFUXAABZFwAA
aBcAAGkXAABsFwAAbRcAAHMXAAB3FwAAhhcAAIcXAACKFwAAixcAAJEXAACVFwAApBcAAKUXAACo
FwAAqRcAAK8XAACzFwAAwhcAAMMXAADGFwAAxxcAAM0XAADRFwAA4BcAAOEXAADkFwAA5RcAAOsX
AADvFwAA/hcAAP8XAAACGAAAAxgAABwYAAA1GAAAPRgAAFAYAABjGAAAZRgAADkbAABFGwAATRsA
AE4bAAB3GwAAexsAAJsbAACcGwAAYxwAAGQcAAB+HAAAhxwAAI0cAACZHAAAoRwAALccAAAPHgAA
ER4AACUeAAAnHgAAKR4AACseAAAyHgAANR4AAEAeAABBHgAAQx4AAEUeAABMHgAAUB4AAFUeAABW
HgAAWB4AAFoeAABhHgAAZB4AAG8eAABwHgAAch4AAHQeAAB7HgAAfh4AAIceAACIHgAAkx4AAJUe
AACiHgAApB4AALgeAAC5HgAAxR4AAMYeAADUHgAA1R4AAPUeAAABHwAAoB8AAKEfAACgIAAAoSAA
AKAiAAChIgAA/SMAABAkAAAxJgAAPCYAAEomAABLJgAAdCYAAHgmAACYJgAAoCYAAKUmAACuJgAA
uiYAALsmAADzJgAA9CYAAPkmAAD7JgAAAicAAAQnAAAXJwAAGCcAACknAAArJwAAQCcAAEInAABV
JwAAVicAAG8nAABwJwAApCcAAKUnAADlJwAA5icAAA8oAAAQKAAAJigAACcoAAA5KAAAOigAAD8o
AABBKAAASCgAAEooAABeKAAAXygAAHIoAAB0KAAAeygAAH0oAACAKAAAgigAAIkoAACLKAAAkCgA
AJIoAACZKAAAnigAAKgoAACqKAAAsSgAALMoAAC9KAAAvygAAMYoAADLKAAA7SgAAPkoAAAgKgAA
ISoAALkqAADLKgAA4SoAAOIqAADtKgAA7ioAAAorAAALKwAA2iwAANssAAD5LAAABi0AALotAAC7
LQAAeS4AAHouAAA6LwAARC8AAE8vAABQLwAAZi8AAGcvAACbLwAAnC8AAKgvAACpLwAAwC8AAMIv
AADJLwAAyi8AAPYvAAD4LwAABTAAAAgwAAAmMAAAKDAAAC8wAAAwMAAAPTAAAEkwAADwMgAACTMA
ACg0AAAzNAAAOzQAAEI0AAACNQAACzUAABM1AAAfNQAAJzUAADM1AAA7NQAAYDUAAGA1AAB1NQAA
dTUAAHY1AAADNgAADjYAAM82AADSNgAABwAcAAcAHAAHABwABwAFAAcABQAHAAUABwAFAAcABQAH
AAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcA
BQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAF
AAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUA
BwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAH
AAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcA
BQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAF
AAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUA
BwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAH
AAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcA
BQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAF
AAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUA
BwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAH
AAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAEAAcABAACAAcAHAAHAAIAAAAAAGgCAAB+AgAA
fwIAAIkCAACKAgAAlwIAAJkCAAAmAwAAMwMAAEEDAABCAwAAXAMAAF0DAACQAwAAkQMAAJ4DAACf
AwAAvQMAAL4DAADZAwAA2wMAAOwDAADtAwAABwQAAAgEAAA+BAAAPwQAAEwEAABNBAAAawQAAGwE
AACHBAAAiQQAAKUEAACmBAAAwAQAAMEEAADwBAAA8QQAAA4FAAAPBQAALQUAAC4FAABJBQAASgUA
AO0FAADuBQAANgYAADgGAABLBgAATAYAAGMGAABkBgAAcQYAAHIGAACQBgAAkQYAALEGAACzBgAA
yQYAAMoGAADhBgAA4gYAAO8GAADwBgAADgcAAA8HAAAvBwAAMQcAAKkHAACyBwAAtgcAAMAHAADH
BwAAyQcAAN4HAADfBwAA+wcAAPwHAAAHCAAACAgAAAsIAAAMCAAAIwgAACQIAAAxCAAAMggAAHwI
AAB+CAAAhAgAAIUIAACcCAAAnQgAAKoIAACrCAAA+AgAAPoIAAAACQAAAQkAABkJAAAaCQAAJgkA
ACcJAABZCQAAWwkAAGQJAABlCQAAfAkAAH0JAACjCQAApAkAAOUJAADpCQAA+wkAAPwJAAAQCgAA
EgoAAB8KAAAgCgAANQoAADcKAABDCgAARAoAALEKAACzCgAAvwoAAMAKAADECgAA0QoAANUKAADi
CgAAkAwAAJEMAADxDQAA8g0AAJwOAACdDgAAPA8AAD0PAADuEAAA+xAAABERAAASEQAAHBEAAB0R
AAAqEQAAKxEAAPIRAADzEQAANRIAAEISAABIEgAAURIAAFgSAABaEgAAbhIAAG8SAACJEgAAihIA
AKUSAACmEgAArBIAAK0SAADQEgAA0RIAAN8SAADgEgAA8RIAAPISAABlEwAAZhMAAGsTAABsEwAA
gBMAAIETAACSEwAAkxMAAK4TAACvEwAAtRMAALcTAADaEwAA2xMAAOkTAADqEwAA+xMAAPwTAAB+
FAAAgBQAAJEUAACSFAAAoBQAAKEUAACzFAAAtBQAAOoUAAD0FAAA+BQAAAUVAAAJFQAAFhUAABoV
AAArFQAAQBUAAEEVAABLFQAATBUAAGIVAABjFQAAChYAAAwWAAAkFgAAJxYAADoWAAA9FgAAWRYA
AFsWAAB3FgAAeRYAAJUWAACXFgAAsxYAALUWAADRFgAA0xYAAO8WAADxFgAADRcAAA8XAAArFwAA
LRcAAEkXAABLFwAAZxcAAGkXAACFFwAAhxcAAKMXAAClFwAAwRcAAMMXAADfFwAA4RcAAP0XAAD/
FwAAGxgAADUYAAA8GAAAUBgAAGsYAABsGAAAdhgAAHcYAACNGAAAjhgAAHcaAAB4GgAA9RoAAPYa
AAA4GwAARRsAAEwbAABOGwAAdhsAAHkbAACaGwAAnBsAAKkbAACqGwAAfRwAAIccAACMHAAAmRwA
AKAcAAC3HAAAzBwAAM0cAADXHAAA2BwAAPMcAAD0HAAAxB0AAMUdAAAOHgAAER4AACQeAAAnHgAA
Px4AAEEeAABUHgAAVh4AAG4eAABwHgAAhh4AAIgeAAC3HgAAuR4AAPQeAAABHwAAxyAAAMggAACJ
IgAAiiIAAPwjAAAQJAAAJiQAACckAAAxJAAAMiQAAD8kAABAJAAA3CUAAN0lAAAwJgAAPCYAAEkm
AABLJgAAcyYAAHYmAACXJgAAoCYAAKQmAACuJgAAuSYAALsmAADQJgAA0SYAAOYmAADnJgAA8iYA
APQmAAADJwAABCcAABYnAAAYJwAAKCcAACsnAAA/JwAAQicAAFQnAABWJwAAbicAAHAnAACjJwAA
pScAAOQnAADmJwAADigAABAoAAA4KAAAOigAAEkoAABKKAAAXSgAAF8oAACaKAAAnigAAMcoAADL
KAAA3CgAAN0oAADnKAAA6CgAAOwoAAD5KAAAuCoAAMsqAADgKgAA4ioAAOwqAADuKgAACSsAAAsr
AADZLAAA2ywAAPgsAAAGLQAAGC0AABktAAA0LQAANS0AAEotAABLLQAAZS0AAGYtAACDLQAAhC0A
ALktAAC7LQAAxy0AAMgtAADfLQAA4C0AAO0tAADuLQAACC4AAAkuAAAmLgAAJy4AAHguAAB6LgAA
li4AAJcuAACxLgAAsi4AAOEuAADiLgAA/y4AAAAvAAAeLwAAHy8AADkvAABELwAATi8AAFAvAABl
LwAAZy8AAJovAACcLwAApy8AAKkvAACwLwAAsS8AAMkvAADKLwAA2y8AANwvAAAGMAAACDAAABYw
AAAXMAAALzAAADAwAAA8MAAASTAAALoxAAC7MQAA7zIAAAkzAAAgMwAAITMAACszAAAsMwAAOTMA
ADozAAAnNAAAMzQAADo0AABCNAAAUTQAAFI0AABmNAAAZzQAAI80AACQNAAAqjQAAKs0AACvNAAA
sDQAANM0AADUNAAA3zQAAOA0AAABNQAACzUAABI1AAAfNQAAJjUAADM1AAA6NQAAYDUAAGA1AAB1
NQAAdTUAAHY1AAAoNgAALDYAAM82AADSNgAABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcA
BQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAF
AAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUA
BwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAH
AAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcA
BQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAF
AAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUA
BwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAH
AAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcA
BQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAF
AAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUA
BwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAH
AAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcA
BQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAF
AAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUA
BwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAH
AAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcA
BAAHAAQAAgAHABoABwACAP//FAAAAAYATgBvAHIAdABlAGwAKQBDADoAXABXAEkATgBEAE8AVwBT
AFwARABFAFMASwBUAE8AUABcAFMARwAxADYAXABVAEkAIABwAGEAYwBrAGEAZwBlACAAVABEAC4A
ZABvAGMABgBOAG8AcgB0AGUAbAA2AEMAOgBcAHcAaQBuAGQAbwB3AHMAXABUAEUATQBQAFwAQQB1
AHQAbwBSAGUAYwBvAHYAZQByAHkAIABzAGEAdgBlACAAbwBmACAAVQBJACAAcABhAGMAawBhAGcA
ZQAgAFQARAAuAGEAcwBkAAYATgBvAHIAdABlAGwANgBDADoAXAB3AGkAbgBkAG8AdwBzAFwAVABF
AE0AUABcAEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAFUASQAgAHAA
YQBjAGsAYQBnAGUAIABUAEQALgBhAHMAZAAGAE4AbwByAHQAZQBsACkAQwA6AFwAVwBJAE4ARABP
AFcAUwBcAEQARQBTAEsAVABPAFAAXABTAEcAMQA2AFwAVQBJACAAcABhAGMAawBhAGcAZQAgAFQA
RAAuAGQAbwBjAAYATgBvAHIAdABlAGwANgBDADoAXAB3AGkAbgBkAG8AdwBzAFwAVABFAE0AUABc
AEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAFUASQAgAHAAYQBjAGsA
YQBnAGUAIABUAEQALgBhAHMAZAAGAE4AbwByAHQAZQBsADYAQwA6AFwAdwBpAG4AZABvAHcAcwBc
AFQARQBNAFAAXABBAHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABVAEkA
IABwAGEAYwBrAGEAZwBlACAAVABEAC4AYQBzAGQABgBOAG8AcgB0AGUAbAA2AEMAOgBcAHcAaQBu
AGQAbwB3AHMAXABUAEUATQBQAFwAQQB1AHQAbwBSAGUAYwBvAHYAZQByAHkAIABzAGEAdgBlACAA
bwBmACAAVQBJACAAcABhAGMAawBhAGcAZQAgAFQARAAuAGEAcwBkAAYATgBvAHIAdABlAGwAKQBD
ADoAXABXAEkATgBEAE8AVwBTAFwARABFAFMASwBUAE8AUABcAFMARwAxADYAXABVAEkAIABwAGEA
YwBrAGEAZwBlACAAVABEAC4AZABvAGMABgBOAG8AcgB0AGUAbAA2AEMAOgBcAHcAaQBuAGQAbwB3
AHMAXABUAEUATQBQAFwAQQB1AHQAbwBSAGUAYwBvAHYAZQByAHkAIABzAGEAdgBlACAAbwBmACAA
VQBJACAAcABhAGMAawBhAGcAZQAgAFQARAAuAGEAcwBkAAYATgBvAHIAdABlAGwAKQBDADoAXABX
AEkATgBEAE8AVwBTAFwARABFAFMASwBUAE8AUABcAFMARwAxADYAXABVAEkAIABwAGEAYwBrAGEA
ZwBlACAAVABEAC4AZABvAGMAHwB8////+GbKAv8PAAAAAAAAAAAAAAAAAAAAAAEAff///+KCHj7/
DwAAAAAAAAAAAAAAAAAAAAABAH7///9c9Px+/w8AAAAAAAAAAAAAAAAAAAAAAQB/////IjH2C/8P
AAAAAAAAAAAAAAAAAAAAAAEAgP///zIAjF//DwAAAAAAAAAAAAAAAAAAAAABAIH///+w4bjs/w8A
AAAAAAAAAAAAAAAAAAAAAQCC////iKgkFv8PAAAAAAAAAAAAAAAAAAAAAAEAg////9o/vGr/DwAA
AAAAAAAAAAAAAAAAAAABAIj///+gIh7M/w8AAAAAAAAAAAAAAAAAAAAAAQCJ////nBqyUP8P/w//
D/8P/w//D/8P/w//DwEA/v//////////DwAAAAAAAAAAAAAAAAAAAAABAAEAAAAAAAAA/w8AAAAA
AAAAAAAAAAAAAAAAAQACAAAACQQPAP8PAAAAAAAAAAAAAAAAAAAAAAEAAwAAAAAAAAD/DwAAAAAA
AAAAAAAAAAAAAAABAAQAAAAAAAAA/w8AAAAAAAAAAAAAAAAAAAAAAQAFAAAAAAAAAP8PAAAAAAAA
AAAAAAAAAAAAAAEABgAAAAAAAAD/DwAAAAAAAAAAAAAAAAAAAAABAAkAAAAAAAAA/w8AAAAAAAAA
AAAAAAAAAAAAAQAKAAAAAAAAAP8PAAAAAAAAAAAAAAAAAAAAAAEACwAAAAkEDwD/DwAAAAAAAAAA
AAAAAAAAAAABAAFOxwHCSuy0/w8AAAAAAAAAAAAAAAAAAAAAAQCoIikNfuDWXMDa/w//D/8P/w//
D/8P/w//DwAAKC33D6zkQij/D/8P/w//D/8P/w//D/8P/w8AAABTYRKufbxo/w8AAAAAAAAAAAAA
AAAAAAAAAQBAK2kYmH2UJv8PAAAAAAAAAAAAAAAAAAAAAAEAiSiRHHQX8nf/D/8P/w//D/8P/w//
D/8P/w8AALdukSEki+Lf/w//D/8P/w//D/8P/w//D/8PAABGFzsoAQAJBP8PAAAAAAAAAAAAAAAA
AAAAAAEAQ1UWPAEACQT/DwAAAAAAAAAAAAAAAAAAAAABAOlDDHjKdDRpAAAAAAAAAAAAAAAAAAAA
AAAAAQCqbYZ8PCuIBAYAAAAAAAAAAAAAAAAAAAAAAAEAAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAA
ABgAAA+E1AURhJj+FcYFAAHUBQZehNQFYISY/gIAAAAuAAEAAAAAAAEAAAAAAAAAAAAAAAAAAAAA
AAAYAAAPhLkEEYSY/hXGBQABuQQGXoS5BGCEmP4CAAAALgABAAAAAAABAAAAAAAAAAAAAAAAAAAA
AAAAGAAAD4SeAxGEmP4VxgUAAZ4DBl6EngNghJj+AgAAAC4AAQAAAAAAAQAAAAAAAAAAAAAAAAAA
AAAAABgAAA+EgwIRhJj+FcYFAAGDAgZehIMCYISY/gIAAAAuAAEAAAAXAAAAAAAAAAAAAAAAAAAA
AAAAAAsYAAAPhNQFEYSY/hXGBQAB1AUGXoTUBWCEmP5PSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAA
AAAAAAAAAAAAAAAAAAALGAAAD4S5BBGEmP4VxgUAAbkEBl6EuQRghJj+T0oBAFFKAQBvKAABALfw
AQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EngMRhJj+FcYFAAGeAwZehJ4DYISY/k9KAQBR
SgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhIMCEYSY/hXGBQABgwIGXoSD
AmCEmP5PSgEAUUoBAG8oAAEAt/ABAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4RoARGEmP4V
xgUAAWgBBl6EaAFghJj+AgAAAC4AAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+
FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAqAAQA
AAAAQAEAAAAAAAAAAAAAAAAAaAEAAAAQAAAPhGgBEYSY/l6EaAFghJj+AgAAAC4AAQAAAAAAAQAA
AAAAAAAAAAAAAAAAAAAAABgAAA+EaAERhJj+FcYFAAFoAQZehGgBYISY/gIAAAAuAAEAAAAAAAEA
AAAAAAAAAAAAAAAAAAAAAAMYAAAPhDgEEYSY/hXGBQABOAQGXoQ4BGCEmP5vKAACAAAALgAEAAAA
AEABAAAAAAAAAAAAAAAAAGgBAAAAEAAAD4RoARGEmP5ehGgBYISY/gIAAAAuAAQAAAAAQAEAAAAA
AAAAAAAAAAAAaAEAAAAQAAAPhGgBEYSY/l6EaAFghJj+AgAAAC4ABAAAAABAAQAAAAAAAAAAAAAA
AABoAQAAABAAAA+EaAERhJj+XoRoAWCEmP4CAAAALgAEAAAAAEABAAAAAAAAAAAAAAAAAGgBAAAA
EAAAD4RoARGEmP5ehGgBYISY/gIAAAAuAAQAAAAAQAEAAAAAAAAAAAAAAAAAaAEAAAAQAAAPhGgB
EYSY/l6EaAFghJj+AgAAAC4AAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EaAERhJj+FcYF
AAFoAQZehGgBYISY/gIAAAAuAAEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhGgBEYSY/hXG
BQABaAEGXoRoAWCEmP4CAAAALgABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4QIBxGEmP4V
xgUAAQgHBl6ECAdghJj+T0oBAFFKAQBvKAABALfwAQAAABcQAAAAAAAAAAAAAGgBAAAAAAAACxgA
AA+E2AkRhJj+FcYFAAHYCQZehNgJYISY/k9KAQBRSgEAbygAAQC38AEAAAAXkAAAAAAAAAAAAABo
AQAAAAAAAAsYAAAPhKgMEYSY/hXGBQABqAwGXoSoDGCEmP5PSgUAUUoFAG8oAAEAp/ABAAAAF5AA
AAAAAAAAAAAAaAEAAAAAAAALGAAAD4R4DxGEmP4VxgUAAXgPBl6EeA9ghJj+T0oBAFFKAQBvKAAB
ALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+ESBIRhJj+FcYFAAFIEgZehEgSYISY/k9K
BgBRSgYAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhBgVEYSY/hXGBQABGBUG
XoQYFWCEmP5PSgUAUUoFAG8oAAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4ToFxGE
mP4VxgUAAegXBl6E6BdghJj+T0oBAFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAA
CxgAAA+EuBoRhJj+FcYFAAG4GgZehLgaYISY/k9KBgBRSgYAbygAAQBvAAEAAAAXkAAAAAAAAAAA
AABoAQAAAAAAAAsYAAAPhIgdEYSY/hXGBQABiB0GXoSIHWCEmP5PSgUAUUoFAG8oAAEAp/ABAAAA
AAABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4QAABGEAAAVxgUAAWgBBl6EAABghAAAAgAAAC4AAQAA
AAAAAQMAAAAAAAAAAAAAAAAAAAAAABgAAA+EAAARhAAAFcYFAAFoAQZehAAAYIQAAAMAAAAuAAEA
AQAAAAAAAQMFAAAAAAAAAAAAAAAAAAAAABgAAA+EAAARhAAAFcYFAAHQAgZehAAAYIQAAAUAAAAu
AAEALgACAAEAAAAAAAEDBQcAAAAAAAAAAAAAAAAAAAAYAAAPhAAAEYQAABXGBQABOAQGXoQAAGCE
AAAHAAAALgABAC4AAgAuAAMAAQAAAAAAAQMFBwkAAAAAAAAAAAAAAAAAABgAAA+EAAARhAAAFcYF
AAE4BAZehAAAYIQAAAkAAAAuAAEALgACAC4AAwAuAAQAAQAAAAAAAQMFBwkLAAAAAAAAAAAAAAAA
ABgAAA+EAAARhAAAFcYFAAE4BAZehAAAYIQAAAsAAAAuAAEALgACAC4AAwAuAAQALgAFAAEAAAAA
AAEDBQcJCw0AAAAAAAAAAAAAAAAYAAAPhAAAEYQAABXGBQABAAAGXoQAAGCEAAANAAAALgABAC4A
AgAuAAMALgAEAC4ABQAuAAYAAQAAAAAAAQMFBwkLDQ8AAAAAAAAAAAAAABgAAA+EAAARhAAAFcYF
AAEAAAZehAAAYIQAAA8AAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcAAQAAAAAAAQMFBwkL
DQ8RAAAAAAAAAAAAABgAAA+EAAARhAAAFcYFAAEAAAZehAAAYIQAABEAAAAuAAEALgACAC4AAwAu
AAQALgAFAC4ABgAuAAcALgAIAAEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhGgBEYSY/hXG
BQABaAEGXoRoAWCEmP4CAAAALgABAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4T7BBGEBfsV
xgUAAfsEBl6E+wRghAX7AwBbAAAAXQABAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4SwARGE
UP4VxgUAAbABBl6EsAFghFD+AQAAAAEAAAAAAAEDAAAAAAAAAAAAAAAAAAAAAAAYAAAPhEACEYTA
/RXGBQABQAIGXoRAAmCEwP0DAAAALgABAAEAAAAAAAEDBQAAAAAAAAAAAAAAAAAAAAAYAAAPhNAC
EYQw/RXGBQAB0AIGXoTQAmCEMP0FAAAALgABAC4AAgABAAAAAAABAwUHAAAAAAAAAAAAAAAAAAAA
GAAAD4RgAxGEoPwVxgUAAWADBl6EYANghKD8BwAAAC4AAQAuAAIALgADAAEAAAAAAAEDBQcJAAAA
AAAAAAAAAAAAAAAYAAAPhPADEYQQ/BXGBQAB8AMGXoTwA2CEEPwJAAAALgABAC4AAgAuAAMALgAE
AAEAAAAAAAEDBQcJCwAAAAAAAAAAAAAAAAAYAAAPhIAEEYSA+xXGBQABgAQGXoSABGCEgPsLAAAA
LgABAC4AAgAuAAMALgAEAC4ABQABAAAAAAABAwUHCQsNAAAAAAAAAAAAAAAAGAAAD4QQBRGE8PoV
xgUAARAFBl6EEAVghPD6DQAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAAEAAAAAAAEDBQcJCw0P
AAAAAAAAAAAAAAAYAAAPhKAFEYRg+hXGBQABoAUGXoSgBWCEYPoPAAAALgABAC4AAgAuAAMALgAE
AC4ABQAuAAYALgAHAAEAAAAAAAEDBQcJCw0PEQAAAAAAAAAAAAAYAAAPhDAGEYTQ+RXGBQABMAYG
XoQwBmCE0PkRAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgAHAC4ACAABAAAAAwAHAAAAAAAA
AAAAAAAAAAAAAAADGAAAD4QAABGEAAAVxgUAAaAFBl6EAABghAAAbygABwBBAG4AbgBlAHgAIAAA
AAEAAAAAAAEDAAAAAAAAAAAAAAAAAAAAAAMYAQAPhAAAEYQAABXGBQABaAEGXoQAAGCEAABvKAAD
AAAALgABAAEAAAAAAAEDBQAAAAAAAAAAAAAAAAAAAAMYAgAPhAAAEYQAABXGBQAB0AIGXoQAAGCE
AABvKAAFAAAALgABAC4AAgABAAAAAAABAwUHAAAAAAAAAAAAAAAAAAADGAMAD4QAABGEAAAVxgUA
AQAABl6EAABghAAAbygABwAAAC4AAQAuAAIALgADAAEAAAAAAAEDBQcJAAAAAAAAAAAAAAAAAAMY
BAAPhAAAEYQAABXGBQABAAAGXoQAAGCEAABvKAAJAAAALgABAC4AAgAuAAMALgAEAAEAAAAAAAED
BQcJCwAAAAAAAAAAAAAAAAMYBQAPhAAAEYQAABXGBQABAAAGXoQAAGCEAABvKAALAAAALgABAC4A
AgAuAAMALgAEAC4ABQABAAAAAAABAwUHCQsNAAAAAAAAAAAAAAADGAYAD4QAABGEAAAVxgUAAQAA
Bl6EAABghAAAbygADQAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAAEAAAAAAAEDBQcJCw0PAAAA
AAAAAAAAAAMYBwAPhAAAEYQAABXGBQABAAAGXoQAAGCEAABvKAAPAAAALgABAC4AAgAuAAMALgAE
AC4ABQAuAAYALgAHAAEAAAAAAAEDBQcJCw0PEQAAAAAAAAAAAAMYCAAPhAAAEYQAABXGBQABAAAG
XoQAAGCEAABvKAARAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgAHAC4ACAABAAAAFwAAAAAA
AAAAAAAAAAAAAAAAAAALGAAAD4RoARGEmP4VxgUAAWgBBl6EaAFghJj+T0oBAFFKAQBvKAABALfw
AQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EaAERhJj+FcYFAAFoAQZehGgBYISY/k9KAQBR
SgEAbygAAQC38AEAAAAAAAEAAAAAAAAAAADQAgAAAAAAAAMYAAAPhDgEEYSY/hXGBQABOAQGXoQ4
BGCEmP5vKAACAAAALgAAAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAADGAAAD4RoARGEmP4VxgUAAWgB
Bl6EaAFghJj+bygAAQAtAB8AAACJ////AAAAAAAAAAAAAAAA/v///wAAAABI+AsCAQAAAENVFjwA
AAAAAAAAAAAAAACD////AAAAAAAAAAAAAAAAgv///wAAAAAAAAAAAAAAAIH///8AAAAAAAAAAAAA
AACA////AAAAAAAAAAAAAAAAiP///wAAAAAAAAAAAAAAAH////8AAAAAAAAAAAAAAAB+////AAAA
AAAAAAAAAAAAff///wAAAAAAAAAAAAAAAHz///8AAAAAAAAAAAAAAACqbYZ8AAAAAAAAAAAAAAAA
KC33DwAAAAAAAAAAAAAAAABTYRIAAAAAAAAAAAAAAADpQwx4AAAAAAAAAAAAAAAAqCIpDQAAAAAA
AAAAAAAAAEYXOygAAAAAAAAAAAAAAAABTscBAAAAAAAAAAAAAAAAiSiRHAAAAAAAAAAAAAAAALdu
kSEAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAA
AAAAAAAEAAAAAAAAAAAAAAAAAAAABQAAAAAAAAAAAAAAAAAAAAYAAAAAAAAAAAAAAAAAAAAJAAAA
AAAAAAAAAAAAAAAACgAAAAAAAAAAAAAAAAAAAAsAAAAAAAAAAAAAAAAAAABAK2kYAAAAAAAAAAAA
AAAA//////////9U+AsC4Kf0AwEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsQAAAPhJUBEYSY/l6E
lQFghJj+T0oBAFFKAQBvKAABALfw////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////x8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP9ASFAgTGFzZXJKZXQgODEwMCBTZXJp
ZXMgUENMIDYAXFxOQ1BTMDFccG5jMXAwMTAASFBCRkRCMwBIUCBMYXNlckpldCA4MTAwIFNlcmll
cyBQQ0wgNgBIUCBMYXNlckpldCA4MTAwIFNlcmllcyBQQ0wgNgAAAAAEEACUAI4DA78AAAEAAQAA
AAAAAAABAAcAWAICAAEAWAIAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIgQsAEhQIExhc2VySmV0
IDgxMDAgU2VyaWVzIFBDTCA2AAAAAAAAAAQALgDrAgAAXAMdDcajgFFwtjEFDMbDAFDEYjaFROHw
sFQOCweEwsbDSHxEZRWKDGDQMbDONQoZDmUDiOyKKw4uF2TSiESocjYFS4azCKTOaykFSuDS6dSM
FTKaDeT0KVx6XDefRagUybRuV1KXQakTal02b0McwqXDmpwqq2CsDmQjgbw6kWiv1eVDie2640mD
0sa1KwjMb2aIU2uxerUIZji2jeUUiQ2m6QscWQbx6kUqB0zEDiWwSpw4RCKZ5CnS+3UeYZjD2EZR
m3VK42aq5rS5SuakFaHSaym27BT7ZUvNby2ji4bjdXy/RsZjC4RHLTCUUG/jCyYrP3vqcwYcXG7j
d9yWjjoxSlVW+04cz3B+zpYb038aROI6iKSHtwoZjSoS7swF4X6DRd1uf8XXocuAUhYNsEwfhq3M
fxOw4b95nag+AV3Dlx1IaNymIDRjURbd92GWqAVQWxZ4WU2H4Zd+FYdbNOl/ZqE3uhVyX5QsN1aD
mI0VY8XVyRhBl/DaCkkeVFQzQqOgyDZPUsfZMYrZEMg0VJLIMhxc1ODVKEsj9CmqiZQw1Q5LIURV
HoAmZIQ5DSG5Um0MoEnBeZklYNEGnCClTnQNUKnCL0woBHpwkqY5VU6PAKnCN6Fl1rA3nwNJTopM
4llZgaOliBZODilZiRWdHGp2ak/pJWA2WZ65yRNzqLpOaKBp+F1DDebw1n6XJODegpfiqbX8rqiV
6qWrQ1pBCl+qpCn8sCl6kcKM0bfytJblSOY8tVda6qNoGitRTnko4NaoXq23DVicaOQ12bbgRQqB
lFElTQN/lhmiR7aCK4UQWNclVgRYaBTpOaEk2lLdXpOXRuG/wxWNPYdviCAKoGWZQvfC1CvtqMQb
kIsADGzYHU4NGCSSy0WjoMwym8NqjQ2eWIDKYKsVPNKycyV6OW9U5Bydf51R9/mFk4NsHrmwrOUM
NpZYytplk+fGVgXPEqu9EIEXlM5DQSRXMYRJLowrVHpDlntekJe1yQAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEhQIExhc2VySmV0IDgxMDAg
U2VyaWVzIFBDTCA2AAAAAAQQAJQAjgMDvwAAAQABAAAAAAAAAAEABwBYAgIAAQBYAgAAAQAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAiBCwASFAgTGFzZXJKZXQgODEwMCBTZXJpZXMgUENMIDYAAAAAAAAA
BAAuAOsCAABcAx0NxqOAUXC2MQUMxsMAUMRiNoVE4fCwVA4LB4TCxsNIfERlFYoMYNAxsM41ChkO
ZQOI7IorDi4XZNKIRKhyNgVLhrMIpM5rKQVK4NLp1IwVMpoN5PQpXHpcN59FqBTJtG5XUpdBqRNq
XTZvQxzCpcOanCqrYKwOZCOBvDqRaK/V5UOJ7brjSYPSxrUrCMxvZohTa7F6tQhmOLaN5RSJDabp
CxxZBvHqRSoHTMQOJbBKnDhEIpnkKdL7dR5hmMPYRlGbdUrjZqrmtLlK5qQVodJrKbbsFPtlS81v
LaOLhuN1fL9GxmMLhEctMJRQb+MLJis/e+pzBhxcbuN33JaOOjFKVVb7ThzPcH7OlhvTfxpE4jqI
pIe3ChmNKhLuzAXhfoNF3W5/xdehy4BSFg2wTB+Grcx/E7Dhv3mdqD4BXcOXHUho3KYgNGNRFt33
YZaoBVBbFnhZTYfhl34Vh1s06X9moTe6FXJflCw3VoOYjRVjxdXJGEGX8NoKSR5UVDNCo6DINk9S
x9kxitkQyDRUksgyHFzU4NUoSyP0KaqJlDDVDkshRFUegCZkhDkNIblSbQygScF5mSVg0QacIKVO
dA1QqcIvTCgEenCSpjlVTo8AqcI3oWXWsDefA0lOikziWVmBo6WIFk4OKVmJFZ0canZqT+klYDZZ
nrnJE3Oouk5ooGn4XUMN5vDWfpck4N6Cl+KptfyuqJXqpatDWkEKX6qkKfywKXqRwozRt/K0luVI
5jy1V1rqo2gaK1FOeSjg1qherbcNWJxo5DXZtuBFCoGUUSVNA3+WGaJHtoIrhRBY1yVWBFhoFOk5
oSTaUt1ek5dG4b/DFY09h2+IIAqgZZlC98LUK+2oxBuQiwAMbNgdTg0YJJLLRaOgzDKbw2qNDZ5Y
gMpgqxU80rJzJXo5b1TkHJ1/nVH3+YWTg2weubCs5Qw2lljK2mWT58ZWBc8Sq70QgReUzkNBJFcx
hEkujCtUekOWe16Ql7XJAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAA4ABAEoAAABKAAAASF/oAQEAAQBKAAAAAAACAEUAAAAyCqclAhAAAAAA
AAAA0TYAAGABAAgAQAAABwAAAEcWkAEAAAICBgMFBAUCAwQDAAAAAAAAAAAAAAAAAAAAAQAAAAAA
AABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAADUWkAECAAUFAQIBBwYCBQcAAAAAAAAA
EAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAAADMmkAEAAAILBgQCAgICAgQDAAAAAAAAAAAA
AAAAAAAAAQAAAAAAAABBAHIAaQBhAGwAAABZEpABAAkAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAA
AAEAAAAAAAAAQwBHACAAVABpAG0AZQBzAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4A
AABFEZABgAUAAAAAAAAAAAAAAQAAAAAABwgQAAAAAAAAAAAAAgAAAAAAEyC+ABkgqQAAABogbAAa
IHIAIAATIL4AGSCpAAAAOwaQAQIABQAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFcA
aQBuAGcAZABpAG4AZwBzAAAAPzWQAQAAAgcDCQICBQIEBAMAAAAAAAAAAAAAAAAAAAABAAAAAAAA
AEMAbwB1AHIAaQBlAHIAIABOAGUAdwAAACIBBAABBAgYVgzQAgAAaAEAAAAAGXtCRu17QkZuVCZm
BQCSAAAAFgAAAIIAAAABAAEAAAAEAIMAAQAAAAAAAAAAAAAAAQABAAAAAQAAAAAAAACBAlYMAIQA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAClBsAHtAC0AIAAEjAAABAAGQBkAAAAGQAAAJ8AAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgNQAAAAAAAAAAAAAAAAAA
AAAAAAAAAgAAAAAA//8SAAAAAAAAAEIASQBUAFUAIAAtACAAVABlAGwAZQBjAG8AbQBtAHUAbgBp
AGMAYQB0AGkAbwBuACAAUwB0AGEAbgBkAGEAcgBkAGkAegBhAHQAaQBvAG4AIABTAGUAYwB0AG8A
cgAJAFQAZQBtAHAAbwByAGEAcgB5ACAARABvAGMAdQBtAGUAbgB0ACAAAAAAAAAAEQBBAHMAdABy
AGkAZAAgAHYAYQBuACAAZABlACAASwBhAHIABgBOAG8AcgB0AGUAbAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAA/v8AAAQAAgAAAAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQq5EIACsns9kw
AAAAICUAABMAAAABAAAAoAAAAAIAAACoAAAAAwAAAPQAAAAEAAAAAAEAAAUAAAAcAQAABgAAACgB
AAAHAAAANAEAAAgAAABEAQAACQAAAFQBAAASAAAAYAEAAAoAAAB8AQAACwAAAIgBAAAMAAAAlAEA
AA0AAACgAQAADgAAAKwBAAAPAAAAtAEAABAAAAC8AQAAEwAAAMQBAAARAAAAzAEAAAIAAADkBAAA
HgAAAEMAAABJVFUgLSBUZWxlY29tbXVuaWNhdGlvbiBTdGFuZGFyZGl6YXRpb24gU2VjdG9yCVRl
bXBvcmFyeSBEb2N1bWVudCAAAB4AAAABAAAAAFRVIB4AAAASAAAAQXN0cmlkIHZhbiBkZSBLYXIA
YXQeAAAAAQAAAABzdHIeAAAAAQAAAABzdHIeAAAABwAAAE5vcm1hbAB2HgAAAAcAAABOb3J0ZWwA
dh4AAAACAAAANQBydB4AAAATAAAATWljcm9zb2Z0IFdvcmQgOC4wAHRAAAAAAOxdZRQAAABAAAAA
AETvicGUvQFAAAAAAL4gltl3vwFAAAAAAG6vhvV3vwEDAAAAAQAAAAMAAAAWAAAAAwAAAIIAAAAD
AAAAAAAAAEcAAABMIwAA/////wMAAAAIAA5S/XP2DwEACQAAA5YRAAAJAJ0AAAAAABQAAAAmBg8A
HgD/////BAAUAAAAV29yZA4ATWljcm9zb2Z0IFdvcmQFAAAACwIAAAAABQAAAAwCZhtiEw0AAAD7
AgAAAAAAAAAAAAAAAAAAAAAAAQAMBAAAAC0BAAAEAAAAAgEBABUAAAD7ArX/AAAAAAAAkAEAAAAA
BEAAEFRpbWVzIE5ldyBSb21hbgBMAAQAAAAtAQEABQAAAAkCAAAAAAQAAAACAQEABAAAAAIBAQAV
AAAA+wK1/wAAAAAAALwCAAAAAARAABBUaW1lcyBOZXcgUm9tYW4AEQAEAAAALQECAAUAAAAUAtAY
2gEEAAAALgEBABcAAAAyCtAY2gEIAAQAAAAAAGITZhtDb250YWN0OjYAJQApABkAJQAhABkAGQAE
AAAALgEAAAUAAAAUAgAAAAAEAAAALQEBAAQAAAACAQEABAAAAAIBAQAFAAAAFAJ4GFkDBAAAAC4B
AQAUAAAAMgp4GFkDBgAEAAAAAABiE2YbUGV0ZXIgKwAhABUAIQAZABMABAAAAC4BAAAFAAAAFALk
Z7CiBQAAABQCeBgHBAQAAAAuAQEAHAAAADIKeBgHBAsABAAAAAAAYhNmG0JsYXRoZXJ3aWNrADIA
FQAhABUAJgAhABkANQAVACEAJQAEAAAALgEAAAUAAAAUAuRnsKIEAAAAAgEBAAMAAAAeAAcAAAAW
BGYbYhMAAAAABAAAACcB//8EAAAAAgEBAAUAAAAUAtAYWQMEAAAALgEBACIAAAAyCtAYWQMPAAQA
AAAAAGITZhtOb3J0ZWwgTmV0d29ya3MANgAmABkAFQAhABUAEwA2ACEAFQA1ACYAGQAlAB0ABAAA
AC4BAAAFAAAAFALkZ7CiBAAAAAIBAQADAAAAHgAHAAAAFgRmG2ITAAAAAAQAAAAnAf//BAAAAAIB
AQAFAAAAFAJ4GPwFBAAAAC4BAQAZAAAAMgp4GPwFCQAEAAAAAABiE2YbVGVsOiAoNjEzAC0AIQAV
ABUAEwAZACYAJgAmAAQAAAAuAQAABQAAABQC5GewogUAAAAUAngYEgcEAAAALgEBABkAAAAyCngY
EgcJAAQAAAAAAGITZhspNzYzIDc1MzkAGQAmACYAJgATACYAJgAmACYABAAAAC4BAAAFAAAAFALk
Z7CiBAAAAAIBAQADAAAAHgAHAAAAFgRmG2ITAAAAAAQAAAAnAf//BAAAAAIBAQAFAAAAFALQGPwF
BAAAAC4BAQARAAAAMgrQGPwFBAAEAAAAAABiE2YbRmF4OioAIQAlABUABAAAAC4BAAAFAAAAFALk
Z7CiBAAAAAIBAQADAAAAHgAHAAAAFgRmG2ITAAAAAAQAAAAnAf//BAAAAAIBAQAFAAAAFAIoGfwF
BAAAAC4BAQA+AAAAMgooGfwFIgAEAAAAAABiE2YbRS1tYWlsOiBibGF0aGVyQG5vcnRlbG5ldHdv
cmtzLmNvbS4AGQA5ACEAFQAVABUAEwAmABUAIQAVACYAIQAZAEUAJgAmABkAFQAhABUAJgAhABUA
NQAmABkAJQAdABMAIQAmADkABAAAAC4BAAAFAAAAFALkZ7CiBAAAAAIBAQADAAAAHgAHAAAAFgRm
G2ITAAAAAAQAAAAnAf//BwAAAPwCAAAAAAAAAAAEAAAALQEDAAkAAAAdBiEA8AAGAH8BbxiqAQcA
AAD8AgAA////AAAABAAAAC0BBAAEAAAALQEDAAkAAAAdBiEA8AAGAAYAbxgpAwQAAAAtAQQABAAA
AC0BAwAJAAAAHQYhAPAABgCdAm8YLwMEAAAALQEEAAQAAAAtAQMACQAAAB0GIQDwAAYABgBvGMwF
BAAAAC0BBAAEAAAALQEDAAkAAAAdBiEA8AAGALULbxjSBQQAAAAtAQQABAAAAAIBAQAEAAAAAgEB
AAQAAAACAQEABAAAAAIBAQADAAAAHgAHAAAAFgRmG2ITAAAAAAQAAAAnAf//BAAAAAIBAQAEAAAA
AgEBAAMAAAAeAAcAAAAWBGYbYhMAAAAABAAAACcB//8EAAAAAgEBABUAAAD7Ar3/AAAAAAAAkAEA
AAAABEAAEFRpbWVzIE5ldyBSb21hbgBuAgQAAAAtAQUABAAAAAIBAQADAAAAHgAHAAAAFgRmG2IT
AAAAAAQAAAAnAf//BAAAAAIBAQAEAAAALQEBAAUAAAAUAica2gEEAAAALgEBAEkAAAAyCica2gEp
AAQAAAAAAGITZhtDOlxXSU5ET1dTXERFU0tUT1BcU0cxNlxVSSBQQUNLQUdFIFRELkRPQwAyABUA
FABGABkANgA2ADYARgAqABQANgAuACoANgAtADYAKwAUACoANQAmACYAFAA2ABkAEwArADUAMgA2
ADUANQAuABMALQA2ABMANgA2ADIABAAAAC4BAAAFAAAAFAIAAAAABQAAABQCJxoKEAQAAAAuAQEA
FwAAADIKJxoKEAgABAAAAAAAYhNmGzE1LjAyLjAwJgAmABMAJgAmABMAJgAmAAQAAAAuAQAABQAA
ABQCJGywogQAAAACAQEAAwAAAB4ABwAAABYEZhtiEwAAAAAEAAAAJwH//wQAAAACAQEAFQAAAPsC
nP8AAAAAAAC8AgAAAAAEQAAQVGltZXMgTmV3IFJvbWFuADQABAAAAC0BBgAFAAAAFAJwAtoBBAAA
AC4BAQBQAAAAMgpwAtoBLgAEAAAAAABiE2YbSVRVIC0gVGVsZWNvbW11bmljYXRpb24gU3RhbmRh
cmRpemF0aW9uIFNlY3RvcicAQwBIABkAIQAZAEMALAAcACwALAAyAFIAUgA4ADgAHAAsADIAIQAc
ADIAOAAZADgAIQAyADgAOAAyACwAOAAcACwAMgAhABwAMgA4ABkAOAAsACwAIQAyACwABAAAAC4B
AAAFAAAAFAIkbLCiFQAAAPsCnP8AAAAAAACQAQAAAAAEQAAQVGltZXMgTmV3IFJvbWFuABUABAAA
AC0BBwAVAAAA+wJ7/wAAAAAAALwCAAAAAARAABBUaW1lcyBOZXcgUm9tYW4AJQAEAAAALQEIAAUA
AAAUAlIC6QoEAAAALgEBAA0AAAAyClIC6QoBAAQAAAAAAGITZhtUAFkABAAAAC4BAAAFAAAAFAIk
bLCiBAAAAC0BBgAFAAAAFAJwAkILBAAAAC4BAQAZAAAAMgpwAkILCQAEAAAAAABiE2YbZW1wb3Jh
cnkgACwAUgA4ADIALAAyACwAMgAZAAQAAAAuAQAABQAAABQCJGywogQAAAAtAQgABQAAABQCUgL/
DAQAAAAuAQEADQAAADIKUgL/DAEABAAAAAAAYhNmG0QAYAAEAAAALgEAAAUAAAAUAiRssKIEAAAA
LQEGAAUAAAAUAnACXw0EAAAALgEBABcAAAAyCnACXw0IAAQAAAAAAGITZhtvY3VtZW50IDIALAA4
AFIALAA4ACEAGQAEAAAALgEAAAUAAAAUAiRssKIEAAAALQEIAAUAAAAUAlIC5Q4EAAAALgEBABcA
AAAyClIC5Q4IAAQAAAAAAGITZhtYWFgvUExFTl8AXwBfACUAUQBZAFkAYAAEAAAALgEAAAUAAAAU
AiRssKIEAAAALQEGAAQAAAACAQEAAwAAAB4ABwAAABYEZhtiEwAAAAAEAAAAJwH//wQAAAACAQEA
BAAAAC0BBwAFAAAAFAJuA9oBBAAAAC4BAQAdAAAAMgpuA9oBDAAEAAAAAABiE2YbU1RVRFkgR1JP
VVAgOAA9AEgASABIABkASABDAEgASAA4ABkABAAAAC4BAAAFAAAAFAIkbLCiBAAAAC0BCAAFAAAA
FAJOA6wEBAAAAC4BAQAOAAAAMgpOA6wEAgAEAAAAAABiE2YbMTZDAEMABAAAAC4BAAAFAAAAFAIk
bLCiBAAAAC0BBwAEAAAAAgEBAAQAAAACAQEABAAAAAIBAQADAAAAHgAHAAAAFgRmG2ITAAAAAAQA
AAAtAQMACQAAAB0GIQDwAAYABAVjBM4BBAAAAC0BBAAEAAAAJwH//wQAAAACAQEABQAAABQCwATa
AQQAAAAuAQEAMgAAADIKwATaARoABAAAAAAAYhNmG0dlbmV2YSwgNy0xOCBGZWJydWFyeSAyMDAw
SAAsADIALAAyACwAGQAZADIAIQAyADIAGQA3ACwAMgAhADIALAAhAC8AGQAyADIAMgAyAAQAAAAu
AQAABQAAABQCJGywogQAAAACAQEABAAAAAIBAQAEAAAAAgEBAAQAAAACAQEABQAAABQCrAXaAQQA
AAAuAQEAHQAAADIKrAXaAQwABAAAAAAAYhNmG1F1ZXN0aW9uKHMpOkgAMgAsACcAHAAcADIAMgAh
ACcAIQAcAAQAAAAuAQAABQAAABQCJGywogUAAAAUAqwFKQQEAAAALgEBABMAAAAyCqwFKQQFAAQA
AAAAAGITZhsxNC8xNgAyADIAHAAyADIABAAAAC4BAAAFAAAAFAIkbLCiBAAAAAIBAQADAAAAHgAH
AAAAFgRmG2ITAAAAAAQAAAAnAf//BAAAAAIBAQAEAAAAAgEBAAQAAAACAQEABQAAABQCmAbaAQQA
AAAuAQEAFwAAADIKmAbaAQgABAAAAAAAYhNmG1NPVVJDRSo6OABIAEgAQwBDAD0AMgAcAAQAAAAu
AQAABQAAABQCJGywogUAAAAUApgGKQQEAAAALgEBABoAAAAyCpgGKQQKAAQAAAAAAGITZhtSYXBw
b3J0ZXVyQwAsADIAMgAyACEAHAAsADIAIQAEAAAALgEAAAUAAAAUAiRssKIEAAAAAgEBAAMAAAAe
AAcAAAAWBGYbYhMAAAAABAAAACcB//8EAAAAAgEBAAQAAAACAQEAAwAAAB4ABwAAABYEZhtiEwAA
AAAEAAAAJwH//wQAAAACAQEABQAAABQChAfaAQQAAAAuAQEAFAAAADIKhAfaAQYABAAAAAAAYhNm
G1RJVExFOj0AHwA9ADsAPQAcAAQAAAAuAQAABQAAABQCJGywogUAAAAUAoQHKQQEAAAALgEBAH8A
AAAyCoQHKQRNAAQAAAAAAGITZhtILjI0OCBBbm5leCBHOiBVc2VyIEludGVyZmFjZSBFbGVtZW50
cyBhbmQgQWN0aW9ucyBQYWNrYWdlcyBmb3IgRGV0ZXJtaW5hdGlvbgBIABkAMgAyADIAGQBIADIA
MgAsADMAGQBIABwAGQBIACcALAAhABkAHwAyABwALAAhACEALAAsACwAGQA9ABwALABOACwAMgAc
ACcAGQAsADIAMgAZAEgALAAcABwAMgAyACcAGQA4ACwALAAyACwAMQAsACcAGQAhADIAIQAZAEgA
LAAcACwAIQBOABwAMgAsABwAHAAyADIABAAAAC4BAAAFAAAAFAIkbLCiBAAAAAIBAQADAAAAHgAH
AAAAFgRmG2ITAAAAAAQAAAAnAf//BAAAAAIBAQAFAAAAFAIsCO8HBAAAAC4BAQAmAAAAMgosCO8H
EgAEAAAAAABiE2YbX19fX19fX19fX19fX19fX19fMgAyADIAMgAyADIAMgAyADIAMgAyADIAMgAy
ADIAMgAyADIABAAAAC4BAAAFAAAAFAIkbLCiBAAAAAIBAQAEAAAAAgEBAAQAAAACAQEABAAAAAIB
AQAEAAAALQEGAAUAAAAUAuAJ2gEEAAAALgEBAB0AAAAyCuAJ2gEMAAQAAAAAAGITZhtJbnRyb2R1
Y3Rpb24nADgAIQAsADIAOAA4ACwAIQAcADIAOAAEAAAALgEAAAUAAAAUAiRssKIEAAAAAgEBAAMA
AAAeAAcAAAAWBGYbYhMAAAAABAAAACcB//8EAAAAAgEBAAQAAAAtAQcABQAAABQCiAraAQQAAAAu
AQEAkgAAADIKiAraAVoABAAAAAAAYhNmG1RoZSBmb2xsb3dpbmcgcGFja2FnZXMgZGVmaW5lIGEg
ZnJhbWV3b3JrIGZvciBzcGVjaWZ5aW5nIGNhcGFiaWxpdGllcyBhc3NvY2lhdGVkIHdpdGggdXNl
cj0AMgAsABkAIQAyABwAHAAyAEgAHAAyADEAGQAyACwALAAyACwAMQAsACcAGQAyACwAIQAcADIA
LAAZACwAGQAhACEALABOACwASAAyACEAMgAZACEAMgAhABkAJwAyACwALAAcACEALwAcADIAMQAZ
ACwALAAyACwAMgAcABwAHAAcABwALAAnABkALAAnACcAMgAsABwALAAcACwAMgAZAEgAHAAcADIA
GQAyACcALAAhAAQAAAAuAQAABQAAABQCJGywogQAAAACAQEAAwAAAB4ABwAAABYEZhtiEwAAAAAE
AAAAJwH//wQAAAACAQEABQAAABQC/graAQQAAAAuAQEAjwAAADIK/graAVgABAAAAAAAYhNmG2lu
dGVyZmFjZSBlbGVtZW50cywgc3VjaCBhcyB0ZXh0IGRpc3BsYXksIGtleXMsIGR5bmFtaWNhbGx5
IGxhYmVsZWQga2V5cywgaW5kaWNhdG9ycyBhbmQcADIAHAAsACEAIQAsACwALAAZACwAHAAsAE4A
LAAyABwAJwAZABkAJwAyACwAMgAZACwAJwAZABwALAAzABwAGQAyABwAJwAyABwALAAvABkAGQAy
ACwALwAnABkAGQAyAC8AMgAsAE4AHAAsACwAHAAcAC8AGQAcACwAMgAsABwALAAyABkAMgAsAC8A
JwAZABkAHAAyADIAHAAsACwAHAAyACEAJwAZACwAMgAyAAQAAAAuAQAABQAAABQCJGywogQAAAAC
AQEAAwAAAB4ABwAAABYEZhtiEwAAAAAEAAAAJwH//wQAAAACAQEABQAAABQCdAvaAQQAAAAuAQEA
mwAAADIKdAvaAWAABAAAAAAAYhNmG2FscGhhbnVtZXJpYyBpbnB1dC4gSW4gYWRkaXRpb24sIHNw
ZWNpZmljIGV4dGVuc2lvbiBwYWNrYWdlcyBmb3IgdGVsZXBob25lIGtleXBhZHMgYW5kIHRlbGVw
aG9uZSwAHAAyADIALAAyADIATgAsACEAHAAsABkAHAAyADIAMgAcABkAGQAfADIAGQAsADIAMgAc
ABwAHAAyADIAGQAZACcAMgAsACwAHAAhABwALAAZACwAMwAcACwAMgAnABwAMgAyABkAMgAsACwA
MgAsADEALAAnABkAIQAyACEAGQAcACwAHAAsADIAMgAyADIALAAZADIALAAvADIALAAyACcAGQAs
ADIAMgAZABwALAAcACwAMgAyADIAMgAsAAQAAAAuAQAABQAAABQCJGywogQAAAACAQEAAwAAAB4A
BwAAABYEZhtiEwAAAAAEAAAAJwH//wQAAAACAQEABQAAABQC6gvaAQQAAAAuAQEAMgAAADIK6gva
ARoABAAAAAAAYhNmG2Z1bmN0aW9uIGtleXMgYXJlIGRlZmluZWQuIQAyADIALAAcABwAMgAyABkA
MgAsAC8AJwAZACwAIQAsABkAMgAsACEAHAAyACwAMgAZAAQAAAAuAQAABQAAABQCJGywogQAAAAC
AQEAAwAAAB4ABwAAABYEZhtiEwAAAAAEAAAAJwH//wQAAAACAQEABAAAAC0BBgAFAAAAFAIoDdoB
BAAAAC4BAQAlAAAAMgooDdoBEQAEAAAAAABiE2YbUHJvcG9zZWQgUGFja2FnZXMAPAAsADIAOAAy
ACcALAA4ABkAPAAyACwAOAAyADIALAAnAAQAAAAuAQAABQAAABQCJGywogQAAAACAQEAAwAAAB4A
BwAAABYEZhtiEwAAAAAEAAAAJwH//wQAAAACAQEABQAAABQCZg7aAQQAAAAuAQEAIgAAADIKZg7a
AQ8ABAAAAAAAYhNmG0Rpc3BsYXkgUGFja2FnZQBIABwAJwA4ABwAMgAyABkAPAAyACwAOAAyADIA
LAAEAAAALgEAAAUAAAAUAiRssKIEAAAAAgEBAAMAAAAeAAcAAAAWBGYbYhMAAAAABAAAACcB//8E
AAAAAgEBAAQAAAAtAQcABQAAABQCDg/aAQQAAAAuAQEALAAAADIKDg/aARYABAAAAAAAYhNmG1Bh
Y2thZ2VJRDogZGlzLCAweDAwMjU4ACwALAAyACwAMQAsAB8ASAAcABkAMgAcACcAGQAZADIAMwAy
ADIAMgAyAAQAAAAuAQAABQAAABQCJGywogQAAAACAQEABAAAAAIBAQAFAAAAFAK2D9oBBAAAAC4B
AQAaAAAAMgq2D9oBCgAEAAAAAABiE2YbVmVyc2lvbjogMUgALAAhACcAHAAyADIAHAAZADIABAAA
AC4BAAAFAAAAFAIkbLCiBAAAAAIBAQAEAAAAAgEBAAUAAAAUAl4Q2gEEAAAALgEBAB8AAAAyCl4Q
2gENAAQAAAAAAGITZhtFeHRlbmRzOiBOb25lAD0AMwAcACwAMgAyACcAHAAZAEgAMgAyACwABAAA
AC4BAAAFAAAAFAIkbLCiBAAAAAIBAQAEAAAAAgEBAAQAAAACAQEABAAAAAIBAQAFAAAAFAKuEdoB
BAAAAC4BAQCdAAAAMgquEdoBYQAEAAAAAABiE2YbVGhpcyBwYWNrYWdlIGRlZmluZXMgcHJvcGVy
dGllcyBhbmQgc2lnbmFscyBhc3NvY2lhdGVkIHdpdGggdGV4dCBkaXNwbGF5IHVzZXIgaW50ZXJm
YWNlIGVsZW1lbnRzLgA9ADIAHAAnABkAMgAsACwAMgAsADEALAAZADIALAAhABwAMgAsACcAGQAy
ACEAMgAyACwAIQAcABwALAAnABkALAAyADIAGQAnABwAMQAyACwAHAAnABkALAAnACcAMgAsABwA
LAAcACwAMgAZAEgAHAAcADIAGQAcACwAMwAcABkAMgAcACcAMgAcACwALwAZADIAJwAsACEAGQAc
ADIAHAAsACEAIQAsACwALAAZACwAHAAsAE4ALAAyABwAJwAZAAQAAAAuAQAABQAAABQCJGywogQA
AAACAQEABAAAAAIBAQAFAAAAFAIkEtoBBAAAAC4BAQBHAAAAMgokEtoBKAAEAAAAAABiE2YbU2Vl
IFByb2NlZHVyZXMgZm9yIGRldGFpbHMgb2Ygb3BlcmF0aW9uLjgALAAsABkAOAAhADIALAAsADIA
MgAhACwAJwAZACEAMgAhABkAMgAsABwALAAcABwAJwAZADIAIQAZADIAMgAsACEALAAcABwAMgAy
ABkABAAAAC4BAAAFAAAAFAIkbLCiBAAAAAIBAQAEAAAAAgEBAAQAAAACAQEABAAAAAIBAQAEAAAA
LQEGAAUAAAAUAnQT2gEEAAAALgEBABoAAAAyCnQT2gEKAAQAAAAAAGITZhtQcm9wZXJ0aWVzPAAs
ADIAOAAsACwAIQAcACwAJwAEAAAALgEAAAUAAAAUAiRssKIEAAAAAgEBAAMAAAAeAAcAAAAWBGYb
YhMAAAAABAAAACcB//8EAAAAAgEBAAQAAAAtAQcABQAAABQCHBTaAQQAAAAuAQEAIAAAADIKHBTa
AQ4ABAAAAAAAYhNmG051bWJlciBvZiByb3dzSAAyAE4AMgAsACEAGQAyACEAGQAhADIASAAnAAQA
AAAuAQAABQAAABQCJGywogQAAAACAQEABAAAAAIBAQAFAAAAFALEFAYDBAAAAC4BAQAyAAAAMgrE
FAYDGgAEAAAAAABiE2YbUHJvcGVydHlJRDogbnJvd3MgKDB4MDAwMSk4ACEAMgAyACwAIQAcAC8A
HwBIABwAGQAyACEAMgBIACcAGQAhADIAMwAyADIAMgAyACEABAAAAC4BAAAFAAAAFAIkbLCiBAAA
AAIBAQAEAAAAAgEBAAUAAAAUAmwVBgMEAAAALgEBAFYAAAAyCmwVBgMyAAQAAAAAAGITZhtEZXNj
cmlwdGlvbjogTWF4aW11bSBudW1iZXIgb2Ygcm93cyBvbiB0aGUgZGlzcGxheUgALAAnACwAIQAc
ADIAHAAcADIAMgAcABkAWQAsADMAHABOADIATgAZADIAMgBOADIALAAhABkAMgAhABkAIQAyAEgA
JwAZADIAMgAZABwAMgAsABkAMgAcACcAMgAcACwALwAEAAAALgEAAAUAAAAUAiRssKIEAAAAAgEB
AAQAAAACAQEABQAAABQCFBYGAwQAAAAuAQEAHwAAADIKFBYGAw0ABAAAAAAAYhNmG1R5cGU6IGlu
dGVnZXIAPQAvADIALAAcABkAHAAyABwALAAxACwAIQAEAAAALgEAAAUAAAAUAiRssKIEAAAAAgEB
AAQAAAACAQEABQAAABQCvBYGAwQAAAAuAQEANwAAADIKvBYGAx0ABAAAAAAAYhNmG0RlZmluZWQg
aW46IFRlcm1pbmF0aW9uU3RhdGUuAEgALAAhABwAMgAsADIAGQAcADIAHAAZAD0ALAAhAE4AHAAy
ACwAHAAcADIAMgA4ABwALAAcACwAGQAEAAAALgEAAAUAAAAUAiRssKIEAAAAAgEBAAQAAAACAQEA
BQAAABQCZBcGAwQAAAAuAQEANAAAADIKZBcGAxsABAAAAAAAYhNmG0NoYXJhY3RlcmlzdGljczog
cmVhZCBvbmx5OgBDADIALAAhACwALAAcACwAIQAcACcAHAAcACwAJwAcABkAIQAsACwAMgAZADIA
MgAcAC8AHAAEAAAALgEAAAUAAAAUAiRssKIEAAAAAgEBAAQAAAAtAQAABQAAABQCAAAAAAUAAAAT
AmYbAAAFAAAAEwJmG2ITBQAAABMCAABiEwUAAAATAgAAAAAFAAAAFAIBAAEABQAAABMCZRsBAAUA
AAATAmUbYRMFAAAAEwIBAGETBQAAABMCAQABAAUAAAAUAgIAAgAFAAAAEwJkGwIABQAAABMCZBtg
EwUAAAATAgIAYBMFAAAAEwICAAIABQAAABQCAwADAAUAAAATAmMbAwAFAAAAEwJjG18TBQAAABMC
AwBfEwUAAAATAgMAAwAFAAAAFAIEAAQABQAAABMCYhsEAAUAAAATAmIbXhMFAAAAEwIEAF4TBQAA
ABMCBAAEAAUAAAAUAgUABQAFAAAAEwJhGwUABQAAABMCYRtdEwUAAAATAgUAXRMFAAAAEwIFAAUA
BQAAABQCBgAGAAUAAAATAmAbBgAFAAAAEwJgG1wTBQAAABMCBgBcEwUAAAATAgYABgAFAAAAFAIH
AAcABQAAABMCXxsHAAUAAAATAl8bWxMFAAAAEwIHAFsTBQAAABMCBwAHAAUAAAAUAggACAAFAAAA
EwJeGwgABQAAABMCXhtaEwUAAAATAggAWhMFAAAAEwIIAAgABQAAABQCCQAJAAUAAAATAl0bCQAF
AAAAEwJdG1kTBQAAABMCCQBZEwUAAAATAgkACQAFAAAAFAIKAAoABQAAABMCXBsKAAUAAAATAlwb
WBMFAAAAEwIKAFgTBQAAABMCCgAKAAUAAAAUAgsACwAFAAAAEwJbGwsABQAAABMCWxtXEwUAAAAT
AgsAVxMFAAAAEwILAAsABQAAABQCDAAMAAUAAAATAlobDAAFAAAAEwJaG1YTBQAAABMCDABWEwUA
AAATAgwADAAFAAAAFAINAA0ABQAAABMCWRsNAAUAAAATAlkbVRMFAAAAEwINAFUTBQAAABMCDQAN
AAUAAAAUAg4ADgAFAAAAEwJYGw4ABQAAABMCWBtUEwUAAAATAg4AVBMFAAAAEwIOAA4ABQAAABQC
DwAPAAUAAAATAlcbDwAFAAAAEwJXG1MTBQAAABMCDwBTEwUAAAATAg8ADwAFAAAAFAIQABAABQAA
ABMCVhsQAAUAAAATAlYbUhMFAAAAEwIQAFITBQAAABMCEAAQAAUAAAAUAhEAEQAFAAAAEwJVGxEA
BQAAABMCVRtREwUAAAATAhEAURMFAAAAEwIRABEABQAAABQCEgASAAUAAAATAlQbEgAFAAAAEwJU
G1ATBQAAABMCEgBQEwUAAAATAhIAEgADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAAC
AAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOXCAArLPmu
aAQAACQEAAANAAAAAQAAAHAAAAAPAAAAeAAAAAQAAACEAAAABQAAAIwAAAAGAAAAlAAAABEAAACc
AAAAFwAAAKQAAAALAAAArAAAABAAAAC0AAAAEwAAALwAAAAWAAAAxAAAAA0AAADMAAAADAAAAOoD
AAACAAAA5AQAAB4AAAAEAAAASVRVAAMAAAAATAAAAwAAAAEAAAADAAAAAQAAAAMAAACfAAAAAwAA
AGoQCAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAAnAAAAQwAAAElUVSAtIFRl
bGVjb21tdW5pY2F0aW9uIFN0YW5kYXJkaXphdGlvbiBTZWN0b3IJVGVtcG9yYXJ5IERvY3VtZW50
IAANAAAASW50cm9kdWN0aW9uABIAAABQcm9wb3NlZCBQYWNrYWdlcwAQAAAARGlzcGxheSBQYWNr
YWdlAA8AAAAgICAgUHJvcGVydGllcwALAAAAICAgIEV2ZW50cwAMAAAAICAgIFNpZ25hbHMADwAA
ACAgICBTdGF0aXN0aWNzAA8AAAAgICAgUHJvY2VkdXJlcwAMAAAAS2V5IFBhY2thZ2UADwAAACAg
ICBQcm9wZXJ0aWVzAAsAAAAgICAgRXZlbnRzAAwAAAAgICAgU2lnbmFscwAPAAAAICAgIFN0YXRp
c3RpY3MADwAAACAgICBQcm9jZWR1cmVzAA8AAABLZXlwYWQgUGFja2FnZQAcAAAAICAgIEFkZGl0
aW9uYWwgUHJvcGVydGllczogABIAAABMYWJlbCBLZXkgUGFja2FnZQAPAAAAICAgIFByb3BlcnRp
ZXMADAAAACAgICBTaWduYWxzAA8AAAAgICAgUHJvY2VkdXJlcwAVAAAARnVuY3Rpb24gS2V5IFBh
Y2thZ2UADwAAACAgICBQcm9jZWR1cmVzABIAAABJbmRpY2F0b3IgUGFja2FnZQAPAAAAICAgIFBy
b3BlcnRpZXMACwAAACAgICBFdmVudHMADAAAACAgICBTaWduYWxzAA8AAAAgICAgUHJvY2VkdXJl
cwARAAAAU29mdCBLZXkgUGFja2FnZQAPAAAAICAgIFByb3BlcnRpZXMADAAAACAgICBTaWduYWxz
AA8AAAAgICAgUHJvY2VkdXJlcwAYAAAAQW5jaWxsYXJ5IElucHV0IFBhY2thZ2UADwAAACAgICBQ
cm9wZXJ0aWVzAAsAAAAgICAgRXZlbnRzAAwAAAAgICAgU2lnbmFscwAPAAAAICAgIFN0YXRpc3Rp
Y3MADwAAACAgICBQcm9jZWR1cmVzAAsAAABSZWZlcmVuY2VzAAwQAAAEAAAAHgAAAAYAAABUaXRs
ZQADAAAAAQAAAB4AAAAJAAAASGVhZGluZ3MAAwAAACYAAAAAAACYAAAAAwAAAAAAAAAgAAAAAQAA
ADYAAAACAAAAPgAAAAEAAAACAAAACgAAAF9QSURfR1VJRAACAAAA5AQAAEEAAABOAAAAewA0ADEA
QwBCAEEAMQA2ADAALQBGAEQANwA5AC0AMQAxAEQAMgAtAEEANgBEADcALQAwADAANgAwADkANwA4
AEEANgA0AEMAMAB9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAA
AAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAA
EwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAh
AAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwAAAAtAAAALgAAAC8A
AAAwAAAAMQAAADIAAAAzAAAANAAAADUAAAA2AAAANwAAADgAAAA5AAAAOgAAADsAAAD+////PQAA
AD4AAAA/AAAAQAAAAEEAAABCAAAAQwAAAEQAAABFAAAARgAAAEcAAABIAAAASQAAAEoAAABLAAAA
TAAAAE0AAABOAAAATwAAAFAAAABRAAAAUgAAAFMAAABUAAAAVQAAAFYAAABXAAAAWAAAAFkAAABa
AAAAWwAAAFwAAABdAAAAXgAAAF8AAABgAAAAYQAAAGIAAABjAAAAZAAAAP7///9mAAAAZwAAAGgA
AABpAAAAagAAAGsAAABsAAAAbQAAAG4AAABvAAAAcAAAAHEAAAByAAAAcwAAAHQAAAB1AAAAdgAA
AHcAAAD+////eQAAAHoAAAB7AAAAfAAAAH0AAAB+AAAAfwAAAP7////9/////f///4MAAAD+////
/v////7/////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////1IAbwBvAHQAIABFAG4AdABy
AHkAAAAAAAAAAAAAAAAAgMlNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB////////
//8DAAAABgkCAAAAAADAAAAAAAAARgAAAAAAIiKa2Xe/AcAFHY/1d78BhQAAAIAAAAAAAAAAMQBU
AGEAYgBsAGUAAAAAAAAAAAAAAAAAgQEAoDwAQAAsAEAAgMlNAAAAAAAAAAAAeAB4AAAAAAAAAAAA
BJEAAA4AAgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAA8
AAAAFFEAAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AACQxU0AhgAA8AAAAAABAAAAGgACAQUAAAD//////////wYAAAAHAAAACAAAAAkAAAAKAAAACwAA
AAwAAAANAAAADgAAAAAAAAA0dgAAEQAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQA
aQBvAG4AAACAyU0AAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBAgAAAAQAAAD/////AgAAADDKTQAA
AAAAAAAAAAEAAAAAAAAAAAAAABIAAAACAAAAZQAAAFAlAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQA
UwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAgBAAAAAAAADgAAgH/////////
//////8AAAAAAAAAAAAAAAAFAAAABAAAAAAAAAAAAAAA6QEAoDwAQAB4AAAAABAAAAAAAAABAEMA
bwBtAHAATwBiAGoAAAAASAAAAAAAAAAAAAAAAAAAAAAEzE0AAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAEgACAQEAAAAGAAAA/////w0AAAABAAAA//8GAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AABqAAAAAAAAAE8AYgBqAGUAYwB0AFAAbwBvAGwAAAAAAAAAAAA5AQCgPABAAHQ8GgIEzE0AAAAA
AAAAAAB4AHgAAAAAAAAAAAAWAAEA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAADABR2P
9Xe/AcAFHY/1d78BAAAAAB4AAAAQAAMAAAAAALDMTQCGAADwAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAACdAACgPABAAAAAAAD///////////////8AAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXQAAoCwAQAABAAAA/v//////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////wEA/v8DCgAA/////wYJAgAAAAAA
wAAAAAAAAEYYAAAATWljcm9zb2Z0IFdvcmQgRG9jdW1lbnQACgAAAE1TV29yZERvYwAQAAAAV29y
ZC5Eb2N1bWVudC44APQ5snEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

------_=_NextPart_000_01BFAACF.F8CC384E--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr 20 11:40:10 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13461
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 20 Apr 2000 11:40:10 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3F9A8CD0@standards.nortelnetworks.com>; Thu, 20 Apr 2000 11:33:28 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 9995 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 20 Apr 2000 11:31:46 -0400
Received: from fw7.usa.alcatel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.9D185600@standards.nortelnetworks.com>; Thu, 20 Apr 2000 11:21:46
          -0400
Received: (from uucp@localhost) by fw7.usa.alcatel.com (8.8.8+Sun/8.8.8) id
          KAA22507 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 20 Apr 2000
          10:26:48 -0500 (CDT)
Received: from <Chuong.Nguyen@usa.alcatel.com> (relay2.usa.alcatel.com
          [143.209.238.7]) by fw7 via smap (V2.1) id xma022310; Thu, 20 Apr 00
          10:25:46 -0500
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 KAA27686 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 20 Apr 2000 10:24:38
          -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 KAA17543 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 20
          Apr 2000 10:22:47 -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 KAA19398
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 20 Apr 2000 10:22:47
          -0500 (CDT)
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="------------1D5FF258BB119C5E6BD54398"
Message-ID:  <38FF20C5.89E514D1@usa.alcatel.com>
Date:         Thu, 20 Apr 2000 10:22:46 -0500
Reply-To: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Subject:      Error 433 behavior
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--------------1D5FF258BB119C5E6BD54398
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi All,

If MGC tries to add a physical terminaiton that is already in a Context,
what is the expected
response from MG.

For example,

Transaction=1 {Context=$ {Add = TDM123{....}}}

Reply=1{Context= ???? {Add = TDM123{errorDescriptor}}} or

Reply=1{Context = ??? {errorDescriptor}}     // Error 433: Termination
ID is already in a Context


What should the MG return for ContextID --  $ or the context Id that the
termination is in?

Should the Error Descriptor be in the command level or at the context
level?
I think it should be in the command level since it is the Add command
that result in an error.

Thanks
Chuong

--
  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 ****



--------------1D5FF258BB119C5E6BD54398
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi All,
<p>If MGC tries to add a physical terminaiton that is already in a Context,
what is the expected
<br>response from MG.
<p>For example,
<p>Transaction=1 {Context=$ {Add = TDM123{....}}}
<p>Reply=1{Context= ???? {Add = TDM123{errorDescriptor}}} or
<p>Reply=1{Context = ??? {errorDescriptor}}&nbsp;&nbsp;&nbsp;&nbsp; //
Error 433: Termination ID is already in a Context
<br>&nbsp;
<p>What should the MG return for ContextID --&nbsp; $ or the context Id
that the termination is in?
<p>Should the Error Descriptor be in the command level or at the context
level?
<br>I think it should be in the command level since it is the Add command
that result in an error.
<p>Thanks
<br>Chuong
<pre>--&nbsp;
&nbsp; Alcatel USA, Inc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Internet: Chuong.Nguyen@usa.alcatel.com
&nbsp; 1000 Coit Road Plano, Texas 75075&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Phone:&nbsp;&nbsp;&nbsp; (972) 519-4613
&nbsp; **** The opinions expressed are not those of Alcatel USA, Inc ****</pre>
&nbsp;</html>

--------------1D5FF258BB119C5E6BD54398--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Apr 21 05:56:05 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10986
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 21 Apr 2000 05:56:04 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.15C4EBA0@standards.nortelnetworks.com>; Fri, 21 Apr 2000 5:47:31 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 10626 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Apr 2000 05:46:28 -0400
Received: from auemlsrv.firewall.lucent.com (192.11.223.161) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.F0271940@standards.nortelnetworks.com>; Fri, 21 Apr 2000
          5:46:28 -0400
Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by
          auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id FAA01648
          for <MEGACO@standards.nortelnetworks.com>; Fri, 21 Apr 2000 05:52:24
          -0400 (EDT)
Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31])
          by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id
          FAA01635 for <MEGACO@standards.nortelnetworks.com>; Fri, 21 Apr 2000
          05:52:23 -0400 (EDT)
Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA11574; Fri,
          21 Apr 2000 11:52:22 +0200 (MET DST)
Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id
          LAA11502; Fri, 21 Apr 2000 11:52:11 +0200 (MET DST)
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
Original-CC: MEGACO@standards.nortelnetworks.com
References: <4FBEA8857476D311A03300204840E1CF6781C2@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <390024A7.82EB634E@lucent.com>
Date:         Fri, 21 Apr 2000 11:51:35 +0200
Reply-To: John Segers <jsegers@LUCENT.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: John Segers <jsegers@LUCENT.COM>
Organization: Lucent Technologies
Subject:      Re: Multiple streams per call,
X-To:         "Rosen, Brian" <brosen@FORE.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi,

Having been away from the list for a while, I've got some catching up to
do!  Although this thread is probably less urgent than some of the
others, this one being related to more advanced (future) functionality,
I'll jump in on this first.

Comparing Brian's proposal for the video translator to less exotic MG
devices that translate audio, I wonder why the extra ports are needed.
In the audio case, the required transcoding, e.g. from G.711 A-law to
G.723.1 is inferred from the Termination type/name and/or RTP payload
type.  No extra ports are introduced to model the translator resource.
Why can't it work the same for video?

Cheers,

John

"Rosen, Brian" wrote:
>
> You seem to have everything correct!
>
> You are worried about the video translator.  The problem statement
> was MG-A and MG-B did not have a common video encoding, so the MGC
> wanted to insert a translator to fix the problem.
>
> I think this is very reasonable to do, and I would model the
> translator as a set of pairs of terminations - The "A" side and
> the "B" side.  Trying to push these into a single context, to
> my way of thinking, is very weird.  Much cleaner to have two
> separate contexts.  I waffled over whether to represent the "ports"
> of the translator as physical terminations.  In reality, they could
> be, if the translator was some hard wired fixed function.  It is
> possible that it could just be a fancy DSP, and the number of translations
> it could do was a variable, determined by what
> translations were in use.  For example, it might be able to do
> 10 MPEG 1 to MPEG 2 translations, but only 3 MPEG2 to H.261 translations.
> In this case, it might be better to model the ports as ephemeral
> terminations.  I would still represent them as pairs of terminations,
> which would go in pairs of two termination contexts, the other
> termination being (for example) the RTP termination.
>
> To help your thinking, instead of calling those terminations Y and Z,
> call them XLate/A and XLate/B.  If the box could do more than one,
> maybe we would call them XL/1/A and XL/1/B, so you could talk about
> XL/4/A for example.  Then XL/1/A is in a context with RTP-A, and
> XL/1/B is in context with RTP-B.
>
> It is possible to have one termination that had two streams (the A
> stream and the B stream) and then the context would have 3 terminations, the
> translator, the "A" RTP and the "B" RTP.  Then you would use streamIDs to
> keep the streams straight (no need to use topology).
> This is one of the things I don't like about what we did, two ways to
> do the same thing, nothing but "taste" to decide which to use,
> guaranteed interoperability problems unless some package is standardized.
> Oh well.  Anyway, I think modeling the translator as having two
> terminations, an A termination and a B termination, each with one
> stream, is the best way to do it.
>
> In fact, you may have noticed that I used the same model for the
> weird function bridge a few emails back -- I think whenever we have
> odd-function devices, we should model the "ports" of the device
> as a termination implementing a specific package.  In this specific
> case the ports are symmetric (because the flows are send-receive),
> but in the general case, they may not be.
>
> Brian
>
> > -----Original Message-----
> > From: Chip Sharp [mailto:chsharp@cisco.com]
> > Sent: Friday, April 14, 2000 3:58 PM
> > To: Rosen, Brian; MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Multiple streams per call,
> >
> >
> > At 02:33 PM 4/14/00 -0400, Rosen, Brian wrote:
> >
> > ...snip...
> >
> > >Sure.  Look at it from the point of view of the MGs.  You have MG-A,
> > >MG-B and MG1.  MG-A has a termination with two streams, video and
> > >audio.  It is commanded by the MGC to set up a single context with
> > >the termination and two RTP connections, call them RTP-A-Audio and
> > >RTP-A-Video.  The address it assigns to RTP-A-Audio is MG-B.
> > >The address it assigns RTP-A-Video is MG1.
> > >Again, this is a single context, with the physical termination
> > >having two streams, and each of the RTP terminations having one
> > >stream each.
> >
> > I assume when you say "RTP connections" above, you mean "RTP
> > terminations"
> > since the word "connection" isn't allowed in megaco. (your
> > MGCP is showing
> > ;-) ).
> > I'm not sure what kind of termination you are talking about,
> > but I'll call
> > it X.
> >
> > In MG-A, Terminations X, RTP-A-Audio and RTP-A-Video all
> > belong to the same
> > context, say Context A.  Termination X has 2 streams assigned
> > to it.  One
> > stream contains the video, the other stream contains the
> > audio (both in
> > send-receive).  Termination RTP-A-Audio would be configured
> > with only the
> > Audio stream.  Termination RTP-A-Video would be configured
> > with only the
> > Video stream.
> >
> > Therefore the video stream goes to MG1 and the audio stream
> > goes to MGB, as
> > described.
> >
> >
> > >Look at MG1.  It has two terminations, with one stream each.  It
> > >is asked to set up two contexts, one with an RTP connecting to
> > >MG-A and the other with its RTP connection to MG-B.  That's
> > >two contexts, each with two terminations, with one stream in
> > >each of the contexts.
> >
> > I'm not sure what the two mystery terminations are again, but
> > I'll call
> > them Y and Z.
> >
> > Terminations Y and RTP-A belong to a context A and contain one stream.
> > Terminations Z and RTP-B belong to a context B and contain one stream.
> >
> > The video stream from MGA comes into context A via
> > Termination RTP-A and
> > ends up on Termination Y (and vice versa).
> >
> > Whatever is on termination Z is transmitted out RTP-B via
> > context B (and
> > vice versa).
> >  From the below, it seems video is connected to MG-B; however
> > there is no
> > context containing Terminations Z & Y to allow them to
> > communicate under
> > the control of megaco.  Therefore, I assume that some internal
> > implementation-specific mechanism connects terminations Y & Z
> > in order to
> > get the video from Context A into context B.
> > MG1 could just have 2 RTP terminations with one stream in one
> > context.  Of
> > course, H.248 forbids a termination from belonging to more than one
> > context, so you can't just create a context containing X & Y.
> >
> >
> >
> > >Of course, MG-B has a similar setup to MG-A -- it's audio connects
> > >to MG-A, the video connects to MG1.
> > >
> > >Now look at it from the MGC.  The "call" has 3 Megaco contexts.
> > >The MG-A to MG-B audio, the MG-A to MG1 video and the MG1 to MG-B
> > >video.
> >
> > Yes, but the MGC has no idea how the video gets from Termination X to
> > Termination Y in MG1.
> >
> > Thanks for the illustration.  I haven't really thought about
> > it in a while.
> >
> >
> > >I'm still not thrilled with the whole stream idea, but it does work.
> > >
> > >Brian
> >
> > http://www.netaid.org
> > --------------------------------------------------------------
> > -----------
> > Chip Sharp                 CTO Consulting Engineering
> > Cisco Systems
> > Reality - Love it or Leave it.
> > --------------------------------------------------------------
> > ----------
> >

--
John Segers                                  email: jsegers@lucent.com
Lucent Technologies                                        Room HE 306
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 Apr 21 09:10:19 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15278
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 21 Apr 2000 09:10:18 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7B2173E0@standards.nortelnetworks.com>; Fri, 21 Apr 2000 9:03:38 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 10692 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Apr 2000 09:01:41 -0400
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.D025BE70@standards.nortelnetworks.com>; Fri, 21 Apr 2000 8:51:41
          -0400
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id IAA26500; Fri, 21 Apr
          2000 08:57:41 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id IAA06169; Fri, 21 Apr
          2000 08:57:44 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <2MSF5BD9>; Fri, 21 Apr 2000 08:52:26 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF6781D9@whq-msgusr-02.fore.com>
Date:         Fri, 21 Apr 2000 08:57:40 -0400
Reply-To: "Rosen, Brian" <brosen@FORE.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <brosen@FORE.COM>
Subject:      Re: Multiple streams per call,
X-To:         John Segers <jsegers@lucent.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Yes, the translation MG, you could construct a context with
two RTP ports and use the SDP to imply translation.  The protocol would
allow that.

The problem is that it would work for things that are expressible in SDP,
but not for more general mechanisms.  For example, suppose you wanted
an MCU that did tiling.  I'd prefer that we use one mechanism for all of
these
kinds of problems.

And, yes Christian, SDP is shorthand for "SDP or Annex C"

Brian

> -----Original Message-----
> From: John Segers [mailto:jsegers@lucent.com]
> Sent: Friday, April 21, 2000 5:52 AM
> To: Rosen, Brian
> Cc: MEGACO@standards.nortelnetworks.com
> Subject: Re: Multiple streams per call,
>
>
> Hi,
>
> Having been away from the list for a while, I've got some
> catching up to
> do!  Although this thread is probably less urgent than some of the
> others, this one being related to more advanced (future)
> functionality,
> I'll jump in on this first.
>
> Comparing Brian's proposal for the video translator to less exotic MG
> devices that translate audio, I wonder why the extra ports
> are needed.
> In the audio case, the required transcoding, e.g. from G.711 A-law to
> G.723.1 is inferred from the Termination type/name and/or RTP payload
> type.  No extra ports are introduced to model the translator
> resource.
> Why can't it work the same for video?
>
> Cheers,
>
> John
>
> "Rosen, Brian" wrote:
> >
> > You seem to have everything correct!
> >
> > You are worried about the video translator.  The problem statement
> > was MG-A and MG-B did not have a common video encoding, so the MGC
> > wanted to insert a translator to fix the problem.
> >
> > I think this is very reasonable to do, and I would model the
> > translator as a set of pairs of terminations - The "A" side and
> > the "B" side.  Trying to push these into a single context, to
> > my way of thinking, is very weird.  Much cleaner to have two
> > separate contexts.  I waffled over whether to represent the "ports"
> > of the translator as physical terminations.  In reality, they could
> > be, if the translator was some hard wired fixed function.  It is
> > possible that it could just be a fancy DSP, and the number
> of translations
> > it could do was a variable, determined by what
> > translations were in use.  For example, it might be able to do
> > 10 MPEG 1 to MPEG 2 translations, but only 3 MPEG2 to H.261
> translations.
> > In this case, it might be better to model the ports as ephemeral
> > terminations.  I would still represent them as pairs of
> terminations,
> > which would go in pairs of two termination contexts, the other
> > termination being (for example) the RTP termination.
> >
> > To help your thinking, instead of calling those
> terminations Y and Z,
> > call them XLate/A and XLate/B.  If the box could do more than one,
> > maybe we would call them XL/1/A and XL/1/B, so you could talk about
> > XL/4/A for example.  Then XL/1/A is in a context with RTP-A, and
> > XL/1/B is in context with RTP-B.
> >
> > It is possible to have one termination that had two streams (the A
> > stream and the B stream) and then the context would have 3
> terminations, the
> > translator, the "A" RTP and the "B" RTP.  Then you would
> use streamIDs to
> > keep the streams straight (no need to use topology).
> > This is one of the things I don't like about what we did,
> two ways to
> > do the same thing, nothing but "taste" to decide which to use,
> > guaranteed interoperability problems unless some package is
> standardized.
> > Oh well.  Anyway, I think modeling the translator as having two
> > terminations, an A termination and a B termination, each with one
> > stream, is the best way to do it.
> >
> > In fact, you may have noticed that I used the same model for the
> > weird function bridge a few emails back -- I think whenever we have
> > odd-function devices, we should model the "ports" of the device
> > as a termination implementing a specific package.  In this specific
> > case the ports are symmetric (because the flows are send-receive),
> > but in the general case, they may not be.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Chip Sharp [mailto:chsharp@cisco.com]
> > > Sent: Friday, April 14, 2000 3:58 PM
> > > To: Rosen, Brian; MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Multiple streams per call,
> > >
> > >
> > > At 02:33 PM 4/14/00 -0400, Rosen, Brian wrote:
> > >
> > > ...snip...
> > >
> > > >Sure.  Look at it from the point of view of the MGs.
> You have MG-A,
> > > >MG-B and MG1.  MG-A has a termination with two streams, video and
> > > >audio.  It is commanded by the MGC to set up a single
> context with
> > > >the termination and two RTP connections, call them
> RTP-A-Audio and
> > > >RTP-A-Video.  The address it assigns to RTP-A-Audio is MG-B.
> > > >The address it assigns RTP-A-Video is MG1.
> > > >Again, this is a single context, with the physical termination
> > > >having two streams, and each of the RTP terminations having one
> > > >stream each.
> > >
> > > I assume when you say "RTP connections" above, you mean "RTP
> > > terminations"
> > > since the word "connection" isn't allowed in megaco. (your
> > > MGCP is showing
> > > ;-) ).
> > > I'm not sure what kind of termination you are talking about,
> > > but I'll call
> > > it X.
> > >
> > > In MG-A, Terminations X, RTP-A-Audio and RTP-A-Video all
> > > belong to the same
> > > context, say Context A.  Termination X has 2 streams assigned
> > > to it.  One
> > > stream contains the video, the other stream contains the
> > > audio (both in
> > > send-receive).  Termination RTP-A-Audio would be configured
> > > with only the
> > > Audio stream.  Termination RTP-A-Video would be configured
> > > with only the
> > > Video stream.
> > >
> > > Therefore the video stream goes to MG1 and the audio stream
> > > goes to MGB, as
> > > described.
> > >
> > >
> > > >Look at MG1.  It has two terminations, with one stream each.  It
> > > >is asked to set up two contexts, one with an RTP connecting to
> > > >MG-A and the other with its RTP connection to MG-B.  That's
> > > >two contexts, each with two terminations, with one stream in
> > > >each of the contexts.
> > >
> > > I'm not sure what the two mystery terminations are again, but
> > > I'll call
> > > them Y and Z.
> > >
> > > Terminations Y and RTP-A belong to a context A and
> contain one stream.
> > > Terminations Z and RTP-B belong to a context B and
> contain one stream.
> > >
> > > The video stream from MGA comes into context A via
> > > Termination RTP-A and
> > > ends up on Termination Y (and vice versa).
> > >
> > > Whatever is on termination Z is transmitted out RTP-B via
> > > context B (and
> > > vice versa).
> > >  From the below, it seems video is connected to MG-B; however
> > > there is no
> > > context containing Terminations Z & Y to allow them to
> > > communicate under
> > > the control of megaco.  Therefore, I assume that some internal
> > > implementation-specific mechanism connects terminations Y & Z
> > > in order to
> > > get the video from Context A into context B.
> > > MG1 could just have 2 RTP terminations with one stream in one
> > > context.  Of
> > > course, H.248 forbids a termination from belonging to
> more than one
> > > context, so you can't just create a context containing X & Y.
> > >
> > >
> > >
> > > >Of course, MG-B has a similar setup to MG-A -- it's
> audio connects
> > > >to MG-A, the video connects to MG1.
> > > >
> > > >Now look at it from the MGC.  The "call" has 3 Megaco contexts.
> > > >The MG-A to MG-B audio, the MG-A to MG1 video and the MG1 to MG-B
> > > >video.
> > >
> > > Yes, but the MGC has no idea how the video gets from
> Termination X to
> > > Termination Y in MG1.
> > >
> > > Thanks for the illustration.  I haven't really thought about
> > > it in a while.
> > >
> > >
> > > >I'm still not thrilled with the whole stream idea, but
> it does work.
> > > >
> > > >Brian
> > >
> > > http://www.netaid.org
> > > --------------------------------------------------------------
> > > -----------
> > > Chip Sharp                 CTO Consulting Engineering
> > > Cisco Systems
> > > Reality - Love it or Leave it.
> > > --------------------------------------------------------------
> > > ----------
> > >
>
> --
> John Segers                                  email: jsegers@lucent.com
> Lucent Technologies                                        Room HE 306
> 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 Apr 21 09:38:15 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16142
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 21 Apr 2000 09:38:15 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.66232AC0@standards.nortelnetworks.com>; Fri, 21 Apr 2000 9:31:40 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 10722 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Apr 2000 09:30:03 -0400
Received: from smtprtp1.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.2C5E0B20@standards.nortelnetworks.com>; Fri, 21 Apr 2000 9:30:03
          -0400
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          smtprtp1.ntcom.nortel.net; Fri, 21 Apr 2000 09:35:45 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <27B9N4WJ>; Fri, 21 Apr 2000 09:35:45 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B6D7@zcard00g.ca.nortel.com>
Date:         Fri, 21 Apr 2000 09:35:45 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Multiple streams per call,
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

My view of something like tiling is that we need a per-stream property to
express mixing method.  I didn't push this last summer because it was clear
that it would have to be designed by specialists in the area, and I figured
they should be the ones to step up to the plate when they are serious about
building product using Megaco/H.248.

> -----Original Message-----
> From: Rosen, Brian [SMTP:brosen@FORE.COM]
> Sent: Friday, April 21, 2000 8:58 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: Multiple streams per call,
>
> Yes, the translation MG, you could construct a context with
> two RTP ports and use the SDP to imply translation.  The protocol would
> allow that.
>
> The problem is that it would work for things that are expressible in SDP,
> but not for more general mechanisms.  For example, suppose you wanted
> an MCU that did tiling.  I'd prefer that we use one mechanism for all of
> these
> kinds of problems.
>
> And, yes Christian, SDP is shorthand for "SDP or Annex C"
>
> Brian
>
> > -----Original Message-----
> > From: John Segers [mailto:jsegers@lucent.com]
> > Sent: Friday, April 21, 2000 5:52 AM
> > To: Rosen, Brian
> > Cc: MEGACO@standards.nortelnetworks.com
> > Subject: Re: Multiple streams per call,
> >
> >
> > Hi,
> >
> > Having been away from the list for a while, I've got some
> > catching up to
> > do!  Although this thread is probably less urgent than some of the
> > others, this one being related to more advanced (future)
> > functionality,
> > I'll jump in on this first.
> >
> > Comparing Brian's proposal for the video translator to less exotic MG
> > devices that translate audio, I wonder why the extra ports
> > are needed.
> > In the audio case, the required transcoding, e.g. from G.711 A-law to
> > G.723.1 is inferred from the Termination type/name and/or RTP payload
> > type.  No extra ports are introduced to model the translator
> > resource.
> > Why can't it work the same for video?
> >
> > Cheers,
> >
> > John
> >
> > "Rosen, Brian" wrote:
> > >
> > > You seem to have everything correct!
> > >
> > > You are worried about the video translator.  The problem statement
> > > was MG-A and MG-B did not have a common video encoding, so the MGC
> > > wanted to insert a translator to fix the problem.
> > >
> > > I think this is very reasonable to do, and I would model the
> > > translator as a set of pairs of terminations - The "A" side and
> > > the "B" side.  Trying to push these into a single context, to
> > > my way of thinking, is very weird.  Much cleaner to have two
> > > separate contexts.  I waffled over whether to represent the "ports"
> > > of the translator as physical terminations.  In reality, they could
> > > be, if the translator was some hard wired fixed function.  It is
> > > possible that it could just be a fancy DSP, and the number
> > of translations
> > > it could do was a variable, determined by what
> > > translations were in use.  For example, it might be able to do
> > > 10 MPEG 1 to MPEG 2 translations, but only 3 MPEG2 to H.261
> > translations.
> > > In this case, it might be better to model the ports as ephemeral
> > > terminations.  I would still represent them as pairs of
> > terminations,
> > > which would go in pairs of two termination contexts, the other
> > > termination being (for example) the RTP termination.
> > >
> > > To help your thinking, instead of calling those
> > terminations Y and Z,
> > > call them XLate/A and XLate/B.  If the box could do more than one,
> > > maybe we would call them XL/1/A and XL/1/B, so you could talk about
> > > XL/4/A for example.  Then XL/1/A is in a context with RTP-A, and
> > > XL/1/B is in context with RTP-B.
> > >
> > > It is possible to have one termination that had two streams (the A
> > > stream and the B stream) and then the context would have 3
> > terminations, the
> > > translator, the "A" RTP and the "B" RTP.  Then you would
> > use streamIDs to
> > > keep the streams straight (no need to use topology).
> > > This is one of the things I don't like about what we did,
> > two ways to
> > > do the same thing, nothing but "taste" to decide which to use,
> > > guaranteed interoperability problems unless some package is
> > standardized.
> > > Oh well.  Anyway, I think modeling the translator as having two
> > > terminations, an A termination and a B termination, each with one
> > > stream, is the best way to do it.
> > >
> > > In fact, you may have noticed that I used the same model for the
> > > weird function bridge a few emails back -- I think whenever we have
> > > odd-function devices, we should model the "ports" of the device
> > > as a termination implementing a specific package.  In this specific
> > > case the ports are symmetric (because the flows are send-receive),
> > > but in the general case, they may not be.
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Chip Sharp [mailto:chsharp@cisco.com]
> > > > Sent: Friday, April 14, 2000 3:58 PM
> > > > To: Rosen, Brian; MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: Re: Multiple streams per call,
> > > >
> > > >
> > > > At 02:33 PM 4/14/00 -0400, Rosen, Brian wrote:
> > > >
> > > > ...snip...
> > > >
> > > > >Sure.  Look at it from the point of view of the MGs.
> > You have MG-A,
> > > > >MG-B and MG1.  MG-A has a termination with two streams, video and
> > > > >audio.  It is commanded by the MGC to set up a single
> > context with
> > > > >the termination and two RTP connections, call them
> > RTP-A-Audio and
> > > > >RTP-A-Video.  The address it assigns to RTP-A-Audio is MG-B.
> > > > >The address it assigns RTP-A-Video is MG1.
> > > > >Again, this is a single context, with the physical termination
> > > > >having two streams, and each of the RTP terminations having one
> > > > >stream each.
> > > >
> > > > I assume when you say "RTP connections" above, you mean "RTP
> > > > terminations"
> > > > since the word "connection" isn't allowed in megaco. (your
> > > > MGCP is showing
> > > > ;-) ).
> > > > I'm not sure what kind of termination you are talking about,
> > > > but I'll call
> > > > it X.
> > > >
> > > > In MG-A, Terminations X, RTP-A-Audio and RTP-A-Video all
> > > > belong to the same
> > > > context, say Context A.  Termination X has 2 streams assigned
> > > > to it.  One
> > > > stream contains the video, the other stream contains the
> > > > audio (both in
> > > > send-receive).  Termination RTP-A-Audio would be configured
> > > > with only the
> > > > Audio stream.  Termination RTP-A-Video would be configured
> > > > with only the
> > > > Video stream.
> > > >
> > > > Therefore the video stream goes to MG1 and the audio stream
> > > > goes to MGB, as
> > > > described.
> > > >
> > > >
> > > > >Look at MG1.  It has two terminations, with one stream each.  It
> > > > >is asked to set up two contexts, one with an RTP connecting to
> > > > >MG-A and the other with its RTP connection to MG-B.  That's
> > > > >two contexts, each with two terminations, with one stream in
> > > > >each of the contexts.
> > > >
> > > > I'm not sure what the two mystery terminations are again, but
> > > > I'll call
> > > > them Y and Z.
> > > >
> > > > Terminations Y and RTP-A belong to a context A and
> > contain one stream.
> > > > Terminations Z and RTP-B belong to a context B and
> > contain one stream.
> > > >
> > > > The video stream from MGA comes into context A via
> > > > Termination RTP-A and
> > > > ends up on Termination Y (and vice versa).
> > > >
> > > > Whatever is on termination Z is transmitted out RTP-B via
> > > > context B (and
> > > > vice versa).
> > > >  From the below, it seems video is connected to MG-B; however
> > > > there is no
> > > > context containing Terminations Z & Y to allow them to
> > > > communicate under
> > > > the control of megaco.  Therefore, I assume that some internal
> > > > implementation-specific mechanism connects terminations Y & Z
> > > > in order to
> > > > get the video from Context A into context B.
> > > > MG1 could just have 2 RTP terminations with one stream in one
> > > > context.  Of
> > > > course, H.248 forbids a termination from belonging to
> > more than one
> > > > context, so you can't just create a context containing X & Y.
> > > >
> > > >
> > > >
> > > > >Of course, MG-B has a similar setup to MG-A -- it's
> > audio connects
> > > > >to MG-A, the video connects to MG1.
> > > > >
> > > > >Now look at it from the MGC.  The "call" has 3 Megaco contexts.
> > > > >The MG-A to MG-B audio, the MG-A to MG1 video and the MG1 to MG-B
> > > > >video.
> > > >
> > > > Yes, but the MGC has no idea how the video gets from
> > Termination X to
> > > > Termination Y in MG1.
> > > >
> > > > Thanks for the illustration.  I haven't really thought about
> > > > it in a while.
> > > >
> > > >
> > > > >I'm still not thrilled with the whole stream idea, but
> > it does work.
> > > > >
> > > > >Brian
> > > >
> > > > http://www.netaid.org
> > > > --------------------------------------------------------------
> > > > -----------
> > > > Chip Sharp                 CTO Consulting Engineering
> > > > Cisco Systems
> > > > Reality - Love it or Leave it.
> > > > --------------------------------------------------------------
> > > > ----------
> > > >
> >
> > --
> > John Segers                                  email: jsegers@lucent.com
> > Lucent Technologies                                        Room HE 306
> > 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  Sun Apr 23 22:26:09 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13385
	for <megaco-archive@LISTS.IETF.ORG>; Sun, 23 Apr 2000 22:26:09 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EF23E540@standards.nortelnetworks.com>; 23 Apr 2000 22:19:04 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11509 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 23 Apr 2000 22:17:27 -0400
Received: from fw7.usa.alcatel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.4F898C20@standards.nortelnetworks.com>; 23 Apr 2000 22:07:27 -0400
Received: (from uucp@localhost) by fw7.usa.alcatel.com (8.8.8+Sun/8.8.8) id
          VAA00654 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Sun, 23 Apr 2000
          21:12:36 -0500 (CDT)
Received: from <Chuong.Nguyen@usa.alcatel.com> (relay2.usa.alcatel.com
          [143.209.238.7]) by fw7 via smap (V2.1) id xma000648; Sun, 23 Apr 00
          21:11:54 -0500
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 VAA17543 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Sun, 23 Apr 2000 21:10:50
          -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 VAA15568 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Sun, 23
          Apr 2000 21:08:43 -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 VAA26122
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Sun, 23 Apr 2000 21:08:42
          -0500 (CDT)
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3903ACAA.283764E4@usa.alcatel.com>
Date:         Sun, 23 Apr 2000 21:08:42 -0500
Reply-To: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Subject:      Event Request ID
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi All,

Is event Request ID scoped to a termination or context or gateway?

In general is event detected on a gateway basis or context basis or
termination basis?


Thanks
Chuong


--
  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 Apr 24 09:33:24 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03364
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 24 Apr 2000 09:33:24 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.308129F0@standards.nortelnetworks.com>; Mon, 24 Apr 2000 9:26:37 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11904 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Apr 2000 09:25:09 -0400
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.FC0FDEF0@standards.nortelnetworks.com>; Mon, 24 Apr 2000
          9:25:09 -0400
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Mon, 24 Apr 2000 08:31:05 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <269WV4Q7>; Mon, 24 Apr 2000 08:30:57 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFADF1.50D29AAA"
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B6DD@zcard00g.ca.nortel.com>
Date:         Mon, 24 Apr 2000 08:30:54 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Event Request ID
X-To:         Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
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_01BFADF1.50D29AAA
Content-Type: text/plain

At the moment, the requirement is to scope to termination.  At some point in
the future one could imagine context-level events, but that is not a present
requirement.

> -----Original Message-----
> From: Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]
> Sent: Sunday, April 23, 2000 10:09 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Event Request ID
>
> Hi All,
>
> Is event Request ID scoped to a termination or context or gateway?
>
> In general is event detected on a gateway basis or context basis or
> termination basis?
>
>
> Thanks
> Chuong
>
>
> --
>   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 ****

------_=_NextPart_001_01BFADF1.50D29AAA
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: Event Request ID</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">At the moment, the =
requirement is to scope to termination.&nbsp; At some point in the =
future one could imagine context-level events, but that is not a =
present requirement.</FONT></P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Chuong Nguyen =
[SMTP:Chuong.Nguyen@USA.ALCATEL.COM]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Sunday, April 23, 2000 10:09 PM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Event Request ID</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi All,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Is event Request ID scoped to a =
termination or context or gateway?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In general is event detected on a =
gateway basis or context basis or</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">termination basis?</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Chuong</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">--</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; Alcatel USA, =
Inc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; Internet: Chuong.Nguyen@usa.alcatel.com</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; 1000 Coit Road Plano, Texas =
75075&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Phone:&nbsp;&nbsp;&nbsp; (972) 519-4613</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; **** The opinions expressed =
are not those of Alcatel USA, Inc ****</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFADF1.50D29AAA--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Apr 24 09:45:18 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03652
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 24 Apr 2000 09:45:18 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DECDB810@standards.nortelnetworks.com>; Mon, 24 Apr 2000 9:38:39 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11925 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Apr 2000 09:37:24 -0400
Received: from smtprtp.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.B2768DA0@standards.nortelnetworks.com>; Mon, 24 Apr 2000 9:37:24
          -0400
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          smtprtp.ntcom.nortel.net; Mon, 24 Apr 2000 09:38:11 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <27B93L56>; Mon, 24 Apr 2000 09:38:12 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B6DE@zcard00g.ca.nortel.com>
Date:         Mon, 24 Apr 2000 09:37:57 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      FW: SDP issues
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Please note this ruling from current MMUSIC discussion.

> -----Original Message-----
> From: Mark Handley [SMTP:mjh@aciri.org]
> Sent: Saturday, April 22, 2000 10:13 PM
> To:   Henning Schulzrinne
> Cc:   Jeff Ayars; Henning Schulzrinne; confctrl@ISI.EDU;
> sip@lists.bell-labs.com
> Subject:      Re: SDP issues
>
>
> >Any half-way robust implementation needs to be able to deal with missing
> >s= and with s= followed by nothing. Might as well get the benefit of
> >allowing it officially.
>
> Whatever you might wish the SDP spec would say, it's fairly clear on
> this issue: if there's no s= line, you should treat the SDP as
> corrupted and act accordingly.  If you send SDP without the s= line,
> you are definitely not compliant with RFC 2327 and shouldn't expect
> your message to be accepted.
>
> Changing the spec at this stage would introduce backward compatibility
> issues, so should not be done lightly.  The more incompatible changes
> we introduce, the less likely we are to be able to move SDP (and hence
> SIP and RTSP) to Draft Standard without cycling it at Proposed
> Standard first.
>
> Cheers,
>       Mark
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Apr 24 09:47:41 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03732
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 24 Apr 2000 09:47:40 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.26F65070@standards.nortelnetworks.com>; Mon, 24 Apr 2000 9:40:40 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11935 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Apr 2000 09:38:58 -0400
Received: from smtprich.nortel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.EA1C28A0@standards.nortelnetworks.com>; Mon, 24 Apr 2000 9:38:58
          -0400
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprich.nortel.com; Mon, 24 Apr 2000 08:39:59 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <269WV45W>; Mon, 24 Apr 2000 08:38:49 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B6DF@zcard00g.ca.nortel.com>
Date:         Mon, 24 Apr 2000 08:38:49 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      FW: [SIP] Re: SDP issues
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Another point affecting case sensitivity of the Local and Remote descriptors
when using SDP.

> -----Original Message-----
> From: Jonathan Rosenberg [SMTP:jdrosen@dynamicsoft.com]
> Sent: Sunday, April 23, 2000 4:58 PM
> To:   Henning Schulzrinne
> Cc:   confctrl@ISI.EDU; sip@lists.bell-labs.com
> Subject:      [SIP] Re: SDP issues
>
> There was another issue raised; SDP says very little overall about case
> sensitivity. The type (m=, s=, etc.) is case sensitive, and the values
> depend on the type. The only types which discuss case sensitivity are:
>
> 1. t and r, which indicate that the d,h,m,s (days, hour, minutes,
> seconds) characters are case sensitive.
> 2. a=charset:, which uses case insensitive matching for the character
> set.
>
> So, we also agreed that in the spirit of SDP, all other values are CASE
> SENSITIVE unless otherwise noted. This includes the encoding name
> Henning mentions below, which, along with the character set, represent
> the only two case insensitive matches in SDP (I believe).
>
> -Jonathan R.
>
> Henning Schulzrinne wrote:
> >
> > During the SIP bake-off, two SDP-related issues were raised:
> >
> > Currently, s= is defined as text, which is 1*(some set of bytes), i.e.,
> > at least one character. It doesn't seem necessary to enforce that s=
> > have anything in them (like a space). Other textual Internet protocols
> > seem to be fine with having empty unformatted fields (like Subject: in
> > email).
> >
> > Secondly, the rtpmap description does not specify whether the 'encoding
> > name' is case-sensitive or not. Since it's also used as a media type and
> > media types are case-insensitive (RFC 2616, 3.7), it probably makes
> > sense to make them CI in SDP as well.
> >
> > Comments are appreciated.
> >
> > Henning
>
> --
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (732) 741-4778
> http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
> http://www.dynamicsoft.com
>
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Apr 24 10:48:34 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05254
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 24 Apr 2000 10:48:34 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B0118570@standards.nortelnetworks.com>; Mon, 24 Apr 2000 10:41:46 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11995 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Apr 2000 10:40:07 -0400
Received: from mailcity.com (209.1.236.7) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.0F4F9C40@standards.nortelnetworks.com>; Mon, 24 Apr 2000 10:30:07
          -0400
Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Mon Apr 24 07:35:56
          2000
Mime-Version: 1.0
X-Sent-Mail: off
X-Mailer: MailCity Service
X-Sender-Ip: 207.236.91.222
Content-Type: text/plain; charset=us-ascii
Content-Language: en
Content-Transfer-Encoding: 7bit
Message-ID:  <EMBKFMPOBEJMAAAA@mailcity.com>
Date:         Mon, 24 Apr 2000 07:35:56 -0700
Reply-To: himanshoo-saxena@mailcity.com
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Himanshoo SaK Saxena <himanshoo-saxena@mailcity.com>
Organization: MailCity  (http://www.mailcity.lycos.com:80)
Subject:      events
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello,
I am part of a team that is implementing MF package for MGCP.I don't know where I should submit my querries since there is no list for  available for MGCP. If there is one pls. let me know.
My querry is related to events in MGCP. A number of events are grouped in package. I thought the idea of package was just ot group a number of similar events in an entity, known as package. But there are a few events which exist in more than one package. To elaborate my question let me give an example. There could be an event 'A' which exists is packages X & Y. So endpoint 'ep1', which supports package X of MGCP, will have to interpret this hardware event as X/A, while for endpoint 'ep2' , supporting package Y , the same signal (event ) on hardware shall be interpretted as Y/A.
I don't understand the reason of keeping the same event in two packages . I think grouping of events in packages should be based on similarity in events. But it seems some packages have been defined based on the application. For example 'handset emulation package' has some events that are common with 'line package'. Defining a package like this causes confusion since now, if I were to identify a hardware event, I will have to see if my endpoint supports 'handset emulation package' or 'line package'.
My point is, Isn't it wrong to have common events in packages. A package (and the events taht it contains), should be added only if there is need for extra event. In case somebody wants to support events for a new type of endpoint then instead of defining a new package for that end point, which contains some events that are already defined in some other package , won't it make sense to add only the new events to specification. This way interpretation of event is not dependent on the type of endpoint.

Thanks & Regards
Himanshoo


Send FREE April Fool's Greetings to your friends!
http://www.whowhere.lycos.com/redirects/American_Greetings.rdct


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Apr 24 11:57:42 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06902
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 24 Apr 2000 11:57:42 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.57AB2A80@standards.nortelnetworks.com>; Mon, 24 Apr 2000 11:50:52 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 12064 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Apr 2000 11:50:05 -0400
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.D5E56250@standards.nortelnetworks.com>; Mon, 24 Apr 2000 11:40:05
          -0400
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id LAA22430; Mon, 24 Apr
          2000 11:46:15 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id LAA04357; Mon, 24 Apr
          2000 11:45:52 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <2MSF5Y90>; Mon, 24 Apr 2000 11:40:30 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFAE03.6B79B91C"
Message-ID:  <4FBEA8857476D311A03300204840E1CF6781E0@whq-msgusr-02.fore.com>
Date:         Mon, 24 Apr 2000 11:45:50 -0400
Reply-To: "Rosen, Brian" <brosen@FORE.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <brosen@FORE.COM>
Subject:      Re: Error 433 behavior
X-To:         Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
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_01BFAE03.6B79B91C
Content-Type: text/plain;
        charset="iso-8859-1"

Transaction=1 {Context=$ {Add = TDM123{....}}}


Reply=1{Context= ???? {Add = TDM123{errorDescriptor}}} or


Reply=1{Context = ??? {errorDescriptor}}     // Error 433: Termination ID is
already in a Context

I believe it should be the former.  In general, you want the most
specificity in error returns.  In this case, we clearly have no syntax
issues in determining that it is the Add which fails, for a specific reason.
Thus I think you get the error on the add.


What should the MG return for ContextID --  $ or the context Id that the
termination is in?


You get "Choose"


Should the Error Descriptor be in the command level or at the context level?

I think it should be in the command level since it is the Add command that
result in an error.

I agree, at the command level

 Brian


------_=_NextPart_001_01BFAE03.6B79B91C
Content-Type: text/html;
        charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.2919.6307" name=GENERATOR></HEAD>
<BODY>
<BLOCKQUOTE
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">
  <P>Transaction=1 {Context=$ {Add = TDM123{....}}}
  <P>Reply=1{Context= ???? {Add = TDM123{errorDescriptor}}} or
  <P>Reply=1{Context = ??? {errorDescriptor}}&nbsp;&nbsp;&nbsp;&nbsp; // Error
  433: Termination ID is already in a Context&nbsp;<SPAN
  class=270455514-24042000><FONT color=#0000ff face=Arial
  size=2>&nbsp;</FONT></SPAN></P>
  <P><FONT color=#0000ff><SPAN class=270455514-24042000><FONT size=2><FONT
  face=Arial>I believe it should be the former.&nbsp; In general, you want the
  most specif</FONT><FONT face=Arial>icity in error</FONT></FONT></SPAN><SPAN
  class=270455514-24042000><FONT size=2><FONT face=Arial> returns.&nbsp; In this
  case, we clearly h</FONT><FONT face=Arial>ave no synta</FONT></FONT><FONT
  face=Arial size=2>x issues i</FONT><FONT face=Arial size=2>n determining that
  it is the Add which</FONT></SPAN></FONT><SPAN class=270455514-24042000><FONT
  color=#0000ff><FONT size=2><FONT face=Arial> fails, for a specific
  reason.&nbsp; Thus I think you get the error o</FONT><FONT face=Arial>n the
  add.</FONT></FONT></FONT>&nbsp;</SPAN><BR>&nbsp; </P>
  <P>What should the MG return for ContextID --&nbsp; $ or the context Id that
  the termination is in?&nbsp;<FONT color=#0000ff face=Arial size=2><SPAN
  class=270455514-24042000>&nbsp;</SPAN></FONT>
  <P><FONT color=#0000ff face=Arial size=2><SPAN class=270455514-24042000>You
  get "Choose"&nbsp;</SPAN></FONT>
  <P>Should the Error Descriptor be in the command level or at the context
  level? <BR>I think it should be in the command level since it is the Add
  command that result in an error.&nbsp;<FONT color=#0000ff face=Arial
  size=2><SPAN class=270455514-24042000>&nbsp;</SPAN></FONT></P>
  <P><FONT color=#0000ff face=Arial size=2><SPAN class=270455514-24042000>I
  agree, at the command level&nbsp;</SPAN></FONT></P>
  <P><FONT color=#0000ff face=Arial size=2><SPAN
  class=270455514-24042000>&nbsp;Brian&nbsp;</SPAN></FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01BFAE03.6B79B91C--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Apr 24 12:04:46 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07310
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 24 Apr 2000 12:04:46 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.534D5930@standards.nortelnetworks.com>; Mon, 24 Apr 2000 11:57:55 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 12065 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Apr 2000 11:56:44 -0400
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.C33BE600@standards.nortelnetworks.com>; Mon, 24 Apr 2000 11:46:43
          -0400
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id LAA23405; Mon, 24 Apr
          2000 11:52:53 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id LAA06139; Mon, 24 Apr
          2000 11:52:54 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <2MSF5ZF3>; Mon, 24 Apr 2000 11:47: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:  <4FBEA8857476D311A03300204840E1CF6781E2@whq-msgusr-02.fore.com>
Date:         Mon, 24 Apr 2000 11:52:44 -0400
Reply-To: "Rosen, Brian" <brosen@FORE.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <brosen@FORE.COM>
Subject:      Re: Multiple streams per call,
X-To:         Tom-PT Taylor <taylor@nortelnetworks.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is beyond the current discussion.  The question is, in general,
how do we model devices that are "different".  In the case cited,
media translation, we could model it as a two termination context,
with the RTP flows, specified by media descriptors, describing the
two sides, and an implicit translation in between.  This certainly
works, and is pretty elegant.

The problem is that it doesn't work for all kinds of devices,
and I wondered if we should model them in a more uniform way.  I
suggested a set of two termination contexts with an "internal"
termination that can have characteristics ascribed to it by a
set of packages implemented on it, and an RTP termination that
had the external flow on it.  This would also work for the translator,
but requires more terminations and more contexts, and thus is
somewhat less elegant.  It too would work, and has the advantage of
being able to be used for a much wider range of applications.

Brian

Brian

> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> Sent: Friday, April 21, 2000 9:36 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: Multiple streams per call,
>
>
> My view of something like tiling is that we need a per-stream
> property to
> express mixing method.  I didn't push this last summer
> because it was clear
> that it would have to be designed by specialists in the area,
> and I figured
> they should be the ones to step up to the plate when they are
> serious about
> building product using Megaco/H.248.
>
> > -----Original Message-----
> > From: Rosen, Brian [SMTP:brosen@FORE.COM]
> > Sent: Friday, April 21, 2000 8:58 AM
> > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject:      Re: Multiple streams per call,
> >
> > Yes, the translation MG, you could construct a context with
> > two RTP ports and use the SDP to imply translation.  The
> protocol would
> > allow that.
> >
> > The problem is that it would work for things that are
> expressible in SDP,
> > but not for more general mechanisms.  For example, suppose
> you wanted
> > an MCU that did tiling.  I'd prefer that we use one
> mechanism for all of
> > these
> > kinds of problems.
> >
> > And, yes Christian, SDP is shorthand for "SDP or Annex C"
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: John Segers [mailto:jsegers@lucent.com]
> > > Sent: Friday, April 21, 2000 5:52 AM
> > > To: Rosen, Brian
> > > Cc: MEGACO@standards.nortelnetworks.com
> > > Subject: Re: Multiple streams per call,
> > >
> > >
> > > Hi,
> > >
> > > Having been away from the list for a while, I've got some
> > > catching up to
> > > do!  Although this thread is probably less urgent than some of the
> > > others, this one being related to more advanced (future)
> > > functionality,
> > > I'll jump in on this first.
> > >
> > > Comparing Brian's proposal for the video translator to
> less exotic MG
> > > devices that translate audio, I wonder why the extra ports
> > > are needed.
> > > In the audio case, the required transcoding, e.g. from
> G.711 A-law to
> > > G.723.1 is inferred from the Termination type/name and/or
> RTP payload
> > > type.  No extra ports are introduced to model the translator
> > > resource.
> > > Why can't it work the same for video?
> > >
> > > Cheers,
> > >
> > > John
> > >
> > > "Rosen, Brian" wrote:
> > > >
> > > > You seem to have everything correct!
> > > >
> > > > You are worried about the video translator.  The
> problem statement
> > > > was MG-A and MG-B did not have a common video encoding,
> so the MGC
> > > > wanted to insert a translator to fix the problem.
> > > >
> > > > I think this is very reasonable to do, and I would model the
> > > > translator as a set of pairs of terminations - The "A" side and
> > > > the "B" side.  Trying to push these into a single context, to
> > > > my way of thinking, is very weird.  Much cleaner to have two
> > > > separate contexts.  I waffled over whether to represent
> the "ports"
> > > > of the translator as physical terminations.  In
> reality, they could
> > > > be, if the translator was some hard wired fixed function.  It is
> > > > possible that it could just be a fancy DSP, and the number
> > > of translations
> > > > it could do was a variable, determined by what
> > > > translations were in use.  For example, it might be able to do
> > > > 10 MPEG 1 to MPEG 2 translations, but only 3 MPEG2 to H.261
> > > translations.
> > > > In this case, it might be better to model the ports as ephemeral
> > > > terminations.  I would still represent them as pairs of
> > > terminations,
> > > > which would go in pairs of two termination contexts, the other
> > > > termination being (for example) the RTP termination.
> > > >
> > > > To help your thinking, instead of calling those
> > > terminations Y and Z,
> > > > call them XLate/A and XLate/B.  If the box could do
> more than one,
> > > > maybe we would call them XL/1/A and XL/1/B, so you
> could talk about
> > > > XL/4/A for example.  Then XL/1/A is in a context with RTP-A, and
> > > > XL/1/B is in context with RTP-B.
> > > >
> > > > It is possible to have one termination that had two
> streams (the A
> > > > stream and the B stream) and then the context would have 3
> > > terminations, the
> > > > translator, the "A" RTP and the "B" RTP.  Then you would
> > > use streamIDs to
> > > > keep the streams straight (no need to use topology).
> > > > This is one of the things I don't like about what we did,
> > > two ways to
> > > > do the same thing, nothing but "taste" to decide which to use,
> > > > guaranteed interoperability problems unless some package is
> > > standardized.
> > > > Oh well.  Anyway, I think modeling the translator as having two
> > > > terminations, an A termination and a B termination,
> each with one
> > > > stream, is the best way to do it.
> > > >
> > > > In fact, you may have noticed that I used the same model for the
> > > > weird function bridge a few emails back -- I think
> whenever we have
> > > > odd-function devices, we should model the "ports" of the device
> > > > as a termination implementing a specific package.  In
> this specific
> > > > case the ports are symmetric (because the flows are
> send-receive),
> > > > but in the general case, they may not be.
> > > >
> > > > Brian
> > > >
> > > > > -----Original Message-----
> > > > > From: Chip Sharp [mailto:chsharp@cisco.com]
> > > > > Sent: Friday, April 14, 2000 3:58 PM
> > > > > To: Rosen, Brian; MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: Re: Multiple streams per call,
> > > > >
> > > > >
> > > > > At 02:33 PM 4/14/00 -0400, Rosen, Brian wrote:
> > > > >
> > > > > ...snip...
> > > > >
> > > > > >Sure.  Look at it from the point of view of the MGs.
> > > You have MG-A,
> > > > > >MG-B and MG1.  MG-A has a termination with two
> streams, video and
> > > > > >audio.  It is commanded by the MGC to set up a single
> > > context with
> > > > > >the termination and two RTP connections, call them
> > > RTP-A-Audio and
> > > > > >RTP-A-Video.  The address it assigns to RTP-A-Audio is MG-B.
> > > > > >The address it assigns RTP-A-Video is MG1.
> > > > > >Again, this is a single context, with the physical
> termination
> > > > > >having two streams, and each of the RTP terminations
> having one
> > > > > >stream each.
> > > > >
> > > > > I assume when you say "RTP connections" above, you mean "RTP
> > > > > terminations"
> > > > > since the word "connection" isn't allowed in megaco. (your
> > > > > MGCP is showing
> > > > > ;-) ).
> > > > > I'm not sure what kind of termination you are talking about,
> > > > > but I'll call
> > > > > it X.
> > > > >
> > > > > In MG-A, Terminations X, RTP-A-Audio and RTP-A-Video all
> > > > > belong to the same
> > > > > context, say Context A.  Termination X has 2 streams assigned
> > > > > to it.  One
> > > > > stream contains the video, the other stream contains the
> > > > > audio (both in
> > > > > send-receive).  Termination RTP-A-Audio would be configured
> > > > > with only the
> > > > > Audio stream.  Termination RTP-A-Video would be configured
> > > > > with only the
> > > > > Video stream.
> > > > >
> > > > > Therefore the video stream goes to MG1 and the audio stream
> > > > > goes to MGB, as
> > > > > described.
> > > > >
> > > > >
> > > > > >Look at MG1.  It has two terminations, with one
> stream each.  It
> > > > > >is asked to set up two contexts, one with an RTP
> connecting to
> > > > > >MG-A and the other with its RTP connection to MG-B.  That's
> > > > > >two contexts, each with two terminations, with one stream in
> > > > > >each of the contexts.
> > > > >
> > > > > I'm not sure what the two mystery terminations are again, but
> > > > > I'll call
> > > > > them Y and Z.
> > > > >
> > > > > Terminations Y and RTP-A belong to a context A and
> > > contain one stream.
> > > > > Terminations Z and RTP-B belong to a context B and
> > > contain one stream.
> > > > >
> > > > > The video stream from MGA comes into context A via
> > > > > Termination RTP-A and
> > > > > ends up on Termination Y (and vice versa).
> > > > >
> > > > > Whatever is on termination Z is transmitted out RTP-B via
> > > > > context B (and
> > > > > vice versa).
> > > > >  From the below, it seems video is connected to MG-B; however
> > > > > there is no
> > > > > context containing Terminations Z & Y to allow them to
> > > > > communicate under
> > > > > the control of megaco.  Therefore, I assume that some internal
> > > > > implementation-specific mechanism connects terminations Y & Z
> > > > > in order to
> > > > > get the video from Context A into context B.
> > > > > MG1 could just have 2 RTP terminations with one stream in one
> > > > > context.  Of
> > > > > course, H.248 forbids a termination from belonging to
> > > more than one
> > > > > context, so you can't just create a context containing X & Y.
> > > > >
> > > > >
> > > > >
> > > > > >Of course, MG-B has a similar setup to MG-A -- it's
> > > audio connects
> > > > > >to MG-A, the video connects to MG1.
> > > > > >
> > > > > >Now look at it from the MGC.  The "call" has 3
> Megaco contexts.
> > > > > >The MG-A to MG-B audio, the MG-A to MG1 video and
> the MG1 to MG-B
> > > > > >video.
> > > > >
> > > > > Yes, but the MGC has no idea how the video gets from
> > > Termination X to
> > > > > Termination Y in MG1.
> > > > >
> > > > > Thanks for the illustration.  I haven't really thought about
> > > > > it in a while.
> > > > >
> > > > >
> > > > > >I'm still not thrilled with the whole stream idea, but
> > > it does work.
> > > > > >
> > > > > >Brian
> > > > >
> > > > > http://www.netaid.org
> > > > > --------------------------------------------------------------
> > > > > -----------
> > > > > Chip Sharp                 CTO Consulting Engineering
> > > > > Cisco Systems
> > > > > Reality - Love it or Leave it.
> > > > > --------------------------------------------------------------
> > > > > ----------
> > > > >
> > >
> > > --
> > > John Segers                                  email:
> jsegers@lucent.com
> > > Lucent Technologies
>  Room HE 306
> > > 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 Apr 24 12:07:18 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07399
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 24 Apr 2000 12:07:18 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9B7D4490@standards.nortelnetworks.com>; Mon, 24 Apr 2000 11:59:56 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 12078 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Apr 2000 11:58:14 -0400
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.F917BD80@standards.nortelnetworks.com>; Mon, 24 Apr 2000 11:48:14
          -0400
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id LAA23622; Mon, 24 Apr
          2000 11:54:24 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id LAA06523; Mon, 24 Apr
          2000 11:54:25 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <2MSF5ZG6>; Mon, 24 Apr 2000 11:49:03 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFAE04.9D2E9F26"
Message-ID:  <4FBEA8857476D311A03300204840E1CF6781E3@whq-msgusr-02.fore.com>
Date:         Mon, 24 Apr 2000 11:54:19 -0400
Reply-To: "Rosen, Brian" <brosen@FORE.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <brosen@FORE.COM>
Subject:      Re: Event Request ID
X-To:         Tom-PT Taylor <taylor@nortelnetworks.com>
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_01BFAE04.9D2E9F26
Content-Type: text/plain;
        charset="iso-8859-1"

I'd agree, but if I were implementing, I'd make it scope to the MGC (that
is, no two request-Ids
from the same MGC were the same).

Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Monday, April 24, 2000 9:31 AM
To: MEGACO@standards.nortelnetworks.com
Subject: Re: Event Request ID



At the moment, the requirement is to scope to termination.  At some point in
the future one could imagine context-level events, but that is not a present
requirement.

        -----Original Message-----
From:   Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]
Sent:   Sunday, April 23, 2000 10:09 PM
To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject:        Event Request ID

        Hi All,

        Is event Request ID scoped to a termination or context or gateway?

        In general is event detected on a gateway basis or context basis or
termination basis?


        Thanks
Chuong


        --
  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 ****


------_=_NextPart_001_01BFAE04.9D2E9F26
Content-Type: text/html;
        charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: Event Request ID</TITLE>

<META content="MSHTML 5.00.2919.6307" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=930502815-24042000>I'd
agree, but if I were implementing, I'd make it scope to the MGC (that is, no two
request-Ids</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=930502815-24042000>from
the same MGC were the same).</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=930502815-24042000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=930502815-24042000>Brian</SPAN></FONT></DIV>
<BLOCKQUOTE
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma
  size=2>-----Original Message-----<BR><B>From:</B> Tom-PT Taylor
  [mailto:taylor@nortelnetworks.com]<BR><B>Sent:</B> Monday, April 24, 2000 9:31
  AM<BR><B>To:</B> MEGACO@standards.nortelnetworks.com<BR><B>Subject:</B> Re:
  Event Request ID<BR><BR></DIV></FONT>
  <P><FONT color=#0000ff face=Arial size=2>At the moment, the requirement is to
  scope to termination.&nbsp; At some point in the future one could imagine
  context-level events, but that is not a present requirement.</FONT></P>
  <UL>
    <P><FONT face=Arial size=1>-----Original Message-----</FONT> <BR><B><FONT
    face=Arial size=1>From:&nbsp;&nbsp;</FONT></B> <FONT face=Arial
    size=1>Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]</FONT>
    <BR><B><FONT face=Arial size=1>Sent:&nbsp;&nbsp;</FONT></B> <FONT face=Arial
    size=1>Sunday, April 23, 2000 10:09 PM</FONT> <BR><B><FONT face=Arial
    size=1>To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT face=Arial
    size=1>MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT> <BR><B><FONT face=Arial
    size=1>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT
    face=Arial size=1>Event Request ID</FONT> </P>
    <P><FONT face=Arial size=2>Hi All,</FONT> </P>
    <P><FONT face=Arial size=2>Is event Request ID scoped to a termination or
    context or gateway?</FONT> </P>
    <P><FONT face=Arial size=2>In general is event detected on a gateway basis
    or context basis or</FONT> <BR><FONT face=Arial size=2>termination
    basis?</FONT> </P><BR>
    <P><FONT face=Arial size=2>Thanks</FONT> <BR><FONT face=Arial
    size=2>Chuong</FONT> </P><BR>
    <P><FONT face=Arial size=2>--</FONT> <BR><FONT face=Arial size=2>&nbsp;
    Alcatel USA,
    Inc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    Internet: Chuong.Nguyen@usa.alcatel.com</FONT> <BR><FONT face=Arial
    size=2>&nbsp; 1000 Coit Road Plano, Texas
    75075&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
    Phone:&nbsp;&nbsp;&nbsp; (972) 519-4613</FONT> <BR><FONT face=Arial
    size=2>&nbsp; **** The opinions expressed are not those of Alcatel USA, Inc
    ****</FONT> </P></UL></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01BFAE04.9D2E9F26--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Apr 24 12:20:44 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07898
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 24 Apr 2000 12:20:44 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.927CA9B0@standards.nortelnetworks.com>; Mon, 24 Apr 2000 12:14:00 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 12154 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Apr 2000 12:12:10 -0400
Received: from fw7.usa.alcatel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.EB382FE0@standards.nortelnetworks.com>; Mon, 24 Apr 2000 12:02:10
          -0400
Received: (from uucp@localhost) by fw7.usa.alcatel.com (8.8.8+Sun/8.8.8) id
          LAA01092 for <MEGACO@standards.nortelnetworks.com>; Mon, 24 Apr 2000
          11:07:14 -0500 (CDT)
Received: from <Chuong.Nguyen@usa.alcatel.com> (relay2.usa.alcatel.com
          [143.209.238.7]) by fw7 via smap (V2.1) id xma000788; Mon, 24 Apr 00
          11:06:27 -0500
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 LAA21485 for
          <MEGACO@standards.nortelnetworks.com>; Mon, 24 Apr 2000 11:08:44
          -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 LAA25210 for <MEGACO@standards.nortelnetworks.com>; Mon, 24
          Apr 2000 11:06:30 -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 LAA27639
          for <MEGACO@standards.nortelnetworks.com>; Mon, 24 Apr 2000 11:06:30
          -0500 (CDT)
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF6781E0@whq-msgusr-02.fore.com>
Content-Type: multipart/alternative;
              boundary="------------BBE110E9565E6B94DBE76986"
Message-ID:  <39047105.EC034FF8@usa.alcatel.com>
Date:         Mon, 24 Apr 2000 11:06:30 -0500
Reply-To: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Subject:      Re: Error 433 behavior
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--------------BBE110E9565E6B94DBE76986
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


--------------BBE110E9565E6B94DBE76986
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Thanks for the response Brian.
<p>Can we specify in the Standard or implementor Guide that the MG returns
the ContextId that
<br>the termination is already in instead of "CHOOSE"?
<br>Therefore MGC does not have to do an audit to find out what context
that termination is already in.
<p>Having MG returns "CHOOSE" does not buy MGC anything.
<p>For a physical termination, the contextID is going to be either NULL&nbsp;or
created contextId, so I&nbsp;don't
<br>think it would hurt to return that instead of "CHOOSE".
<p>Either way can this be documented in the Standard or implementor Guide?
<br>&nbsp;
<p>Thanks
<br>Chuong
<br>&nbsp;
<p>"Rosen, Brian" wrote:
<blockquote TYPE=CITE>&nbsp;
<blockquote
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">Transaction=1
{Context=$ {Add = TDM123{....}}}
<p>Reply=1{Context= ???? {Add = TDM123{errorDescriptor}}} or
<p>Reply=1{Context = ??? {errorDescriptor}}&nbsp;&nbsp;&nbsp;&nbsp; //
Error 433: Termination ID is already in a Context&nbsp;<span
  class=270455514-24042000></span>
<p><span class=270455514-24042000><font face="Arial"><font color="#0000FF"><font size=-1>I
believe it should be the former.&nbsp; In general, you want the most specificity
in error</span><span
  class=270455514-24042000> returns.&nbsp; In this
case, we clearly have no syntax issues in determining that it is the Add
which</span><span class=270455514-24042000> fails, for a specific reason.&nbsp;
Thus I think you get the error on the add.</font></font></font></span>
<br>&nbsp;
<p>What should the MG return for ContextID --&nbsp; $ or the context Id
that the termination is in?&nbsp;<span
  class=270455514-24042000></span>
<p><span class=270455514-24042000><font face="Arial"><font color="#0000FF"><font size=-1>You
get "Choose"&nbsp;</font></font></font></span>
<p>Should the Error Descriptor be in the command level or at the context
level?
<br>I think it should be in the command level since it is the Add command
that result in an error.&nbsp;<span class=270455514-24042000></span>
<p><span class=270455514-24042000><font face="Arial"><font color="#0000FF"><font size=-1>I
agree, at the command level&nbsp;</font></font></font></span>
<p><span
  class=270455514-24042000><font face="Arial"><font color="#0000FF"><font size=-1>Brian&nbsp;</font></font></font></span></blockquote>
</blockquote>

<pre>--&nbsp;
&nbsp; Alcatel USA, Inc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Internet: Chuong.Nguyen@usa.alcatel.com
&nbsp; 1000 Coit Road Plano, Texas 75075&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Phone:&nbsp;&nbsp;&nbsp; (972) 519-4613
&nbsp; **** The opinions expressed are not those of Alcatel USA, Inc ****</pre>
&nbsp;</html>

--------------BBE110E9565E6B94DBE76986--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Apr 24 12:45:50 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08562
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 24 Apr 2000 12:45:49 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.12217BC0@standards.nortelnetworks.com>; Mon, 24 Apr 2000 12:39:02 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 12185 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Apr 2000 12:38:01 -0400
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.878EBDC0@standards.nortelnetworks.com>; Mon, 24 Apr 2000 12:28:00
          -0400
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id MAA27230; Mon, 24 Apr
          2000 12:34:07 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id MAA14267; Mon, 24 Apr
          2000 12:34:03 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <2MSF55AL>; Mon, 24 Apr 2000 12:28:41 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFAE0A.26D761FE"
Message-ID:  <4FBEA8857476D311A03300204840E1CF6781EE@whq-msgusr-02.fore.com>
Date:         Mon, 24 Apr 2000 12:34:01 -0400
Reply-To: "Rosen, Brian" <brosen@FORE.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <brosen@FORE.COM>
Subject:      Re: Error 433 behavior
X-To:         Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
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_01BFAE0A.26D761FE
Content-Type: text/plain;
        charset="iso-8859-1"

I don't think that is a good idea to return the context ID of the context
the termination is in.

The MGC asked that a new context be created, and this termination be put in
it.
Returning the context ID that the termination is already in would be
incorrect, because
there was not a request to Add a termination to that context.

This problem occurs when the context was already created.  Suppose that a
context with
two terminations already existed, and a termination was Added to it which
was in another
context.  Would you still expect the context the termination was already in
to be returned?
I wouldn't

I do agree that when/If we do a guide, we should put some text in for this
case.

Brian



-----Original Message-----
From: Chuong Nguyen [mailto:Chuong.Nguyen@USA.ALCATEL.COM]
Sent: Monday, April 24, 2000 12:07 PM
To: MEGACO@standards.nortelnetworks.com
Subject: Re: Error 433 behavior


Thanks for the response Brian.

Can we specify in the Standard or implementor Guide that the MG returns the
ContextId that
the termination is already in instead of "CHOOSE"?
Therefore MGC does not have to do an audit to find out what context that
termination is already in.


Having MG returns "CHOOSE" does not buy MGC anything.


For a physical termination, the contextID is going to be either NULL or
created contextId, so I don't
think it would hurt to return that instead of "CHOOSE".


Either way can this be documented in the Standard or implementor Guide?



Thanks
Chuong



"Rosen, Brian" wrote:




Transaction=1 {Context=$ {Add = TDM123{....}}}

Reply=1{Context= ???? {Add = TDM123{errorDescriptor}}} or


Reply=1{Context = ??? {errorDescriptor}}     // Error 433: Termination ID is
already in a Context


I believe it should be the former.  In general, you want the most
specificity in error returns.  In this case, we clearly have no syntax
issues in determining that it is the Add which fails, for a specific reason.
Thus I think you get the error on the add.



What should the MG return for ContextID --  $ or the context Id that the
termination is in?


You get "Choose"


Should the Error Descriptor be in the command level or at the context level?

I think it should be in the command level since it is the Add command that
result in an error.


I agree, at the command level


Brian

--

  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 ****



------_=_NextPart_001_01BFAE0A.26D761FE
Content-Type: text/html;
        charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.2919.6307" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=970452816-24042000>I
don't think that is a good idea to return the context ID of the context the
termination is in.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=970452816-24042000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=970452816-24042000>The
MGC asked that a new context be created, and this termination be put in
it.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=970452816-24042000>Returning the context ID that the termination is
already in would be incorrect, because</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=970452816-24042000>there
was not a request to Add a termination to that context.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=970452816-24042000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=970452816-24042000>This
problem occurs when the context was already created.&nbsp; Suppose that a
context with</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=970452816-24042000>two
terminations already existed, and a termination was Added to it which was in
another</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=970452816-24042000>context.&nbsp; Would you still </SPAN></FONT><FONT
color=#0000ff face=Arial size=2><SPAN class=970452816-24042000>expect the
context the termination was already in to be returned?&nbsp;
</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=970452816-24042000>I
wouldn't</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=970452816-24042000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=970452816-24042000>I do
agree that when/If we do a guide, we should put some text in for this
case.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=970452816-24042000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=970452816-24042000>Brian</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=970452816-24042000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=970452816-24042000></SPAN></FONT>&nbsp;</DIV>
<BLOCKQUOTE
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma
  size=2>-----Original Message-----<BR><B>From:</B> Chuong Nguyen
  [mailto:Chuong.Nguyen@USA.ALCATEL.COM]<BR><B>Sent:</B> Monday, April 24, 2000
  12:07 PM<BR><B>To:</B> MEGACO@standards.nortelnetworks.com<BR><B>Subject:</B>
  Re: Error 433 behavior<BR><BR></DIV></FONT>Thanks for the response Brian.
  <P>Can we specify in the Standard or implementor Guide that the MG returns the
  ContextId that <BR>the termination is already in instead of "CHOOSE"?
  <BR>Therefore MGC does not have to do an audit to find out what context that
  termination is already in.
  <P>Having MG returns "CHOOSE" does not buy MGC anything.
  <P>For a physical termination, the contextID is going to be either
  NULL&nbsp;or created contextId, so I&nbsp;don't <BR>think it would hurt to
  return that instead of "CHOOSE".
  <P>Either way can this be documented in the Standard or implementor Guide?
  <BR>&nbsp;
  <P>Thanks <BR>Chuong <BR>&nbsp;
  <P>"Rosen, Brian" wrote:
  <BLOCKQUOTE TYPE="CITE">&nbsp;
    <BLOCKQUOTE
    style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">Transaction=1
      {Context=$ {Add = TDM123{....}}}
      <P>Reply=1{Context= ???? {Add = TDM123{errorDescriptor}}} or
      <P>Reply=1{Context = ??? {errorDescriptor}}&nbsp;&nbsp;&nbsp;&nbsp; //
      Error 433: Termination ID is already in a Context&nbsp;<SPAN
      class=270455514-24042000></SPAN>
      <P><SPAN class=270455514-24042000><FONT face=Arial><FONT
      color=#0000ff><FONT size=-1>I believe it should be the former.&nbsp; In
      general, you want the most specificity in error</SPAN><SPAN
      class=270455514-24042000> returns.&nbsp; In this case, we clearly have no
      syntax issues in determining that it is the Add which</SPAN><SPAN
      class=270455514-24042000> fails, for a specific reason.&nbsp; Thus I think
      you get the error on the add.</FONT></FONT></FONT></SPAN> <BR>&nbsp;
      <P>What should the MG return for ContextID --&nbsp; $ or the context Id
      that the termination is in?&nbsp;<SPAN class=270455514-24042000></SPAN>
      <P><SPAN class=270455514-24042000><FONT face=Arial><FONT
      color=#0000ff><FONT size=-1>You get
      "Choose"&nbsp;</FONT></FONT></FONT></SPAN>
      <P>Should the Error Descriptor be in the command level or at the context
      level? <BR>I think it should be in the command level since it is the Add
      command that result in an error.&nbsp;<SPAN
      class=270455514-24042000></SPAN>
      <P><SPAN class=270455514-24042000><FONT face=Arial><FONT
      color=#0000ff><FONT size=-1>I agree, at the command
      level&nbsp;</FONT></FONT></FONT></SPAN>
      <P><SPAN class=270455514-24042000><FONT face=Arial><FONT
      color=#0000ff><FONT
    size=-1>Brian&nbsp;</FONT></FONT></FONT></SPAN></P></BLOCKQUOTE></BLOCKQUOTE><PRE>--&nbsp;
&nbsp; Alcatel USA, Inc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Internet: Chuong.Nguyen@usa.alcatel.com
&nbsp; 1000 Coit Road Plano, Texas 75075&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Phone:&nbsp;&nbsp;&nbsp; (972) 519-4613
&nbsp; **** The opinions expressed are not those of Alcatel USA, Inc ****</PRE>&nbsp;
</BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01BFAE0A.26D761FE--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Apr 24 13:36:53 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09804
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 24 Apr 2000 13:36:52 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.34175090@standards.nortelnetworks.com>; Mon, 24 Apr 2000 13:30:06 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 12234 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Apr 2000 13:28:51 -0400
Received: from lmmx1.fl.icn.siemens.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.A17AECC0@standards.nortelnetworks.com>; Mon, 24 Apr 2000 13:18:50
          -0400
Received: from boca210a.boca.ssc.siemens.com (boca210a.boca.ssc.siemens.com
          [135.1.69.210]) by lmmx1.fl.icn.siemens.com (8.9.3/8.9.3) with ESMTP
          id NAA04412 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 24 Apr
          2000 13:25:01 -0400 (EDT)
Received: by boca210a.boca.ssc.siemens.com with Internet Mail Service
          (5.5.2650.21) id <2N17C7GA>; Mon, 24 Apr 2000 13:25: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:  <1B5DAABC2176D31189AE0008C7E632E8090F79@boca213a.boca.ssc.siemens.com>
Date:         Mon, 24 Apr 2000 13:24:58 -0400
Reply-To: "Link, Brian" <Brian.Link@ICN.SIEMENS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Link, Brian" <Brian.Link@ICN.SIEMENS.COM>
Subject:      Residentual Gateway Administration
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Has there been any work to define SNMP/Q3/CORBA management objects of
Residential Gateways?  If so, could you point me to a source.

Thanks!

Brian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Apr 24 16:12:13 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13840
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 24 Apr 2000 16:12:13 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E79917B0@standards.nortelnetworks.com>; Mon, 24 Apr 2000 16:05:26 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 12500 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Apr 2000 16:04:00 -0400
Received: from smtprtp1.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.B4162450@standards.nortelnetworks.com>; Mon, 24 Apr 2000 16:04:00
          -0400
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          smtprtp1.ntcom.nortel.net; Mon, 24 Apr 2000 16:05:33 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <27B935JS>; Mon, 24 Apr 2000 16:05:33 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B6E7@zcard00g.ca.nortel.com>
Date:         Mon, 24 Apr 2000 16:05:29 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: LocalControl Descriptor
X-To:         Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

My views below.

> -----Original Message-----
> From: Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]
> Sent: Friday, April 07, 2000 12:43 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      LocalControl Descriptor
>
> Hi
>
> I asked this question before maybe in a different but I don't think that I
> got a response or
> clarification in the latest version.
>
> Maybe I will try again w/an example.
>
>
> Section 7.1.7 LocalControl Descriptor
> "The allowed values for the mode property are send-only, receive-only,
> send/receive,
> inactive and loop-back.  "Send" and "receive" are with respect to the
> exterior of the context,
> so that, for example, a stream set to mode=sendonly does not pass received
> media
> into the context.  Signals and Events are not affected by mode."
>
> If I have the following sceanrio
>
>
>          MG1                                          MG2
> CO
>     ______________         ________________           _______________
>     |                       |        |                           |
> |                             |
>     |   TDM--*--RTP  |--------|  RTP--*--TDM ------|           |
> |
>     |                       |        |                           |
> |                             |
>              |------------|                     |-------------|
> |-----------|
>
>
> MG1 TDM termination is set to sendrecv.
> MG1 RTP termination is set to receive only.
>
> MG1 TDM termination is set to inactive.
> MG1 RTP termination is set to inactive.
>
> MGC sends the following transaction to MG2 to do a Continuity Test:
>
> Transaction=1{Context=1{Modify=TDM{Signals={ct/ct}, Events=123{ct/cmp} }}}
>
>
> The questions that I have are (keep in mind of the definition of mode and
> the relationship
> of signal and mode as described in Section 7.1.7 above):
>
> 1) Since the MG2 TDM termination mode is inactive, does a ct signal get
> send to CO?
>      The answer should be yes since "Signals and Events are not affected
> by mode.".
        [PTT]  Agreed.

> 2) Since the MG2 RTP termination mode is inactive, does a ct signal gets
> propagated to
>      MG1 RTP terminaiton?
>      The answer should be no since the termination mode is inactive.
        [PTT]  Agreed.

> 3) Even though MG2 TDM termination is inactive, with the above transaction
> would I
>      still have performed a valid COT between the TDM termination and CO?
        [PTT]  Yes.  It's important to note that you have tested the TDM
portion of the connection only, but that is AFAIK the intent of a continuity
test.

> 4) Does signal get propagated out of the context regardless of mode via
> whatever terminations
>      are in the context?
>      If there is a link between 2 MGs contexts, does a signal applied to
> MG2 termination get
>      propagate out of MG2 context and into MG1 context?
        [PTT]  Since you're putting MG2 in the role of initiator, the
response from the other end gets propagated through the context if the modes
of the two terminations are set to allow it.

> 5) What does loopback really mean?  Can someone provide an example?
>       " "Send" and "receive" are with respect to the exterior of the
> context, ...."
>       Does loopback on a RTP termination mean that media flows into the
> context via
>       the RTP termination and flows back out of the context.? That media
> does not flow
>       into the TDM termination.  Thus that same media does not flow out of
> context via
>       the TDM termination.
>       Was loopback intended for COT initiated by CO?  But with the
> definition that signal
>        is not affected by mode, how is loopback used with COT signal?
        [PTT]  "Loopback" mode means that the media content received on a
termination is reflected back along the return direction.  We have not
pinned down whether loopback happens on the outside of the MG or whether it
passes through signal processors in the interior.  The difference does
matter for some maintenance operations, so this is an open issue.

        When it comes to continuity tests, some variants require loopback at
the responding end, while others require generation of a different tone in
the return direction from the tone sent by the initiator.  In our design of
the package, we assumed that the MG would be aware through provisioning
which test variant applied to a given termination.  Where loopback is
required, it is implicit in the invocation of ct/rsp that it should be
applied to the termination while the ct/rsp "signal" is active.

> Am I even approaching this COT correctly?
>
>
>
> Thanks
> Chuong
>
>
> --
>   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 Apr 24 18:01:27 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16106
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 24 Apr 2000 18:01:26 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.29065E60@standards.nortelnetworks.com>; Mon, 24 Apr 2000 17:54:39 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 12657 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Apr 2000 17:52:55 -0400
Received: from fw7.usa.alcatel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.858EA400@standards.nortelnetworks.com>; Mon, 24 Apr 2000 17:42:55
          -0400
Received: (from uucp@localhost) by fw7.usa.alcatel.com (8.8.8+Sun/8.8.8) id
          QAA18523 for <megaco@standards.nortelnetworks.com>; Mon, 24 Apr 2000
          16:48:05 -0500 (CDT)
Received: from <Chuong.Nguyen@usa.alcatel.com> (relay1.usa.alcatel.com
          [143.209.238.6]) by fw7 via smap (V2.1) id xma018465; Mon, 24 Apr 00
          16:47:56 -0500
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1]) by
          relay1.usa.alcatel.com (8.9.3/8.9.3) with ESMTP id QAA12922 for
          <megaco@standards.nortelnetworks.com>; Mon, 24 Apr 2000 16:45:46
          -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 QAA27253 for <megaco@standards.nortelnetworks.com>; Mon, 24
          Apr 2000 16:45:11 -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 QAA29304
          for <megaco@standards.nortelnetworks.com>; Mon, 24 Apr 2000 16:45:10
          -0500 (CDT)
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <C51ED84B6F47D211917A0000F8BCBD1193B6E7@zcard00g.ca.nortel.com>
Content-Type: multipart/alternative;
              boundary="------------E8F90098372E8FDD88792144"
Message-ID:  <3904C066.16B62E32@usa.alcatel.com>
Date:         Mon, 24 Apr 2000 16:45:10 -0500
Reply-To: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Subject:      Re: LocalControl Descriptor
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--------------E8F90098372E8FDD88792144
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thanks for the response Tom.

See comments below.

Tom-PT Taylor wrote:

>
>
> My views below.
>
>      -----Original Message-----
>      From:  Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]
>      Sent:  Friday, April 07, 2000 12:43 PM
>      To:    MEGACO@STANDARDS.NORTELNETWORKS.COM
>      Subject:       LocalControl Descriptor
>
>      Hi
>
>      I asked this question before maybe in a different but I don't
>      think that I got a response or
>      clarification in the latest version.
>
>      Maybe I will try again w/an example.
>
>
>      Section 7.1.7 LocalControl Descriptor
>      "The allowed values for the mode property are send-only,
>      receive-only, send/receive,
>      inactive and loop-back.  "Send" and "receive" are with respect to
>      the exterior of the context,
>      so that, for example, a stream set to mode=sendonly does not pass
>      received media
>      into the context.  Signals and Events are not affected by mode."
>
>      If I have the following sceanrio
>
>
>               MG1
>      MG2                                            CO
>          ______________         ________________
>      _______________
>          |                       |        |
>      |            |                             |
>          |   TDM--*--RTP  |--------|  RTP--*--TDM ------|
>      |                 |
>          |                       |        |
>      |            |                             |
>                   |------------|
>      |-------------|            |-----------|
>
>
>      MG1 TDM termination is set to sendrecv.
>      MG1 RTP termination is set to receive only.
>
>      MG2 TDM termination is set to inactive.
>      MG2 RTP termination is set to inactive.
>
>      MGC sends the following transaction to MG2 to do a Continuity
>      Test:
>
>      Transaction=1{Context=1{Modify=TDM{Signals={ct/ct},
>      Events=123{ct/cmp} }}}
>
>      The questions that I have are (keep in mind of the definition of
>      mode and the relationship
>      of signal and mode as described in Section 7.1.7 above):
>
>      1) Since the MG2 TDM termination mode is inactive, does a ct
>      signal get send to CO?
>           The answer should be yes since "Signals and Events are not
>      affected by mode.".
>      [PTT]  Agreed.
>
>      2) Since the MG2 RTP termination mode is inactive, does a ct
>      signal gets propagated to
>           MG1 RTP terminaiton?
>           The answer should be no since the termination mode is
>      inactive.
>      [PTT]  Agreed.
>
>
<cnn>  This is the behavior that I would like to see but doesn't this
conflict w/#1 above?
             That is a signal is applied to TDM termination.  Is this
signal seen by the RTP termination?
             If this signal is seen by the RTP termination (default
topology behavior of bothway),
             shouldn't this signal be propagated out of the context via
RTP termination too
            since signal is not dependent on termination mode?

             Does topology, signal, event, termination/stream mode have
any relationships?



>
>      3) Even though MG2 TDM termination is inactive, with the above
>      transaction would I
>           still have performed a valid COT between the TDM termination
>      and CO?
>      [PTT]  Yes.  It's important to note that you have tested the TDM
>      portion of the connection only, but that is AFAIK the intent of a
>      continuity test.
>
>      4) Does signal get propagated out of the context regardless of
>      mode via whatever terminations
>           are in the context?
>           If there is a link between 2 MGs contexts, does a signal
>      applied to MG2 termination get
>           propagate out of MG2 context and into MG1 context?
>      [PTT]  Since you're putting MG2 in the role of initiator, the
>      response from the other end gets propagated through the context
>      if the modes of the two terminations are set to allow it.
>
>
<cnn>  I understand the response gets propagated through the context.
But the question is, does
             signal applied to a TDM gets propagated

>
>      5) What does loopback really mean?  Can someone provide an
>      example?
>            " "Send" and "receive" are with respect to the exterior of
>      the context, ...."
>            Does loopback on a RTP termination mean that media flows
>      into the context via
>            the RTP termination and flows back out of the context.?
>      That media does not flow
>            into the TDM termination.  Thus that same media does not
>      flow out of context via
>            the TDM termination.
>            Was loopback intended for COT initiated by CO?  But with
>      the definition that signal
>             is not affected by mode, how is loopback used with COT
>      signal?
>      [PTT]  "Loopback" mode means that the media content received on a
>      termination is reflected back along the return direction.  We
>      have not pinned down whether loopback happens on the outside of
>      the MG or whether it passes through signal processors in the
>      interior.  The difference does matter for some maintenance
>      operations, so this is an open issue.
>
>      When it comes to continuity tests, some variants require loopback
>      at the responding end, while others require generation of a
>      different tone in the return direction from the tone sent by the
>      initiator.  In our design of the package, we assumed that the MG
>      would be aware through provisioning which test variant applied to
>      a given termination.  Where loopback is required, it is implicit
>      in the invocation of ct/rsp that it should be applied to the
>      termination while the ct/rsp "signal" is active.
>
>      Am I even approaching this COT correctly?
>
>
>
>      Thanks
>      Chuong
>
>
>      --
>        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
>      ****
>
>
--
  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 ****



--------------E8F90098372E8FDD88792144
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Thanks for the response Tom.
<p>See comments below.
<p>Tom-PT Taylor wrote:
<blockquote TYPE=CITE>&nbsp;
<p><font face="Arial"><font color="#0000FF"><font size=-1>My views below.</font></font></font>
<ul><font face="Arial"><font size=-2>-----Original Message-----</font></font>
<br><font face="Arial"><font size=-2><b>From:&nbsp; </b>Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]</font></font>
<br><font face="Arial"><font size=-2><b>Sent:&nbsp; </b>Friday, April 07,
2000 12:43 PM</font></font>
<br><font face="Arial"><font size=-2><b>To:&nbsp;&nbsp;&nbsp; </b>MEGACO@STANDARDS.NORTELNETWORKS.COM</font></font>
<br><font face="Arial"><font size=-2><b>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</b>LocalControl Descriptor</font></font>
<p><font face="Arial"><font size=-1>Hi</font></font>
<p><font face="Arial"><font size=-1>I asked this question before maybe
in a different but I don't think that I got a response or</font></font>
<br><font face="Arial"><font size=-1>clarification in the latest version.</font></font>
<p><font face="Arial"><font size=-1>Maybe I will try again w/an example.</font></font>
<br>&nbsp;
<p><font face="Arial"><font size=-1>Section 7.1.7 LocalControl Descriptor</font></font>
<br><font face="Arial"><font size=-1>"The allowed values for the mode property
are send-only, receive-only, send/receive,</font></font>
<br><font face="Arial"><font size=-1>inactive and loop-back.&nbsp; "Send"
and "receive" are with respect to the exterior of the context,</font></font>
<br><font face="Arial"><font size=-1>so that, for example, a stream set
to mode=sendonly does not pass received media</font></font>
<br><font face="Arial"><font size=-1>into the context.&nbsp; Signals and
Events are not affected by mode."</font></font>
<p><font face="Arial"><font size=-1>If I have the following sceanrio</font></font>
<br>&nbsp;
<p><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
MG1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
MG2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
CO</font></font>
<br><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp; ______________&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
________________&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
_______________</font></font>
<br><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</font></font>
<br><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; TDM--*--RTP&nbsp;
|--------|&nbsp; RTP--*--TDM ------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</font></font>
<br><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</font></font>
<br><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|-------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|-----------|</font></font>
<br>&nbsp;
<p><font face="Arial"><font size=-1>MG1 TDM termination is set to sendrecv.</font></font>
<br><font face="Arial"><font size=-1>MG1 RTP termination is set to receive
only.</font></font>
<p><font face="Arial"><font size=-1>MG2 TDM termination is set to inactive.</font></font>
<br><font face="Arial"><font size=-1>MG2 RTP termination is set to inactive.</font></font>
<p><font face="Arial"><font size=-1>MGC sends the following transaction
to MG2 to do a Continuity Test:</font></font>
<p><font face="Arial"><font size=-1>Transaction=1{Context=1{Modify=TDM{Signals={ct/ct},
Events=123{ct/cmp} }}}</font></font>
<p><font face="Arial"><font size=-1>The questions that I have are (keep
in mind of the definition of mode and the relationship</font></font>
<br><font face="Arial"><font size=-1>of signal and mode as described in
Section 7.1.7 above):</font></font>
<p><font face="Arial"><font size=-1>1) Since the MG2 TDM termination mode
is inactive, does a ct signal get send to CO?</font></font>
<br><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp; The answer
should be yes since "Signals and Events are not affected by mode.".</font></font>
<br><b><i><font face="Arial"><font color="#0000FF"><font size=-1>[PTT]</font></font></font></i></b>&nbsp;<font face="Arial"><font color="#0000FF"><font size=-1>
Agreed.</font></font></font>
<p><font face="Arial"><font size=-1>2) Since the MG2 RTP termination mode
is inactive, does a ct signal gets propagated to</font></font>
<br><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp; MG1 RTP terminaiton?</font></font>
<br><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp; The answer
should be no since the termination mode is inactive.</font></font>
<br><b><i><font face="Arial"><font color="#0000FF"><font size=-1>[PTT]</font></font></font></i></b>&nbsp;<font face="Arial"><font color="#0000FF"><font size=-1>
Agreed.</font></font></font>
<br>&nbsp;</ul>
</blockquote>
&lt;cnn>&nbsp; This is the behavior that I&nbsp;would like to see but doesn't
this conflict w/#1 above?
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
That is a signal is applied to TDM termination.&nbsp; Is this signal seen
by the RTP&nbsp;termination?
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
If this signal is seen by the RTP&nbsp;termination (default topology behavior
of bothway),
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
shouldn't this signal be propagated out of the context via RTP termination
too
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
since signal is not dependent on termination mode?
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Does topology, signal, event, termination/stream mode have any relationships?
<br>&nbsp;
<br>&nbsp;
<blockquote TYPE=CITE>
<ul>&nbsp;
<br><font face="Arial"><font size=-1>3) Even though MG2 TDM termination
is inactive, with the above transaction would I</font></font>
<br><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp; still have
performed a valid COT between the TDM termination and CO?</font></font>
<br><b><i><font face="Arial"><font color="#0000FF"><font size=-1>[PTT]</font></font></font></i></b>&nbsp;<font face="Arial"><font color="#0000FF"><font size=-1>
Yes.&nbsp; It's important to note that you have tested the TDM portion
of the connection only, but that is AFAIK the intent of a continuity test.</font></font></font>
<p><font face="Arial"><font size=-1>4) Does signal get propagated out of
the context regardless of mode via whatever terminations</font></font>
<br><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp; are in the
context?</font></font>
<br><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp; If there
is a link between 2 MGs contexts, does a signal applied to MG2 termination
get</font></font>
<br><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp; propagate
out of MG2 context and into MG1 context?</font></font>
<br><b><i><font face="Arial"><font color="#0000FF"><font size=-1>[PTT]</font></font></font></i></b>&nbsp;<font face="Arial"><font color="#0000FF"><font size=-1>
Since you're putting MG2 in the role of initiator, the response from the
other end gets propagated through the context if the modes of the two terminations
are set to allow it.</font></font></font>
<br>&nbsp;</ul>
</blockquote>
&lt;cnn>&nbsp; I understand the response gets propagated through the context.&nbsp;
But the question is, does
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
signal applied to a TDM gets propagated
<blockquote TYPE=CITE>
<ul>&nbsp;
<br><font face="Arial"><font size=-1>5) What does loopback really mean?&nbsp;
Can someone provide an example?</font></font>
<br><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; " "Send"
and "receive" are with respect to the exterior of the context, ...."</font></font>
<br><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Does
loopback on a RTP termination mean that media flows into the context via</font></font>
<br><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the
RTP termination and flows back out of the context.? That media does not
flow</font></font>
<br><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; into
the TDM termination.&nbsp; Thus that same media does not flow out of context
via</font></font>
<br><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the
TDM termination.</font></font>
<br><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Was
loopback intended for COT initiated by CO?&nbsp; But with the definition
that signal</font></font>
<br><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
is not affected by mode, how is loopback used with COT signal?</font></font>
<br><b><i><font face="Arial"><font color="#0000FF"><font size=-1>[PTT]</font></font></font></i></b>&nbsp;<font face="Arial"><font color="#0000FF"><font size=-1>
"Loopback" mode means that the media content received on a termination
is reflected back along the return direction.&nbsp; We have not pinned
down whether loopback happens on the outside of the MG or whether it passes
through signal processors in the interior.&nbsp; The difference does matter
for some maintenance operations, so this is an open issue.</font></font></font>
<p><font face="Arial"><font color="#0000FF"><font size=-1>When it comes
to continuity tests, some variants require loopback at the responding end,
while others require generation of a different tone in the return direction
from the tone sent by the initiator.&nbsp; In our design of the package,
we assumed that the MG would be aware through provisioning which test variant
applied to a given termination.&nbsp; Where loopback is required, it is
implicit in the invocation of ct/rsp that it should be applied to the termination
while the ct/rsp "signal" is active.</font></font></font>
<p><font face="Arial"><font size=-1>Am I even approaching this COT correctly?</font></font>
<br>&nbsp;
<br>&nbsp;
<p><font face="Arial"><font size=-1>Thanks</font></font>
<br><font face="Arial"><font size=-1>Chuong</font></font>
<br>&nbsp;
<p><font face="Courier New"><font size=-1>--</font></font>
<br><font face="Courier New"><font size=-1>&nbsp; Alcatel USA, Inc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Internet: Chuong.Nguyen@usa.alcatel.com</font></font>
<br><font face="Courier New"><font size=-1>&nbsp; 1000 Coit Road Plano,
Texas 75075&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Phone:&nbsp;&nbsp;&nbsp; (972) 519-4613</font></font>
<br><font face="Courier New"><font size=-1>&nbsp; **** The opinions expressed
are not those of Alcatel USA, Inc ****</font></font>
<br>&nbsp;</ul>
</blockquote>

<pre>--&nbsp;
&nbsp; Alcatel USA, Inc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Internet: Chuong.Nguyen@usa.alcatel.com
&nbsp; 1000 Coit Road Plano, Texas 75075&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Phone:&nbsp;&nbsp;&nbsp; (972) 519-4613
&nbsp; **** The opinions expressed are not those of Alcatel USA, Inc ****</pre>
&nbsp;</html>

--------------E8F90098372E8FDD88792144--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Apr 24 19:24:27 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17473
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 24 Apr 2000 19:24:27 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C44E8FE0@standards.nortelnetworks.com>; Mon, 24 Apr 2000 19:17:44 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 12714 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Apr 2000 19:16:00 -0400
Received: from smtprtp.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.864CB0F0@standards.nortelnetworks.com>; Mon, 24 Apr 2000 19:16:00
          -0400
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          smtprtp.ntcom.nortel.net; Mon, 24 Apr 2000 19:19:30 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <27B9389A>; Mon, 24 Apr 2000 19:19:30 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B6E9@zcard00g.ca.nortel.com>
Date:         Mon, 24 Apr 2000 19:19:25 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: LocalControl Descriptor
X-To:         Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

The general response to your follow-up queries is that, except where a
package specifies otherwise, signals are sent from the termination outwards,
never inwards to the context.  See the third-last paragraph of sec. 7.1.11.

The only reason continuity test tones would be propagated inwards would be
because the audio stream of the termination is in receive or sendReceive
mode.

> -----Original Message-----
> From: Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]
> Sent: Monday, April 24, 2000 5:45 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: LocalControl Descriptor
>
> Thanks for the response Tom.
>
> See comments below.
>
> Tom-PT Taylor wrote:
>
>
>
>       My views below.
>
>               -----Original Message-----
>       From:  Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]
>       Sent:  Friday, April 07, 2000 12:43 PM
>       To:    MEGACO@STANDARDS.NORTELNETWORKS.COM
>       Subject:       LocalControl Descriptor
>
>               Hi
>
>               I asked this question before maybe in a different but I
> don't think that I got a response or
>       clarification in the latest version.
>
>               Maybe I will try again w/an example.
>
>
>               Section 7.1.7 LocalControl Descriptor
>       "The allowed values for the mode property are send-only,
> receive-only, send/receive,
>       inactive and loop-back.  "Send" and "receive" are with respect to
> the exterior of the context,
>       so that, for example, a stream set to mode=sendonly does not pass
> received media
>       into the context.  Signals and Events are not affected by mode."
>
>               If I have the following sceanrio
>
>
>                        MG1                                          MG2
> CO
>           ______________         ________________
> _______________
>           |                       |        |                           |
> |                             |
>           |   TDM--*--RTP  |--------|  RTP--*--TDM ------|           |
> |
>           |                       |        |                           |
> |                             |
>                    |------------|                     |-------------|
> |-----------|
>
>
>               MG1 TDM termination is set to sendrecv.
>       MG1 RTP termination is set to receive only.
>
>               MG2 TDM termination is set to inactive.
>       MG2 RTP termination is set to inactive.
>
>               MGC sends the following transaction to MG2 to do a
> Continuity Test:
>
>               Transaction=1{Context=1{Modify=TDM{Signals={ct/ct},
> Events=123{ct/cmp} }}}
>
>               The questions that I have are (keep in mind of the
> definition of mode and the relationship
>       of signal and mode as described in Section 7.1.7 above):
>
>               1) Since the MG2 TDM termination mode is inactive, does a ct
> signal get send to CO?
>            The answer should be yes since "Signals and Events are not
> affected by mode.".
>       [PTT]  Agreed.
>
>               2) Since the MG2 RTP termination mode is inactive, does a ct
> signal gets propagated to
>            MG1 RTP terminaiton?
>            The answer should be no since the termination mode is inactive.
>
>       [PTT]  Agreed.
>
>
> <cnn>  This is the behavior that I would like to see but doesn't this
> conflict w/#1 above?
>              That is a signal is applied to TDM termination.  Is this
> signal seen by the RTP termination?
>              If this signal is seen by the RTP termination (default
> topology behavior of bothway),
>              shouldn't this signal be propagated out of the context via
> RTP termination too
>             since signal is not dependent on termination mode?
>
>              Does topology, signal, event, termination/stream mode have
> any relationships?
>
>
>
>
>       3) Even though MG2 TDM termination is inactive, with the above
> transaction would I
>            still have performed a valid COT between the TDM termination
> and CO?
>       [PTT]  Yes.  It's important to note that you have tested the TDM
> portion of the connection only, but that is AFAIK the intent of a
> continuity test.
>
>               4) Does signal get propagated out of the context regardless
> of mode via whatever terminations
>            are in the context?
>            If there is a link between 2 MGs contexts, does a signal
> applied to MG2 termination get
>            propagate out of MG2 context and into MG1 context?
>       [PTT]  Since you're putting MG2 in the role of initiator, the
> response from the other end gets propagated through the context if the
> modes of the two terminations are set to allow it.
>
>
> <cnn>  I understand the response gets propagated through the context.  But
> the question is, does
>              signal applied to a TDM gets propagated
>
>
>       5) What does loopback really mean?  Can someone provide an example?
>             " "Send" and "receive" are with respect to the exterior of the
> context, ...."
>             Does loopback on a RTP termination mean that media flows into
> the context via
>             the RTP termination and flows back out of the context.? That
> media does not flow
>             into the TDM termination.  Thus that same media does not flow
> out of context via
>             the TDM termination.
>             Was loopback intended for COT initiated by CO?  But with the
> definition that signal
>              is not affected by mode, how is loopback used with COT
> signal?
>       [PTT]  "Loopback" mode means that the media content received on a
> termination is reflected back along the return direction.  We have not
> pinned down whether loopback happens on the outside of the MG or whether
> it passes through signal processors in the interior.  The difference does
> matter for some maintenance operations, so this is an open issue.
>
>               When it comes to continuity tests, some variants require
> loopback at the responding end, while others require generation of a
> different tone in the return direction from the tone sent by the
> initiator.  In our design of the package, we assumed that the MG would be
> aware through provisioning which test variant applied to a given
> termination.  Where loopback is required, it is implicit in the invocation
> of ct/rsp that it should be applied to the termination while the ct/rsp
> "signal" is active.
>
>               Am I even approaching this COT correctly?
>
>
>
>               Thanks
>       Chuong
>
>
>               --
>         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 ****
>
>
>
> --
>   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 Apr 24 22:30:50 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21114
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 24 Apr 2000 22:30:50 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C7E32980@standards.nortelnetworks.com>; Mon, 24 Apr 2000 22:23:56 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 12860 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Apr 2000 22:22:28 -0400
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.932A4E30@standards.nortelnetworks.com>; Mon, 24 Apr 2000
          22:22:28 -0400
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Mon, 24 Apr 2000 21:28:25 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <JSPANYPL>; Mon, 24 Apr 2000 21:28:17 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B6EA@zcard00g.ca.nortel.com>
Date:         Mon, 24 Apr 2000 21:27:13 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Open Issue: Sublist vs. Alternatives
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

In production alternativeValue in Annex B.2, we still have the open issue
that the syntax for over-specification and that for sub-lists is apparently
the same: LSBRKT VALUE *(COMMA VALUE) RSBRKT.  How about enclosing sub-lists
in square brackets and sets of alternative values in curly brackets?
Combined with an accepted fix for ranges this gives:

 alternativeValue = (VALUE                                       ; single
value
       /  LSBRKT VALUE *(COMMA VALUE) RSBRKT  ; sub-list
       /  LBRKT VALUE *(COMMA VALUE) RBRKT      ; alternatives
       /   LSBRKT VALUE COLON VALUE RSBRKT )   ; range

ASN.1 encoding also lacks sub-list support.  I suggest that it be added as a
BOOLEAN choice in extrainfo within the PropertyParm production.


Tom Taylor
Phone and FAX: +1 613 736 0961
E-mail: taylor@nortelnetworks.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Apr 24 23:51:48 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23239
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 24 Apr 2000 23:51:47 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1A715810@standards.nortelnetworks.com>; Mon, 24 Apr 2000 23:44:59 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 12898 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Apr 2000 23:43:50 -0400
Received: from smtprich.nortel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.F0C8D2E0@standards.nortelnetworks.com>; Mon, 24 Apr 2000 23:43:50
          -0400
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprich.nortel.com; Mon, 24 Apr 2000 22:48:36 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <JSPANY5Z>; Mon, 24 Apr 2000 22:47:26 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B6ED@zcard00g.ca.nortel.com>
Date:         Mon, 24 Apr 2000 22:47:26 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Side Effects on streams or termination
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

The following message from Hemant Kumar hasn't gotten through except as a
bounce message, for some reason, so I'm forwarding it.  My response is that
I believe current intent is that events detected on one stream make their
side-effects felt on all streams of the termination.  We may alter that in
v2 if experience shows that we should allow a more refined response.

Tom Taylor
Phone and FAX: +1 613 736 0961
E-mail: taylor@nortelnetworks.com

Original message:

Hi Everyone,

     The event descriptor provides for detection of events on a =
particular stream by means of the parameter :eventStream  (eventStream =
=3D StreamToken EQUAL StreamID). However I couldn't find any mention of =
whether the side effect of event detected on a particular stream within =
a termination are limited to that stream only and not all the streams on =
the termination.

Let me take an example :
         There are 2 streams Audio and Video on a termination. =
EventBufferControl is set to Lockstep for the termination and Events are =
being detected according to Event descriptor. The events being looked =
for on Audio and video stream are ( A, B, C ) and (X, Y, Z). Also some =
signals are being applied on both the streams. Suppose event A is =
detected and Notified. Which out of the following would be the side =
Effect of event detection.

1)    Signals on audio stream are stopped (keepactive was not specified) =
and any further events are stored in event buffer.=20
       Signals continue on Video stream and the events (X,Y,Z) are still =
being detected on Video stream.
2)    Signals are stopped on both the streams and both start buffering =
events.=20

Any comments ??

Regards,
Hemant Kumar

PS : Also find attached my previous mail regarding error codes for =
termination state changes which went unanswered.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hemant Kumar
Ficon Technology
E-mail: mailto:hkumar@ficon-tech.com
Web: http://www.ficon-tech.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr 25 00:03:53 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23463
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 25 Apr 2000 00:03:53 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C8EB10B0@standards.nortelnetworks.com>; Mon, 24 Apr 2000 23:57:02 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 12907 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Apr 2000 23:55:32 -0400
Received: from ficon-tech.com (12.10.198.190) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.2BE2D420@standards.nortelnetworks.com>; Mon, 24 Apr 2000 23:45:29
          -0400
Received: from hgupta (hkumar.india.ficon-tech.com [172.25.1.130]) by
          ficon-tech.com (8.9.3/8.9.3) with SMTP id JAA32963 for
          <Megaco@standards.nortelnetworks.com>; Tue, 25 Apr 2000 09:21:16
          +0530 (IST) (envelope-from hkumar@ficon-tech.com)
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_010A_01BFAE97.A9BE9F00"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Message-ID:  <010d01bfae69$91dc5b80$820119ac@india.ficontech.com>
Date:         Tue, 25 Apr 2000 09:21:39 +0530
Reply-To: Hemant Kumar <hkumar@FICON-TECH.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Hemant Kumar <hkumar@FICON-TECH.COM>
Subject:      Side Effects on streams or termination
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_010A_01BFAE97.A9BE9F00
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Everyone,

     The event descriptor provides for detection of events on a =
particular stream by means of the parameter :eventStream  (eventStream =
=3D StreamToken EQUAL StreamID). However I couldn't find any mention of =
whether the side effect of event detected on a particular stream within =
a termination are limited to that stream only and not all the streams on =
the termination.

Let me take an example :
         There are 2 streams Audio and Video on a termination. =
EventBufferControl is set to Lockstep for the termination and Events are =
being detected according to Event descriptor. The events being looked =
for on Audio and video stream are ( A, B, C ) and (X, Y, Z). Also some =
signals are being applied on both the streams. Suppose event A is =
detected and Notified. Which out of the following would be the side =
Effect of event detection.

1)    Signals on audio stream are stopped (keepactive was not specified) =
and any further events are stored in event buffer.=20
       Signals continue on Video stream and the events (X,Y,Z) are still =
being detected on Video stream.
2)    Signals are stopped on both the streams and both start buffering =
events.=20

Any comments ??

Regards,
Hemant Kumar

PS : Also find below my previous mail which went unanswered. Its =
regarding error codes for termination state changes.


Hi Brian, Tom, list,

    Pls consider the following comments ( inlined <HKG> )

Regards and thanks,
Hemant Kumar

    ----- Original Message -----
From: Rosen, Brian
To: Hemant ; MEGACO@standards.nortelnetworks.com
Sent: Tuesday, April 18, 2000 4:59 AM
Subject: RE: Service State Property "Out of Service"


I'd think you should not set a termination out of service unless it was =
in
null context (and thus would not have any media streams).

<HKG> I Agree. Regarding what Michael mentioned test might have to be
carried out in OOS state. I think that should be done in the service =
state
"Test" rather than "OOS"

Whether it should be illegal is another question.  I don't care.  I =
would
not
want setting the property to have side effects like moving to null, etc.

A line with at least "SHOULD" is needed I think.

<HKG>
(case : termination in non null context receives a command with service =
state OOS)
Think "SHALL" would me more appropriate and the MG NEEDS to send an =
error
code to indicate to the MGC that the termination is in a non null =
context
 and so its service state can't be changed to OOS). The error code can =
be
    433 - TerminationID is already in a Context

Another Error condition that needs to be identified here is the case =
when an
MGC attempts to Add an OOS terminaiton (Explicitly prohobited according =
to
the draft) but error code is not specified. An error code should be =
allocated here.
    4xx - TerminationId in OOS state

Third condition : A termination is presently in service and in null =
context. An Add commnad specifying service state OOS is received. Either =
of the above errore code should be used.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hemant Kumar
Ficon Technology
E-mail: mailto:hkumar@ficon-tech.com
Web: http://www.ficon-tech.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

------=_NextPart_000_010A_01BFAE97.A9BE9F00
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#c0c0c0>
<DIV style=3D"FONT: 10pt arial"></DIV>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>Hi Everyone,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; The event =
descriptor=20
provides for detection of events on a particular stream <FONT =
size=3D2>by means of=20
the parameter :eventStream&nbsp;&nbsp;<FONT size=3D2>(eventStream =3D =
StreamToken=20
EQUAL StreamID). However I couldn't find any mention of whether the side =
effect=20
of event detected on a particular stream within a termination are =
limited to=20
that stream only and not all the streams on the=20
termination.</FONT></FONT></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Let me take an example :</FONT></DIV>
<DIV><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
There are 2 streams&nbsp;Audio and Video on a termination. =
EventBufferControl is=20
set to Lockstep for the termination and Events are being detected =
according to=20
Event descriptor. The events being looked for on Audio and video stream =
are ( A,=20
B, C ) and (X, Y, Z). Also some signals&nbsp;are being applied on both =
the=20
streams. Suppose event A is detected and Notified.&nbsp;Which out of the =

following would be the side Effect of event detection.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>1)&nbsp;&nbsp;&nbsp; Signals on audio =
stream are=20
stopped (keepactive was&nbsp;not specified)&nbsp;and&nbsp;any further =
events are=20
stored&nbsp;in event buffer. </FONT></DIV>
<DIV><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Signals=20
continue on Video stream and the events (X,Y,Z) are still being detected =
on=20
Video stream.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>2)&nbsp;&nbsp;&nbsp; Signals are =
stopped on both=20
the streams and both start buffering events. </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Any comments ??</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Hemant Kumar</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>PS : Also find&nbsp;below my previous =
mail which=20
went unanswered. Its regarding error codes for termination state=20
changes.</FONT></DIV>
<DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>
<DIV><FONT face=3DArial size=3D2>Hi Brian, Tom, =
list,<BR><BR>&nbsp;&nbsp;&nbsp; Pls=20
consider the following comments ( inlined &lt;HKG&gt; )<BR><BR>Regards =
and=20
thanks,<BR>Hemant Kumar<BR><BR>&nbsp;&nbsp;&nbsp; ----- Original Message =

-----<BR>From: Rosen, Brian<BR>To: Hemant ; <A=20
href=3D"mailto:MEGACO@standards.nortelnetworks.com">MEGACO@standards.nort=
elnetworks.com</A><BR>Sent:=20
Tuesday, April 18, 2000 4:59 AM<BR>Subject: RE: Service State Property =
"Out of=20
Service"<BR><BR><BR>I'd think you should not set a termination out of =
service=20
unless it was in<BR>null context (and thus would not have any media=20
streams).<BR><BR>&lt;HKG&gt; I Agree. Regarding what Michael mentioned =
test=20
might have to be<BR>carried out in OOS state. I think that should be =
done in the=20
service state<BR>"Test" rather than "OOS"<BR><BR>Whether it should be =
illegal is=20
another question.&nbsp; I don't care.&nbsp; I would<BR>not<BR>want =
setting the=20
property to have side effects like moving to null, etc.<BR><BR>A line =
with at=20
least "SHOULD" is needed I think.<BR><BR>&lt;HKG&gt;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>(case :&nbsp;termination in non null =
context=20
receives a command with service state OOS)<BR>Think "SHALL" would me =
more=20
appropriate and the MG NEEDS to send an error<BR>code to indicate to the =
MGC=20
that the termination is in a non null context<BR>&nbsp;and so its =
service state=20
can't be changed to OOS). The error code can be<BR>&nbsp;&nbsp;&nbsp; =
433 -=20
TerminationID is already in a Context<BR><BR>Another Error condition =
that needs=20
to be identified here is the case when an<BR>MGC attempts to Add an OOS=20
terminaiton (Explicitly prohobited according to<BR>the draft) but error =
code is=20
not specified. An error code should be allocated =
here.<BR>&nbsp;&nbsp;&nbsp; 4xx=20
- TerminationId in OOS state<BR><BR>Third condition : A =
termination&nbsp;is=20
presently in service and in null context. An Add commnad specifying =
service=20
state OOS is received.&nbsp;Either of the&nbsp;above errore code should =
be=20
used.</FONT><FONT face=3DArial size=3D2><BR><BR></FONT><FONT =
face=3DArial=20
size=3D2>~~~~~~~~~~~~~~~~~~~~~~~~~~~~<BR>Hemant Kumar<BR>Ficon=20
Technology<BR>E-mail: <A=20
href=3D"mailto:hkumar@ficon-tech.com">mailto:hkumar@ficon-tech.com</A><BR=
>Web: <A=20
href=3D"http://www.ficon-tech.com">http://www.ficon-tech.com</A><BR>~~~~~=
~~~~~~~~~~~~~~~~~~~~~~~</FONT></DIV></DIV></DIV></FONT></DIV></BODY></HTM=
L>

------=_NextPart_000_010A_01BFAE97.A9BE9F00--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr 25 00:16:53 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23662
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 25 Apr 2000 00:16:52 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9CF46AE0@standards.nortelnetworks.com>; Tue, 25 Apr 2000 0:10:07 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 12966 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Apr 2000 00:08:59 -0400
Received: from smtprtp1.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.7488F990@standards.nortelnetworks.com>; Tue, 25 Apr 2000 0:08:59
          -0400
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          smtprtp1.ntcom.nortel.net; Tue, 25 Apr 2000 00:10:13 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <27B930X2>; Tue, 25 Apr 2000 00:10:14 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B6EE@zcard00g.ca.nortel.com>
Date:         Tue, 25 Apr 2000 00:10:10 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Signalling Failure
X-To:         Flemming Andreasen <fandreas@CISCO.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

In my opinion the proper solution would be to add the mask to the individual
signals rather than the completion event, because "failure" may be different
for different signals.  For instance, interruption by an event is normal for
dial tone, but abnormal for outpulsing of digits.  I hesitate to add yet
another parameter, of sub-list type at that, to the basic signal mechanism.
Maybe the real problem is that the original mechanism is mis-specified: the
interesting event is that of  the signal not completing in the way expected,
rather than completing.  The way forward may be to replace
"notifyCompletion" with an optional parameter "expect", with possible values
"timeout" or "event", representing the expected way the signal terminates.
If "expect" is present and the signal does not complete in the expected way,
a signal failure event is reported (new name for the signal completion
event, nothing else changes).  If "expect" is absent, a signal failure event
is reported if and only if the event terminates due to other causes (not TO,
not event, not replacement of the signalling descriptor).

> -----Original Message-----
> From: Flemming Andreasen [SMTP:fandreas@CISCO.COM]
> Sent: Tuesday, March 07, 2000 8:28 PM
>
> 5) 7.1.11, second paragraph:    The granularity of the signal completion
> event defined in E.1.2 is too coarse. There is for example no way to be
> informed of just failures (which would seem generally desirable) without
> being more or less flooded by the other completion reasons as well (some
> of which are more questionable). One simple way out of this is to extend
> the definition of the signal completion event to include
> EventsDescriptorParameters where the TerminationMethod(s) of interest
> could be specified. Also, the term "notifyCompletion" is somewhat of a
> misnomer.
>
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr 25 01:53:58 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29480
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 25 Apr 2000 01:53:57 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2BCEC730@standards.nortelnetworks.com>; Tue, 25 Apr 2000 1:47:10 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 13002 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Apr 2000 01:45:23 -0400
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.EC0C9AA0@standards.nortelnetworks.com>; Tue, 25 Apr 2000
          1:45:23 -0400
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Tue, 25 Apr 2000 00:48:33 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <JSPANZGC>; Tue, 25 Apr 2000 00:48:24 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B6F0@zcard00g.ca.nortel.com>
Date:         Tue, 25 Apr 2000 00:47:41 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: E.10 Basic Continuity Package
X-To:         Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I don't think this has been answered.  It seems to be an arbitrary choice.
I would opt for making the MG intelligent enough to turn off echo and codecs
for the duration of the test without being told.

> -----Original Message-----
> From: Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]
> Sent: Monday, April 03, 2000 5:26 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      E.10 Basic Continuity Package
>
> Hi,
>
> E.10.5 Procedures
>
> "When a continuity test is performed
> on a termination, no echo devices or codecs shall be active on that ter-
> mination."
>
> Does this statement applies to MG?
> That is MG should turn off echo and codecs w/o any instruction from MGC
> when MGC
> initiates COT.
> After COT, MG resumes echo and codecs prior to COT.
>
> Or MGC has to tell MG to turn off echo and codecs and after COT turns echo
> and codecs on?
>
>
> Thanks
> Chuong
> --
>   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  Tue Apr 25 02:21:00 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06198
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 25 Apr 2000 02:20:59 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F3571250@standards.nortelnetworks.com>; Tue, 25 Apr 2000 2:14:13 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 13031 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Apr 2000 02:12:20 -0400
Received: from smtprtp.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.AFC82650@standards.nortelnetworks.com>; Tue, 25 Apr 2000 2:12:20
          -0400
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          smtprtp.ntcom.nortel.net; Tue, 25 Apr 2000 02:14:02 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <27B9PACG>; Tue, 25 Apr 2000 02:14:03 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B6F1@zcard00g.ca.nortel.com>
Date:         Tue, 25 Apr 2000 02:14:00 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: E.10.3 Signals (Basic Continuity Package)
X-To:         Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

More unanswered mail.  Responses below.

> -----Original Message-----
> From: Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]
> Sent: Monday, April 03, 2000 5:45 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      E.10.3 Signals (Basic Continuity Package)
>
>
> Hi
>
> The Respond SignalID: rsp (0x004)  has a Signal Type of Timeout.
>
> Looking at Section 10.5,
> "Upon reception of a command with the rsp signal, the MG
> awaits reception of the continuity test tone.  When the tone is received
> before the rsp signal times out, the MG returns the applicable return
> tone."
>
> What is the duration of this Respond Signal?  The text seems to imply that
> the Signal Type is
> Timeout but it is used to timeout the reception of the continuity test
> tone.
> Is the intend that the Respond Signal has the same duration as the Timeout
> for the detection of
> the continuity test tone?
        [PTT]
        I'd like someone to confirm the correctness of the procedure as
quoted.  My understanding of continuity testing varies on two points:
         - sometimes the responder just does a loopback rather than
detecting a tone and playing out another
         - the responder continues to respond until told by the MGC to stop.
        Am I wrong?

> If the Respond Signal duration is TimeOut, MGC gets indication from
> Central Office that
> COT test successful, should MGC sends a Modify to stop the Respond Signal
> or
> just let it play until Timeout?
> If let it plays until Timeout, will or should MG sends Notify w/COT failed
> due to Timeout of
> Respond Signal?
>
> Or should the Respond Signal be Brief or ON/OFF?
        [PTT]
        If it is correct that the responder continues running the test until
call signalling indicates that it can stop, then no timeout is needed and
the rsp signal should be ON/OFF.

          Thanks
> Chuong
>
> --
>   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  Tue Apr 25 02:23:51 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06210
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 25 Apr 2000 02:23:51 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3BC28010@standards.nortelnetworks.com>; Tue, 25 Apr 2000 2:16:15 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 13044 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Apr 2000 02:16:05 -0400
Received: from smtprtp1.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.35A1BE80@standards.nortelnetworks.com>; Tue, 25 Apr 2000 2:16:04
          -0400
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          smtprtp1.ntcom.nortel.net; Tue, 25 Apr 2000 02:18:56 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <27B9PACT>; Tue, 25 Apr 2000 02:18:57 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B6F2@zcard00g.ca.nortel.com>
Date:         Tue, 25 Apr 2000 02:18:53 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Choice Strategy, Merits and Demerits...
X-To:         Venugopal M <m_venugopal@MINDTREE.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

The Hughes Software Systems paper circulated last year had a pretty good
analysis.  The key point is that Megaco provides stronger support for
applications.  MGCP will likely prove to be a dead end once you get past
basic voice services.

> -----Original Message-----
> From: Venugopal M [SMTP:m_venugopal@MINDTREE.COM]
> Sent: Tuesday, April 04, 2000 2:16 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Choice Strategy, Merits and Demerits...
> Importance:   High
>
> Let me keep this to the point. I haven't been able to find enough
> "strategic or technical merits" information in the net for using MEGACO
> vis-a-vis MGCP. I hope I have not overlooked but I don't think I found a
> clear discussion anywhere - I could be happily corrected on this, of
> course.
>
>  Given a choice between MEGACO and MGCP for the MGC-MG space what would
> experts prefer ? If some one ( Maybe Brian,Nancy or john ...too! ) could
> just put in a few lines of merits and demerits (at this point, without
> being overly philosophical like "both are equally good etc.etc." ) that
> would be great help to people who're jut beginning to wade into these
> waters. At  the first look it does appear that MEGACO is a lot of work as
> compared to MGCP ... but what does it offer in return ? are companies
> betting more on MEGACO as compared to MGCP ? or is the jury still out ?
>
> ( yeah, I wish I could attend a few VON seminars but then I live about
> 12000 miles away from the US :-( )
>
>
>
> -Venu
>
> * What's Voice without IP ? *
>
> ( aren't I optimistic ? )
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr 25 06:05:19 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07668
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 25 Apr 2000 06:05:19 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4617AB70@standards.nortelnetworks.com>; Tue, 25 Apr 2000 5:58:26 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 13204 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Apr 2000 05:57:22 -0400
Received: from smtprich.nortel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.1F4FFF10@standards.nortelnetworks.com>; Tue, 25 Apr 2000 5:57:21
          -0400
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprich.nortel.com; Tue, 25 Apr 2000 05:04:10 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <JSPANZTK>; Tue, 25 Apr 2000 05:03:00 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFAE9D.6F89A676"
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B6F7@zcard00g.ca.nortel.com>
Date:         Tue, 25 Apr 2000 05:03:00 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: clarification
X-To:         "marc_mathew@mailcity.com" <marc_mathew@mailcity.com>
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_01BFAE9D.6F89A676
Content-Type: text/plain

This is a leftover from Santiago, when we firmed up the set of descriptors
needed to describe a termination.  Mike Buckley had an insight: let the
descriptors form a hierarchy, describing the termination from the physical
layer upwards.  We didn't really follow through on that thought, but the
modem descriptor got left in the schema more or less through oversight.
It's a bit late to delete it, but maybe in H.248v2 it could be deprecated
and replaced by a property in another descriptor.

> -----Original Message-----
> From: Marc Mathew [SMTP:marc_mathew@MAILCITY.COM]
> Sent: Thursday, April 06, 2000 8:06 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      clarification
>
> Hi,
>
>    Can anyone please tell me what modem descriptor is used for. Should
> modem not be specified as a seperate package (NAS ?). Isn't modem a
> different kind of termination. Why is there a seperate descriptor for it.
>
> Always,
> Marc
>
>
> Send FREE April Fool's Greetings to your friends!
> http://www.whowhere.lycos.com/redirects/American_Greetings.rdct

------_=_NextPart_001_01BFAE9D.6F89A676
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: clarification</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">This is a leftover =
from Santiago, when we firmed up the set of descriptors needed to =
describe a termination.&nbsp; Mike Buckley had an insight: let the =
descriptors form a hierarchy, describing the termination from the =
physical layer upwards.&nbsp; We didn't really follow through on that =
thought, but the modem descriptor got left in the schema more or less =
through oversight.&nbsp; It's a bit late to delete it, but maybe in =
H.248v2 it could be deprecated and replaced by a property in another =
descriptor.</FONT></P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Marc Mathew =
[SMTP:marc_mathew@MAILCITY.COM]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Thursday, April 06, 2000 8:06 AM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">clarification</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; Can anyone please tell me =
what modem descriptor is used for. Should modem not be specified as a =
seperate package (NAS ?). Isn't modem a different kind of termination. =
Why is there a seperate descriptor for it.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Always,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Marc</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Send FREE April Fool's Greetings to =
your friends!</FONT>
<BR><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://www.whowhere.lycos.com/redirects/American_Greetings.rdct"=
 =
TARGET=3D"_blank">http://www.whowhere.lycos.com/redirects/American_Greet=
ings.rdct</A></FONT></U>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFAE9D.6F89A676--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr 25 06:11:13 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07719
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 25 Apr 2000 06:11:13 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1E4EED50@standards.nortelnetworks.com>; Tue, 25 Apr 2000 6:04:29 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 13232 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Apr 2000 06:04:20 -0400
Received: from smtprtp.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.189E2BA0@standards.nortelnetworks.com>; Tue, 25 Apr 2000 6:04:20
          -0400
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          smtprtp.ntcom.nortel.net; Tue, 25 Apr 2000 06:06:21 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <27B9PA4A>; Tue, 25 Apr 2000 06:06:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFAE9D.E356807E"
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B6F8@zcard00g.ca.nortel.com>
Date:         Tue, 25 Apr 2000 06:06:11 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: EventBufferDescriptor question
X-To:         Flemming Andreasen <fandreas@CISCO.COM>
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_01BFAE9D.E356807E
Content-Type: text/plain

Looks like an error to me.

> -----Original Message-----
> From: Flemming Andreasen [SMTP:fandreas@CISCO.COM]
> Sent: Friday, April 07, 2000 3:46 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      EventBufferDescriptor question
>
> Considering the definition given in Section 7.1.10, can somebody explain
> why EventBufferDescriptor is defined as "sequence of ObservedEvent" ?
>
> Thanks
>
>         Flemming
>
> --
> Flemming Andreasen                Phone: +1 732 452 1667
> Cisco Systems                     Fax:   +1 240 359 5839

------_=_NextPart_001_01BFAE9D.E356807E
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: EventBufferDescriptor question</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Looks like an error =
to me.</FONT>
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Flemming Andreasen =
[SMTP:fandreas@CISCO.COM]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Friday, April 07, 2000 3:46 PM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">EventBufferDescriptor =
question</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Considering the definition given in =
Section 7.1.10, can somebody explain</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">why EventBufferDescriptor is defined =
as &quot;sequence of ObservedEvent&quot; ?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks</FONT>
</P>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Flemming</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">--</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Flemming =
Andreasen&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; Phone: +1 732 452 1667</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Cisco =
Systems&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Fax:&nbsp;&nbsp; +1 240 359 5839</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFAE9D.E356807E--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr 25 06:27:23 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07843
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 25 Apr 2000 06:27:23 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5BE43CE0@standards.nortelnetworks.com>; Tue, 25 Apr 2000 6:20:32 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 13260 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Apr 2000 06:19:53 -0400
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.44BAAC20@standards.nortelnetworks.com>; Tue, 25 Apr 2000
          6:19:53 -0400
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Tue, 25 Apr 2000 05:18:59 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <JSPANZ44>; Tue, 25 Apr 2000 05:18:50 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFAE9F.A5CCEA2A"
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B6F9@zcard00g.ca.nortel.com>
Date:         Tue, 25 Apr 2000 05:18:50 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Brief == TimeOut ?
X-To:         Flemming Andreasen <fandreas@CISCO.COM>
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_01BFAE9F.A5CCEA2A
Content-Type: text/plain

I've been saying that for a long time.

> -----Original Message-----
> From: Flemming Andreasen [SMTP:fandreas@CISCO.COM]
> Sent: Friday, April 07, 2000 6:36 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Brief == TimeOut ?
>
> As the spec currently reads (incl. Tom's list), it seems to me that the
> signalTypes Brief and TimeOut are semantically identical.- am I missing
> something ?
>
>
> Thanks
>
>         Flemming
>
> --
> Flemming Andreasen                Phone: +1 732 452 1667
> Cisco Systems                     Fax:   +1 240 359 5839

------_=_NextPart_001_01BFAE9F.A5CCEA2A
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: Brief =3D=3D TimeOut ?</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I've been saying =
that for a long time.</FONT>
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Flemming Andreasen =
[SMTP:fandreas@CISCO.COM]</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Friday, April 07, 2000 6:36 PM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Brief =3D=3D TimeOut ?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">As the spec currently reads (incl. =
Tom's list), it seems to me that the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">signalTypes Brief and TimeOut are =
semantically identical.- am I missing</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">something ?</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks</FONT>
</P>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Flemming</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">--</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Flemming =
Andreasen&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; Phone: +1 732 452 1667</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Cisco =
Systems&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Fax:&nbsp;&nbsp; +1 240 359 5839</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFAE9F.A5CCEA2A--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr 25 06:47:26 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08160
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 25 Apr 2000 06:47:26 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.29263FD0@standards.nortelnetworks.com>; Tue, 25 Apr 2000 6:40:35 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 13301 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Apr 2000 06:38:55 -0400
Received: from smtprich.nortel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.ED9512C0@standards.nortelnetworks.com>; Tue, 25 Apr 2000 6:38:55
          -0400
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprich.nortel.com; Tue, 25 Apr 2000 05:45:46 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <JSPANZW9>; Tue, 25 Apr 2000 05:44:36 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B6FA@zcard00g.ca.nortel.com>
Date:         Tue, 25 Apr 2000 05:44:36 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: DIgit Map specification with Reset Dialing
X-To:         M S N Murthy <murtymsn@AXES-MACH01.DSCCC.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

> -----Original Message-----
> From: M S N Murthy [SMTP:murtymsn@AXES-MACH01.DSCCC.COM]
> Sent: Monday, April 10, 2000 10:51 AM
>
> Problem 1.   Is there a way for the MGC to request the MG to detect   '#'
> and notify while specifying a Digit Map?
>      This is necessary when MGC wants to cancel the previous user dialed
> digits on '#' dialing.
        [PTT]
        Yes.  If you look at section E.6 you see that the octothorpe event
"do" maps to digit map symbol "f" or "F".
>
> Problem 2.  MGC specifies a list of Digit Strings  in a Digit Map to MG.
> The MG notifies to the MGC when a matching digit string
>      is dialed. Is there a way for the MGC to find out the matching digit
> string notified by the MG without performing the string comparisons?
        [PTT]
        Not currently.  Seems like an unfortunate lack.  Maybe in v2 ...
>
>
>
> Thanks,
> Murthy
>
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr 25 07:17:32 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08723
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 25 Apr 2000 07:17:32 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5D1DA310@standards.nortelnetworks.com>; Tue, 25 Apr 2000 7:10:40 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 13361 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Apr 2000 07:08:57 -0400
Received: from ws9.cdotb.ernet.in (202.41.72.121) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.B7EF3800@standards.nortelnetworks.com>; Tue, 25 Apr 2000
          6:58:53 -0400
Received: from jnana.cdotb.ernet.in (ws61 [202.41.72.173]) by
          ws9.cdotb.ernet.in (8.9.3/8.9.3) with ESMTP id QAA24884 for
          <megaco@standards.nortelnetworks.com>; Tue, 25 Apr 2000 16:32:28
          +0500 (GMT+0500)
Received: from cdotb.ernet.in by jnana.cdotb.ernet.in
          (8.8.8/1.1.22.3/13Apr00-1149AM) id QAA0000020042; Tue, 25 Apr 2000
          16:30:27 +0500 (GMT+0500)
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3905C963.486A4914@cdotb.ernet.in>
Date:         Tue, 25 Apr 2000 22:05:47 +0530
Reply-To: rprakash@cdotb.ernet.in
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Prakash R <rprakash@cdotb.ernet.in>
Organization: C-DOT (Center for Development of Telematics)
Subject:      Package for digital trunk with CAS signalling
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

I was trying to work out a call flow for the following setup:

Configuration                   : Trunking Gateway.
Incoming Trunk                  : Digital Trunk (E1, 2.048Mbps)
Incoming Line signaling         : CAS
Incoming Register signaling     : Both Decadic and MFR2

I was unable to trace a call through. Basically, I'm not clear about
which packages to be used. The R2 package gives line signaling also.
But, what do I do for CAS + Decadic combination?

Could anybody give me some suggestions?

- Regards,
--
Prakash R
Co-ordinating Engineer, Internet Telephony Group
===========================================================================
C-DOT (Centre for Development of Telematics)
71/1, Sneha Complex, Miller Road, Bangalore - 560052, India
Email:rprakash@cdotb.ernet.in, Phone:+91-80-2263399, Fax:+91-80-2263256
===========================================================================


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr 25 07:19:57 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08758
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 25 Apr 2000 07:19:57 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A5D55C10@standards.nortelnetworks.com>; Tue, 25 Apr 2000 7:12:42 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 13378 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Apr 2000 07:12:17 -0400
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.96D6DBD0@standards.nortelnetworks.com>; Tue, 25 Apr 2000
          7:12:17 -0400
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Tue, 25 Apr 2000 06:18:35 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <JSPANZ72>; Tue, 25 Apr 2000 06:18:26 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B6FB@zcard00g.ca.nortel.com>
Date:         Tue, 25 Apr 2000 06:18:27 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Responses to Commands.
X-To:         Shalini Philip <sphilip@FICON-TECH.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Sounds like a good possibility.  Any further comments?

> -----Original Message-----
> From: Shalini Philip [SMTP:sphilip@FICON-TECH.COM]
> Sent: Tuesday, April 11, 2000 9:13 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Responses to Commands.
>
> Hello all,
>     In the mail sent by Tom Taylor on "Summary of Issues Raised On the
> List", there was an item in the section on "Errors for which corrections
> are stated" :
>
>    D.1        Even in the case of handoff     In the last sentence of
>               or failover, the originating          the first paragraph,
>
>               MGC needs confirmation that   delete the excepting
>               its command was received.       clause, so that the
>                                                               sentence
> reads:
>                                                               "Responses
> must be sent
>                                                               to the
> address and port
>                                                               from which
> the
>
> corresponding commands
>                                                               were
> sent."
>
>     I think we are right in saying that the response to handoff/failover
> should be sent to the originator of the command. However we also need to
> add the information of what to do about the responses to outstanding
> commands when an MGC performs a handoff. They should be sent to the new
> (to which handoff happened) MGC only. Thus IMO, the above sentence
> should be changed to :
>
> "Responses must be sent to the address and port from which the
> corresponding commands were sent, except in the case of outstanding
> commands after a handoff, where the responses must be sent to the new
> MGC".
>
>
>
> Regards,
>
> Shalini Philip
> Ficon Technology
> E-Mail : mailto:sphilip@ficon-tech.com
> Web    : http://www.ficon-tech.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr 25 07:49:52 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09506
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 25 Apr 2000 07:49:52 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D821F580@standards.nortelnetworks.com>; Tue, 25 Apr 2000 7:42:44 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 13410 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Apr 2000 07:41:23 -0400
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.421F5C40@standards.nortelnetworks.com>; Tue, 25 Apr 2000 7:31:23
          -0400
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id HAA00856; Tue, 25 Apr
          2000 07:37:36 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id HAA16151; Tue, 25 Apr
          2000 07:37:37 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <2MSF6HJC>; Tue, 25 Apr 2000 07:32:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF6781FE@whq-msgusr-02.fore.com>
Date:         Tue, 25 Apr 2000 07:37:27 -0400
Reply-To: "Rosen, Brian" <brosen@FORE.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <brosen@FORE.COM>
Subject:      Re: Open Issue: Sublist vs. Alternatives
X-To:         Tom-PT Taylor <taylor@nortelnetworks.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Works for me

Brian

> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> Sent: Monday, April 24, 2000 10:27 PM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Open Issue: Sublist vs. Alternatives
>
>
> In production alternativeValue in Annex B.2, we still have
> the open issue
> that the syntax for over-specification and that for sub-lists
> is apparently
> the same: LSBRKT VALUE *(COMMA VALUE) RSBRKT.  How about
> enclosing sub-lists
> in square brackets and sets of alternative values in curly brackets?
> Combined with an accepted fix for ranges this gives:
>
>  alternativeValue = (VALUE
>    ; single
> value
>        /  LSBRKT VALUE *(COMMA VALUE) RSBRKT  ; sub-list
>        /  LBRKT VALUE *(COMMA VALUE) RBRKT      ; alternatives
>        /   LSBRKT VALUE COLON VALUE RSBRKT )   ; range
>
> ASN.1 encoding also lacks sub-list support.  I suggest that
> it be added as a
> BOOLEAN choice in extrainfo within the PropertyParm production.
>
>
> Tom Taylor
> Phone and FAX: +1 613 736 0961
> E-mail: taylor@nortelnetworks.com
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr 25 07:53:40 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09645
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 25 Apr 2000 07:53:39 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.689BE3F0@standards.nortelnetworks.com>; Tue, 25 Apr 2000 7:46:47 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 13411 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Apr 2000 07:46:45 -0400
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.01C05E00@standards.nortelnetworks.com>; Tue, 25 Apr 2000 7:36:45
          -0400
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id HAA01204; Tue, 25 Apr
          2000 07:42:57 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id HAA16667; Tue, 25 Apr
          2000 07:42:58 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <2MSF6HLG>; Tue, 25 Apr 2000 07:37: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:  <4FBEA8857476D311A03300204840E1CF6781FF@whq-msgusr-02.fore.com>
Date:         Tue, 25 Apr 2000 07:42:52 -0400
Reply-To: "Rosen, Brian" <brosen@FORE.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <brosen@FORE.COM>
Subject:      Re: Side Effects on streams or termination
X-To:         Tom-PT Taylor <taylor@nortelnetworks.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I agree with your interpretation - there is ONE eventDescriptor,
ONE eventBuffer, ONE signals list, and side effects like events
stopping signals occur for all the signals in the Signals descriptor,
all the events in the Events descriptor, etc.

Brian

> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> Sent: Monday, April 24, 2000 11:47 PM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: Side Effects on streams or termination
>
>
> The following message from Hemant Kumar hasn't gotten through
> except as a
> bounce message, for some reason, so I'm forwarding it.  My
> response is that
> I believe current intent is that events detected on one
> stream make their
> side-effects felt on all streams of the termination.  We may
> alter that in
> v2 if experience shows that we should allow a more refined response.
>
> Tom Taylor
> Phone and FAX: +1 613 736 0961
> E-mail: taylor@nortelnetworks.com
>
> Original message:
>
> Hi Everyone,
>
>      The event descriptor provides for detection of events on a =
> particular stream by means of the parameter :eventStream
> (eventStream =
> =3D StreamToken EQUAL StreamID). However I couldn't find any
> mention of =
> whether the side effect of event detected on a particular
> stream within =
> a termination are limited to that stream only and not all the
> streams on =
> the termination.
>
> Let me take an example :
>          There are 2 streams Audio and Video on a termination. =
> EventBufferControl is set to Lockstep for the termination and
> Events are =
> being detected according to Event descriptor. The events
> being looked =
> for on Audio and video stream are ( A, B, C ) and (X, Y, Z).
> Also some =
> signals are being applied on both the streams. Suppose event A is =
> detected and Notified. Which out of the following would be the side =
> Effect of event detection.
>
> 1)    Signals on audio stream are stopped (keepactive was not
> specified) =
> and any further events are stored in event buffer.=20
>        Signals continue on Video stream and the events
> (X,Y,Z) are still =
> being detected on Video stream.
> 2)    Signals are stopped on both the streams and both start
> buffering =
> events.=20
>
> Any comments ??
>
> Regards,
> Hemant Kumar
>
> PS : Also find attached my previous mail regarding error codes for =
> termination state changes which went unanswered.
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Hemant Kumar
> Ficon Technology
> E-mail: mailto:hkumar@ficon-tech.com
> Web: http://www.ficon-tech.com
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr 25 08:03:38 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10035
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 25 Apr 2000 08:03:38 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CF9FD970@standards.nortelnetworks.com>; Tue, 25 Apr 2000 7:56:49 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 13463 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Apr 2000 07:55:11 -0400
Received: from smtprtp1.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.95042FF0@standards.nortelnetworks.com>; Tue, 25 Apr 2000 7:55:11
          -0400
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          smtprtp1.ntcom.nortel.net; Tue, 25 Apr 2000 08:01:12 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <27B9PB3Y>; Tue, 25 Apr 2000 08:01:11 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B6FE@zcard00g.ca.nortel.com>
Date:         Tue, 25 Apr 2000 08:01:08 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Command Atomicity and Rollback
X-To:         "Rosen, Brian" <brosen@FORE.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Maybe the best we can do is an implementor's note saying that the MG should
do things in the way you describe, and should seek to avoid commitments of
state until it has determined that the command can be executed.

> -----Original Message-----
> From: Rosen, Brian [SMTP:brosen@FORE.COM]
> Sent: Friday, April 14, 2000 3:57 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: Command Atomicity and Rollback
>
> I've had this argument many times before, and always lost it, I think to
> the determent of
> both the protocol, and the resulting system.
>
> First of all, you can't audit to find out the state of an MG to the level
> of what happened on
> a broken command without a pretty major amount of code.  I think it is
> possible, but I think
> it's hard.   There is transient state you would not reasonably be able to
> figure out - a short
> BRief signal, for example.
>
> It is quite straightforward to build an MG to have "rollback" semantics,
> even at the transaction
> level.  It requires that you construct the code so that errors are
> detectable before state is
> changed, rather than after.  This is always possible - we only argue about
> how hard it is.
> It is also always possible to put state back, but I agree that it is
> sometimes hard.
>
> Certainly, at the level of a command:
>     You should be parsing the whole command before executing any of it
>     You should be checking availability of resources either
> simultaneously, or
>         prior to reserving them
>     It should be straightforward to do all of the above before actually
> doing state
>         changes (reserving resources not counted as "state change")
>     There are VERY few non-fatal errors that are not detected by the
> above, that
>         would cause a rollback problem.  Might be a couple, but special
> casing them
>         should not be very hard.
>
> I believe that MGC out of sync with MG is a very bad problem
> Audit to determine state at the level of a descriptor in a command is very
> hard
> Avoiding state change before determining almost all errors is pretty easy
> Fixing the few cases where it isn't possible to determine the error is not
> very hard.
>
> I'll agree that it is harder to design MG code that does this, compared to
> an MG that doesn't
> care a whit what the MGC has to do to figure out what state it is in.
>
> I don't think there are any cases where "roll back" doesn't make sense.
> You cited:
>     Signals - if the command has an error, I don't want signals specified
> in an earlier
>         descriptor sent.  I want the whole command to fail
>     Events - if the command has an error, I don't want events in a new
> events descriptor
>         to be detected - I want the old events descriptor to be active
>
> You specifically raised the issue of embedded signals or events.  If the
> syntax of the
> descriptors is wrong, then that should be detected with the original
> command.  Otherwise,
> the detection has to be when the first event is detected, and the embedded
> event is
> activated.  If it fails, the prior signals and events descriptors should
> be "restored".  Of course,
> I would say they were never changed if there were, for example,
> insufficient resources
> available for the embedded events following detection of the original
> event.
>
> I believe that there are many "recoverable" errors.  If there weren't,
> then we should make
> errors fatal, and specify that contexts are taken down, terminations set
> to default state, etc.
> Without the MGC knowing the MG state, recovery is very difficult.
>
> Brian
>
>       -----Original Message-----
>       From: Hemant [mailto:hkumar@ficon-tech.com]
>       Sent: Thursday, April 13, 2000 12:18 AM
>       To: MEGACO@standards.nortelnetworks.com
>       Subject: Command Atomicity and Rollback
>
>
>       Hi everyone,
>
>           The discussions till date on the issue of rollback of command in
> case of its failure do not seem to lead to a clear consensus. Lets look at
> the issue from the point of view of both the MG as well as the MGC.
>
>           From an MG point of view, the MG will always have to maintain
> duplicate state information. One of the current state (after execution of
> descriptor) and another for what existed previous to it while executing
> the command. This would be a lot of overhead in terms of memory and
> implementation complexity. Also there might cases where rollback doesn't
> make sense (signals, event detection etc). Another clarification required
> is whether commands with embedded events and signals also be considered
> atomic? (in case the embedded signal or event encounters error, what will
> the MG rollback to)
>
>            As far as the MGC is concerned, it wants to know the status of
> the termination on which command was executed. This can be determined by
> Auditing the termination.
>           Another MGC concern may be that since the command can fail at
> any point, one would think that without rollback implementation, the MGC
> handling following a failed command would be very complex. The typical
> action of the MGC however in such cases is to follow up with an error
> treatment(like playing an error tone or taking the termination out of
> context or allocating some other termination etc). Will going back to the
> previous status really help the MGC implementation ? If the reason for
> rollback is to bring the termination into a state known to the MGC, it can
> be achieved by auditing the termination upon receiving the error response.
>
>           Considering the above I would favour that rollback not be
> mandatory. Instead on encountering an error, the MG should stop further
> command processing.
>
>       Any Comments ??
>
>       Regards,
>       Hemant
>       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>       Hemant Kumar
>       Ficon Technology
>       E-mail: <mailto:hkumar@ficon-tech.com>
>       Web: <http://www.ficon-tech.com>
>       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr 25 08:54:43 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11284
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 25 Apr 2000 08:54:38 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.85BF2CA0@standards.nortelnetworks.com>; Tue, 25 Apr 2000 8:44:52 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 13494 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Apr 2000 08:43:08 -0400
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.72F26DB0@standards.nortelnetworks.com>; Tue, 25 Apr 2000 8:22:52
          -0400
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id SAA10387 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 25 Apr 2000 18:35:21
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          652568CC.0043BE07 ; Tue, 25 Apr 2000 17:49:55 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: multipart/mixed;
              Boundary="0__=5DnV1j7mrOy37Gam7COeoyGPPJynCEMhmXOFfzF2oo1OG521V0WiyrWs"
Content-Disposition: inline
Message-ID:  <652568CC.0043B763.01@sandesh.hss.hns.com>
Date:         Tue, 25 Apr 2000 17:49:36 +0530
Reply-To: smahajan@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Sunil Mahajan <smahajan@HSS.HNS.COM>
Subject:      Conformance Test Specifications for SCTP
X-To:         SIGTRAN-TEST@STANDARDS.NORTELNETWORKS.COM
X-cc:         SIGTRAN@STANDARDS.NORTELNETWORKS.COM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--0__=5DnV1j7mrOy37Gam7COeoyGPPJynCEMhmXOFfzF2oo1OG521V0WiyrWs
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline




Hi All,

As the need for Interoperability for all new protocols and standards
is high, we at HSS are working on producing conformance test
specifications for new VoIP protocols (which includes SIGTRAN
and MEGACO).

As first step in that direction, attached is the document (PDF) presenting
conformance test specification for SCTP (draft 07) protocol. The test
specification include tests required for SCTP implementation conformance
against standard definition, except tests for calculation of timer values
(related to congestion and retransmmiting) which will be added with
the next release of the document (this will also include tests for
SCTP draft-09).

This specification can be used for conformance testing of implementations, plus
all the tests or a part of it (subset) can also be used for the planned bake-off
testing
(5-9th June).

The same specification will be submitted as text file (IETF draft) to IETF soon.

Regards,
Sunil Mahajan
HSS VoIP Group

(See attached file: Sctp07ConformanceTestSpec.pdf)

--0__=5DnV1j7mrOy37Gam7COeoyGPPJynCEMhmXOFfzF2oo1OG521V0WiyrWs
Content-type: application/pdf;
        name="Sctp07ConformanceTestSpec.pdf"
Content-Disposition: attachment; filename="Sctp07ConformanceTestSpec.pdf"
Content-Description: Adobe Portable Document
Content-Transfer-Encoding: base64

JVBERi0xLjINJeLjz9MNCjQ4MiAwIG9iag08PCANL0xpbmVhcml6ZWQgMSANL08gNDg0IA0vSCBb
IDkwMyA2MjQgXSANL0wgMzk4NDAxIA0vRSA5Njk0IA0vTiAxMDYgDS9UIDM4ODY0MiANPj4gDWVu
ZG9iag0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB4cmVmDTQ4MiAxOCANMDAwMDAwMDAxNiAwMDAwMCBuDQowMDAwMDAwNzExIDAwMDAwIG4NCjAw
MDAwMDE1MjcgMDAwMDAgbg0KMDAwMDAwMTY4NSAwMDAwMCBuDQowMDAwMDAxOTA4IDAwMDAwIG4N
CjAwMDAwMDI0MjAgMDAwMDAgbg0KMDAwMDAwMjYwMSAwMDAwMCBuDQowMDAwMDAyODAwIDAwMDAw
IG4NCjAwMDAwMDI4NTIgMDAwMDAgbg0KMDAwMDAwMzI5NiAwMDAwMCBuDQowMDAwMDAzNjcxIDAw
MDAwIG4NCjAwMDAwMDM4NTMgMDAwMDAgbg0KMDAwMDAwNDA2MCAwMDAwMCBuDQowMDAwMDA0NTI1
IDAwMDAwIG4NCjAwMDAwMDQ2MDQgMDAwMDAgbg0KMDAwMDAwNTA2NCAwMDAwMCBuDQowMDAwMDAw
OTAzIDAwMDAwIG4NCjAwMDAwMDE1MDUgMDAwMDAgbg0KdHJhaWxlcg08PA0vU2l6ZSA1MDANL0lu
Zm8gNDY4IDAgUiANL1Jvb3QgNDgzIDAgUiANL1ByZXYgMzg4NjMxIA0vSURbPDE5YTYyYjIyNDRj
M2UxZDU3YTI5YTM1M2M4Y2NlZDJkPjwxOWE2MmIyMjQ0YzNlMWQ1N2EyOWEzNTNjOGNjZWQyZD5d
DT4+DXN0YXJ0eHJlZg0wDSUlRU9GDSAgICANNDgzIDAgb2JqDTw8IA0vVHlwZSAvQ2F0YWxvZyAN
L1BhZ2VzIDQ4MCAwIFIgDS9PdXRsaW5lcyAzNTUgMCBSIA0vT3BlbkFjdGlvbiBbIDQ4NCAwIFIg
L1hZWiBudWxsIG51bGwgbnVsbCBdIA0vUGFnZU1vZGUgL1VzZU5vbmUgDS9QYWdlTGFiZWxzIDw8
IC9OdW1zIFsgLTIgPDwgL1MgL0QgL1N0IC0xID4+IF0gPj4gDT4+IA1lbmRvYmoNNDk4IDAgb2Jq
DTw8IC9TIDE5MDYgL08gMTk3NSAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDQ5OSAwIFIg
Pj4gDXN0cmVhbQ0KSIliYGBgBqJ2BlYGBjZ7Bl4GBOBlYAGKsjBwROgFMFAITjSk3GtgYJXtceQ4
oWkgwHCuKevQZ62zIcfrPasUeg7lLzm+vOeb2jcjwZ1nJ5R9qVmamu8jp5+5IvBE2BW/mXOOsLdY
M27zU/FyZZzZa5fhqM6keW5W0uNzohLz23h8GU/6Xiu5Yj51zuuUOsOX2zr78orldXJLXvyIuHQj
QC1o0svVDi880h0eFvZ4ZCyeupRj57LH6pmFbS9CPkUJ71nDfEcvMJp7Wf2hSfw1s5+Gqx1cdWDl
kjNvVp3BAKdWrcEUhAOIPw2sz74TFFNZMWHBs69nH0e/NOIS7Xiaem1yDbug0KXoh0Zczb2pKbIl
M1k+HhN1vPZzwReZxNBDW2TSSmyhYtc9J/jLJIbIjnIhITQhBBhCBz8vcQ+RzZ/J6nhMNEbeyqV0
sLhvlIuNm8DAoOTSAcwNSg1AwqWBAUQxCIJIQUEIWwkhBJKFCrsgkaF4SfwqXXCQxKjBr4tUNyCz
G7Cw8OszRiJx2YnJxuVX/CFKjC/xm0yJLeS5ByYypGoXBgbGCAbWaS1Al/MBsSTICwwmDLzMAVqH
Z3AIeDYwGDI6swioHbZi3HDGVYN9kQJ/QWQjC8cBryYdQQUp9gSwBgbGZAbWRXpARiEDg6McQIAB
ABvabYoNZW5kc3RyZWFtDWVuZG9iag00OTkgMCBvYmoNNTA2IA1lbmRvYmoNNDg0IDAgb2JqDTw8
IA0vVHlwZSAvUGFnZSANL1BhcmVudCA0NjkgMCBSIA0vUmVzb3VyY2VzIDQ4NSAwIFIgDS9Db250
ZW50cyA0OTAgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2
MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag00ODUgMCBvYmoNPDwgDS9Qcm9jU2V0IFsg
L1BERiAvVGV4dCAvSW1hZ2VDIC9JbWFnZUkgXSANL0ZvbnQgPDwgL1RUMiA0ODYgMCBSIC9UVDQg
NDkxIDAgUiAvVFQ2IDQ5NCAwIFIgPj4gDS9YT2JqZWN0IDw8IC9JbTEgNDk3IDAgUiA+PiANL0V4
dEdTdGF0ZSA8PCAvR1MxIDQ5NSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgNDg3IDAgUiAv
Q3M5IDQ4OSAwIFIgPj4gDT4+IA1lbmRvYmoNNDg2IDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1
YnR5cGUgL1RydWVUeXBlIA0vRmlyc3RDaGFyIDMyIA0vTGFzdENoYXIgMTIyIA0vV2lkdGhzIFsg
MjUwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNTcwIDI1MCAzMzMgMjUwIDAgNTAwIDUwMCA1MDAgNTAw
IDUwMCA1MDAgDTUwMCA1MDAgNTAwIDUwMCAzMzMgMCA1NzAgNTcwIDAgMCAwIDcyMiA2NjcgNzIy
IDcyMiA2NjcgNjExIDc3OCANNzc4IDM4OSAwIDc3OCA2NjcgOTQ0IDcyMiA3NzggNjExIDAgNzIy
IDU1NiA2NjcgNzIyIDcyMiAxMDAwIDcyMiANNzIyIDAgMCAwIDAgMCA1MDAgMCA1MDAgNTU2IDQ0
NCA1NTYgNDQ0IDMzMyA1MDAgNTU2IDI3OCAzMzMgNTU2IA0yNzggODMzIDU1NiA1MDAgNTU2IDU1
NiA0NDQgMzg5IDMzMyA1NTYgNTAwIDcyMiA1MDAgNTAwIDQ0NCBdIA0vRW5jb2RpbmcgL1dpbkFu
c2lFbmNvZGluZyANL0Jhc2VGb250IC9UaW1lc05ld1JvbWFuUFMtQm9sZE1UIA0vRm9udERlc2Ny
aXB0b3IgNDg4IDAgUiANPj4gDWVuZG9iag00ODcgMCBvYmoNWyANL0NhbFJHQiA8PCAvV2hpdGVQ
b2ludCBbIDAuOTUwNSAxIDEuMDg5IF0gL0dhbW1hIFsgMi4yMjIyMSAyLjIyMjIxIDIuMjIyMjEg
XSANL01hdHJpeCBbIDAuNDEyNCAwLjIxMjYgMC4wMTkzIDAuMzU3NiAwLjcxNTE5IDAuMTE5MiAw
LjE4MDUgMC4wNzIyIDAuOTUwNSBdID4+IA0NXQ1lbmRvYmoNNDg4IDAgb2JqDTw8IA0vVHlwZSAv
Rm9udERlc2NyaXB0b3IgDS9Bc2NlbnQgODkxIA0vQ2FwSGVpZ2h0IDAgDS9EZXNjZW50IC0yMTYg
DS9GbGFncyAzNCANL0ZvbnRCQm94IFsgLTE4NCAtMzA3IDEwODkgMTAyNiBdIA0vRm9udE5hbWUg
L1RpbWVzTmV3Um9tYW5QUy1Cb2xkTVQgDS9JdGFsaWNBbmdsZSAwIA0vU3RlbVYgMTMzIA0+PiAN
ZW5kb2JqDTQ4OSAwIG9iag1bIA0vSW5kZXhlZCA0ODcgMCBSIDI1NSA0OTYgMCBSIA1dDWVuZG9i
ag00OTAgMCBvYmoNPDwgL0xlbmd0aCAzNjkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh
bQ0KSIk8klFLwzAQx9/zKe4xAXtL0jRJQYRtytAHURt8cT6M0krBrbMd+PW9XjsJJP9c7prf/dNN
EquULBhIrTARNA1ajC0xeO3BRYcR0lGstmMB9cgJGsZarHaVga9RaNTa5JBqVhbSr/iQsO1PyqGR
rTKyH46HeVc3kJpR5RjlRQX0EiqOn3lu6q7tVEGH9eHSLR+AtldRDkvilmoLmV4yHdRneprY3cLu
ULsZn5XNKZM78AEjtzDx6X/SvJxR35sBjCrRSVRZjqXUoCJdspfr89B9k44SbMEZN2C1ZqX3igEe
kjAwDXLEQAciWLrdQNAaPfnoC/SQWUPz0IhWbNhvPzOXWHpGZsGVBOxLg84x8NXrjE0OV3QXZvTb
6nGXVGYCAb2pbOJaPwNFCsxlM3Xj5XiB6qyygOEaqeelo0J6nmxRS/Qwp5L9szjdXdv8EcbGycmJ
yXm0kEfaM3ERp2Zr+ksejwbue/Eq/gQYAL7Wg3UKZW5kc3RyZWFtDWVuZG9iag00OTEgMCBvYmoN
PDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHJ1ZVR5cGUgDS9GaXJzdENoYXIgMzIgDS9MYXN0
Q2hhciAxMTQgDS9XaWR0aHMgWyAyNzggMCAwIDAgMCAwIDAgMCAzMzMgMzMzIDAgMCAyNzggMCAy
NzggMCA1NTYgNTU2IDU1NiAwIDAgNTU2IDAgMCANMCAwIDAgMCAwIDAgMCAwIDAgNjY3IDAgMCAw
IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA2NjcgDTAgMCAwIDAgMCAwIDAgMCAw
IDAgMCAwIDAgMCA1NTYgMCAwIDAgMjIyIDAgMCAyMjIgMCAwIDAgNTU2IDAgMzMzIA1dIA0vRW5j
b2RpbmcgL1dpbkFuc2lFbmNvZGluZyANL0Jhc2VGb250IC9BcmlhbE1UIA0vRm9udERlc2NyaXB0
b3IgNDkyIDAgUiANPj4gDWVuZG9iag00OTIgMCBvYmoNPDwgDS9UeXBlIC9Gb250RGVzY3JpcHRv
ciANL0FzY2VudCA5MDUgDS9DYXBIZWlnaHQgMCANL0Rlc2NlbnQgLTIxMSANL0ZsYWdzIDMyIA0v
Rm9udEJCb3ggWyAtMjIyIC0zMjUgMTA3MiAxMDM3IF0gDS9Gb250TmFtZSAvQXJpYWxNVCANL0l0
YWxpY0FuZ2xlIDAgDS9TdGVtViAwIA0+PiANZW5kb2JqDTQ5MyAwIG9iag08PCANL1R5cGUgL0Zv
bnREZXNjcmlwdG9yIA0vQXNjZW50IDg5MSANL0NhcEhlaWdodCAwIA0vRGVzY2VudCAtMjE2IA0v
RmxhZ3MgOTggDS9Gb250QkJveCBbIC0xODQgLTMwNyAxMjA2IDEwMzIgXSANL0ZvbnROYW1lIC9U
aW1lc05ld1JvbWFuUFMtQm9sZEl0YWxpY01UIA0vSXRhbGljQW5nbGUgLTE1IA0vU3RlbVYgMTMz
IA0+PiANZW5kb2JqDTQ5NCAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UcnVlVHlw
ZSANL0ZpcnN0Q2hhciAzMiANL0xhc3RDaGFyIDExOCANL1dpZHRocyBbIDI1MCAwIDAgMCAwIDAg
MCAwIDAgMCAwIDAgMCAwIDI1MCAwIDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIA0wIDAg
MzMzIDAgNTcwIDAgNTcwIDAgMCA2NjcgMCA2NjcgNzIyIDY2NyA2NjcgNzIyIDAgMzg5IDAgMCA2
MTEgDTg4OSA3MjIgNzIyIDYxMSAwIDY2NyA1NTYgNjExIDcyMiAwIDAgMCAwIDAgMCAwIDAgMCAw
IDAgNTAwIDAgNDQ0IA01MDAgNDQ0IDMzMyA1MDAgMCAyNzggMCA1MDAgMjc4IDc3OCA1NTYgNTAw
IDUwMCAwIDM4OSAzODkgMjc4IDU1NiANNDQ0IF0gDS9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5n
IA0vQmFzZUZvbnQgL1RpbWVzTmV3Um9tYW5QUy1Cb2xkSXRhbGljTVQgDS9Gb250RGVzY3JpcHRv
ciA0OTMgMCBSIA0+PiANZW5kb2JqDTQ5NSAwIG9iag08PCANL1R5cGUgL0V4dEdTdGF0ZSANL1NB
IGZhbHNlIA0vU00gMC4wMiANL1RSIC9JZGVudGl0eSANPj4gDWVuZG9iag00OTYgMCBvYmoNPDwg
L0xlbmd0aCAzODUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIk8UVuRw0AM06Io
hTIwhEAoBEMIhUIwhVAIBVEIhlDQSZmbevLj2KuXAdcLeAMFbMAHaGAHvsAAB3ACBC7gBvRbLVSh
C1NgQb+XjWp0Yxps6Ac0qEEPZsCBfrhEEU0MQUL/NPlKaGEEyt0Lr9fL3O/3+6Gv8BjSr0vpUl01
VaxSR5z77poudmmi1eOemilOiZHu7WYNiyzJTvy4WjUqyhI2bNtmb5/P57FXMWcfluytuK2QGNUw
rQzD6ppudmuShUW4n2lOi4nGmjweNtmSk7JEb/eoKfvese+7s/t+v098lUQdnnOytKRZcWYr1u5H
CbfCaRKjjrIbq/7h4oyY6O3cItyTI/kSDsKaPB7KYR84jmOdOM9zEYu12IuzyOU8cq1KnAFyZkoM
SbDjzFaMkVtWJITGPGJOWxmG1SX50o7bzi3CPbUuXNe1btz3vYSlWuqlWeJS7pAj6zljXiahxK8n
4ABFe4LRYz24RkUk6xEVGhcCpmdd+fEnwAD1BGJVCmVuZHN0cmVhbQ1lbmRvYmoNNDk3IDAgb2Jq
DTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNDgwIC9IZWlnaHQgMTcy
IC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDQ4OSAwIFIgL0xlbmd0aCA0MzA3IC9G
aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ7Jc7chs5EIYV6TAOtTl5iY3k1ORUWVdw
JMWSq8zETsTEm0gHUWIl5oFm5z0A+g1gOJKNH9tbMqfR6AbY84F1/bdou0HH2mmZtWgF1db/V2X0
tz7no+r9+cFM9SvkfTF/+Fw5TJUISem12W63nvHu29Df+JwKa/EHa6BGLxX4iqmxcVW5kOtY/c1q
IlWeJfpb4w3S+4fxGdPNt64Xm4+9FmkrNLK++yX/SJZM/lo/3dBEsK4Ym1FELUJqGlnIpfG3xhuk
446WdBzHrKST/KMzUcwRUtMolUahfxxFthTdXOlJx1EY+IgF8/6x9I0ltlHgrW/0B1nb6DZNE/0p
SnG1YPGslJP2R3sbCCvGbykRe8dqcRrp0pD9I5kmx1FnhvuT7OTn0VWY947V4jTSpSERx0AnwcfK
OMlfQVFkniqikJlKi9NImwZLHIxOqhyRh/o4Kn/1c7IeMn8hM5VSaQT7N+Y3nEB/jGh8OJpgIJaY
Gu9vjQfmkM8VgWQtzV9rFqo11VkijySeWv2NmYE59HNNJHGlpWmkS4P1V5MXzuFWWu++Ifvnou/Z
aUSFZWit+U0LRflZY0n+Ebkp9icXfd8EjWqH2siK8LekKiRBMEByKYzgb41Xy/Stu/2Q42i0NI10
aTI0srPXiYl8vPR9Q9e/1vtJtN4Gf2kaxbB3EO65Pn+ttE7RG6BRK3281PcWiJfob41XBzVFFaHX
mWlUfcW/sGqaJ2PJGk/yj8jPSOsknYdG+6qqBsPDqmmezCtrPMnfnl/eegQtTqOmY4ehiipES+eV
leaSv/12YPVPkpVukj94XrWSsiDoFcbK8W0HMRP9rfEgsePqUGppGhG8Dafh8fLTF8YU3MP14fvK
Fq+OIna0MtJoW22qKpKWOM0he9O/6+e5b7BaoCp6rRw0qmbZadQJp+sC9IUxE/0jMoRVbSOLUayV
SqNN1fVte5FqzU6jLipK8yXoW4OYif7WeDVa12LvaEA4q3/lyxpviIrSawn61iBmor81Xo3WtRiF
jbwE5Oi6dzDsuTULbq0snDLGlPbHuH/4HNtdxaJkGg2KjTcI5dAS9M1z30iIh87JWF8gAz36XkXo
GxnPj41QaAn61iCm1aR4iTlkKNFfSkWP6Ru2AI1q9zekF2oJQqHks5gUD6/L+5xfI0ORs2QaOaRt
bIFfg94s58Nl+ESyTzsi4xnmZKhyEk8AkhM5aeStw8XK8s0WKxIGmbllnnFXE6ol6TF/Vk0G6Rtm
EklMjD4InZJKHRNMoy8sOGae6J+h0j49lB6ACu6IpxGTxuiPfbbNSaZU+sL+zUPtBW4a3Trg3U9R
oeoYYqaRMQvnw2W4lEpf8b5BDLJi5TqRMpAH95fiGbNgM8tQr0i+pfhrzyNHtQ5lOZuKMtNImQXi
j+SRWGunRPqCgiPnofXF3Fx4WYljppEuDcwfySWx2C6qMabkryY3DG0lfYySaWN8TgijlMywGFlj
Sv7KeOjn0t5LuSlkJYCZRsYsnA9hPppQUxyiBivlJP80arK7n+F9xREAnSD9Tov7HYdSCuakC8VT
zEq53PECLUng5tpkoMUwx0gjXSaoP8xLVZQwB9SaOZ4mR08cgc3BHEX98spEIzIXPr+YqozPl46n
WiMpWqfpO2J85y9DI5SwSG6KULnvB8vcN8RVkqK535A3QaMtRljtjSBMgJ9jjZk7nnodsB/qSNPk
iDe+5B9HEJRecb8HpTnWmLnj0UIJbI6S+ItL8rfGC2YJmUbUJz3PzV9FipSw87CHcGR/34v+UfzF
vaNoJK1vzS93PFap/IXfj9w0gr9ZdXlhtI6ikbS+Nb/c8YTVUmgeTq4wAgsxzDRSJUjQOoZG0vrW
/HLHExRP8832ctsbO8QoNhqpeERFi6GRtL41v9zxjPmrp81969AXIbAQx/xrUJMhFe2v4y+Mp51F
d2xWGtWQ6HJyJG0iaCQR20r03PFExdAcuUYNk3PTqA6f65BJ+IJY8vdZIraV6LnjybLT/HIir0/f
Oj+N6gj+Zo1mvh+cOZ4sczTYt536Z5lpFMFfjq5J0dCYi983pARbcXVYoxG35vGpkZayPwIBXhxd
EaiICfL+a8cb59APbTQnyTs8zkujOono2FPj70GR/sbbgRRPXA8T62ej7/ZyGi6Bx8e5aVSbf7MK
bIXRMC/G3/h86XjTHOqhjb5o7zpfntw0qrHfrGQtgbduRS5a/l+ruePNc4iHNvpeovR1lspMoxoF
gi4e7mEksLS2IbdF4s1zFOu1H1xMav+sx49670uUvk44I91U/vA3K1m01UemkuSbcDvIEq+e90dc
r/uAO99LlL5uuMw0QmOScZUrI/H0vlEV6OMpMgPrqPdu+tQ/14vpfJHe9V8MuWlEeOEkiWK0QCbJ
L/d9A8kMH1g16h0hzhfcmsE3LDeNBi/0JxnrIywrx6P8Ag/peShzPMqcJMkbB1kfcb79oTL0zU6j
QQiBHaJQn1vWRYit8YFriwsb41FG7A2dv7uKc74XA5C7GZdbhMBeekvwF/Pjh7BqjTN9eh9xsaU4
1nX1eREVYjlKO0Kc70buXxt/9fRSc4mNEh2RrMe4thTPnkfUjkznO/3n9q9HX+8bmJtGbuURZOKl
jUd+mbEY1jVjc7LtS5iGe77OD6X2YHnUb/PSyHdWkUlYMVheF5POD/hIKwr+6lwsNcA0iPPF6Muz
QCjX5q/gkrAekByRjw28rOvF5qOfg6Uxn29/tA5/2ZeFlYRmcpooo1MMdel8rPmb6qPmmXeEON+g
b9Xf2qxKpK4lZnLc80lDXVH9oSquHYvLI0y+oAaSvkFF3kKcAJcEgc9/wEULaEP0b6e1kytKlte3
yXfXojen5mCZq8h27fSKEkXRd417dNEConp3Wyj8R4jo28LhP0UMfRurels7yaJ4CQQuJH7nYulb
TVZt1060KE4CfQuJ37s0BN5Mnbx2tkVmyfQtLH7XUhLYHWunXGSSlsDel2DtpIv0UtIX2Np5Fyll
InC5V79DGeiLjLWzL5JlJjB4ma9dQdGkq3+uwGcxBIYdfv5aiiY1xzoO7HEEff3RfxmqTXlhn1Uf
rq6uHGM8owkMR1W4vKz+uUKGOCuavlPvQjtDsX+NmkO8wk0dwkxfosOryQYtWPafrauP04jr2kCR
9N2wXTzbElvw5+nf6+vrD9dXrl0FpBVoyygHfb3ehfpaGhro7nocH91x1Rno4LS1chJ44xw6qjzb
8y51e3d72xzoaNfNgU7WHKdrM23zLK0mcHwXD53sWJ7U37Keb9tx19kwrt3OHS3s3LZ3P2bOxUZg
DX2rzvY6y1zNWnp6/vLc2u1od1+arm3t386ue7u9vm6pO9oHn8CZmhZoSQIPphr7d9Pbp9Pv0+n0
dHoerTncedzO484doIcd+i6dcTJ9N9qXdfDC3ne2d20/2cN+v3Thsn6+/jyN41djvxt7Gu25s+fe
xv51Xs63gL53Ln0bO18hVgJHHSjXvY1546GzYOw62z1kLv74+HJ8eXw9vs723+vP1k6vp9Z+nfqu
7TvX7d6noHuftN2buQSFePrqCayk72De2E8WaAcHqU+tHXb3jR0+HT531o0f33709r0fx86G8dgc
cmOvj//19nMeUwc/+d37DLu3szuXwNejTeQ9/8k6Wo2+Yf8yPQzG/WTtOIzj0NlNY4cf4xh0bOyl
+f9LO5re9frX792wf2EPP2P9++zfoLseXvVkZ0UQWP2yBgTe4wR+8G3X2c61XWdhH98PNhzxp+Z4
P4829O83rH9fvP59fZx71+nf3y6Bn7Eedg721iXw2kcKxdLXQOCvldjNZPciYwc7eO5cr3vbcdN1
b2dD/35rGvd7b82htnbs6WvoYK9zTwR9h+5d+xh5eQTW0ddGYDAI+gICw851CXzfEfgwEvhzQGCn
g2f6egTG6EsT+ItP4J6+a5+dXisR+MFMYNC/E30PHn17Ah97Ah+74fbuY9+73u0ZEhjSt+/hN/gu
1onv24ifSw1tAYH3NIF3vlE93NP3fjf070Tf5oy93g37F7s9e/T95dIXEPjL+z1YXyb6KjuZ7F6Z
vg8efb0Ovpk6+Ma5P38f7RgQeOpgSOBf5N257dm1T2QZkZ2spy8g8J4mMBg0fXcdfe9H+n4K6PsZ
uz9THewROKDv2idwHi1EX6aHCfoCAh9cAv/wCHxsrKNvO2y359+ntXd8Jale1oDAe5zAgL6AwLvO
wj6+nwh86Al8MxMY3p7n/n3x+vcVI/Da+/t2RBymuXuRgRD43iOwd3++6enrEPjbTGCfvlQHr72X
b1sm+lY0fQGB8bvzSOD7jsCHkcCfAwJ/w+7PLoHX3rZ3KSuBH8wEBv070ffg0bcn8LEn8LEbj69r
b88fpp6+gMB7msA736ge7ul7vxv6d6Jvc8Ze7/5Yewf+OmnuzkT33mMEvpk6uKHv2sUVqeQSeNDa
KRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRVRumgV8exd6iKiopg5Scq43sUs5hk9
yX16AQTzvSD+9iKwy7Gp8LuC+2FFSHPoWsndmR/w5WqL0YjdG/WmijU7f1+Ef2OB2Sz5fVZXG36M
/UOao9oFOIn6N5zNVaMQuzfmPaVrnv92P6cD82nGni/p6f47eEbNoWtNO199NRoZNk4xTSjZ9XH+
xgILacZtCB2EzomcQ9eqP19FOWkHTNflfgAXYlfG8grXuQg+9abC2Ph0cjUuL7Qi8gkzh16dzCgs
j/wGGCsj5UTg9g0/ezYodb5uRcT3hpityJMXs3XC+dILJZ0vVi2362aBxbhnC50vnBlxvlKhoSd5
vkx09VHS5yKfL7vrZonnS2TMr8zug1MSjMKeL5eLUCeYCBYhchK3O+V8sWq5E7GLOSfvUb7zdUvC
jxebDnLRpkJWRDy0FWp9PRvPN11J52sKaj1fpK2ZVHKdL3CBnyhiklP8JdAVlzhfOhcq4+jzdUsi
NpPEMp6x9XylzkLPN+67zC1Sh6ftu2jqUQhdAkkc3VNqLh0POV9sInO+9AnIG8M74U+lwGT99OHB
VxleDlOJWvTO+J8FDvyeotkNH7oF4qVhAYL1uGfKapmH5BwsNlk/fXh++f9TWwbZEYMwDOX+l24X
814Gg/UtQ7qoVxAj2bIyTEgPaTGDxxZPOQqSw7s0UrbVLuoNyNliQxJAgpHKFP4WgkiNF9yKkIEz
hfGhv19cnjHGUQ4EjkoGokemDTPEEIaGF3qcoFaEDBwqTOJzPU+XdP5GpRlREFtx1U6JFsa5ntex
Za+6Xe8wdrq4zfrkT0pdYvkTzkh1Svjr6oydpM8PMDbP7G/w2i94GujvWunK3x/0d9aeMb7gr/qp
MlOKab4nDX/xPjmJ1/wVydXfyl7T37Mh2F6dYArLgnwqeu0veRh2MG+7rQt/5/2xvySWnzUxejrR
1O+y0WQryEMsdOPvvNZfbD1/Da2mv/eY+nqeR1H660hTQd2XM23+/ab+bumcgkRf+Fv3fYK597fk
ccP0kL2QKrJa0t+4/2t/MwHVMxfz2u/3VX/Bw82L6+tZUQp/SfRYohIrFIm+TzC6pWjqtEoJ7+2l
T5otuaWYVNaaNxIk5pKwk4KGWNX3q5hnO+Kq0WQvkEynuLJIBp6NIZtEmlyRjXkUJ/XDHkZb9OxG
XDUKNgPJZIpLi+RMtJGm+3SXI62BFAe1gT2M7ujZjrhqFOwGcqnUP/V3PqxyL2BcfxOhCxy1fOJ3
AEh1Rs4KZW5kc3RyZWFtDWVuZG9iag0xIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA0
NjkgMCBSIA0vUmVzb3VyY2VzIDIgMCBSIA0vQ29udGVudHMgMyAwIFIgDS9NZWRpYUJveCBbIDAg
MCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5k
b2JqDTIgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvRjIgMzQ0
IDAgUiAvVFQyIDQ4NiAwIFIgL1RUOCAzNDUgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgNDk1
IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSA0ODcgMCBSID4+IA0+PiANZW5kb2JqDTMgMCBv
YmoNPDwgL0xlbmd0aCAxNjE0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJjFdZ
b+M2EEZf/Sv4SLaxIlL34zbJJtvuBdsoUCz6oEh0rK0tGZScwP++c1CynU2LIoBMDmeGc36c/Lqa
Xa9WudBitZ4VQZGKEP5oUYRBGIepSPM8CHOx2s2ub/pEVD2xhKKvZtf3Sy2e+tkcWEMNPNUMVzGs
Xmbf5M2Xr2qudVDIP9XcBIlcfFDzNNDy/mEFBxlQhKd8Zob3Xxaf4CQNIvlOFUAY+TzbF2b7rP5a
/Ta7fm/Y7lDMdWCSSKxuYY1G4P3yJ7X6fuZdGGRFYsBw5AIrE42sZLrRbLC4gUtj2e2PykSBka7B
a4182ihwQ8tBJUEuxYOKgeswUm2v8iCTYqky2YG9kVwrbYBxYOkXBQ7FslSk0orlkeVYjHVaNc8h
Tjs8yf3JlTLAJUwYhuSvNhR3+JlSk+ogMqHG5JAjYeJzUOAKXXq33QrXPFEwNwqYEjn0woHNmJkI
Lo7g655tHQgghfJzJ/alG0S3FsOm6UXdVYedbQexKykzmQTzURuzP+IXdqyHaVW3b2x9BRsTgsN7
19UHz1YxHZj6oXNqjrm1NVOaln/LFgXh4EhuU3Z1MqZtLDOT5IZddJAOjGASpHLgTcO755J+tkLh
haC8AJ2GIjwwxw5DEssr4uhYWAyO5VpFrLtm8Ny1ABvHM0iYGdWx4WsS70iKVXn1YtSM0ToXm3Rd
UHcUrNi7hDzZaMuVYGIzbKzXyYQt32Sr8zB0bVNNOiaeLYU3Hq+7OotyilHmSorGbsYVhnlnq02J
CqGoE1luQY02lCUoB6hWcFJ0w4Zs57pKpHtpeitewNruMIi9a4DnBSOnIUAGpDC0rdhbt2v6vuna
gDt7tTq1tgmik1loIZuFKyrwj2oeg3P+Ryw+3Cvsugc1j8C7FZOXap5gIhZ3F3u/W/zhF7d0/ds4
mOQ6yFJsNYKMZIqP77QHAARoK4QpsezWw4uPREktzweACBhyu0NIMFCSZwWepmOJR8WETGHBypeM
EhU0jdA5lquRX7cKbe4GEUF7F1IjOOqLfMbxpNRMgWONdwpRdktZAL0Oa0XcNMPxbZuS+ISWMWu4
R5TT8qAyRJCnsmtpNQeEMiECWSx1QtpWP7OOkwofstIdodtTML68gqcgp2bAbU3fhkq/DC6UZBPC
f5O/gOORLDRUYow3ZnIe+UWapn4xllQ+lVQUpFmcja6FhCjf6K2J4dYF3Krh/SHvblUI3zt8lSJQ
9m7x+/LHEsXOybNT70yxjswJhQcsMQRhNMqKRwAZeh7aWrQlIUCE+B8RmKIlUB/ixNPxatRiHbST
p9WHypN76DqEG6Y7LgjRW/fMlKayvaC+1a/var2Kxgu3ltDuwuqGHo3pmtqzVoDuxgBlpwzizGuV
oxfQCE1tp4sUYvz6fANXPh6Z91W43i5KcwKpjAMN0F1bsjJDaxBoSuf3f/eQ2ALBWPAKwgIBOcWD
2RE3MjkJKZpGep4/+FW0jaMXFHXsoXeaZyu6F//CtdbxSfBj3ZnA5IWZ2jw6q+TbD9jiRt6g27H8
COWHzf3h093izXrLw7N6i6d686252kCoW4otzSQ4fzjKSsx5j2TJ1IF5Gs/UTjnPKPSJz3lGOTdj
zmPIuddjvdrWS4lXAv349D9+ZwZbjZzDhX0CnhdvBF38xBuLRYyThcZJCrvQULVE8sJMr+RAm/GC
trt0ksQg4+M9teg3F4Lb+rWMeLSiGoPTe6Jjmw5Qr15V/zbonpDA+JkYdcFEC6MexQ8wbqCxyki/
x3jiez9QK/h5c54Q0GKZPjFxQxvo5mXHBH5wDD32ROBJk5Y47WDkcCAxqeyD/1LpOTF9ufy/6r3x
BFhE6gkTXjnVU3TJJ5pAcejZe0rbc+FoGCnRjmaLbxEzexb3LyigJxTwryXcivw0sHIHs1/4r0hP
bwoYIrhjM+74QjpXtkNj/fkaUAJLrmyPwjrXOU8fNiWMwspgCsujKPd7WzpqGhiWmQUnZhqx9GiI
hcJDOBQllFwNfhb0+CN3RUfb0hO9gNeElze7PQRKbpvRgfr8NZwGfhpI0HdOU8RpStArXkB/8oxJ
Ow4pwi8SzyAQwc46akWSUojrg989Tkk5aUBYwe5dN0Nr+x4C5+nCC8G/E54yNNVhW16K7Q9u7yV6
y5B5t5r9MwDBVGbLCmVuZHN0cmVhbQ1lbmRvYmoNNCAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9Q
YXJlbnQgNDY5IDAgUiANL1Jlc291cmNlcyAyOCAwIFIgDS9Db250ZW50cyAyOSAwIFIgDS9Bbm5v
dHMgWyA1IDAgUiA2IDAgUiA3IDAgUiA4IDAgUiA5IDAgUiAxMCAwIFIgMTEgMCBSIDEyIDAgUiAx
MyAwIFIgMTQgMCBSIA0xNSAwIFIgMTYgMCBSIDE3IDAgUiAxOCAwIFIgMTkgMCBSIDIwIDAgUiAy
MSAwIFIgMjIgMCBSIDIzIDAgUiAyNCAwIFIgDTI1IDAgUiAyNiAwIFIgMjcgMCBSIF0gDS9NZWRp
YUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAw
IA0+PiANZW5kb2JqDTUgMCBvYmoNPDwgDS9EZXN0IFsgMzggMCBSIC9GaXRCIF0gDS9UeXBlIC9B
bm5vdCANL1N1YnR5cGUgL0xpbmsgDS9SZWN0IFsgMjU2IDY3MiAzNTUgNjg2IF0gDS9DIFsgMCAw
IDAgXSANL0JvcmRlciBbIDAgMCAxIF0gDS9IIC9JIA0+PiANZW5kb2JqDTYgMCBvYmoNPDwgDS9E
ZXN0IFsgMzggMCBSIC9GaXRCIF0gDS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL0xpbmsgDS9SZWN0
IFsgMjEwIDY0NyA0MDMgNjYxIF0gDS9DIFsgMCAwIDAgXSANL0JvcmRlciBbIDAgMCAxIF0gDS9I
IC9JIA0+PiANZW5kb2JqDTcgMCBvYmoNPDwgDS9EZXN0IFsgMzggMCBSIC9GaXRCIF0gDS9UeXBl
IC9Bbm5vdCANL1N1YnR5cGUgL0xpbmsgDS9SZWN0IFsgMjE4IDYyMCAzOTcgNjMyIF0gDS9DIFsg
MCAwIDAgXSANL0JvcmRlciBbIDAgMCAxIF0gDS9IIC9JIA0+PiANZW5kb2JqDTggMCBvYmoNPDwg
DS9EZXN0IFsgMzggMCBSIC9GaXRCIF0gDS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL0xpbmsgDS9S
ZWN0IFsgMjI4IDU5NSAzODUgNjA3IF0gDS9DIFsgMCAwIDAgXSANL0JvcmRlciBbIDAgMCAxIF0g
DS9IIC9JIA0+PiANZW5kb2JqDTkgMCBvYmoNPDwgDS9EZXN0IFsgMzggMCBSIC9GaXRCIF0gDS9U
eXBlIC9Bbm5vdCANL1N1YnR5cGUgL0xpbmsgDS9SZWN0IFsgMjQ1IDU2NyAzNjkgNTgxIF0gDS9D
IFsgMCAwIDAgXSANL0JvcmRlciBbIDAgMCAxIF0gDS9IIC9JIA0+PiANZW5kb2JqDTEwIDAgb2Jq
DTw8IA0vRGVzdCBbIDQxIDAgUiAvRml0QiBdIA0vVHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9MaW5r
IA0vUmVjdCBbIDE5MiA1MzkgNDIyIDU1MyBdIA0vQyBbIDAgMCAwIF0gDS9Cb3JkZXIgWyAwIDAg
MSBdIA0vSCAvSSANPj4gDWVuZG9iag0xMSAwIG9iag08PCANL0Rlc3QgWyA0MSAwIFIgL0ZpdEIg
XSANL1R5cGUgL0Fubm90IA0vU3VidHlwZSAvTGluayANL1JlY3QgWyAyNDYgNTExIDM2NyA1MjUg
XSANL0MgWyAwIDAgMCBdIA0vQm9yZGVyIFsgMCAwIDEgXSANL0ggL0kgDT4+IA1lbmRvYmoNMTIg
MCBvYmoNPDwgDS9EZXN0IFsgNDEgMCBSIC9GaXRCIF0gDS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUg
L0xpbmsgDS9SZWN0IFsgMjkxIDQ4NSAzMjIgNDk3IF0gDS9DIFsgMCAwIDAgXSANL0JvcmRlciBb
IDAgMCAxIF0gDS9IIC9JIA0+PiANZW5kb2JqDTEzIDAgb2JqDTw8IA0vRGVzdCBbIDQxIDAgUiAv
Rml0QiBdIA0vVHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9MaW5rIA0vUmVjdCBbIDIzNCA0NTkgMzc5
IDQ3MSBdIA0vQyBbIDAgMCAwIF0gDS9Cb3JkZXIgWyAwIDAgMSBdIA0vSCAvSSANPj4gDWVuZG9i
ag0xNCAwIG9iag08PCANL0Rlc3QgWyA0MSAwIFIgL0ZpdEIgXSANL1R5cGUgL0Fubm90IA0vU3Vi
dHlwZSAvTGluayANL1JlY3QgWyAyNDUgNDMzIDM2OSA0NDUgXSANL0MgWyAwIDAgMCBdIA0vQm9y
ZGVyIFsgMCAwIDEgXSANL0ggL0kgDT4+IA1lbmRvYmoNMTUgMCBvYmoNPDwgDS9EZXN0IFsgNDQg
MCBSIC9GaXRCIF0gDS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL0xpbmsgDS9SZWN0IFsgMjU4IDQw
OCAzNTUgNDIwIF0gDS9DIFsgMCAwIDAgXSANL0JvcmRlciBbIDAgMCAxIF0gDS9IIC9JIA0+PiAN
ZW5kb2JqDTE2IDAgb2JqDTw8IA0vRGVzdCBbIDQ0IDAgUiAvRml0QiBdIA0vVHlwZSAvQW5ub3Qg
DS9TdWJ0eXBlIC9MaW5rIA0vUmVjdCBbIDI1MyAzODAgMzYxIDM5NCBdIA0vQyBbIDAgMCAwIF0g
DS9Cb3JkZXIgWyAwIDAgMSBdIA0vSCAvSSANPj4gDWVuZG9iag0xNyAwIG9iag08PCANL0Rlc3Qg
WyA0NCAwIFIgL0ZpdEIgXSANL1R5cGUgL0Fubm90IA0vU3VidHlwZSAvTGluayANL1JlY3QgWyAy
NzIgMzUyIDM0MiAzNjYgXSANL0MgWyAwIDAgMCBdIA0vQm9yZGVyIFsgMCAwIDEgXSANL0ggL0kg
DT4+IA1lbmRvYmoNMTggMCBvYmoNPDwgDS9EZXN0IFsgNTYgMCBSIC9GaXRCIF0gDS9UeXBlIC9B
bm5vdCANL1N1YnR5cGUgL0xpbmsgDS9SZWN0IFsgMjUxIDMyMyAzNjQgMzM3IF0gDS9DIFsgMCAw
IDAgXSANL0JvcmRlciBbIDAgMCAxIF0gDS9IIC9JIA0+PiANZW5kb2JqDTE5IDAgb2JqDTw8IA0v
RGVzdCBbIDI5NiAwIFIgL0ZpdEIgXSANL1R5cGUgL0Fubm90IA0vU3VidHlwZSAvTGluayANL1Jl
Y3QgWyAyNTEgMjk4IDM3MyAzMTAgXSANL0MgWyAwIDAgMCBdIA0vQm9yZGVyIFsgMCAwIDEgXSAN
L0ggL0kgDT4+IA1lbmRvYmoNMjAgMCBvYmoNPDwgDS9EZXN0IFsgMjk5IDAgUiAvRml0QiBdIA0v
VHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9MaW5rIA0vUmVjdCBbIDI1MSAyNzQgMzczIDI4NiBdIA0v
QyBbIDAgMCAwIF0gDS9Cb3JkZXIgWyAwIDAgMSBdIA0vSCAvSSANPj4gDWVuZG9iag0yMSAwIG9i
ag08PCANL0Rlc3QgWyAzMDIgMCBSIC9GaXRCIF0gDS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL0xp
bmsgDS9SZWN0IFsgMjMwIDI0OCAzOTMgMjYwIF0gDS9DIFsgMCAwIDAgXSANL0JvcmRlciBbIDAg
MCAxIF0gDS9IIC9JIA0+PiANZW5kb2JqDTIyIDAgb2JqDTw8IA0vRGVzdCBbIDMwNSAwIFIgL0Zp
dEIgXSANL1R5cGUgL0Fubm90IA0vU3VidHlwZSAvTGluayANL1JlY3QgWyAyNTQgMjIzIDM3MCAy
MzUgXSANL0MgWyAwIDAgMCBdIA0vQm9yZGVyIFsgMCAwIDEgXSANL0ggL0kgDT4+IA1lbmRvYmoN
MjMgMCBvYmoNPDwgDS9EZXN0IFsgMzA4IDAgUiAvRml0QiBdIA0vVHlwZSAvQW5ub3QgDS9TdWJ0
eXBlIC9MaW5rIA0vUmVjdCBbIDI1NyAxOTcgMzY3IDIwOSBdIA0vQyBbIDAgMCAwIF0gDS9Cb3Jk
ZXIgWyAwIDAgMSBdIA0vSCAvSSANPj4gDWVuZG9iag0yNCAwIG9iag08PCANL0Rlc3QgWyAzMTQg
MCBSIC9GaXRCIF0gDS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL0xpbmsgDS9SZWN0IFsgMjY5IDE3
MSAzNTUgMTgzIF0gDS9DIFsgMCAwIDAgXSANL0JvcmRlciBbIDAgMCAxIF0gDS9IIC9JIA0+PiAN
ZW5kb2JqDTI1IDAgb2JqDTw8IA0vRGVzdCBbIDMxNyAwIFIgL0ZpdEIgXSANL1R5cGUgL0Fubm90
IA0vU3VidHlwZSAvTGluayANL1JlY3QgWyAyNTIgMTQ1IDM3MSAxNTcgXSANL0MgWyAwIDAgMCBd
IA0vQm9yZGVyIFsgMCAwIDEgXSANL0ggL0kgDT4+IA1lbmRvYmoNMjYgMCBvYmoNPDwgDS9EZXN0
IFsgMzIwIDAgUiAvRml0QiBdIA0vVHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9MaW5rIA0vUmVjdCBb
IDI3MyAxMjAgMzUxIDEzMiBdIA0vQyBbIDAgMCAwIF0gDS9Cb3JkZXIgWyAwIDAgMSBdIA0vSCAv
SSANPj4gDWVuZG9iag0yNyAwIG9iag08PCANL0Rlc3QgWyAzMjMgMCBSIC9GaXRCIF0gDS9UeXBl
IC9Bbm5vdCANL1N1YnR5cGUgL0xpbmsgDS9SZWN0IFsgMjYyIDk0IDM2MiAxMDYgXSANL0MgWyAw
IDAgMCBdIA0vQm9yZGVyIFsgMCAwIDEgXSANL0ggL0kgDT4+IA1lbmRvYmoNMjggMCBvYmoNPDwg
DS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDQ4NiAwIFIgL1RUNiA0OTQg
MCBSIC9UVDggMzQ1IDAgUiAvVFQxMCAzNDYgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgNDk1
IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSA0ODcgMCBSID4+IA0+PiANZW5kb2JqDTI5IDAg
b2JqDTw8IC9MZW5ndGggMTU4NyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiZRX
XW/iOBR951f40XkgYzu2Y6+0DzOUVqymtIJUWmm1D4jSLrudUAGdmZ+/59pOQiGw3VYi/kicc+7H
uTdfqsGnqlJMsuppIHUuNBP4jyNly9woYZn1BgNWfRt8Gu0MW+7CTYLtloNPN3PJnneDociFkCWr
lgPBqh8DPrqbVuNpNc+qv+kVNr1CxfMVDscTjg4vTV5YOpyOUAUdMWyGPwZ/cJkNpQSUkk8ymRte
77ebx7dlZnPJ9+tNJlVe8JrJ7M/qt8FQ51KyIZY0q67CkaI7UqQjVTjS48ibTOHIVb3aLl7Y63Zd
L9evL6sd2zyx+ai6Z/vVbr9LZ4+rgWRrNnAut0Iya21umS507hzD8aVi29Xgqds2uezb/xJsLkW0
iM+9DTYJAyXBM5hcyQOrkPEbq6hEIYddVKnL3PF72MXybeYwXmUFzLE7GNf7zOSeL+JlHX43NRiG
EYvLh4/FFfa4itNl2Iqnx6df3x8Vb+uM1BigwFVfMFBR5qrfPkdGUXQQjGIoDulRmGXYuZZGRedZ
C7R5NiTQikxkaHRPC55vV7tVHW/ZZyLXfJEmiKMwSJssTZ/CTWz/V5yuQjywlzV+TugiDt0lulLm
fdsxHE7zQweuIE2hr9r8OI2EIuWH41UGiJmFG/EqvmfIEb5BgCtek7MVXz+/bRfgWp+gN66klD+L
3jjTG+xA32GWHu+inDYFcsu2bkJGJjfRiDBfZ5SoiKDgpmcmf2HVOK7N6eLBBY/CEaO4ejdNj0xu
HmZx9Dle0o2Tuym7S/ewdEZ6FmmsjukaD/W5QNeU/bH7jq/SFtvEF761rvGRMJ3gmMhXIyC99JCa
igJoXH9fbzc1JKzk38h9uK7q/SnMQl7AqHDe/xYYL6Oma3KoviAw1zG9n5k6hSVU7vtSt91H/PVZ
9zS1cYsWBMeEOeCQsTppm5N3HTwZbJeVcOc9+754ORCgx2NlO6do8Yb6+YSPLqFEF4Jfo0R9jA6S
tgjWxb2ylW8tW+s2CaAhffhD8eK4zEeAqcHPQqgEmLK3XUYVb7UNFxZn6wwIEDAF7n1D2IDNS1ha
xMk+TDZxkp484Wrgm0tcjfgQU+NSHAlHvk5Mi46paJkWB0wR/iHq9yDhiJcNvGjy7e1lsd9swwor
jmErQ4pyHrbCe85Uk155NSqmbuHEQR4cOKpBr2FOpT3/uq7/Ybebeg2MJ/AKH6xyFl7hyVz/qSel
iuFTAJ3peqIuNyMoExSf9F6FKo/oDJqveKpNJ/BKSe89D68U/UHxHp4RIEnwYOzO57LDJxNAGwGG
kqQIIOCJUJKuwmSJn+36NVSi8hirLnqTrd1W1Bidc7TrFT0A18HZQlCNbnTaNWWp0byH6RCJaPgc
tUhSBbm5RQ+bxlgjc1+xq8/Uc4bKEzbSlLlsSEU2EiJ7wBx4xHjR9qJtJZQ6vjGepdNZlqcpm4+7
V7erzXRCZVOhJrL4ZhfLnWssScFmJbRehZyAt6DWB6Zq90WIipP9HpkWsRlBIkApYwcWTGhbEyZC
HXC0v2SzIllMxqIeltOUzcZpYTRGgxYlPi5QOXeQAsv9MSu03eYSK/Td4mOs0Bk66iuVKrp0k7ps
4lnSBw2RGmUlMCvLp6NMUiQAvuRfMzwHv1cFgqbkw0yRk7aZDKGegYfmPzMlSM+qSVy+jZ8r6YQZ
ncZ8eFwc89QhVs/zRI/Vt91DE60rOU96VATbOU/5xnmN2pH1KcYLCjAJRsBMHxbD0E/+BE5PVG7H
MxQX6Pn4d7iNRpN4S1weU80GZy+PKcEk4hIlWVCT+QFK1sePRwnFFK5tNFUbjuROYvQFwKg9fIid
5vX1mDp5xWdsDuiK6uXnYH44Fr9pFy4ZQm54cURAOh/E5xwBiS7a98Vmj1OQuMEp6CHVpfr5MA/W
hiawK8oRikSogE7Oss2UTaaMPEU0f8SlGl2T5I+kW57/ijfrYz42BP55PhYoP8YHjnAkBxLx3lYu
Er4kD8kfo7vpzXgeszw27Z5U06KmHUHD12GvOLX7NpSsjwSLjD2mh7e7bxLVQNNJ/GfhA8QFu1oY
bJYVUaoELlOSXj6/nRBaFIh5GkQCFPX2mIBU/TrU7ofG43T/3wEAFxmxXAplbmRzdHJlYW0NZW5k
b2JqDTMwIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA0NjkgMCBSIA0vUmVzb3VyY2Vz
IDM2IDAgUiANL0NvbnRlbnRzIDM3IDAgUiANL0Fubm90cyBbIDMxIDAgUiAzMiAwIFIgMzMgMCBS
IDM0IDAgUiAzNSAwIFIgXSANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAw
IDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMzEgMCBvYmoNPDwgDS9EZXN0IFsg
MzI5IDAgUiAvRml0QiBdIA0vVHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9MaW5rIA0vUmVjdCBbIDI0
NiA3MDggMzc3IDcyMCBdIA0vQyBbIDAgMCAwIF0gDS9Cb3JkZXIgWyAwIDAgMSBdIA0vSCAvSSAN
Pj4gDWVuZG9iag0zMiAwIG9iag08PCANL0Rlc3QgWyAzMzIgMCBSIC9GaXRCIF0gDS9UeXBlIC9B
bm5vdCANL1N1YnR5cGUgL0xpbmsgDS9SZWN0IFsgMjQzIDY4NSAzODEgNjk3IF0gDS9DIFsgMCAw
IDAgXSANL0JvcmRlciBbIDAgMCAxIF0gDS9IIC9JIA0+PiANZW5kb2JqDTMzIDAgb2JqDTw8IA0v
RGVzdCBbIDMzNSAwIFIgL0ZpdEIgXSANL1R5cGUgL0Fubm90IA0vU3VidHlwZSAvTGluayANL1Jl
Y3QgWyAyMzkgNjU4IDM4NSA2NzAgXSANL0MgWyAwIDAgMCBdIA0vQm9yZGVyIFsgMCAwIDEgXSAN
L0ggL0kgDT4+IA1lbmRvYmoNMzQgMCBvYmoNPDwgDS9EZXN0IFsgMzM4IDAgUiAvRml0QiBdIA0v
VHlwZSAvQW5ub3QgDS9TdWJ0eXBlIC9MaW5rIA0vUmVjdCBbIDI0NyA2MzMgMzc3IDY0NSBdIA0v
QyBbIDAgMCAwIF0gDS9Cb3JkZXIgWyAwIDAgMSBdIA0vSCAvSSANPj4gDWVuZG9iag0zNSAwIG9i
ag08PCANL0Rlc3QgWyAzNDEgMCBSIC9GaXRCIF0gDS9UeXBlIC9Bbm5vdCANL1N1YnR5cGUgL0xp
bmsgDS9SZWN0IFsgMjQ0IDYwNyAzODAgNjE5IF0gDS9DIFsgMCAwIDAgXSANL0JvcmRlciBbIDAg
MCAxIF0gDS9IIC9JIA0+PiANZW5kb2JqDTM2IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1Rl
eHQgXSANL0ZvbnQgPDwgL1RUOCAzNDUgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgNDk1IDAg
UiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSA0ODcgMCBSID4+IA0+PiANZW5kb2JqDTM3IDAgb2Jq
DTw8IC9MZW5ndGggNDU0IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJjJNNb9sw
DIbv+hU8Sgczor59TG2j29I6haNkCIadgnXYYZflsL8/SrZXLOiKwoAtiZLI5+Xruyw2OScgyM+i
xTaA5qcOjAuonQ4QiaM/xaa7erhc6wYN14vY3B8Ivl+FRq15W77UkXGQf4sv8jg2KqGVe9WQQSMn
5bCV/cBTjySnoYe/kwfVyo+qsRjlaZjO0KrGo5NJfc2fRKPRkrXQGPQxWcj9nNEuGcmlOeO4nx75
QsfJtopPOb438ZWw7Xbj/jOHWp7Na0PJZmV/P4Di8kjWlJE/JeWQBcEPEG1CHwiiNhjAGQYwwBdH
A7++ieeXMCG9Fr/Lt5LahC6xVsG36E1RtaCQW1FsnFH64WFb6oryzDqV+rl6YqKCETAUxTAViiLt
CwWpxnFUr58FZik0xIDp/xwherTv42BrhGKNYG3ZtXKEufru+Hhc6l0xcm2MLV02bIPTAOvKQZVG
jLBs7FRpww7+JaFbEk9vcDgW950clttQOHRirxeOZvXw7Ga/uHliqYM81PfElWsW+1Q8RLKu9fMY
ug/H6mkjx11FTLx6noNP9U/w8wEgRmM3SHOLZrgL5g06YzG91sU/AgwAQmDGawplbmRzdHJlYW0N
ZW5kb2JqDTM4IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA0NjkgMCBSIA0vUmVzb3Vy
Y2VzIDM5IDAgUiANL0NvbnRlbnRzIDQwIDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSAN
L0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMzkgMCBvYmoN
PDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDQ4NiAwIFIgL1RUOCAz
NDUgMCBSIC9UVDEwIDM0NiAwIFIgL1RUMTIgMzQ3IDAgUiAvVFQxNCAzNDggMCBSID4+IA0vRXh0
R1N0YXRlIDw8IC9HUzEgNDk1IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSA0ODcgMCBSID4+
IA0+PiANZW5kb2JqDTQwIDAgb2JqDTw8IC9MZW5ndGggMzc5NSAvRmlsdGVyIC9GbGF0ZURlY29k
ZSA+PiANc3RyZWFtDQpIibxX227jyBF991c08kQGFof3y+PGa8wmQAJnrQQBZvNAUy2ZCSVqScoT
54/yl6mqU02Jsicz85IZwGLf6t6nTv9uffNhvY5iE5n19iaKgjA1If3HVxXS3zA3RZoFpVnvbz7c
jZlpRtkSmrG5+fDxMTK78WZFO8MkM+vmhr/KxKw/33zy7vrD1l+VQeL1g78qgtTb46f2qyD2Do01
azv6PDNhn3k8Wllr/FUSZF6r59um1h1tfzB+FAaV50T7qygovMFPSIx5vFs/hIXRLW9+3fB6/J2/
37n9r1bdN5E4F8DyUAa/eLyWeT8c1YU4u9VgxNgRhr/4/t/Xf5BchchVFVS5ZEE+XKaSMsjiMOJc
cR7SgjMiyYkKTYlfef3xdfAlln5GCnfPk/waCmQcRN5//Lgie8xPfuqdds+UIGSm38o2bP5McmpI
sebxFXuwZPd0EBO3PqeG/AhD50CptVYGUV4W5MD6R7E1keKBkQb//Cj2rr/enfx/fkXOEXdpYtyY
eE5CXlAaU5eDWHLwyYv8VVyGBQXl9xSUyjtwsLhsc4p178f0vTk1MsJK64e8crgK3PuJz/MoyMtz
5pNyznxYIqhrSi8rfqaaKkl6StJx98ymb057P46D3LNkF6+YhjTzRgzrFkWKOT1WG3xYcUjP8XVM
ycutT9povLEqQTZBbSd/cWxjpouRA4ML464FPkp07qi+otmnB3+Vc40eh37yo5z86JseWgLJ3NJ5
xRz7NdWw9kCZo1t4uRdh2GBBpfQ6epE1uAsTIEZ31yqHTklE1SKYLnLYcs55aAjYojTN3RUJZ4CN
M+SUskIIUxKsRhX5f/RXmYQ3IkWW1hhC9+QLjQ4orVpnp7bHZsybJ4x4mTwf7QZjs9z16K8qCu4d
GVpKTDMS/YBJs5E9AwM3+b+lBFHQVvLTUhHA0i2WMT2SnGh2YgcLh/oAnW4Phanymul4ORtiUOAn
4NDS0X9BQmA+Oudht4VXQ90ZlaJWtlhv2mXkRgeFcEJjMHBzufJ5suM0mnqwFxnL8jlj71zD4+Cq
7/J+ubvwZDtXTFL0n/24kIbxVdAJyXK5/TOOerG//of0jBSnCE+AtwT1WFFxcVBGZySOz10j1q7x
kRsZW8nROliAVi2gRSHFsD0AvYBbxw6bR3HM9FsKHnlWeesHXzJjgHK6C4Pxm7AuK6gg4hlfc3cp
iLHMQJdQ8p4peTnf9ZxzyqmSr4m6bOLh2zCulaR57/P9MVNP11dOkRMEzrq6ffVjHhPiaWHsZFcr
otwJRpiUKo5HZiGXg4FVjC02yWXkWbqMeox6LEU6YU0MCIwFptW1umn6YVNjRNRJTaEScZZMUArH
zWJkzWA7C1NrcY6A/k3NStKzcuZxWrM/W76EBZMy/mGkSyiV+z27xUV82IgnDHuyY+IbIzebf3pd
PAjvKT1DGYojwb4QQMVnzHjUfUttKmSrvzr7JUVi2MHoxKiYzBBT0PggCjdLPVdqD1fLOKOKjFOx
RV2rGWbnNLy4U7POvc8c0CnpIMcFjoD7rAc7VNP/jiQrRuQXHhn30S99GM2hX4o3O6dWfwdB4Vlv
p9a731fqolyXX/RKd3FJrX87N6lmblxcR/VBLlI+U8298Nt+00rZx1LGxP1xLzJ3LzJ3L2It6lKK
mpuoxfrm2Lf4mkSCk3/SZTvo9Y90Q2B+6gXKc74/GbliVecLJPts5nBr2sm0OEgXqOl3ENj+2xJv
gRH1ZBo7TECS0lODz+pkdhbx6wkCBmua+lg/tV07tXb81oavrQh9iS2Q9ma0Sb4q5MpgumIBERBO
my1Oku3Uu8xBSajInow7g3bqWmPbtFOnp6HIKEnQ9gqjXDdfdF7HJrTfXllhzc8UWimhXOmKkhac
Vj6wWVCUKwJzCwpgHL/BrNPrAqWL4B2SAZWp9EezYaDeyVJvtaaugvXkYvAuAeCe1Mx9Svo/789B
QKjqRiFm5A5iw6y66wyCWEkYIneEyUmkPuS65EYqpNao5IhZzp4yA4blPzCDLmSO+kvzdqf9Fd8n
kSbRz1R0Y2/nMhfT1FomQDoznm91VM3hyyV86SJ8qae6NXy502XUVV0ex/Zp4fv3B0kseTdKEUCX
ZyRKl9AVzi0wjs+kIpUHRM6wOtit3GMxNEY2qQhuzXJawiM2g96WnlqNsJYoUHdpGHxyeZtFrnZj
yQX11e4iifyzEQcScT7zlkJxfiQm7RxNdIULP71A30LvE0MiIXzJLc1BJ9SrxK6eLNHnTvW8wpcG
0VBv9Qc6rN7xzEXsXClkGhEtbEb+9aZHmv95OLwXZMlp7rZsvsqMU/ool8z4k0ceEmCEeUhMXpBo
4BdkLPdR6uPALWdVoMDpETs22DC0R179NqaaFlUQ5TNTdTUVXfJUIWgUHqLH/IR1kw8+w4O0Ebko
wrXxLaS1ktzHbLohFJ84HLF3uVk3UT9itiqYy2PVxm0p8q51yiQlQeLB/V4paIOio0QIwSWor5gH
DnIpUmdILTbweiM3lU0jZvTiCw/RJbM0nhlELjwjltcAb9Ol8xnKCA61sotJwfK+JheppQvCL6fO
T0CfSnG68tDvubArb8cTZlNP9Y4+2A3aJKxDKAn6NUeamiM/SDHci9ctRE4TUQAi4/xqI2Zgyc1K
nnFUk4StvDCJCbqfYDYR3b37gNAOy680cWvk2MWMubDffsneWJgf5SuV14B4zwfaRjaIq019gjpY
qIZ/oAxeRvHta7WV1yheqhsMmlqfrAa/z7JIzVQud6zjWkc4usMenRsJd1JwOgF9q/KJxF2og3QH
RziDOa4GRq6TpkqkcapG6O6lLBOORSYdp1LgLWbhV7bf/83nF+PD/Z3PN2AtXLDy7n+UafPH+0d5
nz4yBiRcYSz3oyzeG6zdCxH/s8z9BSsq5U8yguR7Ko1OVJ/wNNkz/EgTlocKxeSSQSczgy6QD1s3
zDoThwxSZB7jkwwaMiJ1GCX7gq/jI/c1AanVknM61k6GASvJ6gc8TwUtizdoCaoFqDddO07fhpIh
vV3jGSWjWX91iZO5cH5q7aOE22oACkG70sO3qd2vqxuqgYRCgrNcGLlATcm9GjiqeFMJjoIWRbmb
O4KmdXayTuKLiKol3V27qTXUeBvSya0WmJrrjgm+p7MzjLWEtAMKFigrL5FMQE7eaZXcJjH8JD8T
Ic3mBG2bGr+NGNJaLTb4H/gr8ege5RJ5aBDnDdOizGaSGipJ5ScPqioXBRnV1BPjnczzH0G1CugT
I0yKZfwMKeVGyuZjzz84wvfgqaPU9UbsIpogGEVH/4kzR4JSUW5F6ywwDgUoarcdp43tLINypK83
uUdsyFRLa5oPag7kESnUBmyQZcA9EKVMGGHpwCmUwKmhZBrSdLsorUJNadUho4H50ouumomlsgAw
SfAZb6D8MtmJ9KlU6dOF0R98nTrlCb/M3pS9Ezya34hV+rAge1XqYCGnsW7D7bx1ogcd9YPIcxPc
Fnizs4G6/rw2Kmrx+hPWV6JCpMwS1EhoNwJXcAMcnCydjIoXj8eG0ApjfbvgiVApcr15UcUzjXI9
aq3PtGe8P7nA6Wp1+kEPK52h2sIXiqWUVMce9/EWn+BIkUqyhq8yGjYzxL0v/BiFUnlYJMQYwQxP
cqhpVInO8mWuhLEovFdzNCKFrVIgrNJvubpk7dIre2G9ml27mq08J33Y2GF2d7YDLofggnyyrTv4
2YneV5x2dwR+YGsjxzQq/2W8XJbbBIIous9XsJSqLJd5SSI7y5VUdlEl+gGMCCZRCRVGruTv031v
zwASfmxsMTMM03f6cXpkSn64fQcdviHc+1ocrQzsNV+9GBBoRmpvLqpxc5Jeg0MN62IbyJDhQiMX
EamvGSxUrqCj/tgehAKHKGPw4JhhQ9+y3lkvdIdeKNKTfYhpsHD09Xr4AVyKszDH6j+2asAj1QSj
jBQI8qJoziMy4geaAUek7jjNWA3K/DZZnNq86OpCGk2JSGn2anVsda4zOMJhRw6/DmefgzOn4ZkL
+fpMCzLmgCSFAcheo0comF1TCrEac9WOm5YWrAIzN/1Yae8zFQ9KeoVxqSYoxbGFMzO3gVF/DH+/
UYiqzaX/uPSx7D83YcVAL1Wp8MqpXkzHMZLVihkzhpXD4cCefllFREy7SZvr5HYUUJbW/8DdlaAu
0U1SobRkURq7VJikvu0RSIvnu9+6OkyM9G6jZRoKbOlqXShicIXtJ61UFGW2YNIntqLJztoGBUtH
nAvxx4fmuMelXjCe8tJ6jawtZ/V170q/jXios5fymB7K8VK/u/rI54pKdqaQqySxVpK+Ekdur4Di
lqVdiXib/aiGEncaskBvt+9z6UbOGDnZazU39NvkwRtXH2pI2t3Tqpaw4eYkTrMBkeDkT9yhbI2c
i7GfBI82bwZCHWferYZ/zHKROluey+va+UGP1TIfWzdlCgiRmTC0qIbDen1Nn2CrVcLbWy6wlsey
k6tpHznDhOML0mSJ9/u+2IRr16MkgTYpmTL2VpBzjUQP+NsZIbLGDiYexFZWKCR1nkj/1vMUTIh/
Vx5OWaM779zX/Hxv9Ch5NCj/jkn3bEeIUVIBi0atlUFt7liyc1irRMw3eh5FJsZMw9eL2vUifV3T
6ScXXeBbfv6w1+RXHADnAkCPjpTJ3g6mdemeu9fHarTzPel3w4v7/gPC7cxxA7NfKVyZwdoE925Z
dzTcbGmZ7OVb77er4Vq4yXerHgYjCh+LE6wlpOQg4nZwOKSRtfjuIlO9EzlHpRnszPF2rhwmynFK
y+ns8san+9ZwhR+h71yX3g0Snib4WldnkLCEU6jaWke3tOtI2USoXy7Bn5Q+sWe9cpZS6CmR4rZT
XVczj4Ap7mqpwfjittcu4PDCa1MU54r9qan5yzYfXmfGEhUih2H1q69tiOqg1cTRaog6sRqfng8n
a0uK2pmC2SInF8B6TTo+L0beyrrzspiVkosne4OJxNAhhsfBryMB/z3pYZQ57bs/4cYPyBg7ZL1s
trVEdxJXiTQh8FXtBbmV5nCFlAg96pFbqmJz3gye7bMbeviX3af/AgwAyFJzEAplbmRzdHJlYW0N
ZW5kb2JqDTQxIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA0NjkgMCBSIA0vUmVzb3Vy
Y2VzIDQyIDAgUiANL0NvbnRlbnRzIDQzIDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSAN
L0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNNDIgMCBvYmoN
PDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDQ4NiAwIFIgL1RUOCAz
NDUgMCBSIC9UVDEwIDM0NiAwIFIgL1RUMTIgMzQ3IDAgUiAvVFQxNCAzNDggMCBSID4+IA0vRXh0
R1N0YXRlIDw8IC9HUzEgNDk1IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSA0ODcgMCBSID4+
IA0+PiANZW5kb2JqDTQzIDAgb2JqDTw8IC9MZW5ndGggMTk2MCAvRmlsdGVyIC9GbGF0ZURlY29k
ZSA+PiANc3RyZWFtDQpIibxX23LbNhB911fsI5CpGAIkSDB5Spy0TadNPBXTlyQPqkTbTHTxkFQ8
+ZH+Q/+yewEoWnbTuNOpNCMSwALYs2dvel7PHte1sWCgvpgZk6Q5pPiVtyrF37SAMneJh3o7e3zW
O1j1LJJCv5o9/mFh4LKfzVEyzRzUqxm9+Qzqm9k7dbbfXei5TzK17/S8THK1lcdSV4lVu1UDddNr
mhlEDhbXDa+t9DxLnGrD/na1DBLtfgfapEml4tF6bpJSdTrDY2BxVp+nJQSRO884PB0/8PlA8d+a
AB8Mg0tE85QH7xWtOfXsOkCw7rtgDCsSafpe6w/1T8xVKlxVSVUwC/wSmcp84mxqiCviIS+JESbH
lIESXan99ZdOsy21wwsvrwZ+AhrSJkb9qW2F+sCPOleHyyskSJjZX7CYCN/gOUs5pYHFF5GRpWaL
G2XiO03UII40jQB88DWfmMKXCKB+wbpm7DyiJMhHG6tO3+6d/D/fLAPBkOE4sZClldi+KBA8W56Q
RHXv++j6I1kiRN0cTWEdzIvE22iM1I7E0evEJvd+vtfGIJlzqy7BPIH65aKGszevefoVspomhfpB
e/X2V3K1Qj2rX715DW94nSKGiffqnKGlgJFnHKsycqLyJGhtclE7TUon7KkTQMcV0t8eodgApW50
oXpyFjTpy93ntsPxXltKCVttaJokdhTYBToVGxyNmwHZqihvq/ZOfU9h5tkACZlAKJqbIqlwS04B
Eu3qj3b1sjlPDO5LHQUaJQ+0CV4Kn5ebdr0cKNsMTT+0u8sTB74/AK1LE1ccI3CEjFhQEXWlkWaK
mLM4c464MUToEmh2vPyZf1uMHac6Sm8lhhJagwyD9qlQvwZnM7IXiw6w2stykOp1joHY9kL30ENY
vsCoxMge2CfcqI1MB5nNJl55ozkftEE6nH3Jm6Adog5bTelLroT3qm8adMh5xfmFIFzKvgPv6xqk
h8eY0zjFPzkJqNGUGbphMQaUuOEf5Gq3TW8wW5XF7Q1JatyY+4wNua++0pbyUaNRb4Sw0IbMc6Zt
qoh4GsBBZHqycxZFO/IKRBdmW8a61dbiI2zYaPQ3qmy8YZDRHvN3GXc/FbfMksp7INc2uRsdM4u1
Myr7B1on9yVuJ0+hvEpsZcw86ckO0xM3hhhg82ZqsxyYRrz0aYxm5MDlnFrY8Yt4UzW5qMrpGgZy
1ZDXYNXa0EEElh+7T7E+bDVnC7zHYvCoXRAY5EHOYxEy+UymJkqUeMsItxrhmttwTQgVz3Arhqvg
1Tls2h1PfDpxF1PmSUH+YnyeZLH4HT0mOcm2ZZJisrXJ0fTmmBNMzAk2ZFbJCFzED33TicGDEdDb
0OrIZ8lm774pQZjcJoWfJIg8WoKIoctfHDAac9VRyqEX4MaHUgeNMHUQPSV6bRF8I0M7n8skeYWm
lEm60Rt2EpT8MVqhpTHs5JRV09NwqSmwiaxcfcEw4OSwh1akPsrFzWo4Uo8uYpkUckI6Qo6RsSjc
8KF8W1yQ89bx4DW1c5haWQbvW8b1C7K1YYXw4j07fhlvfZAhmnDk9T7cORw90bhirAhm9EQTyD9o
8v4d/671nFwciSfDOoQ1YLouVAKv2KA0A+uw1PJSt/x905CqFYcsnbIcYJC3JhpyQVrboDVVXkRm
KfmQlByHl15oyvUHUUI0WulUoek0VTcb5tA1Zcd61Gm8b7kKqsjRSLjakOXoum/SYS9KHE/86uYb
bSVnWK7cEyOAnBg13yIpVMaIlPrRpDhPq+ZyLaUiPFoG7sayR96FhtnAhdQWmV3JbKxxUoNu7esj
C7fqXicp9fpWtQqj/bSsNmM57aSCwXKSGslYcbmZ1OVCqkIo6VJomwAM5LZwfHcXD5XZE/CJdDtw
2lksg8rhsZFQm+6EXmRjmZfLNlGX5abfT2mRBm7aMl13+8+a6G7XDVBwcshnIQ14jnbLHuQ5vFdX
PNGswvonHkqMGBUWMTcMTUfOhl6KfwxbWZWzcAUdGTOG7AzWvqEcTAyz5HB177ELqWbkri64q5Ms
gT7ZsvbXmyZoFsBMYQxiPkxEVZiBgzzXY1rwnBYq5ITs9rKeGaBvv5o9PusdnC24DqRYTXDlJ3z5
CNgkW7gB/Dv3C7z7kMIaV1qYUTNT5AYKhxU/B5TJkXvomtnzR7Pn9Wnrk5WJpcJRlNhVWKl89O2F
MDdSV4Vi/3JHvYjlvKgFEo8HHsCzOwAybx6gUOarqFA+Nm8ThfLq+Id0ohHV16AR1QoeDzyA55O0
7dNyLNpuzBVOznm7Y4bZi510SXmI6SOojzDDDkEAldgJ5LA9IpSJzWxxRE9MzQz9I0GBPKVOA0qE
+HVWsC30ZIQ8wz7G/1esYDhKk1JO/vosuB9Bv6Uy4cYGsOCu8w6XSEr+ACCZt9KX/A2Qf8tmzPff
yqE0wDZOTAk9RVZ4gZUV/wwKW7K7mNKRHBuy3Vvq+9jOhjM8NaEHLn6x2fZTW5PDVEEb7I9dQS5W
HidycrEcjRL13R5HOdZEf48HWu/RNQ1krmLivobPVmhpwkdA8bIpQOn/xzJbBYQ/EzhPyfYT/ELZ
04bmvuLmvpBqSg9u7u/gzVA0vYU3TGSoS1kwoL8GAJnEbf0KZW5kc3RyZWFtDWVuZG9iag00NCAw
IG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgNDY5IDAgUiANL1Jlc291cmNlcyA0NSAwIFIg
DS9Db250ZW50cyA0NiAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsg
MCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTQ1IDAgb2JqDTw8IA0vUHJvY1Nl
dCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiA0ODYgMCBSIC9UVDQgNDkxIDAgUiAvVFQ4
IDM0NSAwIFIgL1RUMTAgMzQ2IDAgUiAvVFQxMiAzNDcgMCBSIA0vVFQxNCAzNDggMCBSID4+IA0v
RXh0R1N0YXRlIDw8IC9HUzEgNDk1IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSA0ODcgMCBS
ID4+IA0+PiANZW5kb2JqDTQ2IDAgb2JqDTw8IC9MZW5ndGggMzI4MCAvRmlsdGVyIC9GbGF0ZURl
Y29kZSA+PiANc3RyZWFtDQpIibxXWXfbuBV+96/AI9ETMQQIcHl0PV3cTOKckTov8TzQFG1zIosq
RduT/qP+y94NFCU7il2f08wZiwAuLu7y3e3Pi5P3i4WxyqjF9YkxceJUAv/xV5nA3yRTufNxoRZ3
J+/Ptl7VWyJJ1LY+ef+3uVE325MZUCapV4v6BL+KVC0eT75EZ936Ws+KOI26Xs/y2EV3/FPpMrbR
um7Uotlq3BmYTs03DZ3VepbGPmrlfltXQtF2a6VNEpdRYK1nJs6jXqfARs3PFp+TXAnJk9+wPFy/
8veV5L82or4ypFzMkie0uIzwzEenG1HB+ndiDMsUSXKp9W+Lf5CvEvZVGZcZeYE+gqfSIvY2Megr
9IPL0SPkHJOLS3QZdZtvvSZbag8P3twO9KvAkDY20X+0LUEe9XftovubW3AQe6a7JjImfgQ+FXNp
1Pwb0/BRcwcXeeOdRteAHkkSFCgEa0VssiIHBRY/kawpgYeFVPxPGxsdfj27+f/8SoMiIWgsR4zd
hUtSxIUjH6BOXyIXpyI8oH1Q2/ZOmzS6R4QX0aoaIDj2jfO8c7Myj21wrclCsBnHRvvpHgIpi/p2
fUMfao4o8uBxDxhcgHMdOPczb6oB3OoBW0O7Jmq50w6q1bMSnMbHik+bGshnGYjL25UGUKUQc8i0
iL5pg1cCgIZOCdffmVdTg9Z0EYM1g/fvtE0QKsxHVVdMD8cOtgNfoapW6o6RRg8guPZloU3WQNRS
l1ElXyLUIzgQ7CAvrlaqGplNFP2OAEK60halFY47HSZ8npWJ3+QjCOWZRWMNHXk9UZC+jM+yEAiJ
DZ61BXv2GriUiBePeFkBb7iBRqe4HFAARBJAa5CzW53BUw1mQ9jxYPDP6AlIRfd0sqa/S+bY9IiG
4Z0awrUpy20rPO/gcCcFoJa/erXla+halhNXK2Gu+LAShg/8AqdsfJCI2m2w6Z6qLGXNxEMbHuDt
GM0I/M95qSp5UH5aot9xeSfko44v0AtDxUajdrg7KrdznXM715Wj6wy77paYo/akOuHPROQnxA4f
N6quNsjfRNUV/7arNtBgcBFa6ED1EIvtlBeb1pCeJasPu7WwruX0Ky130KWAbeRwuw1MbnaMJz4p
MK9gunLiZRs4PNGEEYexQ4izjLhyXzpBXKwCbbg9eX69++wrcSbusnqyZNFU3fRD1Yok65eGFds6
ACS4nRIU64eJZ9v8a+r5EBgCzWarAioZuVMDj8Rg3hsJNcbyaNrjoVOttiKVutq7r6qAmGLUAhET
UoLcEpEOk8Krojv+YbnLrJeyNFZwqHhOL36nfsXJvdh6LvZgIz4SjnbSA9ixX8FPdNLP7fqr+qhz
sFGKiQvCgi2GqxfWTVDWuVA47dilJn4snFgSqXBSbZxjQ5ZB4cQisyBjWYQzVUgsnBkWOShxSC13
uHAWVJXwWPEpF04swLxd6YRjCXiWENoWl5O6uSsthltbbIKZVQt9ghr4jVtmrh7oV5i23b28vc+l
IRd7kSDIwXssfUMM5PJVI4rs6ReY/EHL+lYe5s01yzlltgQ+IuyjtmiAphmpuQPZV2Wf+Du10aaj
86SfnaOXMvGSYy9BvDRrahiWm65dS2vKBbjEwpFgDP2MzXkeYbsTMc1XbnRH65XsgFyOyQHUehiS
GvxzTz+rZbjD2+gPFz1Iy4LfqF0ppy2LMWZX5sFP1ERNxC0I3PFurM65fwosOirqmJPkecgUms1G
8qogBxo8/64kVHeqK641gkak6A60lNfINZh8Vki9wlLKfNFViz9xBGdjBEPkkYc2VV8BEi21SlTJ
taNrPLWhFTBosKgoGDGMoaaGaG5h/IH2aZJUE8FzQg1XTg1XLv1FQg0X3SDeP05d3tvQqcuIdDAt
eegaigS1RIDR254iCcc6lBHMsWq3w9E8ZGCcyjN8zpk4KQ5SpQmJUgY7F3vvJjnR73KilZx4isNV
EfHfDuFcRHVLAKgG+uFFt1ZzXtOkVkS8uN/8+0BeHAkccAcVfV6kYzp2+DT0QEUhJVNBOKKlU+T2
SWMf2/Xk3OCCDJpkRzmosHkOH6faOBon+P8O+7AMxUUqEHeWk7y4kjMu4CASmAwlKhMXJHJ+YrjY
iul2JSbzRiyHdGOlCTNnnOSQQYJpjR8dbqw4fNFqKP8OoJY6ymVUKHtEJUTGwmhsembaYq455901
ZlnMI3SRoQDBU0CGOi59bPblt3Fi3XH5idsIDWwy67HxJPEpDWYAqhnWlxmIW4CcM0s9f4GNJQwJ
LXdmNL+UlBeglKprIu74Zq/OP50vSBdYZwZEPwDHoTL2jcpgYEh/ZnfKOJDFYAG1oAwWivNQEjNq
8kkZgJ3nhjTjDsmQOkje8d1enV1gEokuPpz/hbXCjJJaf9xH6dsQRlWqHisXKvWx+gNEz3l8SSOa
XgA8Q0zKuuiXZugr6nKhXqm64697/mHioelfDLL07SALGshE89eqXUHdifoGC4VMIwWhCKKeUIMY
zAl8OYY/CI5FOo0+vBxP6ZvxZEbTm3QqeY5VZyp7zoMQBkEoNCBudIFQmZ3ip8iNvVpaPMlJydhQ
WmkogU1hCwwxgq5nZ/vIIVQdJosz7TjWfMCopwkNurxGrelDdgf1C4hJJoXDBzpqls9nyC8H73le
KfinAfvqFBMWjiPCu24rHt8gkmSL34Y35UUMOp56qOBSsh7ApVbmDh9B+bvlrzuqxOEmcxrUJQ99
IPz19ZRZf0BITFW7FuIgGAsgT94Q6aUm9SF80jw9DiP/avhDm1JOUTT6VmYF1gIQ00OLCbEoI2yO
5Q+z6Q1sQls+rlekB0ZwzqYBK7pJz/8InqFOJxwjV9XKLVy0A7ip5RHRyPFWkS8cGQbe6gfBxAyq
linM8aTgXx1ch1YZ2/DQKJFdSrEKtttiF8d2yNAu2Nc90I/skW3QMtLUWeoT3KQ5JutkaJ0JCb/A
NpLFzkYZDS5MIFaCwUpbsdGMWrYr/v2GJQPKesdLgtzuLZqplOgj1oV+Li2LQ8zZcqzDkiRV+Edx
p6BtwtAro2yypy42IDJWZejPtIGGWjplQwnJTPK8K0x53KXZm/O8yUafOlbiYoN2AYy1HX+gKTJ2
Xori8q6s+4rc47itcGzBFJXAoMaLz7cUR1R6awmwY2ZOfFBJTO5pSMvE6DKYku1TGWBFcBpVx6oG
Xcgpt4Rn1IB8CLCAGfVJKrJjBUrS52ABfqZUsoeU+dA3DAJ4d5QtjWQLZStItt2UCsaGYZHzMw5o
vFUNtVy9FRRBl3vc4vn/AKKiNNnE4m5UWaa/jy3OkiQTtvs1zoyOghdxv+bVwCs+a8amglCEvd1S
XcwVWyKTO0vFY2mOOSKlrECsPp7PA8RKbPB/oPDrIXag8JgJk3yqMHsmKMzZitWl4XbGyqZTZRl4
qBnooCqmDWoWrGYWWFxI1yvK5s/WwjQdR8eAQJBf5rcy+qfmaavE6IXdqKm7G16CDhmOBssAwYRw
ZRFxkJowKTQ905ArhcsuwpOp4Wf7bVIqwWjQTtSsYBtQUnOE+f0c80oRfZZ5UlVLjS3Bksl7Pm22
22aLAUodzhgMkDSgoFBfQnCBWGk3fHHVqIpan0xaH6oXxThwopRp9qR0+nSKGJMcTgR5bo4BJuHU
MAImLXc+kaHtk8bE0mHPZhAc2B70mD0hiNGuJQR2DjJvup4PwSLLvuFN/ttAgdtODD9tiIp9+Z/G
uE+TH8w0hZto4EYF/lt8+ewmDMNg/L6n4AgHkPKHpj1PO3OZ9gKQSVwKAg48/vx9TtqMllWgTbu1
adr659ifbdPb72i/Wh/UegfrpaCeKf7J+FAYX6VHEkGeCSybJYL4tYlCccs0SONHmQoo31MFUEFz
hGuNqZJDDrEot7Vi4VHGqrksSGs2a9yoUGHOIgJFXi4YrlJKIGCvXRUZi7+pKoLugmVkpU6XaPyI
LVd2yCycTK1nQpIzR7GjPorb/afaqBVkO4tX7r7EZKp+SV/aqxb5tPhjeaKkV9JiWawcoyLKy9aE
gU7ZPifsHcaHr9ByWYxg3QX9gqlsdzjRDTXcYCEmyQ0N3dCoG7DzElvdiK4BC70e1tRDNqXfmA2Y
4ZJjhDzxpXFZvCPRv4XuMrqb24TuOvRG0UNCNwLuM7bL2E3CdvPRMqC3GVyxfYfturYJTeES/5B4
h3yleJfOytthR3KrLpLfVvoah39uqA0Uijg7FD2QxSlSgU7xKQ0SAZUPTetRYXQZwKY/xTsTwBNX
hj3TipojnKoZZrZpuU4HMO0arR0N2NXflWa71fphmL6B+CimWCF+lTKb48bKpms9PlMcn7gk/Sjv
k0R2abuGBQZfWjUM87/zhf0XXywXTHgGs5dgLjvxetRD2TXqKK3Tb+8vX5TTo1IKZW5kc3RyZWFt
DWVuZG9iag00NyAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgNDY5IDAgUiANL1Jlc291
cmNlcyA0OCAwIFIgDS9Db250ZW50cyA0OSAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0g
DS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTQ4IDAgb2Jq
DTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiA0ODYgMCBSIC9UVDQg
NDkxIDAgUiAvVFQ4IDM0NSAwIFIgL1RUMTAgMzQ2IDAgUiAvVFQxMiAzNDcgMCBSID4+IA0vRXh0
R1N0YXRlIDw8IC9HUzEgNDk1IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSA0ODcgMCBSID4+
IA0+PiANZW5kb2JqDTQ5IDAgb2JqDTw8IC9MZW5ndGggMzI2NiAvRmlsdGVyIC9GbGF0ZURlY29k
ZSA+PiANc3RyZWFtDQpIicRXSXPcuhG+61fgCKbe0ARAcDnkIEtVtuJ4KWvycohzYGY4I8YjjopD
yU8/Kf8yvYHLSPazarJIVUMCbAC9fP114/Xy7NVyaawyark5MyZOUpXAP7+VCfwmmcpTHxdqeXv2
6uLg1epAIok6rM5evbk2ans4W4Bk4rxars7wrXBq+e3sb/pi326iRRE7ve+iRR6n+pYfVVTGVrer
Wi3rQ4QzPcup67uavq2ihYu9bmR9s6pEotm3KjJJXOqwdbQwca67yME26vpi+SnJlYg8eYbh8fiF
zxeK/1qL+cqQcTFrntDgi8ZvXp/fiQnW/yLOsCyRJF+i6O/LP1GsEo5VGZcZRYFeQqRcEXubGIwV
xiHNMSIUHJNLSKJS7+8eu4h8GXk4cHvT01OBI21s9L8iW4I+6m2U6vvtDQSII7PfkBgLf4N9Kt6l
VtePLMOf6ltYyBO/RBgasCNJggGFYK2ITVbkYMDyknR1BB5WUvFfZKw+fnt28n/5lpIhi6B/BqEz
hRmssIPHEzsz5pQzA2oS+IUQwTS8uODRkL0udsY58ejgTQjr8p8Tx8Me3o1ut1lIWkh40vcKQev0
J0alqtYQyUyvO8BBBsfyr9qwVMfJt78FDd2AoG8RKFPqG1pZd7Wi3M3DhLr6cLUEUQeiagVrrUHY
gHl52L6Rp2zY0sI9cgIAUDU8Bo4wuHIHeeP0PevJMvU6CKn+Bg4crZkYwoEEmskyp8AOAy//3UA+
87Zhjmgi9Fi9W6u9zLCXUMeElEtTUu4/owe+wJ6WgZU+hRL55IVQCkgyAUglBPQTht4wjhhFHqLC
v2B8SdS9sELkGYgCHpK4mIPJIXYClMowHIGU6wVtdc7CF9HCw+gd0I9DiM13rnHnoEIjzxFpqEhA
mV7t+Lx71B7nBVmIK1bh04CjwpT/PxyhgzGYgu9C8+/v4Qut9uA8mjqPcHARYaq8I7NgUVEoCE+O
tWQGBitgMFKR0tj71I5wSIux+BRs+TlWBa4NKddtKPRYhLyuenrwAEr8ErTPIVIW1OpIHqoKxIcF
2rk479QelRhKG59jMyKxMGMsBKMQclicuBK2fgOHQXzbCAd1V/XQatC7uGyEJKAsBdHXgAeAzkdE
SK4/Ux8zyVhfIqVe0il2OIVdjrRIvMeRKTSfVEVoCLGllQ9Bh3/AOq8fcQ3Eu6tXdfPQtFv++Lxe
QSM+MAjJsTUddcBEcYSVXFe8W00mLP/AVaEIWW0FvhaXUA/DVQgMS5GF3wB/G3Qfwo7dx5I8o2S0
gWD6QZnrt39B/VJQ6PLjX5Gkrf4wceEkemk64ikN0UvJrznsv6Ri4LRdRLwznIo0AYGDNoYfCBqj
13uhDGAWZImWPyKzZBQPeoCbHCgDnRulNxzrMjMNq2RB7CUPUuHO2GbeTKjzmDWhtc7thDbNUIGD
WedISUxQlsgItFs17FDgMYA/BDbDCKDf31e/DUNsmT/DMgzvAutz31Ut7wMseE9yLW/YB8uAel3u
Zpaht/0k0+PsBBspYn4wssjYyOsbClim73tUqER2pTEYaTk6HByeXWCSIUPhJBb+Eia/Rsmkb+UF
De/Wk6uwByGRh5obgI63aeTrRqRX/LXihygk34I+rZJ5kdoqlTzx4BSvMw/mp6JkyEMjeXhZ9RUV
UM8F1EsBdVzmxoTHsBf6DpW34UHwMLpTu+oxMmUAjKGGLqUCjaZB0SzgNnVU044sAwqd2WbjxKY/
to2QNkHHeHP0YhwmoWVXpxyQIozUhqJYSGQysJeK/mDvHWHG6/CseZ2sUrvZbo8R0/FchgGCtJwg
W10j+YLUzb2ospatgwqIvUH6UBM+IU9FWh3mFsiIiRb61cyAS3/HyfYEJxN9l0Ojb2YAMoiVjrlk
T3ZarhH5BEEFIOTurma8WKwRCJ4GC1VK3XlJTkL6vqERL+kjdM46bPsN65MN8lzD6B23U1iEvCyp
yL9GRi9ylDsZjYOninKCxoyjV2D0fMBmwWg0CTO1xTbFYM9yBMZSh2fNy8IiRONkt0e+2x0LIRxz
8hzmKMFRwIhr17I1K4BQTIPk0altEG1CaebhlhAqehAdyFA8j6Y4639cJIoTKc4OLJD4CUIHmHi6
IgKc+GrnBXHgCLzzeYIc48cGyGV8eyi0LECIGdmm7WXIKyrJaB7VP8/s5almD/empHjObEv6umC2
FbNLNrsgs7FnRNSJ2SWb7bUseLJXQOeBaIvXVr0YDbwHnTw2/c44N6TFUMElKaDzS5MM4XlFMHW6
fahYsx13lQ0/1nTdUu+ZLGoWOVCdwbvAArtuWGgTvY2S8F29xZzLtezY8ibjxpAOjuBrYRWqDdcP
U5gfIdQdF6qXh+oJh14xlzGLQfeud816vFgBOwiT1sJnzHH8GzhuKxQ4L7jfAxxYcVLBfb6pv+Im
/YF+UbGYTGESCAZh8wMGUetVU7cJTeqhkrctN/68duzJ6NFEnFqIEw/ApQuBnNn0C0rOcIKcztup
llW4p9FuFx9Xgh8E++SSaYbMDBfYK+y8LbgpZ8ZIILTkJqryg5s8xZ2wTChgJ+HbllbWvHLmJE9O
KsVJBpyUh+6/oBYOcvx9xeevh24Ct+lFqJMqSw2dI+6fSHVBhaAZLQ2XgCnBfxd49sT0cX64wQWG
v2qpgX2gX8gfQNYsgyw0/gYvqucR6n5Brew7eh/vs1Qja1p8OICE4Zusf5pT3wWLPTmnzJBSI1QQ
KOz/UrJpApJcI+5zsAy58+LdaE/OhJEwTebEktiTg1XwYYYa4MIekALbUvCx7sMVqBdC5gPCcbRc
fQAsvSyR7OmJFJwTbriUR4byyLCDipBH2DqRfYOjMrKjIEel6CiyPKUqgJFHB4A8lr6cMgVKOtNU
Gfbm42T/ihOmlIRxnDA2nHs33PJwpaRNqW8n16RiljhJmaXHiWMmRRJWxchpJY5MkiK7XWHttvqH
bvi17oKJG3IAEkShV1XfsK28WgUvyQZbnm3ka6VuKWlEcQKUI0ARNMk2XsLZkhyDYSz8Nh2MQqjF
XLpTMSpjo1AtbJYfImmZDRwnpSQdkvY8or5TZnd1hyF2YWcrwheorKF6ARVn9ZWnD9zL3vOI4pJy
i5wMp4PZk3RyXJbcUK1SKi/DxQKMc9mT3sHZka4kqWNoqpRCoFD5KqkWlFQLxEyFFAX3wv1Xmm/q
UQ+GD6nBRe3A1XZLkrX6otfNhu5jQa6roUl9f+kVS9J1CytjSdAZz+35wz1NdfWXaBLJKZuPBhkx
CPJfiUFgD2HtgR9VhOyyi1K6LaQcLMQfWFiIhSTIH2sSn3FymCROJjuZqMFQ4fY/Y8ZlaBeGecOY
qFUvh9LsbCtV/8ab3PGpXb2eGftdDstPKF3c/bqh/XXCYQS4jLtebK2pOc24682465245Dzy+jVm
qv4IhunPkDzIzBaQRP5IxqXtijfcyxadfA7Pmj+LVM+L1INMd/PNNvIUaWq0GTITZcNJrZL5ILYV
905vQt918qkXQJMP/Zb4+CLCa25LFfEr/apdHXTd0gSx/9hL8WSH1ASOgjtNp0SiCutY/q5a8Y51
P9mTZrZIwA53/slLoDv5Emj8YLqflEhPtcEztaehNni6AhZg4A0P70kIr3HSG3qKKDIc1UosgDS7
OOfhiuz15FOPAMRas2HGCvUFV7MOC/rAZcYGXba89I8q4a0DUJ7eHp9vpVO8PnqnL6NELLBaOtYd
6lCr9zUxvaViRfzBvfPP3fbSk297Ic+hD1EX4BFoTXfNoaG39mehkZ7cNY+e+3fvVdPTIBBE7/4K
jnioKbAscDTSpKZJObTGc60kGhPTA/3/znszQENjRCFeNhRmtzM7H+899ac83+bhye7ISBJgl5KD
QL+k0JRMACutmyMItHw0I3ZzMOJOZbZoU56JBFfOF+a8V5Zi3nt676xxY1acRKDMRnCoNqvm8CJ5
oelbT3WE7gX6En0hLdTUYymvm4Hyxp0eWBZ93kAvh8F7C75g5mKNPWHsOrQiMjTsZex4YP9LtIr6
WBtqolc2Lpo+oRagrZ5U20mfF+aB/Zf+6m5ohBiU+fhPZY3hA5EEniNwIOuGzyB8BUc2KQk+gJII
S+Iwt33WBjWsmhYjtCkQdNYH/TPAuTs3MWaUwrErD4vaS1JOQN2oHXwPcDoPq2rzuFrci+BRbuvI
bQsUvpS87aDqbb9jUKakyxQqkfJrlsBCEQLWvwo5nWeI7tZPe6qtLCyrZxTvNjj+fab6qYlwXSL8
RSKcJsK3iditWTEuNOcTdT4Ti+1gkEap99/4OnmQJr2LcHDoXh5e362w5lwnoRBOUT0id1QDFVSG
vuNLCmxcPuS16BWecFDb9yaQWrN6We1vvgBZmA/XCmVuZHN0cmVhbQ1lbmRvYmoNNTAgMCBvYmoN
PDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDQ2OSAwIFIgDS9SZXNvdXJjZXMgNTEgMCBSIA0vQ29u
dGVudHMgNTIgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2
MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag01MSAwIG9iag08PCANL1Byb2NTZXQgWyAv
UERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDQgNDkxIDAgUiAvVFQ4IDM0NSAwIFIgL1RUMTAgMzQ2
IDAgUiAvVFQxMiAzNDcgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgNDk1IDAgUiA+PiANL0Nv
bG9yU3BhY2UgPDwgL0NzNSA0ODcgMCBSID4+IA0+PiANZW5kb2JqDTUyIDAgb2JqDTw8IC9MZW5n
dGggMjcyOCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIicRX23LbyBF911fM40zV
EsYMgAHwKFNK5KhsbUl09iGbSmFJmEIskQoByfYn7V+mT/cApKhLxMLWZl0rYi7AzOnL6dPvZ0fv
ZjPrlFWzL0fWRnGqYvonT2VMf2Ov8jSLCjW7PXo3bTM1b3lLrNr50bu/Xlm1bI8mtDNOMjWbH+Gp
SNTs29E/9HS9+mImRZTo9cZM8ijVt/JTmTJyejWv1axuDWY62aeu7mpem5tJEmW6Ce838yrsaNYr
ZWwclbr/tJnYKNcbk9Bn1NV09nOcq7DlyW8/3B8f+Hvg9r/XAb6yDC6Sm8c8+FVjLdPHdwGCy34K
xnCyI45/Neafs7+xr2LxVRmVnr3AD72nkiLKXGzhK/ghzeERdo7Ng0tMqdd3PzaGbWkyOnB53fGv
IkO6yOrfjSvpPurMpPp+eU0OEs+sv/A22fyNvlPJV2p19UP2yFJ9Sy/KxE8GriEccdwDKEKsFZH1
RU4AZid814SDRy6p5D9jnd5/enbyz3zKGAiFnE1Trzx5zha2B5FyCug08pEzs38Dbyp4XRS71Aa4
vEmFDb1Boqzk7Aufghclm1wpVjm5N57cc2cmGQXVDVKCTH/GXsv15xk9ZJHXJxe/IKBK/UndGjJz
qWtaSei3baslfwITUaFVs+Jh7/jpzVq+3VIg5rpeyEi1HZ0ksJPIWwIJ+Jn3j2Gz8xh7MhK7TXrs
fdgS9pzi6W4XNb0lqFMKOkbt6dZA7eIAEoZpTcqQ8LcylAxeL/ljtQxgBQx7K1xdy1mdcXoBcvFk
qm/kftr7eOelgb3red3QRKwfwlfZUHQFnxRe9YESkMGX88G/O7H+/w7sliIhI8zkYN17m8gkZgTs
nWd9nT/2tI2cz173dJy7ZCfrk4Gh4lA0TgwsfU/MB38TlTT0P+g/BdOQyZ0m74OhPvPOGXsjDe9d
8F+KhRSxwIMJbdDHhsLEE/3l9Pec5xW5rSCX4iAlC+v1V5xW/4ujCm53iKkK/qVfrOEe4Rp4lHsF
n0dJkievG6wYabAtK2wTgymhJ4SppMHFxfmHU74WZXhBFRG3ylGYn71VZMem7CH36hOIswplCFWi
YyMn+ppeRE7Sq5RRkrKgO7CRVh9PMv5tG0pi5CM7h7IV522esNQrjhjN0C+zlETfLvD0GeCegDuB
DdCIwvr77gewvAELY6BuSAsRl3dCNgPJHQB4LC0TGfROTndKkpeSlPaAH3iO3cKTC1lV021MglSp
flCuEEMnaTmc4IYTCjmBvJ1kPtZ/MbBbhfOcvunUmXwf+YsZPqOgw7gu2DC75MOoPFBevmacbD/8
D0rLyWPbJF5ufty2a7je63lTdQ0qSREhZGGMCPLW64/V935ItTvXl3W3qVbyVqum4f173hOmO9KS
e2n9MqrRae0GTR9nAmvGdneQ3RDoXXWjVqT1MrolT1BgWgrh32RUbxTJRsprqjHztWxsRYPMQwm/
50lUHqfByOTGB56q1UbMIS+xFglfD/vkS/K3MeFWLILkJeQTfud1vWjZavGjgrwjOYO3dn3FUcSe
Yj/54CW79ZJu/3f6sRtGU82QF7bYuiElaCAOR6aar0EThb7n8Yr/dsSrJVzw8iKTCSPlDUteUl3Y
L87deRWsA9diBq6Vpy8GKlO8xQRXhDNaCFG8BTnahFHbhNdWw2Fbz+yISjdkVBzYpoZXvV7crRt5
QtAQazYtZztdQB5qg2LdqbXsonmWaMi+B54JA1leyiaq6bDnMZtlSt8pSSYIVxHzJO5Vds32PXxw
XXf5gDbooEsqaEBCbqBoA7IEEYgSSWJFr+9xfcCsOZES/Z3HEuvYrH6WprOSj1zzcoRQ5ocgm/gY
OWFfxLwgF7L9QnIw2Gf60kvUNoPQkSZyQ5emq6+kj4xYIXDvSrBZi4Wedb43Id/YcCxwcxq++UaB
Rp8YiQ3fnQ8BzAo/8AVUQBtx3hIWbrXA7RPhK6x2nKlPpynV5CmsdoBXHwAqGxudg7yLQzN6Vleb
7re66qhzQOVCpDrOKIvOCd3lXb1p1gvSBDc30OtO/4Bm4YxXlexUzU2tFrV8Ql5rZK+sBy6GId4c
nH4s1oFq95FecloBqdX/obKl+eJwx92Gr50Q1SG3mi4MH7Dp7W4a2025IfZi36cVRDf476FZgeko
ZbaAPoIwUT9ZrdlAhs/1My9ae2w/Ew+85wLvnZ0eX6K6Zfo98Zc+PUaDKhMTvt3x9LzX0V94YiNi
CpECvrs1Ft2h4pTLuc0jgpBkonZh3vUTD2IcxeIRjiWkVJ+6vRckBnOWYG92ZfmH2IUpsgwUeXGx
Y5b+0pVcuquWfNlgChHHCEe+sI+KLEshthObJINmTZMdAeRD+wW9U8SODHiK8lHqy8sLhk+6J8jp
zBb2+ajQfpSSfr4QXpEMQRtFNW/9VfKrVvVms95IZX/gOSmVC9VIWSQm3W5uQ+JKnQx106A7CUsy
oOblrQ724wv+E2UtOMO9s2dAZgzS9yAR4krEr6hnNF9rrvP9zo0KwyqI7fDe7iFBjj/a8ObS4kdr
AVcOdgiE+2HFevKB/1bGooVkdVYwTkJVV6HNuzUltFuzqOWdDsIu5V7Aa+47fBhQCWVrvpXZ/Ggh
8BTYRxaq0gBlIkKJU5ainj9WAmGBDEblo7siiTOUTRvEnGN7bLbwneXQt0NbuJPrOWRWSPVsyKoi
sElOIjzOSjrxPZ+T6vvVgr+ba6rXfD9LGnkJle8SlvlUu0+4NYJORuUjQqIbpGGk5rijp55EPnMf
flcGxPI1jKgNAHX3FP6NX21wYscnXvNuNe2PXXVYgzFipvjhgtvj8ML2MPn9yrPtPmW9EMf5aN4a
Chl1l2Lh6bVQ9L38SDX5KjUJLVHWr9x0zV14qgNxf+dtjbFcdXhNCF59QzmUhS7UqWtZMWzPD58+
zN4a5PlYFrOZ3WJl1cpVEyiB0XPjSHOC0Au+FOgIQizegujwjAvkLNNdoOprrOzgovJHqxMyXk4x
N8HW6flbuSofy1V/Itqrs8892pOLX4gp9KeAeoqgz/UBqEd3NL34t9luYJcSviUHtuXAtmKGYaUP
7LIP7JID2zLuQgK75MC2wSRpWBKTOA5t2xtlKvl+cXH+4fTtIT6294GUDon9CH8qKFPGz0EQeUns
YaXHn/b4ORiY7kSI8NpS3mT8ZViS1M4Zv3+E3wr+CXe3x2HqgGj4o9ujEKlJH6lef1KN9EWDcgk9
00L9hq6J6hyqHIyy2FYBpr2GWkDOh5LTgZrIK1RJS8kOq0xZrB0AdmxDlSSDCh/UqEGJxYVSgkiq
lP6e07U9NxoFF/dygF6y7kRcA/yKx4tHuB0TfXeNylpyYeUPz3hD2g9R60JAoLJTgJUSQI5rSjmU
OogEV5QKIsIX+ctiRBXkAptbwtJLCxYaN+tqIXcp5XAX7gLMUkyL0vrX7F4cXEzjKEud29rd+iHK
QjH9TFhTsseEsV6ZhDWu2GgpS6SGYm5eZXbFrunINeSChWxh+QJeQVNJAIEs5fBi25ExyP+v0Ulx
cMXch/aETU+OhfiE770OQ3VVL4UfpbL0BCps24WutOh70p2rv+iVQ8vf/tVdMQSRC0FEl4QGJ19A
vRJv1xw8JNU4dmyInbIfcl7c0d3l2qezo/8OAAl+9oQKZW5kc3RyZWFtDWVuZG9iag01MyAwIG9i
ag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgNDY5IDAgUiANL1Jlc291cmNlcyA1NCAwIFIgDS9D
b250ZW50cyA1NSAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAw
IDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTU0IDAgb2JqDTw8IA0vUHJvY1NldCBb
IC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUNCA0OTEgMCBSIC9UVDggMzQ1IDAgUiAvVFQxMCAz
NDYgMCBSIC9UVDEyIDM0NyAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA0OTUgMCBSID4+IA0v
Q29sb3JTcGFjZSA8PCAvQ3M1IDQ4NyAwIFIgPj4gDT4+IA1lbmRvYmoNNTUgMCBvYmoNPDwgL0xl
bmd0aCAxMTkzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJvFdNb+M2EL37V/BI
AiuFpCRKOqZO0aKLbou1tpemB1dWEjWObch2tvlJ+y/7Zoayg3y1gYE6gCWSI/m9eTOPzHfN5Kxp
nFdONVcT51KbK4s/uastvm1QZV6klWruJmfTbaHaLYdYtW0nZz/MnLreThJE2qxQTTuhuypTzdfJ
73q6Xl2ZpEozvR5MUqa5vpPL3NSp16u2U023NTSzkzg123S81pokSwvdx+f7dh4j+vVKGWfTWo+v
NolLSz2YDK9Rs2nzqy1VDHl2HYdPx++8vjP8ty7SV47JpYLc8uBS01qhzzeRgi8+xGR4ibD20pg/
mp9YKyta1WkdWAW+GZXKqrTw1pFWpENekiIsjiujJKbW683DYDiXpsAPXt/s+KqQSJ86/c34GnjU
jybX++sbCCTKrK84TIK/4j1zeUunZg8SI0vdHR6UiQ+GpAEPa0cCVay1KnWhKkGguWCsGRePgFTy
Mc7rp3cvTv6fd4GJJHUagi9VgHKuciOJnFtAV2lumr+IbR7Zpj4ULpLlEBUDYjpsWuTeH7PhwthL
LpecNFAnhzqZSXIkOUFlZCj6xCPBu7/RQ0GrXW8ArESXeUtCGEiPINXOVxzQdktB79LKll7hWpTU
rI/RswagUJxIIcsOxWezIwcPYJnAToxzWg1AT1w4w2NEb8grPJVjhxrKQQJs0E2lluhNP3TPuNQw
rRe5hFPlGNXwQuRib0q9WZIrdepivpv/dyjliVB8PmJBvzOYzyYgLV3b9fdoOpLdUvv+iXwVWNjz
5NUVeRGyOaitCXpD9hr0vH2exFcLojo1ifWhpp0g/7KFYRSEiXKoeqrS+uBDxMtHXjQPXsKKpvc8
BVZoRCFFb9pQc7gXab0qSH0irZwFIWeFuHq9uqZEQwU4IBuiY5t1vE9liFi9Ba3IooE4+xRWWbq3
YdksuCMsqVlUR7cb0P5JgXRtZV+5Q2Jr3W/jsEe9VASPQp6je1QPR3TuRHT5cWOSUvgFex/7GTnW
ohu6hVrArXIkrOfve6QVQj/8e/ZGYZ0/EaQ/FOyI8ssqIXUDZSuDpsMBKfde/QggeDhYIIXRPvdq
96rx82SrqV/Zh2bdsmt3Y6urc8NFheMSzmxB3/L0ir/X0QC+SsjSEOJuEWev79A6GEvsTl3qGZ1D
Sn0+ZT/5qOKhA31WVcwDKX+phfCad7ZQVO2Q6OJwcqxjVj5Bc65JsrIBO0GOsphTvRYgQgZAzANi
WkNGdrvCXoK1NXtHIM60KKEdhyzAGGs05NfEJ3ail0+rosjfMkCcxE6kedjT61hOFzAGnJ8MedaS
s04U9QPRdXF+QURLhLU8JKI+0nREk5bk2RgvNEumqTn6OcVXzBAb6wkUZasvR5LZeOLcmyTwoSTo
eLuc00kFyO5jAhLSTDXs7TkKEb+rP6nz6UdBHqRzUYN5qOtDLx1+ajxfoOlePrT93GPToxx2y+V8
xUbdievteSCrDCCLKzK1kyN5O5chTJ0A5XLoA+rM4p+nMZPhaGpjc9OeC3YZudpncQg6GaMIh3tx
ks6QWItx05ty0M1+Jau3ciFkntr3gc5EOHrI/vZ9M/lnABLx7K0KZW5kc3RyZWFtDWVuZG9iag01
NiAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgNDcxIDAgUiANL1Jlc291cmNlcyA1NyAw
IFIgDS9Db250ZW50cyA1OCAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94
IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTU3IDAgb2JqDTw8IA0vUHJv
Y1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiA0ODYgMCBSIC9UVDQgNDkxIDAgUiAv
VFQ4IDM0NSAwIFIgL1RUMTAgMzQ2IDAgUiAvVFQxMiAzNDcgMCBSID4+IA0vRXh0R1N0YXRlIDw8
IC9HUzEgNDk1IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSA0ODcgMCBSID4+IA0+PiANZW5k
b2JqDTU4IDAgb2JqDTw8IC9MZW5ndGggMzAzNCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry
ZWFtDQpIidxXW3PbuBV+16/AI9BZMQR491tsq1tvEjuN5E5n4p0dhqJt7cqSSklJ85P6L3tuIGVZ
VJxmu9PUnqEAnAsOvnPBwelk8GIysU5ZNbkdWBuEsQrhn0dFCN8wVVmcBLmaPAxenK0TVa2JJVTr
avDix7FVd+vBEDjDKFGTaoCjPFKTT4P3+my5uDXDPIj0sjHDLIj1A/+UpgicXlS1mtRrgysb5lPj
VU20ygyjINEzkZ9VpXDMlgtlbBgU2qs2QxtkujERqFHjs8nbMFPC8uTXT/fnX/n7lex/q+X4ytLh
ArY8pMmNRlqiX67kCC75QcBwzBGGN8b8PPmJfBWyr4qgSMkLNPCeivIgcaFFX6Ef4gw9Qs6xmbjE
FHq5+twYwtIksOHd/YZ+FQDpAqv/ZVwB9qi/mFhv7+7BQeyZ5S2xMfMn0FOyllqNPzMPk+oHEOSF
Hwy6Bs4Rhv4AucRaHtg0z+AAk3OyNaLgYSMV/xnr9P7o4OIfOcr8QXzSOM4Y16VLmKNPwAeEvLM+
LXCEx0vN0OUE9cQME/ip1xt1Xq8rdnszM8MYfldILABUjCFZg2BHuQUZ8TgGXBoFhYP90yzG7PUx
4LoYcLz/pcHUorzJIW+GBfw8mCjU5dzEGK8v0ZBUY2bm8hXuakYc5YZ/ZXWx59yhhWBPslyBsVFc
xOhjsgDNYiyimG0BBGwKJxrB+fTY2Aj29Wvq8vrNKZoi5HfqBBJomEKMBQYNtLTvaDKwaqYGeRzE
EPtpGgYOylgQw/70berB7Zeped5S4xjsdrv0xGWB6xf/AtnvnRRBlgrVReikx9I99NNJT7qnIIhO
FU9HnaelAL8jmGrjALJbjGAeNjU6PQO/QX2KdFWfmARLJ3Ej+haY3mL45ZoCf9qUJA4Jroc4gMoh
uqAsZ6A75HUMFgrWTN+xchRpgFwuhAHi2OoKl1e0EmYBTv7ZsStfidigOSyVW9bMeypQoUqxfoqz
IPWh4LGO0iBzvX5m6hE/94p75a2bDzmyh97vyBDi3vsx7ApG0SVJAkhcUCr62WtAJ9EjSApIWHLZ
er3kmlHNIEMxOTE3KZXGm7LZbGm82ocKkq4fKSIeAapPmDW7DsVDOPXQe3FKchjkHijbVhObMlDj
61OsDxFhhPXyAi5Q285eGyx1I6yhUMxP1OWyeTAOUhYqn485gBKMwjjFD5XJGMBmRBd70CV5EaR5
H3ZC7QevX9wrPwJeD7kfuySFzbrmwLXgMXZvudJew5UdQeFAFGXpaoxBNlmq6t7kuq5+g69aGLoU
YrxAAFxs7QDJHJEsEUoEj+4Q/BJjG5Qp3WCgY9Usq3q6NXQLOWwl9vFNgTftxZepR/DtFWflSYf+
IYB76P0IRxFu5/FtAcaIFYSxhiG2kLdDCMaCQhNv4xHepHgDxhKvuKjOiPXq8vziEfMFdwFXl8x+
gvmP62sMfkaenBPRjc2Bm2PIS4zzTBg2qmaBTflhPhMV98RRGy6wH+rNJ96hpsshF4po9Ys8na6W
Mx5toFgXeiex6EylsKnTwNs9x+vIPrZblU0jrHc7xqgN84qBalpuSgqaUAGAFjzeNpRFex2GUkex
aUnBTMRS1fyL5u4sb2isTtV6S3MIeeLecAPPs1K45GTMuVrVjZoToTROfzaOrlvKD0fOwS5f8Q8S
ZH/2ZYdSFDjh5a+0fBVbKVvXkDsz/6RyWLBkxmTm/Ugb1IrXRI8YwGtwJ7CYHAGdQ8ct10c2n+3q
EwExH8IkCdxjYwRBjJKwFTgMexcqCT2T9qoBJHrWXw2YeqQa9Ip75c5nexQHSfpU+hC9txrERb7T
nLmkrQYJB+Po71QPUk59bHZSudwxAkbn6s0I05trQszpk+sfR4rnIvXX69ElARuJAijVBNvkT5wF
XVMYSlM4Qsgj8YDmCeC/iz45Y+fv+NPo0OI3vd3aYWsq/ezbe/oMtYQFtGM2Ag+0j03Xdg5h6p+c
rez1a2wscyjXKDv0wgh3HHflpXtXhc7ruAEnYNrMl2tyRk2X6fTGfCUA/+1Rr509pZTQ8of8HztL
3+h5jBwfcHsV2Ci08ZG28RG3x37mxpSohUZgnXzpSuMGqJagkh2/f6AvLi8wXTKoXDtlJ6bseK+B
OvmFynlCr7lEv/IhBmXaYnU6b586Vfv8+Y7Of3Z19eoCinGSRFg0JKL4fCHWfz6f3XUty/xCrXDO
L44U4MFOmeGBskLCe+EB948Hye2C9E3F9qBwVz9/D7Cw2FjOAgf9SgFhwN8tL2Gbl0PTgL1gJY+E
RPpLgPSaX6yHMfkOU+a5jD216VAQfJUJ45qBnR6tRd9rRp5T/+Kok3KUXlKX6K627c0fU2UHNF6e
vTKTX5+m7FOgWbUV1YWWqdr/+52y8D8dncObSIltTTP7SM6u/8/qLviN/YzFxUnd3HkrhFmQud63
AlOPvBV6xb1yaCGZ6ixca+6p+EGG3teCy+BVi6LyXggz7xcnbTsGXYJtP0beGM+eyZo6H43P3l3A
c6KALmPCHBdXlyd7mLg8P4KJUPsx6Rf3ytsjW/sEkj56PyJp9giRtC302gaYsC8mk1gB+RbIWVJI
hUQueMowPWe6BY2560poVHS9e8HojuH2zeUZWjbyHOW3qTx0G0p6vLkcvCN1OWeeUp61a2qo+SsS
Fb9wS9bGEyGxZrVqllU93dIE9AM4ulYfQCMG9mfYSCvWWMsuLDdlJaxxwZM71lh+0Y4adp3hyzOG
o4BSb5m3kigfSVttwIBbA95KvXlLMU5Q8G/Ga4P3+GvsZCL9VnnLyKQ92+nZ2VIF6dPg8MvjaXl6
R+leV8tmqjb3UNrATG8FGGXBKHjNAADDhHBI4VvePebjVWT7x5YpBkPSUsNR6KpWW2aZLVhSlUoW
zDAHFO6YsZwrL4n9TKpZ2xzAQLiXDZ8KzpSHmdt/Qe4EtPuGgB76ZyzhZJNMesx7iGgIp4oclurf
aIrXAjbrJwY9ol6u1+DQFMj4NpnJeMGsxnKQ4QHxPRP5pXq9KT8w63wGQBda9sJwSzA6kfT07Dt+
3Tl79I3J7NobHbXS0cFVmcbYkPNbOj9O1SnGRQTnj/D8f5414Fe9UVO8Mqv77YK4hLeLFjhaCCdj
6oZlS1F8ayi6N3WjalJWfphTmNAbUN9zDMWUmsOU1qgT9pizUjVDghLBB67hGFRW9p7i43HO5M+i
sPqNhblfzvQnfHpmFH8gNuV9RZzKCjJBWcEFNcZMz7CHgS9D9orGz3Vc/K2OS1vHxZ3jCnJc6h3H
zgBkmIZ+i1rPvKO1uqpXgmPq3RJrnkKNaEoeYgLz6yPiNM64SORCmZFqhjIRcbUk78KOH2leGkye
Zua5tjua1bx+tPUdfTe8E5/pUZhBSIqgN/0Rb03RBGSKJ7FUSGTFFAMKGfhLMRW3ebxziOf6M/lD
E/H8xHvxpUTtnAEovEBX1bssaFOo9MHNSil5yqaGnqKqqePtAh+uCljdzCXwA3WjL5dqvkQZkltK
Cn/thsGN2e+wsvRYh8XUIx1Wr7hX3nZQedh2UEK2RXJEuJ+Klgn1uGWH9vb0HvVfIL84WyfqbEy9
X6jGZwOrfoLY+hUYgfuTsqF6o97/HKrpwOZZkIKmOMmCXD0MohDu29jP54MxceS4kkIRS4HF5thJ
/rvsskd2GISBcJ+jpPDYIMBcKFXe/du3+kFITpURWUmfF+xBW+KCVvme+X193ihTjhMGEGFYKjFJ
F7gwZkLNIxySHnsvzVYMr+zAuJIkYIkTcGkPYJO44Bo/wHXiOn2HJFuIwHUSb+fu7RoHRjV5ggBc
ce9OSRJH4DouNcJ7m8QFHZ/SJ3ArR+KVOOES5lSKnU3igoZ7BS1aK1Mvo7U2EqeyRWaxUNYkLqgN
pR4mnGjFOfxB6CtOJuCT0ZIJJnEBiIaZQLWoBkMQm0CdX4IVc1leKaIgNYH6HVK+WzCLm0B1Ku3A
Sx5zJJayUOiW3bwjf5vEJFsgj5NpzVundW8dZnnrnU3iguDt0uBXQJSdo0hKOFwzkqrA/+7EZ08L
Uj8Ia+0UBIswaErBf2rRnSMKZW5kc3RyZWFtDWVuZG9iag01OSAwIG9iag08PCANL1R5cGUgL1Bh
Z2UgDS9QYXJlbnQgNDcxIDAgUiANL1Jlc291cmNlcyA2MCAwIFIgDS9Db250ZW50cyA2MSAwIFIg
DS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1Jv
dGF0ZSAwIA0+PiANZW5kb2JqDTYwIDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSAN
L0ZvbnQgPDwgL1RUMiA0ODYgMCBSIC9UVDQgNDkxIDAgUiAvVFQ4IDM0NSAwIFIgL1RUMTAgMzQ2
IDAgUiAvVFQxMiAzNDcgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgNDk1IDAgUiA+PiANL0Nv
bG9yU3BhY2UgPDwgL0NzNSA0ODcgMCBSID4+IA0+PiANZW5kb2JqDTYxIDAgb2JqDTw8IC9MZW5n
dGggMjg4NSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIidRX3XLbNha+11PgEuhE
DAmCf76LZU1X3cb1RsruzjS9YCRaVmNJLkVvktfoW+xb7vkDKUui4k5m0q4zEQGcgwPgO/+Xs8HL
2SyyKlKz20EUBaFTIfzjURHCb5iqzCVBrmbrwcvRLlHzHbGEajcfvPx+GqnlbjAEzjBO1Gw+wFEe
q9nHwc96tN3cmmEexHpbm2EWOL3mT2mKwOrNvFKzamdwpWE+NX2oiDY3wzhI9Er2r+alcKy2G2Wi
MCi0F22GUZDp2sQgRk1Hs5swU8Jy9PXTw/kf/P5B9n9W8nwV0eMCvnlIk3caaYl+9SBPsMkLAcMy
Rxi+M+aX2Q+kq5B1VQRFSlqggddUnAeJDSPUFerBZagRUk6UiUpMobcPn2tDWJoEDlzeNfRVAKQN
Iv1fYwu4j/qbcfpxeQcKYs1sb4mNmT+CnJKlVGr6mXmYVK1hIy+8MKgaeEcY+gfkYmt5EKV5Bg+Y
XdFdYzIevqTiPxNZfTg6ufgtR7l/iDgNGJ/NC6tS0G/h/Guc7ZC3/KgZIJLoCK0118MJWH2uNyYF
wFfGgZU0qlmhJUTgJFEGC1Wtbre1Ys5rg+4wmR3AOIzSIM+KRA1tEMdZe37SHt+ePgRbzPQYNOL0
1ERFu6Su4fxYv6Xf18YGqb4cvwHLA6VfgEaBIwpM5DQYBx0/ng0itVKD3AUOjC0tUjLGwOVqSL91
Nbj9MjXPW6pzcH27T09sFtj+7V8g750NS0y1Mca0o92n6JezHv9K0ximew4Wd2qWmPcG1JzqCmB0
EKHAaHhYV2ZYAJQbDAmxnleALEYr4kZNoFpuzBAirSZbW9QlbQef0kMcgLOKLIiEGcgOeR3jZ6HR
dPSSheOWGsjlRhiGDqxqjssPtBJmAU4+dezKOz9f6B6WykeWzGcqEBGkqpT7L1TsTcFjnYGB9uuZ
qWf03LvdCw/PKbKH3q9IB7zOqxEVypnLFp27JAAEO5+f/UguPFYXSr0ypLHdbos6K/R8VTYrTEXe
qdW0KevmkcYPh1glIWXaHqyYegar3u0k3BUdkqew6qH3YwUxBgKcYGXbLI9BBrGaQuBwED4wrl0i
VDHkrAnaidV++iNnwjFGP8DmgkzcEyPO9UPeMuEIuSGsVxwVc1hYGxthtjEhaKL29nrLm7YsAqLl
tcTIPbRtClmxF22mnkG7d7sX3uriFNo99F60kwKKgBZsj3XEUN8gFBFhHUOkSeFXln6aji/UbKvm
dybX1fwD/KoGx2WjVhh6YoAKA5Bi1DNE3QHmuAaQw+sRcg848q9BAxnhHQGw1SegPqxqKAfQFVTD
THQc6oJ2M/wsX4HCwiAXARCEUvQX2lwucZe/lxdYlyhCGPlw4WiaaqFoUykryBkc6hlqiD4lA+mM
hk9vZJm2U/4p9fbQ+9WbFnCjNvAUnV5Jn06PUSW5+EbKHpOgj7VLakSMP11fTZ6wkhYtrF9gdIoF
7Ux+yUM4TiGEFgtpg5ajVszgPYpXhb1RFVOb8v39inRDOgcO1CukKfW+aj7ycRWlsUIoIt0v8nTx
sF3xqIG0kreHyoUxvxCbugz8I+paFpd8pUrJA+QaalE2pQKpaA2hwgDjXNoWYscZeuxzGNwF8txm
Lwt2tyGT3D1Ktr7jr6LMK5OSdkywMEv1xKdwyq+yf/R3oinKzZxMlZwmTQuJ8Gl2vz4gAu2TBVVX
zPewlZUn2Rn5RebRldARY1KYpYxF+0qpFapDL0qyoquJjhxJqP2+1L9dhAspdpiEDrceE/sdCZhg
2puVxv++wWo69TkHnSZvU874Sr0ec+LiXzK2XH8/VjyXXf94O76mMjkWAZD89wwtSVtDiztDCztD
K7ydOc2Txrh9M3NoH3t/53uQbvhcvj8usL00fQ5vftl7AKESQ7UTgy7aru5YL0d730ptcEMShl7E
IbxdQ+Vbmnegkgxi4/12R6qpKCsu3plnovlnjHrvTI+ffcdvJcw8XH/ZtzwdPY+RrQTquyJK96wk
ba3Etc9+jjzy2kIjllZ+KXE5ynOVWJQcd2BRNm8PFYNS19umUhPMNlgIUT2aUMiwGDENWumSiOo/
9OGle6zAEv1IS5V6+vfNlACVl7/vyUR4AuMrqgBS/bvkHB+XGEjM4plmjgWD+ic97WDkh9Rg7TUS
ETcSjhuJmBsJ/4K2kci4kXDyvvp0NOeyAUYRtJWEllS2RzmepEuiX0NT2JNm/TGQNyOMZVdtuzlv
W9D/d38nVUSEfsroO82oUanXrNbs/o6hbt0/KtqAp6vazH4dDD3PYRZAxr88SOfz9PiTKaSREpsA
m02yvLWJrLUJqSO6sJT5sCTdAEWgnIJSxkEpgyW00ljfP3L/pg7+vh0WEpLorkkSR1ri/5G3tQH4
29+xV4fnVNgO34CTcyfESchBlRRDDMbAJJ6QsCck2qcVjEPeDcLcsRtQYZNme4l/XWG0SiVA7dXn
jorjvvqcqWfq897tXnjoq/eoSE5uP8nQW6fHcdF2u61lW7FsNOIEa21MsFMshzNZU1fj6ejN5Aa7
IjIg5JhAb3sAR+zyM+2KUPvh6N8uwv1TQYP2aOsxsR8GdGuGIe2iXRRgtHs5mzkF8f8WyFlSSGBE
LmgVmJ4zPQJhue0ip3Ndd+s6SNH9azDKSH821oLtYX8IM+oQ07b/oL7QQsBAlg/sqhVNVIm4p9x8
Qt4vdybX+F8kzFckr2zMMAW9rPal+z1yyK2hD19nixkSvqoSLuqNcLPM+Z7QZjy98BfYu34qwTj4
/rNcAW9cPXnJggV6ITRZCvfkGnw30xOPoBJ8RIKHQKBZPsHr6SupHMk8vnD7vmcGPb1k0jU70jZh
rVbASb8jgHa/VuMIxMgjxwJ9JaGCkFOvxYIFN70ymIexAcmhYqGcDCURzninwpyE4h7ksH3hqtnu
i0RwLBU2SNwxJ6YejHhL2l3x6+BteZjZZ5Tf/Ccxdb6tF1xrN3dSWXdmi2f6qDtMSDkYfMvlU05e
ZcbfpD7fzCvFQ9m62khNXyrmX3E9v+SAXd6rigzCwsFFW+ffc5xvtnWw37rt+bb9Ct8m1SdtxZ6n
jNDorkJ9JXoON0Ij/NCZPlr+hRk6eKqaoIkW+hq9k+pgnGEMFbOOxKxJxm5Xymgp0tEqHGMLit55
xk0j4lt+g7Zc8ibZs2mptwYvJntEcs1XUTL9RAIeCN7USwAeayFwkU9uhcbClH9DJMtDedtG9vob
yhdWI4xP66fHn7XLPQ3GXxmdj/Pd6A4sDGqyOUWIGIIuTtUlXA+UF1EU2vBaI6zglE1dCj/Tdvga
DC8ZWmvTVAu0ZNJsRvbOzKxYHC1ZFIY7q1/4I1YNuSugCBbtJO+WzAu1ZCq1JGy5F8ZHudJK5jvj
8Nj2nO58jBDlzlvnRyyXRNau3e0fKlP/3gd+TI29HHg5X2S15dVHAYDOlXCU7D8cTzj97udq3X2l
1o/rd4i4+o6L8bnklg9csSPlwmDPqv7FD+SCHgNRTNDkhAwX8m38KySqSQzLhL9cCiNPmeM3RAj4
pRvgLgJioG8T5Kjy/Zbbh+qwwIrTcwUWU88UWL3bRbiQ8rCtoYRmk+TMzn4qXkuoZ691fLAn9sj+
AvnlaJeo0ZRKv1BNR4NI/QAW8iswgr19VFGoXquffwnVYhDlWZCCJAcFNFxkPYhDiJiuXbgfTIkn
p6UC37CGBSwl93g6Dqo/7we333WSw/9VXQY5AIQgDLzvY4wKiP7J/f91KehGr02ZNh6IlKQXOYSL
nAXNDvL2bAcNTWORSe3hYVJa5C3kjo/ufFjIoyRXnBjvw1XiaAgB2ZDYPQ2dzVP0HJq/g0dHO89m
bjHFYkUxtQQS2xzs5A/UX9InCmVuZHN0cmVhbQ1lbmRvYmoNNjIgMCBvYmoNPDwgDS9UeXBlIC9Q
YWdlIA0vUGFyZW50IDQ3MSAwIFIgDS9SZXNvdXJjZXMgNjMgMCBSIA0vQ29udGVudHMgNjQgMCBS
IA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9S
b3RhdGUgMCANPj4gDWVuZG9iag02MyAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0g
DS9Gb250IDw8IC9UVDIgNDg2IDAgUiAvVFQ0IDQ5MSAwIFIgL1RUOCAzNDUgMCBSIC9UVDEwIDM0
NiAwIFIgL1RUMTIgMzQ3IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDQ5NSAwIFIgPj4gDS9D
b2xvclNwYWNlIDw8IC9DczUgNDg3IDAgUiA+PiANPj4gDWVuZG9iag02NCAwIG9iag08PCAvTGVu
Z3RoIDI2ODcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIncV9ty28gRfedXzCOw
tYAxg7veLJq14XotOSadpMreB5iCKK4lUQvCsf0b+Yv8ZU53zwC8gbJrqzZRrDIBTF9mpvv07Xw+
ejafa6O0ml+PtA6jREX4k7cywm+UqTxJw0LN70bPxptULTbMEqnNYvTsp5lWy80oAGcUp2q+GNFb
Eav559E7b7y+v/aDIoy9deMHeZh4d/Ko/DI03v2iVvN649NKK3xq9lAzbeEHcZh6Kyu/WlSWY7W+
V76OwtJzqv1Ah7nX+DHUqNl4/jrKlWU5eLrP/e/vfH4n+99qe32l+XKhnDzij/ce0VLv+YO9gkl/
tMYwwhFF733/1/nP7KtIfFWGZcZe4BfnqbgIUxNp8hX5IcnJI+wcnVuX+KW3fvja+GxLP8WGy5uW
nwqGNKH2/u2bEudRf/ET79PyBg4Sz6yvmU2YP0NPJVpqNfsqPEKq7yAoCz/65BrcI4rcBQqLtSLU
WZHjAvMXfNaYwSOHVPLP18bbfzu6+Ge+le4iNmgCE5os1SqDf8uku03RWT4q5FJzWER72icBL5gy
6u9hsBxuSGDvVrUrQcKdr+lRN+p63ajx5eVL4Z7s2TDQaVhGcaagMo7zbvO029u4rQMAMYcCDTUz
X5fdkrrA5rH3ln9f+SbMvPPJG8AOHj/j0ykd+jrxcGrefjIfabVSoyIJEyAtKzNGYpgUKuDfph5d
P04tio6aJDi+2aanJg/NsPgj5K29sSRUE1NCO5A+Rj+fDwRXlsX43IquuI8um/DewMeZV8OMCdIT
ECOvTe0HJUx5T/kg9hY1LEupirnJE+SW136ANOsx0K6aisURUF5AL4hUqwtpMIfuSNYpeZYe4cZb
inISaUCu7i1DkAB2C1p+4JUoD+njS8+uXOTLgW6xVH0SzbKngoowU5U9/5WKHRScrXMk62E/C/WE
nwfFnfLolCMH6MOOTMCbODeSQ6VsmbIPlxSGoKgruq9fYJzUm6gzpZ777LHNZk0+K73FqmpXVIcK
uDiDIdWsrZr2E78/7NsqjbjMDthKqCdsNSjOypOyt+QxWw3Qh22lEWOms1XZ2UqLrWZvz/0gs2bC
FWA0B2r6+oUzyYSSHjLJGYPb0TQZTwPHBds6iDkhZoRnyYUAG3UMmkIHEaS9xgH1mmXWosCmyMm+
nU2GYjhoZ6GesPOguFPeeeGYnQfog3ZOS1zfmRkNmTWztsXjNXUEJdJ0BAy+sV+Xs8mZmq8pwpE3
FjeAKzLO4iM/VSvfVavElGI1dCNi/5TsT4IBr7L9NexPMr39NewveSCgatGo+gtzPIjsCgWlRHrb
qNay20OwnwqrzvrHOW9H44ZKHqUpUlctRbo7sSyrtkHq4Q0tu6hYtW19ZW9vRSsnKTuH+5hAmzEE
CJBOoOG4oOg0PVCOQWGAPgyFrMSJHBZMl56isscCKk1GHUGA+JLYixEQE2qFUxT4pFtSY2a8vHgx
3WGdSh9yeXFG2YxCb8PVXn7XhAbJa1S5DHXd3L6olTA4X8qqZW9VLdS2+nALRuSFGIAgjhrARVlT
H+r2s2xXc9krLcVqd4vyefWwXslb6xsujbKpPTDVI2ZT56G7RNPYxaUcqVb2AvYY6qpqKwWthItI
wVw6SbJjPejkHh2unAA3Q2eeb+9P3ZLaUP5BjwwGBB8iy44o9I6wE9QHPvdZz8cvCdVE3sAjcAzp
JcPBbLLCl/e2trP8tALICNPDmj6dgCajteuDADMa5hJ9wiq/Fa8s/dKK7odHmpd9S3QQIZY6HCTD
4la5JcUJ1aB90UPicISACZ8uQrq5kzpf9t0/XlOesAFBfU3WQd94kxfq1QQxwq0w/TJ2Cu+niZJv
K/XXt5MLziaxVYDav4WbNOtx03eCUdzDh1olAMinslZyr5XsYihzQ803zB/967fyfZfCwfOeP66L
jRKj14nhim6gM0nnlsyNdZ3s218oLArkMpINnPC+XU1vVzvKvIcvaDi6XW/YJwRkHPu9/41m/BPf
Bo/qQIQ40gSdw+Tzv3eZgbdvYxSAICeVOtsCSNYBJOmu/Q36OFwlBxr7u5bukepVbRFldzuR4Z+G
kacXU6kg8wHYcJi988A359wS02SoXYrJGYS599JJw05pXnQ+6Br6SD8lq2y3/Afp+LAgqBfcv6Te
v8iWBiXXpuENj2jUg2SecFwRlNKdxPxfuy1Pkd3MRLVLy+kCucaUClVhD26b9gIL3ADE9loNG2n+
g82jubWNTu1oYS0ZaOoTA7Q0BBwSHJOyxHupMIJJDxcwoDabyr4t0e3RNkeBaYrOC+ZJQetw0XnA
IO2wB4x4IBUPpJ7EaNoxwRPsA/RozUDL8OQS0ZFFDIOl97Ci3vT/K7t0+SVI05j6FFvDdtz4hG7z
BjXAUAPCCS/lAQPjwFZyofmKoa0F2plAO+HkUnorFmhdKnmyCO6vm/Od8n5YopLZ7A9ECU8jQwOR
UE8MRIPiTnnkxiWTJUfFjzIMDkYmd8Emo1GX7SNj5xK6fEoTDqWpmXQIsqZeTGbjN1NMTpjiaI04
ppcXZ3s2MSeHRPPYkDgsbpVbElqY1ByIHhKHbZEWO7bIOrx6OvTnv42ezeeJAvka5DwtbWNKXMj4
Qi+ErqGxMH3nmiTdXKKT3q5UcxvUXO199Y2hJqJFgdTUnVIpcD0HEEcVpPKJ5SMFWwL4MX9FxqdO
hBdVtfELj/5bDYsV66taP8g4KLe0Oxm7ybXPDznO+k46QlVbLh7zSNh+yzkx6+0e+BH2fpRNgSL1
4as9Ap243rnJlSh0SvhjabmnFxyHU2dBZe1jNTgTWNMsd+y1e0vukXJnX5x+6JqhzAiI+yg3B93j
UN9CSRRd0GLdXPnUZan2hp/1lmO55OM0NJ4EKR+f2qpqucspq8L4+yeh3S9qJa9WdHUvUqpSws/d
Xeot73m5ulU1m8xg4xLrInzrU4NYtesm3M7WW+g3fxD9UTe3GQv+8Q3Oh4sv2AMJQJ1t4f05ga/0
znz2rl2U+tpbTpdsEJGXDpPelqKYEAPZ1aYzIKCZcUViwi57BUPxyCQ8qrqGZWKvrRvldvjClAcy
NNlVIhdZEAb8St0u4LwWosgqzpHYWMtqwKtTKphuG9t/88Z3gErsjt2chNuWY+I/6BgTd8jNrWP4
ZDd8WPaOxuE+yo3O5SZnPt7/Tu85YoyiZIMoKS264210l4xYYggyBjHxMbSJTT6F43dry09Cu+cH
8F3ZI9gtqg/rfwrHfo3J8lM1RqgnasyguFVuSWl+QItKqixDkoNUPpZQTx7rcOOOeFz3I+Rn402q
xjOufpGajUda/Qxw/AZGQO2z0pF6pd79GqmrkS7yMIOmBNkxztTdKIbKLOkWbkcz5il4Kac73GGB
qukWT8eh+Ty3o+sfRrqEAaA5jvEkxRgliUe+WW+Zspo4RmhlrBfX2mLpGSKq4aw2zoQHlhchtxDH
mTB1VypYautKhVWzdSV4qdy5kuPpOHLkd3clx5SWvbFM0S2QZloSHsTR1rU7lo4hQz0SvUkaywFL
WrobJZqaFPdNWmmFb13iNBmzwN1Jz9IxFHYbUhsb3ilNUjGVW6Buyx73PwMAF5F+GwplbmRzdHJl
YW0NZW5kb2JqDTY1IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA0NzEgMCBSIA0vUmVz
b3VyY2VzIDY2IDAgUiANL0NvbnRlbnRzIDY3IDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIg
XSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNNjYgMCBv
YmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDQ4NiAwIFIgL1RU
NCA0OTEgMCBSIC9UVDggMzQ1IDAgUiAvVFQxMCAzNDYgMCBSIC9UVDEyIDM0NyAwIFIgPj4gDS9F
eHRHU3RhdGUgPDwgL0dTMSA0OTUgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDQ4NyAwIFIg
Pj4gDT4+IA1lbmRvYmoNNjcgMCBvYmoNPDwgL0xlbmd0aCAzOTE2IC9GaWx0ZXIgL0ZsYXRlRGVj
b2RlID4+IA1zdHJlYW0NCkiJ1Ffbchu5EX3nV+ARk1qOBxjMTW+6MBvGtuwVx4mr1nmgqZHExCK1
JBXbv5G/yF/mdDcwHJMcWd6qJJJUxQHQjUbj9BUn9eBFXRurjKqvBsbEiVMJ/mVUJfhNclW4LC5V
fTt4cbrO1GzNLIlazwYvfp4Ydb0eDMGZpJmqZwMalamqPw9+1afLxVU0LONUL1fRsIidvpXPNKpi
qxezRtXNOqKVjfCpyV3DtFk0TONMz/3++WzqOebLhYpMElc6iI6GJi70KkohRk1O67dJoTzL3jdM
d+c/+P1B9r80/vrK8OVi0TzhyQdNtEwf3/kr2OwnD4YVjiT5EEV/q//MtkrEVlVc5WwFHgRLpWWc
2cSQrcgOriCLsHFM4U0SVXp593UVMZZRhgOvbzb8VQDSxkb/O7IV9FF/ipy+v76BgcQyyytmE+bP
kDMVKY2afBUeITW32CgLP0VkGtwjScIFSu9rZWzyssAF6jPWNTWtrnQB0lXJX2Ss3h0dXPxfjkx7
IR88sGGVVqXKYefKhVuZKsSE8Zd6DZRxd338Ph4DrkyfAyOrZVxHObnHxSgaIuT89OL4HHvIkSZH
6o/T+af7VaM2S7VqZs38n43qEzM8Pn25gzqJsbas1NDGaVq0amYt9la0rPnEQo8g1elJZKp2SZ1H
DqZ9x7+vIxvn+mR0AUeFjxzheHCYODJOp7Hh40f1wKi5GpQudjBtXuXsu7Er1ZB/V83g6vvUsmyp
zkF926Vntoht//bvkDtnY0moNqUUuLf7EP2k7gnHPE8x7cRjuo1HnyIvECe5bgCjQ0KDc8lw1UTD
ClAuKIOketYAWUpuzE2WILO8FS9hn7xcTXk7QlAPaYDY9rKQOAvITmSd0m0FKtauRThtWYE8XXiG
oYN/zmj5jleSIqbJly27CrlCFPqEpem9SJYzVaqmXvdLBXFxHlwhYF0gvffbWagP2Ll3exCePGTI
Hnq/IR14XTBjYkJQ22obLhmAGAOCsp29AjiZHqkjpY4jtth6vSSbVXo2n27mVLlKmDgHkGqyma42
9zy+28UqS7gw92Al1Aew6t3Owl21RfIQVj30fqwMYswGrEzZJkCfWibvTgQDggnxAdAqzlkye0Ve
Y5F4UNXh20fqNbBDKtHIl+fjwBVfMFIjYQ6rsuj5KWkapK4UYSR5k0Iq0/dsIxRki0knkfIywi4h
a3SOGrJ6XuipqP5y10I2R+HttZBQH7BQ7/YgvLXfIQv10HstlFXoM1oDtc5svDMjrVRI75CnL3j8
ZjI6UvWS8gKaGQLKCFCAcX71FcUBNlAbrg9W3zB9ulFzv3CFMChbSB0CQ83XUHGzQoog3jU1QCl6
QwhCagqCNs2lP1IkeAVW8IjWF0galcvgQTS/gK0oB7EDwPhwAWh3E9QGrdJysJr6o9dedghLt2WB
qtOPshIUoNa0o1686wxJ2usJID3gBoc3iky79ZBDPtBD7/eBvIJGwQlsGpwgKVonoHigiMr1CGUg
8VHmJDRTwOra0EPCP2XON+dn4y7vGGGGReE9UhxFORk8Z7tngiqFqEC/kF5zTm4nZCVLnmujGlne
TD9+8lws60ZaUfbaS/Wx2RDtc2SpH2ka7wleeiPfy7vlfOH71rTtfr2KavrNnkt1EgftV+S3tHjd
OVPxgV4LdTndTBWEk2MkCnAZ5/LQbLltpxuawhHXSsMqAapS+/mGJx3VuE9f3wt1diNfOrvgyOPp
1O8an/N7YiztQk7ln1Kql4LekO02l71UvAsCm0Xwm6oKxwuNO5JqRzO/2y/C54T3bulXwlYrGcJJ
GJPsPfXUbWStbyCCPtyLpHp6LdKaOEDxikI887xel9ecN1y44HsWj04U7LtnxdR2wZPDXKZ+o/BO
OsbL8q3xtq2yycR4syXbIxMUMn4FoY9bKWrIMOILo8Uiv2MGtnIWYAsb1ImSVXo6mdboX4RnN8lk
RbXtRffyjKf2p5r+7V64J7mMksbu1n1if55BMnJu2wLbrM00Hr7Re841ueQVKrG576Eoy47O1OsR
pQ+n5ZeDsNQ/j5TM/a5f3o3klZR6AWi7GLL6D/K83LbeSdoGXeXTAB6sMoErdcONi1Xn7+G34Xb4
WL4HR61+/NlV8uRxOoURY5EiU6awQBK8eT/vb3e8406sQCWgrcOwdyce4F4trr7B+wALFHDZT8s1
W6KJqFxcfogeCeN/e9Sr3zf+wsAETJ6E3t8fPY5RXAGloDJ5xxXy1hVce+3HHcwhSZU45+yVS86j
JEpFvfH+4w/cKYbPDGe0nRIV9X554CDInIfRhvx2Jg3KkksNQvhfGypqqLWTRprPxaUn0QlUrKjQ
FtS+5tsZ8qGlPDc8luXTl11vte0rKwThM8AyfGvfkxvpq4dS8MZSNQXvrGVSmzn6BKrZzSqYAEXO
UH5/7h41zDIU7FL7EH1R11ahcF7ttJB0P/hK/XfiKD1HbLNUgvlbN0xK9wg3xMPLdfzwRzxwq+VQ
lNgtEM/LHDLwF/PgWlyXwjnkSpMVoegZ6+tmbcgrC3ivlXcPI3mOjhJjXqrR/5ocg7l8bqPUcQvL
/cxqF8xw6DP27h0U0ZrmRaf5cHyXX6k5R9+dE2bW59UuDn4buVVJXUoHh6cPgYziTrGgHgp3eF6q
d6yY7VjRtC2k8aFw0WxW00VEpW1NFc7A1Us93+DFNxbzDoOU59sM+PGOt+JeuXEBHU7UcW+iDuV6
1pZwvvcXbqC4zplKN/wOKoHkHnCdJGurtv6bpw7fa35XWf0+Zn+gsl7q+AL+gtdemMvUc55PnmNn
PlveRxW92PBeS1EZmpVqvmA2a5pLapJzHYdrPemLnHIkU0OPOKZGQH7vF/PZdDNf0gUVW83oV1L1
mFeuuBG3TeIUpbLrtb8+cO6TuXqfWgfXHvuq+sGDf/hx9WDv9UTh9pODrytfH7itLQOcBpeVa439
w+CcutRUU0ZBy5CiTT1lIaN68NugRBNRGmWLKs6VK+MqV/BUpNxVM/irWgxO6kFFiwn+eWDQfuUu
yZUtrc+qt5LQGU79krI6RP+yv7Us4oR3FknsSt73QIZ+ogbxo9M3b16OR/tPXS73WVv4/UvXsw+R
Hzh3UyI/YIQsj7Nc5QD4e0ZwyP4lQZmRyX6XEVwRO/e7jLCd/L+NwLWQg55aKX5m3MLLkQK2SRgA
afXurlsoDxjozFul3rdKmsaZVaklg3zHLAjRhM2SZnFld4xy/AijIEAz6835XGNj4puTAw5uUQst
4p9ecN/BMs3Q3CW7mBxycQh3IGewE0oJp5Yh/0L0VTjaU53Do9F26ZmFDz24XYRbCk2hpmDd397D
sHexKhFbm7IC09bW9ILzDW8qtqaWL9MjcuhKTwjUwq+ps9Hk9GL8ljK7ozXiGL85PwqQe7VNVcEh
+zDx1H5M+reL8DION4YtESM7mw+S+/Eoik5VyLeWNuGh4MJDociq7kNCffuQMJBX2m2nQVluJlXS
+FYDHpoBzE2UIXHIb0NY5kgf0NXoO8DMTRqRlHyWshZaOuSbFF4+lX3/oPLsIAVuoJVfXMiimq4j
eqeUQcRszgKnIlcmy4W6iljwKkr8aSnnMz5GNd+IvLxbyjY/94qe7KjaPMzuYVAf/Vlfvb6k6s55
IjAI4cm15x6fcxfPLxaD/kJ5lQWLNQnzePgdTd9ND1ZTl2/N51sbudZ/eK+a3rhtIHr3r+BRW9Sq
RFESlVu86KEfKYoYRQsUOSi27Gy7sR2tHKP/vvPmkRK1jl0DAXqShvM4nHkcDodNDKvKgjypYM7y
PK32j4so31DDxe14aaYPekMMybbiGhk2pezYaY0IpLWss/56jeMoYJ/uqdHwwQ6ki8HcE7K74UzT
mzCwOfXCwjWB/d7EmXg+NBmt7YXTRjLkdmQsQoovWntMTnJM7Fcek8cN+Vbc7TLw0whZ6qSTRPfJ
IQg9+CvxVoj/4Qr7gB++X3Etr3jFAUEXm/bsfTB8zXVUb3bUmWmM6htVH8BRle0mcCgHeLg0Yc3Q
+o/mzes/8mT9/K1G8X2UKQa/fznfOJzXaUd7s5NcMzgRInjgnJ3GGhwgObf3+pkiMg1lirZvOGp6
RpJydPq4qdfML5fML2PhQpDbDRLoJ/3/dlMmLOuJhuOn6PQPkucti0GHoiNlH0UHHwpBpcdHjIin
re4Lppn+/e1IME6yzS7hugIvzT1/7u6G0expVzH/bKwNR99mYzQ0DlL7746toVu4vUK99SixUH2g
WTrH2S9N/+prbwm7kG1j/ntJDvXJ6gHoxKu/KZqzV+KknGqCeipvgnIIP1qgXGTYZhPnnBnE5oPY
j2G4j7PMsNILX1X2fq+CblGZUR9ck8oStj8YGOjNA5IBt9GBcN1tz0TomAhdRiGoov9LxtdasACZ
uHJcc1hF/ESgaVbWspUlZm5nRiOXa9M0RJfD1dQxsapsqb5t7rMjHxhD9EOF65e+0F4f9Go7xOsT
ZeFi10+DuRt3XEaKAwpNkKbdZ/GhXi6EK33cjejFSHWj7YTOMb+Fu/FnAXXZr6gIzYtT2/2vlZ26
UNF/xxXoJAWXqm1WpS+5N1GYY3mXWT7W91ANDUUiPqGNFfZYOAeWRLkz+3XllRL0mYj8uLPFk+np
zpbaZzrbJ6fTeLO0rkWFxj5V++deCk8q4Zf/j0fIUwtH/ZeNP6/9bnuozfZcG+7CnG9PSvOj5Mlf
ApSsezBlYd6YP98V5vIErDRiSJ4l6Mw/nlSFdCSOA96Z/cm5YrwOOTxxP8oAGvh50n5BSEMvpXR/
cvXNYrlyePQlljmwslz53LrUcsQsCAnP0XLlahpq6xzuzHIlx1Egs2w7xLsAqq7CgCC6RnfOdXIC
EbVcwWKeAwWjBkatdDViEive0xVO2i8I8bEKUTt5ugKExyGCjrItCk5yZUtfbAm1PHmtp4RFISP+
SlAFCHFNofMJmNVqNawYEUXLFUuPIhdkNVqCXRiVNlejRU/uFsgMkPzT/QTJYbcs3nQ+bA04CwPc
voKxFFa+wLSW0UZMRNhucXgGeWaFlWOpUl41ZL4oA0DOV5I4M2QGdDa3R+5KTviVuxxI3bVtB2cS
dyNmQVimgbrrhDUZayoGWRVOCcZAGz2uiKk73QMwXTcJZAY0svtHNDiXr4hQecWDK+jvHGSALAAP
19ZESIXQzZ6JsC1BCRGVPOpSHiJkBsirzoc0C3lra5vkLaQ0b+HJKm8JmNV1PafBvwMA6YlG8Qpl
bmRzdHJlYW0NZW5kb2JqDTY4IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA0NzEgMCBS
IA0vUmVzb3VyY2VzIDY5IDAgUiANL0NvbnRlbnRzIDcwIDAgUiANL01lZGlhQm94IFsgMCAwIDYx
MiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoN
NjkgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDQ4NiAw
IFIgL1RUNCA0OTEgMCBSIC9UVDggMzQ1IDAgUiAvVFQxMCAzNDYgMCBSIC9UVDEyIDM0NyAwIFIg
Pj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA0OTUgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDQ4
NyAwIFIgPj4gDT4+IA1lbmRvYmoNNzAgMCBvYmoNPDwgL0xlbmd0aCAzOTAzIC9GaWx0ZXIgL0Zs
YXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ3FfbctvIEX3nV8zjTGoBYwZ3venCbBjZkleEE1et80BT
kMXEIrUktbZ/I3+Rv8zp7gEIXiBrq3ZTUuQyOJeenunu07eTavCqqqxTVlU3A2vDKFER/smojPCN
MpUnaVio6m7w6nSVqumKSSK1mg5e/Ti26tNqEIAyilNVTQc0KmJVfRn8rE8X8xsTFGGsF0sT5GGi
7+RnYsrQ6fm0VlW9MrSyFjo1vq95b2qCOEz1zJ+fTSeeYraYK2OjsNQNaxPYMNdLE4ONGp9Wb6Nc
eZK932a6O/+Nv7+R/G+1F19ZFi6Ul0c8+aBpL9XH914El/7gleGEIoo+GPOP6q9sq0hsVYZlxlbg
QWOpuAhTF1myFdkhyckibBybe5OYUi/uvy0N69KkuPDT7Zp/FRTpQqv/Y1yJ96i/mEQ/fLqFgcQy
ixsmE+Iv4DMRLrUafxMa2arvcFAWfjBkGsgRRY0AhcdaEdqsyCFAdcZvjW37VhKA3qrkz1ind0cH
F/+XI2sbgbzzwGKly3OVwc5l0kjlssYn4E8s1BtomaBw/D4cmQzWvYCOSi3jCt9Sh1dDGVwdX4A6
wsbYJDDJkUBd/Xky+/zAK8tarRdqWU/r2a+1Or28PBdGQz4fCP3x6fmO9gPAKrEqcGEc5+1j09YC
Tt5a8e05uFm8eGxs2S6pC9wf63f8fWNcmOmT4RXgCqQcAQagsKGxiY5Dx5cPq4FVMzUokjCBgbMy
YwSHSaEC/i7rwc33d4ui3U0SPN9191OXh67/+He2O3djSXZdTIFw7/Sh/ZOqxymzLMa045Xxxit9
oLyCt2S6hhoThDVATIbL2sBSuZ5THIn1tIZmKcQxNVmCzPLWBAjPmpF5vZzwcTgijI8BPNzzQvjM
wTuSdQq6JXax9kmY05EltidzTxAkiAVTWr7nlSgPafJ1Q66aiCEP+oylyYNwljtVrCb+7dcK7MKs
gUKj6xxBvt/OsvuInXuPN8yjxwzZs99vyAS0SWPGyDau7cqNu6RQxAgqKNrZaygn1UN1pNSxYYut
VguyWamns8l6RvmrgIkzKFKN15Pl+oHH97u6SiNOzz26kt1HdNV7nJkn5UaTh3TVs9+vKwsfc42u
bN7oqkH8+N2JCQTECRRWQi0yfk14sQg5AYVFaO0NtBZrRMuLkVCEVyajkERkskILTHXBPmERqmJo
/ogDJblQph9gEyoSAopUnaDJy3AzCrLqFHwujcV/YXOO8WgY8OuY/ym9+XzXMC5D1u01jOw+Ypje
4w3z1myHDNOz32uYtESR0djFtSUbBX+yy1sqRjLEdQsIQ6/4+qVLykGJHh6paqF+ZVDXJsLGcnbz
zTgaKa7RCn3Lu5O1msn8xthGv5hdcgqJNXLVUM1WAvxlvV4iVtC51R1XPf7sel1fK89gIUXhEpho
8RBTPSUPHUq51azKItkNPxf+UhFCrW+9AGToVMvFarKS1/h7xD39nn/Oio0fKaDTplm2lTojUeHk
42K55hRYA4ZWX4e7gIniXrRg6xGoHD4oPN0GRXFCzrpz9PB+P07SgmgboMQtUPIOUAQi8EZkiMgr
PhHfFVW7dpGNDxRdnI26tCN4JBaF9kixtTLKPmSHlaEoydbIO9aI2Rql31ay5KnWqpbl9eTjZ0/F
vG6lVgViEySjj/Wa9r4Yx3YSHOTac6/l9/p+MZv7wjZuy2P/RDXZOnOtTsLm9UtBcozUurlT8YX+
Fep6sp4oMCdgVH+SArgDoeEc5bVcX9LlVE5trqeSS60ohaBAB8H0Fh/l+yMaw/O4FGSzSAEo+I31
iq2giC9pDPqSFdaA7lzn6WkFSBGi+wVNmwMUISmQylXN++6Mo9Ah/IRUvqwvqKT0R0P1WtKhTNdb
uig3zYBPrpQGUmDkvWGPN+TpowuejKQUKigOFFT8NnOZ+oNCOzZcLE0p6xLkoD8wmvN3DRBCsGUj
yg29LyM90WxJsCAysgtTdk+pEyWLVP8gXHzlvV3PT9Ed9Ne1frff//uPN8zbwjRJiXLv9KH9/hAA
8Tc5fD9XDN/71MAOT2Vg5use0vTwTL0ZSriVr4/EPw6VzyRy6qd3wyY4CwOUSltY2JTLUbxxD++f
aDVlAjNs+0jWtIpP6Oo2w6fSPTrqfd/Jb280WRUxIlgMA0RtX7kXjzcn3r0Wr3/LR4Pm7E7GAsJa
tfp27wMMQOD9vFixIcgxIcUH80Qt/tGj3vd1cnKSbCTsBNRnIsH3R08jFFAgxJU264Aia0GRtGI/
7WL2TQntzn85oSacdmuPJH/hLpJejJ5RMoprVFsBJiEBfta+oETw1YHh+p/jSM6oy33Z78+4slW1
fQmS+yTdFSFqRLCJ9/8zbkst96Kl/jeSZ4b6YFzL/Fo2iSfH+oBrea4yUF8cdsEXp6atPFBZrp8y
KlKpUGnwgfphPeM6B6XjspEcuLGUq86evZQeC0GaxhEJI+HkVVU5BSvd7HQ3rXfD9NU/iazwZKFL
4030iTcgotIoA4ByLsjHVAsmvHRNe7jfq3ELPJv7A+H8YsNMB0VeMK8xh1Tsok0at2neJGHrfB6v
rAArME76I66RL1DDYsxLFUp9m2Ewk587Q/0cZUMqr5a7ymwuJYDimpenzl0lorSzSacWijh+a49q
gWgrvCcmLBVUKnWEf+5yd0ZhJ7xSLfcCgszW62m47wtFlnfNGLf5qBBYXtXr5YSSD7Wt6Eapucz1
bI3mah/jzOz/IGR4be2pK++EjqAp/AnElIosKYfDLCLHakc7LswyRJeoD/y/twg7Lw9cGeZFbLvG
ed7meMN1X6zfh21JmOvwCuksRtPK8bhZlUVPjza2RAQeN1XW85bylJ9OVb5+MCV1qehRYy5pVP0V
s2ldX1MrkOlwv7p71rJ1RLszQJ//Psxn08l6tiBRFRvQ6tdiT6YVYdfS7ESSLQ+A9tC9z0b0vmcd
XHtqF/m0637fHvJ5a3m/k+SYXDS6sxDRCzNipJUSHWJNAcVRtEDhy2eH1eCXQZGERWGVS9IQWk8B
SURPG7pCLevB39V8cFINyrAkM0WKBxZh1WZRhjN5mMBSd91S/ZzqIHD+af9gkeMKOhenYen43COd
2jM1Q6ed3W86k1aU1ghCz+2c1QzUnFrYFHY4h30igFRt/f3x4Zd9I+PQZP33QZbm8jNDNLaaI1az
XtA739135O74kLOt3GVrwjMWNvE43cIatbYqRqR034OaTan4AGRsvIOz4yfgLCI0E6peJNJkNOYU
7/S+y9qyDKNCuZzarO8oMk7RoUW7OjnktWCeYDtFK5g6FVE4CPgL1jfN1X43SRzZsLOfolp0jx5v
mCPYyG4cxwePHyTYE6yMxNY2zzHd2FpqVLZ67NtbeFuKKiqgkDg2XLDKmjobjk+vRm8pTHKBRRSj
y4ujRuX+2RbASrM+nfjdfp30H2+Yw5qya1l7e6cP7fdrJEu3NJJtrG1D36wmUigjnaSlz8Pc0Sq/
7wtpMkbhNok64TjHecf6TA2UplDo2sBh/bcmfVKYwWutvoequcahLSU/C1lrKqI742IgfSLn/mU4
ONbGhTCRX5zLopqsTKHpv2cxnTHDifCVyWKubgwzXprI3xZzScbXqHqL5fX9Qo75uX/oyc5T68fJ
vRrUR3/XN/9eeurOfcKwYcKTT556dMHlMHcAFolC+SeLLlb/Jb0Kltu4YehdX8Gj1KmUXZLL5fqW
aHpoM+mhPuSQ6WGdyLYyspRI6/j3iweA5K4tazrji2UAj9hHEABBONN46IrNazs9266bOh+f1UaI
beGUdFtxrvLAgvmwSsPG+T6KxwjR+3o4fjPDPV0WHVEqp1pjtl/UdGB07zU8oTXz/m6KEy1gPx/F
wruv+fLBm8A8CmS7l5WmN6pYLHE93Qmw35m0EndbmIu33QIXWT8cjrIXikmsWvv8Ch9ViX1jleRL
0UqQ1vcLCsNXnA0ld5vT/j2Ozs2vFgiT+fOW6BajjA8lli2Hks4O4+6S5i/68djYHZybLY8UTpVm
OPZ70itSVifIMGwoB6m05IMH/H80nzh1mkQqP0Q9P0T/WGiHZPkfBf3N4cbzE43TDOkLU7ZpD0+y
aMvbHRSK0DCDR/wZJBS8JVk9JOB2DwAshrZ2Nr1ftn6d2dDrlzLQgDnGsHb+8Xfz/nQ6yESG5wJm
nhrh2lNy0We2J9PfiFlRR/Eh8UN59gJN4iNLP0TSH6QklcjR7HrqCXEVs4bcHzfUy39c/obqb2US
oyLDN7anl8k8isQomd1bW37pGbUW/Zqp3Mtki7ym60e6NvrmFWUgdQ4B9WLcq3Gj/3C38dJtKu42
vOYD1XXLyQGxP6q6T6vMZmKnrLPzmx0LW2Q63oCwKzXqE5p66mAjbJ7Qq/kuETi3+A5XCbsd1CH+
qknX/9+Y+zfG3IbcZ30KeSAaaLBBOgkNcxRyiEZsV9TmKFs+I1sQd7wU0SUt7txl5Kjw6tJSOk5P
AS7R7gXP/RlAEQXxE0W0arinBtwa+KHW3CsX/VR/c/gliNXzGaptLs1QYr0wQ726PDnPM1JnMUKO
zdGVofLF2leN4CXGy7TOfTjZzzu/bH23PjVmfc2DXWWu17Pa/EV58p2AlHVPpq7MJ/Pl38p8m3lL
NL2MzTGah6yoiX9nzW5WR2oedNnTTbeqAyFcRc+vIAr6+G52zZgGqqbCg+Jhhpm6DXnRriAkELvZ
7W8zzKWYMl1DqcOO6c71SRa/LZNxTUfu4DdiRC2QAqgxwLJb5xt24123ApcsY94hSJJdF0ZWFyrY
usBH6ltQQThoA95nBUgBw/4o+OwhRuaQIRnQCkni5OlagMrGwFv19KiyMcnwCk3FCEveAAkVu02Q
DKApnT8ziqAPHXIbIbRClxTeT2LoW4fJv8RQF5Ugehr723w2CmpiOnXKzSgKPXVHD0Je13ikcDnA
jMmIwNklx6MgGywS7CFvQhVjzjYEycpEJ2MyouGX7ISz5W0mwpDGbK1ncoWtALIZmeWfUaVMUhpK
VRQTqt7JuWUWCZMRTutlTNVGKZjMVhQTwlSRegRKJ2EywpXsz54np2a5CEc+a/ssCAwo5m4UBCl3
W/mVlKD0A5HH1W+rKFmYqj9BCqBCGU8rwgZJg1wSopjUhLUrLtZcEwmTEW7kmXTsuZX69DQzYaQW
mf2SxjKiFcLcGnyBZEDostuc3BWwo2SAognTWqONT2stYXLDoh6Rau2/AQCDDxjQCmVuZHN0cmVh
bQ1lbmRvYmoNNzEgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDQ3MSAwIFIgDS9SZXNv
dXJjZXMgNzIgMCBSIA0vQ29udGVudHMgNzMgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBd
IA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag03MiAwIG9i
ag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgNDg2IDAgUiAvVFQ0
IDQ5MSAwIFIgL1RUOCAzNDUgMCBSIC9UVDEwIDM0NiAwIFIgL1RUMTIgMzQ3IDAgUiA+PiANL0V4
dEdTdGF0ZSA8PCAvR1MxIDQ5NSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgNDg3IDAgUiA+
PiANPj4gDWVuZG9iag03MyAwIG9iag08PCAvTGVuZ3RoIDMwOTYgL0ZpbHRlciAvRmxhdGVEZWNv
ZGUgPj4gDXN0cmVhbQ0KSIncV9ty20YSfedXzCOwFcKYweCmN4viZhnbktek1ltlp1IwCVGIJUKh
ICv+jf2L/cvt2wAgRchyJeWKV6oigOmenp7T9+PF6NlioY3SanEx0joIrQrhn9/yEH7DRKU2DjK1
uB49m9zGanlLLKG6XY6e/TjXan07GgNnGMVqsRzhWxapxf3onTepNxf+OAsir9764zSw3jU/Cj8P
jLdZlmpR3vq40jCfmt+URFv64yiIvUr2V8tCOKp6o3wdBrnnRPtjHaTe1o9AjJpPFq/DVAnLg6f7
3P/+yudXsv+rlOsrTZcLWPOQPt57SIu95zdyBRP/IGAY5gjD977/8+InslXItsqDPCEr0IuzVJQF
sQk12grtYFO0CBlHp2ISP/fqm89bn7D0YzhwfdnQUwGQJtDef32Tgz7qH7717taXYCC2TH1BbMx8
D3IKllKq+WfmYVJ5DRt54QcfTQP3CEN3gUx8LQt0kqVwgcUJ6RrpVle8AOqq+M/Xxtt/O7j4Ld+0
cReS4AF3TfPYqATsnFt3K5O6mAglJv5eVFd321I1tdqWy7L6VKpJDWClXv3R1wk8q1K9AlOkCK0f
BhlgmcA7/xbrcg/JsbZBlELwjU0QRSkdzTBad3Zk+ewFiE3AwlN/bL25r6MgadfU6fmrY/Q7Ib9R
R+Ct4wQMGoB6iWfp3OlipFWlRpkNLNgpyRNyxMBmaky/23J08WVqlrVUa0Fv06fHJg3M8PYvkHtn
wxJTTYT57MHuQ/TjxUBsJUkEn11wmTbdhTHD+wYslJHNEkhOEPpGPrYlgKwhpjaAZOwtyyM1x6BP
IBxxC9ogAu7XvEhOttoWIqMZ87MqKQVmmPg0PGQZ/UJDKBNpTQc022LTUscxpKBlcyMLYRo0vzOX
chHPWlz5qENxxwJZc2UD7ezugE0hMQ8blamPGHVwuxMePma1Afqw1SzwWmezUDubmbwLiRguOoMq
lLVfLwmgKYSAeu6D5SCf3daCZFU0FdacDKxJgTNvim1zR+83+1jFIZXUAayY+ghWg9tJuM07JA9h
NUAfxgoSQW4cVjpzWEF/QFjNz48ZA/bXHEDDQuG+XrKDTdk7ATtKdYRrP9/RAgREiNhNCLYaUh+u
YuaDcgNJJwHHxVpSrIV9D1eTQKEbxJWpj+A6uN0Jb1E/hOsAfRDXOIe63qaNBxXhNfcG576BDJK6
z7O5bwGG6ZFa1OoTFQiuBtvq4rNv8E1RPki8S6IWjeI0E1GaSb3VTV3xW8ONxdbRr32D2aggeRUL
YU4uMmpnTS2val4vV4pfWGDRlI6TUhUcMTk7ezGburwi57hjd+qYrK17N1OVHC/b+fgaO0E40rlP
x78K9t0CIB3yCSA94hCHN7JM0/nKIW8YoA97Q5KDRq07mNYdsp475FRMIAWNIcRcwMUcW1i6IS23
ixREsXd2ejLbYZ75Y0Tx7JTZjzCV4ToFmKEAyxjdTLIaAm7I+jlsYAbFi8IHPsbLTfHhqhJJl8SB
Nom8lfqAZQr33/NxJZs/80R6yU/nnVDffEM9NRtdlFTFzq6VOg6c/luobrS47p2r5FDRRa2KplBw
ADpIqAA1bW3iujIbdX2xBOF0gx4ckVo+Fmr6goa2rxiWBmxp4TicWnLvjtmWeHYKZ2unSvtRkIgJ
dVBnGCtgKB/7rhf0O/NDKDN4IgtUcrAMNbSZKSWf0VeswnNkAZyO+W5qWXHbDMYl8otMNTvloxeE
sMU+wrjbTVitLoC1FhG3LA8SMkkvgz1crlAZ5nEHXfmxbO7jCEkhgkfB9/mdxdFV6LQ73kzvXSLo
g6JgEOnMGietWaOkGyESNmuBGhmPf2sMCAu+DvFAlrF0smXRSNpAAHW3Bwe2cJ1LpjEjmJoy3SVz
lryDvMZS5sVPltwDCMWoZSF75ZSStWLmgialD1eiE6SAVLSWk3bWlIjYlbhS2PWhe2qAiF4US2cZ
MJixr4hiBZTlgk/clsXKx0ki9j5j0k6/Ur2S6KtAvQWRWO1ZKlb51EmUbZs1694I8GjKxd/YbHHi
smEmBrwucFfsfSz5icGFbQqcixd3q85RgEomI2TwGOrbAIoELYesFXOIWOGXRfSCCFXcLyxxmnfD
woPaItTh8jK8XYQLKU4PbX1IHK4tcNOug3s4oUz/LSMGFRK9N35MT9SrKRYLrjCWc3Hm/ThV/C27
/nk+PSXHi0QANMrOjBSHXXoNu/Sau+zK7oo5zO7GCDhF7w+z0vBb9/pUvqcytqrSY1/f4yeIJSwi
aGwjsEDospNpfRtaBALl0N7zl5j4XpOIsZOxn+dMh6+05u/BEujP3KllFI9wh/f+E+H8dm+Dmrqc
DkFEE4eg1k4h7qooanY6w1SGs8fhSqA7hHS37S9w/YNvch2KRLzVLxQOlpCy0ClQCX/vva2o4eec
S8MTknF4ws+q3MFQYxQKGgThXx4GvE7E18FJsD9DsJtgSzrGqRA9J8FWBPobnkCw3TnY6pm89Z/v
wBGwr82519b9iQf7OO3mnYfe/n3Yd/ftaYycSsEBcp08nkqfJI8KWk7+Y+SXwLY0AJWSdeW4b4fy
U4vZ1ySTtMuNu9nAUvV45wHf4hdq3mMP55MYEs1B9zqcgv/E6/+pSeTs7MVsejgXoLO0JhTGMdw/
ghFojH7xHJvmFNAYYyb6P4ADU6qmuQlveQ11IqbfxLvDVJN51bJoKkfnJXV+02/mwrQH2slzFIv9
Ygxg9bi+rzQ7p/pqqL4asXOv2YeCE5vBZp+pjzT7g9udcPBDphqdIeuD7QcZBpt+k5te0y/2QptI
783mmuIUm0NjDzdPZU2dTOeTNzOYCWA+wTXkmJ2dHu0hEoXmEUSEOozI8HYnvL2w1g8AGaIP45GF
PTyS1n09HfiLX0fPFgurwEkvgJzGuVQV5IJphOkZ09EQmemVnRZaN9agH3kNFA5UjAPMejeYTGBc
UE2908TEOHQS30cItBRKOrZ8yi1uaFEVWJYij39rFoXFqao36gITu/W2OIYlEtbWCVfljiActfit
8bHA9SctD1UrB/iOA3VSb/7DRzWKFdmTzWphevEojXb3RAD4Yv17FLSylmYtATGHG5msa9szRnhb
3lKXe1PjEIZSUzoB5ly6BVYx0i2HJI7e4VFJ01TSNMQ2dlLBU3vDN5QQymW9XanmkhuvHRum1IhR
GxrT3WJsQ3f4eBXZfruT1g310x43d8tS3TFLteGdqlCygOBYb82MxZVyOyVl0/IV3Ah636be8q3g
TlmYmn0oe25v/qDb226Y0oITgmthDAEf0QAX5o8cvJo+e46G3nnkW/Ty6Yap6G60It8Nk48hplkK
wIxZqIChxyAiaJANOnxOtocI2dmvllf0WTOxXCl+YbkFy+SP8qmARX80T0StX6UOLxxY0KEigova
jI/0qY55pjny4f0tvqcULjjlxOTksq0XYxRhyDBOyOGQj9wQ2fiTOX6jFJGR6wBtQw/wwEJUkCOK
D/Un5ngqRPYb+xQTxZcECF4TEzt3KL/kZzvusZXlwu1S5a77oBN+YA8TX2S6qAmhK8qIAHHie/Z9
SObMXrMDL1mlohGB5LhM2uwGjwhgloZPdmeWOzceuOhuEAZ7Bd1ArRwu6EIdLujD253wtmBnYVuw
HTnMH9s8SCXNmPq4ZofObumHxX+B/GxyG6vJnFqNUM0nI61+Ar/+FRghSu6VDtUr9e7nUK1GOkMF
tLIpVLxMXY+ofcnahavR/7ougyyJQRCI7vsos/BFQYznmDv0qvv+26EECc5S3reCBRr91ZDuLzAi
uKiA0fOdExPEYHzh83r/PFDXI0J0Vr1HkSsCUEZozesT875POpt5iIpvH8o0dUMlYRsfuroYkqS7
kQ3Q5NLFZIMZ+qzgZIUHshU0eNvluWwmiLsVuU2ZW1/lYu3xjnRYLsvPAlAGwyskKKkydZh/mwni
usNkvR2sGG7hdSl7ALlbOp6faMdkr9Y4e0XDJcIHRwIQgpmnV72V3DU2PpzicNMzcSSArv8a/idL
tbQsu8aHLHbAIetIANSxs7xh9LfRNFanyq0lkj0FLGA2cKlgGmGeMkNvgi0xQegR1VyZcd8RrJKw
w1HZaq8AC6zKarEnGJrWjCxaQElMEDxQgqX8B90KqO8KZW5kc3RyZWFtDWVuZG9iag03NCAwIG9i
ag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgNDcxIDAgUiANL1Jlc291cmNlcyA3NSAwIFIgDS9D
b250ZW50cyA3NiAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAw
IDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTc1IDAgb2JqDTw8IA0vUHJvY1NldCBb
IC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiA0ODYgMCBSIC9UVDQgNDkxIDAgUiAvVFQ4IDM0
NSAwIFIgL1RUMTAgMzQ2IDAgUiAvVFQxMiAzNDcgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEg
NDk1IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSA0ODcgMCBSID4+IA0+PiANZW5kb2JqDTc2
IDAgb2JqDTw8IC9MZW5ndGggMzUyOCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpI
idRXW3PbuBV+16/AI9hZMQR4z1tsa3bd7NppxKSdaTo7tATJ6tiSh6KT5if1X/bcQFEXOk6nyabO
RARwLjg4lw8HZ9XoRVUZq4yqFiNjwihREfzjURnBb5SpPEnDQlX3oxfn21TNtsQSqe1s9OLnqVHL
7WgMnFGcqmo2wlERq+rT6O/6fLNeBOMijPWmCcZ5mOh7/tRBGVq9njlVuW2AKy3zqemDI9osGMdh
qlciv5rVwrHarFVgorDUXnUwNmGumyAGNWp6Xr2JciUsR18/PZx/5fcr2d87Ob4ydLiQLY9o8kEj
LdWvHuQINv1JnGGZI4o+BME/qj9TrCKOVRmWGUWBBj5ScRGmNjIYK4xDkmNEKDgml5AEpd48fG4C
8mWQwobL25a+ChxpQ6P/HdgS7FG/BIl+XN5CgDgymwWxMfMn0FOzFqemn5mHSe4eBHnhpwBDA+eI
In+AQnKtCE1W5HCA6oJsjU1nKx4AbVX8FxirD0cnF7/nyMT+QFI8Y5OGUW5jlUGgy8QfK+qKwqZ8
qovVYuEat25VVQfjFDy95I96L/O7R7dVq7Wad5xC2G43PJitZKXFMimgKHi6Vjdutfb6VutV2zG6
uVo0WCt5mEEZ2gxj6mCOZbaeP4iGFaxEoHEdWIz1nr7WbUHNQSBh/yTNCzW2YRzn3bnTLpqWj12R
4lxPICUSPQ1M2S2pqyABa97R72+wcabPJm8h9cHCl5BSwGHCwCQ6DQ3tPqlGRq3UqABLIVmyMqNq
CBMwg34bN1p8iWpCW3TUJAHzbZ+e2jjMhsW/QO7tDUtMBQkA1SPpU/Sz6qDAC+DDAs+yGKa7CreZ
Ty8QJT+/DcAg7QJ07ALxJ5ZJg8FG36+hNDM9cy/VlJHnnEQqygWj3/AiZfq8qUVHO+bvyhEOo26C
XVneggqLyYOkJW3QNvW6o0ICFXrWPshClIftv5hLedhhK+4AA2NdP7JCtlxBXuwi712bQ+IOh5Wp
T4R1QHynPHoqbgP04bglwJtg1DqEm3Ww58sDfXQZYH362a+EohP1UqlXAQTPMgRk4C6AgBbLHoAU
btJD56QRXeUDzmHqE84ZEBflSblz3SnnDNCHnWMg8ra7tJLdpSU5PQ0ywocYkuGsojSOwVOUNn76
K04LgBdEL0QNo9UFSaxosmB2+ThAmZRKogR3rzEr+WYDKa+xJp4l09R70sVrd8T4yBTRARceIC4R
RB3gN4aq/Iqt6y2qoY4GKpS11UzjiZD8DlI6nwKTdgdtedNbYUGFNe91jynkDVBOlAD0i9m8UXiY
S3BVpHYwl5j6RC4NiO+Ud5l2KpcG6IO5lJZwH3XomHTomHEmEbjlkEqIXQiVuV+6nk5eqmqjPkLJ
JQQ8EKTV4nNgI7r7ENrQq0it257nMS1u8RrOtFsTGa9rw2HiKeAfJkiG4Yspsli7Ql2xZiTD2Qgg
jeyPa22AoFzf3HV8oIvNgCu93ahaPTjXqFbW/J7YPbCuRV+l3ALeNtauPlBX8mU+YWkwC0tKRsy7
e8qYSMGiSbOs6+h2hewvpxaueAPWl2ipemjcRxquaHkDoJ+Tt3KN/0G95TJIuAwSKoNEyiCBndck
Dk1Ki0EsMRy47JwQZNlvuM+1UcJGFZBQ4Zb8FMnJ0bmGvntMHfzlumeoMIy5nCpKBYCLJe/JR6oh
wxAoiPNR9mdxOqXkD1Nwxc2PCi+KB6sOSE+U3ClBr9PuqjFOEKcPRE/Th+stLZDXF1zcFVzeK7iC
Si3TE8xuaTQSgOoxwuwUnGK7RXVOnNdXF5d93kvIBVhk3pd4GcaEuXQVbgG3Sq6tvFdbMdVWKWTF
S8LVKsfLLVdW6XXd8pMmIGTkxMKEsSmlFdVErkW74y+mz1reP3EXWTFRsMDLzNVZ6K1voEGixWVv
T0UbihVqXrc1tPGUGNWfuKrKXVWV7GNK49KncaZ52tK4Z04KrlPbRyLObunDFZFontX7IqyGqpBL
Hq8NeDlYvAfvmBUvLOwWhWvGBogingiJtalZTU1/N79xGImcnjIkGlh9c9cTh7hAGoqFcHWBC2s5
r2IRXDwwb8XHWveP5eYeJ/D1anN0sNs3Zn/6LH92tpwdlm8KD8Hhd4dQh4t4SHynvHs4nKjjIfpw
HYMgDHYPi+7dGsm7dfI3quWM65b79UIK1OrJhfptguWZaP6lJC/0zxPFc5H6y7vJFXk5FgXQ3O6l
d7xL71g2XtNTkMOheQLB6IeCItP7w7fL8Gg3fC7fE6NB686eq6E/IlfEAEQxBCDyN6m1XTAK9kkn
8e5XvJIzwFmUHHvRw6vY7rxqWcMH8D+W3d1mS3FwAYLx/EPwTCd+s9GgYXtpQg7xvvhjDX52jj1P
mFPAhEVpsl4KHNXjl/RJAaITjfzS5ZfSFekkX2QfgOg4MrbbLe92kyK82rQOu6AC0bUd89OBih8g
G59cSyKp93AzQJ+aQWeDc6f6f9/E3ZdXl96ak21oYnu5AszV74TdKaRZAb+vvRR4wCD6iAeKzgP2
B04zGp1fX7++BHxN0yTWkkDRUUiP3kIs9rs08a/4JXNOb6LX6vDvG6HnubyI7gE3jfw+8tKaPyt6
ecywqfPr9MB598AZHPEpDwHvCB/+axO//+hp7BjAh6OKfe52U8dVPe8QIS3hvXbgUFt2+s0PVw+H
DruglsDK06yA3N5dHQbt73Jj+iqwBtLpHAWSPTDo184RGPAO/vFXapmqw78/JNcu8NUgFjXN6iOE
F6/Rk+j4Q8f1aDSVwGKHYIege6/4p7+8qwjhEn1x/VdsYHN91e8k/p+AHj3A58Gcg/Nc+TCjQ4w4
pAijpGBETJLvFmgaDF9RFLANRcISzmfyS2hvCNVLAvuMwZ4XfI8PXS52gRtmxm4GH4wEWL3jPnkB
/ADB+59cmUMXQNbFN3leg+hHdPOX5FQrv+Tn5GSjeAAfdO08vz38SJ8aCBjOu1NN4jfz8EGj6F8S
yUF7SBkX6zFmnDwuc6qvXOprUo0KOBKUURrHkHwKdBZqTL+NGy1GhQlt0VGTBNTZPj21kOVPiHvl
NkwzodqyRNYD8QGGs2pUhiXmRqRoUGRhkkDbZ0GyBJS75zzpWgYrLQMhpYZOEuFlyifnNXUxmZ6/
vXwTjEsOLHJcXl+9PPCIhSOldsgjQh32yJD4TnnnL4gOcB5Jn6IP+wOYdv7IukTQJgyqf45eVFWi
ACwXQM7TUmoNuQCXmF4w3TAGRcPNNtUCpFUDX3Dd58BGAGGq3agVN7SrFotNcWl0XW4N9Yg1qaX5
xYrE9xVA5UZYbpysfOIO3jkhuD1V84eN7NRSR+2RVfp+VQubOoOHBBgaBhCATCuq7PaWiI7qN6GS
TvUdb/vIJNkMbVWbBRYa7HHpz8asY172vqiXbOhD3fhj32M7ZkEbbtC6ZtvrWnqXWZSyVxs3c9Tf
pCSSgfl0yJSehbwPlD5pjYVli+djuDNsQirWp7IYnm6VTOqDatJdUBMyF5NVN/cY1ViDCTkow3C2
WDCFvqUFh+EcZ7R5CvtATBNYxphiNJFF3YDKDKz8HBi8HX2UWED2YdY5S694B15bshIRkl4BLaTe
By/NK08UW0Xlnl310ptLvKnfULUNqSs76yB9GzeGe9zuFKGGNrCwVN/ciXWint2A2fRMd4R7ndrR
DfcKo5fp+j+kVz1vFDEQ7e9XbBmQEvxtL+11SFSRaBBFRC7iIAcSRMrfZ753fFGOgupux2/Gz7Pv
2d4jyquT0IEU/8gRxu8AR79RmCXcSMKdJdxJwjjEus2o26NkXXOEpSR6aSzZE386HKgSaRWPzmUm
YzKMIkO1SpkO3DuJcXkuyYsHEY7QX9xv3GaV/nezMl2rrfbAaVDD4C19FW/8YF/5bWNcvX9DBvt0
R50c1MlqnUzcyWv+r3a8Ixuy8Tbv16vJpdBP7uS4EkM/CR9l8HNy7jPzIUlt9iYRbJKiOlKVAcv9
8UGoHn4fGPGkM8gAbdlDLq9NabKsrEvLr8f7RaY43JyfiileOhV59MKp+Er6VtxOvbZOY7GmCzeM
10aZloxepvViYh18pfY/ht/t/9Rlf0sndVhu97u4fADRfgcgWOB5iWH5uHz+Epb7XRydKpUOY205
7XKALalY4HF3S5hBoYL5JwiAzD3GEK3hTeBx9/AWCgE3aECpHWMuiwNYOYfIeTXjhcLNrhhDtMhT
QWXjnEFIPomeJ8Z5xbudm1sgG2Ara4RBtaX4JA5MhMPAbru5FWMIOH/SmAnnFTThkvjZE84rbOGe
sEIMAL/5jHDuY34vEvCEM7473yzDGGLQPVgIS6EKVzxKkpnoeapbpVlWVyAGaGD+ctaHEnmVGTeI
ZoGpEwU6MS1KMYbIHS01E044q2fMgYlyhHz/7gxjiAQqGdpkBqW1s0R1ERKYOIc4S90wikhrwVVN
3UitzOKXgK+c2jirrJgNEa2yLj6VlbthWRzw3UjQ56kbhjEEmNO6scLbReutCWV42sFtEt6/Bagy
YMgS8JtJ7mOwJRRjCBiowrnAW8EYfo5hkj6nHNhHuEdQUois5BJ5/5UATl1iZMeGyo4oAY7K4jCK
yGu3ncpAMMZZsCjeCaL6qGCbqFCX2ZWOYgwBx5v6SCvnWm98YX72dXONaJOtrkI2AH2ZSq8CNT3B
F1htrq4EfOEEtvZ8DWKANdy4unQW9sT+tCQO+Ban3tifukbDGAI0q/78K8AAXtjcuwplbmRzdHJl
YW0NZW5kb2JqDTc3IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA0NzEgMCBSIA0vUmVz
b3VyY2VzIDc4IDAgUiANL0NvbnRlbnRzIDc5IDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIg
XSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNNzggMCBv
YmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDQ4NiAwIFIgL1RU
NCA0OTEgMCBSIC9UVDggMzQ1IDAgUiAvVFQxMCAzNDYgMCBSIC9UVDEyIDM0NyAwIFIgPj4gDS9F
eHRHU3RhdGUgPDwgL0dTMSA0OTUgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDQ4NyAwIFIg
Pj4gDT4+IA1lbmRvYmoNNzkgMCBvYmoNPDwgL0xlbmd0aCAzMzU1IC9GaWx0ZXIgL0ZsYXRlRGVj
b2RlID4+IA1zdHJlYW0NCkiJ1FfbctvIEX3XV8zjILWEMYO73nRh7Sr2ShsTdlIV5wGiQAoJRapA
0F5/Uv4yfRsApAhZTuJdr1wmgOmenp7u07fz4uRVURirjCoWJ8b4QaQC+MdveQC/QaLSKPYzVTyc
vLrYxmq+JZZAbecnr36cGbXcnkyAMwhjVcxP8C0LVfHp5O/6YrNeeJPMD/Wm8SapH+kHfpRe7lu9
nleqqLYerrTMp2aPFdHm3iT0Y13L/npeCke9WSvPBH6unWhvYvxUN14IYtTsovglSJWwPHm6z8Pv
r3x+Jfv7Sq6vDF3OZ80D+vigkRbrs0e5go1/EGNY5giCD573j+LP5KuAfZX7eUJeoBfnqTDzYxsY
9BX6IUrRI+Qck4pLvFxvHj83HtnSi+HA5X1LTwWGtL7R//ZsDvqon7xI75b34CD2zGZBbMz8CeSU
LKVSs8/Mw6TqATbywg8eugbuEQTuAplgLfNNkqVwgeKSdA1NpyteAHVV/OcZqw/fji7+lm8mcheS
4JmY0E8Sm6oEHJ1H7lomc0EBUUa3uqwXi6qp1q0qvATMXS7V+3K1AzOTE+q1uus4Sl7kXwB6hJFR
ly0GwW1Vr5fAXrewUN2pRYORkIDVHzyb+olWm/a+alS1ZjTdPW7qdXvgBpCYJWmsJtYPw7TTOu58
IUoXIDoAV07BoZGeeSbvltS1F4H4d/T7s2fh5PPpWwAuYOYUFAcO43sm0rFv6fRpcWJUrU6ywM/A
1UmeEJb9KFMT+m2qk8WXqMa3WUeNIlDfDumxBW+Mb/8CeXA2LDEVdkBKfLL7GP28OAjPDPgwPJMk
hM8+Pm3iwAFbyc5vARK5rjw07AKzRygfTQXmRtuvIbASPa9O1YzzxgVtQW+EgKZfeJFweteUIqOd
8LOuKIuibEqasrwFERayAZGWdEDblOuOOoH8r+ftoywEqd/+ylzKJQ3WYgUZLNTljgWy5gpw4Rvn
eWfaFLL7uFuZ+oxbR7b3woPn/DZCH/dbBLwReq3LT/MuabnwQBtdeRh47usN5cCpOlXqzAPnWb3d
Qoxi0HMQA1+GdfDQOHFAhXjEOEx9xjgj20V4lPemO2acEfq4cSDn5LYrOX3qMDEbZwZgiCA/hGCS
84JgbMFSABur3ecb/MwhvWC9xKwBWfaSdtT0sWB2eVSUZTAksFCtEZUxFR/Y5SSWxLNkmnpPsnht
RYw7pogMLFcGki+RRCDkYXRW9hWHl1sWRD1JDF6m5ZKp/CEkd4aEzyePEMMsLR97LywssuTzHhhI
rITaVwIz/PACfKx/iC6bQJMwii6mPoOuke298A57x9A1Qh9FV5xDT9Tly6jLlwlji9JdCuDCbIbJ
M3VLN7PpqSo26iNYL6JUFOumXnz2LBmV8mAONkZq2Q78EMLme+w+E12tiaxKwlSi3SdkxASTJjoT
+aQkM7VmyUiGu1HKNHI+rrUepunydtXxgSxWA4p4u1GleqygbLey5s7EroBlLYYipS443Vi6+kBd
xpf5hKVBTOYETazXD4SYQMGiiZOk69CivkOTctVC0TegfY6aqsem+kivNS1voAykZK1U438Qb8lY
RC15r7DCyRGcvKbt0Nq06MQc3YHLVSUEWXYH7nNtlLBRHKBY/hQuVAH66Al15FfrgaLCMMHQMpSS
LFaxJZ/JVyo9jNoVc+7kfN5OtxT8MAVXqrsngReEo1EHpGdC7thGJ9P20RhGmLkPth6nj8dbnCGv
C7iwC7h0EHAZhVqip4huaT0iSN4AmBDSfSSJnaaZC+K8ub68GvJeARZgkXlPsTxiHG25OGK7m3Ns
pYPYCim2ciErXhKuVlW83HJk5U7WPY8oEAOACwYWAsbGBCuKiVSL9Iqf1CjLPBN2nhUVJRe4PXfq
3HfaN9Ay0eJycKaiA0ULdVe2JbTsBIziTxxVeR9VOduYYJw7GCeaP1t6H6hDFWe7I+L8nh4cEZHm
r3J/C4uhKOSQt1RPrIXblCtmxQKG/aNwzVkBEcQfQmJpal7SGNB931boiZSqD231rL5dDbZvcYqJ
RUMoY2DCUu6reAsuHqhX87XWw2tVdy5P4DQKE0/IDh0os//5Int2upwfhm8Mg934JCLU8SAe294L
70aJI3E8Rh+PY9gIL/2oEXeRLG3Z9G8UywnHLXfwmQSo1dNL9fMUwzPS/Esgz/SPU8Xfsusv76bX
ZOVQBEC7uwfvsId3KAevaThkd2j+AGcMXUGeGfzhNDP+1r++lO+Zt1Htzl8qYfhGpgghEYXggMBV
Ums7Z2Rsk27HuzdYkhPIs7hz4rYelmLbW9WyhA9gfwy71WZLfqg8TMZ3H7wXGvGbvY0q5roMiJjA
2M42aWcbwYu6usbaAZgrBlsMIku25N0WmceuN22FNR4brLqdsEm5sOMUYChFQ4J4D3lvgv3Qjr6r
Iea+jUXkLr02ohyB3uqL18PgCbqLWboYVNObm9dXU6/45xHDPbHC7+35Z974Hgd3x8qQ6ddPu8/v
+yqAbst9iIF6lcOF+He3rueudwGsvXvkkA7Ya4cRTc4b+u2/zmC//duxBDxYoxxo/Cw3ySAHPo3z
Fx43oz4t1XeSIqExz2EgOTDoHyocLiUEXFI4G2QBg/p32JidedZAwrrADVEfLAe5IOsuL+WBT3DT
Ta7lUx3+/S5Yu8S2WDRqmvojuBfrxNEp9A/lVzXrchsmidfH69de8M9+eoc+isG5lzd/xQ4t1dcv
9fL3bAolN0P0wc2uncPRNEZMk/lBlD3Jjd/a5fQyytHldxoQ9hI853xpMzycAYcJX9pZaOiMG1Rx
tk1oNqLU5a67D4cw6uCgoV0opNofqRffucOl10kl6aTc66Sce0JyfLhX7qOou99h64M9nTeJwYLc
2SXS2WXSSkXU2E2ws0OS+kiPkqYZo1c7+qwOR7owBA+MjnRMfWakG9nuhFsc02Rkg6SdH850Ywyj
Q53t57mgK59WyidlDRzLMMBmaOJU1tTldHbx9grGvZyaaOK4urk+PTCHxW5szBpMHDfGyOZeMuQt
pkI4xPbp5mP0UUuYLHeWSPpoMT7GyquiiBQYagHkNM6l5UAuiEmmZ0w3HH99TxJ1iSbpjRoCShuc
dnP92bMBhK9qN6rGKI8Ag3UJiESgGYAiL6oSwhxDnaMe0gIw4aABmN0Iy20lK588OCHVVSWEak8U
zqH81nqIZJdVzniXKoVNnWN0hNr3JthSK5qA2nsiVuojPUsPlV/xsTsmyWGoq9osMD7hjCt3N2ad
8LKzRblkRR/Lxl37AZsSC9LwgLZqtsdrdxCzVZtqXlGVj2lLAurTJWOaj/gcy8davCnE9gXNjq/p
3dkAs7AVCVu8fk7p1bCGsVwulkV/OFmZ2HnaxL2nIxKH8NXNA7o61KAXDq/o4xbjJ9P3tFChjycJ
HYlZaYPDS0yORhcji7oFkQno9tkzWC6c2rxBzmHWO95d8wm8tmQhskmKJ2pIbQFWkeveEKSriNzT
q1w6dYk3dgeqtiFxeacdYLqpJmJSEUT51rOwVN6uRDsRz2ZAiL3QHHv2t539HSbO2GdljZjLtMCB
HxRFCCzVMvWe/asYQyUhYMWknZAYzBbBXMsuAZTDl6CEcEwADgVLBGCEjNpX5v+KTTYHBEgWpE86
nkFOs/9rTntiaVZXTDiXGPkXX3GYXTJ96uFd1fvyOdseWpWuPDCtHHBo4QPbts6losF6L4I/sT4E
st6UAov/FF72vG3EMBje/Ss0d7hKFPVxs7cCnTwG2ZwALVIUaAPk74ciRZ4Yx+1kmHru1XsUKem0
yFhnqs71u/54nlaf/jwJ8aozzAHe2fu831W1+bHQfr9cw5xirtxxbKa93z82ZfD+sXnn4UPZjsW6
+zHYj7HbJ++MTlMy+m9XNxPb4Ofa/xn+ev5bwvnCR3kMl/MphW9UsT8JpPp/CymG7+HhMYbrKUfa
kDAFLG3bIfw6pd5YegZeThcO9cFUWr3ODNU4LowRBbfYKfD85YAyrTU9lCPQmP4fuvR9JU9lOteQ
kWlmIgdAlykUWWOosBBXwxJwhulIwNWvIgbEzhOx3bwhyeTWR5KGGfouRAuIbua5c4etciJaYR1j
jGg4UjUdy4vnSrHFjfxfE5ErVdSaCEUOoI9MufxmpLvImuAZcMKYNqeryAHQFqq6ks88rsyciNHC
1QJrgnOuo+iWd1LGCOgjVd4xZT05xxJwjiMdv6tjRQxI4AsC6L5a6lIQM7D6hT3KO6kVY4ygpW3g
/UIBV8Hyf3UL2H0FK2JAqTcVDJS85AxLwBlGvqwvhpUxIvPGwsqYGiuPr53xkP6HOBcBixZwl27H
JHvYDIypMSVZpR2k2zHSWYMLY0Qv1u0KUQttbbwUfV9Ku0uAlXF2y964EdSNIQpgLNqWNjmiJEt1
Z8DpUrJg0TXkANQtHXGjt6GBqu6ytBIQ1S4Jpp4T1SrJVMSAVn29IP3ubsuTgNvzWls3PAVsuEvj
k+o71lRZDwplbmRzdHJlYW0NZW5kb2JqDTgwIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVu
dCA0NzEgMCBSIA0vUmVzb3VyY2VzIDgxIDAgUiANL0NvbnRlbnRzIDgyIDAgUiANL01lZGlhQm94
IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+
IA1lbmRvYmoNODEgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAv
VFQyIDQ4NiAwIFIgL1RUNCA0OTEgMCBSIC9UVDggMzQ1IDAgUiAvVFQxMCAzNDYgMCBSIC9UVDEy
IDM0NyAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA0OTUgMCBSID4+IA0vQ29sb3JTcGFjZSA8
PCAvQ3M1IDQ4NyAwIFIgPj4gDT4+IA1lbmRvYmoNODIgMCBvYmoNPDwgL0xlbmd0aCAyODEwIC9G
aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ1BfZctvI8Z1f0Y/AlgljBoNLb5bE2mi9
lhyTSqVqtZWCQYjimiIYErLjT8pfpo8ZADxA72YryUYugzPTx/T03Zez0evZTGlQMHscKRWEBkL8
J6s8xG+YQGriIIPZ8+j11S6GcscoIezK0evvpwoWu9EYMcMohlk5olUWwezL6Cfvql4/+uMsiLx6
64/TwHjP8lP4eaC9dVnBrNr5dNIIHkw3FcNKfxwFsbe09MuysBjLeg2+CoPcc6z9sQpSb+tHyAam
V7P3YQoW5ejXbQ/3v/H3N6L/pbLPB8WPC0TykDcPHsFi783GPkHHr6wytGCE4YPv/zz7gW0Viq3y
IE/YCrxwloqyINahIluRHUxKFmHjqNSaxM+9evN167Mu/RgvXDw1/AuoSB0o75++zlEe+JNvvJfF
ExpILFM/Mpogf0E+hXCpYPpVcARUPSOhHLzyyTT4jjB0D8isr2WBSrIUHzC7Zlkj1cpKDyBZQf58
pb3D1cnD/+ZKxe5BNnjGcRDlaQIJ2jk37lU6cjERWgPcbRp04WIFm2JboMYxtDAqNKrDq/yQ9Ftt
d6hHdJvlGpqnypnlhg9vUaMJrscJHs38BDcO4dlXieWxE7jwKRbVgfIJP02VgrEOoihtpY1bE2gR
doasQ7TgBG813tRXeXsEt75BC9/z952vUZDLyQf0V3SVC7wXMVTgK+OhIHz9ZDZSsIRRZgKDFk7y
hF04MBmM+butRo/fhmZZCzUGxdd9eKzTQA+TfwPcuxuPBKojyoRH1Kfgl7OBqEySCLddWOqkdQoj
ev6AhszZdimmNdRvZDfbCtVNul9jPCVeWV3AVNLFFZOQNSK09Hs5ZPecbwvLoxnL77Li5Em8OVfa
4x2y0JgEGLTgC5ptsW6hY/LNstnYgzANmn8IFjifEylWmLgir3gRhiI5oG06yzvVppjUh80q0DNm
HSR3zMNzdhuAD9vNIK5xVguVs5rOu+iIORpTVJTb/Ygqir0JXAC88dl2u11Nusy9cllg8CNehvak
AIVpU2ybF15vDnUVh1yOB3Ql0DO6GiRn5ibvNHlKVwPwYV0pdATtdKVaXSmrq+n9JeWkhNVkWGmZ
VZphpVHJmfiYkGLvAu42/tigwlhbtFijihW2DfiSzMPcKad2vy0w9eUcQLxvqNyiLciHDbniUsih
4dylvSfeVnBze+MEgH0WO4onR18sBP/QQDrBajtoIIGeMdAguWPemu+UgQbggwaKc2wuhjOQTSD3
mOhzm47s0d10cgGzGj5z6Nu0tHz86msOc5tZnhhaNLB0mYZzBhWwbQUF/q8lheFii8rWFBg1NXnG
IyBXReHBN0h9tHhyqZg1YutQniGzEsG+CBXqoayWfWnnztCUKaHlKYlVeMm3sGeLHjG+wO5cIiYv
CAETqYqTpG1fkq59SUSlzy6RU8rdkceS5Cnds0B3J1GXpOLUnkJRltWmqeZQrBk+x6cIaFPbk2oe
HHphGA26IILO+N9pQuGpO9eMDGWCA9LT8GHnizPCdd531BSxq2Xsd4k3oXpjK5uhnKBQi1OMRN0e
whVj3t1e3/RxsS3SeCi4F5R+I8Taa4bY5VKbidfS2aIVcgsGObJYDVRy3BQfVxaLeT1J48u91hw+
UnnNsSXW1PZU4impZ7lX8jvf1Mu17ZKjtmezIkKxRzOHy8BJv8WKzIeL3p3AF1opYF40BQUDOcbs
O+n8Tdf52whHORTLi4Lgo5Rn9w1vegJx77Z7EWj5JL90IyUFuy0sVbHiX/lSFPNC+PNglrhrCp9S
u0WU3pc8GqMx4p6BoEIta4p1isvM4+xBCwHsi70UsewhBrpPhuNoJ7eBPf474oLBx7hVcPDmlbAi
HCs6fENnlyyWVUn9Io8jf4Cb95/lNOlbRWacsLVHTjXt4+o4qGOcIobbXwsdDu1hcse87V9NTJhH
1Kfgw9GNqu5qv47b6I7lpZO/cnwnEsvSNGY2aLU3uYZ3EwpZ48mXHT/zvp+A7C3Vn+8nt1y/I8sA
W6w95UZdBo7sxWueR9h6lLlzjj7Td3au/b2/89Nft/y1eOdWg+Jd/hsDKasiwuQUoQHCdv48KvQn
aO9/xD4VczBxGDsWh/VNd9q1w+ED2oEahFW9Y3tQocPXPPi/Upn/2dWgdK5+Y/CESreKylpFaaco
oL6BwjhGZz1Z9cOWSrdKQaci31qtgLt+LN7yw70sLdYsTyFevYL3lAgjt6e8yGHB/ai0HXiMvc9u
T3RF7n7dyypjN6M42f/nFji1sgqV6Nf4vr9xDBo2lvHe9tRsTKdm0+ZN7+ru7u3NxJ/9cqwImsvK
0R9dD/IA6nHw+fx6ja/n7vDtaS877Zt/jNccrq54VKrt/PXMY90z964va574lmXBkcBwOYL7TT+R
U1PYVslrCif2lhiV1cP6/zD2tDUwtfFvD8s8TiLDE6SFninzg+SOeTshqjw+SX4SYbDQR4q7AVvo
rZ1sQ08WEDNhvdbYR03p5ak9g+vJ9OrDDec6Q2eEcXN3e3GgEaw8NE0MaMRChzUyTO6Yh66xUay7
I+pT8GF9hFFPH0mXpFRACer1bGYAnfMRwWmc26pMWNiBCDwTOBki013ZjvIupeeiW25SNfUHGEvy
rbgdUjJoJlRnqPAIDOSnljPX8GA3rNEmhSX8hIGZU28sA0jIDS4dQbHj4ilfy6RcMstCOMumXsMj
Ng80p/hj7oKRj+HyxTdBtcdXWh0eCmhrRe234fpQ8uocJY5JU2y6eTRwV1g6ngS0mwQyngRIIidQ
/4Hu8YtOH2Xdv6hYUgNr7BV7m4VV2IoRV6czuOm6J2VTOM1KhpkZGUtJSB4vNM9KkbdiCM9KNMXw
DMMNosiIa56RAs2vwBc+eHbs0J4RflDM51uyD1IIknxfYTOEj2zRkw5dDtia6iRRWdefBGnZEwU2
W4tcbT/3X9F/pQVUD35wPpV/4HRZlfV2Dg2NuXhNz4cV25FsiA0VGTEhIy728eSU0P7+IhD2BMVF
J/fKCl4EZbkWSijAHvjjDO27EMRiBY7SFjI+XqF7UTDUW3kLKTBM9aHle0lB/86koNt86+YbrCoe
aQe1UdqB9xNv+wOOd4GSGgoIjoWII0GxaoSEHu2+hT1bCFefWjVYCgyKsqw2TTWHYs3gecdzLNPu
G59LHRY63ZHJj7tNSBuW6Vhzvaavp7nod2rOxF34xU511Hk8SXdP2qNG5ZNs4fLC50zUT0wUBRm7
VWYbHMTElEiImBJjjgf61tzAJxLLyExOhYw8KWePzThTxzZMEu/jqscC/RoLSysdI8zhY9X4Yxod
vvhYsNCfLTN3UWUXnCpl0OB9c+oxlPB7xHNMpYelGF9xphQL9EwpHiR3zNtSm+R7MG1MBzuiHIaS
WBZ6Xqyjix1wgPc3wK+vdjFcTbk9CGF6NVLwA/rhL4iIXv0FVAjv4KefQ5iPVEadgwKToPcZeB5F
oUaW7cFqNMUjjAfGoScxDmYd08NpMVJ0jAwPHr/rkKI0SBOkUlkaJGF7QJzpiOmMIsmeO3EcTosR
of9p4dwiaZSnLzLv9yTWoXuVFcaidAgZnh8IjD2U7svL+z1xQxwpkr64FsUhRHkeRMm+tFGGTUlP
Wtn3pY3SlITppHUoLUKGLfGBtFGS7kkr+760Uar2pXUoLULyrx7K7QQAGISBGwnWlOr+i9X3bwh4
nBBZWsRq5ilNt75aTavtFjowKLfQoa3KFuysW4jR8eyyEQfuBOIPecX7ARBmaHQKZW5kc3RyZWFt
DWVuZG9iag04MyAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgNDcxIDAgUiANL1Jlc291
cmNlcyA4NCAwIFIgDS9Db250ZW50cyA4NSAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0g
DS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTg0IDAgb2Jq
DTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiA0ODYgMCBSIC9UVDQg
NDkxIDAgUiAvVFQ4IDM0NSAwIFIgL1RUMTAgMzQ2IDAgUiAvVFQxMiAzNDcgMCBSID4+IA0vRXh0
R1N0YXRlIDw8IC9HUzEgNDk1IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSA0ODcgMCBSID4+
IA0+PiANZW5kb2JqDTg1IDAgb2JqDTw8IC9MZW5ndGggMjk2MyAvRmlsdGVyIC9GbGF0ZURlY29k
ZSA+PiANc3RyZWFtDQpIidRXbXPbxhH+zl+xH3EdE8Yd3vXNojkpo1hSTartTJTpQCREMZFJloDi
uv+o/7L7BhCiCFqZTDuxPCbubm/37vbl2d3z2eDtbGYdWJjdD6z1gwgC/CejPMDfIIE0iv0MZp8G
b0dVDPOKtwRQzQdvv5taWFaDIe4Mwhhm8wGNshBmnwc/eqPN+t4MMz/0NjszTP3I+ySfwuS+89bz
EmZlZWilln0w3ZZMm5th6MfeSvlX80J3rDZrMDbwc68RbYbWT72dCVEMTEez6yAF3fLi20wP57/x
+xu3/7XU54Plx/ly84Antx7RYu/dVp/g4jeqDCc7guDWmJ9m37OtArFV7ucJW4EHjaXCzI9dYMlW
ZIcoJYuwcWyqJjG5t9l+2RnWpYnxwOVDzV9ARTrfev8xLsf7wJ9N5D0tH9BAYpnNPW+TzZ9RTiFS
Sph+kT1CKj8hoyy8MWQafEcQNA/I1Ncy3yZZig+Yvee7hra9Kz2A7gryZ6zzDkdHF/+fI5s0D9Lg
GSZ+kqLCE7RzHjWvclETE2gdftTVtkYXLh5hW+wK1HiMCvpkXIZ2Lk2Aeq/LXWUSD1ZrqB/KxigT
XLpkbU7MMPFmJsHh8N3ootnwydgEPyKjoj0kpViWB4ofYmzTBYfOj1MKVLlo3GrfyT1nKDfAM8Z4
aORNjc3bJbg0ERr3hn8/GOcn3vn4I7oqesmZoQeB9Y2NvMR3fPp4NrCwgkEW+REaN8kjP8kg8KMM
hvy7Kwf3X6dmWUuNIueHrkuPXeq7fvavkDtnOyW6kDDwBfMR8vmsJxyTxOJhnXgM9/GoEPkR4yRB
qzlU8j05lwx3pRnmqMg1IUjozUvUK4Eb7yY7kFGuzRCB2WOfXOwKZscQ9IY0wNhWWQicKcoOZJ3g
Nkcqri1FOLHskFzoYbptGKE7zeUatGXL60Hq0+Rfe1ZoPFAu94hLxZOcIucDmsq3jSM0mk4tAkCv
lYV6wsq97CI82Bv5mB176P2GDAmuGjMGtglql++DJcbHT/DZWTv7ARUSe2M4A3hn2GJVtSGb5d58
VSAM4L4MTUxxC9O62NVPPN4e6ipK/bRfV0I9oate9ka4O6WrHnq/rixGWNTqKmx1pRloenMuyVDU
FKHSsnZMKiPMweQfemdwtSV1of+tNjIgZYUe4Sa5GihZ57sCQTBnEOR5TWmXUbHCzJoTpDI71BRA
3gNPSphcTprjh3iVd4aU5HWRNW0kVhUdFfoUO8x8aCmHABH1WkqoJyzVyy7Cw70dj1mqh95rqTjH
IHKNpVzSpqpILHUthckNZoAcgSrBX126mo7PYLaBXxW9KCvsVvdfjOP8wKVaigomalHDSub3AhqU
1nYlFPh/sxYBsNkBJkEKkQ3ZngAQNpwpRQafIDlT98mhYuIQgw6zHaZQMjExPL9CiYqYl6vubReN
2RGaCPHoYhik5CYjfukFJzvn7b0gZ4MTcyXAK0cWSxVLrhAA+omNk+REWVM/GHbSNX+68jP2MyoZ
K87v8lvo2lLY0Br0TqFBMZ+X27pcQCHiFvhUIW03ulIu/EM3DfAVrtdNhXrCTXvZG+GtE4eRHycv
uY/R+900Tvwga920BZQg7bhpxg6aeGOypSeGjQhILFptipWKaxdhxDuvLt9PunuxrnK4KHvPgJ0h
4UqKAYRQm30zVfBeS1mMvp0rGWRJd9VQynJd3D3qLpb1IFWzIZRZwF1ZE+2zcYRkZcm5nYCOpZfy
XWw3q7WW2GHrMnpFKJ7xLODcb26/2xWyuOycCXyg3gIWRV1Q1Oy9N4pa742SfcGi9WvJVULCV8Ln
hZ7Oa550rsYaqZ6EOn+QL52dcFzytFCu4pG/8kuBzwORz/1d1BxTYEmRNhulhM65r3Qhg4KTaoUf
67gtJN1k3I9g2BDoyFDIzy+/ksvpIiIEp42J1FsME05ggt42upCksq+/bXtqJWcUS5FUyiVlkYxD
jPIGWdM3wleUew6VKm6jehUhC2W/6wOhfd0ZaN05uaa3Zt6vDGsJ+j6hCWMS5te7x5egESfxibpc
qf2g0c/eCG8QJYop+l8wHyH3Q0aQd2oQF7eQEcvrx39n0EgEICxDfqZI4Lzxe/gwJhyIPPnlaMq8
78Ygc+X6y834krE5VAFY6rHSZn/qU/tYFMz2JZ/OOaSjbtxE5Hqdv9P96H742n2nRr3XO3+thM6I
VREi4oVogKDxxZfG6PLe/GA4110z87DhPvRnt1estqu3aAKqTB43FZuC0iQ+5Na8Uo//21Hv7Y7D
rqS4Rjt/gPu/ZvS6jeIUiMg5tW+nnOK0PA3Jykh2pl/OuzFn51LdR885dJ9vRL1YoVI0pAhM6iaY
45I8b7PzPjnrY5jDMoeUBP/gZEX4RNn+4nh6oEJq3hZXEk1/I3zEFFw/aJ35+Ajcg4XeVj7ak4Xc
k2kP5rBGv5Zkp3PtyWLpoJwW7DEXtxEy70MAE0dA3Yh6RN56hP3jW2p0dXUxGfdoN+q4m24cslGG
5LA5YT6ZaiQav+hmkG9LC0Ag5yQOpaFJ9PdJlqgWzbGso9J0XmhVpaU0VlI32+7b1Svl2e/f0Rnk
1THq69vV0JQTvPNEUxeHJRZGStsavSyxhHqixOplF+GZnyZKtXl8hL1nQ2+ZFVKT0XZmL2FE7DWm
4jLHUgpfnuoavB9PRx8nihUz2TG5ujw70EiIZb3rLTqV2q+RfnYR7vyGiK4Yu0Pmo+R+bQS2o42k
9V7P+mb28+DtbBYB+ug9ktM41+RHu7D6E3omdIvyMrfPjlEH6CPRLMO6dDpWf7nJSKQPsQTSVhsH
S11XLAmS1vYdC2nHK4TvF0o10kHF3FLS4loWocA2hVqVRsR8xQILkSuTzRruDQveYZspp4V4R72Q
9jZR09vYRrhe8fzgkl/ZrgrwDTc++qIpZqJQn9Cwqzju5dKmlwull7ONHrmXS5/3clYFUS+nnRyq
B+abtVyh0GvpZ3kc/W3YBIVNxXSaSSkWtvLhTBpx40kZAHXPrR0oWeeUSV0ghuaeUDOp5UyK8HnL
TV3GTR3JiYQdioUM9INcqKOqegMTQ4V2hyN5wUGre4YbueCunOuFlzxfy2T171L5QKX237y6Nf5p
GP/ICIkn7RaARQgliLLjuZQxsYrGt2MNEnMFGJOVnu2TVdr2zyehaM6RhDMv4Um2rNbCCQXoAj0g
8paysXiEhrPJZ7T8yImsqDc7eQuaPgtSd+gCHSRwvxMJbKsmq2qixtN5D6gsfN1c3/0LTzs9JcX5
GXozB8JE+twMY4DegmROSAknJBrv1ZwhvTQBaTlhLceiZT4NVoLesgrFfF5u63IBxZrpCxCZXPEc
EVkVuqbicA1WVWu6cl2/Vqvh78XXeI+vcaNW8t8HCvqY9Uol7C8yhfMzfLHr6jfmViRjl8saEIsF
Jp3ApPNkIrCo0IrCZFXYoJSDZCZcBZvt7rEjopK6sbkdb1jAXVmTlTLvs3GsUBXWHFTqQAHVNYT6
2GMkAbTMCzj3DzMzhsOJzCzUE5m5l12EB23qTfJnJBdZv5evl0h3EuKpK708tKEdF3ya+nZUxTCa
cqEQwHQ0sPA9OuDPuBHd+TPYAD7Ajz8FsBjYLPUTFBQlGGYJfBqEAYbmf6sslySIQRCI7nOUWViK
+Mk55g6zSu6/HRqQmCXUA9uWpOBIXMdXmYnUyNhFbklg8diYIDrhhOv4faQRpSyX56r73FZlCXTG
4qJ1tVjnOH0xD3HCPO3MsAuax8Tacx/cqlVZAp25FDtsyowymCy/op0JYsgjsXUON3JOLzkav7zI
nErfb+XIAuopG0F3wcSaw5qMmhVXYq2wDnXKl++H0lyx2XQ6oVIFKd0aOBLAqbd1l4Zqr3I/NaBL
PFesHkmGlZDRUWQ09WghDzAThUWuVt5+0C7XEi+9GIe+611MEBgpdymgRsnmxR7D4t382rr1DTGO
BMAT+7G2/QNi4tmuCmVuZHN0cmVhbQ1lbmRvYmoNODYgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0v
UGFyZW50IDQ3MiAwIFIgDS9SZXNvdXJjZXMgODcgMCBSIA0vQ29udGVudHMgODggMCBSIA0vTWVk
aWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUg
MCANPj4gDWVuZG9iag04NyAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250
IDw8IC9UVDIgNDg2IDAgUiAvVFQ0IDQ5MSAwIFIgL1RUOCAzNDUgMCBSIC9UVDEwIDM0NiAwIFIg
L1RUMTIgMzQ3IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDQ5NSAwIFIgPj4gDS9Db2xvclNw
YWNlIDw8IC9DczUgNDg3IDAgUiA+PiANPj4gDWVuZG9iag04OCAwIG9iag08PCAvTGVuZ3RoIDM2
MjQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSInUF9tu28j1XV8xj8MiYjjDu9Et
EDvqVs3azkZMsdu6KGiJtlg4kkvRTfJJ/cs9tyEpWfQ6aLZIbYCamTPnzLlfTovJy6IwVhlV3EyM
8YNIBfDPqzyAb5CoNIr9TBUfJi/PdrFa7uhKoHbLycvvF0bd7iZTuBmEsSqWE1xloSo+Tv6mz7ab
G2+a+aHeNt409SP9gX9KL/et3iwrVVQ7D09avqcW9xXBlt409GNdC369LOVGvd0ozwR+rh1pb2r8
VDdeCGTU4qx4G6RKrjz6ddvD/Rf+fuH1v1QivjIknM+cB7S50giL9at7EcHGL0QZlm8EwZXn/b34
M9kqYFvlfp6QFWjhLBVmfmwDg7ZCO0QpWoSMY1IxiZfr7f3nxiNdejE8eLtu6VeBIq1v9H88mwM/
6k9epB9u12Agtsz2hq7x5Y9Ap2QqlVp85jsMqj4AIh+88NA0IEcQOAEy8bXMN0mWggDFa+I1NB2v
KADyqvjPM1Yfro4e/i9XJnUCSfBMTeKHYRqqBAydRygWC5O4qAgTFuvcm9rAT0D7AWh7501zCAsb
g6FLb5oAADw9ArdZrlW9UbJZgyZR1ZfeNIbtA20Fdk2bLSMzZAO2DED1K9qphdxsKngCVJ+6F5U8
2d1Xc7e8dgQ3K+cZ42TuhU7TA0wIGBXICr4keLKDYDARXN55wBqIOL+AA3T9eXGEn4t5weEwZSKv
zt4c+BLEfxaaUCHxFHMPe1TcOZRlxRdCdAZKifTCM3l3pC68CJ54T99zzwILp7N3EH3A4Ql4Ndww
vmcinfqGXp8VE6NqNckiPwJ/TXIQKFOBH2VqSt+mmtz8OjTLOmgUWT+0Q3hsU9+Oo/8KePC2FaAN
Ma0/Qj4CPi1GMkySGHisTzG2c29AJS2/8xIyNar1BhNgKJsGzG9Q8xvIDYleVidqwanvjFAK8gKj
3/IhhdqqKYVGO+XfuqJCgLQp78vxDkhYCCkC3dIDbVNuOihETaaX7b0cBKnffuJbEMxnCDb6DvJv
qMsHpsVMq8g3vcmdTlM4S0btydAn7DmKzsSD3pzHLDYCHzdZiLnWGSwke/UBYUHIuUdB4LY/eGSm
mTpRYCGMuRY0gwYsId4h2DDeKdKNloMKQsrotmpcqvgAsZOBPRBvh5tUl+2SUNaH2oxSPx3XJkOf
0OYouiNun9LmCHxcm5i6oq7Chn2FlaZnQd7zHiSHHFKIy8/Rmd0G9GspDaHSIbtodQ6VGNVk0f+h
04mx/0GdrdldFcI3sgb/7wBUEKDoY9oPuAJD4n6QqyvFzOAp5eycUza+omTbXZ3LCtB54SAcZ8dJ
gTnFFwakK8if1CfIqsEWL0chpt17mPRRQ3OnFFX2nAhoqLMpbl55JgbAGQXuGxbcP/QmCwktGvUm
hj7hTaPoTDzsfe2YN43AR70pziFubBebed8D5exNb9GRLCTVDL5vsThafUlHCw9T2uzEw1Kqiq36
N0QZJl6rm5oObz571rK/gAbXBAbnovs1H95gqCd4B0/XWJ/Bfk2lmAIaDtyz7KPaoucKMjiswUZG
aC75BUd6w7u919FdkfcHfojx0OEQyAgrBikWj29wvxEQA/QiOgtdRq/FBfk8nxwgOgzJWEEvRSVb
vkp6E3lZ+A15VqDA/U2cJK6teFzxsEVBjtArqWFhR3b1TEoOOC/wx6XuDa2HudIVSa49/C3F97mc
ST1q1xW/pCqpdu2a4Y0qpc4x+hZHqEgv67KFoYlxBIUvqPJ627TVSm0J2EigC/3V/bbmVUt1UQ3L
YtveVY79j9jq5ZTrQy3FmVnaF5AvMElefwA/gIiOuYpADtjK/qZPdT21ym0/ejYB6dA6xe8mg9GT
zYGWJhOHVJYSMrCVdUMs5eTZ5nHyCEA4O5o8GPpE8hhFd8S71BLFmAYeYR+DjyePKNrvxcLOM2Xa
o1Yqo5Ys0TN0RPFKqO5o7VAvSDfuUJ3RzcuL1/Ph3TnEJBzy3RP1Cg2OyQGyEQ4wOJCQs6UDZ6Oi
Nc0FrPhIbrWq4uO2vL6TW0RrzQMluFgEkXSNrV6O5sYGvOL2MdVCveJf56boemHnccKiKvdwVurU
d9xDs7fPurqrWkUPChfqkgVWW3RHrU6HHhfZvvDLeFFTq4SOBQ3SX7HGJ+BgBin0XKF3N9CY3qKH
g1OqFWVPSMyeZZ1FlAoJqiqsq5nboqhDMCOCQCEmrd0Dny7XgkyZ12jZyjNcXGNXdwEPi7aWh5h5
/pZ85BgdsicyilS84wv7nMkFKjI5hh6m2y13Dc8SbV9vg4SD21pa06GU6nyOfQrQ/5nE/L3k+M4c
+/Eex9ETjbxAx+N9HJ2Jh32jHkZ+nBxiH4ePx3uQD1pPG3fRHrMDzn6ieE84tg3VmkyC2OrZa3U+
Q4+ONH8pEDL9/UzxXrB+fD+7IK2FQgDmgL1c27e8gbS8sw0leDai5g1YcGg/ajoGf9jOja/65XPv
PbUaZe/0uRQGK1JFCC4WggGCrimIOmMkrJMB7vsf0DkzyMaIO3XIB31F2GeUQDLKFVgAG5K77Y4s
gSUM5LjynqnG33Y1yp3rmyBsKDm+fjR4Ignpk/qx87/j6GuKeLngnI9Mnap6R0URUzo1KX+A3HK0
MzTOBzrzYWUJoV/HYFqo79RPLyBB8SFuf97TlcHIEnfKO3cyorGLbVtBi59RqTD67oGWlTAK7F1i
Qs0ptrO9UPutVCgGTNCAqKp/UJhb8goLLa7FfKyuNHLeC3rQTKedoGHvGl/bnl9ldaUvyWZoQrLl
nkxR1MkURJ2n67PLyzfzmVf884joj238rYquWIwpm7sz8xQ97Y2rDd8y/4p9kjo9HkcS+T5s6qVr
WaHheH+/V+oOUtY3IMixFbH8siisAke6mVio6tCZcHFixp8b445SxpRSPwgTM6hyR6L1eZV6Qd16
qldSAqEc5tA5HZbA/w99f4lG3YrbBsNiP9k2PMa90ou2qXCmpWGiXg1Kx9TRPMwuWUfZfvMKZe/I
wDum2KmqP5Y11bdMN9XxHBtF/fgViXyXHo5x2P7DoPKdbGkoiqDdiyHwr7cPG96vFN/jc1AuFk/M
CUerVGT611yupkED3zkvP3k0Y9TYfFugYS0VaSrHd1yO5xu+4zgwzAHNOZl7P5f3B/OJyX3wkbH5
hKFPzCej6EwcItJNLzZID3GPQUdnkzCwOArJbBJ0icJKosAmL8YRw1KPAhUklTP1erY4ezd/ixqI
8AxvzC8vTg50EUL3lY7OagId18U4uiNu3SwG69g+xj4GH9WHhUWvj6TvCIyP3QDk2IhzLHROcS4Z
AW/B0MRwycEG6GV2kDK6LjPIWbU0x4GLt5WHrKEXYejcYzDlulXtVtWbuq1LaCBLuYLxZrQqd+D/
qebvlhGWNdZDuJe4WzdQKcFJ0TJUQw0Gig2wXlZ79HDC4lUL3V82nP+QQ+Tk1JvGEGg+toyAz5Fv
OPJhDz0lz6sQWvJGBd2z1UNGnRC3hMpw99RHfqqm91v0KavXLMa5w/tE+5qBrKySiNxhnGYuTJmv
owkhDPtZTRwch4ScxkqKZhoeKBXAy/dlc3CEsxKYrGrUXSUQJsBfBZxnwDdOqiUPrMOjipv9GLIb
zbLALi1kzkVDweSyAGXZRxyZQNPMAGyd+sNm53E/+o6apmq5bVaqXcu8IXqmYpSiHMAymDQmzmNd
3u7f41O89i+ZWMgIRnPDtazUA1+pN7+0Xi29TQNB+J5fsccUqcG7Xtvr3tqKCwgO5IAQ4pA2poSm
jUiiIv493zcza7uPVJXKyd7Zbx47O69VTrdwRsB54aMrBS7WLnPa4Cbk9RFDZbHfbPUsuKdUNOHh
fY3yL7w2/x41Vs6WXoIswVliZJhey3KUABGfE1iLgvduxbvEn/Fs1bv4Q0Ly8FFzMVguanN0K2VS
gFtcbLb7buk2W2mi9hirpKiygh7r8vSI+tXED/Kv71lI2HaXncm8U/VHzLflKJVo9MqMY8wheLQv
7y1D0LOditvL2TTSvLZBzyy22FdSK7FALQj9pzv74/rWSeT4PkdRRfaa0p08xeQcd6NasHSW21a/
RkXlpVFSvjJKYjVMDFUOE7rrp14L44TOuNalOzuRZHWfrRrJ5q1uXhkLbq/W3A2jgscxJ8nUE6du
bldBWTZUVMx5nRuFjOrgqVFXpoK5NdLIOj7eVoHuzC0yQMcfqtxZvX+gEo+Q8j+oHPKn0hSopBfI
tRZOQRsT/1U8cazu8S+96fjaelD38RrzRbOEM0LrXA+i1APcnu6xDsA7X1g4o8S1lv+gVR4r4x6q
rZR9Ax7TF4qXckugLhXxm3OVdAfZu5XPZW7+MatCBblTxANfYYTy7HDmAXuZ8Wif4GsMrd2JO93t
5D9PCxwW6ulgb219Ok7/kn5BBAu4VHhZCROGisgO1i25wpxCMLK7nq527nKxM9OGKTC07TNToO0e
ngIPs2fhoymvmhX39z2+4RDzwU0appvP2/Wk5gx4Wvrzu2/Pd5U7n8twWrj5+cS79wjiXwDimv84
X7iP7tv3wi0nPnFu9S7WDe24mXCeL1JPWE/mICFABFPyFMSgEccRpkc0SLcAwo83A6hEQwOTT82s
LvKackkRrrLhyHwzGGOQHhCQBbWK7TEo6ymZMSH1BDW4VQy+rRjsaxWUMT3CN3SJSVYDy5bgEZcR
7plcFLM0sriHZEDZlio1lkEQFXpqTZZMQKrxsteTyIcpCamGw4ioSjmREaiXJGFKwaTUherJmB7R
ShyobtB4BWVT8TkILrztOOUZQSSDFATTyjX11mTIAEAJMblFqaQqzLIxMeW1SAVFEDGpL2Od1DyD
9IDK7IfYf0FUiOwKZW5kc3RyZWFtDWVuZG9iag04OSAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9Q
YXJlbnQgNDcyIDAgUiANL1Jlc291cmNlcyA5MCAwIFIgDS9Db250ZW50cyA5MSAwIFIgDS9NZWRp
YUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAw
IA0+PiANZW5kb2JqDTkwIDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQg
PDwgL1RUMiA0ODYgMCBSIC9UVDQgNDkxIDAgUiAvVFQ4IDM0NSAwIFIgL1RUMTAgMzQ2IDAgUiAv
VFQxMiAzNDcgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgNDk1IDAgUiA+PiANL0NvbG9yU3Bh
Y2UgPDwgL0NzNSA0ODcgMCBSID4+IA0+PiANZW5kb2JqDTkxIDAgb2JqDTw8IC9MZW5ndGggMzcw
OCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiexXW3PbuBV+16/AI9gJGQIEKdLT
fbAVdatmfWnEdNKuOx1aomx1HMkj0U3yk/ove26gKFl0nJlesju1ZygA5wLgXL5zcFYOXpelscqo
cjEwJoqdiuGfR0UM3zhTQ5dGuSo/Dl6PtqmabYklVtvZ4PWPU6Nut4MQOOMkVeVsgKM8UeWnwc96
tF4tgjCPEr3eBOEwcvoj/1RBEVm9mtWqrLcBrjTMp6YPNdFmQZhEqV6K/HJWCcdyvVKBiaNCe9VB
aKKh3gQJqFHTUXkVD5WwPPn108P5N/5+I/ufarm+MnS5iE8e0+RaIy3Vpw9yBZu+EmNY5ojj6yD4
a/kH8lXMviqiIiMv0MB7Ksmj1MYGfYV+cEP0CDnHDMUlQaHXD182AdkySGHD27uGfhUY0kZG/zOw
BZxH/T5w+vH2DhzEnlkviI2ZP4GeirXUavqFeZhUfwRBXngVoGvgHnHsL5BLrOWRyfIhXKB8Q2dN
THtWvACeVfFfYKw+HB1d/G+OTO4vJMkTmixKkmGiMnB04fBafJnMZ0WS8bXOg9DGUQbWj8Ha2yAs
IC1sCo6ugjADAkS6g7CZ3anlSsnkDiyJpr4MwhSmjzQV2g1N1izMlBX4MgbTz2mmpsK5qWELMP3Q
76hky5ZfTfzwxitczX1k9Kt5ED2bHcEkIFHDXSGWRE5mkAzGAfM2gKPBFScXsIChPymPnOdiUnI6
hKzkdPT2IJYg//PEJAqUgwecj6i0DSjLhi9F6RiM4vQ0MEW7pC4CB1u8p+95YOEIZ+N3kH1wwhOI
auAwUWCcHkaWdh+XA6OWapC7yEG8ZkVGCRm5XIX03dSDxdeped5SnYPj2y49tbBbv/hXyJ29YYmp
NkFcfyJ9jH5W9mBMliUw3YGMbQMcRMnO74KMnI2GXSAEJjLZQAAYtP0K0CHTs/pETRn8RiRSUhwY
fcWLlGzzTSU6mpB/lzWVAtRNyC/LW1BhIamIdEsbNJtq1VIhb3I9ax5kIR5GzWfmgnQeIdnoe0Dg
RFePrIsPrVxkIuOd7q06hOrU71GmPuPRXnGvPH7OZT30fpc54HXeYQn5a5cSFi45CSgN/PSngNw0
VicKPIRZ14Bl0IEVZDykG2Y85brRslBDUhnd1BsPFh8he3LwB8ptcTLUVTMjkbtDa6YxdR491mTq
M9bsFSflrtjZ+pg1e+j91gSkL2xbY5NdjZW2Z0rR8x5uDihSSshPMJj9BOxrCYjQ6IAvWp1DLUYz
WYx/6HVS7IDQZnccrgrpKxlD/LcEKglQ9hH4Y67BAN2PwjpXfBhcJdQuGLRxFyXTlnUiIxDngadw
nh1XBe6UWOiorgFBqVOQ0QabvAIvEbb7IeyjhSbeKKranURIXZuFODkNTAqEESXuW754dBhNNoMu
qDeamPpMNPWKe+VtrB2Lph56bzSlBVS+NjWLXRNUcDBdYRxZwNQcvldYHa2+pKVpgIg2Pgmwlqpy
rf4BSYa4a/VmSYuLL4G1HC5gwDsiQ2wR/5IXF5jpGfLg6h0WaHDfplasAf0G0Vntktpi4IowxKvB
TkZ0zngHr3rFs73dMVrx7I+8EcthvCGRBeZMUnw95uCGI6YD0I4YK8SMQYsDCnleORD0EgJY8e4W
tUyZlewm9+XLryiwYgXRb9Is833F04KHPQqeCIOSOhaOY1/OpOJA7ML5uNK9pXEXKn2N5NLD30pC
n6uZlCMpfne8xpuqWupeI8sbVUnFY01rfE45PVtWDTygWEZEmEFVN+tNU8/VmogbSXnRP39YL3nU
UIVU3QLZNPe1v8knbPsKQv1E7510/67MwCp5/BFCAnI75XoCaLCW+WIHep17++mnwGZwu52jnGsd
JQ9S9hG6n/yeUKnKyOtWxhs6XEHhbp4CCpTMPjQB0jNQclyQddodyrgUEeFA9Di9H0ccdYG+KUva
GJWHH/VUOfVmmR5jSEp8QplHZyd6Sgbxi2pEnJcXbyZd3glkJywy74k6RX8jTAAu4VsG3yYUa8NO
rFH1CgshK14SrkbVvNxUN/fCRbru+G0JEeYgp26w5yvQ29iL19xHDrVor/nXRylGXtIGnBxRVXsy
c3UW+dND17d/dHVfN4o2lFOoS76wWmM0anV2HBnc7g1r5A2LSJJTXIHav2DZx4KFrVLnfCmWSOhV
bwPCo1rNCVFzAACLu7KSFVNVjaW28FO8dJfMgnA1cuL2kVdndyJMaGy1TGUbrrfOl+IMEQt7OlaC
xdYBYpHCNotBPqfqDmDF16tua7V3Xf7ZP65sKGoWvA+kX8wgBS8sStKCnPrcBfet18EfnC75lszq
r34+gQZGqw90kd8S9ie6dcl+yqdp9kx/L9T+xO8X98rb/j1xyPlE+hi9P/fBiruO1KZt7qcchOMP
lP0ZZ7qhGpRLSls9fqPOxxjfTvOX0iLXP44Vz0Xqj+/HF2I1VgDPAzJb+RuG210nHEsnPF4R2rML
NU/AKV3vUTPS+cMur3+0G76U77lR7/HOXqqhMyJTJABdCTggbpsF1zojY5t0ZN//xGl0RbKhFz5A
FQix1q6WdVyDB7BRuV9vyRNYxeAe18ELzfifHfWerqdMd6r0d3H+l4xexsgxARBXmKwTE08ayJfq
O+X2qtsjdjq7WsJI9jsMo1+ImaV9HgI+dcDFDlubJd/5Ha715VT9gMUeUfMV1raEqg8s/nmXBFA7
DEKmtA624x58T/yNKltK1TeF6ns0dYw3SosLGA0JPBBxT9rwFezMizj90Le/zVv72u/cvmp0efl2
MlbX+oKC39KjJNW13E0iJnYdi7IIvSgS6G5CzKLTgPrBEZbGZM/C3cde0drFfO92UQi7ggj80Mrk
+7haznw3Dq3V+4f/I3E/qrxI35TeHEM9/1VgrnpDnVhCPaGFa8lU7f6+alt4SQ3dkG3Ltz2ExWmz
qSto77HlV8s5wNHnkKHeSOqGXss+OhkGup/19BSl8UliHL1JjuZswszftcH/5xH8Kwvgf5s9v6k3
68a08zENZs10G9Adu3aQ9pdUbpUPlhyCheqt+l21vH+klU3tcxC60Kwo2n7GtY8W4w15CWV6CG/M
DJHlB5k+IgI4KOEp1Kyb9eOK53PFfLwONg5CLmdHM96Z3W6+TEPDFWS4z3n1GXUavcRKb0GHtVAF
SWOh7+GJC3A0WTGPP4HhE+BzkG4p3Lz/uBzkgD+ASik4PrUKTpyrkL6berBAap63VOcAzWyXnlo4
yLPiXjlEIVNtUeDkifhRhrNyAKfFsI4VDQowjYMXqAV0T1G0/MjR18KHFfjACpBqaJXQRlPE2aGs
qTfj6ejd5Aot4XANOSaXFycHNrG21yBI6rdGjyDr7BjK0PhA9Di93xBxvGeIrAU6baKg/PvgdVk6
BeQFkIdpIQiBXFoJPWc6+iC3OwgxbW4byW16thndwAsNyyuGIDb1D0HosHtVzVotV8sGn3CqEpYV
9HIQl9UWEsBp/q5ZAN96SxgbTBDhW0Cfl+oNOiXVngaRHkPSqHpP5/xhveRREyC3OgvCFNtCOIac
NAIBzPPpgSTvj080DAlsokPaV8RGrOhtgA8fRaLGH8Jr6t7H3/WWtNf4UtrJfWKdSzpjg0GX6ju+
LGT0khdEecWi9z3okO3QIZMXFiV5hunOA5nP8eKA5FtwkCXwSXzyO9gMIgug66HatCsWYA9Ojj0T
c/N4o+47sy2r+xfp1dKbRgyE7/wKH6ES1Ov1er3cmqiXSu2hOVRV1QOBTUJLWAVIqv77fvPwrklC
Gikn8Mw3j52XPUYQN2JKVahh8KYBUGW2PB2bsXongmk2BZ2O1VMH2R3TcXKq8RXmNzl8NssXo6cr
zVfeG9plt1uZww3vCG2WPtqS2kmBpE1pI92z6cX1MU6oBLu7F86EGrEYy86xbM29QNZbkTQLo4TJ
NMLrawEuNiZJ6u7C5A3CgZgdup18C9IUbe0epzprY/fGNsYwSmGKukSyuzecy3bJTsbxb0mtRoEb
oRrPJzQbzcc1122RZHYSXfyjvka+0Q6ddPNW1KwFT+1BzX/Z7Q7tynQ7I7Zl8V3vMdyW7fpBdE0s
crx6ZVTKN0bFu6GXXApL5LCgMiUuDYeFj+ZsjgsUofjKoIUwt8K8VpEJF2l3Re3V0MWtY4FqHPNA
fg6shx9bkGooVETgho0cuJqLTcy2+odmHeP0LFrMmUrvZZ5YI/ROlX2fUBKn4k/x2oLzby24J09P
SnrDxRNSwXkuOMwL4c3hKWL3jTqT5iktU9RVPGymkQcKSw/t3PBYEuCUykzw3M8ElKMg7ujiRyju
hbfln6VcUgWPcTaFOn0QxKNYIbFcJhoB3Sjo074g1phr7dx82O/5f7rVaBaH7PagqUj2/Pgv0S8J
QROCRwifWGhHdxPei+2KTrhPCYx2C2O0y3KxV9eyZ0phTz5TwHrhmfK8IOu0TfYMsaiicMQvbMWv
keelT3PJKeW+4Ncp4wlwQv9/2O/P95U5v+AnlDUX56PCfEIB/wIQKf4DMfPZ/PhpzWpUxHoWoAmL
ABm/HZVwKfiesBldMCYSqS7J21sQ6EmWYXpEqMjCZnT1DorczCIIvqxmIRfiM+lFoYkUNq7gc9sK
GQC4Kr2o7R0Gr2aH8W5ikBCOHLbsTmY7YRKibOpZ45JmAZU1B1XccbEniMuNYlxmugcMbMxM0epL
x6QKWNaaCA4XP1n2tDyRDMWOAVUpZoVAZonEegMCQpBgxXCCDICGI0eGXcU14vFZYliFlMB6gfFM
8hQGYIpaMpAwPaLGrHbHKSi9nxV5Cohg/VEKSh9JbkiBCmUp8Ja646hmygJxjLmUEPKqKTHmWHOq
mh7TI2hpVM19xConEUTUo01njkVRiKkqaB7Qj84PkB6AT2rCI7XkA6uNdM3qWdRG0VKU0mB9vhXS
A6zmktSqaRfxWMxrggjOH9UEyGBl+e0xA0IDA83/BBgAepAWcwplbmRzdHJlYW0NZW5kb2JqDTky
IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA0NzIgMCBSIA0vUmVzb3VyY2VzIDkzIDAg
UiANL0NvbnRlbnRzIDk0IDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3gg
WyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNOTMgMCBvYmoNPDwgDS9Qcm9j
U2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDQ4NiAwIFIgL1RUNCA0OTEgMCBSIC9U
VDggMzQ1IDAgUiAvVFQxMCAzNDYgMCBSIC9UVDEyIDM0NyAwIFIgPj4gDS9FeHRHU3RhdGUgPDwg
L0dTMSA0OTUgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDQ4NyAwIFIgPj4gDT4+IA1lbmRv
YmoNOTQgMCBvYmoNPDwgL0xlbmd0aCAzMTQ2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJl
YW0NCkiJ1Fdtc9u4Ef7uX4GPYCdiCPDd32Jbc3V95/gi+tqZpNNhJFpmI0saib40/Uf3L7tvIKkX
6nxN2l7tGRHAAovFvjy7e1GcvS4KY5VRxcOZMX4QqQD+eZQH8BskKo1iP1PF09nry22splvaEqjt
9Oz1dxOj5tuzEewMwlgV0zMcZaEqPp+915er5YM3yvxQrzbeKPUj/cSf0st9q5fTShXV1sOVhvep
yboi2tQbhX6sazlfT0vZUa+WyjOBn2vH2hsZP9UbLwQ2anJZ3AWpki0HXzfdn//G72/c/lMlz1eG
Huez5AFNPmikxfrNWp5g41eiDMs7guCD5/21+BPZKmBb5X6ekBVo4CwVZn5sA4O2QjtEKVqEjGNS
MYmX69X6y8YjXXoxXDh/bOirQJHWN/oXz+Ygj/qjF+nn+SMYiC2zeqBtvPkz8CmZS6UmX3gPk6on
OMgLrzw0DbwjCNwDMvG1zDdJlsIDiiuSNTStrPgAlFXxn2es3h8dXfxvjkzuHiTBg/ZN8lwl8M0j
9yqTuZiAIKNH3S831XQ1X9b/rGbqrtyUoPUEVPXk2dRPdOWBCoxuqs12xyjrEztVvXTbrunQLagd
x6ME9hVeApPRm8ubPROMMMqTwKqR9eMUY/ZK9B85ocOIhS7oaqPH3ijSE8+ExJfX1O39DxfosEJ+
p87BzeHqCPw8g40Z3Tsuzoyq1VkW+BkYOMkjP8lU4EeZGtHvpjp7+DWq8W3WUqPI+qHt02MLgg0f
/xVy724rRDgAyjg4fIR8UeyFZAYKwJBMEgOXdTFpE6fcQJT7DgyUgzkDCJUHRIxQJhswMdgo0kvS
47Q6VxPGiks6ghYIQe13vEi+OduUwqMZ8beuCDmRNwGlLG+BhQUEINKcLmg25bKljgDz9bRZy0KQ
+s0/eJdyzsZSLAC1Ql0+M0OWXIFlfOvs7hSbglcmg0Zl6gmjDhx3zIPOpsfMNkAftluICIVWazFp
2gKViwnU0bWXSjTg7HvCvTHEgHrjgfGs3m5XGA1GT+uyqTFbZZj79pUTpX46rBymnlDOwPGOuT2l
nAH6sHIMRFDkXBpEaqFbUG4COGT0vQfIoi8K8pcYNEXp0E2/R/0kCBpwsT5X90vKdgSPXB/Qbw3+
lWtCS9QjpB1At1ATHMLzEA7R7XCNUDOBNSVweUhXNUMV81bXt9dOnBFLB1aLMMJu/H0LWQj8aNBC
TD1hoYHjjnnY2e+YhQbogxaKc4gWOww6ghn3oJdcEEiW3k7G56pYqZ8p2gWJ6ocvnqXIFjB5JGrZ
qNqBC8GEeqb1JVZvEZuSwYvSnQMstLz+iYwE1kGEc0gnFgTLlJsKnjit6r4cM0h1NHWGQ25qjwcz
4N9S1uY9Jqp5lFkfXXcf5mju1SANuUOgAENNnCRtgk/bBC9F7wN4VqTrxaKaQTpEnYCKclJKKrfj
t1L3dIeRddQV75/zh5dRb8LmDgXE2hncB8IEVReAvSqeo+bUmre2W8i1sWLIWD+yUclNLKrTZQQh
gHOIgGPuH4Ai7KD7M/WE+w8c75i3wRFC/CWHp4/Rh90/Tvwga90/bN0/7bl/Ro4PCIShL9k0QjxC
rJh4EK/torqknW9vr677e6HEsrDIe88R8bEy2jLeYwGXY3sCoSvgv+RSGh1CyIqXZFejKl5uyo8L
2UW8HrnS9hApZ+ojpvQcanAboyexs6ZauFf8na1X9VLK8rCtI0VEVe6cmakL30m/gSqAFue9OxVd
KFKoWdmUGIldRERRGxFRV8gbSZUgkcFaFUUCVWVa5g1NeqJRxbt9Zur0kb94N+QnLdNSTpUoBg1L
SDMWxCXyhr0cooPQH5gD8BrQFTHn63cZqmcnXvWwI15FfGeSTMC/KJdQrYYEvpzHGyfkF9xh9bpC
I6eEQxT1/OHNS3kBf6h/zclsL1fSfnTGSXyiYBbqcHQOHe+Y2+HgHCAPx6Y1UllRbMZtbMbsLeO/
UHQmHIlcZmYSclaPr9QPYwy4SPMvuW2mvxsrnsupH+/Ht1QBhMIAarLjEB6GXfkiGD7G8iAUU2ie
gB36Vogwinp/p9vGbvjSfadGg+Jd/BudLCklBJAJwRSBU8phxXDk7D0l8jviMHIs9rV7WBx+AItg
pbFYcbXGxdnsg/dCZf6HR4Pi0TuLP/CzItIPPkhT/iz+fgiFNm+VKEj4Z+yrjK6pBMkJevALyIPB
nnA/xiUJwgyggbpjHIGqV0u5lEp5YiiXd3/fQAfk2FZPp9W6obpA7d2IKonlt5S1uUh7NLqCtkCy
Ya9xAqCEPijTa1RISOyx6lvxVFapXYqpFkpAhpI3LZSQZY5aMTlXQoYLHGrGUhCzb7HWYO/17aqp
FDUcrt3AKKJWI6VWY/fv2ziXDFGrfyM9h+Roob7ZEbNLn85pyAWo7bHOBcg5pOoj3ThkeuC0hy8B
z13svORbQM/R0QdNvRslX5RKOjjusowIw3Ky2LOuQaOkeuxBFArYBIpy3ndw+z+Fh73Rc++hL3/+
jkVP62HAsLtwFPTg6PLt25vrsQASZPwA+8AhQPo96pQfMGJEFES6xI4lk1A5ABmbte+yv993KQx3
w7W+BXMjZvHvMy8h7LOJYz0tCf0Mwx+uq/v1jsnTHqBdvcFbGFnf9Hf9f1h80loZU93NfnEbQu+Y
DBa3TD1R3A4c75hbV/qaLMRK9eD40Q2DBW4IpVBb3w7lPyhTsZWY4MNTWVNX48nlu+s7bDYiXMMd
129vz/cUEkZJW3Ef6IOJw+oYOOw4Q950VEjusd0/fJw+rAvovlpdJB1IGR8B6nVRRAr88gHIaZxL
+Ym7APeYnjHd+EGU2a4+DfMuTebi2NQbcV+WyG9F2Gr0E4PJGlVqhKb4s+I1VdMMIRsLAai5ItnH
BGgyW57gtSVvVKVcsKWSkX+F41QO9rlgREcU6XQaQN3AKvWsUUukLhOQ3wnPm6UvdCLKG/ptod1/
0oX6iP0od5+x3uPHm+SpvDZnsa5vPYSj64IKPEAekag68linAD5Kujn9qlZivML3ArpQ9MHiPzKr
nhgd6Peq66jr24yE1hP2IyADXLtF8XJdzj3qAatXihcqDK4U3kvLM8zYqRbainrMrM9GrdaNF4OW
yKymO1kSeQHrUssgV3hj6LujeI5HG2bvnv4ZjZUQzwbrgEfmiM0AC1U9IE1mzIIrpp5gPe6KuKCl
Ybau/IEceZAJ3hHaQrWymSlpSConY1v2o7Wh2m5rflfs99sB9czfne6FN6pS7dDmTCwXyrHADJjo
50XZrDYsOgieBYAyew/ooYf9SvQ41AVnHlHCVET7xE/oYgz9+BycMtFUxhOBw+OlPRICjSitpC4L
mo1SmkA36PNuqyDbS484VqJQYcYfJwHzaUjSl+o0/EqdmtDp1KSi00dqb0idGPqfaKouvBEkB9Cj
pcCntUa2uqdHsGGENQ084JL333hBD/BA5QFFGrPebksZzZkRYk+iX2GPh3Ps8rCCRDp9eLlG8AIV
RmibGVOwNsdyq2QW1HDJVTjHwryryTFVWCzH5Wy9S1ssWq5d7FuKfcwmeDk/HNqInlhyxj3OXbPs
P83xXfO3lVbOHAg9AApJGwgRGw00VdU/g/9gogMfALeslzR1tkGEe6lTRV/pVJHtMN66SM3A0wkz
LflWDsb6xFPFxHMyaD/TcLbK5JeQPOMEnXOCzjVPOAXkDL6Wq4JcjqmKL+MZn8I0EOqPix6LLVrE
thLShpn6WCFKkwfYFJUrzNxFlQwkzbcSNHtvMTFhx87hmbrw/1V4GTM3DMJQeOdXMHdIwQgsz956
18ljr1uvQy+ZOvTv90nCQHqxOwo9pO/FxBZ/R8REJyOiJk9GxMeb98qpj4AYhwvdpaeMh8VHm4+y
xlWzZ2CPe+/5g/L/pJ/X7+zXTYfX4LfVRf+C4/gFIZr9+Bj8q397D/7DRfgIFD0tUe4UN5fChJK2
AJqr27CEwyUaxnNm1eALR4OmKZYsEFf3+dRFWS4PN3SaldliqSsruquESzZJhamSJsiTwGnZpsEc
ziOvxne4eGEwjbhV0gVs+ANtWkZWiUbStOhdoJOaoKdxpCsn4SCTrDErJ94CymmxFCU2jMRknMSV
oUqaAGV3ztZ4xhdlsG/xaD/NAjDY3yVdwJep2WcrU5K6K9YEkdkv9jcrpdrHVuJd0NJ56fZz0qY5
TWa/xnLfst/0FzcJl8IKZW5kc3RyZWFtDWVuZG9iag05NSAwIG9iag08PCANL1R5cGUgL1BhZ2Ug
DS9QYXJlbnQgNDcyIDAgUiANL1Jlc291cmNlcyA5NiAwIFIgDS9Db250ZW50cyA5NyAwIFIgDS9N
ZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0
ZSAwIA0+PiANZW5kb2JqDTk2IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0Zv
bnQgPDwgL1RUMiA0ODYgMCBSIC9UVDQgNDkxIDAgUiAvVFQ4IDM0NSAwIFIgL1RUMTAgMzQ2IDAg
UiAvVFQxMiAzNDcgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgNDk1IDAgUiA+PiANL0NvbG9y
U3BhY2UgPDwgL0NzNSA0ODcgMCBSID4+IA0+PiANZW5kb2JqDTk3IDAgb2JqDTw8IC9MZW5ndGgg
Mjk1OSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIidQX2XLbyPGdX9GPwJYJA4Nr
oKp9ECXWhmtbUkw6lSp7H2ASoriWSIWEYit/lL9MXwOCFEHJtUlqLZeJmemenr6PwaT3ejKJDEQw
ue5FURAmEOI/WRUh/oYZ5EkaWJjc9V6fbVKYbhglhM209/qXcQTzTa+PmGGcwmTao5WNYfK199E7
Wy2v/b4NYm+19vt5kHh38in9IjDeclrBpNr4dFILHozvK4ZN/X4cpN5C7y+mpWIsVkvwozAoPEfa
70dB7q39GMnA+GxyFeagKE++bru//87vd6L/rVLxIWLhAuE85M0nj2Cpd3qvIpj0lSrDCEYYfvL9
3ya/sq1CsVURFBlbgRfOUrENUhNGZCuyQ5KTRdg4Ua4m8Qtvdf+49lmXfooPzm9q/gIq0gSR92/f
FMgP/MVPvIf5DRpILLO6ZjRB/op0SqFSwfhRcARU3eFFOXjlk2lQjjB0Alj1NRtEmc1RgMk58xpH
Da8kAPEK8udHxttfHTz8f65MI5AGD7prlqPCM7RzkZBULIuJXVCkGhSjK7+fkleUYuXZDJ0jQTNX
8tlsYIGWQHLe0kcaW8Pc+RiXaBM5vcWAyBDJId/rsZJx5DeblSymck7oiK1QR0NxlntW6kcJS9M3
QRznW6kwOahUcSJSTZBshjwO8RVv7DNH7gwuPrwb0AMKfg8nGAj4cIKRYBGx4GeHk14EC+hZfBNd
ICsy9vEgsdDn33XVu34eam0DTRLk27ThqckD0339GXDrbTwSqIkpVT65fQg+mHSEbZbFuN3GrWky
aZiKet/7WWDRQ0LU1jVlFaObNZobvSJF02Hse9PqBMaUTzKMdLoyYe8w3pUcsv/O1qXSqPvyXVSc
XS3l1Ag/erzxyXwLAc35gXpdLhso+/G0vteDMA/qb4IFzmeFi1ufeCgfhKBwDujLzu5OsTnm/G6j
CvSIUTuvO+LhMat1wLutliBu4mwWOZOZbUAkmPxGqJC82b3FhJ54wxOAU7QEhaefoC7kF4MQLbgo
awrHKEdNLX3MnuO6XKN5UMUxxn6Ogb6ntTTkut2hNYEe0VrndSaeFFudHtJaB7xba5gSCkNa68gk
4w+aK1z6GGGDEDe7t76VLHICoysoZ5JH9MOZNPcqyqFLLEZZO3dayZ0Z587Fva4qKDlF0qbRveWA
2lOzybC4dqpZoEfU3HndEW+McEjNHfBONacF9hJNPmmUjBBWMqeD3PvA9ZmSS+6OLsfonZMV/NMn
fVGopt56cf3oG1oB54nCu2FoWcNC9pxPMNOXSwbA6GIkmQcbhzvfRFLeooh9Xf6Xup+3HoIpaT9F
Ng5cAn1kRa0hZj6gwxozS4SdSK2MLIUcGlWfUezGtERcmVTX+ErVKsc0R5R25IMSKN/xmmjdr9Y1
utxsXTnqezTk2mKqXN+wC4WAOTVKs8y1Oq1cUYg5Fhsob9cVeXNkvUfyVazg6MJcPkvWZCGlnFOu
CkNrwcGO0VBPUfPLBl+mU7SPGoJDgWOgYJ0KOUd4rmmZcz8gMyjgvZDfeWUmG0XUXUsF1J0sannb
HZ/K8UDqzyWfksuh33vfyVmwH5Fh3BmOCDoSi4cvCk2zDdM4ody2d/UwvDsQU0u4LhIb04dFE4mW
IxDLQh+rgyvZGWU5KuxjP2mO4IwRLy/ORzuoIzK/wfMTqisxuys5uvxyCIjX+H0aKHCG8inDoqkZ
wdlKThW9hkqgdfn5FhExQ8bs4FLAsY2Az1X9VZ6TOC0UotTdoWxn96uFrGrfkJ9tHYTHnlLRYBA4
IdZrPZwLSxWoAMoGzMq6pDAhv5j8JDOP2c48WoqrpfQnxAH6HTEk3Q9vWnyklII2DwKd3siX3qRa
rNtSb40ufBpQObrITJTmcBbyuajTTGspwxXcOEm/BvK4wEA+laAcZOjaZ+2txPnX20qG7yjpL9q+
iVT6EGlSF4IlT8mvUpvKFRVGNiuNOXd7G9ekF8HZ1QU8o9nBfsSmOB11d+0K7Y7b7uuOeNN2Hwjd
Lnh36GKhTZJjbfnw79pXc6xGez338BzeDcec6eSX3dp6vwxB9nrrrx+GF9rfCYEhnLRdOo4blw51
iBwuMf5j1bsnG1R625mpo4TW3/G5drt8Kd5LEDvZHHwHLVZFjHUgRgOErog+NcaTux/ekjcWmGKJ
Qt+R2KvG8TZhuN4dPqEhcnT629VGB6+IxPjkv0yZ//NVJ3+u4cAI4vR33rTWqCsSzuOGYPL7064k
tls9WNHDJ290JXkfUwnnBul9ci4w9As/wzeuRK8w8WNWe2z7rYkbE+XORBwvlIYsUsVu6mcolWvn
7NGWjcjd+nNo/cAKtUk+JjFvMOL6suX4S7yzN23RwpYZzi4v34yGaohda1FTOO39IAoAEYTFzkRs
g86JY5j13jxtf//csgBFlZEGiAptgSLJ74McUTdS8KSAE4UMMNjOSDu1LdwPvLvf8eoDEehA/424
+9dO3D0Z90ADL+fAS3YDTwyUJNmP6YDqcwPxucv3bMJJKxFGVD/PmzykZvjonZ8SBZ5B0HEPTmo/
liZg3MQf6eDNfvMVx9jXdDZfAj3SfHVeF+KGGiqBmpg6qP3rHQid7ZcpcKQ1rvlS02lZIVOI5YY0
+hTYYKHkuZ7B+XB89p5iqJApkzBGOB3taSRuD3NPNKLQbo10X3fEG33RiGCe3j4E79aHDVv6yLYJ
JQoonbyeTBJAL71GcJ4W2ikRFiYmgVuBR0jPmm0rlWxLbqRuzsNQwn281V8eVQrMh1zg7ql1LRQE
8lnJWWtQIb2Xco9HlYgHJDeZ6LiAk2JJWS335FfJ8IhiZUSxnmxWS5o5KZMZmUtw8qwckWqHpo4k
1u2V0/awl7hRiabO6vi9AXzGq4n3SEIZGd9yb+9JYdxd581cmeNxMXHjYsbjImlHKbTlL1lF8wp4
AMTJz++HUpXw/btDNfUZ3ndlDnwqWjB8Tl45FZagvOXduipnO2rYueqs+lJjMiV3tz1tJoqhlr5x
Bv4u076A4OgKSldZHcNYV1WYxjWUksocvLRoSiWqpqv1DOob7gmqVmxE7D8RPttPsZWnRj71yvku
npwS2j+kq6i06ZCOY1rBg6AslnITStADv0+Vfi6I5S24m66hoeNb7mTKerUWqVAmG+Zmvwy2co35
A7mm71oS0VOszcnZjc+BPCV/QHa++G37nZIVcu/Eb3vJ6WazogYJu7BFif2XrJdyccGCkhti/yRn
ilADmrqPWav8LAe3C94rA1QnUopiApH96dRtd9kZkHZj7DYonrlRw7xoydwqxGZT6mreJg6LTWPa
Sh6oX6j5+I9m+XSb5VPVPDqBlWhIWf8Ffr/IFgYnyB6G+PCbHCx4u6FGmPI+beSIM10qmS6lXL5B
spFEfkqRT0hl+4aClnqDUzqNsRyrWGkq4cTBK11w3MuLvBeSO3FvNQk1l2fP3aZEJ4IR06BA5VBx
Zm0U5fVBENc+5ebP1SzY6y0Mlu3u3kKh3b1F93VHvOkdsmIXZqIjfVo3lNkS6HG2njzcAA/Tfgb8
+myTwtmY+50Qxme9CH5FD/4dETEevkIUwjv4+FsIs15k6fUI0K+DKIO7HvdQtjm47Y3xCCOJcHIM
R0bBdJe0UBoES7vrn5BqHmTIX5Lk1G61ruCBTZgq4fClNKIe7G7Lily63WIkSRAZR1mRYuzKrVI2
tjkQfgvFCUnniIP5xCYtnC2GbSg3SOiECbOjMvB+h2NMQnHW5lhRGoQwo8acySbmP1VXwRaAIAj7
o14FmPxT/3+OgRIcnZubw4vsmMAb524ARUPkYqxVMR0j8PAJLADOzBIaleOBMwt5n8nZDD4prXc8
shfm1rgizwS8K4NucOZYfVq8Inp/htrG7PMlsc6aKoDaFo0TI//bSk4yxL9BPTMhas0cQMtM/lko
7puTDPYX0DPfV5XYqqU1XOtsg5Db1xNP3g78ACrVLBcKZW5kc3RyZWFtDWVuZG9iag05OCAwIG9i
ag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgNDcyIDAgUiANL1Jlc291cmNlcyA5OSAwIFIgDS9D
b250ZW50cyAxMDAgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAg
MCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag05OSAwIG9iag08PCANL1Byb2NTZXQg
WyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgNDg2IDAgUiAvVFQ0IDQ5MSAwIFIgL1RUOCAz
NDUgMCBSIC9UVDEwIDM0NiAwIFIgL1RUMTIgMzQ3IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1Mx
IDQ5NSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgNDg3IDAgUiA+PiANPj4gDWVuZG9iag0x
MDAgMCBvYmoNPDwgL0xlbmd0aCAyNzc3IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0N
CkiJ1BfZcttG8p1fMY9AKoQxBy69WTIrq9iWHBPa2io7tQWTEMVEIrUEFa0/af8yfQ0AHqDtyu5W
IlURM909PX13z3k5elGW2iitytuR1lHsVAz/vCpi+I1TlbkkylX5MHpx0SRq1hBJrJrZ6MUPU60W
zWgMlLFNVDkb4Sq3qnwefQgu1qvbcJxHNlhvwnEWueCBP1VYRCZYzWpV1k2IkC3TqeljTbhZOLZR
Eizl/HJWCcVyvVKhjqMi8KzDsY6yYBNaYKOmF+W7OFNCcvD12/39N36/kfzvtaivNCkXseQxbT4G
iEuCl4+igkm+F2MYpojjj2H4c/kj+SpmXxVRkZIXaOE9ZfMoMbFGX6EfXIYeIefoTFwSFsH68fMm
JFuGCVy4uNvSV4EhTaSD/4SmAHnU30IXPC3uwEHsmfUtkTHxM/CpmEutpp+ZhlH1AxxkwPchugb0
iGOvQC6xlkc6zTNQoHxFslrdyooKoKyK/0Jtgv3VUeD/c2W0V0iSZ5xESQaBnyaRLkyOapEyxvms
SByrdbVG94K9S4gKB1aqeL8K4UASNI+CFyzEfYpGFKr5XOA1fxrwWhzlQeP3arnynry8uhRsCY4o
Wg8/hJDghxyAxnhhFvzxJNGe+5BPUkCNGJvIusJ5Lyam9aIxrG5J7JNgAuzTYBpqDGkPVFehg88N
/b4NDYhxPnkfUvydQTSBzDoKtYMjQM82n5QjrZZqlLvIQaikmaOyFblcjel3U49uv4zN8xbrHGhh
+vjEZJEZPv4FdHs3lLBUsMYi5d7p4/jzciC9UwflxLTZbbvsloL7HrIuBacZcN0thiovN+DGAmJo
hfXIBrMaTIulkqjRFRqI3oUQwnlAET7fVHQcEjoY4wIqhfCCcMyAd8xwLN4FYAG2YOZ4ZAPoaiUE
EEA6mCH4kSBxFuHm3x25D0uW5x4gFcv7xDR8CV+vgFtkfBx4QycQS2bQyYw94eTB45556+NjXhzA
D3tRQyvwToy1Lw+m6PIlATtcgtZ5u3sDtoEcUmdKvQzJX02zRo8VwWxZbZfYBXNwcAp2VNNttdk+
0fpx31QmG7QToE4Y6fhB5pl29jtmoQH8oIWSwoJEaCIeLFJvozRlG01vzilqLdmngO+lX7yZYDs1
wZnCOluA6SiiPZoacYEBBvUa7IUx1TwyodALyVYJ0ZzBc4HXDG0av8CCe8m4Ky6XsvN3Kqi3SYTJ
OAbXp3C0ktXC84j23RRbtNaQpxh7wlmDx4X5CWcdQw57KiNaCWaTeUfFUpDe8dxzExqoTZnfXk8n
Z6pcq9kdRHUW1LNf6au2slfVbItzHkwcUAAg6Wn2SwOPbtBqWfCZtg3EOdYRy+2KouIBOkg30DxD
A4GzMFBCz1vxVdAa0T3kHKMjrG7cA4kz86yE20KuXTIYTDKrlyzRb4yis3M1WzN3FqYSGoYtCbZi
Xl4yRq1ZNHUp5lHVnODzTc038u9+jCQZ++R4jAh2OEaGj3vmbQQdCZMh/HCkuBS3PlJsGylZL1Jy
iJIUTDaBThFT/qDRJjjhWxgdnEwONCZfEOX11avLPi2kngEg055hrbSYcThDafhgvSRzZ1I2Vzzc
gqsKQSsGCdVW1QzeVp/uhYp43fHsG2J8ztWneou459Bg+NQch1kg3Gv+zh/Xy5UMyraNARFRVTtn
5uo88tJvNhUDF707FV0oUqh5ta2gDlGExArMpROslTyUuW5OYFvXOAiQOGAmHgtAJNcLzJdYsUDG
BltwAHkKv3hjBkDaVLv0xGKNtocohvid436DAy1Ih/07DfgXu7iWtao2mMsduC/Iki8jEGRraH2R
RxsdpEKSdpPUYSow9kQqDB73zGMf6tYh5cHpY/jhVAAdujHOJG0qJOyeyT8oGVIOfJyLUpkELAT1
5JV6O8H4dgH/UpTkwQ8TxXs59dPN5IqmbCsMYHggs5Xf8YOrGx99tZ6swkLiNMT3SEGh6vpR4dBv
vb/Tr6Vu+bV0X1h5Cen3QMzzb2FGtrCQyhY80D5DDwtTd+LmDbYj7GJ4dOzP7mWb7Z5AsTyBPoIH
Mugx9+uGPFGHWM/mH8OvNOP/ejUon68nkDixNq2G/KRF3QLqo+UvR4pO2lWd1JsB0xgKMHa6FJ94
VGYKfNNCkcgjfC7gr1zsA1V3BtXeJ38Kux1bgUEwSjhfDWTLPylrHJnYBa/7msU9Q15cX7++nHSm
dK41Jb4MZqO/iP6sB/Zv0J1UN6A6jMW56L4TKX9qVRS6zPAkoGmmTOX3abWc+ekBJoabxx2vZq1X
PwSvXvrXRwLW6NJJY/n9C7pXTVufom1e7zdinKXNYCNm7IlGPHjcM4eUYazOzGEnHiIYbMXWFr4P
x+3jxUg7ZK9BOzXg5CmqnQlMvZpML97jvI7vjJIpLq+vzvbMYV1+4hkn2GFzDB8X5l5Vstr+0UPk
sBnw5cZmSLuSpCMsRy/K0ikIzFtAZ0khrRKpYC5gfM54NH5uul7quk6opRNSwU9oxivkt0Yj5pBY
UDGK4BGHl1xQij9rhvkpBB5s9DbDU7/iKUPjo6URGoErBqoKZ8s84F9hMlsSy4o58wZemvDQhJmM
J1ZNtNio6CZV73CVqbnwe5G0Pzcn+4LDKD8N8dHAcnpOgqXhNvHDbUIvUiukfQ1Eu8WOyvjk7Mkh
NDsS0iSt8enJZhGwF47n9U3dvyo6/pA4rFTvqQrUs/VmrrZ3VA3rnp9wVodhAt9MaJaGun612KVj
KJL964kxZAgdcHWd1eqJSZYrPqkqJYBwDAkSLJiwulf+pFRpAt+H+IaqtusNa4Vax5nZ160X9+YP
xr1JWzM5NhMO4PxYg6fOjIR0ELu43XkGFsEZPXQUjVUYhDqgVmoRD2hm9JrWitTPyH7gVv7UwnxF
zLfMrdqyc9Jdo0trc2SoFIMf/QX2vqT3B0SiBEZKkxndcsvSCO2afNw9EJ5ZiTtmu/Sa8t19pdRS
+G3qWb38jWULcbief62X7B+tTt1YqbV3U07SaiwC6CcoklxiQOLzsxCHGHUdom5b2nhSyEUTbLrA
pwGQoQ1mVIZBL6TElIFcdnIuOwatSQeVEK34iFSc3O/5anjsVJtaMSO+ahdfyXeLvjStqHKCsr8A
zxNUBCDXd9UgGxATjjrMbtMrfM9Y+FrbsbxiQIFxnXO+zqUYv44qztFao4veFCVRklFxiKFyfilE
Avff710YHQlrYyQ62gakGHm21wwsFb2va0LSc3zzYigf8y2Id77SY/3/dN9j0eCYbVoJiWCuPtVb
bgDPIcwGkGa7/UzV39TYdlvsHFrb/shj01MjD2NPjDyDx4W5oPK4nWoEZ5LkxMlhLIol2JNiHV7s
kQO8v4B+cdEk6mJKw1isphcjrX6EWPwFCCGon5WO1Vv14edYzUc6xzlNKwcjrXPqYWRjE8V5C7gf
TQEEkYU0Kc2MSAM90PVoWooMKm8OgNvvOiKYNGFYfoCrIEbiFoCcEUTnEoOqP3TieJqWwjmUnTi3
RBbar5fH5C2AZS6YxhR4Dmh0yow8TUthM7ybZfZEUIBi15eZATsym7QvsCdo0TqPhKvTGVsCxvwc
uboUAHkLQK4IckQDZRp1clkSGdej6ShyVgA5W0O3J3A7cxaATWIvjsgXx96/YisG9G1li1T8683g
aVpbxa7zrxDZ7PdZQOyGhRVUADmsjC2A7kMKLbgSuAJzU4ipAInfZrAKZW5kc3RyZWFtDWVuZG9i
ag0xMDEgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDQ3MiAwIFIgDS9SZXNvdXJjZXMg
MTAyIDAgUiANL0NvbnRlbnRzIDEwMyAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9D
cm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTEwMiAwIG9iag08
PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgNDg2IDAgUiAvVFQ0IDQ5
MSAwIFIgL1RUOCAzNDUgMCBSIC9UVDEwIDM0NiAwIFIgL1RUMTIgMzQ3IDAgUiA+PiANL0V4dEdT
dGF0ZSA8PCAvR1MxIDQ5NSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgNDg3IDAgUiA+PiAN
Pj4gDWVuZG9iag0xMDMgMCBvYmoNPDwgL0xlbmd0aCAyOTM5IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl
ID4+IA1zdHJlYW0NCkiJ1Fdbc9u4FX7Xr8AjubNiCPDuN1vRbL1p7DSiO51J9oGRaFm7tuSK8rr5
Sf2X/c45AEnJopJMpp3UmVAAzgUH54YPF+XoVVlqo7Qqb0daB2GsQvyTURHiG6Yqi5MgV+XD6NWk
SdS8YZZQNfPRq19mWi2b0RicYZSocj6iUR6p8nn0wZts1rf+OA8ib7P1x1kQew/yU/lFYLz1vFZl
3fi0shM+NXusmTb3x1GQeCsrv5pXlmO1WStfh0HhOdX+WAeZt/UjqFGzSfkuzJRlefHrpofzb/z9
Rva/1/b4SvPhArE85MlHj2iJd/5oj2CSn60zjHCE4Uff/638lWMVSqyKoEg5CjxwkYryIDGhplhR
HOKMIsLB0ZkNiV94m8fPW5996SfYcHm3418FR5pAe//2TQF71F/82Hta3iFAEpnNLbMJ8zP0VKKl
VrPPwiOk+gGCsvCzT6HBOcLQHSC3uZYHOs0zHKB8zbZGurWVDkC2KvnztfEOR0cX/5cjY9yBbPGM
0yCL4kKliHMR06nE77krijiXU11tKN65p8ot5XiGYuD52g/h/ObRki0RWZ9iWVmmxcKu1/LTIGYh
UqRxc7VauzheXl1aaukbBHQsqs4nb0iXbuP94KPcixcaEbrc2baUn5ZlP5ZjyMdRlKmxCfATu5Am
pg2pMXL4krUn3hTaU2/m64LNk0V15cf4ueHvW9icexfT9z4n4xlSC5WkA1/HECET2YppOdJqpUZ5
HMTIm7RIuTACeHvM3209uv0yNc9bahzjFKZPT0wWmGHxL5B7e2NJqCai/vpC+hj9ohyo9TSNMO0V
e9QVu+2/71GEKaJmUJW3lLky3CKOBeK4pvYUefMazqXOydwUDITTe+ePE8pSEltsKxZHfSOLMEDj
sLqQnxl0h7JOvbwAFWtLUU4iW5CrtWUYx0i5OS0/8kqYBTT5V8fu8lLsucdKJfY+CY9sItsraOsy
wbk6w9UxHGahngjzoLhTHp6K4wB9OI4xeGMXxVC7fmGKrmQSOOLSpxJ0s7/COSgjdabUuc8Ba5oN
hazw5qtqt6JbkXoKN4/Zrtrunnj8eOirJORLf8BXQj3hq0FxVh4XnSeP+WqAPuwrjRIzzlem9VVo
fTW7uSAfSBZH7LTCOi1ip9nmA8SQeGfqasPp7chorQa9pVrDt+jE6DiZ97jZ7lS1WPCSZaiFJN/a
l25JYzRf5lNovU7pmC1AjBCiCUIQe2943HXfnDuraEGHjqyyasm6aq7Hwi4Gh+EzKW78wfAJ9UT4
BsWd8ja4x8I3QB8MX1IA4LTRy9ro2Xb1TkDSjW/QuTI3vZ5Nz1S5UfM7+AP+nv/Bv2pn56qa7wgU
Ap4gunAsA8XUc+SGMiLzPvO08VPuMgS0xLMRIlD04vGMCwayuOiAbNaylQsnNTna4px4JtCLWJpe
JIueVtlJvpVdW4pJiDUa60pocNm8Xv3ZoyzUfCMbi51OesUzoazkjGvRqGRxI1ary3ecJaFCmusk
Td19HLPDxddI6S1D79ST74vMQlSG0gqkEzl1XFB0mi7dophq/0D0OH04oZKceF1GRW1GZb2MypFN
KU44pejZYo+lCUSAIHFg2kU1Yc7rq9eXfV7gKINF4T2jhhux3xhPNYxMNgKNpPeuBTEjSIUlK1my
XDtVy/Ku+nRvuVjXnQBqn5JsoT7VO6I9+4YbjWRW5lnttfwuHjertUXfUZuL1kRV7cks1EXgrN9u
K1lc9vZUvKG1Qi2qXUUtjRKj/KlLIcEY4uGaQAQbAecIpIAhNOyZkpC9DV3fHqoYX9onwyJPqn1+
VrEhjyORufVijs5LV/9exhIC0Hasqi1VerfcN2Qlm/ESatmnIrksrWfGPv+c8+qET/6Gx4cFkQDZ
D4NHSx0ui2Fxp7xFf0cqY4g+XBnox3HcoUOTtLWRSOSm/+DqSKUSNF9O7qo03vS1ejulhI89+XLa
5N4vUyVzK/W3m+kVw/fIKgAk6SdM1KFS1+anazTKyOaMJxNEqp8wMYW093f6TdYNv5bvCyNnIX9f
mHnxLcrYFxFqO0IE2sfuy07VSdwwSqHrj0THTvagl0fd2yq0b6uPiEAGXHO/aTgStU8NbvHR/0o3
/rdHg/bt5UvvjvpB7P7y6OsYJRV0kBc67aVC2qZC3B77tD4uxYKxhbFfvlhivn5qmzd2I8qbOO7y
5v/Lv0BeUg2lgzTor5qaij0OX0gfPIvQQJSGbrtIximXoaMfB0Rpd52lrojofsB9TigK4NhTfH8V
nuClnD1O3/20NXkbRfPDO3dyff3mctpzaKjNcGey3IKExnQvWwRBAJieM6r39z3t+StHEwuiALf5
/5NMBcwAI3tzgmCwN0GPsVjp5vF4+oRZrxxen7vHYIIj9oNbtD7RP3xw1Ywz33DmG5v5PRQTRd2b
7SWKEeoJFDMoLsoNIROh6iI5Ij7AMIhjIpP1EH7YvhmNBRMSLqSnQY3OpOZlTb2ezibvUcVjepaV
wnF5fXV24JEoyoIwH/KIpQ57ZFhclOM94c6r6XFzIHyUPOwNnfS8kbbJ6+nAL38fvSrLWCFFb0HO
ksJeMsQFcCX0XOga+nLT3UJxB9O09Sz3vRSQJ+H/NfmRqk5r75GwX8bLij4bmTsA9+ADfGp6t5LE
Hz6jQ4LlMT9ICvtOoMKsCLMXnnytmvkKKivSS4PNWt1SZm99fhUwCLUbqHpPGQPKxM3YuIs98+yJ
AsYdgLF0cR6osJz8SEjdI4HanjbOIZM3TDs4rNXTP4496nLv/PNNz76KXiZu7/7YyvSfRPJ6FOve
DVxnvWZWyX3VvZaC0x3tPXeLer7ZLtSOHoAFHoDdEWlf4DV6pya4FBu+GqvlPp+sEts/n4TC7tPc
hQtvXqsnYVmtRVJVyi744xzeWQpjda+cJBo8bBdt9+z3arfZyllw+jzMzKEXelVhvrMqdOsmbd00
4aS54/jWc3vuP3jae77QA+oM8e6yROT4JlWrRjV1G1kS3QlvtYPr8YzdPPHqllpWTG6jJkaYQ0lU
G1QEucUyUFqQdoQp7FXhs9hx549jzFZzMVpZpERlNGYt1l6+zXPcF5o2WknXbHyKNprSvF79KYdG
GS6+1v/R93Yl3XWlNgCUKHdUEJojgP4oLQb94OIMT9PcU9c+YZUdTxwrXIwm0qU0VnO72jQMEqul
Y2WlskjNB+ckX4eEs62gskxrEZG3LOMNnsvWaD/VFvFkRbLVPr2yvzuUPodK9rcSXO6Eb3jVGsDZ
oNrqzgbMhGhMCWF6iflM/av1ndhrHWjXpO/Fru+llAfE1fT6zcBbwqZIwa86/TUp4sXfmx2myw7T
ZUcipzE2O3LJDuS0EClF+sUacTvL+JT0Za/ndAkRH0eo8GQi148NuhHnFFZMEsIpEanKp/fIp/ue
ioaq0bQWMsNCfao5AyhEhnp1bZW5jWo7sGnWWrA7OIvmaq32hBfqIjhEPCY5hXiEegLxDIqL8riF
NIUhsNinmj4AfCE7TCXDLPWUYUe3duQB7V8gv5o0iZrMGIuFajYZafUr8vF3MCKxn5UO1Vv14bdQ
LUZxRJsSyo2DKFUP7QLBPKC4+5HOEV7sFecoNwOOKEQLjtuF+9GMeXJeisnND1gIWUvL03JkaPs5
Fm5/giJsBSfFaXggJQukGe88kUvSg90dT8uRIs+N1YzLhdcA/ZP0P1VXURaAIAi7US+FEO5/scAh
0e+cgw3z2VZOEw4w/3v2xzD34odShOkVoctjobh/U2OnJQ5oAaEbEAfHG42GeT3X5EYpwlhQrcp+
f5mkx6kAlDMHA+f2piKrsng4xYgXXyUMIfLHOEkzGcD8K5PKzuEI555PmMyvgczhJsRp2+FDSMVw
GmJ1t+Y/S/BjgtY2oZZVEUgbGMlzrT6wBPrASCyOcTNzOB9j1FF4AUFWwcsKZW5kc3RyZWFtDWVu
ZG9iag0xMDQgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDQ3MiAwIFIgDS9SZXNvdXJj
ZXMgMTA1IDAgUiANL0NvbnRlbnRzIDEwNiAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0g
DS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTEwNSAwIG9i
ag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgNDg2IDAgUiAvVFQ0
IDQ5MSAwIFIgL1RUOCAzNDUgMCBSIC9UVDEwIDM0NiAwIFIgL1RUMTIgMzQ3IDAgUiA+PiANL0V4
dEdTdGF0ZSA8PCAvR1MxIDQ5NSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgNDg3IDAgUiA+
PiANPj4gDWVuZG9iag0xMDYgMCBvYmoNPDwgL0xlbmd0aCAyOTA4IC9GaWx0ZXIgL0ZsYXRlRGVj
b2RlID4+IA1zdHJlYW0NCkiJ1Fdbb9tGFn7Xr5jHYRExnOHdb7EsdNUkThrJ6QJNsWAkymbXlgSJ
ru2ftP9yz21IShaVFGkLxAZEcs5lzm2+c+Z8Nng5mxmrjJotB8b4QaQC+Oe3PIDfIFFpFPuZmt0N
Xo52sZrviCVQu/ng5Y9To653gyFwBmGsZvMBvmWhmj0MftWj9WrpDTM/1OutN0z9SN/xo/By3+rV
vFSzcufhSs18aropiTb3hqEf60rkq3khHNV6pTwT+Ll2qr2h8VO99UJQo6aj2fsgVcLy7Ok+D7//
5PNPsn8sxX1lyDmfLQ/o45NGWqxfbcQFG7+QYFjmCIJPnvfb7CfKVcC5yv08oSzQi8tUmPmxDQzm
CvMQpZgRSo5JJSVertebp61HsfRi2PD6pqangkBa3+j/eTYHe9S/vEjfX99Agjgz6yWxMfMD6ClY
S6mmT8zDpPIOBHnhhYepAT+CwDmQSa1lvkmyFByYXZCtoWlsRQfQVsV/nrH68O3o4j/5ZkPnkBwe
yKEJbaySxA/DNHRumcgdCpOwVx/L1WK9VTsv1htIOMRvXi2ruSop/Il+5PNQrpCDqp3Tsim2Bbwm
ENA7z6ZQFyARQKLqcqvqp02pqpWagMwlcBlQge+zg7AjJczTRA3tnpmxbaJvLds5AzWofgw5TPTU
M1iKblFdehE8ruj3rWf9TJ+PP3hUN2dQBVD0xvdMBCKwoyErxrOBUZUaZIGfQYqTLPZjqGE/ytSQ
frflYPklqvFt1lCjCLywXXpsQz/pF/8CubN3kAkVJAAKn0kfo5/PDo5llvgRHssktvjSnEubuKIA
UQr2By+BmJVeANldImqE8rEtJZsrOFCJnpdnasp4MSIRTEgI1fGeF6k+F9tCdNRDflYloSfqJrCU
5R2osIACRLqmDeptsWqoQ8B9Pa83shCkfv3IXMpVJVtxS4Vc3LNCttz68O8S7yKbWGoxPVll6oms
9og75aZN6rG09dD702YzP7eYtAaW5g1WuSOCIZrAkU2arzcEfWN1ptQrD3Jn9W4HTSqBaM2roq6w
YWXY/g6DQ+jdGxymnghOj3irvAndseD00PuDEwDWu4I2YYNy0memV+fockRRiQiN8ub9DQBFCsCC
IKTPoD2uIIChXnjDCNbX/ICWCV1nt+EvBEnQUHkwGqjykfhrhsxUs/gOwAg4RJzXlIgXCJWJJgS1
hKAZw2fC8Imwpp8Q4yLtdmSyqogm6iaXE+eEf5g+E/fmDkgnEndM0OmM2pwey1oPvTdrMViUZf04
JDByBZifCyjJ0rvp+EzN1uoPAgABp2r55Fl8U4IvN0QtalU5vCHkaKS6WMZdEAFjg8NexDlmvCI8
4Z6IAoI62BMJsdasQUlPNDRZWnw4Ccgq86piW0JQ5mXVtXwBzZJVFA7JDhSwNP+6Pa47GvY9LkXb
/qKIuRiBJVQzgQIQNlGUNN23bb6chs12vSm3t9BIU5RGgFc3gCVgCb6v8BVOi9HMUtLq4rAi49xg
YfQUpVD767JPvFEupDBCWD0UfU7sL8oowU9XlA2WBGmnKDMqx0SPsRlJ24sQQ2CggekkkuGEJugR
cb67vJh0eSeAN7DIvGeIzWAsdjlE5h0NLWssxFRgesVzL1RyLmTFS8JVq5KX6+LzrXCRrhsei6FM
Iii0z9h7cxiYLaWKiyLVor3k52KzrlYyQ4fNJC4mqmJPZqHOfWf9Fto1LV539lS0oVihFkVdYLW3
lRcnTeVF7dRtpKmBRXAGDZkEocq0fNf00TGN7gy7e6bOb/iJe+NsKp+FSBVoBr0WMCxaMJfIW8RY
OF93+EnKbQTLD6yct99XCEhCTwgj1JCzjaEkhRBtsCByhBISXmIDzkTTXI0f2YiSjFixCBPXLCgK
BVlwC8AFS7MZinTFt1gaKYEEqhEDRLX4XXd1qy+E9vzZAY6TE0OwUE8c4B7xVnkzxR47wz30/mMM
oeZxiY5x3BzjmAtr/G86yAkfWh4dMzmdVo8v1Nsxns1I8y9VeKZ/HCv+Fqmfr8aXdAkJRQEMWhS2
2Q88m4XtPTKUjVcwb4QSdc0fEPJuLUd4zDp/py+B7evX8n0VY6+d51+vi0IRJnwXDdwxf56MrszV
GyxD7PQoPHTSB1ARtldE16Y+QQpwNrhd7ygVpYdgvPjkfWUc/6m3XjsdKMIJCoxtPKVgsYs48H27
EX+LV5NrD/GKuxZcFGmOzgkLpxs3S6U0S0FLO47/NmsKQ3L6S1Vj5wA4+ki9KUOFw1ZhTApjANOD
v7/axfEj7V6LFZi5SCY/MI6gBK6cHhauDIGWZzie0HIcAbvAgDeTeXNbIVx4JMTGHWDiD6nJh3KB
CGniT2mjDDYuuFPJBSLEnTAWJS8fbBW2XTUw7Xn72yrhL3qDWuc+PCMnE/0fQsaITk+kXx8fXvHq
IMdFj969ez0Ze7Pfj1Ra3lTadxQSxR7hzAnxoHBYCMcQ+/Vrl/LvxBWFabQ8veJ1JweP+Pd+Vc3d
xAtjytWmW8xB2oHDi1eoC+sjhmi06Gmw7X7XiVZq2qQXw/T6cBYDZIlt7yzG1BOzWI94qxzOEVNN
FuJY9Uz8KEPvNBbaFJllGgsa8LMCfpxDGKpwuJ2i56msqYvxdPRh8h7H3wjXkGPy7vLsICJhmLYD
4rOICLU/In3iTjlc4Zy/FLoD4aPk/mjghaKJRtIilvERrV7OZpGCal0COY1zGZyQC4ZEpmdMxzRk
tjNZ2abaMw4sza2xrmu+6WVwxvBUbfDYQTtT9RpuY1UNV8xSLnYZXeygCAvsQJnm3zUL8F0UE0O3
E+Jbengx2WJmjHY07H1wxdjT6K6VeHHBLO5dLCHTYMu5N4zx9fMTdrT27slGYCcNnTI2CG+6QOe1
azYIpySa40ER2eHM6DrknGUZ1ux2O+HRvsk+Nlzo/xMJRc3W3LBONuTopNMd6hD1UpoC0c8h3jVx
vEh0gSNV+ULxFzlBExa6jlfPvLtGd07kw9TqZwOXKh9hsmAOhNbcXSqN4TklEwtgePC7gPscQD8Q
IpXz9XahaDoDO1xcSBU5w67E5EqMrhAfBd3IorrnZ8VDDeM9M6pC7dGumVjcKqdCesVtUa/FYAhx
FqT2MNSd42W/9Xg9u7jwpQ+DANPXnEyL9X/pc69UMn3m4b1SXRQ1esR1F7tZMebAUQXaCIQeWIin
31bXH7yRyKzoy2Xe8KGOm9xbyr2l3BNnvS9ICcpliI3bemitwVORYEWoindQxXxebupyoQrZ3L20
h87qIe8ujo9wG+xgWGOqYu9FHT/2zarJ6K9NafiNKY3iZjg2TU4zyildLzCpOeWUPtX5mYfedJLL
kJJRVWeCF3gjqYgR0h1TJmIediAkCTjKyniVxbCwc8oKfrFU4eHc+/m2o2KHOc4b64hhoT6XUFVY
iQ8eNFo4Z6LMbVTKCyIwqZHv+pgz2Ac6wgt17h/2Whuf6rVMPdFre8Sd8qhppjBaJNEe1UYBtdTj
sn1UNkyopww7urUj92j/AvnlaBer0ZSmgEBNRwOjfoJa/B0YobIflAnUW/Xrb4FaDAy4EURGRQn0
H6vuBmFgIVLNwu1gCktwJognxt2QB4Aw6vA0HCkgfwILyx9appAmjzvYKiWjZQE14xLJhTBpRcQj
5jielsNgcEhzw4RREHMw2PzNFufMYdAGZDEJqxGWhgGHxEat2Idgb7tCvLBnsKF66hj8/6qrIAdg
EIT9aHHQoP5p/z+vrOr0CGkJNA3ixCxE4ZPVVBluAhUuKZJQ+X1qM866mUmxvMdl2TA3Bhv7IROA
gryDR1nODd3GH2fE7rjUinrzzksjxkBoShik1B3i8FC0HCgNOUkfZiE6cuRDKqcjauwsJgKHVE6T
VNukGqRnQ9yyESu/YKWzJAplbmRzdHJlYW0NZW5kb2JqDTEwNyAwIG9iag08PCANL1R5cGUgL1Bh
Z2UgDS9QYXJlbnQgNDcyIDAgUiANL1Jlc291cmNlcyAxMDggMCBSIA0vQ29udGVudHMgMTA5IDAg
UiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0v
Um90YXRlIDAgDT4+IA1lbmRvYmoNMTA4IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQg
XSANL0ZvbnQgPDwgL1RUMiA0ODYgMCBSIC9UVDQgNDkxIDAgUiAvVFQ4IDM0NSAwIFIgL1RUMTAg
MzQ2IDAgUiAvVFQxMiAzNDcgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgNDk1IDAgUiA+PiAN
L0NvbG9yU3BhY2UgPDwgL0NzNSA0ODcgMCBSID4+IA0+PiANZW5kb2JqDTEwOSAwIG9iag08PCAv
TGVuZ3RoIDMwNzUgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSInUV91y27oRvvdT
4BLoRAwB/vsutjWnanLsNJLTzjS9YCRaZo8jaSQ6sR+pb9n9A0nLouIzZ5o5sWdEgotdLHYX3344
m528ns2sU1bNbk6sDcJYhfDPb0UIv2GqsjgJcjX7cvL6fJeo+Y6mhGo3P3n9y9Sq5e5kBDPDKFGz
+Qm+5ZGafTv5lz5fr27MKA8ivd6aURbE+gs/SlMETq/mlZpVO4NfGp6nppuKZHMzioJE16Jfz0uZ
Ua9XytgwKLQ3bUY2yPTWRGBGTc9n78NMyZRnTz/cH//O5++c/rGS7StLmwvY85AGnzTKEv1mI1tw
ySsJhuMZYfjJmH/P/ka5CjlXRVCklAV68ZmK8iBxocVcYR7iDDNCybGZpMQUer153BqKpUlgweVt
Q08FgXSB1f81rgB/1F9NrO+Xt5Agzsz6hqbx5G9gp2QrlZo+8hwWVV9AkT+8Mpga2EcY+g3kUmt5
YNM8gw3MLsjXyLa+4gbQV8V/xjq9/3bw4498c7HfkBweyFjsIMppGkRRFvlt2fZQ4Bvu6mO1Wqy3
agexsnpDKa/m9U09VxUlINEPBuuhqVY8hyqeU7MptyW8pkEKJ8llGHwDIYOkVFvVPG4qVa/UhLQu
YZ6FCTyawW+uR2/k4/nbvXSMoFBtmMdqBA6kaet+4tqsOMf+zwxOTvQYcpvqqbFYov6jujQxPK7p
91fjYNGz8QdD9XQKPsBhsIGxMaiAI468GM9OrKrVSR4GOaQ+zSMoDQW7ytWIfrfVyc33pGAsb6Vx
7ILI9eWJi4J0WP074nZtF6S5SEEDIHJP+7D8bLZ3XPM0iPG4pkmIy8lpdakvFVCkUH8wKUSsMiEc
ohvEkkgG24oSGesVHLNUz6tTNWUUOScVTAfsRL/nj1S1i20pNpoRP+uKMBVtE4TK5x2YcIANJFrS
As22XLXSEZbSvNnIhzALmgeepXydshd3UNyRLu/ZIHvuAtel3cc1KYJsOKcsPZLTAfXOuDuWtAH5
cNIcHL8Yk9aC1bxFMH9AMEQTOMZpO3pHgDhWp0q9MVj7ereD1pVCtOZ12dTYxnJsivvBiSB48WBw
WHokOAPq3njShe5QcAbkw8EJoeycr2gbteAn7Wd6fYZ7jiksMTwnpmjf3wFOZIArgEGRPoWuuTII
cQsziuH7mh/QSaEZ7TY8QuQEC7UBxqCqB5rfMI5mmtV3gEUwY024mctHJfolwmeqCVVRBVAVjiSj
asqoisimHxHmYu1XZbGqSSYWJ5cTv5ERuARJBjSAk0DbfWtQIdjPLa7pBnPL0iO5HVDvjLeZP5Tb
AflgbpOsCDqwavtaKH2NsCYF6LcQZUSu3H+6mo5P1WytvsIRSAgHIOL1zSPGGqJIIJTrW5KWjap5
TGAFzdZrIeAlBHiJ5gaaUgMlnkh1QPNrAB0qBlF4IAVqpik3U/qgpJXiFEi65VZKQ8g6z1XltoKY
zKu67/kCeiybKD3c7Rlgbf71ayx7Fp7uuBJrjQwfeSimwQUqmlABRFtozW1n7hozx3+zXW+q7R00
2QzK1SH8q1tAGnAB31f4CkfJap5S0dfFfkkmOcDhUEWycLggB5S95byr1gj4QbqvfFg+XI9xDO22
Y7uuRZsw65UkF2Oqx9ivpDPGiDKYsqmJhb0Q9T6nmVeXF5P+3AkgEnzkuacI3+AxNkJOM7KaNZZh
Jki+YsIMdVyIWPEnmdWoij835ec7mUW2bplPG2R0C/UZ23MBTNtRvri6Mi3WK34uNut6JeQ7aqtG
XFTlE52FOgu891vo6PRx2VtT0YLihVqUTYm1jgUy+wtfKDqSbqXbgR/IHckRCBACLI0bGvQcoivG
7p6l81t+4ooZRFWGpWiVuDi9lsAhHThJ4i3irtPlFxyScRfD529snJd/ahDQwwqgQ+143xg+MgjM
BsugQPgg5RvszLlYmqvxAztRkRMrVmHhmhXFoKAJLgFY4Ii0oUpffYsFga6xGXFATMu+m75t9Z3Q
nj07u0l8hBuL9MjpHVD3xqOO3B46vgPy4eMbFsKjfDkJVSi4sMb/fI/VSHQAeC33VjjGF+rX8XRK
7TXWv4zVdPz36/El9dkU+VW/XqOou1RGYnYFLCOSmGoeQED7lYrLqN7f8Rth9/rSeS+aOOjn2ctt
USiAANoI2nXoO8fz1t3XvX6HRVYAdqLyyGvvdZ+ouxf6/vMJuA5eNu7WO2r+lUGAXXwyL4zjj3ob
9LPXZ+O42ykFy8fpT7WT4beXTeTyAMAr8Ni35fHsGvriham3FHKB5F9qeTE1xkoqShbcr6ifJM5A
8/GAZMAOpF4ATy0CzQV4LpcAvEqMeBrhSUQ1F8E1AK82av/vh25ksjTYt5izaGC4eM8qqCdON55H
Z8SjgdAcJp8ub2tETv8/auKv0JY+EjPJ0eCoM5iQwQSa6v957+MHWr0RL7AKY2H94BwxwghYBUKc
XAAc8/eUSFCB9L/fQvDmOm9vs9RBHqhz4wqjmC6YCfzWax6tuLu/R4of8/3S+ftlxPfLhC+Qrl3q
Gei4oo2v/fMfCf92fnX1djJ+fiw8lrTnWyaOLAZuhAhR4DlBpnrOCXo7UHc/ZVyUwtMvWIi3RSA+
8nu/quf+ygCM73rTL70w68XsAhkPXUkSiFUX49C6nz06akog6TSH6e0+rbVwq4wHaS1Lj9DaAXVv
HG6dnvQ6iPie7iHpIKWNQocMWiht2CKHE+Tg7BGjLeDqCXvO5Ju6GE/PP0yQ8QJqzHjG5OrydC8W
ER6SQYov0uFYDKl3xp2n8PCeuOfah+SD8XBF2ItH2laztoGZ/efk9WwWK6jUGxBnSSEUBGcBG2d5
znIbhHHuOo7yHJSReugGOIbHWUTfDUNyo5o1XGTrBkmI8lAsQF0yfPOvYDiyFcRzi71D5t0YzMwW
M5NqLxM4V9UTm8jZ+a0xeElRZ3A50egEeak+i/ajgdLM25sHuyCtQSyxPzWWRSrfluK3LDngfqU2
W1ETJ2XU1F/54umXPbqxa+qQVtOlwGrpagFeUGEjk9VhmI5sdzsQJAJ2UICBSrUMKWWGlEPqMEh4
9mMiSN1dDDGSCTrTyUx+ce/Yqpdsk+SKRZWIViRqgHNAgOsVFCrLN2uW+NmkCpnpufVK9YU8fcEn
Un3trSgS4E1imud4xpMT48mB8XifHtinasXza3FFbcqt3xExkaLdBRCEoN8RniP8B4LMar7eLhQx
sKLLLBmjfcB2RwnkExdOdLnkeZJb/qju+Vlzirkh8URVqieyJQvLO+VNSDO7K5u1OAwVkYeZ26+M
Hga4P4gBLm5jkQqtoLDe0tGv5uRaqn+joQ8J3VAyfWqwEauLssEd8T5jzwdTDpxDJRfDvG+sxAy3
s/WVFxKdFY2kGrAWImSUUguWasFiLTzQvOap2g4BgllA3NZDzxNkpglWg6rRuirn82rTVAtVyrKQ
It79lbH0i/WDxwlHk7Go4c/ThRty63nKely0l7LoD6YsTlpcsInPGfLyW74iYNIKeP7GQ3V2CrDm
+slLiNLnVLX4i3iFt4qaJkI68cEDFEW0UTbGX1kNC7eg85ATSpCywcP/+a5nYsfU1HtHExbqcwVV
k4Ij34zL8ByJMb9QJS/YBsiMjJtDm0Ec7ykv1Fmw1/JdURxp+SIdbvlD6p3xtqXnoBE/FYOP6SB3
GpKKZyw97tmhtVv5YfPfEb8+/1/X1a7bMAwDd3+F5g4BJVKPzNkKdPJYdCs6FM7Uob/fI2nTcjf7
cjrxJfnyU9NjNTNCaX0sOb1iGr9BxGz/pkzpLb1/UPpc8uimJK2r0nNhwjUmAWzLapyhUMehASUj
d5opQWi47PH+9bKoDSRUQIRdNxY5oLrw7b6MseWY9z44wZCuyZlyREw4NRYxvtZGcuASMcZszJsf
lCBQdVXhYgzu1VWly22MAFRVoWYcRKWyONgweRPnZFhGu7J6b/fg+J/yDIDJjPUW0TGCurc9IxkB
WK0A2SJPGXfytGI7f77nW9RpV0VT+KLqwEW1wv/MugclCGh12fMpA7npNOCrYfk0GK4SgFWq6CMg
FMgrhSs8z5xgoHT0r7Ms5tCncByYO8tSdZbP1gYnGNx9Kyj/AQcDJHMKZW5kc3RyZWFtDWVuZG9i
ag0xMTAgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDQ3MiAwIFIgDS9SZXNvdXJjZXMg
MTExIDAgUiANL0NvbnRlbnRzIDExMiAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9D
cm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTExMSAwIG9iag08
PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgNDg2IDAgUiAvVFQ0IDQ5
MSAwIFIgL1RUOCAzNDUgMCBSIC9UVDEwIDM0NiAwIFIgL1RUMTIgMzQ3IDAgUiA+PiANL0V4dEdT
dGF0ZSA8PCAvR1MxIDQ5NSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgNDg3IDAgUiA+PiAN
Pj4gDWVuZG9iag0xMTIgMCBvYmoNPDwgL0xlbmd0aCAzNDY5IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl
ID4+IA1zdHJlYW0NCkiJ3Fdtb9vIEf7uXzEfySJiyN3lm4H7ENvC1b2c7UZKUaApCkaiZfViSaXo
5HL/qP+y87YUJYuOrwHSuzoItbszOzvzzMvOnk1PXk6niYEEprcnSRLFDmL8J6Myxm+cQe7SqIDp
/cnL820Ksy2zxLCdnbz8fpLAYnsyQs7YpjCdndCosDD9dPK34Hy9ug1HRWSDdROO8sgF9/JThWVk
gtWshmm9DWmlFT6YbGqmzcKRjdJgqfuXs0o5lusVhEkclYEXHY6SKA+a0KIYmJxPb+IclOXRr58e
zn/l769k/0ut5kPCxkWiecyTdwHR0uDVRk0w6QsFwwhHHL8Lw79P/8S+isVXZVRm7AUeeE/ZIkpN
nJCvyA8uJ4+wc5JcXRKWwXrzuQkZyzDFAxd3Lf8CAmmiJPh3aErUB/4YuuBhcYcOEs+sb5lNmD+h
nEqk1DD5LDxCqu9xoyy8CMk1aEccewMKjbUiSrIiRwOmF6yrTTpdyQDSFeQvTExwODq6+C1HJvUG
afKgD22OKZChn0vnrTrigetVmEUZorZuPOL3oY0RcY5kGzSYFYhuE5qoCCrh3m74Z920UM15KN9G
vSPfOhyV3QTEu7IfLnntigIrCWRCh6AGxrEG6BB0HZ+5FQHVoj5w2gjDOS9TAyMTWZt3VuKKt9IY
sXIaEnMajDECsmASJhTIfhGuQoc/b/n7I595Nn4TctSdotaoVxKFicMthA9rMZ6eJLCEk8JFDgMk
KzPOgMgVMOJvU5/cfplaFB3VObTC9OmpySMzvP0L5N7ZuCRUY6mQPtp9jH42HUjqLLM43WW1yXyd
xa0M9hv0cYnOQ+9gVUSIrU4ajAis5RQFBbphVp/CRKrNOW8hh1h0/40scnTPm0pltCP5XdZce0k2
l1pd3qIIgzWESQs+oG2qVUcd4a0RzNqNLsR51P4sXOADX7T4gHUPw+1BBIrmgFEZGe95D22Od8Kw
W4X6hFsHt3vh8VN+G6AP+80hr/NeixPvNVPuUiRFOC7xAiy62WuECNMGTgFehey77XZNWJbBbFm1
SyoSBWd1gjW5rZr2gcebQ6zSmG/zAayE+gRWg9tZuCt3SB7DaoA+jFWCgWAIK2klcg9WplVz8vZM
Q5mAKvH30g9ejyl6bXAK16uakMJyt6ZKSE3BqAgAi1uKCPXXPJ+XwYuVLK6wIFmquMze34XFV1jm
sjjvy9pu/QCWK6y3SMFy60hTGvuTvDaUmTnK2G5V5kJkqpDo0J0mw6t90J1CfcKdg9u98M7Zx9w5
QB90Z1piJ9PVq86ZsfaFN9INvQ0Nlq7cT68n41OYruFjWDAOMWZFs7z9HBoaAdegLLhjatXCUuZc
qxDW9q7Gi7PC/+uVCKAL9j40idysVm5WqlBMpmJjg43cqHO6RzOtaVbPljGLbOpZvezrNUcf8xQu
rzgQbeDP8pvRjf6UaqEa7dkgtdlivJGrY8DamqRZ5i9V07XTcSqwsWEpGcZGGzJaVlhSyqdhZMEl
I4rh3VmWKA1ma1bTBu+1wVaZc1+SP4V4IxRY1i0ewPoWgZwCezPs+qh6F3qHmMCfKQetRfwD8zZ0
b+BdUAPjLUc+CMe+OnUDS9X0Qa2ZQ6Ur3lqYq02qkNqgxVFSWBRGZwsnnduD2bkOZscoC8AKF5kh
30dZiBE8lIJIeiL/jm8UmWaXmvjSwjQ62HqcPpx8jtsTn322C6O8l30FNw1ZMKbbWX3osFvjDnQS
Ou3W+EFyzpzXVxeXfV6sagYXhfeULivLuI0k2ujC4iDI9d5a+a50VCoZZEm5Wqhlua3ef1AulnWn
vS2l+RzeUzNSYpgayq9aQj8PVHotv/PNernSJ4ntHjaqIhXx3p45nEVe+0aqg+V2xp8JfKBqAfOq
rSj5j+as2zXCiTbCqBHnKqmEUJWBzlue9FRLKWK3D0Kd3fkMJ2cRBjytdNdahew/IoyVJ0RBhe7y
hrJf2DD/YkqlLXca8q3lluMx17j+8r6OS9FBF7HihZSqXPao6gCfzG8PL1y+lSwtVFeWHMH4aUDO
QFZVs8ubj0LOxDKYVRuMD2apD7IzTbMn2kOlDufo8HYvvGv/rCPOR7uP0YfTFMGTlud4tR//VSsq
J6X0yrtqO76AH8eUey6Q7yup29+PQea6689vx1f86rIqADtLhm36Bz7N2i5i/e2MDio1h0J6OZSc
Rq4fq47SqPdH74bh0W74XL5nMnaa8s+humfP0Y6xsFhmLHog9nmclN4bSSKgALx9Le+YG94y8nsO
KoDdVYBYK8A7RJ5eVx/WW/ZAHVKNnb8LnwnfNxsNKuqLHWYO1zVtUIouZI0HCagfIpxSjNSjJdIW
O4AKD9CU6q4vH05ua0el5ZU0y/5edsoA38HPzP+Cmy0fmZ+plyj94i9w08n5Dio1w8d9slMj2Wn/
v3fCF0YKrxQCg2n4D05Hx65zwQ/HXdXrcoLz6+sfLsfh9J9HWs4u7H+DmAxWETGI+hiEg9EwiAa+
vAqFQ11+PF5/I9YdG5FLtZM2eL2X3C2XvnU23L9Ip54Gs677tboObze9YEio0A89LC708vCXi06x
IHQvCUo47ql1Qft77OZ3qfX7iqdjo0kXPnip75Jp/8XwX+LH79jsSwAeuOp3BuAwfv2ocJ1RWR+/
XPGzgU47/HLC7xfQ8RoD0e0D5zP8/wCuXjuLl1n38Hvczgr1iXZ2cLsXjreCUI2lnvTx9qMMgw2t
KRIUTcjfd+/NWfcGJW+Qf1PqTA3e0hOyPdc1uBhPzt+Qt0v07VQ4Lq+vTg8wMWUyBAiRhtEY2Cgy
4x1QCYN2sPU4fRiIrNwDIttdvklEF+/L6dQBkm+RnKel9p3Eha2M0Auhkw8Ks2tM3a5t8Z0pt0iO
n0+FfvktVuJlwZ3Chl4CpZJAftay1ns7EuCV7PuJ9iX8YMNA1cWVLEJFHVgeyFfFzJYstBLZMlmv
4DZM+DFKr0/DvM6fBPWeVH0LFn6uuu4eHGThger103vPInwIZWqEZ9Wt/IJ1/gWb8QvW8IOSlepb
qNYv9iCZrffOqpZUmLpT9me6E/yWGtbN43uFPeqsT5hcE+aeciRlk+npgUgWEdk0ykiNS5neELBo
zkenbOQyYpjrfH50+3brB9Fzb+83XKfq2bqZQ3uHZRgh64VQgnjhmwGRG6WoNT0i0qBa7PPJKrH9
60Eo7ISEuxYMpRoehGW5kp1QgS6Q+i5YCGP1AfxOaoqyQKR9QM9mGInrRqxCm4o4N4e29VLSfGVK
mqyDyQlM56huGRA+CPaMlXSYVDTthbRFntOQrjtq6uXqSzgUib3WbWS60W+lawuRjK8cvBiXQoNq
Nqs3bT1/rtn2m5p9RiGRHLGX23br8TgXth9CTlNvmvx4RFYssRVJVUuJxSeCtL9pcCsiJUKJ0DbV
3l6RR49MqORlucNYUNWDm3pWLz/20J7DUkT0TXgu4u4rEbd292S1HnJqJe8w/q1ATkr+xFMQ2mno
uqC7bpUzJCyaXeYmsa5tt+xDzFnhE4GyyOWcagg+SXgLePqKuakOy6ilM8+gamqQrSK8R0S3tZjN
XnOgiz+jqt35o/Snqg92erMPSh9GUrqTA13VDF1b9HY/dlavs+85K/3a9Oian56vODlynxyWkwNT
+OIUryonlZnXV7w+pxcCmnnBZnDNcNIiyxA40B27RB4UfE1SNURiXc3kNJAe2vXAtcF/Sq+a3rZh
GHrPr9AxHdDO1pfls28bdspx2CFdMnTD2gZosGD/fnwkJUte3A3oJbHJJ5J+okhRfiWbB+6l7JG3
EE9nbpBVtQJzt3yspusfcRax7ixnJcMU9VtQyIlcqcw+f+fV9hNK+xmtMIjgRzrgJ/RSVIgDGbnc
WOzud/ogVIVbUPAgaly0KXrcstG3po83gf7WjytvfHzrxq91Tep4pyPoyY1zf//8Sx/PR2lxZ+5e
5uteO9vcLPNWXGRieLjSOqUSjnzDWHRlHjbp8B41GexWPEeRz5kRKpfyxFt2ytqjuDj/b80b3spm
Kmzamc2ey/FY8ZlmPlPh0zOfofApNd7r4obRfqtWFPjEb+b+Wa0rb24rHjx4Q9MV3GGhjlmdafWN
Z3muifVCLN3f5Uim0mBwLb1bDkHDuDoEkeqVIej6QrGZqiHHxqW+D3YeB/9ava5FUKp9La4V5xmw
Yv8f6vfTSzDTjge0zuymTW8+UJr9ICAl7cX0nflkPn/pzGHTJ8xuNEAOPOg+blxHJlMR/NzsSETp
DkyMpGIM3Tt9hSmIwdGHk+DbuxnkPWbER3JFfbkrAliGiNd5OlyWMRpOxswIOmpWLPcJSpLZQB44
ngFzYRZIzPFuYAy1CI4ZA0WsMDNiBHFqWUNEGY28Kop7ETQxU9NpY86YguhSidlbz7JgsSS/2dFR
DITwVKiZLCJygGMf6CClIoBjiODHjWQekNipG4VkgO/oE+dNgBk3pCpSvAlJo7573Xz9XAEUdcLu
trvqYpBAM2UqqBlycUS+VX4zZkb04LBwbyEL1DZjlYkqqDPReerrVSIWSAEE6njtnjpHjDaLRNBE
7CiGOuAMKQAkS7arGLqGhah2mWsRNAT3dDGo+c2QAsDZX8SL7Il1vCJo4kUhbwLOmILoPGoPW/4D
PnC0xAplbmRzdHJlYW0NZW5kb2JqDTExMyAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQg
NDcyIDAgUiANL1Jlc291cmNlcyAxMTQgMCBSIA0vQ29udGVudHMgMTE1IDAgUiANL01lZGlhQm94
IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+
IA1lbmRvYmoNMTE0IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwg
L1RUMiA0ODYgMCBSIC9UVDQgNDkxIDAgUiAvVFQ4IDM0NSAwIFIgL1RUMTAgMzQ2IDAgUiAvVFQx
MiAzNDcgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgNDk1IDAgUiA+PiANL0NvbG9yU3BhY2Ug
PDwgL0NzNSA0ODcgMCBSID4+IA0+PiANZW5kb2JqDTExNSAwIG9iag08PCAvTGVuZ3RoIDM1NjUg
L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSInUF9ty2zb23V+BR2AnZAjw7pk82I6m
63VqeyNmpzPNPjASbWsTi1qKTpr+0f7lnhskShZdt5npNM5EBHAuODj3c1odvawq65RV1c2RtWGU
qAj+8aqM4DfKVJ6kYaGq+6OXZ+tUzdaEEqn17OjlD1OrbtdHAWBGcaqq2RGuilhVX45+1mft8sYE
RRjrtjNBHib6nj+1KUOnl7NGVc3a4EnPeGq6agg2M0Ecpnoh9ItZLRiLdqmMjcJSe9YmsGGuOxMD
GzU9q66jXAnKo6/f7u9/5/d3ov+rkecrS48LWfKINu81wlJ9spInuPSFKMMxRhS9N+bf1T/IVhHb
qgzLjKxAC2+puAhTF1m0FdohydEiZBybi0lMqdvV186QLk0KF97e9fRVoEgXWv0/40qQR/3dJPrh
9g4MxJZpbwiNkb8An5q5NGr6lXEY1NwDIR+8MGgaeEcU+QcU4mtFaLMihwdUr0nW2G5kxQegrIr/
jHV6f3Xw8M9cucw/SIIHLFbmaakysHOZ4KvoLa7wQZEW/KorNK7VSxOgbzQmSFBFLZ4W4MW8FVPc
G0cOPgB5gkr2NUOF3RoILbjMire7pD06mtVKSObzXZbrNSxsBpC1WizV+SXs0jDT51XAhCdycHbB
T9hKaQdP8SKsTQSs5K5b/niUcM8bgjK0JagqcGEc54n3idRtfMI51l4F3CPwzgl4VqanxmKA+EN1
aRL4vKPfH42DG08nbw158zH4JoSiDY1NgAQEdyTEpDqyaqGOiiRMwPGyMqPIChOQhn675ujmt6FF
sYEmCbzCDeGpy0M3Tv4b4MHdcMRQF2OCfkR9CH5ajSSLLIthu80WLvOuCqSk7LcmI7tGYLMbNHIs
m64hIyfgdgWYYdYcqylnsTMiQYPE4BnXfEhRM+9q4dEH/F00lNORN6VwOV4DCwe5iUC3dEHf1csN
NIBqpGf9Sg6iPOx/YSzlPZKl+AT5NNb1AzNkyVUS2q3lvWpzqDXjZmXoE2YdJffMo6fsNgIft1sC
uIm3WmS91Vy5DRGKWyisxWb3BlQEYaOOlToxZLv1ukVdlnq2qPsFllFMIxkG9rSvu/6B1qt9XaUR
dQkjumLoE7oaJSfmSbnVpIOMsUd8GDyuKXinzVBTlEMSrymphdN3p+TGOSmphO+5X7yZoOdm+lhd
LRvWEqZoG2EupXJ4j3mk0DuHHtNzkeOaj5cGkuKK8HeoeiUIczqd7zKjrEwLSsoMu+Q8Kjt/XXBy
Ju+5kCJx35BV1+uavreeVbhvVAexMR4ADH3CqKPknrl7KgBG4KNmTQswzSYAthU2khpBWSeGMoCp
4K3JfSKK9dV0cqyqVn02XI2wbHWLm6/GUZ9G6SjVdwSte7XgPaUtyGL9XdM1qob/7ZIZqLYDR3BY
ilpsWB1kRoXJisCYdxK9ajuwMBTbhvf8y3fzmlh2zaxZDOWag71pC5WY/NLBYcCinKDzYZrDt12Q
22yLMZY7zz7A0Odb6lthjqaPFGRcm2aZL7WPk39/R0m14RRP3p8CZ97CyyWZK8nhgi25Vp371L95
uZPErmYtqSzRH1Blic/0wnjuH/LFuAxgMfWVgyv2Lny68PCVLV/0QBQdFxuYPVa0FyAYiSV44P2u
jE2nFiK+iMfM5LlzVQt0T7i5PL2nd+y8FHPucmCMJNkYI9m27WILk3A6QY2Dd4G9cWzKyLkI5vWc
k1D4ux/jaQnhNpq4BToe4+PkzDzbZgAYFyFa96gPw8djPIEyvQlxt3HOYhDiJTUoUNQC8Hlve2wN
A7Tc1GCI+EN1RqhXl6/Pd5AhhaI1ry4Z/RiLI55D6LDLppzkY+w5FmyzAg0NtoSmVRAUHwperxo+
7usPnxbC6Y4wMC5jCO0P2PqU5OV0XcMNVaGFe8Pf+apd8Ko3jgZPdj4REgvHgGquTkMvf8dJyFED
5e9VcqnIouZ1X2OWOZgRkm3zbSWxNuh5IhaoC0sa7XvaDIRLKfYeGDq746+S+UO2tVC1woSS6d7c
g2/rMJmgezMaBYHV5OqF5t8GlBPLmpLp8HhXxgXLIIc45JAXVKTIFPOrBTR5Agw6pOb9OYdu4zsg
q7L0qFkvz6PQg6anGI08Aj4ReGPEnjOQMTROsDt6RHwIPh53USYtEwVeugm8lF1g8tM1d0YUZdxp
FxJNTk9eqx8nGEkcfgk7aqF/mCjeC9U/300uaWaLhQH0paSz6m90WxxvfC+K5eIlxG0srqd5AzYd
el2C1WHwh1PH+Gq7fC7eMxE3ktJnX9zT50hHuojBEjFYIPIRaUtvDSt1Qal3b7gMXxNJ4Gn2Ckq8
jWXfJL2n7iHVn9o1WaAxFoV+b56pvj9tNSro4bRFnhN59fy1njK6eh4iewXkxNJmW6943Lk9jx+F
ZqmHrZm0QljnGvEnue17VzK00BgnOOmJ10C6tZhm5EHUcv2sN612zKVA8kpOPohz1eFSud+vvddV
d7hNo8oC7rvXrKlX6hdEf2HsJqPBVIIfOvpVXW9YvKp3fH8Q5m6TICL7HRnn7Orq4nxyWLWsW3E1
QQxIhQE6K5VqS/ahAe9iWEW+M3Wgi0kM8hiXye8DH2E/V9JElOkZd35WS0MKnc271c7bH1Xu11KL
fa2WLeTXcynp5IQ48Co5IFlSHI1eqYHT7YXO95YLphTSMXZ3h6Poj6kOwjXC1dO62/Xu78xDZTU9
YVfdDbZk85RsqLVctBZr2W60hqkMExuvW/C8ZFddvhn8KznYdvlsBxvMAZC48mx0EGDoE5PAKLln
7vyg4GLs5x+TH0QYHQZcjheia/I4EOXexk66crRtil09TqdTLpV8pl5Ppmdv0dIl2LVijPOry+M9
nbgCpErGdCLQcZ2MkzPzZKsxHPDcPvVh+LhGsnhHI9nGN7UNTfWfo5dVlSgA3wA4T0tp0xAL6jrD
C4Zb4Fi4bR+XpNsuQvIONQsFzA0pDbCpnzNTHEUt7FY4TqUCUvxp+Ww7tDoMvprpPmIXlNIIC6lK
Dpd8qOo1xKDV/CtsZgtiWjNv3rRLdQOeDqvORHJjTNWKrlLNDlua2JBM9iLs6Z64zdPooorQELJ/
3BTa1kRe4+mF3/mlwRxN7RyqKmCJhQ+EJmXwjZIIhxkNtSAaut1R26zdkU1wdqRemABnleXtSMO4
nceszGPME2RQbadQk6yZQneNOr/+zMCEj1Tt+8dC8y9KFss6fLoHeku5u5m13Vz1d9Q7NANnwWYK
RizgFaTwEBwMUl3f7uLxKaL994Eh0o5wLzJr1AOjLJZMqWolBybAPH/LiPUn5Sl9q4PHn6jHqfu2
47fgo6Pc7WtxEHzuG4MP8qJXk9gDS5zVqB/Q7kyc6CNtvRYozVt9bGJ2OBkdSvQ1dIITg1jM6ILW
Wz2XpL+IBjBQdEYqTVjRcKEiPaVyqurZrFn1zfy56oi/VR1uo47CqwOth+pwXh0FqQNDmV3l2ODb
FWNSp46vKMldMObUuln2qu4Vdazk6TeghxITF6EJd9XD7LTGkUn8fN2sIS3PmsVnRgC1wQSlFszG
Kx6NEBA/ajRSHAlQrAtKGc/VXPKNmou3syCOLt6Tcngc1kFSHbaJH2mrGHZskoFzXPWCS4J3gxwV
wYdP1xDq6CyMxyzxCBMzRlNnAvStVoiUx1kSBeZYXvV886mqIc0gA2a/AwSL9dijlf4NCqt6hv2b
z0N8t9hoK/v/Wa+WHqdhIHzPr/AxyyH4HZsbKickLvSIOGRpEUK72woqKv498/Ar2aZdablU9czn
8cznsb+Y9ojqLIcD322U4Xv+WGAC8HSM/e1Kn+9i893e7KJ7bf/70v+29n+kDvW5/y31P+jBh3di
u0+mJzLt8OMfyt5Npwm3BBv2F97dI93qjhRcI17spxyNg+OhIDxfzj7RPZJAM90eup5/B9xmy2du
LbsUZkrW051pgyfrX8ZiF+S7RkypFpHXPB6SBZznO+35Mh97iHVJ5RQqTvlyh49iKniD+25hx3FD
b5/K3r92K9cEEMTruMfezho43R/+pL+nPavViYRIfJuSSFXdy716xnJ0/+OCCvI9F1nR5wJLj0PF
0o57q3te2bO9brRrluR/tEfH7N3zEqeXXm/jf9fJzyRvLGWVz1D5DIVPbj5X+NRJ3njyjNGivAn4
xMJ7f0jRE2+m5xUs8gZSMDFut3D77M602tnKWWQrsZaJhU9vVplwWd4pUZAZC0YW+GH5uhnNtdcN
e6+8blanc3DdvF60X/qV9fXB92z2uhdTS95rqa0sngEr8W+4325+O7HZ0stLiu2mU+IjtOJPAEJj
n4WS4pP48lWKXWc1pGrxXeuRpMdi0CGIh05FGMFC1jvwGakHa3n00G3B66C1cRzwfffYqQB5FUB1
w1HyYPj+ptORqbEmDrqdQWMMighPFscZlVUTpACsgfActuSpxsG3c2g8yxXuDjfLNUEKQOHrNIXN
GOmQXI4rQzFgYCMVEQbtMDhNmMj5ZUxFROwDikyrgs0Qb9ZBiwYeYUwcS/JqLBEAXlIIBlR3BGsO
KJmB0RGxiKEsaExBleICx4jbARBpuLoEqQA1mAUDJqhCLBLA47Z+M2JFTf0ZUgAB+LCLsE7WScQA
Gzhw5CqhyT2RDz0abIMpCGeZ6aYTjIEnUjuJxm0nGDyWbSdkSAEYi60yT1jTieO4NhQDJUxnCE10
3gEDZ0naBlMQBr7N9CJh6LtZlTSeJQw9M84STpACAD5iSrjsgpc4Iy8Co1lIb+YnlwHF7Xw5uf8E
GAAV/wjHCmVuZHN0cmVhbQ1lbmRvYmoNMTE2IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVu
dCA0NzMgMCBSIA0vUmVzb3VyY2VzIDExNyAwIFIgDS9Db250ZW50cyAxMTggMCBSIA0vTWVkaWFC
b3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCAN
Pj4gDWVuZG9iag0xMTcgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8
PCAvVFQyIDQ4NiAwIFIgL1RUNCA0OTEgMCBSIC9UVDggMzQ1IDAgUiAvVFQxMCAzNDYgMCBSIC9U
VDEyIDM0NyAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA0OTUgMCBSID4+IA0vQ29sb3JTcGFj
ZSA8PCAvQ3M1IDQ4NyAwIFIgPj4gDT4+IA1lbmRvYmoNMTE4IDAgb2JqDTw8IC9MZW5ndGggNDEx
MCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIidRX227jyBF991f0YzMYcdjNu4E8
jG1ho+ys7Yw0QYBMEHAkSmJii16Jinf2j/KXqVuTlCxqvAmy2LEBin2pYvWpqlPVV7OLt7OZscqo
2fLCGD+IVAD//JYH8AwSlUaxn6nZ48Xb612s5jvaEqjd/OLtd1OjVruLEewMwljN5hf4loVq9nzx
V31db5beKPNDXW+9UepH+pF/Ci/3rd7MSzUrdx7ONLxPTZ9KWpt7o9CPdSXy1byQHVW9UZ4J/Fw7
1d7I+KneeiGoUdPr2X2QKtny4tcNj8e/8PcXbv9zKcdXhg7ns+UBDT5pXIv1uyc5go3fCBiWdwTB
J8/72+yP5KuAfZX7eUJeoBfnqTDzYxsY9BX6IUrRI+Qck4pLvFzXT1+2HmHpxfDB1bqhXwVAWt/o
f3s2B3vUH7xI71drcBB7pl7SNt78DHoK1lKq6Rfew0vlIwjyxBsPXQPnCAJ3gExiLfNNkqVwgNkN
2Rqa1lY8ANqq+M8zVh+/nZz8Nd9s6g4kyTMykZ+EWaIScHQeuWOZ0CWF88DEiyAm7r2RRVSLxWIL
COMUP9VyixGd+BkkiwE3PMPIgD/WEB1Wl9tSNetSsZZbL/AT0AgBZPQM0E+0mh+Il94It4juCpYC
N9jUjao284f9oiTPp3oB4572Axtly6GpVfmwUPWytYYt5dHsyOOYzyG4FnWGaQtQbFu/W8sIzdBK
0DOG6En01DOYBG5S3YL2WH+k5w+ehYNejT94FLGXgACYZXwPnGE1GBySEePZhVGVusgiPwILkjyh
7PGjTI3ouS0vll9fzbJ2NYpAt+2vxzb17bD4V5Z734YpXrUhkvAL6VPrV7MBQkiSEIYdI9jEhSOI
EtgfPDAIwiQA5y6Rr0IZkMsN5PMGUjnR8/JSTZmprkkEHRJC2N3zJGXGYluIjmbEv1VJvI26iaZl
egcqLPAPLa3oA8222LSrI6g4et48yUSQ+s1PvEs5mmIrHiArQl3sWSFbriLf+NZ53kGbQvwNu5VX
z7h1UNwpD875bWB92G8R7I2c1wLjvGbzLkViSv0UgHKj9wARpI26VOqdR77b7WrEMtfzqmgqZIYM
/JkAfGraFNtmT+9Px1jFAXUCA1jx6hmsBsVJeZR3SJ7CamB9GCtgu9y2EZ62ES5dyPTjFWDA8QqA
QUBFMniPIBngmRGW6Us1uXd8nEiMAvstWWKL8Zvo+tGzyHHqec1U7GEEA2PeTlgn8K9swWDMnBYK
9cSNNiRVY48DqeIWeXb+wKM9jRa8p0RqponeJ++lqRi0uaKGgjmaZ9jOI2/bBLqGQW/z6hlvD4o7
5W0snPL2wPqgt+McztQ6u62ugVRXwiSD8oDOQm5L3NTddHypZrX6FzctHjm1Wn7xLAEDNJXrNa0V
5JGc6FBTPURuoqUdVZinets41GMqh1R3aD/EiaWeNKYSbDHAHGU9e8CYCXwFfJrqNn7CXvygKRJB
RowU7WSSvLMxNesRa3kOoyen2Ak5dtI2dkLd+9w9BUGgIKhNnCRnurA2ulLNT46ujKIr60VXpt0p
LPYh8K0cz7ChH7Xc0+/WTYODrN46ZB5hMpNJYv9QPlasZPuIWmmxoMMTogzxtLBWzVk1d0Axg58P
iIrFlNUWsxq/72wuRKShE3KiUZrxEVjmEJMCnOlgeqr5zAtA/tnD9OBKZ7Xod0a8Y/uBnqB31Hfg
OZD+QPchB6N/nKzAakOZCktn0vS0IOu0XQaHEbLvkejp9eEcjTPc+7Uk5fQcY43XLvjHCG4ITV8k
PR9lxDXtvLu9mfT3TjDV7m557yWWvJAodoQ1jTNFUoSrnyTBmUSSfG6Kzw+yi3Ste5SxUJ9L4grw
bIzZxW1SKvmnSv5dPNWSdBBEfYejiao4kFmoK99Zv3VMs+p9s09OpVoUTYEZjYEx+x1f9Lq0NZK2
YAfEsCFDACAs+zRuaNAziK5+uz2vQgrRL34RnK9lWIhULUpKVfdS11pGGrNtW0oV5Y1bLK2UKynl
Cj5LaNqtvFPe9KcPrazYCpkEeqGCRhyD/K7k2yVmTq77Hyl4aiX2km71eX+g/fQZuyag04aUZ5gu
AqYL+m6Ph2LmIYSA4Z6zAR2eOLl25vR8Z6M2PRJ23aNQHl53MAKRY5AIMyzm3CwQnTmmAwOJ66Sh
hlLAe1Xll/5B7UkpiKAxmAuCa9lI2hqW5jmsThTB0cFnciFro92c7BGpYlFu34g+XqHkSlyXk8t+
7nK4UkVcqRKoVL56z8TMp2+kyUm7JocPXr38qlQh0+txBOEgbtvnGBHW1U797Huzf/R4NU7SM7c+
WR1m12Fxp7y9tsXpSelT68MEGwS9Jqg9XhBzAI3/QqglzKZ8VcqENq0e36gfxkiakeYnUU+mvxsr
HovUnz6Ob6kQhqIALhZ9WMOw6xWk1R5j4QuFczQPIPIPCx64r/eH18bht+71tfteubG1lH6Ozb16
jXWERQj1IQQPBK6DMrnzhmNipT6+52ssN10jJ4MoR1HXe9kOT8uinwD5FPLgod6RB7BBAqM/ea+E
71d7GzTUtZmQOAYDho9qszZkrQNJYd4iTnhVO92cngIICSJBLqbYirXrVvnmBXz+e/UTONbqNx5S
t4vEL0iYUJhFusYWEvi9ge2FWA1hftAI/9YwP/kmGGZtA/l3aTKvqa38vuePwFiHbMA1iMjx+u7u
+8kY2fGFA166jfFPEUnEOaPWAgyRSeJ+K7DCPCAN4ILW+DVJ/f954/ONONIIHCRI6MBzQQf8/pt3
NnrTOHixHsfy3PPUhlyBN7RYz7H3pWIdyrz6+DSQly9KyY0UB1c8ZOj8nji/x5RKOEFGxYepFBxz
nW1Z8hvJrilFiqU0sl0aHeXHfwVfx0gBTpyH8chf3xiMr0PxRUPMKKaCYqhl6FBMEcWflbxLv4nA
eQRsn9C/RdAEsyvkqEzffSDsuET2+lcTDDavsHSmcz0tSDoDYBQrqzbE3vNIdmjDYONqU4c7965B
2rbm0kKij2NsQbFYTPHoqcypm/H0+gO6PIdKNuMdk7vbyyMobJp33fQLNGR1GJBhcVEuS3B/grMf
i75cHMYizg6wSLoabOh28nY2ixQsL2E5jXPpMXEXFFlez3jdgMbMdk1oZNpOyXWh7/iOyvdQfpZ8
RX3khuGJb6+8JPfVmuccRcm1t2C5f3pymbXYV8nkhidVsfMwGfkpauYVKS1YNw/qjYJrm8Heyxth
g4Z7I/clVR5o5XsF7JWx2NpdLvCER6aX52WvfLj0JHIIt1VEJ7dQPyM9wfAzSM1ilRjVP6GcfnUA
ybw++FZRIUG1XzkciaRyIqWqt68tMo/cy7qKUarCNcFG87P0sLTwu/pMvUACrQKW7UZt6FekG4Bv
hD3CmmZL1RaqF0rRceixLcIFgIsZzh3PXOrWrLcEsxqnsw0n7MudbaOYMEXNxapUlXxkXou5or5i
8zYr0uWrCZt/bLZY2hSfHyrRLUv0uYWSdQ+rctGUygFFqatZ6eJ82bgRZuZWO9MydMcjeBKGJ9J8
DMvHgIrFuNoerrHmpzov+LxusczRP7cT933ASjbB9UuU+V1Ly4WjnNfbRSfeZXYnB2g5W4rV4T6e
xW0/7nmFADMEGGR4qfa8pdqwpCqUTKB/Ir3ijcWDcpIYBRyMuX7wsHQXTb1luzGwgtQep0CPKe3/
yJQ2ab0asVevvUSCBWhhTkZGwHX/4b3aeho3ovB7fsU84iqkc7Mz5m0JkXaLSqTQqg/VPriJIelm
A4qt5e/33GY8pixlhVSB7Pjc5sy5zTf4mU0aBzIXBYKRmAGH1Upx9BIVT+Gy8myEds+WoQwhmXvm
qWazaR/7dvvvbWegOdu2+1+3fYklYV7YL92iXIzHgsWuC5qecWv8ihE5ksWeLTU9zjtaUXGZl9w1
wOvFFdWfmpEu23t8AICXWifGmKMqC5/aTbv/lkV7q/ZsIt/CWwvNvzPiCNrlSNYuhhwH6w7q33HI
0ckv9KmYd1H4VHSrXiQLjMVp6FyjhdZ1lEPoWZZjg0ykU5ZGCg5qUFGRfyRpPB75V49rXqrmxDOx
FuMZs+FDInpOo6zC+ZPyUcdVJQeD35SDOpYRn6jmma+yDaHdZ9pvTVb53vYwqT3qoT08tYeJ7VFT
e0DTX12o21ZIRyJt8dCD7V/JHqhBvNxfqvhJACHQKWQFH9SECALDA/q45zUwxhxh+j4h+oV674qS
woZPSHHNOMoKjqJDU2cA7okX3rF7+7iPnawRu4Khjqbca2ouyK+TZRr2qH1msxFb4gu/xlHhbc4U
zYkqBVOi2POGmQoltod/JnUvAyFfDiBXkNB2X5SkgDY2zWnbblVDiAoOc4W1iYzHh0gC9lMB4B1i
QYo9F/KO2YoQZcCbF7zd2apAQLMuEGcwJrRvrsjqnRWpE/qwgj7W7SPP2xb7ccetqpq/mPjAr29C
7tuuV5tGZl6XJ89S0Cs5yx2d5dS7YqIvDCUrSuSjZ06z9ZxAw5xAg2fQkJtjojrsv4gzor5Yra4/
Ladqueaor1dSLeupuv34O0YYYfPV6g80bs5upi/XgbExNCZwaJJ2ydpo/eb8A+61xFMK8cj1VH1c
ipBw1gUeQFHzkuWWwozkKaNdUP4RrXOCNx8W1zxXW0FsR4JkfWHGPWoJL/Ft7JyuAzsSVONPnryM
smDiYLC2xDhhf0NhdB1O2xc15R312vyyIZCDOsuFGNxKgnt3wjWpwqzh62OZOY9lsMO+pfslDgGR
ly8o1fjrEzNu0IXyTL4wYjXWC9nFQM3BVNc18us+am/4PXJDeN1MDqSE19CrA7WxOTtgZaN/dwUN
aXKIV+EraFwhlnm0OvKBFRRveB9NH/B2le1djTffPTJXHDjSPXE70pCvrBoQHu85o72ss+ML5mh7
l3J1Wa1jCHk2LX+bBD/zcGmx1Xzmg9L4OKfnqZ3cITeExPXezpzN+SUMSPuquhgXlvGwuB0xjXlN
9ftc9Eu4r/r1wsqR+x3j/8H+edGVanEL8xf/bhcTo36Bwfw3CMKYf1JGq1/Vn5+12k5MgO7wRvky
4OJfJ07bmQ6JcJjcAglmBslApVckA1n1mUySqGCbFRDufhqEnGMtE2DgaiZ4T5aRRHoO9kEi4k0U
SQIWjLFdA5GtKyDBaDLs8RynZySwx9VsTjIwNchjnGNVJjNIwPmZLIuDWss+TcWrA+G5x9pzvJLL
rDS47OoKo02WvfVEK3VAQ18TwYI2yqAbFSlpDCAIlG5mAxMsL40kXMkFuCAElKm0rCQySaL2kMMh
DWSoqrA+BoeFwOGqhWSlCGTjSSZJzDXW8SjBDsrC5QlGgh2Hy0Gl5NFKIoMAhHhIg0WSqzE1Q0ki
IfhRSToHECdkJZlkkoQHRBjGCXYwc+c212LCyGNbol7mcpRJEjhEk2URgiFmYotQ2A1ioXGUsV5D
HuUokyQQOjzz2WI55c2HhOpZlLXmfUV3RGnw2dZ2Vkv+/hkA4TMZXAplbmRzdHJlYW0NZW5kb2Jq
DTExOSAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgNDczIDAgUiANL1Jlc291cmNlcyAx
MjAgMCBSIA0vQ29udGVudHMgMTIxIDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Ny
b3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMTIwIDAgb2JqDTw8
IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiA0ODYgMCBSIC9UVDQgNDkx
IDAgUiAvVFQ4IDM0NSAwIFIgL1RUMTAgMzQ2IDAgUiAvVFQxMiAzNDcgMCBSID4+IA0vRXh0R1N0
YXRlIDw8IC9HUzEgNDk1IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSA0ODcgMCBSID4+IA0+
PiANZW5kb2JqDTEyMSAwIG9iag08PCAvTGVuZ3RoIDQyNzQgL0ZpbHRlciAvRmxhdGVEZWNvZGUg
Pj4gDXN0cmVhbQ0KSIncV21v28gR/u5fsR93i4jhLt8N9IPtCFc3OduNlKLApR8YibbY2qJL0efL
/aP+y87bkpQsJjmgODR1EJHcmZ2dnZdnZs6XJ6+XS+uUVcvbE2uDMFYh/OO3IoTfMFVZnAS5Wj6c
vL7YJWq1I5ZQ7VYnr39YWHW3O5kBZxglark6wbc8Usvnk5/0RbO9NbM8iHTTmlkWxPqBH6UpAqe3
q0otq53BlY751OKxItrKzKIg0bXsr1elcNTNVhkbBoX2os3MBpluTQRi1OJieRNmSlhePP3n4fdv
fP5G9r9Wcn1l6XIBax7Sx0eNtESfPcoVXPJKjOGYIww/GvP35Z/JVyH7qgiKlLxAL95TUR4kLrTo
K/RDnKFHyDk2E5eYQjePn1tDtjQJHHi36eipwJAusPrfxhWgj/qTifXT3QYcxJ5pbomNmZ9BTslS
KrX4zDxMqh5gIy+8MugauEcY+gvkEmt5YNM8gwss35Cuke11xQugror/jHX68O3o4u/55nJ/IUme
mc0CF8a5StMgirLI38vGPitsyte6NIm+MTMHnlXlet2CgRON/9Vti8GcgskejE3AFeoZvi3YdAOh
AZZuK9VtKoUSrkwIfJcQO3oJZs/07OzirVodCKgMWFSk12YGwcLv26ZT9XZ1/7SuyOupXsN3L3xP
PWEYtKyr+7VqbkUNVhDfBz0OnA06FGlUKBA6Nk3iepc7x7ZZgjhUeA6Bk+qFsRj/flFdmRgeH+j3
R+OCXJ/P3xsK1lM4GzLNBsbGsAU0jkmJ+fLEqlqd5HEQQ1yleRIkkDgBOGpGv211cvt1ap731DiG
W7gxPXHo+sntXyGPzg5zoboI8ffF7mP08+UEFqQJ2CAewMClPhBhKxn7vUnBZhUF0i1CVSQf5HP0
6hayONWr6lQtGKQuaAs6JILouuFFSop1W4qMbsbPuiLIRtmE0LK8AxEOoIdId3RA15bbnjqDYqNX
3aMshFnQ/cJcyiMUa3FPOVE+sUDWXMWBDZz3vDdt6qiwTbiVqV9w6+R2Fm4Hrx7z2wR92m8uDwrn
vRZa7zVXDCmSgDkuoW7m/dc7MBGkjTpV6syQ73a7Bm1Z6FVddjXiQg7+TBFVFl3Zdk/0/nhoKyoh
k7Zi6hdsNbndC+8tCdc8svkIedJSSVEEadzHd9bHt7Qfiw/nYAGOVjAXhFMsH+/QRBZQBpFJn6rL
G4/EqUQoFLxb3tFi9Ka6eTDOYrA/bxiGDcYvwOXVJcucMfuZcRCfmX4LT4bjhPqeAisjxGjuxVMG
pP5rS+Ia7HoggzyRVwGm6blmaoVQTQuqY7ZelxtpMyYvU1OLwfjNK+MLYCiECq5rkzRFlObWoRDD
+h4CCw3UeLhKhRrBjXYl3bOAfI656uBycBhbIaD5dB4y9QuxNbmdhYMNfJ5FMebcwe7j9OnoSuMg
6/PQuT66crYC2bqAaoRRgVCa+KXrxfxULRv1M7iFgSnSbX372Th8Q6cVYKQNUcuO67IFlMTqTCUY
8ZCoUG/Bjo9N2/WdAgUQ/ire0GKptroRB2CU9p3cs7HYRG/YHX3YulHYAnlGcs6Y9wIxI4HopVhf
DWJzKRWRP76Wp5zFCjd8lDQXtLSW0yVq3YEBKgqS5R+4YR2aQCtNIKUmhqrVZIAMIp1/MaYtSK45
FO/pwYGNy3BFCna6J2bwjNfPaPUCDo/hmtRxd7R1w6dU3CZt+ctfT4Q+8WrboafdsAW7pdbzgg8c
WUv6rUHlkpfuxtvkMoPLEur3IAsLudqKd8lh7JT46CneJC0CG3ljYFT7Opd86RH0jSxbQqj4pcdG
TLEGFz4bhxWf9eoFigfRb9ZGlCiCFADAFhICYhRx4T13q/uokGTQsE2BAhOnMWFyM0uOMIOZCjNs
kR5uPk6fhgSaWnpIiHpIyEaQkBMYpHqOBUFapRhLjYXcWZhYGloKvAvivL56cznmhabewSLznirK
TCwUMyzYO2p0Kc8yKe1bHtAQR4SseEm4OlXxcld+uhcukrXh+c1gHVirT9ivFRCBDtv4invATIv0
ip/rx6beyrAX9VErKqpyb89anQde+5YhLaKOz59JSOC1UOuyKxEjxngwTAhWJoSKotGRImAgSVSn
O/oYKYQwpnZPTF1t+MlJYLV8lrKrESGVasZZTBakfKokT5iN0gvyd0ctGP9iMkfyTvkzXt7XsWYd
ZJFxKvE4lTBOFf4KF2+JOmhlQ8p6Oo3PKO+89p+e5Ah+HNxynOpebUaMwl+poRBEvB96gThO+2G2
6IdZgWcqMYgBM0zweiVqbkzGxYye1aA9tivgfI5AGijhFy7AbFQKY1n1w6xDV2BzL9Qtc6s6qIK9
Sufk2EMtapHX8X7RCVwEwUYMo4NQP/71a8Iju8p11b7qJTKt4ct3Xn1eXd3z1xN9rZmnWgfqXT9q
wRZs2ago9vXdG8Wnwl5DhqaP4j4p/CS34fYSlZP6Z/vGDgNlxksQUtDTYHsaUIOKUF9zzwLRoNWv
hx0bImV2dGQlcGbqF9B5crsX7vxEm2RHdx+jT8JznEK09+ic9OicsJHmfyN8ThmLeYrMBXSdnr9R
P84RcmPNvwRcuf5hrvhbdv3lw/wK3tCDLABmrjFkRdHgHZlD5ltwTySIpfkDUnIMVjGi5+jPWKen
34bXb+X7RsZeU3ocqnv+LdqRLSKoLhF4IJwGDqU+SCLc0JaZ33MY7UMJCKUEfKQITvR9syMPVAZL
6/qj+Ubz/W5vk4ruBcyoX/pfu8Dk27cxcixAAS1sOsSCS/vMjPtrf4M8SsiCBlonv9TgxNQGVRJF
ctpB4frujAzgjdnh22UoAgCyFpNhXARgPPoayB8vIceSCktRiqWOJCSaC1JKrQL+qj+qXwAMnH5l
qG8R9IKxFqNaye4G51HomDpgL/cj3fUgENrvyBUX19dvL+fji4TxKJyEPINuDX0wi7h3s+QDqDfR
nhNGMfmdmQMDSjIOG7mCGiX8feIlbO9xYsVuf8WDAPREPJ1AUH14PB6KL+v0G6m8vjLLp+IIxQJO
kZhjjyQLpFWyH3Q+ZaLvFgMWlIgRjgD/TdN9xm46/ZrtvutYlbfFGQftlP3i/lLp2H6Z2C/S8tnb
L0P7/arkvYEYjP+fkI7izelznFVyff2ejLc8mAnitAjyqZGAidMTweRmLxm2MdVF2NW/3H2UYXIk
cA4QKkcn8FQQZt4xTppzdHWCzb0DlFpw7eQ19Wa+uHiPjsfhaskcl9dXpwcGcVExzCkvLCLUaZNM
b2fheW8wQNTEHW4+Sp62h8327JH2mKhtYJb/OHm9XMYKyLdAzpJCujbkgoLP9JzpFiTmbmjr4mEs
tdLXQTwlYM4O5lkrvxVaEysHlYdHnKlSISl+NLzm24sH4xDJSt73T2yKYNKF2RUcJItbXlTlzmCv
knsRq5oEliyXP5qtujUkuIUuhk/DFJdjVLUnkka2hIobfYuiw9yG1zvQu/ry3vMAgB36qUgu4bll
9+WVQXWoqbPc1I2OgkpAeNTbhqzIgvzlxSh3e5ZaNXtaCM+efjX3b9u7CbB8AWlS2SvVtOoBm8DM
dwdtpRgvwaClbyMTzb8wBMmb+vREEjrFkmR3p7qNSJ6Wgl7EKtai3WIyfgKMooc30DMDmogDtbpN
NQosZK2kUxkL993LHe8DhVUtx66Gk9iC2O5smTF4WTt/0gyi1app18O9DlXA42fJcP7dPt9guH/9
h/Tq+23bBsLv/iv4GBexJ1GUROWtSQNkC9YMToY9DHtQbSXN5jqBpTb//u67O1KU5xQdggKNdfx4
PN7Pj1/VJDFQ/LbuzFeBPKolpjUqmC8wox4E2G5N2BmoG8RbvkQ7PO3lBmS/z2p7mAFJr7Bv7BXU
70Iy6fMDgzrnQHlyFhtpqdrxmZSboz9nc9AVEx8+DWokI9H7OVCi6Jp/j35u2H8ZPx/J0RW71Imj
6UDDfipVatr1unseus2PuqN4qztsdIcP7kD04A4b3OHZHVQL55IqZ3Pc3QiS3yC4RcPpUsJtfbcb
TDsYrlOLOr0nPzToVwxT7WbYt7v++Yl4jFRZ3/U0Rdbd4zcBkNuKk415FDXB8QjCgvUxSSrx2IFZ
13MaQyc/6jn3Rs8V49DJ3JhJNV0OQ5tdl/HcwKeRtbO5S5LjZlAsG75PemvGvRXSvp/XSBbBiUqI
0IVyniUL5NaTbjIBs+MdmATya5CTz01LvQgKRP1kkSI2oOs14Q7cBSt0Ne2CtZytMRpt5xjxPWNx
8ADJQ/HU6hxUx2SKvHLTH41i+YYocuzKWAA+9IPPHZyQnyCCDXqB+YAEayh6xE6pAdx2urLbaLsA
Ivd01Yr2ga9lnJ34MmvR9qTQ3SBaWhFT4eQoo138obgHSn4qpZ9RMeXJb9z7CyYe2BYO3uxlXU3u
e3OvEjrP4iHxBTVSJXOp4gKU7Y9iS7jp53DcR7mwfoULLeRGF9r8rgWUBBMHBd/0fau/HtS4qQl6
kT5OGkUF/yzRF23cdCQqg3rsM3tK9eluozc7+OyPMwxXjgRS37MbMBQLWoMz2/2m25h2J+1+Y1AL
WHh+CiJafplb1I5sHFA4nmzjZcMsyuN9w2G8oUniaUBjBNxpLP6b8jrJD1K+emPjyiKdskqnVt0z
QkmF2DIDqpgBtJ9E+CR/vql46PrBrFvuw4haQngsE55KWULBLAFfRlUMcxDNEZG2vFpTB1Oy5kg5
oSOpOhGa7eM/akxIDh5C9IHH44K8WqHrwJwLCcM1+7g5OcVTijLxciXy1c3qlDjxAgl19fudavhw
84ck08fT4/mSx6aR69S8DbtL2Q3lHxdsRClG0Hw6NVeXCtKV1byU+mLhueAudTGIT0E0qRVcXf6f
XQsmWO8vrqXjd+wqTxGpOTvzpHJfZOcjCwceIGgRTH+nnzIRhOdtUFKeOhEW9kKgaYRjEhzdqX/D
vm7Pvr179woPEcawl4AJ9W2YtqZmF1z+i4L1dcJy2cojTIEDUUWeMKae0FpQjR6utMpimKFB2Xo8
PYUCs8T0nfBEHLndmrAl8B41TOmUbJ6Q8YM1NUFlDwkdUoo19YHSLzr4U8fNCZhnpV/oTRFuS347
WIn0SMYOrqBM72bFHgu+lBZ1eTfzbunoMWap4RGhpjecNwv+f9/N7rHqfVx1jsiATddLLHx3uyin
ItLFvJiueb98dd9razCJ175n0JEjw+JRvd9d/OmiL83FLbVe/Lu9mOXmF+rJfxOQOvyLyTPzq/nz
r8xsZs6SgS43rvJY+xIF1hGbM9tZ3tA3HeRo+BHf/DIrMrt0Lgq2s1vClPSTRLYgQO7JtBQQl/GK
pO/7dzPbiF+KpiBsskkF0ApMBZFvEK3x5IiJiKZeUvmy5mBvUVPPT+1VQWpvUVNSpocHSARU9TLo
DZiSmIlVvZmPAugtspx9V5SUwxVjGjEwYCKiIopUiWaX1wrKxMOupPv5KIBmiNggV+GmhKkyPUox
EUF/vQ+aM4mdbcTLAFUuClhznktwCjoUkKyQ6AVIBFAFuwNfFOXoY/aFCCa+KMinPvVFwIyIBpk7
1Zy50YPsCxGI5kZummUcvYLImHcJZAT4aLFmhW2QDMkmFaRZYZtqmaZkhEQAFV01tdf6DKUtep2P
AraXRIypK8ScMFRimUswEUHdIq8OLEYKTiwWwcRiylufWhwgEVCpH2IQcie5FstFBJPqyFOdETAu
Z6Ga/x0AJ2xsCgplbmRzdHJlYW0NZW5kb2JqDTEyMiAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9Q
YXJlbnQgNDczIDAgUiANL1Jlc291cmNlcyAxMjMgMCBSIA0vQ29udGVudHMgMTI0IDAgUiANL01l
ZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRl
IDAgDT4+IA1lbmRvYmoNMTIzIDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0Zv
bnQgPDwgL1RUMiA0ODYgMCBSIC9UVDQgNDkxIDAgUiAvVFQ4IDM0NSAwIFIgL1RUMTAgMzQ2IDAg
UiAvVFQxMiAzNDcgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgNDk1IDAgUiA+PiANL0NvbG9y
U3BhY2UgPDwgL0NzNSA0ODcgMCBSID4+IA0+PiANZW5kb2JqDTEyNCAwIG9iag08PCAvTGVuZ3Ro
IDI2ODkgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSInkF9tu20b2XV8xjzNFxHCG
d7/FjpB10cZZi95doO4DLdG2WlvyUozdfNL+5Z7bUNSFiosgxQJrA+LMnMucOfdzWo7elqV1yqry
dmRtEMYqhH9eFSH8hqnK4iTIVfk4enu2TtRsTSihWs9Gbz9Mrbpbj8aAGUaJKmcjXOWRKl9Gv+iz
1fLWjPMg0qvGjLMg1o/8qUwROL2c1aqs1wZPWsZT06eaYDMzjoJEL4R+MasEY7FaKmPDoNCetRnb
INONiYCNmp6Vn8JMCcre129393/y+yfR/1HL85WlxwUseUiba42wRL97kie45I0owzFGGF4b82v5
I9kqZFsVQZGSFWjhLRXlQeJCi7ZCO8QZWoSMYzMxiSn06ulLY0iXJoEL7+5b+ipQpAus/o9xBcij
/mZi/fnuHgzEllndEhojvwCfirnUavqFcRhUPwIhH7wxaBp4Rxj6B+Tia3lg0zyDB5TvSdbIdrLi
A1BWxX/GOr27Onj4V65c4R8kwQNOGKU2VinYuYj9q+J4Y4GYX/XBQHRZXRsHSl6aFDXYVC3awuoV
H6jVrXoH3pDpU4yDSF9c0q7c0eLYpkEeZk6NXRBFGV3LKox9LEZybWkQ2eqJGcd6amwUpN2Z+nj1
8yn6nIAv1YlyZpyCMQOwY6ot3TspR1Yt1CiPgxhslBYpOWEQ52pMv009uv06NM87aByD3K4PT1wW
uGHyr4B7d8MRQ12EuWyP+hD8tByIqzSNYLsJLNelujBh9V6C3XIwagjausWwd7JpalCyJVNDcOpZ
faKmGPAphCKSoA0iwP7Eh+Rg86YSHu2Yv4ua0l+OSc/CR47XBs23YNAdXdA21bKDjhNIP7P2SQ7C
LGj/YCzlo52leDAoQ/WZGbLkCvzB290rNoOkPGxUhh4x6iC5Zx4es9oAfNhqMeDGYjObdMnQOkmG
5blxmHLLn4yLyflJJerEWPR9jvayxmDJocCAGbGCRTEWJkZZGocZrmKU1sBLPGgFuTsDhB0NJiEV
2QENMvSIBgfJiXlcbPR7SIMD8GENwksK570+jLzXewVOr065sKEXY+4/N3m3/gk8LcOEggkMMsqH
WrIdujAEBuS8FXpopn3S490t8PDe+Q6Vnmq55eKy3FWnS6HiDaqToUfUOUjumXfKPqTOAfigOpMC
vK3LISnrEAIfHeXKgACRvpTtxXRyokrSCETi7N6gS9Wz3+mrWt5XrdfTC+op0/eMD4pmuisCsyly
f5NakyFiPResvq4zfcOncnWD5isgXzxt7RePxmJrsoC0RD3O4pklfKMqZr7DlSwIdUwEuoRIycRT
og5XmJKDJHq9rig3ppDZiDcfq8Xa46/9Q1uDJVW1Xl+in1qt+vD7PpuGPClUsLFJmnYF220KtmMD
wSWUPedPqwWIXWjZt7TB9zJYVWvsZXPuSHM9Y+yK8XgjICFRfMhUqrpZNYyLvUGk58Gus0MADnk6
gI64+WFC5uk2EYCZLd0lPQwf9vEkR9zBQil1juvlRAqTL4ITVI+F9iSWnIKHikvUxcf359vY56zM
i48n0CxRAubyxb8rniBmi0pKJ0wOVPvAgQhB+crM27a6eVhIybwnRC6Dc3Xji++LcQit66WqmRf6
BK9aqqA9r4/IplvFf65OAy9qA3WaK3aN7sqLedVWSso5V47yB3bLfOOWed8tc3bLhO6gfUsbdaqw
BYcOnk9nGPsOHkY7xUiyq4QEskUOqYLbESGvmc7fhRp3mkG9t6L+yHuJz1PDAj1idU2xPUlJQQnV
Tfx9Znb1rocn0D0PN40CHfbzYXLPvOv6Drj6EHzY1bF5iI91hZN/ibuLY2+3fJP36ucJ+zr/imt8
mCjeC9XfryYfKc1GwmACHUrPOaJoMzpFcvESuo9IUpbmDeSWvs1iTJS9v+Nzz2b5Wryjq04++uwK
efo6mfyKdBGBD0ZggW6gxPoq1oj9PLlPewX+biEpIYux57FTE1zRcZLJ9FpPMGlw1KeaM0dKEZVT
/rZ6fm362v2OI+nu4euE23Igep9X0ncX+Ps8+/CKfQPKRGHTjW8ciJhX3yyhQ+mOvUa4o9fEcec1
/1dK3dLfNRZKbLUWVDcjcDzok9AHqa2MoDBgH1pz01Y3zapRs+qzKTTjMEBcdKNeyPoWDfe+G0Fm
o74F361pjODfFY8dWP1xyqCBZEkDCZd/aDobrv8ojsMa7dGeCQ2LPxQ81ft7ZQr8hhX6FrbKCYw6
Bvvjgz3qfj7aF/F/aHWtsdqn+p/YW1lwCs5DPcPnAZs+oeQkhu91BVE0MPRSV8DQI13BIDkzd1jp
GWohtIvdtmAIYbAviMOu/w07L3XipTTzYGV38Ogp5hKZg7R6P5meXZ7TlEbdL2KcQ3e7o47Y9vqU
PXUIdFgdw+TCvHsqNv67pPvAQTVEsBY1pF0u1DYw5W+jt2UZK3DeWwBnSSGZGbGgRWF4znALzHK3
Sd2x3XTC4v0QNRi3ODvl8ktta4EDJUbxE/ZRhYAUf1Z8pjy+g4asoe4o8mQLAlHra3mMA0Rs6Qs/
BEL6qnB6yzT/CtMZU+LgAYoTPgLzdDRUIPSFpa9rD6m3LpCps5NDHrHp45BYhlDAfh31qbr5Yhw+
WbHgO1Qs6oIFlMM7EW/7ZplZc+76Cf8RORfyagYK5JlZ1IfTWrwpylaC5RZzSGNCUh62xjRSWB5V
IF1A8+ZA+k8wM8n8A3m9lgUPRv4Yxg+N41df/FQ/mIRMV7B5MtZHwfrIPO1cYMjjno/qXvqiA0/n
0Bz43k6e7Rt5TJIhyb8Hl3hKdM9yA7EK+n3afuKHKgF6rWerZq4kr9b+QiprVGY1jbWJ5Njqbhtv
k3n//Vk6RIxvS/USnLlWnxllsWRKVSk5QCvE+o4RqwflKbHAp5q5PXAX2q4afguoMg8zt2v9Xopw
35giXNSpKWM1nVFfgfoBvc5IyEz/TtueeVDOEwNHFzRtJaQAahRm9eKZ1vBiiJK7Q5RoWLQqqd1S
7wNBwGT1mx1krPGgOajyKBgPhJvpTFhgCxKj7VKyUoI6FtlZghp7GTxW/KkFynK3+JR2xX6ByE91
3fgrXliOhUE8EJRxtmpypD1XFKOvBT6Z74cxd9RO1G8TCePFEhhBioDH47tu8EUOIy7lpBvjsIL9
AgCftk5BmzYnOank6BYkQFb1a30p+kt9ScxKTrRtcFYl/1JvmvV709y7mrdn400prrB6ruf7T+5N
G70nx9/65KR7cuKzTEo1Eru4p7pq2aUSLIY3q2dZtjUmBUtTJ9SVWSUm41Mm3vK+XAsXQVzSbktv
eRdVmGly1gZEYSt7uZt5L/imjaN6yFzBPJJQSULRwN9dGKDLgxk2F/L1KznsB8L2G4LddixMjrVj
DD3Sjg2SC3MBFQ6b2D4sArGLdIhyGIpiCfSoWPsXe+AA76+A356tE3U2pUYxVNOzkVU/ggf+Bojg
zy/Khupn9cuvoZqPnE35+Sn0YeoRZk1wwNjvH0ZTwkjpBBroFFBcmG+hdAhJisI8jG5/GMUhhCKy
hTchDeHGfo9sEYNPUmz64WZYhD2UDiHP8V5mC8UijnlSQGn9HjttZvvfAQA5sUkDCmVuZHN0cmVh
bQ1lbmRvYmoNMTI1IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA0NzMgMCBSIA0vUmVz
b3VyY2VzIDEyNiAwIFIgDS9Db250ZW50cyAxMjcgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5
MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0xMjYg
MCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDQ4NiAwIFIg
L1RUNCA0OTEgMCBSIC9UVDggMzQ1IDAgUiAvVFQxMCAzNDYgMCBSIC9UVDEyIDM0NyAwIFIgPj4g
DS9FeHRHU3RhdGUgPDwgL0dTMSA0OTUgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDQ4NyAw
IFIgPj4gDT4+IA1lbmRvYmoNMTI3IDAgb2JqDTw8IC9MZW5ndGggMjg2OSAvRmlsdGVyIC9GbGF0
ZURlY29kZSA+PiANc3RyZWFtDQpIibxX23LbOBJ911fgEawaMQQI3vwWO6pZTyVx1lJ2piqZB1qi
ZU5s0SPT9uY39i/2L7dvoKgLFWezO3YVRaIbjUZfTnefzkavZjNjlVGz65ExYeRUBP/8VkTwjFKV
uSTM1exu9OrsIVHzB2KJ1MN89OrnqVHLh9EYOKM4UbP5CN/yWM2eR5/0WbO6DsZ5GOtmHYyz0Ok7
/imDIrR6Na/UrHoIcKVlPjW9r4g2D8ZxmOha9tfzUjjqZqUCE4WF9qKDsQkzvQ5iEKOmZ7MPUaaE
Ze/Xf+5+f+fvd7L/o5LrK0OXC1nziD4+a6Ql+vW9XMEmP4kxLHNE0ecg+H32C/kqYl8VYZGSF+jF
eyrOw8RGBn2FfnAZeoScYzJxSVDo5v7rOiBbBgkcuLxp6VeBIW1o9L8DW4A+6m+B04/LG3AQe6a5
JjZmfgY5JUup1PQr8zCpuoONvPBTgK6Be0SRv0AusZaHJs0zuMDsDekam05XvADqqvgvMFbvvh1c
/Cvf4u5CkjxjyJmsSKxKwdGF89eyxidFVPCtZkGKRgoi8CyEBWwrIC0MpJiuV2WL8d1cq3Klygcw
Z6b52WA+FHpeM8fVV7Wu5lX9VK+W6vVpME7CVF9csmz1DGIj2FQHFqS2N2rVqGq9Bt3hzGat5uUj
S612vDJOwziDPB7bMI4zugR7xPlbxM7fYmxSCJZJMHZ6GpgYzvdr6v3Hd6cYwkK+VCfKBmNULYSw
SLWlYyezkVG1GuUudODytEgppkOXqzE919Xo+tvUPO+ozoHetk9PbBba4e3fIPfOhiWm2hihcW/3
IfrpbCBN0xR8mW7y1HbIGSVs3ktwZE5BkgLOGYwV/lhXFDKJXoElEz2vTtQU8SOFzMYt6IMYuD/w
IsXrYl2KjHbMv3VFaJojhhr4keWHAN1XM2lJB7TrctVRIcogBNt7WYiysP0nc0FGnCHZ6tsAj8cA
Q1mstIJQ8C73Ns0A3of9ydQj/hzc7oVHxxw2QB92mANeJ+4ySQerxgqszs4Di+A9extYR3FPUKpO
AkMZSX6YVZgnOWQ9eBBrYeywxDHLKrCIlSWztAHcxJMaqAIZMOxYMImoXA9YkKlHLDi4nYS7YmPf
QxYcoA9bEG5S2C7gbRfwORtw+pFALJEATvQ5XLrovt5ixKUIJ2g5wBOypxAxyGK9vgMLYvAWYHjM
DohCxEp6U9glJNQ0oFiAV14GjAVcsgSyOYNs7kGWOa5k49fA4ikMu3zIE3FsnbjkTVJJXwekn9zs
glA5pdze3NPzPgcWMRwhu8BuCGXesDQWLcohkDOE0yorXu3GhoUj7GBsMPVIbAxu98K7yDkUGwP0
wdhICkidLjR8ZEgT8IELyUfoJGIyXeyXLqaTEzVr1BzMpKv5F3iqFt/LduOlGL2k5RUMiR7a9k/M
/snEP7kcwv6B5uUOHY8mhj1k7lSeJa2gPAxA0/MkSUVPZuzJGD1JfkQvui0fijARMcfAhGtgw2gc
gUSOhRxX+byWxFaKGTl+nQgh4V30QrHdiYooHgwJIB2Jh8MbWabdhMqhYBigDwdDWoBGw5VRChsX
yIlUIl/1CB8M9CNoOr+ouDJevH9zvs19zsXv4v2Jes2wy0WLnw1PIGhOLogMCZCxNTMoX4r5sy2v
bmupkTfEyMVvoa58taUcL3RVrVTFshb3Tc1vLdXNrchE/25V+4U6Db2qayjMXKIrinp6WZRtqaR+
c72IFFrEudQ3pG7TZxtJMdDFYPShMmA53ErfLX30VKIp4eGRqZB29Kta9IjV8lnKrhIDv/CidoSc
om2hYaWB5xKUZ28Z6liYE9IOkbAKLKFcRp1wRhWSBC9ZMNMV680MXgJ/McNKtOIfGhmhCnzj4qdq
3mytlFtcNd97JZooWe6EdzlOy31t1JYc+eIjdnM2yYpNb7mXtkIdztzh7SJcSNiJpHtb94nDaQtM
8DmYtpPfJHElRbe71ckb9W7CWctPCfKfJ4q/ZdffP07eE0rHImACHdYmzJO0C/M43oyTsaiwChCK
2dmaP8Do/dh0GIC9v+Oz4Ob1pXyH3jq16GdXt9P/ct4lq8SASzH4Iuqm0T2/7O39SK1WATiLEsZe
xI55bdEJEhD5rCcP1NggkEFxJDDEb8QmzGNIs89B37jffaeXv8nry3TyAQQ5ZDBs5IZ5d0MrpqIA
MQheEOv64hIy2lAII1B9f9D8j95EK7yYkyeVLtvrY3PNVSERBiVjpEWYNdw54I4n4sW6VejFfv34
pH+tqdZwM+M7ZrvdlOZySLWfmZ82Zvr/Of/7387Ik3KXO0i+RJ6PvMR3rQPqB9CmNBPEsq7eBmRK
v8q3b3eB3LkjA69QjwD54HYvvBtoTRTvg/kQwyCguzjqDWxR5rPBCppi3CeIyxj8U4zBTNbUm8n0
7PL8A9ZpquvIcQ5d1o5FnIuODClCHbbI8HYvvBtCsIWy+7sP0YftYfKePVIyB1pCmzCY/TF6NZs5
BVB4DeQsKQRykQvqC9NzphuQl9sNJsfFplIVbFvqkix1BKk8Kyp72BbRDHmPVjVCU/zT8JryG6xe
EzYlflNNBCwuBbdpKc4RIpiXcaDICCbwKRLnvLGkRs+JGKHJNmpxkfjMqkOLy4RqS7w0Wl4JUb/f
G0JKlsL7or2n6uordIrQlpLGO1tYx5pV47Ul67V9JvWjOU6AWBewIbXSkOY0ANLIJaL7BvLGY6EH
AI/a7C53jOQOTog0HzqeD1MoSP3OdUVfOM0BnBC28isjLLXCVajOmQ27f2ot+7MD3gj660u8hOv3
1BEbKaKmGkbHjEbHWJdLEXLPR1XV+l8P6kmaVuJf16zrdVBQFKD6Hg1Tsi+rI6KUyL/pX+aRf25p
80IueCVH8jFK5N/eVsIQHp5k9nsQrMgQe/NmveCZqNhYhQpdRjWfhjQuhQlefIuPV5Htz0fpEjAO
DIF9oeeVemSWesU7ValkAaPH6SUzlrfK78RakmqWdsudSNus+VY4gUaZ3Y2ZHr7YH8QXm3Zmcmwm
bJ15RgUAmJOSTn+hz635s9AnoC046H2zsz6HDiHTX1a0h+teQlGNN6wWSxYtku+om/VfvKflfiQj
c1P24k9FYlcthAD1+FSRHYR9K8ruqHGKjjSYtgYj55LuxTOFobw11IbwwXwEP0tZ84risYg7+LVA
DAS5ufCKEptmCqxUi9rr7TsK61NP6uKlbo7/UjeL5cS/2PMbTQMalO9yXcHF7pt1Wy2oSWrEHRs3
lH1j9gzEPu3MNL9txJSPtID1CHPwpTZxP2gT0yGE6RBC4kzfV2XL0InJX141T/LaVoiIODNYukPZ
AUNCwBB1SUIBb3UtUvyyCAJGRkxHiJkSYqY9xLSEmIVHzF0BJQi45f2Polr15+OGpNpmo79XblM/
CoZXoxHIicoFowB9WeqYtOJ0ybXo8FLXJD8arnuTKLqGZ4+0cw5OLOIcfkXnpNT40Ngx50RmLDey
md+3nJRDGoyxe69WJGgLR3LGESs4EosmbBgrOOIBzB/FT3/8ktWj4xkcNgr0VePTRfltBQkPcy2X
VgyqfkelYLoSPRq+CSRpf+g6ZIJwt+G2+bGGm6lHGu7B7V5411AXFt/75DgeHF4GSKgTko4rdOhI
Tz8k+Bjt1dlDos6m1PtHano2MuoXiN4/gBFy4VmZSL1Tn36P1GJkchwLQIUCMiRVd6M4gvNzXgA9
bkdTWIIsQp48w9kLeSDhXI/nPz2XMQ4AIAgDd5/iYKI2KB/y/0+wBeNYKEe6wXe44rJwakFfaTKN
YHsbO5WY0rHXIAQNbokIw28vgR8QPM6gF5DJNfE0JtEBvUBhmGoKZW5kc3RyZWFtDWVuZG9iag0x
MjggMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDQ3MyAwIFIgDS9SZXNvdXJjZXMgMTI5
IDAgUiANL0NvbnRlbnRzIDEzMCAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9w
Qm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTEyOSAwIG9iag08PCAN
L1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgNDg2IDAgUiAvVFQ0IDQ5MSAw
IFIgL1RUOCAzNDUgMCBSIC9UVDEwIDM0NiAwIFIgL1RUMTIgMzQ3IDAgUiA+PiANL0V4dEdTdGF0
ZSA8PCAvR1MxIDQ5NSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgNDg3IDAgUiA+PiANPj4g
DWVuZG9iag0xMzAgMCBvYmoNPDwgL0xlbmd0aCAzNDQ4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+
IA1zdHJlYW0NCkiJ7Fdbc9u4FX7Xr8Aj2IkYAgRvfotszcbdrJ1GdNOZTR9oiZLV2JJL0cnmb+y/
6L/suYG6RFSS7vaSmdozIoBzcHBwrh9G5eB5WRqrjCrnA2PCyKkI/nlURPAbpSpzSZir8mHw/HyT
qOmGWCK1mQ6e/zAxarEZDIEzihNVTgc4ymNVfhz8rM/Xq3kwzMNYr5tgmIVOP/CnCorQ6tW0VmW9
CXClZT41eayJNg2GcZjopexfTivhWK5XKjBRWGgvOhiaMNNNEIMYNTkvX0eZEpbPvn56OP/G7zey
/7mW6ytDlwtZ84gm7zTSEv3iUa5gk2diDMscUfQuCP5a/pF8FbGvirBIyQs08J6K8zCxkUFfoR9c
hh4h55hMXBIUev34qQnIlkECBy7uWvoqMKQNjf5HYAvQR70MnH5a3IGD2DPrObEx80eQU7GUWk0+
MQ+T6gfYyAvPAnQN3COK/AVyibU8NGmewQXKC9I1Np2ueAHUVfFfYKw+HB1d/E+OYuMvJMkzNC6M
MhurFBxdOLqWzwdJhxLDwGASmBjMslxVwTDFyHcU1zhZKfrMeU0RwwqMWMh4syH6dHls6+0n/Kqm
ntbLDzhcBhGcs1rQ8snTa/XYLD0F2Ax5k6WTqFrNG8w0cBtIsFAQunh5enysG3VP4kiDutkceBsE
RUXq1NCGcZyRcdjTrjORExuB0BSEjuFwPUGF0m5NXd38NMLUEPIbdaYsHAgxF0K4pTqmY8flwKil
GuQudBBKaZFSroQuV0P6berB/MvUPO+ozoHedpee2Cy0/du/QN45G5aYamMsuZ/tPkYflT3pn6Yx
TLf5b7uKHCVs3jdBCp6rIS4wyKA6WZk0NXk9gWiDGqKn9ZmaYF1KoWLgFvRBDNyveZHyYNZUIqMd
8ndZU5XOMYANfGR5E6D7lkxa0AFtU6066jCBAJ+2j7IQZWH7C3MpH2SsxX2AOlRPLJA1V3lovd+9
YTPoHf1OZeoJp/Zu98KjU17rofd7zQGvE5+ZpKvZxkrNLi8Di52hfBVYR8FPJlFngcHY56JU1pgs
OfRBcCNmeeywfzLLKrBYiCtmaQO4iSetocVAjTi0YBIRFuixIFNPWLB3Owl3xda+xyzYQ++3INyk
sF3Umy7qCzbg5GaEMZZKFKf6Ei6dd7NXGHYJ1hRMgDM2p9AwxqxuoORhJ4cQJuASYA2qWsAiNMKi
bTChUKqqZLHaQDvMMLxThikxRvlyZ9stbfuEsq3UbT7gA9H3Tlvwls/0wpQ6UIuKOS95vds9wbzZ
pxarDc3BwiLfRLapJ2Lv6rvBRiTqigJ8x/AwfGwKQKQ3fJh6Inx6t3vhXXAdC58eem/4JAVkl48e
k/noMdK2X2PdcvomMFg+/fR6Mj5T5VpN7wC/ZrqevqevanletVt/pmD2jBsrTlY0WTB7ST0Zii9Z
EyewSuaH5GXOivyE/dgiuvLOTTu2du8UkeW9+xFyXi/v79XUy3kiNnQc9v2W98otVM1nzh7Xcjqf
qtq1kh0iRfg8UFGTlzd8l4vrtxzxVxQUkYKsMkmaeqBnOwN7XPQAAegooHJuBhl1jFhXGPSoFZy+
pM6SCkU91hCTlEcZdAWiUGDmuxd3cK2cTUKIhtlVBdYQaUJX6yca7J3RVnvbZpjAYMoVK6UugBrB
OS/wHEpLHiqW6TeLvrd17U+fCuU9zXkV045hNUi4p3dAPZM1MQKZZ4Ygb++adOZn+Qem7Us+IJ3I
vOMbWabdJiU2l/Rw63F6f9olOfL2YhWBGgxZxoINPA6hYm0AIWIr84uKUcL11cXlPvclw5HrqzP1
gnsgIwj+XfNbE0szQxQu0PAEWjKD8uCIp211e78U1HJHjIxEwDke/3xEiFxocLqqWRZnFIEaAjE7
/oupa+zhr5kahV7VBqASg6YaqwsPZlVbKUFU3LzLP7Ad886Olu1ICuSdAjkpAJcbKbwOvPFokaPS
0oVyzQflWMZKUrSgOxZUomKuPSZMGdOx0vm28+CSZ2hl/oFYWIiSNT7fP1i29Jmac0tuuCVzdsRe
ZvfwoC273clyEeiU5QMOsyOBJ1o/5hdqf470b/fCO9B+JE366P1pgtjPnQL1479IqkhS7CP28YX6
acx5wr8SVj+MFc9l159uxldU0mIRMAaAuRNYceyBaVe4xyuo3DFFVoAgs6Au5fZqE/pr5w+xVf9o
O/xavv5Rr3Kjr5WwO7ohU8RpCGUOsEX3gs35BYv20K9eB+XfBkPPdNj3is5vhs33To8xQLkipJqr
Cs4x9zCGjZ69C3at961af8PID79OKd/aIUfgneKvGHe2+Hnr9H+fyr/vxU+P2P3QRAqTsvvJp2nn
U9dd+4SUCdVi6BQkbujloRkN5ldfpMDWC+pJhf4VK2OqW8Ve4c5kNBMJo0C/mmA9sJx/Vp//qHb/
fl8DXsgh3CZyOPMo6vt/aPyLofGlIvK/aMxTMeFcb0xgiEuAZxLgKQc4lm8KbgltaS3xQWj/1y/+
hdjhSAFMX7idQDGdSwuxhWwo6+aB4QwBN4MAS6KDZXyXwdETHYAyvht9aYqtsqlbAOdUeuk9ILA3
Y1zsNNdo/l1SP2Uoa6Ve7zXSbQcwkdlJjckLlOkAlRmEaz8eL7CSTRgGmYcX8yDHAxNQCJA0QB98
+crCE79xN/TKjekhigszpkLA0XdxPHOd6bCgkVCDBwmgSXgEBBaNIzM16rnidxKsk5c3+86/uH57
RReyRWhiwOJopgyNcFjTQADCwZ1nRxwDou99djD1xLOjdzsLt/iUYKpN3ZHtPQy9Dw+b5Mgkz44o
6+JL0D+aJMHXA74OJ2imTNbUxXhy/uYSXiUFBGzJHJfXV2cHDzGb5mGU91lEqP0W6d/OwuFJJESA
SIk93HyU3G8NB0/JfPsMS7eONiE6+nlZOgXkOZCzpJACj1xaCT1nugGJud12gLjYvqyKrW0BAWDa
gor4qoWAxJSiCoJvK5nVgUUmiE2qPZZqDxLwwVPoil50RguzqnhZVZtNkMEWETblPRWzLXfPkQ23
dYuN1+mPAdWvuhbJQq/5y6+t7niWt/McTKg27G2dnd47Urd8exHCeuO1ZReruWTteG3BOnkjHrXR
DnvlrfPYyPqeJb1RiPKBdqDEzh1Hy7FLtxUyZZ/CNQm60z0TqLUyb2kCF51D2YFRE0Twu6ayTArH
cC48QKGjWP0qMLF+HapRLdzIB/SmBryEDKAaFXM+ion+OJosmCTWMbKhkXPgmul2f8W61c864ZTR
+9KFdqAwi1UzEVHxlCeis/qCRXbDBmPWc6vZevUr3144T2k3kf3nP3qcQV7Jff+xAs/nqJUDxoYu
YgmGUeqQ4e+4isEZFr8PHGJzz4zZkvnVFyHDNAi+KLOfwbS863x2r/O9CRDZ1tN1M4P7QPNs7+hb
e0sQuMCcjzzgSAlcOF0t9jl5lRn//sS01bRWPJStyxXvUpVifkItiV6saLm6V/y6tHSvRPPm+wC9
XLXrJjwODnYqo/2NldEl2yxK2FbnpMQd+hjKwBRdnuj3PN2LmFyfBVRuJnS3l3i3WN+A9rmUV6sv
aHZNv2/heQEyrmiiKIpjDilEcDkZlUA4Ly1EA4hrSKYlHcUMWx/kkl4px2RC4Wo5CzhhUGk5Q1gk
F+zBltHJkNoxefwbTW47HBll3uL4DsNQjMngBgHue5qqEUaSA0vjy+zlTUnZ4BAlMX68UstNQNnL
n38WXjW9bcMw9O5foWM6oJ5kfVTaNTtt2CnHYQevyQqsaVNsAYb++z2Skiylc3ZJTOnxkaZokjpk
9WdWP5PaSZ6PiAL6XGw+fLQau1juNLmHiHhLw+sr3ZMcl5tZccIvGlnaK3l4EQ1MqMV7JRbmG80j
u5d+d8iWVh0/n5p8I0fVLLv7ty3hdjmlsTb5mVpK2tzL3+Mz1RDH7+0lIF7e4i63Odp7WGSaUb/z
36tUqsUdUrxImH76tnEZOaJ4Q4lvpOtP3PMouQ1MfeDn3C8SjiNRNUHD4S4Z8oxBXkxGQkdnyiB1
+tXUrqlMFRO1q4904Pylmk3hzqKMKRGVHsWbvNryp/SZn5X4xv3YI0qu/uJ600qCy+4quZ+gcPE7
qSyps9AU1CEbllHEb0TM2La6GPrmWZUGEuSQILvwqfn+sS6jtVgZnkx28LB/EKvs0X68HI59uDYc
y+6V4XhVXch9M/16QrbbxmmaiFeU13fJs7x7zbN/2y77K/T/2X6//e3VdseDu1a77WDUJ1S4nwAi
/f8oo9UX9fWbVvvBRIz+YHJBj1E9DVanMbgiH4cdIyKv4FITADGRrgELpAIQZVwSjsOPd6ChdzHK
RjRp1rGsIzLRWu1Yy97BAUeWkVChgVRARF1yQlu8tRYdq/FW5NZba5FcrbcFUgEIoQ09rbN0bG0U
ZKELg0XPdW0YCmZBUB8RZodq4BzdOA1Ze6oLU0AjBsbZNE6kBLZEAJsCJ1Ze4FBhib1BViV+7RjF
UsFUBIJppmy6MDt3wSwLHbOLF8wFsyDMW2YaCzpmWeiYKcwdc8FUhEmUwzltctwpShzjfDAsd8dA
NaTLxgypAB1GH3pam1JDSlJHqScJVE0ZBtSESZxRTPgXeW9rewplbmRzdHJlYW0NZW5kb2JqDTEz
MSAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgNDczIDAgUiANL1Jlc291cmNlcyAxMzIg
MCBSIA0vQ29udGVudHMgMTMzIDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BC
b3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMTMyIDAgb2JqDTw8IA0v
UHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiA0ODYgMCBSIC9UVDQgNDkxIDAg
UiAvVFQ4IDM0NSAwIFIgL1RUMTAgMzQ2IDAgUiAvVFQxMiAzNDcgMCBSID4+IA0vRXh0R1N0YXRl
IDw8IC9HUzEgNDk1IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSA0ODcgMCBSID4+IA0+PiAN
ZW5kb2JqDTEzMyAwIG9iag08PCAvTGVuZ3RoIDI1NjEgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g
DXN0cmVhbQ0KSInUF9ty27j1XV+BR2InYggQvPkttjWJt4mdRnS3M8k+MBJtc9eSXIkeJ7/Rv+hf
9txA0rao7G67ndSeEQGcC84N53JcTl6WpbHKqPJqYkwYORXBP6+KCH6jVGUuCXNVriYvT3aJWuwI
JVK7xeTl67lR17vJFDCjOFHlYoKrPFblw+RjcLJZX+lpHsbBZqunWeiCFX8qXYQ2WC9qVdY7jSct
46n5XU2whZ7GYRI0Qt8sKsFoNmulTRQWgWetpybMgq2OgY2an5Tvo0wJyrOv3z7d/87v70T/Wy3q
K0PKhSx5RJtPAcKS4NWdqGCTF2IMyxhR9Enrn8sfyVcR+6oIi5S8QAvvqTgPExsZ9BX6wWXoEXKO
ycQlugg2d1+3mmypE7jw+qalrwJD2tAE/9K2AHnUG+2C++sbcBB7ZnNFaIz8AHwq5lKr+VfGYVC9
AkI+eKHRNaBHFHkFcom1PDRpnoEC5SnJGptOVlQAZVX8p40Nnq72Hv4vV7H1CsnjmdowTo1TKfi5
cKgV65L6RxGnrFVp9TQN02Cqpw6CY35z3/JquWHAA/gBA2ENxgO7C7SBUwPflQagCeqtqr/cwVkE
Bm50BEdb8NRjI08NPNwoswqFi7OBVK6TyolUwCoFJjO4LZjjHWl3ps4v3x1jSAr4gzpSpISDSM4B
0dG9s3JiVKMmuQsduDAtUorR0OVqSr/benL1bWied1DnQG47hCc2C+04+TfAg7vhiKE2xlT3jHof
/LgceXZpGsO2f3e2y4RRwub9oNMwD2rwUwp5C5xmZbOtya8JeBvebrCoj9Qc80EKLxVJSgoGG7zn
Q4q/5bYSHu2Uv01N2THHnGjgI8c7je5rGHRNF7Tbat1BpwkE1KK9k4MoC9svjKV8MmApbjXKUN0z
Q5Zc5aH1fveGzSBnjzuVoQecOkrumUeHvDYCH/eaA1wnPjNJlyuNlVxZnmmLD7F8q62j4CeTqCNt
MPY5GZQ1PpYc6g+4EQtc7LBuMcpaW0yAFaO0GjTxoA2k9gwQnlgwiagGj1iQoQcsOEpOzF3R23ef
BUfg4xYETQrroz7qot5K1M8vjzFsLUVxAt8ziK5+9xZ2BaYUTGhHbE0BWYzNBOIY8efagsFu+Oge
QhACdMk7LP4Z5UyDcb8moGqblc7oieHjScA3U7Q/ZEyC3zEtOAJwfNYc+MACkh31AUMP+GCU3DPv
PLTPByPwUR8kBYSod4HJvQugpyMXvOdW4hJ0NZSFjD+6mM+OVLlRixuwFeSmxa/0VS3vq1ZVlAMs
JBXsB1oqOQS7a8CixoHdv2pTYIezoVIRC6rirFWgGx0wmNLpHJJIFtzcE4t26UkeuKCt5XbIVoi8
ojwEDqTK9kLN31x6pqcXP2HxscG5T1IrbTEjCfaOy+iOmhGvwzUrqRo+VvypBcqXtxBnIHzFuJ6y
oVPGCJ+GShSPxgmADgTJfkLmafv42RchI/DxCEkLkGi8Nklp4RI1k1rg684MC4oB32Hq8oeKq8LF
+enZY+wzLj8X50fqFec8rhj8u+GeftFUUq2glyc3o1eo0fDFkLdt9fm2kSp1I/GAfl6qz77ePWiL
0Lpeq5p5Le82Da9aKlo+RkQeCuq+3i7VcehF3UJp5CJZ4yPgxbJqKyUVlJN1pNAizqW+c3V952qk
cwVZDIYiCgOWQ1Lat7QZiMSxeM9QeIn0xZYP05dsq8dUworGHnh5c50Gb2hwuKTfkvRLg1PaXdDv
T2j4IjinzZRT5SvanCAkDf7Ck8dmq5hMJPO8vKANy4UTW4ZPCD+1pgckMj7SVm1rxrnbrAVZMd4f
Fv7pA0yyom/Vnr1BgY4/w3FyYS4grOnpM9LnwPE3CEiwHX2Ds7/LK5T39rj5m52qdzN+gvwrEft6
pngvVH+9nJ3TSBALgxn0Kn3MJmkXs3HcT1uxiLCGLB1LyAa8AW8NoxUzvhr8HR6V+uVvxRtfjQp3
/IemNzJKDDkmBld0I6g1nVsKP4EyxeVbjOgEUiUSTj3lE6PaoqOXPPApmO24X9H4zDif4f6GWh9o
HYPlJz006Z84unZLL9OIOKRj+QPHCWnkjfGni/hfVvTgimMAUmFh0kEMPPPhb+Pnm1dLYx60LCtu
/al0OKo2BWTyWgJIrh0E0PdsX2m+UDdovs59SoGEnGR5l1L6Mjgw3Xcg/WF3pdikWnAONT45JNgE
e9QCqzX1qAl2qI58uD+V/l88kV5hjElsxClAKVixw/a6JWGWYRdz4DV8B9rsXe2LUgOTTpzF4z7D
FF/+MuwoHJXzsY6CoQc6ilFyzzzy/YbJ7POuYgxhtLOIU+ikrO8sosw7zEpZLymEZxzjc4zkTM7U
6Wx+8uHsPQ5c1Hohxhn07k96rDgzIwMtWkSg4xYZJ/fMu3nXEOYz6n3wcXu4YmCPtHe0CdHRL8vS
KYjlKwBnSSGJH7ECJfCc4XhvbvvK4Gzf5tvetjhLbHnw/KotGCGgHrfgHjf3O2yTY0SkmRLeXhw0
BFjzBFWhF/JAkFUlx6ra7WjyFG4LJqoYrxle5CloNspAnAfs2mGGqZm1h9eykNmkk4BZPppNEhqX
BsTLb1Efq8/eCsKIxWf1PS0L3LCYcngt4gnZnCZAnA0Smg2SztintLugX5oNcpoNko6UjMsXivEq
YV7vz+CO0sHH4ArzyFZHZFHki5xoLCUZpf1MAtm1sMTx8ZR6u836n0hOh3gruhxMl3lsUjrDcEh4
sAMZIWUR7SX9soIuYH4X9EsKZqRgihXK0tyW8tzmaG5LaW6r1mR36IhPseNI2IE9UyZ7Tb8fmFgw
3mkz8PuoDTCoesEPWGQYQKkMbGxy5w60yh80jpb1YrNdqlb60YFHDY2aGE5TjEtuW8Gvj/D4FNH+
cS8dLWpvpP1a1OqeUZo1U6pKyQG3adfSp90qT7mCTiANmNstN/HtZstaYRRHmX0aToOcY//DnGM6
MxkxE851FvxAAbYQvX+l7cDyODQeaWxuusMrUqStt6r+Quh3DWYjqFaYtyIIItghb0ZUpfgfuiMH
9FM6nWs8gvYIGXB7hCQPfOOaxWgbrigrMFoKLoiC7QtfnGMuznqKr/t84N+I/Buhf1Pyb8L+JT2V
cORTxZ9aiPnWlrUVikoIGBY+LWhJcaigMfRAQRsl98y7gpUWj2CWitQY5TgUxRLoYbGeXeyBI7y/
AX55skvUyZyKbKTmJxOjfoRA/QUQIewflInUO/Xx50gtodHKwhQ4uQIeQ6pWkziCgHF8AKxvJ3PC
yekoCaGEruAAr+2IbnsM+IKWt5OrHyaxdYyUpWFGnP1B5PDgtrs7Bi3i4d14YB/fHRcOOfd3C1F/
d5yn6F6620UxcU4i6sRWE5dGhCQHyBlx+Ijo4PYiJc4djsdwRY52Y86gBFG5hLXyBzE0fQVz/vcA
1KvGRgplbmRzdHJlYW0NZW5kb2JqDTEzNCAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQg
NDczIDAgUiANL1Jlc291cmNlcyAxMzUgMCBSIA0vQ29udGVudHMgMTM2IDAgUiANL01lZGlhQm94
IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+
IA1lbmRvYmoNMTM1IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwg
L1RUMiA0ODYgMCBSIC9UVDQgNDkxIDAgUiAvVFQ4IDM0NSAwIFIgL1RUMTAgMzQ2IDAgUiAvVFQx
MiAzNDcgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgNDk1IDAgUiA+PiANL0NvbG9yU3BhY2Ug
PDwgL0NzNSA0ODcgMCBSID4+IA0+PiANZW5kb2JqDTEzNiAwIG9iag08PCAvTGVuZ3RoIDMzNzcg
L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIncV9ty20YSfedXzOPMVghjBoOb3nRh
xdrYkiNCa1fF+wCTkMQtS1RIKLY/KX+5fRsQIgnZrmR3lZWqQAy6p6dvc7r7qBq9qCrrlFXV1cja
KPYqhn9+K2N4xpnKfRoVqrodvThep2q2JpZYrWejFz9Orbpej8bAGSepqmYjfCsSVX0a/aKPl3dX
ZlxEiV6uzDiPvL7ln9qUkdN3s0ZVzdrgl5b51PS+IdrMjJMo1QvZv5jVwrFY3ilj46jUQbQZ2yjX
K5OAGDU9rt7EuRKWnd+w3F5/5+93sv+jEfOVJeMi1jymxXuNtFQf3osJLv1BnOGYI47fG/PP6u8U
q5hjVUZlRlGglxCppIhSF1uMFcbB5xgRCo7NJSSm1Mv7LytDvjQpHHh909KvAke6yOrfjStBH/XS
eP1wfQMB4sgsr4iNmT+BnJqlNGr6hXmY1NzCRv7wg8HQgB1xHAwoJNeKyGZFDgZUJ6RrYjtd0QDU
VfGfsU5vv+39+N98S5JgkFyecRZlmctUBnEufbDK2nAnbMlGHU6n58enGPJEH1YGt+lT48FN52bs
Idpn0WsIRAF5c/guupiQSyt6XhyeAQU9OlXtagGBwW2q+Qw3yOpZ08zNuATPP/Y07kghN8YuSpKc
NGMv+6Ba4lk10MZmIGkCiuipsQmoFr6ps8vXR5iWQr5QB8qh9h6yuQDGlI6dVCOrFmpU+MhDGLMy
ozyNfKHG9Fw1o6uvU4uio3oPers+PXV55Ia3f4XcOxs+MdUlCHc7u/fRj6qBq5dlCSw3d891aBin
7N4Lk0WFbkwM3rpCZHCyWDUU1lTfgSdTCOSBmmKCZHBbcQvGIAHuN/yRcnC+qkVGO+bfRUMIWSAu
WviRz2uD4Vsw6ZoOaFf1XUcdp5Bps/ZePsR51H5mLhUAgbX4aFCH+oEFsuaqiFyIe3BsDrg9HFSm
PhHUwe1BePxU1Abow1HzwOslZjbt8NI6wcvq1DhE5eqVcZ6Sn1yiDozF3GdAqBq8LAXUIAgjFrnE
Y+1iljvj8MrWzNLCnfWBtAR4z4Fhy4NpTHV4wINMfcKDg9tJuC83/t3nwQH6sAfBktKFrI/LkPVO
QHx6eYQwwVkMJgDYFYIruHoFLkgQUhxC2YE6RP86DSBJd6KE5EthDYBpUyySTO5knQNayrd3EX10
cM9wh4gMnPxRWM9E9gZGodw1dMus/gz5XRKarrcD4zIor4OBYeoTgRncHoR3YdsXmAH6YGDSEvK2
i0vRxcVxXABM0POXcI+tvpDV+XRyoKolggKUud8EsABOrF4trr4YKksKcAawItU3RK9btZAPVwQc
avrykt1e6pPztwha4HK1WIPCCD0sfc1gdmuw91m0LRYvOpWFiA6rgEGHfO84L5w+5oTIwvdw3iYh
bEiIRF9MAhmzoJN1RpIgB246OxHh+DrGCq1OsyxUctd5MBYP1oiEXvNzif0qtK2LuoUO1SDYKgLd
VBiUoLwDkwEQsrDjN+JFOC31PNrOuDgZTDcgPZFr+zeyTLdJQwSqbHvrfvpwoqUF8g7WPSlbXP4m
UmdCTZtwdk0JFsNHxRXn/Ozk9DH3KZe28zPmJ7hAVJUyxqVpyaPDJhSphKIQBtXwb1t/+PiIcEPM
XNrm6kMoqJ/4kKYRYY/L9fx+ueC3lipkL2Nxl6qFTR1FQd0V3AIuxY2SM+RoNa/bWi04B6u/cRfv
Nl28pN7kjv2CZxtMbFm3tOhpgJip1g9Mnd3wL56Zk7m0rGXXgr+KKAg6TmaFvl/ehV4hp0x1OA3w
niXHA9oVdN9Lg36/pGclPjqh1Tk932JgCrh3uMDRAE4R2X9A0NgQlouxxxz8n9Cr0J8sV4o3CjlI
C64RT93yoMa2rdnQGiERWybu1BQ7mmkq+IJYHjk/CjJfIcpkIrPtBxTuZgBj6TIIgnCS2kQOIWLK
8nlgoDZcCBWhnxe4wzEhfLngQVP4AOLgHgPGIUJbUD7BQH+mw7axJoXJZbgbF+ow4gxvD8K7dtqn
yLmzex99GHQw6G4YdCbvBHYEYB530pMT9XrCGMJPuZg/ThSvZdfPl5Mzqm2JCJhA49eLZJJshtak
u5pYSflmal5AZvQvpcfM7P09PXFuXr+V76m3QfWOvlVC741ckUBeJhCAuKuUWRcMGSz37L2E62Gh
NKCEcRCxXXK7ZjKWZvK9niBSM9RmGvGb1wifeH+tnr83fd9+t03f/vY4MN+mWq+38L4zlPEg+Oo/
rvifbf5Tb5wigO2lzXopshPZb5NHwxZdpII8urrl4YqquKeCXEI9aySt5NheWj1T/0LHbGh2CcZB
33wWcgUQF27HXzVXNiHLtYPirKkBzAl3S33zYErdzpdUvSx2WtiwAyxBh0FBTaA2l8AO0cYhJPgE
Rps0L55Mp2dg++O3/UEeQwmk9ouvyouqcgqMuOoin/xlIy/2FGyPgwDHhWcQoJKZdmErSjYLPEOz
kaM2rdTj6c1Dy5PgXD5BqjgPiZLSfcfhVQkH9jg4at42WPkLSZaNQ8dBg63see5+3fZj0vNjmEdn
oDvll5UmF7tbyC/2xNmOJ0TGVsFNWNBzdMLOW7Qnv4os7/UhccrmXDQtzFtUi9fojxIgBfNk0e5J
EBLx/+0W300fGSc9JA6nTBJSBiYHmBK+wzvP+PrscdGOj6D/dHHfRxLydgGTYQkY06y3vJGwD+Kh
HPnz1d/SeezKyOW53Wma864WJs8kKDjy6ClMsSbXpzSB5TQG8Ti2GWKBPMGBtRQCzLIpM54ZBw1D
f/B6TkkHdsHVWWJzg+0Mdi84BEDTslLNZ1jNmmaOw0Cmo15TF9uuqXNFFzT3PIxCm6z+CGakeom6
e92oFmcZ6LxVzV/4iYYDnM4WdbtY3nHrHbN5Xx3ohjX538PFMVUJss5SF5rJ84HGDB42FjTtzeqW
J5AFd7JOqIo6Patx2JUUgRVjyaQa/ToqfFQUVrkUqlOmEgCiPFPACwmxakZv1d3oqBqVUYlIEyt6
8THEoIgz2ARHZOjJW7wKch8g9ap/ofCfUbgHcgotVepUHPlCjekJoq/C0UL1HjLS9enQl0buye1B
OFQUpjpQfmfvLnXHpBJSwqNFCXR1nuzBHOmQzCVde2hTxAgHvp1iM53LN3UymR5fnL4x4zIiXEEO
AJaD4GpR1/l0o9COL4Q67Ivh7SzcYxSZaslrW7v304f9AX3axh/ZJsY2wiBDMfAyK0Q5NNNcjJAL
Eo/pUiwwCoXbVCtPLSM14dZtfIvN4woR2OovxoETsLf23HRbuPiyagySVpTb0G4bl8A18HQlYLRz
usYoFFqYZdMN0xA71gabUpE54601cy36x4k49aFpsSmh8RD72qbhAwK9kZf5/fKRHiwy3MFD3qzq
R5vn6kh9CMayYo+lz1mXIJgW13Lw9CXh4yU9gwNPaHVOz7d44bH/xoUiT4l0PoqfNfnzugmaXhma
dCQSS6qY2LRK6dhg6i/6K6YfRYrPDgGcAmJb/V1qj1mbQ1ocA6yl+ie2Z7lSvEtci9eut1Szjepk
OFrJFn/NUmDfE9W98Yx6bvH+iVJzQXDezJarORcyzE2RBSdarNcGwXmc0qSA80J9/ZiPvyLbr1wE
GvKeFbifNeqBWRZ3vFPVSj5wfbhmxvqjCjv7JeUjFZO6Xa7YKoxZnO+U0R4QuD8IBHHnJidu+nfh
1c7bNgyEd/8KjnJRO6IkUky3QuiQFs0QLwWCDoKtNGmc2JBd9O/3++5IRklrd5J4d7wn79XdQ18Y
tpZg2OJRjhOnM+c/zC0UNVd3UNtnZNwjUEvTHmGxR2QXY5BuxWG6htHHjfpYBBq4CAFvItjI0oZY
ZHJubR5b23HYKNyo+J2exjc6ysC58FDmSnqyS4iko86dCvu2FGBV3HxK6Js5+3jEX0u00HQMVwLq
MUT/HP5Oy9Sy1rmN0bEoXowuBgZk54IFMehIAN2CPAAgzA/5DnM64ih0+pSQEP2zfl97Gx1Cve3g
3Wska1l87Hhqii+Sof2xN2sV9uv5Ub4HmHZZvGfWtQWHuYUXS5zWXo6uaZoTiQ/UQ9Fmvd3p37BJ
Gm2Mar/fY+Dd9uKqlh2ERqgpY7zdj8N0jMfOlZ6fUy+Nw14TcKefUUsRY+6l5iiYkUcBPt5rch2W
b/t8XZ/r84o90+dPXlfm1UsfD2Xu4xFtXXXm8mksNYvYc5r9W3bCn2D/H/RFd3CmW8kEUppVN7Pm
MwrGTxCi/Pw2tjRfze330mxmNuD1g1PTVpxNnmZ1iQLWZMB2thKaICDsByCxgQPNhCQTeCQwznfv
XviyBkzZyvkVV6Rn7adsI0kmKGWaFrZ1jbJLmLvUSxlQweOgyecSS8wEX3t4TJh6EVK7KLXmfB8U
UCXNfAQFhg2atWAS8qXthEJCJqo1NnD+MiBc+oBbjS9VfwWQM2kqATl4gzS0dUqTKVoaHznXlejs
rIyTTxnACVQu0XieIbEVgjZmBgBejSKIAeBuouqFSkRnmkzhG74kEf0HUnwq2gplbmRzdHJlYW0N
ZW5kb2JqDTEzNyAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgNDczIDAgUiANL1Jlc291
cmNlcyAxMzggMCBSIA0vQ29udGVudHMgMTM5IDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIg
XSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMTM4IDAg
b2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiA0ODYgMCBSIC9U
VDQgNDkxIDAgUiAvVFQ4IDM0NSAwIFIgL1RUMTAgMzQ2IDAgUiAvVFQxMiAzNDcgMCBSID4+IA0v
RXh0R1N0YXRlIDw8IC9HUzEgNDk1IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSA0ODcgMCBS
ID4+IA0+PiANZW5kb2JqDTEzOSAwIG9iag08PCAvTGVuZ3RoIDI4MTEgL0ZpbHRlciAvRmxhdGVE
ZWNvZGUgPj4gDXN0cmVhbQ0KSIm8F9ly2zjyXV+BR3JqxBAgeLlqH2JZNfEkcbIWnWxVPA8MRcma
2JJHou3NJ+1fbl+gqINOUrNZu4oC0AcaffdpMXhRFNoorYrZQOsgtCqEf17lIXzDRKU2DjJV3A1e
jDaxqjaEEqpNNXjx20Sr+WYwBMwwilVRDXCVRap4GnzyRqvlzB9mQeSt1v4wDax3xz+lnwfGW1a1
KuqNjycN46nJfU2wyh9GQewthH5RlYKxWC2Vr8Mg9xxrf6iD1Fv7EbBRk1HxPkyVoBz8uu3+/gd/
fxD9Qy3PV5oeF7DkIW2uPYTF3st7eYKJfxVlGMYIw2vf/6P4nWwVsq3yIE/ICrRwloqyIDahRluh
HWyKFiHj6FRM4ufe6v7r2idd+jFcOL9p6FeBIk2gvf/4Jgd51Cvfeg/zGzAQW2Y1IzRGfgI+JXOp
1eQr4zCovgNCPvjVR9PAO8LQPSATX8sCnWQpPKA4I1kj3cqKD0BZFf/52nj7q6OH/89VZN2DJHiG
7kUJGDq37lkmckERigUu66pePC6WczV5dVX4SZB4Z+8+XgxfgvpD0PvotTPEna8Tr/bDANU5TOBk
AwoGvc9r9STYCx/UfqMe6/VitqhAOoouiJ3UazBUmpIMMVdMytwa1YBnYuQgHthgsVTrmjHuV0tB
Vc1qV0R6cagg3HScJO6FCT2Q3wYS58CxBv8FWXOg4y9IvGd/YGOCKEojZMNWt05TkWVuBbwRXz32
h9ab+DoCTu5MXVy9PcUwEfClOlEGlWQhujJATOjCcTHQaqEGmQ0suFWSxUEMcRPYTA3pu64Hs29D
s6yFWgtymy48Nmlg+sm/Ae7cHWYCNRGm3wPqY/DToicVJDG4gu3kgmibCyQ9X5Kiah99ZoaOzcs1
mA+tuMTsFXlVfeLHmFgJG/WvAem9P4Si4FE8TNclkUP4e0NcQF4RXpC0U+Ad8jmm+hygcDZn5kiy
BnC5FIShBYtWeHxPJ2Ea4ObfW3TlwoMFuoWj8oE5850Ksmmg1bVXSdoEJ3BaTgyVuB4LM/QZC/eS
M3O9NfAxE/bA+01osiA3YkAdt8lcG0klxblvsGQUb3xjKRJIMeoEEgcqgqxT1Bg5GaiZDHfnR5by
BqEsfYMZumSUxoeXONDKZyfY0yCVmF4NMvQZDfaSO+atfo9psAfer8EQCpKLAJ24BKMlwUyuTjmv
olejAs/hzVG7e4NJErKL8U7UJedETN3gagk6MasHN3P6Or+knMkcIGtyTroYEueXI76vk+INJuSa
tpbyu5FvKWfMHDAwABzdE1oaQ8lQVJAsNyzFYxd/LXLO6HpGp1YKD6E+MEmze5diAYRFg3UASwTD
uE4YrBN0sIMLqIdFgrO7Uz75MSmf1ZQAGakJg/lCQQXJmJ8BL91sStIkqjhmPeFxsO+UOu71SAA9
447HCZmn3XoqhkyyT3oc3uuLcUq4zhnz1hml23mPKjDeFbRMBlJzAl85ejcZn6hipaobznLVF/pV
De/LZs/zMJTF8zR7XkKehwl71/NS8TzuLGL5lnI2l6Qadt0uCgz5UcJuZz0WgtyOkdnnLPlcIrji
c1Z8Lm99zt2CHsa3q7Kq6vumnrLLAWhy80CLhlhNV+Q1xgnDGar4ZeDaXFGrFLlJjVxSIrbo2qAV
tyubWpUMnqpSQCgFTRUWY2VRNiwy9EkLBqkG23kwfwpKzChhDvGljAU8p/v+GafsEsddVKD9XtpP
7pjbrN9R++D9jhrFO52Daee6MG5dFUMfnTTzxkOszcZjzzOYMDX6ItUSd6hGhPvu4ux8F/scsRFw
ol5yEdr43Onid8VTIFoBQyEj98nQSRaMoGrqR2LBb8rPtwAZYq6+IURseMFn1OdaODz5hjJ5vVQ1
85rerxa8anySVRxT5FGlXCHY6jRwoq7X5XLO12Aw8mJaNqVa8GU7vhnl2wknZ0WCBKB6ksC35EI5
+bntlBO4CzOs2jwQEJJATvHDEyXvSiGZ+Bjjr/DyHDJJJIpGDZ/R7h19P3KbdUGbIfYFkCBogz2V
8V7v6OGJBVjwhXyTCPGBEKHtoqBPuY/UFPXWRX1KEYLbFWZvLY9UTrASqOd8hF0cdY5OBU2XDlME
7Rmtg72jNhFEbsFyhWg01qRsKWEqpvn55Sm28TNdp0CfCf9ecmZut10lYOb74d8D7w1/m4HnZv3B
P/6XhL8EOkd2G/1n6u2YY5+/Eiq/jRXvheqfV+MLGmEjYTCGrnXbOljbzpfRdnAJJaePl9TOcNh4
vAGrdkOGXKHzh51w/2q7/F68Y6tWLPrZl+30uyQ5XJFWIshuEdgidFoxUWsXcdgtxRU2rlCK3hPp
0NF2WjLi0HYgoXQg194Y0yjnwcTjXIp7TG1Y27U3vfa7Wv3hx3z/ipffJ5JzHIggeCk+8NPW+D9P
xB9cSUYx3J1dOKFhgIvTrLXKQby1TZ0hsqEEFPVzkKp/ljW4uLvyeodzYuTq8WOntCqpq678lT31
e4FtW0w17mBCoIe3nZuL8mvvQ71ezNCXoYJU3Ihl2IiRPqBwhHDvnI/+ocKta/5PzTbyU35HxFpA
ZQyxEX1Y7ggluecNFkDtKFANGP/4ZJNLHJKbRm1+o3fjkzGEiz87hcPm2bZ1OygcAu0vHP3kwlxA
2iTHaI9Ae4tGlOggN65ohK0tjdgSLRZj7sepdeJT88xn6mw8GV2ev+fxoGCMc+gH94polOrtvHWg
C4H266Kf3DFvS6wmzAPqY/B+fdi8o49ka2IdoIlfFIVVkHVnAE7jXNI6YnlK4BnD8d7MbPO+1W01
dIMjN1KJB0MJdtZffWOwe8M2J0M/1NwuWgpnBK3JVcmdUdkLAi0xzjTOfq6XyjiaU5qJ8Cu8KiYo
GWfRXmMdD262UxrRDPVcNXN18N2tdL+tCMx3p/2F8lk6bCikn90b2+E1pVHW0DjIaCzrguWQw7nc
L2QTP4FeGfIvtcq2VeQZ7d7R9yPGcU6t8ra/EMXxhRu+vRTmtZqtWRt3h4mOOv7nHg2zhUKxjr1F
/bC81Npn1NpbLBhYQl8ffwkZpGtscQT3Kt/sTwRWTC+mvhHdfiD+4miMMeOf6sBjOi7h3lISoTNU
17CioV23DoPjTeNhc3Ppo5R1tVpPeVaDV3e0oOkedCUoqzxOxmjTHTw+RbS/HqT/GFK2X9KuqtUD
oyyWTKlKJQdYJK03Z8TyVjnKO2gQoZTQ8S33OM1qza+CN2VhavYrZSebmL+ZTXTbRWrpIkd+TONd
CvmhrujdqfeFtp2IxPJ3AoMX9DTSIFCPgv09DUsJEFGngojM8vVW2dxWGHI1S26H31LO5nw3JjOc
5hioyqqq75t6+p2Kif6mYqJ8O3TkTjMZuTlGBWkGPfQLT5mnJzx7dnOWkTmVvzLDVjzBljyDLtx4
C5pzU+zujLuu5SIKVEjBj/UUUyFiTlUtC84liXBg3pAm6+4egkgSvxNJVbd8P2+BMS+aroj1/jAb
xflzdZihz9ThXnLHvK2zSb4DM1Rb+yj7oSiWQJ8X6+BiB+zh/Q3wi9EmVqMJ9QahmowGWv0OzvYn
IILrPikdqrfq0x+hmg50lgYJNl02DsJM3Q2iELKCbQ9uBxPCyeiIJL2DA7y2g7PF0IGxcDD7BRgZ
AMIZzAw7RLRHvlGomQqutLZ7t6C0CDpt2VrsyYkoZCKbSk8KB3Hy34ENBgmBzDG2NNMzAymxMILr
ASuBKTAxMNGDmWtsBHEesOVqDNYEFTA2A7axIeYCAAfDPfEKZW5kc3RyZWFtDWVuZG9iag0xNDAg
MCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDQ3MyAwIFIgDS9SZXNvdXJjZXMgMTQxIDAg
UiANL0NvbnRlbnRzIDE0MiAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94
IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTE0MSAwIG9iag08PCANL1By
b2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgNDg2IDAgUiAvVFQ0IDQ5MSAwIFIg
L1RUOCAzNDUgMCBSIC9UVDEwIDM0NiAwIFIgL1RUMTIgMzQ3IDAgUiA+PiANL0V4dEdTdGF0ZSA8
PCAvR1MxIDQ5NSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgNDg3IDAgUiA+PiANPj4gDWVu
ZG9iag0xNDIgMCBvYmoNPDwgL0xlbmd0aCAyNzQwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z
dHJlYW0NCkiJ1Bfbctu49V1fgUdyZ0UTIHjz29pWN94mthvRbWc2+8BIlM2sLbkUVdef1L/suYGi
ZFFJup1Mas+IAM4F534OzorRSVFoo7QqFiOtg9CqEP55lYfwGyYqtXGQqeJxdHK+jtVsTSihWs9G
Jz9Ptbpbj8aAGUaxKmYjXGWRKp5Hv3rnq+XCH2dB5K0af5wG1nvkT+nngfGWs0oV1drHk5bx1PSp
ItjMH0dB7NVCX89KwahXS+XrMMg9x9of6yD1Gj8CNmp6XtyEqRKUV1+33d9/5fcr0f9aifpKk3IB
Sx7S5oOHsNj76UlUMPGPYgzDGGH4wfd/K34hX4XsqzzIE/ICLZynoiyITajRV+gHm6JHyDk6FZf4
ubd6eml8sqUfw4V39y19FRjSBNr7t29ykEe98a23ubsHB7FnVgtCY+Rn4FMyl0pNXxiHQdUjEPLB
jz66BvQIQ6dAJrGWBTrJUlCguCBZI93JigqgrIr/fG28/dXBw2+5imKnkCTPOAlMlhuVgJ9zi1qx
LsYlRWRYq4vSR1yMeAtmlp1a8BYCBX2w4tNH38RB4qnNE/gmBIM+VY16EJIX/sBJvVTT+40wnAvt
M5BE3pI9sK6WAlbr3YtlV+35ZwwlIEvzWIE4cYoJzW6KOy+JOgVJlnoTuMh6U1/n3ZG68i3IfEu/
73wDmpxN3kNIQzSdQqhgZAS+tl4aaLp+Uoy0qtUos4GFIEhyGySZCgObqTH9NtVo8XlolnVQa00A
hu/BY5MGZpj8M+De3UaAJsJa+Yr4APisGEjbJNFw2TZvTVdJ0d5o5fd+EmTgpBBsuMCqYmTTVD66
KgZHQ+57s+pUTbGeJJDpSIK+iAD7hg8pfudNKTzaMX/riqprhjUV/O7J8RpYaKgSBLqjC9qmXHbQ
cQzVbdY+yUGYBu2/GEu5YsJSPPgoQ7lhhiy5ygLjvO7MmmqoCoMuZegRlw6SM/Nw69FDThuAD3st
whomPtNxV2u1kVpbXPoGK3rx1jcW9IYUQZNA7OsE6y05o6h8cFAGia81NcgI07FmlKVvMH1LRmkh
kawDrSCPUkDYs6BNg3TYggw9YsFBcsfcHLPgAHzYghqSzLqoD1MX9Ubmh+ntGYQtxXDsXUJkWVm/
BeXRnlCccu9UXZRtCQUU4Q3ODQkNBTxvaOplGwi81HvCiI3cBzMHopILKhg4goqqM0ozAdRLIsOM
yoHZPdMxr5bq3ZyP3HXP6FEhWlfCddnDd2mxbsu22vcdBImxg75j6BHfDZIz82jr2UO+G4AP+i7O
IdlMV7GSrmJZ9t0NTzW3oHZO5St3R9fTyakqVuqf4LCEigFMb/XixTfUNKgSpWBshJatmqNzm2pW
1X2CuaISRqbHHGsUViYqSRl4Hd1VY7WRMpVB2qAvVkvi4dwgPBoeIVeP3Js2hPPkei3lpUgn0mJk
9PlA96V9S5dgB9YxaPqMeZt7u7gsFTNa9qh24XwGQaJADYyTUIGMOk4S14mlSbC1m+oTV+lq1lbz
YD+yQrjMDEYWQ49E1iC5Y97FHRav5DX1IfhwZMVJEGZdVYh78ZRII5xIx3HdbYIOBDdQgXSHinvP
9dXF5S72JTe56yvGP1U/cX2VhsZNasUPkFldtvWKm6uSTsgIquJvW3582AHcEzI3ubn66FrrM19S
VcJst3HPn1Y1r1rqlS4aRDRVCpo6C5y4DQQ8N+VKyR1yNedMvewFjrVd4Nho+yqQQgsyUSKgFD6K
RDsY5z11pvCBlkPVo7MZlkLMTtopRJF1SegitmBzDvk0bCIZZJHBF4KPvw0zFv4VYzhBOCNREaJG
fLpMXnu0bvzQK4VgDZUeR5XY64sBNsf5WSTcvUJ1yDU2GRGmpz6UfcxEHKx5qiarC8tdnF3OxHRN
guNPtZ+OcRIfmVwFOpyOw+SOuRnOxgHwcDIavR1yDgymk79LYkoK7k6dkwv1bsJZxr8Suj9PFO+F
6i+3kyt54TCDCQxJB6tetA3eUIJ3sqSyTbGLI1NOLrD9FLJYf3t/x9942+WX4h1adWLRZ1+2s//y
HUtWiaDMROCLsOsFtvNLwkbp0d6+xbDMoIIi7dgR77eTvGOhmcUHb4IFjSsStGIoc7zHKoMJq735
B79v1q/W5stXvPwykUjP4geOl16T/AZi/i+V/dyKQwE6WY6Pns6P3RTt8uMzXLQ0RupY0FUe8c0B
LxBsOPj0wC4VkcGxcHMIyaV7jeV1CH1/Fp++uS2oLmTexfXfrgaKzHcdNNN7H9txTj5J3bRJzc7S
c4N6akKjMjiPDhi1P2ImcubeIWAEaDga6+vFd6n2wOpb5opbTStOjvnrdOhFUWi+1whSokGGcxZN
m38q64cNnTRVv3ziHN6lguSOhUoLuYNt33hXY2ivhhr/GN94fz48c/4/lAZ4L6BGNPhrekMm8rvh
oyU1mZpaz4wLI4z//DrIu+SCbqvdu5RTDdvV3gQYwYsqGZwAGXpkAhwkd8yNmw91dID2NXRw/osy
g8Ome4x1CWMkYTAgYhzjDJhgihUolTN1MZmev7+8wdGYHmWIcXl9dbpniyg3W4Fe2UKgw7YYJmfm
kJtOWWhrZp/4IHjYGmnYs0bS5YanA7/4NDopCqsgvhcATuNcCg1iQXQwPGO4Bn6Z2VaiKNmOtTLB
0diKldvyzMgPGJjkLEQlv67QplZgij8rPlOOAB9LjTQ8Iat9aRM4QQmeKoU1H6tyTbmwdhmBPGdM
CCSQ+amwEZiQSQosOAXgXrADPdngpQHX0+NPVYzM83oniWhxtqfHUeT+gA8J+FEuesEJJuWHpemM
JoyYr2NGmzsWfurHQPwG49V4tz6GayE3XNDumn6h8OHL5Yo2AcxMQMobp+jz4aki7GqgkRq4Bu2w
aIJQ2MCVfNEXXluqBdSVBK2IoxcyR3XAifjUVLdUf3IoN/imuGGpVc0M1RlW4wzCYCWs26Zk0Bq9
h87AR1vdBv1q/7pKv2cTzlbNXLUyZDuzP7KZcehe4y2xFLvybhePTxHtHxsZ07l0ct2cVWrDKPWS
KVWp5MAfZ+gfRiwflKN0ZRmPH/gp0K4a1gWsnoWp2bd+L1nNH0xWdN+scymaCR+tlh4hGowlnvmd
tr0gRTee+piJ6qIE/9bstDXEHTi0qT7xvpq11fxLdYn+gC5UbqDmiTKZzCvn9xXGiPZQERTodwwn
jRF+irEPpf1c9ht+MqDcsfsI8bIV3LUsSj6XnWChDXRCoQM6QiYtV2Q94/AwJ2hf8x65EcFGrvso
cGHo0IP9LpOFx7oMQ490mUFyYp7mXRtJ8l0Q1J5huiEgyUTAIyIduLSDHWR8HHpyvo7V+ZSaXqim
5yOtfoGY+QSIEIHPSofqnfr1t1DNRzqD4gGMbJphO3wcRSHko+0OHkZTwsnwCAcICzg6wybaw+kw
UlDYwsHih1GUJ2QZm6OIjyMYIQNr3R75IgZdlVucgeDuLGM2gtIhZAm2bmJrw4gFtpCDyDaOGIf2
yBYxiItNg4jYApuwh9IhRBB1yVZawolgiBa2JnN7YgsnhGEgkejmJBQ2jNIhRCl8RVpjCSeGhwXJ
4g5wXAmd6QyxhfYj9qeLaU9mghPiqxM2fwSLzG5ROgTgbd3F2CiJKOzMRGxpv6NPiH7p6yMoHQJ0
QiNs/zMAAQJZ5gplbmRzdHJlYW0NZW5kb2JqDTE0MyAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9Q
YXJlbnQgNDczIDAgUiANL1Jlc291cmNlcyAxNDQgMCBSIA0vQ29udGVudHMgMTQ1IDAgUiANL01l
ZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRl
IDAgDT4+IA1lbmRvYmoNMTQ0IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0Zv
bnQgPDwgL1RUMiA0ODYgMCBSIC9UVDQgNDkxIDAgUiAvVFQ4IDM0NSAwIFIgL1RUMTAgMzQ2IDAg
UiAvVFQxMiAzNDcgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgNDk1IDAgUiA+PiANL0NvbG9y
U3BhY2UgPDwgL0NzNSA0ODcgMCBSID4+IA0+PiANZW5kb2JqDTE0NSAwIG9iag08PCAvTGVuZ3Ro
IDMwOTYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSInUV9ty28gRfddXzONMaglj
Bne9WSKzVtYrOSaVTZWdB4gEJXglUkuCVvwb+Yv8Zfo2IEgKtL2ubHmlKgKDvkxPX073nE1OXkwm
1imrJvMTa4MwViH881sRwm+YqixOglxNHk5enK8TNV0TS6jW05MXP46tul2fDIAzjBI1mZ7gWx6p
ydPJO32+XMzNIA8ivVyZQRbE+oEfpSkCpxfTSk2qtcEvDfOp8WNFtKkZREGia5Gvp6Vw1MuFMjYM
Cu1Vm4ENMr0yEahR4/PJmzBTwnLw9Mv99Vc+v5L9H5UcX1k6XMCWh7R4r5GW6JePcgSX/CDOcMwR
hu+N+dfkbxSrkGNVBEVKUaAXH6koDxIXWowVxiHOMCIUHJtJSEyhl4+fVoZ8aRLY8PauoacCR7rA
6v8aV4A96pWJ9eb2DgLEkVnOiY2Zn0BPyVoqNf7EPEyqHkCQP/xgMDRwjjD0B8gl1/LApnkGB5gM
ydbItrbiAdBWxX/GOr3/9uzHP/ItSv2BpHgGaVC4LFNpGkRRFvljWV8Tjs80LM0g0Q39qvlqic8H
49Ig12rzaAYFBOCxWql74viEP7CqF2p8t2lmxP4EcbLAvzAOk2tVTav6IzGaAaXbmtU3WEIQnj3P
o7CLrRq4HUOT1v1i6QS2CSF6I4hhrMfGFu0ndWli0HxNvz+DGak+G72FXIU0OYUcwJAHxsY6Cxzt
PpqcWFWrkzwOYnBJmidBAukbxLka0O+qOpl/nprnLTWOwXzXpScOdusX/wy5s3eYC9VFiIIH0s/R
zyY9FZkmLojjbUm6FiTR4+jntwaDX5kQvDhHwHCyWFUU6AQCDWWtp9WpGiNUpFDEKILRiID7DX+k
1JytStHRDPhZVwScOcIlZo18XoMKCwBApFvaoFmVi5Y6SCCTps2jfAizoPk3cymPE2zFvUEbyg0r
ZMtVvo27d2zqqLn0BJWpR4LaK87K7Tamz0Wth94fNZdDNUvMbNLCqHUCo5ML4xCsJ6+Ni+HcUCTo
Esh+myKUUjAmlYEA5dCarKXeF8XY0pgFqhexsWSWBkop9qQlVFIGDHseJHDv9SBTj3iwV9wrb/37
nAd76P0eDKEVtEnfomBYsP/G12eYYqkkcaov4Mx5u3qNWZeAVweY/6dqWDalmhMLdFIHCYddP0Xk
JMTbQGoCbnrgBHcXgJ3O15LTCKHEgyWU6zuExkKzWAMAlusZa3zCeMRamAlbEZSd/khfWJtaE8ix
YNlU+5GySW+YgHQkRs8Lss54G77nAtRD7w1QkgMa5G2E8jZCAv+EKojxmNdvYUaz/tPVeHSqJkuF
HmHgKvSqnn+SWBDcJODinJyjZhg7aVJbgZmac4yXGAoMEMLPmpPiASKd6hohJdbyrTY4Dy4XpIMp
HohE04qzZYnSSUvckICkhtgoNquaTWWdDK6RGM7N1ibwAVICS1y4Dk6ixMCGDIRsUGA4JkSowB4b
x6lvsYL97N9V9YHBt5o21SzYS6GksBjJniwSan8i9YuLciEhIKUHoofE/iyKU1xKFvmWJh2JO9tI
WohvV1TUFgYKRDz/UXEzubocXuxyX3DXurpk/lP1kgFTOhR3nSVfFqZ12dRL7pZKWhszqIqfTXlz
v0O4I2buWjN143vlE29SVaJstxPPHpc1vzXU/HyqiWmqFDZ1FnhzV5Dc3GUrJXvI1lwf9aKTMklK
KfNOVz37nSm2fsODgRjHClXDT6i8TgUkO+CYMDimftAQJ/kWvnNWdi1b2SypSomwfqC7Sd1uIz7z
Hu0qUcC1Gw85j5fl4N7xXpvOUaUIU69dxASXUeHHTgTlBCwKlXhQVUl6ZLIU6pGq6hX3ytvR8LnC
6qH31xa2MRpC3unRP6WmpHp2J8DRUP08Yh/yr2TdjyPFa5H6+/Xokkb4SBSMYGBBF03+wnewaHsH
i7iURwsa6zEFDbbFgq55cTfnY/R85+/4BWr7+qV8z721ZtFj37az33lJJF9EkEIRQHV7M3Vx2xtT
fzFtZa9pVMkB8lB24IU7ZUwqilaF3G3f6xEmK+d5qhGXeI31gx3K6tl703Xr//FSy69fadIXKmef
AlanUbH1adTphB0p3A9RyVK/hSlBvCri+/30wKt/gK+++m1IJcIdDefFl4dITxUH0xufxvnaG3KP
WxKWOr34D3QOvEGodYVgAC6aCUkZgVGeWF6y4PlP3eLe8fn41fWEmGM9vPoFtWX6ssv9Z/DtmBNz
Q7+ctNIvHA9tjvpF0ekXMfULTma1k+0yxcPxv8ejHs2iTkns1NX3d4rfA/X+jYEEhsHCph1wzto8
jdpjf4G+Mc1WWYswoncPt/1l6Ht0JZ8g5wkNvv21rO/5srOqOpVssX63df/SOLgaQPu3OBf89Gcr
eTj2q+vdSgD8uqQrRqqlRs4RJnM5XGf6g5MDyPZNf0w9Mv31invlYSxUGxfIeiD+LEPv/Belfv6j
mLSJ7iTRCcBxtHMAaGM8eibf1HA0Pn97ASNjwXcs5Li4ujzd80iUHfOIUPs90i/ulW8PbA8c0kfv
9wc4beuPtM1qbQMz+XDyYjKJFSTuHMhZ4mcN5IL2yPSc6bhv7jrDSLode2XCo0zCphLzTAm/FU3O
sX4wNEA/oldjoSl+LPmb8gIWIrKSNBWxmkg4q2LPYT5Vimr+rMq1ARdp/hWdUxYEEerVdXc/EZOJ
fG7AmRHuC36g4QFnhgfjyLSKmXmeby2RU3Rn+mL/UEclz9SNbPQJASbD5orWVzsnm7EqL0+LWzZ+
bBIQfoUZ6/S1wYSdiDlDWl3R7y9Y2jGMKrgI+NLHC3/Qp8PxigLbgpsTcFvDgdIAZ0wYlmAakCfG
QsNddw5QmqIXI9gPleNxIIgFHu6a5q5Cv6Y7xxu2Gi+1qFCdmQFerlSzFNXNqmTSGqOHwcCrXN0E
zzfxQyB+y86cLlcz1cg47qP1wA7HiWaN+yWa55rydpePvyLbbxuZgfAQVmakaaU2zFIvWFKVMiHJ
5HTLjOW98pIPFDvWdi9j1HLFp4Iz5WHm9uPQKVv3jWXrbOumgt2El9qYrisWnCUx+pWWndzGgJ4a
rEk1LCHSNYdvDRmY4aj4gdfVtKlmX3qW6BvOsjv9h7nMHOd3MuXjQdCgXzGxLOb6qdwDzmW9MXgF
XaHdiX/4K0J7Z5CXkr/LSrjQBzal1IEzQk0t/KXDi/ubRs1r1EYCG9nuRuii0LN/qf/ib80F7z27
zYQIM4HzwGEWoL/wK8Y+axOCxii0l3B7UHgxQKQBJg4uIMPBEShF94sUPj9hHiGIgdoHmiQr2meN
tR9TMqWEJQ4QLt9WocjVpK2zH8YS82+DhrBC3PWeVTT1R1KCkBgBaQzFVuhLAKmCmoFr979nM1U5
xROjeXsWM0M1k69oXM1mIDMud90wJATPuXAi7S2Qpb9ZIT+ZCJloZag+wGAXtQWbcZigV4WYsNTm
4N6WM5pZwlC8nAbcxdQFYg/22Tt64o7kY0Cpackv3tSEbUvF1NgvdyIA6GvQFwMCLsh3UrtEtIew
qJsKDkaojZ8ppoR2gNkACp1O22N9xYLYK/mtMdEuBGGbpxrJtPDiZOtNhpmW04EmWy+B6ZvCWMun
BHUu7jvPTbUz2R8gJYMdRsvR/pbyG2K/5NU2rg7jCl9kweRbZsIS0d7q1FsNiRnsD5pJcWzQZOqR
QbNX3CvfDpJhFCTpDt0lCZJ6pPupaJpQj5v27OaeoUf/Z8gvzteJOh/TEByq8f/KLmPlCEIQDPc+
hXWKG1TWxTpdZlKlvLkukyKTq/P6+QHlvEkp+4E/yLLuayr5DZPvGyDm6G8ulN/z9Ub5MxXR+3HJ
DCW4yd5To3ohcUPl/JM+YMIENua4VDEGX27emCB6gzMMXy+JkU6HRkafqRMfzZ1srXGVMK+KgWV7
j+5iJvIASK/yFjYYvA19xa0SBgsMkzEkmjCYTh5oMUHoZ6hOwborbEexH4d7GNqJw7YsPe0mYhkV
OS1DX+vGajGPUT2jVd6FBIAOWRlFYQaKaBmtyrnhqVQDg4L3Ui0mCOxEPGu1zklwV94E+3oXzNL9
+KMfJhLAKdqcFjYYbFn3lrH13jFtWINsHTORaBg6/6ttx64VqyelTfx0QoUBj8cYoVPnH8AATFYK
ZW5kc3RyZWFtDWVuZG9iag0xNDYgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDQ3NCAw
IFIgDS9SZXNvdXJjZXMgMTQ3IDAgUiANL0NvbnRlbnRzIDE0OCAwIFIgDS9NZWRpYUJveCBbIDAg
MCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5k
b2JqDTE0NyAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIg
NDg2IDAgUiAvVFQ0IDQ5MSAwIFIgL1RUOCAzNDUgMCBSIC9UVDEwIDM0NiAwIFIgL1RUMTIgMzQ3
IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDQ5NSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9D
czUgNDg3IDAgUiA+PiANPj4gDWVuZG9iag0xNDggMCBvYmoNPDwgL0xlbmd0aCAzMDYwIC9GaWx0
ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ1BfbctvG9Z1fsY/YTghjF3e9WSSbqHFk14Ta
zsR9gEmIgi2RDAlG1W/kL/qXPbcFQZqg5GYmdeUxsbvnsud+zl4Wg1dFYawyqrgdGOMHkQrgH6/y
AH6DRKVR7GeqeBi8Gm1jNdsSSqC2s8Gr76dGLbaDIWAGYayK2QBXWaiKx8HP3mi1vNXDzA+91UYP
Uz/yHvhT6ty33nJWqaLaajxpGE9N1xXBZnoY+rFXC309KwWjXi2VNoGfe461Hho/9TY6BDZqOire
BakSlC++bnu8/8rvV6L/rRL1lSHlfJY8oM0HD2Gx93otKtj4OzGGZYwg+KD1P4u/kK8C9lXu5wl5
gRbOU2HmxzYw6Cv0Q5SiR8g5JhWX6NxbrZ82mmypY7hwcdfQV4EhrW+8f2ubgzzqBx15u8UdOIg9
s7olNEZ+BD4lc6nU9IlxGFQ9ACEffKfRNaBHEDgFMom1zDdJloICxZhkDU0rKyqAsir+08Z6x6uT
h3/kKkydQpI84EMTJ4lKwM95hFqxLtYlRWhZq3Gphwl4FeI5AjPLTt3yFgIFfbDi0wdtYz/x1G4N
vgnAoOtqo+6F5Ik/cFIv1fRuJwznQvsIJKG3ZA+sq6VwmNNBvVzIvdtDOWRXHblriBUB6gQIF4Zp
5JwWtz4T5Qq6JfUmcEvkTbXJ2yN1rSO4/4Z+f9IW9LqcvIcAh9i6gMDBOPG1ibzUD+n2STEwqlaD
LPIjCIkkTyjm/ShTQ/rdVIPb56FZ1kKjCMS3XXhsU9/2kz8D7twNRwy1IZbOL6hPwS+LnjROkhC2
+zy2bWVFi6Od3+vEz8BLAVjxFquMlc2m0uirGBwPtcCbVRdqivUlgcxHEvRGCNjv+JDieb4phUcz
5G9dUbXNsMYa+MjxFlgYqBoEWtAFzaZcttBhDNVu1qzlIEj95l+MpVxxYSnuNcpQ7pghS64y3zq/
O8Om0AP6ncrQM07tJXfMg3Ne64H3ey0C3Eh8ZuK29hortbe40hYrfPFG2wj0hiRBk0D0mwTrLzmj
qDQ4KINCYAw1zBDzsWaUpbaYvSWjNJBKkQOtIJNSQDiyYBxQT++xIEPPWLCXnJhH+d6+pyzYA++3
IGiSWxf1xgW91JbpzSXWqJRiOILvFcTWfvcGDBCBTYdYWS7UuGxKKKoZjQYwS/CgAEUaTGpysJ7a
6dSDuhrzD+QN9mour1A4nxDL7I/rJaBjLuHpHVIgfUPVdI5bx/4RvYqFF8tuhzMeEGItlRgPFogl
qbFtyqY69p9NoKP3+o+hZ/zXS+6Yt9495b8eeK//4hzCuy1aWVu0xIFUc7ADoLbvNRpLjt5OJxeq
WKlfdSZlDUxe3z5pS/MTFaMYrI7QslFz9O2mmlV1l2CuqIqRJ7C8bBQWJ6pKCTg9h98aC07kyVmt
ccRcLYkHQ5wvhNMGyx+gIHXcAndEsOZeLDKKzKpmUZknl95QBN812JpNDAcQI1gABAubMy7mLDf2
ZjoXMRsSE2JDgfgYHoECqWjYkDYs/YGtvKk+cYGuZk01948DKgh7owlAZ0LpNCHztPsow3KVHJOe
hvfHUZwhrgSS63nSsrj1TaTHuH42QU8ZmDiwJLpDxd3m7fX46hD7itva22vGv1CvuaJKC+O2tOIn
yKwum3rF7VRJ72MEVfG3KT/eHwDuCJnb2lx9dM30kS+pKmF22Krn61XNq4a6o4s2EU2VgqYufSfu
BuKb23Cl5A65mlOk5nZQ/IlfA/vHABsU5DAB3asj6h2wa2ipLhU+yxIIdTibYcECzvCjGE7rUnDb
rIAzTgo6L4kK0sNSGcXfDTMV3hUhsAxQtT2UWSipLfJmRSBeb7CShl5JNNsHTXMlC38oC1g6prwD
vM416gC35uQUmTo2cFymGoPhDgXY7W1DSRztL2GSdbVXRBgvcb0gKN8h2vGnOs7MGF4O/ROsQPvz
s5/cMW9H0BMp2gfvT1GcZKJzI+rkH5KwkpqH8+dkrH6acPbxr4T09xPFe6H6683kWvolM5jAuNQJ
6jDcPxtDuXhJjwqOa483YPNuQkXo8c7f+TfffvlSvFOrViz6HMt2+V++a8kWIRSdEDwQtA0har2R
sFE6tDdvMHEyqKdIO3TExz0lb1lIufjgTbC8cX1KPCx6vMeagx3QePMPumvWr9bm5StefqVIL2TO
NoXcT8K8Y9OwNYjM8x3aKdV08K7YVIiftekfYKmvXo0pQbhZWoiT152hI4pImZ+9MXXE3PsNYwlK
WzvEkvnR8AynmcbIJGSBl4Xfkcb1j7RWR3//c/WfSWgXHFEenc23L0m59IVoHIuz5QM+5nDcA0NF
npv9h8K7EzrfTphMf7hxWozf/p3H02v1qG0McVLf37soYJVogMLY+MgLHIhg7NlWDG4O6nhngv1W
tL1UVE1wOIBKDTF8B787+I/VRgaBmAeBiPt9yIMAhz0N8jk2/0SmeB6KjKwrp/+3o/Gzq5chco7A
hJ2bpJMkaZskYevoF/Dj2pq2tVX4HtVW98j8tk05PXzqqT+X9T0/JzfVl2UW9DLYKdrMmL7GmhFB
ATU4I/3Y8xz8v2gzspKSgo0GSsp1tyYEWVd1xougp1DpwQ5yPXytqd6M9DABwI/HI3UYwrTaO1Iz
9MxI3UvOzC2OyQw1UY5P3CPyHoTeoTpMcahu371tvljJFzRAjJOxBWWnGAOpnKnxZDp6fwUTdw5x
UTDG1dvriyOLhNk5iwi03yL95My8q7D5wiB98H57JKZjj6SNBs/4uvg0eFUUkYIIvwVwGrtRDbGg
/TI8Y7gBfpndl6Iw2b8apGHT0JPTGy2UX3o5gjnpoRl6a7RqJDDFnxWfKUdg+JVK4SxktebmkOOA
KniqFNZ8rMotTUT8KzxnTAgkEOupsBGYkEm3vdVgzBDvBTt4/DyN4XpLolWMzM+hVhLR4vJIj7PI
3fcT9LWPctET1qSUH7m2NZowYr6OGW0WLHwh7MRo56y13tRshAMkhgrkV6JgXv7pshilrdNN2jo9
8e6xeCRg/IwNgbakK2OeYci2YKfOVnZ3KA66BjdMr/hTaYyAJcPnQjTWw4ztl1DaylLdYhGLwH+B
3BBy0BnxCDNBl8RkWNqzBODA0iGo+Wr5G7MSYDn7zLCl4/rICiO0mi8YyLIq5s6UPtlRTUjI5wQ4
UP8ABSamXRd5fiDGslvro3DvHKl2a1Y9ZPuRmT05WfBn/+hIKXVjDBl4ffjqmt6DfF2G1+Gkqhiv
wiKZeofM1ZxIS01pgB5Bf7QcIJnoGXODLoy9N2jm1HuHccAxkVJMEE0pnLfoQpIaIQeorWZkUycK
oe2TDEX2Tw4FJzr8e06+2WozV80dPb0qx+uBExQfZVuc2WN5pZWLQ7z92+2XHUPQ/757ys0qtWMU
HGzxRJVKDtAskNmMWN4rR/lAacnc7sknZbPasFagUxak9jhNO2Xe/s4yb01rppzNNAJxMW8xD6sZ
CZl7n2nbsTyG6AVnxbhsSghqiBgszzE6b1N94n01a6r5S3UJf4culBbQLUWZTEbd0V2Fxc94qAgK
9FldkhI5SD/E0qxGst9BbcmwQ+T48uSPEC8bwd3KouRz2QkW2sAkFDqgI+QSlRR8vzryuexr3iM3
ItjJdR8FLgwdun88oaTm3ITC0DMTSi85Mw/2E0gWtBOIgC0NHn3E/VCUTKDnJDt9t4P3sH8G/Gq0
jdVoSrNToKajwX+6LmPdikEYiu58BXOHJwccYn6h0ps6Vm+rOlTJ3N/vtR1M0gnZHG4udojIkt/x
Av0AxOv4mxfKz/z5ovyVuMAp+720l3xEogo6mvfEKw6oAoQDoPMYG414Tx+WMQnaHrhDHan2BlcT
GQD3rpvd0/dbqtRNlnv15y6yme6ZUGFN+TqMYgyZcDCTwIS48jCMg3Iz7PHVMEu7Gx5IAJuE4ZDl
dpe1+Ca70j/ZEwmAy6zDYKoVHySJRybJq68oon0+pgsDYrrq6IJRI+2jmkChi4xYRTXjBOkqIDiS
whOZgOBhp8/B6D3u2i6Lb93C/c+2H05OJABqsf3F/h00Z+dAvRS3iwS7sKaU0VKxbQnfNeELMwgm
xmJX/gMnzEOrCmVuZHN0cmVhbQ1lbmRvYmoNMTQ5IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1Bh
cmVudCA0NzQgMCBSIA0vUmVzb3VyY2VzIDE1MCAwIFIgDS9Db250ZW50cyAxNTEgMCBSIA0vTWVk
aWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUg
MCANPj4gDWVuZG9iag0xNTAgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9u
dCA8PCAvVFQyIDQ4NiAwIFIgL1RUNCA0OTEgMCBSIC9UVDggMzQ1IDAgUiAvVFQxMCAzNDYgMCBS
IC9UVDEyIDM0NyAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA0OTUgMCBSID4+IA0vQ29sb3JT
cGFjZSA8PCAvQ3M1IDQ4NyAwIFIgPj4gDT4+IA1lbmRvYmoNMTUxIDAgb2JqDTw8IC9MZW5ndGgg
MjkyNSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIidRX23LbRhJ951fMIyZlwJjB
XVX7oAsrUWxLXhNab1WUB5iEJMQSqSIhK/qN/Yv9y+3bgCBFUPYm2fJKVSAGfZmevpzuOSpHr8vS
WGVUeTUyJghjFcI/vxUhPMNUZXES5Kq8G70+XiVquiKWUK2mo9c/Toy6Xo184AyjRJXTEb7lkSof
R794x4v5lfbzIPIWS+1nQezd8U+li8B682mtynql8UvLfGpyXxNtqv0oSLxG5JtpJRzNYq60CYPC
c6q1b4LMW+oI1KjJcfk+zJSwPPt1y+31N/5+I/s/ajm+MnS4gC0PaXHpIS3xDu/lCDZ5Jc6wzBGG
l1r/Wv5MsQo5VkVQpBQFenGRivIgsaHBWGEc4gwjQsExmYREF97i/mmpyZc6gQ2vb1r6VeBIGxjv
39oWYI/6Scfew/UNBIgjs7giNmZ+BD0Va6nV5Il5mFTfgSB/eKUxNHCOMHQHyCXX8sCkeQYHKE/I
1sh0tuIB0FbFf9pYb/tt58f/5VuUuwNJ8fhxkGXGqBTiXMTuVDZ1NQH1RIc6qdpKXS0Xd9rm6PT3
db1UzVxNOAtuHtrZ4hEiEWKB6BgDsdIpLGodgi/nrSxbTvuqrbc865soiIosVb4NoigjU3xnAdsS
iS0l6Egh4mPtx95Eg2DafVNnF++OMA+F/EEdKKv9FGwOILapxw4YlyOjGjXK4yCGuKVFSokZxLny
6bmsR1cvU/O8o8Yx2G379MRmgR0Wf4Hc2xs+MdVGiG/PpHfRj8qBWkvTCJbrYrMd/IUJu/cDBCqn
uKUAVhRRXixrcLKB0M7Bk4k3rQ84/CmUJ4pgDCLgfs8fKelmy0p0tD7/NjVBYo5AaOBHPmN6GCht
Il3TBu2ymndUPwFImrb38iHMgvZ35lIOAdiKW402VA+skC1XeWBd3J1jMwDq4aAydU9QB8Wd8nBf
1Abow1GLgTeWmJmkA0hjBSDLU20Rhsu32saU/OQSdaAN5j4jQFljseTQdCCM2NUiLNSGWebaUmUy
Sws1HDvSAvAcanjbg0lIjXfAg0zd48FBcVIeF2v/7vLgAH3Yg3CSwnZZb7usz9mBk4sjzLFEsjjx
TuHQRbd6i2mXIqag5wBUCBCnN5CC1nug5/zzChpJ7oEh07r5Qt8w/SJvBkhJS66XwrvBMSEXuVZb
+DTDgQBz/FHThk6Aay6XNfMClvpptwIsVVdkLLRrDLrTBFgNGXAPSL0dOZtCwx2MHFP3RG5Q3Cnv
4rorcgP0wcglBST2MFwJ2lxo9BJjl3w6n4wPVLlQXwgnBMOaqydtCRMEhm6IWrWqcbBEAKNmHOAH
Is95rvtMC0YWVS3rdaid/plTwxjpAJI3YV0tAZTEO+V4d/wCZZNaOqYRdgjyq02LHRi746A5svcd
zV/8FLMa7LgscMtMT5QUoYKENkmautYPUemGLymNZX2/WOKQhJtSrqKLINE/wd6Uj5NDHRMAF/B8
Q++qmjPXTLFogzmbgFVkBCtaqpJmhsKzWFgWm4ElD+OQAb4nDSw/Y44FFWSEbkPvyCZKtLMghIVf
WLLaND7YroYwGiwFIO2pg92CrNOuSwRRNt0W3U0fLoIkR96XqoDzfyxN0jVkQi1IKsJ091Fxuzw/
Oznd5D7lvnx+xvwH6pAzVHowZ+WCC2IKeQVXG85dyT4pj1rSt/p0u0G42aiWT24akDKoa1G2OWvM
7hfNvFc9rk7ENEw2YlNHgTN3CdMDzxH1VuFwaTfcz8of2KNF51EZ48mQotu5oJ3T/s4xGrJ6ICJ1
gkJAJfZ4BaBS0TEMo0rqtTA1d5hR8LgTe6z/mjU4BADn595PFyWtc+/k/OOZo91xq4Zu7q3QqZDi
LAwYcaJ9bAVinpN21nYKCjCmLy9mihrV8GfFP7VQN/zQLtSQiyAIb7HMI9qi3XRK3Xd72CWylUT+
0tkDErcPvL/Cqs9oHqWuWBJ2WkQNLGyfvk6gvHET+sSC7YxXTvxRSy+lw7UNgQ/iZUZISXvitYbp
R1hTsFuzcn77XbxST7dBJIEL1PAdQajDUDIs7pR3Q36cIOcz6V30YTQBN/SGoWdoMv6n4Ikgx+Z8
Pz5R78YMDvyUivtxrHgtUn+/GJ+RhyNRMIZxtBf8KO5ajbtmfpxDZsaUUdRFeNlyR6EkzuRG2/vb
deFdv+6iftPbeJ9NR/+tZvRDBMN1WhQQHWm+pkMhIygkIhc0f0YA8yjnO8Gt3v0cxC69MZcwVyZi
Ma9dLRpvdqlf9Oaf8yavX2dTbzqJ4+6EER1QXPPXW/ynnvuFN84IgKfCpOuMeB7Sr9JX1ktpEhst
BodATiDZp5dA36NDJ5v9z4HHd2jqpTdpYc5k54vJFmck4/nc+rmhc44/9LqlXAQsNifs0XOWou6E
kVv36qVUheudWa8YTg7dzgnAsdQOdJvQ2L2p9D34rh9wGVSOqSO/2X1F+a5B4BJm8AwnH8Q0GPgw
KTghMkoIToeM0qGAdMBk4FTIXCoYToUIO43XCVM6RDz75ZgPwUZGUBtNXCe30OQ5L/BexLcmmqb/
BbMY5iHMMNjhARhmG2Nw2uWIdGQpQUxJLEGfen0BAfLR0Deq9/dXu7Zt6PAxzIN/W09kOU6c6GyY
4GQs49Q3UfT/lPo7wa43YMLJuxvj8wGTqXsGzEFxpxwCzlSTR88nzCGGwREzslnvwipYhaGIOAAM
VTApWsimCU92/E2djCfHH07f40WGrqvIcXp+drDlkSjKgjAf8ohQhz0yLM7KoXrdecl1W8I7ycPe
gLJeeyPtAMwzgS5/G70uy1hBZl4BOUvcQIhcMAAyPWc6hiG36/kgtt0MjUjvPIu1vtTw2XhP2oIL
8GaKgINAgOXPq1ojaUlZZxFaIq8hwhxByuI1rABuYRahG6bVqoLLYwZk0Tll0Yq5mv52ok59qltE
HQI4vJfVNW/g6LW8yKzd2cEqXc0fsrCqNoRnMIt/codlwza1z9gWp5gW17Lx5CcA4MS7oKdz4Amt
zun5Ebty7p3RQpGnRDtvxc+K/HldO0uv8L5ZuEgsCEcL8PPutrYOZSihrPGuwe7gN+wT4IijQB1e
oenQOeol5N60br4QA3UJvqNYOB0+nTETjYh9g/WUY9Pp1FHbQadQ20lE2Inh/EFTOZxstaJ7XEW3
ulz0168Uf2YeMZm3EYrboK9Lzaq2UtMbYn+Yf6ZfZu+5L2T3GXEfK7EWE5gOyuK1GvLUIXcEDHaY
2W2X9wrR/tFCXF9mjbTOY+hNGZcL9KwppkvqfeblRi5n3gHFRp3QGIBZhLcj/MTvSoRFF3qLXlYa
nFUta8gAfL1fzPn7rJ5JLYAszFSola15Q++qwbEAXemH9GPQwTXtNWt4Y96/vmXOJ1b8td6M/qA3
n88hxzol7MF2j740OAh85u5/xMPIAZwt4oEJxxUav2OetyKatxKRf6BnS+wycyWY/BEDA0rJ+J1R
ymKt48y2VA0PGuTvVLIs8mDGA4dLREVPQ5SWlfC2qq6m8jZBGMRJ3dAshUd7Q+9ukpEDznuWBtv9
zyb7+h9T9/S/QXFWHncNLsm2qTYFEB+cJoapaJhQ9xm2c2tHHtD+Avn18SpRxxPqzKGaHI+M+hlS
7zdghER+VCZU79Qvv4ZqNjIFGAqa4gxAO1V3oyi0QRx3H25HE+AB59GnGHe7G5kctu/zdBxpiue8
HV39sGaKkyAHIVuwS3iNevFLShxQYnF/b2H5T5VllAQgCALRGzUGingnu/9vLKDZZ9sCb3V0/Ax2
H9Rsu4DtvJdfUQg/YJKTdhn271uvhOUhvptV70tAWxvH6BDQFZ6QGmhssqpxH57t6B2BojNr4BUb
5lUpcCcIcwdgscsRwGQC3u4p+FIV8gwsA1v4+DIcRfNw2MnKVJXJgzYLitHrGw+6EY1fal3P8Qpl
bmRzdHJlYW0NZW5kb2JqDTE1MiAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgNDc0IDAg
UiANL1Jlc291cmNlcyAxNTMgMCBSIA0vQ29udGVudHMgMTU0IDAgUiANL01lZGlhQm94IFsgMCAw
IDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRv
YmoNMTUzIDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiA0
ODYgMCBSIC9UVDQgNDkxIDAgUiAvVFQ4IDM0NSAwIFIgL1RUMTAgMzQ2IDAgUiAvVFQxMiAzNDcg
MCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgNDk1IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0Nz
NSA0ODcgMCBSID4+IA0+PiANZW5kb2JqDTE1NCAwIG9iag08PCAvTGVuZ3RoIDI5ODIgL0ZpbHRl
ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSInUV9ty28gRfedXzCNmawljZnDVmyWy1t61JceA
4lSt9wFLQhLXFumQ4Cr+jfxF/jJ9GxAkBVqOKylHLhPAdE9Pd5+evpxXo2dVZawyqroZGRNGsYrg
H78VEfxGqcriJMxVdT96drFJ1GxDLJHazEbPfiqNut2MxsAZuURVsxG+5U5VD6Nfg4vV8kaP89AF
q7UeZ2Ec3POj1kVog+WsUVWz0bjSMp8qPzVEm+mxC5NgIfsXs1o4Fqul0iYKi8CL1mMTZsFaOxCj
yovqTZQpYTl6+s/D7698fiX7XxsxXxkyLmTNI/p4HyAtCZ5/EhNs8qM4wzJHFL3X+rfqZ8IqYqyK
sEgJBXrxSLk8TGxkECvEIc4QEQLHZAKJLoLVp89rTb7UCRx4e9fSU4EjbWiCf2lbgD7qhY6D7e0d
AMTIrG6IjZkfQE7NUhpVfmYeJjX3sJEXftQIDdgRRd6AXGItD02aZ2BANSFdnel0RQNQV8V/2tjg
8O3Rxf/lmyu8QXJ5AMOsSKxKAeci9laZzN8JI3diUre1urjbLhHjOPigTQIu2oDnwMf1ulHrZtYs
/mzmarFU5R1zbdv56gHgMQDPEqIkDdRbZlO8Ey6HhdW6bQ78PIYIdBlcTaA7l5Fi7OTYa+Zi1qyC
A1I4YKrHcVBqg8f4NXV5/focdRHyW3WmrB6noFsISKcBu2NajYxaqFEehzGgmBYphWkY52pMv+tm
dPNlap531DgGvW2fntgstMPbv0DunQ1LTLUOs93R7sfo59XAzUtTB5+7q2e7ZBgl7N63Og3zoNER
eOsGE4OVj3VDyCaALFzfYNacqRJTQgqXFbcgBg643/AiheB8XYuMdszPRUMJMse0aOAhyxuN8C2Y
dEsHtOt62VHHCSSoWftJFqIsbP/BXB5Q77EM8vEwWkw9gdbgdi88OgXHAH0Yjhh4YwHDJF0eNFby
YPVSW8y21SttY4pqyn3qTBsMar7oVYO3IIfaAvhg8XIx1iRmWWqLya1mllaDJZ60grSdAcOBB5OI
6uuAB5l6woOD20l4XOz8+5gHB+jDHgRLCtuFs+3COWcHltfnGDyJhGcSvASji+7rFcZTiskCPQfZ
gvMeRGMS3EGA2WC7/EBPTGB5P/XRKl4NF2ASpE9fm8q7LX232sJhc6z9GMAPmg7d531Lh6FIPS7g
uy9Y8aksxmfNHlQWttpBqJh6AqrB7V54B+RjUA3QB6FKCojkDqm8Q8oyUpQ3XHCt2SkZ/MrSVTk9
U9VKoWc4NRXBenHzWVtqWyihMFw5OEnNEcIZli5c+ICpBaDtQPMSBLT8ADT0NoIkoDkELaZ61udl
/Q5FeiofyXIANQqa+YJXZ/V63szDQyQjNwgjkE5g+PhGlml38D4G4AB9GMC0AI2GS4dkfq4gU0nV
vizQFQMnUwLyi4pLx9Xl5OU+90uuDleXzH+mnnP+kkrA5WLFzfdsUbfQblM5UFJCmEE1/Gzr3z/u
Ee6ImevaXP3ua9IDH9I0Imy/4s0/rRZLKTqud4FFNVULmzoPvbprqGFczRolZ8jRHKULTr6RQt/E
cer7sXjXZRrpMkEn8JAhLcAneSDfLX30dKEeebNl6uyOn3g6oB7IZy27JqhT5ndVZG7aCVnwHpx8
MkxF+GgwSRUHh/ODJhy4BF/Q9FxhT2CkGOHVsXDI+lH5cxbpxdDHrVhU6jR4wfpf00Ti1Z/Q1xX9
vsMQKYJLHlnutcVEKmfwgfxb85LIZpXCA6d+JC2Y39sqLhJ1v2h6D+0k3aFd7NAuGG0cUVJGC/SF
9LGghQ3H5WrLhJZb240EJXLUXESWzDDnS8ebl/xxK9PeBFUv0LhULl4EOsqnN/0G+42UzTUAkiw/
MJfox+JnfLKsqVIkXfwCtoNAWRf9xBBRU8SzBWq2kiRwj70PhoQ71GdNN/eATzX7tiMGbLc4i6Tv
ME1pxN3Pw0lW7Brqo1Qs1OFsPLxdhAspTjCvHm49Jg6nYuwK41N9/PRvko4l8e436dOJej3l3Mq/
krB+mir+ll1/uZ5eUmQ4ETCF1hNdVv3AQ5nrQjeSyXG6hA7LyRUI+APiv+/5GIHo/Z2eZXevT+U7
8Tao3flTJfTfyBUOKooDACJ/n4/BON57/Yqj8g2JGHsZB5mBvBuxjPfBFItXStUHMhaUNP6+05jS
EK35e91361eb8/S37vUpWilR64nC2al4CVzRc6rrnCqz0dHekuo2gCs+FREHPrVFJ8h4dP7r/vpP
3yZ0Wzg9W0rPR/0CXb7EDz7WX8MJd0orKopQof4JxQLHQrVpMC9AmpwLSfFMWUq/+5w3Qt5+tFjt
xWT54rqibXEwuXqHcjOotb38cNzmf5fOLnl4eEL/v2v8eerYa//L1s9oPj32fPVdGk5vHGROgiwL
5BPuNlrrgqZd1xgrmC65A4+h5hbASU5wAd94/l1QHlgh63vtQwjqZWRsdwOPgoI1MKJBEcinOvz7
ymT/TW+T3sCmWg6Qxg+XvXBZYotpgw+ax4udxQaL4+7SfK8xcLmiXi2GAp8Fv2i77/XLlcYOm+2e
NB9p3oWebO1LX2GzjLM0JiKTG8HWOcH2M84eJgNPwo2yBCsnnGtYRp+9wrYt61VCErnvQROZftp5
rq0JUWODvcpApvo/SfSQQ/dzPGTSyzF2B2kg2f8CU3e+Z6ck/+/UJnqDeALdOY1aShippI0tJlOY
G2Z1u/B0XlKvcDR0uMvRmADJBkebgy7dOWiDB7t0pp7o0ge3s3AbJqlQTe6OO/UhhsFu3UEXIo06
Ni+zrqHBoKQCiv02Jr4SAc9kTU2m5cXbl2/wftB4ixwvry7PDtzh4vzE0CLUYXcMbxfh3lQTQptx
uPWYOOwGm3k3pN1tDkyoqz9Gz6oqVnBNb4CcJb7vQy5IF0zPmW5AWG53jaHLdiNItnOphSFxjHfo
M+YKqNwtzTWYg7C28Rc2qDkyUt2DORKQhQqGpCVFai3Dj7CrmpdVvdlQaRRxM95TM9uif5Js+B0E
4arXRoYhlsJqMOecty14eOO1W5Yhe0oaZF9oBxlUijZ0ey64gv/vMFM46MFcxy5W8Rmids0SG89z
g7cu9h5bia6yUzXiBFGQRqfOQ2xyb7hLghC6IVD3OSghgve8rbzRe1KHzW557Y5VfiTX+xvlDprS
jJvSPLjc+cJwuwbboZXZILwxnJP6JeqODdqWokowpkLlB6qadA045Se8jBm3SviJHQEwbzWqDi8f
NLZDDrQOh9pBaa1mK+4uih0Y9xwiPDxJu8W9FcK24+M1Zvv7lsYt36TNGrWVdmyJe9Suf1PMJYkY
Fj7y4Nau1qwr+CGPMntYTenGBvYbL6uNu5qcsh8uQM0swIYKAmRGI0lKzdReUKGKZxpLgppQByaM
vG+75A1gMpi6btTidkkLVEbSYN3M1YJXwNcLYpvV+Gi+bDNnKfetWQqZ0FpEneAmE8BSgOT8TE0R
G7xa+GwJEnUO+VTAooioCWrpubkXR4hVb8WHUskzHkSlI5BZosw0hmca2SFO9vHYQIdXSFTtR1or
gSI+69Uf6NlO1B+mnqg/g9tFuJDSYo9g02xozwAJtUHSSVUODvOUx0Seoj272CTqoqQiGKnyYmTU
zxAZfwAjxNmDMpF6rX79LVLzkclBTGxUnBbYV9yPbMG64kIcq4+jkpZS4knwiPuRiyzQejwdRwbT
SA4LNz/sJEPbnf+7y3JJghgEgeiNLImIeKe5/3r4CMGsUsRn24BVUoUtvnSf3hir7kFegOXrsigD
UEefo0g3xY+B8jIJg6RqAnST3OSDVfdcNCZbXTodCMCc+K8s9wbkJ6ar/TTdAZpIj1hFYU+zgLLb
ipi5HyQBOWx9ZVEcVlmLL9kpT9Ule5AE0IbCq+yDodV+elzLPtbyCoaTQBLg6e0tbgeJfHHrcXU7
FmjpXreBJEBD0/FuwvKj5rRLos1Djlhl9Y+pTPBLgsQuc5AX2HlJ/i1zEB8KZW5kc3RyZWFtDWVu
ZG9iag0xNTUgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDQ3NCAwIFIgDS9SZXNvdXJj
ZXMgMTU2IDAgUiANL0NvbnRlbnRzIDE1NyAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0g
DS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTE1NiAwIG9i
ag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgNDg2IDAgUiAvVFQ0
IDQ5MSAwIFIgL1RUOCAzNDUgMCBSIC9UVDEwIDM0NiAwIFIgL1RUMTIgMzQ3IDAgUiA+PiANL0V4
dEdTdGF0ZSA8PCAvR1MxIDQ5NSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgNDg3IDAgUiA+
PiANPj4gDWVuZG9iag0xNTcgMCBvYmoNPDwgL0xlbmd0aCAyMzYwIC9GaWx0ZXIgL0ZsYXRlRGVj
b2RlID4+IA1zdHJlYW0NCkiJvBfbbttG9l1fMY8zRcVwhsObgX2oHaGrInayEV0s0BQBK9EyW1ny
SnK8+aT9yz23oRhZVFNksQ6i4cy5zLmfM5fV6FVVWaesqu5G1kaxVzH8468yht84U7lPo0JVD6NX
V7tUzXeEEqvdfPTqx5lVy91oDJhxkqpqPsKvIlHV8+gXfbVZ35lxESV6szXjPPL6gZfalJHT63mj
qmZn8GTPeGr22BBsbsZJlOpW6Nt5LRjtZq2MjaNSB9ZmbKNcb00CbNTsqnoX50pQXqxhe7z/i+tf
RP+5EfWVJeUiljymzQeNsFT/8CgquPR7MYZjjDj+YMyv1U/kq5h9VUZlRl6gj+CppIhSF1v0FfrB
5+gRco7NxSWm1JvHz1tDtjQpXLi839OqwJAusvo/xpUgj/q78fppeQ8OYs9s7giNkZ+BT81cGjX7
zDgMah6AkA++N+ga0COOgwKFxFoR2azIQYHqNcma2E5WVABlVfxnrNPHXycP/59fvlNIkmecRtbF
qcrAz6VHrUgX1yVFmrJW0/UndG8KSUDLql2o6Q3YPgWDTSt1bcbOwXljxh6sudsJ3pIXOVbPQtFi
+BeYPxks9wZuzbSarls5+chksquFi7p5Wq2OXDK2CURR4dTYRUmS++CZtHOMYw0quDIGv07Au17P
jC27I3VjPAh1S7/XxoEsl5P3EMUQQBcQHYCRRMZ6bSNL10+qkVWtGhWgFPg9KzMK7MgXaky/22Z0
9+fQouig3oP4rg9PXR65YfI/AffuhiOGOrTUS+pT8MtqIFezLIHtIVldFiIFSMnO7w0IBA5Hw95h
KUlks4UgsGj7NWRZpufNhZpxEbkiEvRGApn8jg8paBfbWnjsx7y2DZVU5E0VVI53wMJhWCFoSRfs
t/W6g0KgF3q+f5SDOI/2/2YsFSoIS7GCcpbo+okZsuQKfHPwfDBtDqV+2K0MPePWQfLAPD7ntwH4
sN884Hr0GuVEmhx3PbC+s3oKwe/l+41Bb0zQpCXmAWQw5qgZl7CuP9XoJgf2ovOWlwW5GNLmGqE5
5j0iUTmwmE9LOYE6Pc608FgHsgMzm+Elcrw8Nn0aU88fMD1Dz5h+kJyY+/LgmFOmH4APmx50KV1I
mDgPlndi+dntJZiBwj8FBxTsAPh+AxWIHODAARdQHSEkc/2JftGeaP12gaENBp/eTJlKXTdg7iVh
NYwVIvwZU6rd3xMMPWmxtjFbrLwWq/C4J4GwgbpL62oVHXvCZdC7Bz3B0DOeGCQPzDs/nfLEAHzQ
E2kJo0pXuTpHxOKIdzzu3BoHRSwP27ezyYWqNmp+b7C2NPM/aFV72at6vsfxbkOFCnoc1adMBzDV
nlx/pi1WFZw4cGRqJLofwM1Atlkz320zbx6RI287ti2zXeOImUAUFBQFMZQ17sXkfgiEB+MsdVwE
yeV8bb1kkV44EQww5EEAnXHfaULm6Q6ePeW7Afiw77ISJOqc19WvOO85r6Duk+kJlnlpKB4zCO08
g/buukN1RZhvb15P+7iQFA4OGfdC/WDgNEMzZpA/O5gFShzdEzDjvK3FSwk5pxSw4iPB2quGj/f1
byvBIl73PIUa9O1C/YZdrYQEdeiuhkMj18K94XXxuGnXMrImXVKLiKr+gmahLqMg/RYaIR0ue3cq
ulCkUIt6XytgjoERKzCX9T4Lo5RPDgO5pApIRH0URTKplh1M0n2xUhRr98QwSB9a8d5cy6YmCpgj
UUwKYJwPMISx9TTUjHb41Cqx4JXU2nmiUHgtQxQvDSOcEOWZRWnxYjwPksC4aVI6+cizBH7WdKlc
EzjcUeEEaLOCn4Vai1K4w//HGZXm5WGsepFUAh3Oq2FyYS6gxGMnOiZ9CRxOKkCCbUiqbuqPZeqf
/JPSKuMU4hGpkFxxevJaXU8wU7zmX4q3Qv84UbwXqn/cTm6ouSTCYALTxCHS0qyLtMQfnlMyTk7W
VB4p0Dww4+2evnux5rFW9v7Ov4cOn1+LN/x1VsBL0rP6jrVzB+3kUfIBLILD7mqzI8s0BivV4oP5
SkW+9utrFe6+BgXrK+SKLmBEHySFVoTZkVKc4OjyvxL9m75et6iI1/N6u+DeDUrhrESn/IvttKQq
WVCVLCWxg7q+UzcTdT/o6ZrmpXb/kdMiIS4pcYFS9jd1c/sGzVFoWcSEvWLh/ZmHhEDPFItB8sC8
eyhk5UvSF8DBYuGzFBEH51geGWVcnXFKykj6ejK7ej99hxWaXxeAMX17c3FkCZ+nB3leWEKgw5YY
Jmfm8LQQILQZGD6OiE+Ch62RJj1rZGQMtIO2kal+H72qKq+squ4AnKdQk6nEIRZULYYXDLfAr3CC
gN3WHrqtZctSL+WaUsgvdbsSZkeKqUcstKWAFC8bPgs1EnqqC2201H8gHXdYR6MDHq75UNXYUHPN
v8Jm3hLTmnnzBoZeaIwWvrYG5HWE68NNqvmCq9THIuxF1v604I9Fb87TwoQzM5koEVCFlGYKH2aK
jGYKF6aEUvc1FO2XX5ikPzp40XfPr9V7MRPfcItjea7fvDnd0WyXJexKKBf41oKBg+ujZwG47kAL
+2S6/erJdMN6qEBlV4EkNOChAiI1802oaqBiz+WWHoGW3wEplbmU3wE9PD5FtH89MYSMZmmUBNc3
6olR2jVTqlrJASoP0xIj1isVKPFNk2nmtqLprt5vtqwLWKiIc3dsqV4KuW9MoaQ8NNqS7XQFoqDr
0NPNnKYRC1lQ9jKEYhCGfvB1JgHkQgAVEkA52SYmo+VRKr+1nC2ZPbwfVUtcGKwW/R02oGah6jUh
wyxJ6waLIgTVZk+o9x2nLb4v6YyZbNbCtN42igEwsooqSMD8vtbUyTea+mVPxBdYTu0z1Y9Nveew
hOeuqn/bfJLPPfZdfMb0prhnnB5zjimoZUwVgEzIrXX11KjNnWThz81WKOSkJabz8DjzONxjAJ5s
zzeb9ZjJbp5WKyWcmA4HmUCkKJecqIVPOMwaziQfkrTXyLLkXCNj6JlGNkjOzF3XqULTFlBSJtHg
KDAIRJkYeE6kl5cG2GnG56GvrnapuppRX43V7Gpk1U8QYb8DIsTrs7Kxula//BqrxcgW2HJhWoEn
wcMoiR3Yhner0Qz2EOMERSxCgNLjA8IBnMMKB3ffjf47AEfd55MKZW5kc3RyZWFtDWVuZG9iag0x
NTggMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDQ3NCAwIFIgDS9SZXNvdXJjZXMgMTU5
IDAgUiANL0NvbnRlbnRzIDE2MCAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9w
Qm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTE1OSAwIG9iag08PCAN
L1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgNDg2IDAgUiAvVFQ0IDQ5MSAw
IFIgL1RUOCAzNDUgMCBSIC9UVDEwIDM0NiAwIFIgL1RUMTIgMzQ3IDAgUiA+PiANL0V4dEdTdGF0
ZSA8PCAvR1MxIDQ5NSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgNDg3IDAgUiA+PiANPj4g
DWVuZG9iag0xNjAgMCBvYmoNPDwgL0xlbmd0aCAzNzM1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+
IA1zdHJlYW0NCkiJ1BfbbtvI9d1fMY/DYsVwhncjeVg7wlbF2k4jZVugLgqaomU2MuWl6GTzSf3L
nttQlCw6cRdtERvQcOacOXPul7PFyavFwlhl1OL2xBg/iFQA//yVB/AbJCqNYj9Ti/uTV+fbWJVb
QgnUtjx59dPcqNX2ZAKYQRirRXmCX1moFp9P/qbPN82tN8n8UG9ab5L6kb7npfBy3+qmrNSi2np4
0jGemj9UBCu9SejHupb7dVkIRr1plGcCP9eOtDcxfqpbLwQyan6+eBekSlCerG57uH/h+kL0XyoR
XxkSzmfOA9pca4TF+scHEcHGP4gyLGMEwbXn/X3xJ7JVwLbK/TwhK9CHs1SY+bENDNoK7RClaBEy
jknFJF6uNw9fWo906cXw4Oquo1WBIq1v9L88mwM/6o9epB9Xd2AgtszmltAY+TPQKZhKpeZfGIdB
1T1c5IMfPDQNyBEEToBMfC3zTZKlIMDiLfEamp5XFAB5VfznGasPv44e/i+/IuMEkuCZmNBPwyhX
CRg6j1AsEsZaFxWxZbFmzSe0r4UooGVdL9XsEpQf69lCXXgTa+G08iYRGGO7FawVL3KsPhN+jb4f
Y/AksNx58CJY6t6zoZ8gqkngyhiJtXw0cn5A5fXXEDZ8esunykmzhvcNcgUHFhGbZbF3X+61TPwL
79RDsXfsLu9kwVOhIDtB3R64FhxGYZiqifVhiZyDxb1/iR0WoJ8A3HMKThrpuWfy/khdehE8/oF+
LzwLHJxN30Mwgtin4OSAEfqeibTxLb0+XZwYVauTDN4G903yhOLTjzI1od+2Orn9OjTLemgUAft2
CI9t6tvx618BD96GI4aCaiHNP7l9DH62GEk5SRLCdpdzbF8FUOOo5/de4mdgswC0eIsZ0cqmRQ9F
T2kgWcS6rE7VHHNhAlkKr6A1QsB+x4cUe8u2EBrdhNe6osqQoSMaWOR4CyQMBgiCVvRA1xZND53E
kJnL7kEOgtTvfmMs5RIhc7H2kIfikQky5wr8ztndKTaFejVuVIY+Y9TR64548JzVRuDjVosAN0Kb
UUTE4WHpBt1bo2fg+pF8/wx6MBAsoNAcowDCDBShZt4kh4/mU4FWgvhnQM3LkiwMUXOB0BQjN3Up
yWA4reQEqs0k0UKjcdd2xCCTwSNyvDrUfRxQ5zKie4Y+o/vR60Q8yneWOab7Efi47kGW3Lp4CXKn
eitlb/7hDNMc+z+IAFbIQHi3+5nSENjBgj5P1awBv8z1J/pFrWI9Qe+GDD+7nLlb6qICpa8IC8Ou
r/afIaowiro7grnjey+VEhK6KkRfQwrrquGH+LCj5BlpIfT6K/ANw25JOFVA3dh7mkRh2UScopMr
LdY+iNQvmLLVg0ARv3VsQgnK2d1o21Xt9tBnLFQSO+ozDH3GZ0avO+K9Rx3zmRH4qM/EObSGfYpN
+xQr0fqO28sPnoVsm7rt1Xx6qhYbVd6BjkEZ5UdaVSd7VZQdttMbyqjQAFIiTbQDU5JMQc24xfSH
HR62qJXE4T24IlzbNEy3rcrqASnytidbM9kGW/oQPBWhBeTRTFofclLuWwxVdwTJ4/xssWKW/EMj
ggLGLAigZ8x3/CLTtDvLHrPdCHzcdkkOHPXG61NtkA6Ml1GZTPQU65FUvgijHPU8hz7E9ofqnDCv
Lt/OhriQiC0cMu6p+tEz2DhtMZVgj4TlboMWSHVZF2KlkIyTC1jxkWB1quLjrrhZCxbRuuOu30Pb
LtUNlt8c0ohFc1XsGqkW6hWvy4dN3ciIEPY5RljEznFwZ6nOfMd9CxWbDleDNxU9KFyoZdEVCoij
YwQK1GWiKHE9X2R3A5B0fcARFXxkCVSVa9l3tBmwhhlGbR8ZCiFEK76dkg5oW8gtaN9xWiVHRhem
FhzYBfeD3OmheQusk9iJcAOk+HGGKV4qRtlniJcN9zbqK9yfDbI68s84DLwTEn2WJQ7pRX7+KJ8k
gloThX3+Vu7loUJ6zIHkhzprjqqyesEjmFkMylvwnfXA+nGS9LOXkYp6j/dQNKx0RNlQZ4IVE5WT
6U1Lagkh2dH0BeNIS5rIUVHW8cW6zEg+GFVQvlQfJqU4zXct9JO8JNDx1DR+XYgLKIoxyRxefQoc
z0uQvKLouc59+ldpvSkPmYO2fPpWXUwx3USafyloM/3TVPFebv35w/SSSn8oBKbQPaLKFn+g18Ko
D1LIpfxwQ5VFvBz7ANx29D0I0QjLzOAPB4Txr93nt+KNfz3L4NmedLsU5AbPa9BDCtG53mxlNMIk
v7z2vlGQ/9rXKGNDgQw3rCiKLgC0+OfTvGuz3pVEZiQPlR5jLwYPOh6vcdSPIeIIwBLGXYoh7DoP
1LQbICIZIChHTSJp+fC8WXU0NaT6Tr3m4eMZlKGAkdkVDUkgnHAySTg4E0b7qdRy8527jPyf5Bcr
efwgvYj2QVtw34Rhr+N+cAjMTsf/T/d5+kUxavUZ6j3TV9CbSh9jUX3X+i819aKQycvikT7Q8bAF
NK5/TPYDfozYTkv7npjsnPVm6KzidiP5B3tSYO9qDg0QuNYbFezHwPeg+zHlH3WmYVCXY3p6mslE
TxczVJQhRUEitKPW+C709iLFDfxrOaK3aOdfZuBf19xkpvoflBu4ZUs5fWBj/X063bPacwk23SlE
ZqArD5sIHGveKPymthtmEHCrSN9sHhveLxUj8XlbUQrFOfSJt3E96csJv3KBdYAmJbw1fyOVQ45r
5DjUTU1FAag+Yjev7xVOVgbrBWSlGzrb0O9js6RVzTu+2jLhCuckqgcmF94G3WFII+NYd8jQZ7rD
0etMHGbTxM2mSXTk+gjCaJdo4wyRpEcMUqdSnGNRp5iAY2z1sIjNuSfjM/V2Oj9/P3uHSonwDDFm
V5enBxqxSeYHo/2yQMc1Mn6diUP/KkAczezh5aPgcW1ECeDueuZB+Bsfo//VYhEpAN8COI2hHacs
gFhQxxieMdwAxcwKwvFZVabQbjDFyXhEE02uH3imOzoqDuc8Geo+7g11xd6kpYrhFChESh4gZczl
zaZRMn6Bu2Ons6F5IOeX1P78NjKn7io6yvfCGdenJGBEDIcsl2eXXggkZ+iCBmm/aM4Vvj4zX7Xo
fW/2HKr1G8g+aXQpivpMbiWTr0FozBkrb4KFFLoi3KnXal2RdnHCOAJHlWF6vYXeKcHudL3jz2Db
XOzdXvLtotvwBxYeFPQLIENLKlA41K27KHSQC91V7dZ/viJxtq/KTbtU0tpVA5UZImVAVxN8l5u9
YrWPt2sBf+WesCJbohC4Kyv1yCh1wzdVoeTAm2Q4EjBisVbu5j10JYlmamtwkAR10LIs6DdBag9t
NIhs+zsim+uQ7QuRRPb5XcVuVdIsYvXHXUygb59iQQHvpVIV60vUV65lh6kUo1/RUJTIPGP7ocjK
UASVqWY6W4wOcJCWCQh0+0DqsVzOYG28AHx3KTvBcttdcCCDQrjj5Y4u7otwRrscSvvEZOAYE2S5
Z13u84slv7Tms0f3IhdiQFopwXDyPW6dgMC6DSF0byGAY8ppeHxzIJjILdw+tfvxgSH8nRn9abE8
x7iFECgpukJIyLhVoKoUTI49hvqlamsMZ+xH8KAscEjFOaimqA0plqFr5A2XWtQLmp3JDa9X6yUj
qprvKUdOWFElJ5EIgmT3687kjuAWQqtqlfDCTw3yuUXdI0QQQPPoop2qt6r6lc8eiZrwvFadoKrO
sVQLi/x63dXFv0mvvp+2YSD83r/Cj2zSsthxnGRvW7UHJsYkGNrDNE1lhMJWoINS/v3dd3dx7AId
UlWpbc6fL9/5zvdj1ZvVTA9NrVxHLRAu7nVvJPZk5nVtzFh6E5c9WXPb/+ov12RLS1GP+DzDcbVS
UGjE4dQVNBE5zlBev2cqmye7X5pY/I4B5kK0RgeLKef5Cy4HHGWIgT9SHWTt3Sscl/mGYwJ7tNWw
xHFktPSku8e0LT2tAGlXq3jO2wDKoyD+akm5l7Vr/qGUPVMu+qrZ6c1aEC89q3rX9mrsroZS1bJd
sHHZc4vTSCvScLEnw5gl/xOxgFHow57i046hQsbCRJEoGQCsZ8b7F7xKw4VDuHIvRYq+4PBbHnx0
v449FIvpG3noISmFpEN8HrI/T2T3wQHdQFzIS8bydtQQFgpSO6OGOyPHIctGyTtmc7a3MPvP2Afh
QqwUO8xpT9dHdi9vhHB/9vj24eitrTRgafQQLzwMd52Cj+ggLUkyeP+Bxyc6FueJwBFSJKpH8+Lb
FXaMGOYqLQ3ixGqcIE11Q3Dgz6q/06G0yk/MS0QgzHjPGAsYDqFvcS8RgJtj9q9Jzk7v2OejTvG5
dlBjnT08kWYTXufacYmtnLEYIT627GNsF5XyLQrnMICZwOOb1KmbVOcGdW4H344wF7jOgOJK7LxI
HK9FNXE8TTQ7eHWv2bUeP2q7j3ptetWvoRDPilC75LWKyc/pETntUGh4jP14dDCeuJGmuiQvMKpt
aNV/5i24Ksz6dAMH86RFHu5iDR9d7LM5b2zUpRFE+z4X7hBueJjpw8PKDxD4epnZnvFhzMBtDAIJ
cyt3mI/jYvv11+H2P6Hw8euk9YWndO3qUJStIc2tecPft/3kHKttG1e9pwnOpeu1o1lk63ZRXhdB
F21AyGTLHTWM4bm9zy6Clyxuo/X0i4f1p5VvX307vavN9JhCHp/j6cSaT3QXfhOQLtWDsaX5bL7/
KM3ZxLbkEW+Np98umKtJVTo6pihYTI5JRNcRmKZhAA1RPgHEZVhMz+evR0wVYPYVvYYKQxkF0AoR
b/NlQf3Y1UhlwERE5WAaa44gxHXGVwQZX2LhUsYDJAJss8GXFpqQ8hVBxrescYoJ3wEzIKquKTqX
861CIycx8FVByrcKVJlDQjhiIqKxYgFrFooVxbVPN/FzyrgKpeiNZBQSAbVDGOWEqWLYjLAIMsI0
HNiM8ICJCLrU3Sbhst3YJYKMMrJKesgRExGll7Mhzf8EGADVNy1LCmVuZHN0cmVhbQ1lbmRvYmoN
MTYxIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA0NzQgMCBSIA0vUmVzb3VyY2VzIDE2
MiAwIFIgDS9Db250ZW50cyAxNjMgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3Jv
cEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0xNjIgMCBvYmoNPDwg
DS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDQ4NiAwIFIgL1RUNCA0OTEg
MCBSIC9UVDggMzQ1IDAgUiAvVFQxMCAzNDYgMCBSIC9UVDEyIDM0NyAwIFIgPj4gDS9FeHRHU3Rh
dGUgPDwgL0dTMSA0OTUgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDQ4NyAwIFIgPj4gDT4+
IA1lbmRvYmoNMTYzIDAgb2JqDTw8IC9MZW5ndGggMjgwNyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+
PiANc3RyZWFtDQpIidRXW4/TSBZ+z6+ox6oRNq5y+dbSPNAhms0ADUvMzkr0CJnEHTykk57EDcNP
2n+551LlmCQOsGhXbLcU23Uudepcv7osRw/LUhuhRXkz0jqMrIjgn9+KCH6jVGQ2CXNR3o4ejneJ
mO+IJRK7+ejhLzMtlrtRAJxRnIhyPsK3PBblx9FrOd6sb1SQh7HcbFWQhVbe8qNSRWjkel6Lst4p
XGmZT8zuaqLNVRCHiWycfDOvHEezWQulo7CQXrUKdJjJrYpBjZiNyxdRJhzL0dN/Hn5/4/Mb2f9R
u+MLTYcL2fKIPq4l0hL56M4dwSQPnDMMc0TRtVK/l79SrCKOVREWKUWBXnyk4jxMTKQxVhgHm2FE
KDg6cyFRhdzcfdoq8qVKYMPlu5aeAhxpQi3/pUwB9oi/KSvvl+8gQByZzQ2xMfNH0FOxllrMPjEP
k+pbEOSFBwpDA+eIIn+A3OVaHuo0z+AA5WOyNdadrXgAtFXwn9JGHr6dXPxfvlnjD+SKJ0jDItG5
SCHOhcVTsd8LXxS24FNN1x8w4OA+fqyahZhege8tuGpaBgo0Gflo/ATJsNkzFRgNfDVWRC53Oye3
5IdbFh+dhgbLwWA9oZp3KpJium7cp1NeKkNF2Ncjrl49fXoQpAD6gNFpIQITxnFmfaySLlSGz1TC
phFsPoF4WzlTuuiWxJWykAmv6PcZbJzKy8lLyGtIqQvIF+CIQ6WthNSj7SflSItGjHIbWsiEtEgp
1UObi4B+t/Xo5svUPO+o1oL5pk9PDLh2WPwL5N7esMRUE2PHPJI+Rb8sB6o3TWP43JevSX3ugCj5
+aVKKeTo2BtsLrH72EIaaPT9GuoulfP6Qsy4rYxJBKMRQ22/4EVK48W2cjragJ9NTU0WdVNPdcs7
hUnTMGlJG7Tbat1RAxgPct7euYUoC9u/mEv4nsJWrKDBxbK6Z4VsuYDYhMZH3rs2g+Y/HFamngnr
oLhXHp2L2wB9OG4WeC1GjWoiiQ/nYIklLKdUdfz+VGE0JujSAusgsOAuIaYqKOBl/aHi4l8xoeHH
gmIcU0vIwHU1M1FH0FhQS7cCrTtIpdOx9mJ7ZTrFTdzy8tD3SUQwYMD3TD3j+0FxUm6LfWRO+X6A
Pux7OEthuorpuq2fITPoOzl0HwOeuCwpG3OIBCRqKv3nU0WOgGhgQl5Av1QYlg/0WyntWvTU8wcs
/oiUjhU6+Qm9i2c1pnYi+bciD2sqGaxaLbt6+Agdj2oqxjLBNLDQqykZ3O4NL7bEEXxucMUaqWWH
h+EzsLUZDB9Tz4RvUNwr74J7KnwD9MHwJQVAni56eRc9N1eoXcUUPg3NL/MdLJbPZ5MLUW7EHL2W
y3r+np6idd+imrcIFTfU4qDjkZMT6cnUtVL5iT4xXOzqRHIjNYBUCQRt1qx3W8/rO9TIn53ahtWu
cQobShkIj4q6ue6SpuAQAsrDwGM/hFosKG10B7xuFQz6tLOAreLfyq0t2Xza4CjyUTwYdiCdiflp
QdZp9ulwKuAD9OGApwVY1EW8a5VR1ot4ToMulRN0mptdFusTyxQr2nSLYkycz68eT/u80EgNLDLv
hQCvYxntEP5oeCTgvg2GLJPzpnJhjSmahSMLXnJcrah5ua3erhwX6XrHEBgCYuVCvMUBWkB1GwQ2
NUcyk057zc/F3aZZO7wcd8F3JorqM5mFuAy99VuYubS47O0paENnhVhUbSVAOSZGJMBd2trUoza7
R9jadUewCLJSk0nUKN13Sx890+h+sLtnKtQcPXHvjEAmfVZOCsAshaCkk1Dz0rD+iFbHCrvaE77p
7Jsh6m9YG2vxWwB2pW9efYMpwGgGNVfUdZeO9Yb3Yf4V/dbEsBBs0StGMABzYVuqXUvFj7NU8KPG
AVwcuMEZ5hYhwZn3buNWvCiNAJbZsKFHvhBQ44aGgaHJTZKVO0F9WNFJVuwR5FFRO+pwXQ+LO+WO
FFucuYeix8ThogYm+PRFnXRFnXCaTf5JZZ1yCTMazF2tGjl5LJ5NsFKt5F/K91z+MhH87aT+/mpy
RZeK2CmYAHDaZ3qSdpkex/u7pINgkzVdOTjRJX9AqPo5zhBs/3f+Irh//Vq+c2+D5l3+B3dTckoM
3SmGUETeKcZ2YUnZJz3ZV08xBXNovygbeOFDv+47iMdX1wSArFxtcFBhFeCYWlyrr3Tjf/ntvHlf
GyV2qA2zAmdd59Cj4XVCtps8ODyOBk/t3O1UH7qb9PtY/QjuPPEGEAdTJ4NyxrOUP7Fvss438Q98
gFlbbVv6LjUBNEIOmm5HOCqaVrSE8FLCg5aGbi63pwdsbHsB66BfzAPQtZiMEjKDCXiycx1D4Gs5
ZczZtG88lmSAyVhQ/EzXAEXw8Fqh9Um/jX17x/qat8cN49J5tV3sMTdff4YwqzsweAR6S3fgoxvb
D5golCDu7qWxerW/kVG2WOmubK3wXHyxI0BPTUduRf0XMd01iB9Oj63/w3rvgRVLSGEIrDD1DFgZ
FPfKIw9ldHxC9pg6CFfiIkVOB1eirlUZ16owiAmiDqy1GVctr4nHk9n45fQFokSLa8gxfX51ceAL
2GVv0JEvHHXYF8PirBxurv6wGq9fB8InycPeQLWdN9IuB6UOVfnH6GFZWgGleQPkLCnc+EMuGHdM
z5muQV/em4869Y7Vlh37SFH7atuaysRCgeC95U4FCPOg127g8tK0OBjpHmSotDK6FuHsNJJ/NyzA
VzfgS6HlOb4bgk5bjEwmPQ3qkO5K9Wc6+R6Gb63CNi0u+UqHZjhLQy5vMTuQ5P2F6/GW+gHu68TG
rOgJtWmPMJ0RXlP/PP6sS9IOHIhxe7cj1NmQjXjbg4O948NS4z89R47a6tT3qDe+R1XQlpa0KD7Q
AxdW9/RaCxp7vrPRnQc9iXeenJAMfmFjQ291sy6nCw73vICGHjPyb+XWeFMUDj1meC1fKrxj1fON
HyhoxN51vo/uVJDsFS4/59tb9ac7htuRjZ7X4p5ZmrU7eCXcAp92yYzVSnhJHPupZG0raupVu9my
3eDzPMqOYFuvhMx3ltAxHED0oKUbuHM3Yd8zEuhfZbS8AGsTuY9NwTMrAbqhO1hGKYrvez8X5L+I
IgyOTv0odzOcsyJxq2LRQwH1QlQMVBaCn4RzYXRsPD4gvVtRzaFqmcXpqba1aKv3jovPxAxf6+j4
ex19hOXxipmSo2Pv6IwczY0iAbvBw1L8hu8ZQTLrAD7nb9zP34JOjwzUGZiPvIps/Mkcf+KggZPf
M21Njzn3QzTBbVG93XxgjmMX9SBpz0X2e12kOxcVexdZcpH2LirIRZBRTLtQpp+Y2Jxz2dZbwklY
TISmCuqeOYIp4yKvPfQuYOG2Sx/jcZR2OApd/wD7ZdFlOqoV1Gx9/fPFK3O/lVtbst2kVTRME/zw
YmxJy4eolpWzh5fDg5kfF/bMzHfU4Zk/LM7K426o51E31D0VDn1GdpBKhjH1nGEnt+7Ip7V/gfxw
vEvEeEZoJBKz8UiLXyHt/gBGSOKPQkfimXj9eyQWI53DrEOQB7gGAOLtKI6gJVtesFasRjPiyWmp
QANvYQHRTSe06nFo3GE1uvkJFBmwDRBTloZZ2pPChZQ1x8Cf0xIkQW9zJ7PaM4Bs6vQivkSLAXwU
qNemEW/OC6S3SPkQmKdocZznn/N0HODBf88Q6mITIxOIIhNTiIthAiYGFhBdsNAyMTaHqIA7GCKA
HFomJuCwQPI3TA1chbExyHVguwHKRmDlCmVuZHN0cmVhbQ1lbmRvYmoNMTY0IDAgb2JqDTw8IA0v
VHlwZSAvUGFnZSANL1BhcmVudCA0NzQgMCBSIA0vUmVzb3VyY2VzIDE2NSAwIFIgDS9Db250ZW50
cyAxNjYgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIg
NzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0xNjUgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BE
RiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDQ4NiAwIFIgL1RUNCA0OTEgMCBSIC9UVDggMzQ1IDAg
UiAvVFQxMCAzNDYgMCBSIC9UVDEyIDM0NyAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA0OTUg
MCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDQ4NyAwIFIgPj4gDT4+IA1lbmRvYmoNMTY2IDAg
b2JqDTw8IC9MZW5ndGggMzcxOSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIidxX
WW/bSBJ+96/oR/YiYtjN5mXsPMSOMOt1YmcjZbDAeDFgJFrWjix6KDqZ/KT9l1tXk7qomWCwB2ID
YrOrulhd51cX07OX06mxyqjp/ZkxYeRUBP+8KiL4jVKVuSTM1fTx7OXlJlGzDbFEajM7e/n9xKjF
5mwEnFGcqOnsDFd5rKafz34MLuv1vR7lYRzUjR5loQse+VHqIrTBelapabXRuNMyn5o8VUSb6VEc
JsFSzi9npXAs67XSJgqLwIvWIxNmQaNjEKMml9N3UaaE5eDpX/ffv/L5lew/VHJ9ZehyIWse0ctd
gLQkePUkV7DJCzGGZY4outP6H9O/kq8i9lURFil5gRbeU3EeJjYy6Cv0g8vQI+Qck4lLdBHUT18a
TbbUCXxw8dDSU4EhbWiCf2lbgD7qL9oFz4sHcBB7pr4nNmb+DHJKllKpyRfmYVL1CAd544VG18A9
oshfIJdYy0OT5hlcYPqadI1NpyteAHVV/KeNDfZXRzf/mysX+wtJ8oDHXG4KlYKfC+dvZbuciBK+
1JVOwcY3YJgc1qME4mMKW3kwenV5rd6CDzAYKh2FKRgRefm3XFT08c/AEZHvYgiN9sF77VFbtHjJ
ebOel23dfFFPZQM7JgFhwsCS26rpD5oUJLG8DWvEn1yuF3teGxVhmqeZGtkwjrPulknnOsuXnJKS
WTCGa7pgok3Rbakb7UCND/T7VltQ5mL8HuIcQuwc4gc44lAbF9jQ0tfH0zOjluosd6GDyEiLlEIf
rK1G9NtUZ/e/Tc3zjuocqG+36YnNQjt8/DfIW9+GLabaGCvowelj9IvpQDanaQyvfTofBtN7ihx2
6T0WGysvTQXmNhgIkIdJMKvO1QTLTAoFAI+gN9Df73iTImvelCKjHfFzWVHRzbHUYrzKtkQHkxb0
gbYp1x2VQmjWPslGlIXtr8ylfNCxFiuKufKZBbLmyoXG+90bNoOQHnYqU084dfC4Fx6d8toAfdhr
Dngd+owyInFdV3RdclgD972C4I+7tzc6hnQZFZgFI4dpoKA8FLBYfyrRSzGYiwhLfszJw1C23yIV
o4CYNhtM+ALruuyoB7+z9md2Ja1ld7Fv9yQiQDBgd6aesPvgcRLuit4rx+w+QB+2O5SxwnZ2T3Nv
9yJnu0/wtgVUHmq3F3BpB0+0v4XnlV+8GVOlcgH4AcMS3WAM1Ww62DGOXvHG5TU/0REFZSAkRoZ5
AHWX8oGinHcXGrTLPY9Ph8/gCeyICIPwmw/M1ZVoOGxxgxxoYSHShL2W3UY0/aLhAY5/2uX2ZC/t
sdqRUu1yqUev1GbjV2sReBApNgXgMRgpTD0RKYPHvfAujo5FygB9MFKSAnBWV1S7OPHN6x2nzQeN
pn8P6NT4rdvJ+FxNazV70Fj6qtnP9FStvKty1iI+ramOQkRQ+UwCT6bSmIJ78BWLHqKpmNo92txC
LybkVa9ZblPNqieUyK+d2CWLXXNkfSJqqRFqrpZzdXWDIQp+KrhgA7SEfkpFlxLgmi62hRsM6OQ1
YK34t5S9BatPHwj3PR/Fg24H0gmfHz/IMm0fDsccPkAfdnhagEadx+PO49mWx3PqpmkwRqNJg3RY
kjGVJgBXbLepLonz9ub11TYvFAoLm8x7rsDqMYG4EaM47Io1uiwLZstS3BqTNwshK94SrlZVvN2W
H1fCJeXBIzkXzNVH7NIFAEOL6KliT2aBSK/4OX+ql2sB6bBb7jDN1UXo1W2gk9PmYusjir4gn1WA
LUsF0jASIgX2Mc6lHgu6uJ85ZAwEFQiyog4aw5beYFjoghC+jYmhNs9MgwSjJ343C+SlpBNXNxrV
pBDHpjVC6PKK9i5BvxTCOyZEI5WVJS9RDp73gnvwi4XPYszjIApDzYI5KrXSlJjUghde514dodNR
Osm/uyrL8YMTRwVifttd1UrmFvvxpEt2qBth+6ItsgjSx69BRsehvxV9gJcNK7ifwUlW9LD0IImF
OpzHw8dFuJBih+18/+ghcTiJgQleB7Hw+O8CZillzR7QHb9Wb8eYmS7gXwr3PPh+rPhdTv3tw/hG
JiwWMAY81gd6knaBHveBHkmgj9c0x1Cco9cK8rDbDnOHsbn1d3ra7Je/l+/IalCri68fe/sVGSWG
ahSDK6LheXf77Ic3GMgF1Fs8PPKn9w1resMaFnIHzsgQt9bYmTCgsS/N7/TvtON/ZHVaqa92k1gU
AHmBza2z6EG3OnK2azVJWBx2mkrMLaJHkMoGo1fMTfK9s/535jy6AiyDIZNBHh/tNqZA7YPyTuvp
P3dzlKeAtJsCUrniFaV3wXA+9nA+FjgfI5zHT03/JPNbF9G5j+i7AAttjhU6phaJ01XSTV6JTF4O
Cz4grrzjWC+gHBusKg/qz4w5TrHU1OKS4N4rRDc2Xh+8O+lTrlZbTaPAJsbzw5rA65xhX9nWvGho
MIlxSsBxBacE15/BLkLYUURV8tpWzQasvKWJLbrINP+n4UMF1+Kshza+RTDPKA6HGHSjQfQNyCkF
eywJOBBkd4R1oJnPymdaYIZj7wbcXMtcR2Acinn5sW5ascxBfKZdcgUfj8Qo5V/WlzvJcI/gEdwY
7lUJohvENhh+txONoOY7jUQVfStu2Y7yojfcjA0nlDjvzZXvmMvwwGN44EkIAuDQioDQgLffXqHZ
suC7b8tip2JuPhBzzvYg3e4ZMWEjFmxEijv4vaY59S4of2LgaRlZC5qHtveNWXULHzsCp0P4mKkn
8PHgcS88yrtRNjqYdQcZBnFyHIFo53FylHkvWAGp6OUE4S5W9QlaIJM99Xo8uXx/9Q67m8M95Li6
vTnfs0gMZ0CNAYsIddgiw8dZeNzbC8PR7p8+Th+0hy1g+EHJYpGt9DAhZsfL6dQpIN8DOUsKgV6E
K5TQc6YbkJhvY7OuF0fSiwmIwdTVVlKQHiF78uAJwRj0UNXWarletgjKVCksa6pSqtxQdeLfmg8g
eltiw0k9171G5NGgb2zAFJj3EM+oakcewn1etRq7nYIox6aBKoiWIXZ8ODjZO8nfVlIRsCmO6Kty
7JIFXXP36YAHKeElbd/F33NB0iuN5eKFEuXAecz1VK95UaGG9O2jY9dhQD8SCscvg+ANwir8soOO
Xi4YmL/wWn7GvF+S4i3BwBQaPbL018iozw/LUquKjBKDtUYIo3i/FTkddbNRu58ou2PCuHt+V52a
afcascguwMPLlqwgi5ozL+E7XDC+yxDfYewhviM6n2m8HoTv+K74ivguPF2/uT5Ws7qZq5YBUrXl
f8MzEJoNGwNDpnKxy9cDqV8YWXHEGIo9CPhKPTPLcs0nValkg4HZghnLlfInHyE404ClrQjDgSka
vgtcOY8ye6JF2j9YA2h8+pFGwRi8BxeaoV7Bz7D0l6Y+EwfnGicyn1cW1iMebl5pHEBYxDWte7MW
MlmKXR1ZMEW7olXJKLHsUS7hAnIJqPNq3sc9IFxHCDdjhMu67ilIjTALbnm8eU/6eFUxYcE/q2eU
DBWCHEQIma6L2/zxStX3fC2GxoeO2MpmckQQ/0EfHNaES84j8gVG98+cVnDBDNxAheuHqllyfnFB
mJU+B5eSSJxeP/ELt0hJIs5ZtX28WkkeoqGIupvSlZphucbs5RzmX78nZ4S3FFlVs1cJen/Z4CNT
+qyn8UUtN6r6hfeeu8IDOq+ULxCq9SotRUX+uvSl1lcIueWnnfK1epaznWJHy7TNu+ohAPOpgts0
1ezf5FdLb9QwEL7nV/hYIbHEzzjXVhxApZUoPSGEdtUUirYFbV9/n29mbMfZbrpI5QSqlK7tb8bj
8TcPD1cPXBOpEIBKUghiFRa9hIUXVmqOC81xoQ/2k0mi2r2QUTsa5I/cBw8cnr8GkMVRdpJ/36UJ
HojxD/m3LInALc4QD5LMWIy85LWOq3SlKEOSriXrWDPinm4zpiijsqpOKZ4pATJW9Kx+3ufGXNV7
b4alBDfyNYhwwl39uSg4PgarKI0ki5ICXAyj5p4H8jIYE5Zux1PL1shV4pJFxV+SPSTOeuQb+op/
8yZVXbEz2nYTz4bxfRjk5h6JRz0c7diLXNTXPFCrgd1jOMV2ODKVkjtZuxKkzHFuJSDnVkzUYqVj
EZvZQZazes/s7Zm9/Q727q5J/j9i77tEsz9kbFI9R1zHXezf4q1sPLJ3m7a8+xZvE2FZUtTsVPYv
kHd36g0vfVT5Ujl85m5I9SIwd6X59Jmw8vOOex9ioq0o+EhPlii9YzxIciM/abRkvev73LdAePl1
w9Wuz/I3jLyQe1cn51w2LROPX1BXAhifTEZqmJE3U5Q3k+E3U5w0dyY1wNIv6/RdprlvKWrJwjp5
kspDUXkq3snbTvpxm0T3qX7iLdK0Fp+txZ+rOcZ2I2M7ua5b7hsHPuoN96/ESZc4GdJc4qRNnOwm
YjUnhZEOx6YWOcKHNnHx7acmQjGeJ7Y1YJFqFy6q1/zdDM0lrcZYVp1DbJt63RuEwbPiohz+CmlV
B+LrZF07NCtmTnp+lUxLq8+ZNrN5Bszo37P85ujWq6MzRB39nR01Wr1HOP4AEMH9qHSrPqjPX1p1
0eiIS4Mm10PcqevGtkghrkysmzPGRJ7CoQHREYSoIQUQ8UTA+PJVw06HC1zXTmV4TFrp7CwUwtbO
CVIAnVsYJ2qLuTaQSyshmZiYC+egUa32zpiCsIZ8Jgb3gW/U67DoA6RQvGFXmWCTgaHNvEFe4N1j
ZEUFUxAINW1EM+1C23vn6X6vy4SFVGRzkn1afFV8p5/4qt32ld7ylR59RWocC+nsh+Q8mZj4qvUk
V/kqYzLC9p1cNt8CilbAXNfLLZge1a8tE6SZpjxj8I4IbDIyQKgwBRHhqzC12QYQvDJZxrXFttMk
NVqcIQUQLG1caGNoDpEYKg/LuPawtaj6tYczpACYFtlaspyEdLI24mh5LNZGOaP1o7VdGCEFYLpi
7W8BBgCnJETICmVuZHN0cmVhbQ1lbmRvYmoNMTY3IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1Bh
cmVudCA0NzQgMCBSIA0vUmVzb3VyY2VzIDE2OCAwIFIgDS9Db250ZW50cyAxNjkgMCBSIA0vTWVk
aWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUg
MCANPj4gDWVuZG9iag0xNjggMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9u
dCA8PCAvVFQyIDQ4NiAwIFIgL1RUOCAzNDUgMCBSIC9UVDEwIDM0NiAwIFIgL1RUMTIgMzQ3IDAg
UiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDQ5NSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUg
NDg3IDAgUiA+PiANPj4gDWVuZG9iag0xNjkgMCBvYmoNPDwgL0xlbmd0aCAzMjk4IC9GaWx0ZXIg
L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ7FfbctvIEX3nV8zjILWEMYPBTW+WxGy0tmVnCW9S
FaVSMAlS3EikioRl+5P2L9O3AcELuFK82fJWRS4TwHRPT09fTnefl4MXZWmsMqqcDYwJI6ci+Mdv
RQS/Uaoyl4S5Ku8HLy42iZpsiCVSm8ngxfdjo+abwRA4ozhR5WSAb3msyk+Df+iL1XIWDPMw1qt1
MMxCp+/5UQVFaPVyUquy3gS40jCfGj/URJsEwzhM9EL2LyaVcCxWSxWYKCy0Fx0MTZjpdRCDGDW+
KN9FmRKWg6f/3P9+5vOZ7D/Vcn1l6HIhax7Rx41GWqJfPsgVbPKdGMMyRxTdBME/yx/IVxH7qgiL
lLxAL95TcR4mNjLoK/SDy9Aj5ByTiUuCQq8evqwDsmWQwIHz24aeCgxpQ6N/CWwB+qi/BE5/nN+C
g9gzqxmxMfMnkFOxlFqNvzAPk+p72MgL3wXoGrhHFPkL5BJreWjSPIMLlJeka2xaXfECqKviv8BY
vf92dPH3fHPOX0iSZ5iEibNWpeDnwvlbObf1gONbXQW5XgYpWOexugODGXKD0VNaUz9BEGS6XvPi
jB8Q/fyy4p2qBPNmuporYajvujJ4TVgr79f7AI2u68CCd8E/9L+a13ueQebUpoka2jCOM7oKu8X5
/I7lKiVITkHkKBg6PQ5MHKbtmrp+/+Yc41jIP6ozFQfDFAIkBOVTHdO5o3Jg1EINchc68HtapBTY
ocvVkH7X9WD269Q8b6nOgd62S09sFtr+7b9C7pwNS0y1MeLjwe5j9POyJ1fTNIbPbbLaFj6jhM37
IzgwB39FYK0ZQomVj3UNRjbgxSVYMtGT+kyNEURSSG/cgj6IgfsdL1LQTteVyGiG/FzUBKk5AqmB
hyxvgpRikkhzOqBZV8uWCoFe6EnzIAtRFjafmUv5SGMt7gLUofrIAllzBUjn/e4NmwHQ9zuVqSec
2rvdC49Oea2H3u81B7wOfUY5kcT7NQ9sbw0kuYVA5/fXYAdKghxrwRkkAxpCXQXDAl6WjxV6yYK5
iLDgx5Q8DOn7BqkACMy02QC3KYAwlxWA6WGqRcbSb9sKg2SEQ2R5vm/7JKKS32N7pp6wfe92Eu6K
rWeO2b6H3m97uEthW9un3vQFW378HuEl0+cU/RlbH55X/uX1iE1+hjEMpgUPQAjH3gUFWi2hskgP
tKVFQCapNbOsZY/wzOQ5YSrIsRH2Mh0xKxKzVF4LOYugmxjqncPlVPRchroFEUA4c3SA3BIw4GEU
EfAUHO/41qbQDPT6lqknfNu73QtvPX/Mtz30Xt8mBfQ+/VAoSPY+QKBiXJSlt+PRmSpXanJLIFRP
/k1P1ci3qiYN9owrQT8loOfJAmhf6JOhqiHg8hh7Tz2YWjHWwjUm9QNK5M9WrADmkvvWR6JWhHl3
i6nib0HvhYddhmE6DSs8RkpC2co3qBh9t6Lpq1PPreHwIT1Zd/6tZG3eOTbcj48o7g0OIJ2IjOMb
WabdBs2xsOih94dFWoBGbVzYNi7yTlwUFBGJHg3BVYVUvwQR14TYlziwiF9UF8T69vryaocZsABt
+vaa2c/Uy4DWN5j9WPZgBMJUjuExWVQSAOz3guyODIoXha9RNS831Ye7lo/k3RIfOgYyXn3ASozU
T4HFAKjZp+xyOKPm5/RhteC3BsrLFg9EVVXt7joP/SXWUL9pbc6K1ZwdoICaVk3l77CkCIkUmM04
l/oe1rZ9H0IuWp30ca0+jjLG7OoDbT/eVX8kBspOJ8lXaP6qGnXx9u2rq9FORPvMSzGW6X8l33Pa
hUZL2rM+8VkLUmBHOiTKdDGjJIPuYy06N37jY0cYZ2ShhZmFTbyTUe1dFdSNvtzd4o9hcf4Cx4wj
nFhHYDunfOZvvnerW3RXinZC1Fl0VZ6qRdddSdq6y8XbkUN6kqvrAOVgITSYEkNsCMFLCXWM2Iy/
IoabAEcHsHm32vBXTQ3NEiY8Gi/galQGQTGmP6yWwqiQB++FIfDUk/fBKcmKbTd9gE9C7Yeo/u0i
XEguQbDZ33pI7McnADHnTjXxo79LoSI4Mnsd+uhSvRkh5DBOOc6dXH8/Uvwtu/76fnQtnQcLGEEj
iSYr/8QT2dbpkTh9tAywT8QkDcBz9NHAWydLuRHd/p0aeLuvT+U7+dbqR499Jc+fppN/I1vEUPpi
8EDUIlfWekOMclzK+9eBQSu/IzFDL2cvsWKztbFhcTfgjQy8dLfCuotNImbxFPLoeer/j95u9ORA
s27UmILsg3fRFZDKn4+gf97a0HobwvByfYUAkEAgHwWhI7b6Nkyy+wbXKP9FieDEk6/8fQBaIAj6
a6BUru7fs1PgK94uF5tJtZ5ygeByDqXhoJCii3hm7BbQoy4zbXNlch/df8NuJdcLkE+z5iM9oLxF
EFJYNaX4YSVcBFjQpI911IbQHqqdOK/MD9sLCpDMH2x8hE0FHRd4fKJns5oblLW0tTWNUhbLETGo
mafA0RanqHtUMeERD9eXCKOtQL9NnpWImx83jG0HTWhXSb+2Gqdk4oyrMX5SRJH2Bmsd4vVLsgui
dgHRhe+ShD7IYn9Qus3GD91s7OYVsnybufQVtYDRG1rXwqSn0fuZKmBq00gUyy915jF18LWAvRy7
Z+gu2H0jttx/62AwJhjElR431bohcmmGTMQMoATIKZFVQ40rj7U8GhZ6vY3IPfAvWhcY30pelZLP
dEDKfYQl+LQQ4Da0W6P9nsYDRKTRDmGRARGbUULCTEYKo5mFfytZmzNrDyq2QeibaUHFWFAxY1TM
GBUtoWIBZpmBfR0ADrbNLSjGBIpZC4oxHE7fU6Yy+4z31jRH2HZT0y3dh56ZsTvWPPXyYGG13H87
QOBNDQIWhoGjuCha2Npxq93zaqer+a8ctL8oIZpyiHpV2hB1uvUdIL/yHvxMXA8LHDy6DXCLnd90
zvqkzaRx2mnE9KRFffA6FeT/o/7vivp/kCg6HkSx4zBpcznGXDZ+1MsomTPpcD2MHO3uv4ErHnnj
jntH+56unBowvP0Q2y24fUy3H2Jn+Ep1/k4H71dr/JwmHWoKRquuDpt0KchUehYiRT0KG25eE2AW
XAIMVBFsP6noLJm52Z0A1HQxE14uMkhi1qZrnuffu9N6GMb1QgS3uF5Q62G86j3zYycRZxzrVNhi
KWxivbwtbFTWwrawYc3slrWMy1pGZS2mTIiprMW/WVmrPwdH6tIfKcG6GXYwnMRUomhgiwq+yZ+D
BDyAIxfOZjBNOQijW3AuNl6zgKJKqHdE41/0IHaMnwLqUMBfGVV/3DenXzWpZLTcgKOwS7XyBt5F
EXyUkq1Cqvi5+XjPbQXumu5oVcm+asOsotyEhQp14ZVEEmtFzUdEzUdBky5ybLBlS0QVUeFD3bBK
crfab/Ry+Dl9WLEM/hStBBZe8lZV7WydqvOw45huc+C2jpH5dLSkBlKOYRGOjjHdY7AmPD32n4qL
T4m0kwqeH4eEw473Ro+4k28CBNjqw52MALfbPnc3u3+jruYk9WlaHU+ytIU94uFecM8MB4BySa40
7Rgon2r/77n92de98TjmOuNY7sexVMYxq5mFfytZmzPr6Tr/7VdC/zZu24+Umi+axkRLrPeKT1tx
k9AoXNtT5LAVoLw327zvjoA5V0rLlZLrZLGtk1R5kSyV0lLymU6tTLlW5lQrHdVKR7XSaYnbUTnI
Xejg2CSOQ0CdKHS5GtLvuh7MkJrnLdU5iHLbpScWxsqT21m4DZNUqC4BGEx36Bno2re3j4ZqEe2U
Uj3Heoajsk8SX1xsEnUxhikH/40vBkb9oIz6GRiz/3Bd7siRwzAQzecUih2oCH5A8hCOHLqcbW20
G/v6bgAkCDkTW09gE5+RJl/fF6Xr/fr8StefFw1UtNJVB1zk6/+rpHyn4cK/1wckfPoI04c4FWbe
XAPjxMD/H4bw9+1APG6SyDT6zckFiSySRZZNlVl2NuME4x0+LLJDFTmo0bMJD8+1yHPB82acaCR7
m2di1Qq3u3PwvIToufCUbB7PzhwCo5C352IQdiuaQ7R+Hi6oZ0jKwKIei6bF2YgDDa9si1s7LkXq
/SaNO6Y2xhI0LqQqzCCrhFxwDYwTvUiXPiJn1HSEwLaOcfNMlq0ddyMOoE8mP1OcEV4N08SYJBOS
FY9m03PmPlcNcg3AuU23pxevvAyJi6UuSavutTUEPtOFaOJJs8vIxkEc4NUg0ayOhjtdc+E+UI7J
0akCfrsOy7L6XESZq1xoS2kDEdJ2Ou250mwo3MVmnMCPyvjVujkV0YJbEx6GkzRoNLyZQyTbSiKj
0TW3La3x3wLCaF/WVrTurazm3kLXPGC4xRnJh2Y4sq3jiUneyDWceCMHmMfWnlU4CYOK1WNKc921
WVOqgN+m7rX5EWAAJaKd5AplbmRzdHJlYW0NZW5kb2JqDTE3MCAwIG9iag08PCANL1R5cGUgL1Bh
Z2UgDS9QYXJlbnQgNDc0IDAgUiANL1Jlc291cmNlcyAxNzEgMCBSIA0vQ29udGVudHMgMTcyIDAg
UiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0v
Um90YXRlIDAgDT4+IA1lbmRvYmoNMTcxIDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQg
XSANL0ZvbnQgPDwgL1RUNCA0OTEgMCBSIC9UVDggMzQ1IDAgUiAvVFQxMCAzNDYgMCBSIC9UVDEy
IDM0NyAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA0OTUgMCBSID4+IA0vQ29sb3JTcGFjZSA8
PCAvQ3M1IDQ4NyAwIFIgPj4gDT4+IA1lbmRvYmoNMTcyIDAgb2JqDTw8IC9MZW5ndGggMjQzMyAv
RmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIidRXSXPbxhK+81fMcSZlwpgFm28yrXpS
VM9KiajkYOcAU5CEhCIVkvLyk/IvX28DQqQoJ7Hr2ZGqCKCnp6fXr3te1qPndW2dsqq+GlmbpEGl
8M9vVQq/aa6KkCWlqm9HzyfrTM3WxJKq9Wz0/D9Tq67XozFwpj5T9WyEb6VX9YfRGz1ZLq7MuEy8
Xq7MuEiCvuVHY6rE6cWsVXW7NkjZMJ+a3rW0NjNjn2S6k/3drBGObrlQxqZJpaNoM7ZJoVfGgxg1
ndQ/pYUSlr1n/Nz9/pvPv8n+cyvmK0vGJax5Sh9vNa5l+uhOTHDZM3GGY440fWvMr/WPFKuUY1Ul
VU5RoJcYKV8mmUstxgrjEAqMCAXHFhISU+nl3aeVIV+aDA68vtnQU4EjXWL1n8ZVoI86MUHfX99A
gDgyyytiY+YPIKdhKa2afmIeXmpvYSMTnhkMDdiRptGAUnKtTGxeFmBA/Yp09bbXFQ1AXRX/Gev0
7tujxP/nW8jIoHG0Iw/REFtRGaAJuoXA1b/Bx9gl3nrXG4ssvYHf3prPvf01RvKIt0lZ2XwbWFdG
WEhdH9d/qsy0XUBilfqSvR8PAwSwWZ73R1b9kQ9T6Xvw5f7bqyNjA9R5TQVY6iMyrv4B9J4iNjgt
DBODH2fGJW5r0be17FW3NjmgxaxZXarNDQSnAkC4NQ4LvwWDIDKaWfi3Edo1s5KpKQUwhG0A8z6A
gQP4Vv/Skfhcq/f0aE2KsN8hVhbQDABqEdE8/EKzgDbBzBs+MNCB8H3ZXQlvu2pliVk3X8udtR/z
CStuTR9ZPKmmNqIwuShEKwZuGOSx75HkDRtYsEhuehl4kaSUWq3aWdu9N+hQdO6l6riFLICkTl+f
cmoVesxSjiCFPKWTp3Ty+q35MuP3iO1HOPquW0H7kGz+F1bmodqMgO4xUtSzimKL+ldD1E+tO4yE
J8dHFxAEK+Ir/dKMAzyO6dQt+Ru6gAs8DAq8jAWeS4E7zSz82wjtmlkfz2wXelfkOwUeuMC5NDIp
8Irz31KB222Bh77AczowbAvc9gWea2b9agV+gvHxUEcXYHFBUcLahuBl8IiLkTxmbYQ6YaYzhX7t
Zy5WcIlDLwIRLu3oPqyiR2YlMrlkeHAMDwwO1RYc0CUGlwUeHMIDELcAkbOyJQFEIIAIBBBBywi6
n/n5NvGv+8R/BMe++1L/SuPOXut6SgomUCVN4I977mtYRg6S4KRtVpt3bbPZn3UGrXLYI75zB58w
rHl9QY0n9iTCvELHxfoAYuz5lcAT3ceFZrn+rNTflizN+GhCzGdq56/X7yvljiCmI8SUGYQHlzZW
+4Pev0atS817mmuZbYY9M+stz3awMmOszEhULlhZMhg4wkq3xcqsx8qMsDLbYqXrsTLTzPrVsHKb
56VouVk1fAaabHVixojzE+LguSbX98SwQDxEXWbLh4R2hfA5RMR/8aSkFJ6N2A+Wrqj8c9GOS/+4
HlnVqVEZkgB4X7hUpUko1Zh+V+3o6jNLZclLIYABbriYObhRHNj41Fo8z1ZJ5mTVg8NC2Nl7iOFl
PaqSCnEzVfRSQRgDNBNfVchc33LGFzH3nefo1tTajs0Y56IpQkYhNPXqeDq5OP3JjEEC0pDj9Pz1
i+hEUTqkVZKWh/wkq4dddXg7C4f6lUUsJ7e7+dHlw94oi4E3Bq3WJthpn9d1UDABXMFykVXShZAL
JgteL3ndgrzSDdqU60GlZMcSakJtbRgISqgYnLvusORKyMzNUnWLbtM1m1Y1woJ1DCncrA1DWMYl
jBtmHeIOFV8V+a5g3KiwMBEE4xoWplbtA4mXd8uO3zaG5l8BTtERdSGwzxg9oKynrezk09WELpvn
52enx1vULaXXegTdnOZW1JhAFyBQvQXIHFcyjjlNxYgMd0sm8BdLQB0ELlCl8X7XesMtJ9NnABmi
wwc2oCOrNnzYDR/2npUg4SvRgx3G3LN9f25E8yidRTQkYn7fMryjBEB3cWdkfSIUhJB8/lAnQEo5
9oHZKEbCMuGQnBlLgXny2ocjAEieLeOtotppjwVCIDdH7hQZx2nAx1Rko9GpkpGZwwcOa9U9s3QL
3qkaJQTE/KCvmbGZq7jzFuzh7lPpucFhvNksV2wLhLZMC7c7mAyK0n1ZUdpMnDO5wfl/BjoF/Tve
EsDB2Mte0MCgJpzWt8byDQvZ1uuGntdyc6CiIS91a3mB0sjBcpo5aDYZ96z0/let9F8KPb5PhkLs
pZaHWeDZbAz/7/TJdR7AdHj/Bd8LSvBAxVjJbOWHycM1HrjGrfBR7iAbfzLHH5T3JcUb1hb0mEV4
K+IRzbvle+bYd9FgEh+4KHxhIgQfL3jW+lgwlidDi7exO9aHPxp+bAw2Qfq9MS7drjNNPtgm5u1B
yeHM1SFtI1vVKcw/+jUWdq7pHUse9o+Nc1zwOcSNdDrjr2ecpEqo50w9PxvIOOah6qGMfF/EqyNW
qZZnpJ8w23GczehLPFO/JEn9Ggv45ztFSfqIhkZpUxOSg17YawQYxzT0WV9IRGGGKSAUFxfn4NkC
4nChZtyWboCAQbiX58JwQfDXGltesVuuMK5Y72Mu2n5s4rNeA8Tj3PxC/dzM7w2AqyLKFeQRIArG
Fgcpj7Qx0VbYSL3+CLwbOl5tOlHgFrAb4RnUgBYyaG04HnfzuXqHYmRdzZr5DE+cY1XBiNte4qpq
+Ggc5dv3qNCKijHoT8Zi64E2BBcF2rIwdEuCSUiOjoqs19QRC4L86JHtoOer4olBT1YPD3qHt7Pw
fDvJpdD+8gfLrvJQ04c2H15FzWT1Kc0ePzuuHxD/meXnk3WmJlMaQlM1ncCl40eAp9+AERLsg7Kp
+q9682uqLkfewmUtWJWHHF10O7IVqJ72hPloCqQMTgFShrMs8sAs68KAp+cAQ10AwtUPQHPkg9zD
pS2HXR4Ss3I9ASUjKScemzhkcQBs5YBly1Cx1FBCWydd8qRAqQFKFqtECCgVSaReTvYiD15XBjw9
RwbzmGPJ3gWyIYNrC+nrUkeShYCSkUT7IFTWibdCGPBEjgw84qNktA53+VI8EQnATLtsmfLZWYZ3
hlsKCzpCCOyrnCVn7Kkw3DEfLFdJKb6C8KByoZLY+pItEgJJLUXfVGLrizDcNO85QrWNbTQglJ71
jb4SwtBXAZKlGvqq59lypOhNyRphyissBjTUUwYIgXQGEvMAog/c2bP0DAU8xReQC5jnBVzbAvoi
EuBuFn3xvwEAnTWeHgplbmRzdHJlYW0NZW5kb2JqDTE3MyAwIG9iag08PCANL1R5cGUgL1BhZ2Ug
DS9QYXJlbnQgNDc0IDAgUiANL1Jlc291cmNlcyAxNzQgMCBSIA0vQ29udGVudHMgMTc1IDAgUiAN
L01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90
YXRlIDAgDT4+IA1lbmRvYmoNMTc0IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSAN
L0ZvbnQgPDwgL1RUMiA0ODYgMCBSIC9UVDggMzQ1IDAgUiAvVFQxMCAzNDYgMCBSIC9UVDEyIDM0
NyAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA0OTUgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAv
Q3M1IDQ4NyAwIFIgPj4gDT4+IA1lbmRvYmoNMTc1IDAgb2JqDTw8IC9MZW5ndGggMzQwMCAvRmls
dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIieRXW3PbNhZ+16/AI9gpGQIEL/BbrGi6bprL
Vsp2Z5I+MBKtqLUtjyQ3yU/af7nnBupCUXE2beLO2jMigXNwCJzLh++cTwaPJhNjlVGTy4ExSepU
Cv/85lP4TQtVujyp1OR68Gi4ztV0TSqpWk8Hj34YGzVfD2LQTLNcTaYDfKsyNXk/eK2Hy5vLKK6S
TC9XUVwmTl/zo458YvXNtFGTZh3hzIb11Pi2Idk0irMk1wtZv5jWorFY3qjIpInXwXQUm6TUqygD
M2o8nLxMSyUqnWcYHo4/8/mZ6v9q5PjK0OES3nlKgzcaZbl+fCtHsPn34gzLGmn6Jop+nfxIsUo5
Vj7xBUWBXkKksirJbWowVhgHV2JEKDimlJBEXi9vP64i8mWUwwfn7zb0VOBImxj9n8h62I/6R+T0
3fwdBIgjs7wkNVZ+D3ZqttKo8UfWYVFzDQt54vsIQwPnSNNwgEpyrUpMUZVwgMkT2mtm2r3iAXCv
iv8iY/Xh29HJr/nminAgKZ64SHIPRVNAnL0Lp3LFNgIFn+oCPAO5H4G+/qO+ApdxIDI9ozn1GNLA
y4DFzSrOrBrS/Duab6A+PPj6dxqtyeTddWQoUosINlPKJ9SYHkNMKasnoOn1y8hoxR+osXogqPV8
ha9Yc9cHoYoBDfISajq2SZaVdDaOkwsFnzk+2wRMFJBCoyh2ehyBuaKdU89fPTvHXYj4Z3WmMtyp
g3qoQNHRd0eTgVELNahc4iARCl9QpieuUjH9rprB5aelVdVKnYN92115bsvE9i//hHjn2zDFUpsh
YHZWH5OfT3qKtyggvsW2em2Lp2nO7v0ZQlbpJkrBW5eILVYGqyaiKEHMAQH0tDmDsAOqFBB3XDKh
0FoIPE1SFs9WtdjYxPxcNISxFSKrgYdMryMM34JFc/rAZlXftNI4h5Sabm5lIi2TzQfWUgFSeBdX
Ee6hvmODvHMFV0uIe3BsCVnYH1SWnghq7/JgPD0VtR55f9Qc6DqMGdVEnh1eguB7a6DqLSQ6v/8E
fqAiwFpUZ1AM6Ah1gSVd6Js/aoySBXeRYMGPGUUYqvsZSktwHymt11i2HgRzmQHcjgstNm7Csq0x
KEb4iEzPD32fp8QBenzP0hO+711Oxp3fRuaY73vk/b6Hs3gb6iVt68VKvYxfnbMbMP9zeDL2htFP
BIYjZBpGn6kLweRdXLxazDC/8/ZyfBwZLA2ZvQJkJpMZj60oD7coTZAaYBo24/UdK11HFC2MSAoW
A1oPw+5ecjoo+dQWqElxhbuudA2Yj8FPDuNoQcn2xpGlJ+LYuzwYb6N8LI498t445h6ITwt7ZQt7
UkEvmTy9iiwgYBmGL8ajMzVZquk7iADUw/R3eqqNjFU93SBZXBLKAb0hcCt0EBNwlfojDRGSkL8g
AWukNq4jvGHV8obtrpppc4sWediaXbDZGwxIBtmD0jrCkELyhLS5jizCczDNn+Pfui1F2het7IQT
XNEXSxCdCOTxhWzTbmN8LIo98v4oFh521IaxJQdpsRPGki6xUo/otjByM2VYhQaSfhw5GIRJNSTd
F8+fXOxrX6C2BwHrnwFngnkMI0AfuBWbAuQe00UtEQuB8iRWPCVaG9Xg5KZ+e9XqxJwojgKS65l6
y5ejB+Zrc7yFOZaFFusNP2e3ywW/bQjld3ADN6jqvVUzdZ6Eva/gTqXJ+c531aze1GHnN5QVqYKz
G4fMUjhmtuWYUjGwGfBXRruJkBXQCOj57n5yRJf1HcugiuiJVVJqGdS0Ai3QC3ZqHnPYE7vkL3D3
xSJ18TxCh15M6JTgFcj7jO56WsNa/Fvz1JzNNHQ9KvyM9HPqxBnOwyne8ynCDsMZ9qWrKCWjGaEs
acz3FcUZchbg3LKflchj5EtQYMFJiDX0skbODdHoFGxe+i3569SsSPvLtn+5GBdR5vDCPFzaFfbX
LCjBsJdxjv4tlJHq0xzQydET9WyEJeg0/1IqV/qHkeKxrPrnq9FzuuYyMTAC1rPN5bxocznb5nJA
/9FN5EMaOM2DTeR2g8f8aft3uoXbvt5X79hbuy16HO7t/H9sU8krGdDjDGKRBq/Yoo2LNFpH1r76
CVIRQBYtxMHEoXvt1r2WLb2BkJRIZZZr6S7wMpq9ie7pzb/mrXdXdLzJd3Qa48kteA5dg2jyW5BY
3zrMBIcBwX5O1wi3pBasftlO/4wDP1msic5N69WMmQsA7B5pQEpg9FoIZKCmWFVz1u65FPLtpZCH
SP+yWhIA5gyAgKSEfBUjH9FZsu0J8ZDW2uNlKhyN7W4JGBOaO2ZCTJ/2I0bV/Vq/lez6czLmmyTo
3htXLTjMVv5k1d7vIISiRFSwwaNfYiqO+EwjFS6fOxqZ11s4/ObOCW9SfY5vD8jG8aZebUg6MTGL
iNcxOSr1YqM2C86iwJtXLN9Pqm6xw6dCicdc8XRJWAIVq59GmNvq8O+v9sD9a50aPin2k1We7ZSh
lLeH2vZU2I7pWSZljflD3iiRyqAnMiBMnptUAy2q5y87fUebqfTOHXAvF3UnKbh0wlIb3IpsgOKc
4YXJUUZ+m2n5LGK90SvVfADx7WIF5LwDQg84wUs4ceeS0tP9+6lqU9aG+0mW5/vLdyP8oI/MQZb4
SvZxkj3dK9YOxRy+ePH0YqR2/74etkNNYjkiusJtSEWZHxRlRq1YwcXBqGy4LPNjZUlXbt7Gt6pC
dRIBNvoX6URWMl4StEFnMoeaxbqfycQVfo9apxK7wyi2iFrgYNhEJjpWnmr4TvSwmD3MwF0cE+Td
iQo0KlkAzi7t3smy2f/H5dzJw3sdRBocTgL+XXLyfPpqfsilfBy7Msdkor1PCcBNaLpKKvDyUwX+
gM7KWLNHPaSVNRxFwi/L91NFPCTf3lDVPiCs9mlIWuziGZlFd8VYr5Q26C4oaQBEtfN3umi+gGsE
XCsE19wBrlk6BvKMGMGtYExzvVTDbFtHs884qBfBX2YdDiHMwqkD75Brvwq8wyHvQGibEgZ65B6J
8J5M2If/AvaxQykrDqXVvM02lJbaE+YaVrgGyHvYRt+Vfa99fbU3SbwO9yDI0c0eAeHK5sLemX0g
vUMn/z+DZ3QSN+WjinfgsN3QdhqIb+6Bzhtv/7CbiR3k8D78dtL0CWkbcZ3XMlSHf1/jzuYWyO20
QFCCqrvDk92dwA62RdwcKfEHwZ1pYScPzZ/AjtXSc1HDk2DLUyU+tFt30oF9adMzPtZqCu5KAxiG
fIYl73qjWIgdIAs2wQ0EumW5reXLU7V8vEl8iDn92VW9U7Odqu5Nl4d37vvW8kMmjL1v91NkUg4c
y5tih5Qfu2Pv++Fxc0N4MhMSLsb/flj/RFKCq6I6gMOui8aPsVIMYU0X1x/Kqdo3/AlInyH2Wa77
HHtcA48PFMZNhAgudC1nyloQZfWg+LemqHwLlnwLjmVD/FWMoWPte1DSh5/LPck8mgwqODRsO3cu
yQECElepmH5XzeASpVXVSp2D1tPuynMLt+vJ5cF4WonUleZQXtqkd22fDLdFstObOvrZoHDU9knh
o+E6V8MxQCX+j4cDo35URv0GiqVV75VJ1TP1+tdUzQamyJPCGeU8lJa6HtiqTIoqjK8GY5pxqFH5
xDpU8Tm8bFVaBV8mcNFeDS6/G7g8Y7N5ice+HmSVxRYjTKBhnCI7BXRVFeqUjg0FnVYDrMHZyHL7
dQfUEBaZomDDNEa7OMOr0iQrUCWv2K6otAoQE0gHMmsK9A3MZTl+Ch3hE1+0E+wJLzoAPOQsOHFu
d3S2Gp5PgJb/22UVZFkMgrAb/SegqHfq/deDIAizlKY2JoR6v05LBlVS2NZZYToNkxV2SAC2uN2r
DjRn0cHWWQdaUHVwSAAmPR0cw5y5MlemjMfqxFQB7/E+BymdQCjScOqEU+BeOoFIsKkRAhIAHL9/
fUBiBt7DreZrPf/YQvJUxg/s/JBe+R5AskRx/mGfhm1ubdAQ21o1kIoeCIa7tdMr3wMgJbe6dgq1
Za1zcocrCubXMIyMPm1BkBxMTJhAtC62VMOOHtua0sbOLRjlrowOs60CN8wvfQmhLt2dSb+G1us3
DziwhAH78laYAX9JwDGiFdwylHSslTy7hWwadjJ13bTABII4xg2MbuRw/QCvbWcu34L7Borp1g64
V37pewhSmSpn4EwYuLKFbcIGWwW8x/iDfwHDhjYZPWO3kGMGwpA4xSwwjsDGaWf7Nsybd1znlxAF
27kZhm1q4FrKMCABmON3B1hgRhzSVLiFLAQwWRcGGccEYrCpnRn3eW1zxlYojKUhzDan45hAyLwP
2xwk2afC2QqFsw3rxNkxDwEWwNQQIPfAWXa2QtkZToDzzo4JRNsWQFUDtREkgtc+udGhr02LpdEW
CpY4Ti988RgauXedrw4yi3aevreQpy/IGFTvfPwG5iFaeEfSQUUHL8jPRY/oQtn66eTPn0zyfyoq
OcKfTwqNOp5f5Lk0DdvVCxPTJ7tcwsvdQNflbiDXzHo3uJAASLDG/xkw7ffk29o6b4tCfeRtHRIA
fvP1Dy26mkMKZW5kc3RyZWFtDWVuZG9iag0xNzYgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFy
ZW50IDQ3NSAwIFIgDS9SZXNvdXJjZXMgMTc3IDAgUiANL0NvbnRlbnRzIDE3OCAwIFIgDS9NZWRp
YUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAw
IA0+PiANZW5kb2JqDTE3NyAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250
IDw8IC9UVDQgNDkxIDAgUiAvVFQ4IDM0NSAwIFIgL1RUMTAgMzQ2IDAgUiAvVFQxMiAzNDcgMCBS
ID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgNDk1IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSA0
ODcgMCBSID4+IA0+PiANZW5kb2JqDTE3OCAwIG9iag08PCAvTGVuZ3RoIDMwNTQgL0ZpbHRlciAv
RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSInsV8t220YS3fMretnIEWF04+0dRXFGjmckH5GJF3YW
MAlRsPhQQMiKP2n+curVIEiKthzbmWRO5GMC6Kquruet6tNJ79lkYqwyanLdM8YPIhXAP37LA/gN
EpVGsZ+pybL3bLiJ1XRDLIHaTHvP/jk2ar7p9YEzCGM1mfbwLQvV5KH3Rg/Xq2uvn/mhXtdeP/Uj
veRH4eW+1atpqSblxsOVhvnU+K4k2tTrh36sK9lfTQvhqNYr5ZnAz7UT7fWNn+raC0GMGg8nr4JU
CcvB033uf3/h8wvZfy7FfGXIOJ81D+jjrUZarAd3YoKNT8QZljmC4K3n/TL5kWIVcKxyP08oCvTi
IhVmfmwDg7HCOEQpRoSCY1IJiZfr9d3H2iNfejEcOL9p6KnAkdY3+j+ezUEfde5F+n5+AwHiyKyv
iY2ZH0BOwVJKNf7IPEwql7CRF048DA3YEQTOgExyLfNNkqVgwOSMdA1NqysagLoq/vOM1ftvjy7+
kW9RSgb1nR1J7Js4SZw11pWCmPKPda2aGy8DZ11DTFPM2kgvFpi8Cfj8wTMhBaSfw2MFjHP4r6YF
xgScGfuJLr0AOPkdMsRodVeX0zUyz1Ba1VT0oSrmUQ1Lw2OLRpUkirjv1hU+G89idCTsA1ZBFcSi
Tr1+jNSiLhVJoNM/wNu+kkUrWBUbr5/4kShJNk6rwun1rmzETtZlq5H4hr6X5NhA9a0fmtC2+RFu
80PgZbTyUBE0BzKOPxov6loUoR86f58O7vb1qXyPvbVq0WNft9PfmcDklRByJbTxtmps4hIN8FqK
5mDvT//yjNGvOGGdCADNnYTNW0GSsm/1aOMlAAQNwFKii3eLir8hVABqpWf07K3Xde53LDt+fZpK
ZOfkB84V9g9apOdAmrxHCuUTEt7o89HgChpQqCeUNKmGvI/gMaLk2S5/Z/vk7YzsSfS0qGfq3OnA
Cp6ORJVWM6kTCGQUUSAxaK9rKLYcKhP6jnACOoR6gT3IYIPpY1dKNZTWkATfAGsJ/RZy5BZeN1j4
gPxLzxo/03shfmKk4G9P/c/4V5SS1SEzvVTiD1fRaNkarWkUE0pSG5ebHdgI0R3bBNA3HPtgP+0l
C/6ADP6WdfC5N8YKiF5ukg5WZG2J27bBHpVyXhZ1866ExoHxM9R9cv3rPVQaIDV6PxKf991Jj/k2
2GnlfwYX7tv5xDTdZldg7HHUFDyxIihjQZkI2i5Tvid6MCTml2rv74mN6Glv5/uHnx7ThldFJ5gO
YH+Fsyh2dMRZNRPARYAqZx0Ekri3CIR4PKdfJVIRhSCPHA7F7lDBIetAnJDIRyzCT0KjWNAo/f1o
dPDGUcKW0dTFSs5C02A4x0mHdcL5LIbnPTGs2IRGTde7C2WtxDGKRa0dZ13yOh2005mCdNuaqp3W
ZNM2q2TSGZ//hKEK9dnl64svtfxrUogbUsgNCYc0iEGpKBgxgy8QmYV/C1mbM6uzmPDAbic462YM
blfg4Tn9crLEmCyYly5ZLCdL7pIFOz6yU7IEwHhLn5QslpLFfsNU+X5vDNRwMwzDzlUIpjMX/7gD
n9u94xKzDL3E+CsCPjvSPdET/5O3sz1IGhyON2CKMduuot//3dQfD/KX5aDZOh1RqhaoFeBnPCua
8miv/3N7WqATrUPw7ALS4eXJ4SxANzL3B3hdzXEcjWFpp0t/F3UZbm0HbmHEdcMvxSWiQSxlqMs0
sxdz5tzpL3E77mWZQ1tCS6Nfk42ZruV7TaCd6dUc8Ddm+KWFBRsOQJ/CmcBuLWMxQrHwWHmq4Y3w
ISjnCMqgJNX0vbAswZ1aLmj7lf0XGReVmli5q4y9CNyAt6d7un+EsDbjgcHoB54b8Wbi4tdQRYVa
LlZQa7BYK77C/AaMdxVOCwcz1V8Pyx8tuiNXM4by290B6MBaaQ4yTF96/Rxcvztof5Gi3xPNzzoz
8s4E7LR3ej9eBn9PSd9mSvp/HJLc2+PD0mjSM6pSvSzyI7AmtYEK/ChTffqty971Z0hZxqQogkq1
XWJsIWWPbPwUzZ0H/SC2Qo0imCuivb3HGE4nPSh1HHgCRS85xCoC6LCJQebJste5TGFA5cqEron1
CCskB6gGd6Wyps5G4+HVi1cIIhGuIceLy4vnzomitE2NH2TH/CTU4646vp2FB34iROiNYPve5kfJ
x70RgS0ZpjD7owOtxkdkfTaZRArI10BO41zKCLmgvpieMR20jjLbqTPbVkjWgnEIhdU0ZdvXEebu
8M6bwZ23WatqVTUVDI2qcKMFsEDiFhuPxxb8XfOGKTBW3Ddzx3ftIcDjwCHjCdKwcWpV7kic3a0r
fms8jKNrtqIj6nKKeBdr3+sjBgouWARPPF29uHjBMx9w0wk4YIW6q6gzYk4bme4OeuCDKjq9wZwy
+oaN2OVwxqzmO1RRVLQBKO+T6aE9MgiknTFpigelgO+32HFCnLNCGjAwsf2dUfcA5rgJldO1mzTz
vUkzpdvAhp3HHY3mzA4fryLbr/dMIUcZuTRMS3XPLNWKd6pCyQJfLuZyu1gotxN1TzRLW8BIlcDV
Y12zLeCKLEjtvks6uW6/MtfDfNt8c/bTkKJ1Q0GRRmqoke7kGjbU5zAPJphPHrZiSiqai7HPkjd5
74Y6M/8WsjZn8R6kRUVSmKxm3S+cJ8qZKlbEPFP8XHNaqXVDrDetpFoVU15jIeuVCC3qUjGhALbb
dgPLO3R1ZzjpuDr8WlgJ24xMnacTMgBnZPI05uAtfXINR+BieH+N7ykoD/BIBQqRaGTbNoNzqlNk
6CfkdeSjBEY2/mSOXwleMko6oK3oMXXQlbojinfrD8zx1GyMvtJFpu1pUrIlQCzUW9GgvZBRqoH7
Aly5IgAe1FRV1wQIao18DSVXqIkVwQ8AdesfuqHJsgjZSFIAGEJGwqaNWlQi5HYrxCEmdtQ+nTcg
RBy+PFHDS8n6y5cvRviJzz1eUACYMSyphi2ikVwZkBGuDKCQvjh5HAIPe73sjWUniL/o4zl4Cp0x
urq6lHOuTjplSzN5ChM5bz/BWoIMGw/QlvMRLQ6ESJwj2rTLfc6LV16sj3Ci5ZHuaIRFjObPMJVB
xFlXJd4z6MJ3GInJxkixLD0CDrxExgTSCBKY3wj9JU6JQMVK57e6nJbVBybSlpl64JkIwcFgrqR8
mQUOR6o53tixaHnAy3TrSLhVEWbD/MOnTHm/wGRC2BKxdnTbAFjcq53tjfCxhL/gPC6fq5+LxT1l
PK1Ilrt8CXGNs6vmDvgb8EpJNC6Dl4B+h4XwwOlYLRbqHRWX5Pi0WEzxxAWXQ1NiqAAE+OimrFX5
ARWqCTwi/RELCmC4Lpuat6y81BUWH+0U2Wxo2kmpT6bikc7YGeefGjuZ+omx8+h2Fp515soYObtk
E4XbMfxg83EqaibUT2n2+NmOfkT8Z8jPhptYDcc0EgdqPIQr0I8Ap++BERLsQZlA/Vu9+SVQs55J
Yj+JjErCEGnLns1SP8nahUVvTEsR8tjcTxPkyaG3Rx2elgNulHECC9c/9EKT+BmsxWmEa8ueQclB
u4CScYl5MrQDeXB47/BsOQI+CiS3TLHFeX/ZC4Pct1m7gJJxiXiiHBmcLo6hJcdAYKnQ0smGOMtE
KuiA1wdZIKlpzNtykIP6hklKnmh5Wo4s9o3TN7V8OpSDjUhf+9+qyyWBYRAEoldSIX7u1N5/W2BG
QpeZjIbPI4nW6RQQb6fHSruZ09TiSccQxwQxL3+sac1it0Xq/6jjXvu+roTDx8yzUns99Pla0mAx
Zev4bLU+y2RbnHYKaF2j5zjb38wyPa8jDmsI+BFoS4CS7BMkU4hSmKThWUBSdq+LPq9jHm/DH246
3Vxwo1BxU4e+0JaWNDzrYtFtlL3DqotY2NlEdwoRsUnwRHdHx67XkLefnrDJoXTYlitYGh2LmA8E
C/YAx3RYPgew6WgOG3L+2yUdPd5AxHGHSebF0ZDwkaeAjDQqLPPi6F8qLZ50rILjHtCeByOvRp3H
TCGA7KiOWOYx8tpQnfS8jp4jL0OhqbIa7C6F2l3RfavR6qJPcbSsxh37NZoHw6thMHPbH4OVp0YK
ZW5kc3RyZWFtDWVuZG9iag0xNzkgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDQ3NSAw
IFIgDS9SZXNvdXJjZXMgMTgwIDAgUiANL0NvbnRlbnRzIDE4MSAwIFIgDS9NZWRpYUJveCBbIDAg
MCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5k
b2JqDTE4MCAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIg
NDg2IDAgUiAvVFQ0IDQ5MSAwIFIgL1RUOCAzNDUgMCBSIC9UVDEwIDM0NiAwIFIgL1RUMTIgMzQ3
IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDQ5NSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9D
czUgNDg3IDAgUiA+PiANPj4gDWVuZG9iag0xODEgMCBvYmoNPDwgL0xlbmd0aCAyNzU0IC9GaWx0
ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ3FfbctvIEX3nV8zjzNYCxlxw05tEsTZarSTH
pJNU2VspmIQo7kqkQ1JW/En5y/QNIEQSsjdOsqlIVQQw3dPT9z5zNhm8mkysU1ZNbgfWxklQCfzz
W5nAb5KpPKRxoSYPg1fDTaqmG2JJ1GY6ePXD2Kr5ZhABZ+JTNZkO8K3wavI0eKeHq+WtiYrY69Xa
RHkc9AM/KlPGTi+ntZrUG4MrW+ZT44810aYm8nGqF7J/Ma2EY7FaKmOTuNSNaBPZONdr40GMGg8n
r5NcCcvBs/nc//6Nz9/I/qdazFeWjItZ84Q+3mukpfr0o5jg0u/FGY45kuS9MT9PfqRYJRyrMi4z
igK9NJHyRZy6xGKsMA4hx4hQcGwuITGlXn38vDbkS5PCgfO7LT0VONLFVv/DuBL0UX8wQT/O7yBA
HJnVLbEx8xPIqVhKrcafmYdJ9QNs5IXvDYYG7EiSxoBCcq2IbVbkYMDknHT1ttUVDUBdFf8Z6/T+
29HF/+ZbKBqDpHggYgkUUgZhLkNjVCh3ASjZqAtwTKqXJosL/am6B49lFIdMz2hNDW9uLplpRNGH
sLgAYXkw4LNM18aTc1P5rea1esIMKkXM9o7lyCIklV7xcXPS/uo8VbyV+edMrLaP9ET+ei9YEaSx
TbNMRS72PifzOFKhKXkf2LwJJFEG2o5MFPTYWA8nNGvq+u3VGaa2kN+oE+VNlEHOxAZtS+nc0WRg
1UINihAHSIWszCjX41CoiH7X9eD2y9SiaKkhgN6uS09dHrv+7V8gd86GJaY6jy3zYPcx+tmkp3yz
zMPnrn5d1rg3Efe+gRiVEJ8EyuoWu4uXj3UNTrbgySV5clqfqDH3lSFtwRh4cPxrXqRMmK0rkbGN
+LmoqcuibGqqsrwBEQ7ShUhzOmC7rpYtNYL5oKfbj7KQ5PH278ylmqbCWtxDh/O6emSBrLmC5I7b
yDeuzaH794eVqS+EtXd7Izx5KW499P64BeANGDWqitTvD0LwvrNQ+g4CxO8/Gc9lUOCAOIFyAHcp
dWGiEl6WnyqMkwOHEWHBjxnFGHrxFVJzcCAxbTbAbUsgzGUFeneUaZGxbLbthEE5wiGyPN/3fZoQ
DujxPVNf8H3vdhIeyl1kjvm+h97ve7CldE3FJGXjeidDZPz2DFtMQRUAJlADztqvnwz6DeLgwJ8n
6mJJefqJftGr+n4xw/y21JjJY6W+hMR1+mLUJDe05pLDYbEacmrOgZoz12u872KXwaDudTFTX3Bx
7/ZGeBuAYy7uofe6OC0Bl7Q9KW97kiT3a8Y2b42D9pQ3nzfj0YmarNT0zmDXqKe/0lNt5VtV0y1i
uRW1IEAf1Hky3ZCpq+T6M31iv0B4gfiolrR9gMjBttWS5a7raf0RJfJnK3bBYpeIJz0EFqkVxK/A
yKohKHwDimNkYcZBZJ/H1UFroj5VaFGIVanmrOZBYMEpfVEF0gshPb6RZbpdtI/Fs4feH8+sBI3a
gLbdKsk7AS1o1mR6hE1dxkfAQkHfjyG7XbuohsR5c31+0eWFXgaOvWbeE3XKYGCD1YhlkkJhrDAq
uZ4uKomcp4CVQla8JFxbVfPytvpwL1wk645hqMF4z9QHnGElAFSH4ao5XXIt0mt+zj6uFkvBrL5F
vqKiqp7tmamzuNF+DWOPFuedMxUdKFqoWbWtFAjHxEgUuMuGkDWA8LB6ak7YRqFcsryjEnxI7j0S
g1TU84KptgwcD3OXq4XTVpK3bfyUw5TdasG0Zjt/Me2YXk+ol9SWlDROJZBb6HMoIsSYGV0xcBef
JDVYieJszRozKkO/LW6lZuu1OGXbnCYE4cUbX0qXSTKRSn/xqWPMTE1XK+43i3rXAUjJi+sLSlDA
NrsIIbZtMS2DLoyOPh1exmbyS6fA07zcYbqDGhdqf5n3bxfhQgopFuz+1kNif41DIwihAyXTNvFS
TrzRX6jOM65pRmiFFK/To3N1NcLSDZp/qQAK/cNI8bfs+uPb0TX1Ti8CRgBm0LGT7/he4HfXOsn4
0ZJmLma8QbxaUhU+T3kCQ7u/l+9ku9ev5ft3COw14+yZ/YfX2vfgKZyQ9yssEcxZCw6fvTdfae7v
9fbcK71WdK13RZt1jo3H7VCCWM8pJJuUIJRLYl3TJH1bgO92WfD72/8tyYUvYnYuZnsXF6XF0hWz
qe+803+F/M+pnKiqLok5arg73Yoc3OLdJrv+Pxz2XqP1mf4zY+8FjBjxWZn5cuezdNdenLQXQCN4
hcIBQFNuYWC60BSS3IwaKZh2FhuU+DJrfRlYlEzU7t+/0E3+02/ni820Ws9wuAbB1zhPuzgg0GDM
GcMWNNwdY1j0zVGkgvdZ8awNTeNCmYisEB6uV8u5YOyrc4MADWd+gaAA7zxCW/KjMoBRoT0S6VGm
eQ0BiVwJeY1TXB3O4/4W8j/g9i+/HS5yQkXc/WjO4dyNAt4pIWAuELKiTIc7WhE8Z3o7PqftTEVH
LO7vmygvDeLDFfoXppD6wC81Xmvh4E3N9O3ebSX1fncTPAQzTH0BzPRuZ+EQ8kyo1h/sPUbthTMe
hMKngJmkRdFN0SNsSRGTQGkDYAHH5rKmzkfj4ZsLwDp4XZwwx8XN9cmeL3wZdgod+EKo/b7o394I
TxrYB10JrmsHu4/R+/2Ru44/OojVEl59NZkEBQPhFsh52vRL5AKUxfSC6RbkFW7XUF1oyy3buRZh
O4HvUn82DpNXbVeKLixwC9jC9a2WSxPjbOgJFTQZbDR8e8vojodAvNR80wMWQvW2EcyoPoeGVcIi
X9RCey8KdP+wz69qOalxhk3N69hEODHUuNnJ59LlNNc3xtJvRK3nkr72LkuOmmRKt0rSnBoktE64
TYhuXU2qBZsjTqC1Je+AuwzTxEJ5sPh1/cxRYtbVeXq8/3XBEPbtjI7K9RwQp1ylPHTUkt2IF9Bb
RhnyzaqLiYXcGj3cGktgXS3pQRcoXv+ECwaR/QzjW7YXJgciI5Z8Cs3cE/xDeOLI913Qd4BJ3gAr
eHe6Ws94PpV784ngI0+nlKxM2fkdPl5Ftr89MoXcaMmNpZ7W6pFZFkveqSolC2hZQIfhcnWvmp0P
BBRY2r3BZKm2qzXbAr4rktztR6NTae7bKs2m4pzhHQKUKegU9K/wqk4Zt5zQxJaRoR6MLSB8NbFt
NhU95wRtqHpwwiBQ2sjLDJN4wUOf0UHLOjswsDP2Owb6b20lts2DUkyFeASNCWDZYlTnV/rkKs7A
aodZ2q1ysJem16aZcR7jDe1kgbnNdQQCpK5KzKgEAw3GOwx+CQ/mYQnq2Zqa4g0G1+uZ2siYRB2g
p31tKoRv9JRt55n1rafATzlqNSVfePBTTvlg2EmhdRKuUJJQTkQ44TJ9iquXDcsT+JHgwpKEkN+w
96gPNdlMUCEhn+TigJ38W4OTc81ym60PMgZq0Y43crfuiDjDvIv3R23hXhq1TH1h1PZub4S3o7RI
2lHakBP70uZeKmnG1Jc1O3Z2Sz8u/gvkV8NNqoZjAgGJGg8HVv0IefQLMEJWPimbqCv17udEzQa2
QHxgVUA8EdTDwCeoUbtwPxgP8JSCeBJUFnmgDYYOz44DcH4BC7ff7ZiyEnV8gKPyOEt4IbBkXKJ9
ORQtsYg2DUvLkEGps9yWx6docEdjXnimsSdk1NG44dlxlBgakvzPAQCP6h47CmVuZHN0cmVhbQ1l
bmRvYmoNMTgyIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA0NzUgMCBSIA0vUmVzb3Vy
Y2VzIDE4MyAwIFIgDS9Db250ZW50cyAxODQgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBd
IA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0xODMgMCBv
YmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDQ4NiAwIFIgL1RU
NCA0OTEgMCBSIC9UVDggMzQ1IDAgUiAvVFQxMCAzNDYgMCBSIC9UVDEyIDM0NyAwIFIgPj4gDS9F
eHRHU3RhdGUgPDwgL0dTMSA0OTUgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDQ4NyAwIFIg
Pj4gDT4+IA1lbmRvYmoNMTg0IDAgb2JqDTw8IC9MZW5ndGggMzEyMCAvRmlsdGVyIC9GbGF0ZURl
Y29kZSA+PiANc3RyZWFtDQpIidRX627byhH+r6fYn8siYrjLu4EWiGXh1D2JnVpKW6AuCoaiZTay
qCPRsfNIfcvObUlJNp2kpzhIbUDk7swOZ+fyzczpfPR6PjdWGTW/GRnjB5EK4J/f8gB+g0SlUexn
an43ej3ZxarcEUugduXo9U8zo5a70Rg4gzBW83KEb1mo5g+jv+tJs77xxpkf6mbrjVM/0nf8KLzc
t3pdVmpe7TzcaZlPzTYV0UpvHPqxruV8XRbCUTdr5ZnAz7UT7Y2Nn+qtF4IYNZvM3wepEpYnT7c8
Xn/n8zvZ/1LJ9ZWhy/mseUCLa420WL/ZyBVs/EqMYZkjCK497x/zP5GvAvZV7ucJeYFenKfCzI9t
YNBX6IcoRY+Qc0wqLvFy3Wy+bD2ypRfDB5e3LT0VGNL6Rv/bsznoo/7oRfp+eQsOYs80N8TGzA8g
p2AplZp9YR4mVXdwkDdeeegauEcQuAtkEmuZb5IshQvMz0jX0HS64gVQV8V/nrH6+O3Zzd/yLcrd
hSR5xomfpsaoBPycR92tsv5WGd/qnOJ9DaZK9edi5UUY5vS7oD01ubz8mZmmYESDfrERPO88g3FS
gU1zzVnDv8WyUg/eOBcx7S3L2RcNuRLgWdXWHG136OREhKkKXB9ApD1CvGV6Q+f54LZaHHluDOAQ
5mmixtYPw5SuyheMXP6HEV91DmIT0HzqjSM980wIX3R76uLDu1OMcyFfqRMVemDFCNIjA8aEvjud
j4yq1SiL/AjiIskTCnw/ytSYfrfV6Obr1CzrqFEEett9emxT3w4f/wp579uwxVQbIn4+Of0c/XQ+
kMtJEsKyT2abOPMGYt4rDxQCFwbgrRuEmlAWW/SnoShDS5bViZqx2yd0BH0QguHf8yYF9WJbiIx2
zM+6IshF2YSwsr0DERaig0hL+kC7LdYddQzFQpftRjaC1G8fmUs5hGEtVgB3oS7uWSBrriDQ/dh5
3pk2hVIw7FamvuDWweNOePCS3wbow36LgDdCr1FWxOFxVQTrWwMwYMFB/P7WCzkNMkzGE0gHMJdS
55DT8LL+XKCfLBiMCDU/FuRjAOZ3SE3BgMS02wG3yYGwlB0A8nGiRcbaHeuFQTrCR2R7eWz7OKCm
YMD2TH3B9oPHSXiU9555zvYD9GHbw11y6zImSJ3prZh+9gEgJ6X4j8EDGXsA3t8C8JEHLHjgRJ2v
ISYBnukX7YnWrxcY2yEBtATyz16gz6curAGgcwJo4t+xW3YAoxDlSxJVHVvXJlCwB63L1BesO3jc
Ce9s/5x1B+iD1o1z6E86OOqMG4hx33OP88GzgEypW17Opidq3qjy1kPAqMpP9FStrFVRttjTNYQ+
0IUQ6CTakQlQUv2FlggV2GZgn1RJxN6B6+BYs2a526qsNiiRl53YmsWusa8MwbMZeTYArALHqgko
fAmKX1IhRMfaA8daQ45FdlGIVSmWrKZ/7FgwypBXgfSCS58/yDJt7+3n/DlAH/ZnAtU+6xzaAVWQ
7jk0ozKT6CniuVQO7EzGaPsZBLftNtWEOC8vzs73eQHGwLAXzHui3nAfsMNab+ARQ8Y16JVUl3Uh
ngvJYbmQFW8JV6sq3m6LjyvhIlm33I566O+F+ojlK4dG1aK7Kg6XVIv0ip+LTVOvpXcNuw5YVFTF
wZmFOvWd9luoeLS53Pumog+KFmpRtIUC4RgYgQJzmShKXF9ou1kpiNnYpFDcKRRTlNtDlTLN6ZDr
e2KhnIolZTLNq6LlDvIwekPJl5gC18hvIXtLOom3gFvXTHPHecW0A83cYcowq9tqq1Y1ayJbIrCV
3TuaZmSzEZ5D5SvK3/rznj4LVTbNJ9qoKyXGUecX5xxflvsS6yyEMZhB/o6p++htwJ/+ugl6d8VJ
566+tcUuDN116yU0x45JHjXQGBePtL1BJ2FtBSnUQdPSx+oCNwdFMahWRN01TFSrqkVT0MDIwisy
p4y6GfmAvgb2vIO+H9YKDpuUOjQaFCZclwB00f07CCmS3dKX1Edh/uIZMiGWQkq0nWK14UR5DGRx
mvdt6xMsE+ownA0fF+FCCiMs9MdHnxKHsQyYYOmw7El6Tf9GaJYwchkJExdC0zP1booAFWn+lWD6
aap4Laf+/GF6IZHFAqbQraHB5r/jwSfsxz2pitO1lwvQeNiQ54Q10X5ic7fX/708gfav38r3vQIH
VT49uKvt72r5rtdgFRwoVs2OrIPTJci59r7xar/926DG+ze1WRdNclE8DgiEwBNDEAlmQBIExjrM
4HLa83ffnJPnU4AHrGaEzvxhyNE/QCrmiPJYSKtSHf79GDbr38QEaXelf1I0Y3KgSUKY62wGWUwm
QXMALs//NRo7whHKksWOjPUjv/Hrtf5rDc1sju0P4ikWqxxLFe4V5NbP9XqJDGyV2I9TmAWDrrgk
XXGJOFwE9xnXuXIjULdu+44+5LYfKVi6cg0YLuE7dp/CyDRhF5m2q2aBVDNpGPb//gsg+V+/ndW7
stgusOtLZGDAqkgZ44p5IgMvvi2Z4fkSbjsrB5FDK0wzy50XVElpaCLuXkJqaB6JpISxxK7l2X4u
ND0YGsl56WRwsMRUzzQGASa59C7YDFDvkkERwKqN8RPh6AG/4sJvuMYzHvsh3y6xpOY8VMR6evWG
11yCjT6/vHjzFjojraayc3XF0xiOk/tonHcWMP9HFuBKY3WBrXtOoYftptG/V7O2WFUuf5mLO16C
kel222wdnkZ5tAenVF0wVABU91q2iPqloZaNqS+0bIPHnfDANXQmMU+m0EGGwdYtTGFKjFzrhsNn
2Q2k6F6MkBg7MAsGmWGBSWVPnU1nk6tzCCnoMnEPOSCQTo6a2DALUY0Biwh12CLDx1m47e2Fo4Q9
Pv08fdgeYLTeHknvaOOjo1/P55GCyL8BchofVFcl9IzpaPvM9oXGdH2MkT6GctDotq0o+ixUFhwN
YH6JcKJTbQMDV93WRVsROiLLGgIUBtFi58VgdP5t+EAJjDXOJAnAp/B9rFp0T6wf+FtVJYTqQB7P
vfjWAv7Fh3MvgEIhbDi1xOBlH4sf5NVMxC1YAzWhoe6Syi7ChwE8xXeobt0oaHGshM8HNASOsXry
NYolyerveuOh5lgI5BK3wrCqmTRUbLogdmMA1m4sJVS8eLTNpEQwAUfeVPYXPOam/ZjLhQLnEosI
gUVCq1vi4aoVEqJAN1A90u6mhrnTfxk3rwhqqrLZLri65rras5IhfchEMQ65hFjF8pCvx7FfGNi4
LBu9plVZqXtmwRYId1ShZAPvHeklMxYr5U7egWUTzdJWHtb+om22fBewcxak9rj87iWJ/ZVJ8rQb
m9xKN051KdKfDvotCFADip7Q4NCBOPdTnS1NTo0Jn+eGBd+WLFj6uHqnFmjqCExDDuXmJ5ajOJfw
CpMBD7rl9AprKhTMy6v+k3sd4g7JGTwwQwr5KHDaCDgfWH9sYelapVPu3uPEwEOdu7lUTRr+sjzY
IFKqeGuLt9lBbtKqpfs89eBexux5MPyVHrS2C/RMPEgBhxFu2Y04cX2iJeNJDP7D2qHO17zbCrM0
IzHkStL9cluSyKo3eU7pGzKmWMKUjBMGJL1S76pCKPe0tcV6BYCITWXu09RH1JZUATuzLpXoy+L4
V9UIR8atqtrpu1W85Q4RhAeqAQBrjm7WigzMdFFcbQo+ziow6P2n9KrnaRgGont+xY0tQ3D8kdhz
NiSmjIgBtSBArUACCX4+787Jxa2adGBqevd8fnFe7l6a6eBol12JxaO+3PaCmuBxvryyoXvaOqEq
ThrE0uaXw59v2KrbaJu6Lgz/X2Ho+Jtl4fjusigsSyJPECd66OaXnI8lT4lWhl056qTXcS+XGjJe
8Ni3Rnw/DtBJPq+lIkK7w0eOPu8pX3zLrpi29bmD6Zo1B5OzKw5mcXkubmaHkqw6tjFtu8imZWHx
cpaZjdk1Zpf3nvIL5a+kb/uvQP0g3srQ0FcN3UET7wBCYT/UGLqnh0dD+6qJbLvgW42rbaRj5QxY
RA0cqgEhaBMYnxLfBmMwonyBmRDBoBFbBF5uFOSxA+zdEVt1dWs0wJU5JJVxXskKJtNRjCK6ubKC
PF7PtuA8Bk44+1CXlBWigODO+PKXaSz55sAJX+i+9SXfCaMIE/E78sW1gFJbS+Hpf8B0l7p/GLny
EwplbmRzdHJlYW0NZW5kb2JqDTE4NSAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgNDc1
IDAgUiANL1Jlc291cmNlcyAxODYgMCBSIA0vQ29udGVudHMgMTg3IDAgUiANL01lZGlhQm94IFsg
MCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1l
bmRvYmoNMTg2IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RU
MiA0ODYgMCBSIC9UVDQgNDkxIDAgUiAvVFQ4IDM0NSAwIFIgL1RUMTAgMzQ2IDAgUiAvVFQxMiAz
NDcgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgNDk1IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwg
L0NzNSA0ODcgMCBSID4+IA0+PiANZW5kb2JqDTE4NyAwIG9iag08PCAvTGVuZ3RoIDI1MjIgL0Zp
bHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSInEV1tz28YVfuevOI+LTghjF4ub3kyZkyoT
W65JZzoT5QEGIRqxRKokJdc/qf+y5wYQpAhJTtNWmiGwey44+53rTuajV/O5dWBhfj2yNow8RPgv
b0WEv1EKmU/CHOa3o1fn2wSqLbNEsK1Gr36cWVhuR2PkjOIE5tWI3vIY5l9Hv5rz9eo6GOdhbNab
YJyF3tzKowyK0JlVVcO83ga0sxM+mN3VTKuCcRwmplH5piqVo1mvILBRWJhWdTC2YWY2QYxqYHY+
fx9loCyPnu3yeP2dz+9k/6XW44Plw4ViecSLK0O0xLy+0yO45AcFwwlHFF0FwW/zn9hXkfiqCIuU
vcAvrafiPExcZMlX5AefkUfYOTZTlwSFWd992wSMZZDgB5efd/wEBNKF1vwrcAXaA38NvLlffkYH
iWfW18wmzF9RTylaaph9Ex4h1bcoKBs/BOQaPEcUtQfINdby0KZ5hgeYv2FbY9vZSgcgW0H+AuvM
8dvJzf/lW9IdSJMHgzCPMgcp+rnw7amSpDuVS+RUF+hTa1Yc9Q/lTZCihxv+XfAevA58mJtJMHa4
d/mBV3MUyjsP3QaW4qKmMEkQalIov+WyPgJ6bNMwTq0HVBfHGVsmKPs2XWMvls0DYrZmGoy9mQU2
DtNuD959fDuh7yn5A5xBHIxTNDhEV6cm4+9O5yMLDYxyH3p0Y1qkHKehz2HMv5t6dP08Nc87qvdo
t+vTE5eFblj8GXLv27glVBdTuXskfYo+mQ+kXprGuOzlnt/nnuL7AYHK0GsOnXYdsCdlsUFPFojh
iuqFN1V9holkqZixBPnAYja9D8YJpRPF4GJTqood845l0fBCtO7IPVQmoz0d0xJ5eH8pHxPxDTOV
q44NXVwJ6U73oiyUjX/2BaGNSTH1hjfLe/qOWAFY20ILV+aTiGkpw0BpPZFhoR+OAqE+EQWD4q3y
6Ck3D9CH3eyR15OT2bVJfNzz0FnOYpI7PKu8/4xlnbMmp15whtCiqwEu1OcPJdV/h9AxoZHHQn0O
b4lKUcNM2y1yY/LHZqk7WKbHqVEdq1ZsrwyzlwJLtpfH2CcRt/wB7IX6BPaD4qzcF3vPnMJ+gD6M
PZ6lcB321rbYe20Ys49conKtWjm6Ie1qWI6OyBADKl8I6BlcrLC0FuaBfxFARK1ZEI62K7SvKWad
Ua2XH1pNgBVYvWIp4MUt9LZkbTVpC4/Bdil250GwhfoE2IPirfLOFafAHqAPgp0UOIy0xcylLdSR
1rL3MrR8xAZfYGGjgqJbl7PpGczXUH3mvlBXX/gJO11DWe1oiMNxAsHFCOfBLjMteUtVLjffeLnl
xrjDDIoZbMszJMU/rFeid1NX9R1plGWnthG1KxoksdMytcQyl5Gbew7Gsk0OJuddykHIy3EvCm4D
R9+tWVgskt9SLVqK6Ux/5PUoHnQ5kp7w92lB0en2oXDK2QP0YWenOF7knbe7QT5Ket5O2c+5mY4l
KwQmRwllEaUZRr7vNuGceS/fvbk45L4gbiKcAYOfM5ZWf9cy9leNjPu5Eb9iG2mEASQKEuXflZ9u
Go6YggMoYS9g+YRPtWr4Gjii1vUKatG1uFs38kaB5cxBMGByl/oJ5YZJ2Jq62ZSrpXxG4pleFuWu
lGjLUYS8HwEh4n3ajoF+P9xarVU1N3vLxvCIp+sdL3om8Wi+vRcqJhU/KWmo4OuyPCk1ITBTc8nX
Cho+vI4SKRewKJQeTV0loGpWUkfSwQCHCBC7hAbyqIXl0FZ58D0MG9wzB5vAV7GukRMcHgQORKr1
BrNbBR/ULLZ4o9KY7BRNIlUpDE3fnlUHGG0eHvE4V5Os2A99j9JVqcMZOyyuypUUe+p7x6KPicPp
iky4HEzX6d81YTU1JRe7fH0Db6eSrfKrwf3jFGStUn/7OH2Hb1RMRcEUh5d9eCdpF95xvL+76Rg0
XXGVliAwskAX9ENUxqD939MXr/3rS/leytiZyo9jeycvUMuoxFiPYvRFd6N97Je+7MefKQapa5Lw
uJU+RpZViPSVmW55nqGqhdnKlY/WnwOaOMhli6ugj+iffOd9Ecwvs7KNI0wlS9GjiOUdYk4R4zix
VMporsIGTePZnIOo6EXPnxQTfwCHtzUdzxv5pQGj4Hkg505UaOPCQFroS1VuFvXidJ+Ik30itTFz
ZS4oHJOuGp5MQVd00GmDgV/qTcPDEN0DqBFgfZR2ilYJhFQQLZtb0MVsTMPMH4mf/yLAz7xx5mEl
sb6feb4DI20zryc34znAm4Wmnoo/j+j3wvJ/eXvDKeNM6+HXx03O+/2163GTE+oTTW5QvFUetS3Q
Wm5Tj8RPMgw2O4/X3e4iEmWtU5w2GjpmQi2LCsKMjp7pHryZzs4/XLynls+TD3Fc4OB5BIh3xRAa
RBqGYkBQdOb7CZyGSXcsepo+jEKU7VFIu65gbBjMfx+9ms89YJReIzlLCs0E4sKGK/Rc6BbV5W6f
Kt7tJ1O3R5TG300wpiHpW+CcXNOoAq9lfNcVDWMxMVoayvCeFPPwpVOXk3ErN8oMpW5DyRNn3mqr
RKgUvqb/oVaCx3mq/Tw94thdi+qWXuuLTp2dBaLyYDBOeMLvCS+ek57ApxYFVSTmy/FbWTG4ETN1
c6nmHX5/IrecS7ozpDyZJx3qwCiKZkVJrVVddQgXA9eMx9mBl5SUxvaeAY4+n2Er1SzpLrm24OsT
6qT77Tjjy65HM8rloZIHWQon9piGGwtdwggMosGu5GEzNiIKItJu3tyrQv2MGKka7uVxE1gu0bw4
MrKUT+8q1SfysOrb1ex4dk2V2FoL3f4WKMQwqyikXGv4hTw7rnF3bUpaHPQ7au4G9OWaOfv674RQ
15vwpU2b5ht0Mbb6hVwwiz3sGBiWT0LhN6Y4ooGCzTrgk11i+8e9UDi0rJHWX9VwLyzNSiShBN2g
gPRmKYzlDbSStziApEa03fAsUe7WeiqK+ihzx2fr1Sj3H9aox4O03Ec+c+LUlWbOF172Ip0uNWdB
fJh/tDkh+BxNk/170QHOMY9vqSBdMKaW446+tJQPy2hn29HO6mhHZY7oC5DnWrIdykrHr0TVQbmp
MVO+1LJ5fBv1NhvsS0h6oi+dFhSd6b7vJNkxOU4KxH5IeJhKNin1KbNOf7ulD6h/hvzqfJvA+Yw7
ZgSz85GFnzCMfkdGDMqvYCN4C7/+FsFiZHNqpmhIgaGawu0ojhwOI7KBqm9GM9zCcCaePKM5hXgw
9H2Pp+Mo6Ny4cf2XkY8da6bppnAo1W7giEBm3Ix8EouatKDxCTki3Ihkw8u3aYs1ZzH2evx0kYqS
lqVjSJMwlS935pF+lLFoN6vlNWmlHRZCyBNhURiUpWPwaKuq/fcA/faVKwplbmRzdHJlYW0NZW5k
b2JqDTE4OCAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgNDc1IDAgUiANL1Jlc291cmNl
cyAxODkgMCBSIA0vQ29udGVudHMgMTkwIDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSAN
L0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMTg5IDAgb2Jq
DTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiA0ODYgMCBSIC9UVDQg
NDkxIDAgUiAvVFQ4IDM0NSAwIFIgL1RUMTAgMzQ2IDAgUiAvVFQxMiAzNDcgMCBSID4+IA0vRXh0
R1N0YXRlIDw8IC9HUzEgNDk1IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSA0ODcgMCBSID4+
IA0+PiANZW5kb2JqDTE5MCAwIG9iag08PCAvTGVuZ3RoIDI0NDggL0ZpbHRlciAvRmxhdGVEZWNv
ZGUgPj4gDXN0cmVhbQ0KSInEV9ty20YSfedXzCOQEiHM4K6HrZIoVsw4lhwSym6VnQcYhCBGFKkl
IXv9SfuX27cBQYqgnUoqK1URwHRPd09fTvdc5YPzPNdGaZXfD7T2/FD58M9vmQ+/fqySMPJSlT8N
zkfbSJVbYvHVthyc/zjTqt4OhsDpB5HKywG+pYHKvww+OKP16t4dpl7grDfuMPFC54kfhZt5xlmV
lcqrrYsrDfOp2XNFtNIdBl7kLGT/oiyEY7FeKVf7XuZY0e5Qe4mzcQMQo2aj/L2fKGF59bSfh99/
8PkH2X+t5PhK0+E8ttynj48O0iLn8lmOYKIzcYZhDt//6Lq/5T9RrHyOVeZlMUWBXmykgtSLjK8x
VhiHMMGIUHB0IiFxM2f9/HXjki/dCBTWDw09FTjSeNr5r2sysEe9cUPnpX6AAHFk1vfExsxfQE7B
Uio1+8o8TKqeYCMvnLkYGjiH79sDpJJrqafjNIED5Ndka6BbW/EAaKviP1cb5/Dt6OLf+RZpeyAp
nmHkGZNmKoY4Z6E9lc5sTWg51OjhZYXhNc6jqyNKJnb7slrVzYOqN1XRVBvVPBQr9VyUwlU1ihkO
/Ih7syBL1dB4QZCQYnZiaDUHIWvOQVEMisbuMHRmrg68uF1TN3fvrtAsIU/VhQrcYQzh9CCSsZOS
3nE+0GqhBmnohRClOIspDb0Q9NPvphrcf5uapi01DMFu06VHJvFM//ZvkDu6YYmpJkA0e7X7GP0q
76msOA7gc1dapgU7P2L3Tt3YS53K9cFb91j4Rj42FThZQ0WtwJORU1YXaoYlH0Mx4haMQQDc73mR
Umy+KURGM+TnoiIATBH2NDxkeeti+BZMqklBsylWLXWIyVM2z7LgJ17zH+ayAbUeSwBv+6PF1BPR
6t1uhfunwtFD7w9HCLwhBoOSPQoOWw841Whn4hrIYH7/GdCVsjvForuALEdnq4k7zOBl9blA9xtn
yYQFP+YUOkC/d0hNIKLEtN0Ct86AUMsKoOUwdkTGym7bCYMqAyWyXB/6PvKp8/b4nqknfN+7nYSH
2S4yx3zfQ+/3PZwlM/2FMLu7wrQzbWJPOPfs58/cFceYx9q5UFwFD5SVL6tHehLYSZ5SajNZ8dqG
S0CAsstQcI0hcErRsTyBz32JB0EwMTTP3iAw9UQQerdb4W2IjgWhh94bhCiDWQFj8MHixp2LPmEU
kqXb2fhC5Wv1mX3AaLS4/+oafDvwXKMWFmAoXNCBKm5AvQ4kV2+qslp0NczVglHJdjZBoScaZorl
krobK91Dxn2DKkgMSqPvy4x5JXbLKVZ7Fom+6kDfvhUMib7CvIzi2PZwk7QZLuAiXknQK3RWAIi5
vJTFZl7NvcPkgq19mQWkE2l1fCPLNLuMC0Is4oOtx+n9ORWlyGsLu8VUX2ZHyipOsdgZY0eRmg65
mAOYKsK20GGgHBHn7c31pMsLiGtgkXkv1CVPIlucNjBXMFXWOP0nTrkoGpj3ef6EuGZCVrwkXI2q
eLkpPi2Fi2Q98HgKKRBCCnzCBprB4GoijBynQuKI9Iqf8+f1YiWzbNAmsJioir09c3XlKWv+ZlPw
at1RqkijmKHmRVMokI6Zkf/AA/pu6LXzIRgCaazJEvAQJjJ9N/TRsYhG9u0LU8sHfqLGhGqGPgvZ
VWKTy+wqlhJzL4lcQZeEplVbRV0Jio3AS1rSahdOgGGackQLYXFIFcnKWemqtaxDq1rVzFN3D2lV
480uRDhCYDvcL6Y84bc9wpbNLGrL9KlaSEfmFSHsgIl7Oh1fXMUPulRCoq33tRLnRp2O0WHtR3Al
6J+DhdqPAP3brfB2kD0CAn30fhCA7hOGpwbd8b+kvUgH359ix9fq3RhrO3T4lwokdX4cK/6WXb/c
jW/gzYfSYAFjmMk6pREEu/ugwO545WZSo3DD5A9webcoeKbb/Z2+zO1ev5fvrxDYe4yrvfPvoMEX
aPgInoJoOss1thpMXA0On390v/O4/6+3fa/0nqJ7epO1WSeHx+2TGxol+dpqsFr/Irv+hrdrmg8i
mg948MgAoJ5co/laoTUBErJsyRMBtCmNlyKZQ3RILmFvAMQZH7Yh49ByYl2FYTu3BNkug7JdBqUI
7i8uwe4jPWz9wGBuqHdRM0AK9YIQ4I/Y/sHjIL5XCHUxN5CYzEf8WxGthv4uYBjLVgluBxOD4MSN
R6gnMLF3Ows3uxtNZl4N2330XkwMA79z4/HbedDsLps6QmAzcNYZolAia+p6PBtNJ++xzfFFFDgm
tzcXB/4AxD1x+RBqvz/6t1vhrbdw0jWvdx+j9/tDpx1/xG1eOtpz898H53keKijbeyAnUSYZjFyQ
akxPma5BXmraFD82D8mkw6216Q4N0vqfuVUfbd/tkGDQ7zKQPHabuTqYUgqeCfhXxJTc5GXM4Y/1
SslgIlMQDyuiSVV7Ur9vlts3/RtzIIyeMze2s4uwytbJjUtzdk6oAlUqVolR3RPK6es9l4hdX9iu
hXh+byose0fJ7rnrbmgejt+udGyrCQEOI167OFxssFYSHC75uohrBVmGPRO/GI3wjS6nezSWgeM3
yODNXkd/ByVfd5qpiyetynUXqHeZxHgtt9pIILuo9/l4Fdn+/cIUQfgVfZWVemGWxYp3qkLJAl5f
Q6dmxmKp7M4nQNLYYWlLF+8cRbPe8KngTKmfmEPfdirT/MnKDNJdM0nZT9hKNAE8xL2kFmCcR/rc
S23tXEACRJKX2uZlJnlp24ehlAzlt5C1msW7xL8gOcyg5t0v7KrV/HudEfxJZ2jT5qz4YloBDFEB
FA1nK2SQKj7x4pofn2W5qbaNKguZYbbVtlNxhlKAq4abKgtTIqMhmihA5EngPtImZ8KZ5lN9U8Fu
Gbpqu4FVMoYsF6LisSsOpyyMEDp3SNl2yWaN3CEm6Fu42kbOGcDPkIn4OXp7pka3twI4zDIZ09rb
yfhADJbN27MeOGh7Kzt29uaOjUmc69t/wpmcG1D9ehFVJM4l2vFmLLTLqeW6QtMTZ3zJE45dPgOM
cYBflqdg2Y7Ys0cU8eKIeUDpLuFxXfbeTvc1XR/Ikk/sQTpA5AIIlyGYKi0MOiPfGAOaOdMpejkB
XdPDi2Zo0lNDBFNPDBG9263wdkjoDE1CDoLeK2oPCW1C0mmDjqm09GOCT9HOR9tIjWY0z/hqNhpo
9RMU+O/ACHDxRWlfvVMffvPVfKBTHHXAhCxEtU+DwAf9abuwHMxgCYCGeIA3JR5A6LDDs+NI4Liw
cP/D4H8DANiak60KZW5kc3RyZWFtDWVuZG9iag0xOTEgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0v
UGFyZW50IDQ3NSAwIFIgDS9SZXNvdXJjZXMgMTkyIDAgUiANL0NvbnRlbnRzIDE5MyAwIFIgDS9N
ZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0
ZSAwIA0+PiANZW5kb2JqDTE5MiAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9G
b250IDw8IC9UVDIgNDg2IDAgUiAvVFQ0IDQ5MSAwIFIgL1RUOCAzNDUgMCBSIC9UVDEwIDM0NiAw
IFIgL1RUMTIgMzQ3IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDQ5NSAwIFIgPj4gDS9Db2xv
clNwYWNlIDw8IC9DczUgNDg3IDAgUiA+PiANPj4gDWVuZG9iag0xOTMgMCBvYmoNPDwgL0xlbmd0
aCAyNzIwIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ1Fdfc+O2EX/Xp8AjmQl5
BAiChN/OsibnOGdfT3LTmTgPPIm2ldiSK8l3vY/Ub9n9B5KSTTuZazutPCYJ7B9gd4Hf7h7PRm9m
M22UVrPrkdZpZlUGf/zlM3hmTpW2SCs1ux+9GW8LNd8SS6a289GbH6Za3WxHCXBmeaFm8xF+Vbma
fRn9Eo3Xq+s4qdI8Wm/ipExtdM+vOvapiVbzRs2abYwzO+ZT04eGaPM4ydMiWor8cl4Lx3K9UrHO
Uh8F1XGi0zLaxDmoUdPx7ENWKmF58g7Dw/GffP9J9r82Yr7SZFzKO89ocBUhrYjePogJpvhenGGY
I8uu4vjX2Y8Uq4xj5VPvKAr0ESKVV2lhMo2xwjjYEiNCwdGlhCT20frh6yYmX8YFLHhzu6O3Akea
VEf/jI2H/ah3sY0eb24hQByZ9TWxMfMX0FOzlkZNvzIPk5p7EOSJ72MMDdiRZcGASs5alWpXlWDA
7IT2mut2r2gA7lXxL9YmOvx6dvK/+VWYYJBcnsSmpvJGOYizt8EqrcOd0J6NOl19joEXvMevu+VC
Td9dgu/RVTPy4MnFz+fJ2/GZuo+1Tauooch4cCqclBxeFlhF/oZfzYF/E52nVekLlZg0z0vaEDvX
hh3llnc0A+0O4j4BTdE0BkHXzqnzy/fHeBqF/FEdqTxOHGwyhQi7yNO6k9lIq6UaVTa1ED3nHR3P
1FYqoeemGV2/Tq2qlmot7Nv06YUpUzMs/gq5tzZMMdXkiHJPpJ+jH88GbpxzOQx7V850V86wfz+C
owoIEBgEmAVh9jLYQFw9hHeFMAGQ1xzFGErAMJKY0Zkoog9xUjDomGixqUXFjngTHixj22rd4SHR
iI4ZvIQBQbYCNiLd8HqsYcN89arlxJMczZn6ILNZmfLEP/qyeBEAulKt1FU0F5CCsxCcXQKEDwea
qS8EelA8KM9eiuQAfTiSFngtxpGiV+SH2QziYXR0Ck628v0TADZdjAqdcYSec+CUUwyri1afa/S3
ie6YsOTXgsIKgPoeqSVebmTaboFbeyDcyAwAcOIi0bEKYp0yuKCwiEzfHPq+yCiZD/ieqS/4flCc
lFvfReY53w/Qh30PtgB2Bt9nLWrmkgqml8foh4ouBVQjEIZSYApHP1G2mWDNUEZH6nQV4435TE9w
oEGURdQCQAOsDVIAswxt5wlpezvmNc5CJryP0cUNKuDwWLo9RYu3PX8bB6l30N9MfcHfg+JBeRuN
5/w9QB/0d+Gh0giQZdqMABTy9gc+mZeUvT+CE8owdTGdHKnZWs1vweOQ6ue/01vtZKzq+Q4rNKgV
NMKK2vHlCOQtHumvNNjGDmAEL1BDZ9iBuz2KrFesc9PMmwfUxsNW5ZJVrjDaDoJcUUGZAVJKLsX4
5nAeKL4F8EB8SfQtJrcSaiCYzaMzYMtQM68bdoH7wv9axje8dVogPYx6lg+GHEgvxPt5QdZpuqPw
XLAH6MPBdpBkqhDtrOjF2FF0q2iSMKyz5wzeJA0umQLK23ZSjYn34vzkdJ/7FLmRwPxHivxcYSop
KKPgxVtzQT9f1hLSQiJZCYNq+L2rP93tEW4lf2YInupTs2PiF16kaURZI+mSh4uH9ZK/8IyZtriV
rala2NRxGra72dSrG15LyRqytFrUu1qBPox+ptA31rpQ49muctUCV82KDxzuIrYhxWtKm1V/L1R3
bx+ZCpeqvTSI+TKsRWoKh/Id7gtvZi6BwRN6QqMLev6MbvbROQ0oeVewDg7GdI7PuMdoAQ5WoPrS
S5FQyrPmqRveAlYWnQ+/8L7Zsv29qmBuogmA2QCSviMK0xdMV5/76jdLVnXNu2ZO6vtwlodrFly1
jsLJ/b3KFtgMxS8xcD8Ku75G9UrIjlvLujNQONeW1V2hb0PKuuVq63G34I815XeD7sPbs5Jir6Fs
pKPVTm13tQx2WJUB6hwCTlH6rj59gjlCHYadYXFRLiRbIIAcij4lDmMOAJO1XVlsijbHCP5M/iYI
JFjD4NIC0Il6P2E44afc0R8misci9ZfLyTnBeC4KJlCGoctm33H9kHddpZRxk1WMVRbHOeIBBLl/
K7mM634vt4Td5x/lO/wa3NLxN3ap5IocQDSHAGRtU+rbplTOqlKXP8XkxQ8kkgSZ3jGnMLaSmUhe
RRNEaYZZSJqA3TxG6MQyCW7UVdx35jeY88rXVYQ20InKCMhe3dfeUSHTgj/+03v9N339MUY+BgCq
XrvuGJiyDWbemv2SFi0pn3Ix5Mv72GDCpTxbSr2Uk8Ot1MdJWDQBRMq0GT5H/2selzLScJtwHlAf
zIB70ZrhWjOsmNGWn5rkEsItT+DkobE4/H3rPk+xYHFU8zgusWy0abgch86ly/MQKSslLpXe2HHS
s5Y5VtT0DO3FKyt7l+PkbTgJBYBl3zH5/0V8p4TwBmKCdcXZYYbN866XepphmfpChh0UZ+VQuzuh
6pIGB+IDDIOZNi+yrpXL2itt5EpzmAARDZy/KRpeypw6mUzHH08/YGlEtSRynF6cHx04JHfZkDeQ
NOyKAUHSWfiuh8Gq3RyIDtCHvZBXnRdce1gjncaz30ZvZjOr4CBeA7ksvEAgckHWZ3rFdA3qKtNh
pDVdbW86jyLsbTDLaGhmDTiAq0nP1WTFZWdFdW3OhaThmpfLeBB7F2M3dEnPoPGERhf0pDq+ojq+
gDo+4fYVB2PqSc7oe6+O97Ier81PKo0rLo2N0IMQ1dk+2LEm1PIIFXmohk2ohn0wgq2EuqTfChQR
8+y4zr1lVi7uw6Jc3LeLssC8Zn3L1nd5t5R4tCZxMSAsu+qrfm5xWRQCKawSGNn/WrahgqyV9gfi
89A0m6eN3l57Jw3QLbcO3BhweyON0n5T1Kg1dxFhzO1O13LstyzSBoUeZ3r72O9EFmiJDVtomWL3
fJPDOvf6JB5Ia5Edlnj9MugjCEO2n683C0wp/iChoLlYhG/jpJCsApXWTZ+P55jt749IwbOOJW40
b9Qjk5crlFF1S1LMdQ+FcBmh1B2cdqgwdusN7xpjmZXmcO908SPzjXc+a1s5TGPoh/Et3dlmLif0
dxr2GgZMoEdUFEEBQNNlRHVAAeZBHYAR9RFVA8g6phbmrHOmI1+y8u22lq8bXlVwY7nFkwHyRggr
eq7R+XCLmwV/vO4gRsb8W5Gx6JBRWjpEJjnkBTkLQBx8RUN1fBQXeDXGjzyx2fDxxwqdCFuQ1jKo
+QUXh1zhEDboYgUZwqUi3JJWx7HiWda1hxYFQ0DLuuhz8lzYWYyA8alZpIeZELLRUCaE8QuZ8HlB
1ll2mc75PZopq472RHKYihsS6kt7embhQBzQ/Qr5zXhbqPGUsnOmpuORVj/C4fkNGOEoflE6U+/V
L79majHSHrYJmqzzWOLcj/LMpNbyhLXqbjQFngLOHEyVOa52P9IVLG9bobuOwxW4wt3o+ruOyQJk
oGbj2SM44VgzTjnkyX3qqv7qgaflAC+BeaQZuUmz18gEUpXB0x8mUDNOMQ/cfGQpLSsOLC0DbDPo
hVOHPFj7ebQzTGABddcZZMCOvj003jPHAALZvjnC0jFUvAtYNc8gSzhYxHt0rYdS0/CIfQ8QBlQL
mrwj30OKdIEhkHMwUztW+K8BAJC1/IMKZW5kc3RyZWFtDWVuZG9iag0xOTQgMCBvYmoNPDwgDS9U
eXBlIC9QYWdlIA0vUGFyZW50IDQ3NSAwIFIgDS9SZXNvdXJjZXMgMTk1IDAgUiANL0NvbnRlbnRz
IDE5NiAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3
OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTE5NSAwIG9iag08PCANL1Byb2NTZXQgWyAvUERG
IC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgNDg2IDAgUiAvVFQ0IDQ5MSAwIFIgL1RUOCAzNDUgMCBS
IC9UVDEwIDM0NiAwIFIgL1RUMTIgMzQ3IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDQ5NSAw
IFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgNDg3IDAgUiA+PiANPj4gDWVuZG9iag0xOTYgMCBv
YmoNPDwgL0xlbmd0aCAzNjM2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ1Bfb
ctu68d1fgUegEzEEePdLJ5Y1p2oSJ42UM52p+0BLtKxGFl2JSppP6l92b6CoC52kmban8pgksBcs
9r5X04uX06l1yqrp/YW1QRirEP74qwjhGaYqi5MgV9PHi5fDbaJmW0IJ1XZ28fKXiVWL7cUAMMMo
UdPZBX7lkZp+ufiLHtbrezPIg0jXGzPIglg/8qs0ReD0elapabU1uNMwnpo8VQSbmUEUJHop9MtZ
KRjLeq2MDYNCe9ZmYINMb0wEbNRkOH0fZkpQTt5+ebz+wfcPov9ayfWVpcsFLHlIi1uNsES/epIr
uOSFKMMxRhjeGvPX6R/JViHbqgiKlKxAH95SUR4kLrRoK7RDnKFFyDg2E5OYQtdPXzeGdGkSOHDx
0NBbgSJdYPU/jStAHvUHE+vd4gEMxJap7wmNkb8An5K5VGrylXEYVD0CIW+8MGgauEcY+gvk4mt5
YNM8gwtMr0nWyLay4gVQVsU/Y50+/jq7+d/8SiJ/IQmeMIhDsEQKZi5ivBRfpY0JjA681PhmjNYt
9BSsnWs1BP9NQd2r1XK7lO/1kbIGoK0kg6gauCCKsg77uGUfM/spGDEFI47MINYTY6MgbffUzce3
V3i4gD+oSxXjiTF4ZA6Ils4dTS+sWqqLPIYrWZUWKflaEOdqQM9NdXH/bWiet9A4BrldF564LHD9
5N8Ad86GLYa6CFPWCfU5+NW0J3zSNILlPn5c6tUbino/GBBIVyYEt77H6I5ksalAyRY0uSZNzqpL
NeG4HhIJ2iACxb/nTfKj+aYUHs2A38uKshzypqQm21tg4SBaCbSgA5pNuW6hA8jPetY8yUaYBc0/
GEv5oGYpVuBzkS53zJAlV3EACN7yXrUZZN9+szL0GbP2knvm4XN264H32y0G3NhbzbYxZ5N9UMAt
9ZjSqV+9gVWhRxAE6npn0CpPK6wzlXoLOS8BpfGzNHgF0DuiVMeKSkIqmj2KYugziuolJ+ZxsVfj
OUX1wPsVBXmgcKionuw0+UgJwknOQJVlndUbWBWUPDCdXCpMZl34M9msozIHu65XZQx9RmW95J55
q9BzKuuB96osKaAotwkhbxOCY4VRPEf6o8Eg+wDKsH7r3WR0qaa1mj1AKOa6mn2it2pkrcpZg81M
TTkAUgKFfqI9mMI61V9piQGLpTciF8RM46CXojJdr5nvpppVT8iRly3b+Y42yLeFUvig+aaUH6BH
eTTOwnGYEwotZ/Op5YIlCo7tGEa9RgTQMxY8T8g83d6458zXA+83X1qARK39otZ+Wcd+OeX1VI8w
gUqqjtHNLdhxYmLxcOrOhoT57uZ63MWFmu5gk3Ev1SsuvFsMAE4jBfapEaTb2bIUI0FPBSm9ELDi
LcFqVMXbTXm3Eizi9cAtl8GMNFd3WC8KaMZcAkQVe0amhXvF7/lTvVxLfxa1XZ6IqMoDmrm6Crz0
GygxtLnonKnoQJFCzcumVEsO8FCBumwcp76ji5N99ynpBSQip0SR4HowAvC6oUVHNCxoqvTY6ht0
V2q74w0ItjaYUuAhy1IQxzfUdJHXYyCg10d0twHGEjatVp4lby2YQQXxnaK9kA0jKH4J6dmLQAg6
WG5Ac47mFFSrHKnuakb2Eh8ymh8csuTbPBqSeoeOCTmWyJlJeUDM0taiE2axYhZfee84lpOs2LdK
J+Es0P6I7icX5gKKYqxXx6SnwP5wBiRY+nBu61coDjb6MwV0ysHLbU8uUer06Fq9HWGMxpqf5Om5
/mWkeC1Uf/o4uoEv7KWYATQJHR9P0tbHo2g/tcjQO1pDXuaoM9gOFhR4cde7Y/Slzu/5kWP/+b14
575aseh1LNvVvzlWkVYiSEwR2KKd5U7tckL78Q06YgH5FzkMPItj9Z4OhbdgEpix9KrG6gRJz2BI
zG/Nd2rzP/P1rFQ/bixWaxxkBRa7Vq0n1escbVt7kqA4LT2V6Ft4H+ubDvAm+x/q8/wX9Sso//R3
rJCsVUj0mxV60pSbhlaUhrRFY0Q82lHjgG0XFtpMLxvFOEuDTQW1ZAkV3hyKyNki6/tQUg7n9qnH
BB5pUfx/2FakzzQ3pBnrJ+NsGVF0Rfq1vxnUodC6Ni5OuvJOYztgpRAfS3ws8MFEDEF7UzfVrSGu
zrFejyIiLDxvRwkIGsB3716PR2b6t4tBSwPyWCwFQhN3VC3oA2hp0OhglAKFwZZryIPC6/OlxbUn
+9T327OaGtL4R/nF0kCSynPHW+jXBblzqmX8sFr636ItiTtaPR33JHG8n25PexKGPtOT9JJ75qHv
WGweYVdxQn4Wobc3iZJwPymGbWpykprQIRPsMNArJ+iOmeyp69Fk+GH8Hnu4GPcQY/zu5vJIIVEa
9mkDQf2q6CEknkmxH6jAOvB9SNoD79dClO+1kLaBoG2AIfNyOo0VuPM9gLOkkNqGWOAMDM8ZboFd
3il+sdtPExLlNCdgzx3joERPaqKpUQ7JoyCmcgEpftW8510Pu3HunnP9Cakcdc8RDUa4ueZNVW4N
Dor8FCazJbEsmTMv6jVPZZhnvrCAVeWZVAc8uUUEGlmLnFcy+ACCkit2BgoLKBsDerAyURR8B5on
kP7h/FksuOIDA2pPqoAHosQPRAkPRKKB7oVFGYsDDTEvYSwS8ooR1s3ZmmXztquziaS2e5xgschR
P14/GmgIQRV3hpjW/GqMzWmmc5jK4YI2pVGQlnBBh0k1+N5s+oFSVzWrN3PVPFAGqjpeYbmLgwsN
EhqiUpwjF4d4vItof+ccVkmK4/w2q9SOUZZrplSlkg0zgDjRC0YsV8pT+vSJ2yvKm2VTb/hW6HRh
dtK1daLM/WyU7YNMyhcIEpFPgapwJqIo6Q4zWNcuDWYzdUUumDG6Iq/Xc8CMxTFSnGfxVREnDwdn
JT+MvB9S9bdc/ROq/jnVSUTZm4j6g4pK+ZbZlsR2QcKSd2Z8BqQsRniq1yKAYknrs6djFDhxYy/5
6QkE/F7DRD9pGBe3/pt6y6SkanQjMg32kZ9oqa7QadEsWIPVeM27jSAraY+oDaVxgXqRhHRM9++G
gROnRhXwfynrBbMz2F+9UL9Wm+U9GsVSvbdQ7xt0ckiMtQjgDy2JhMnVAU21mqtadtSsprYpo5iw
8vR7wlKuVM6rjVqicBhfIlOjmlqJDP7qTSnHyhU/04oFWjHqTq51No/YdgazMoNtqlm1/Ez9aYV5
OUWXpnC4N5SqI5I5pbLk6GINedED03hrxCgVZH7c9BzGvFw2OLkpj1XyMQuCqW2F9xSCZbNV/rQv
mDVxtCA0llBIVyTATgS41dtSuu5Hk4uSsk6sMeKWK6yX7U6O+Wosti1wtEeXgx8Ycbnap8vq4HpL
yQK4JQeeTHhJp5VGB3Bk25TTckEJ2HJahjx8a07DsTMrUTjq+GcjMW0jMd5HIntY6iMxpkgEb2TY
JaeuMfl/TlI7ice0W3UKciLMa3Q/j0n3Sw/LjhNEKjypxGhMYZFi4SnlkPKu/swYv//OVJX8pIJO
W9/hA+Uq0g0q4hMt1fWl4gbYcvIZUOCNcXJAt0UccKqG3IQGi4zicoA5CaNdrSpheE+U0B+gI252
zG7tX8RIVgs+ujwkhOSBvomgOeP5Qw/JJFQTEfWVCfXwdaciFdQNMOvt1h/CxCK42nMmllCanviM
uivvtqKgxg0lIu0IIMj/Kr36XtuGgfC7/wo9ZoNmtizZ8t5K6MNWRmEd7KGMkbbOls1Nhtsx9t/v
7r6TIidNVyiBYEmf7pd0p++G9Q2XhJQvh4THp2vqcQrLjWTJLT/M8kH0E18PdD3tLEtfvqTrYSDj
lBci9ZaSekJdwgxbjYpAnQ2SBRQDufdE5LY/Zbzuv34Gj1rSiSJpoXSpCjDqn/ucNi+8o3VIRIea
POWDgR+gV0ywf/XC6T2aBk9eMfvtdQTMvSJupDNwwjiI9XuQdK+sooqsogNf9jOgjW4SURsRr/Ku
pcrXVFet7Oqxqs2Cn4JzGlbhWjNBVxNyc8ekERCVys2mnUXJMvgmK3ue7ztzAg2qeHEOppFzM59U
QTH+o4VQAtOee+jtSyv3QUp8lFuKF4XPHCWZ76+WTf586PMLS+etVxaz2GxAfexsx6041QExOXKS
cddCZho+a5ES0+3pBD1FgppoiKrmKqZkJMQOI6YpHsgoAMl5cXH+7izrLFnGiMZ2q3YJAawPknsb
wyQejamg7B0k9YBlZVNrYXe9hUX40XxuoRPdKzrHt/JtTmV9g/W/zMnrg74WadHFMaTQIen40b5U
t0KuwZbvGOlN9/Gme9z0bgZbFuLouXyb636FNfVg7JMsUcCB4pJQpQlRP5rtuA/cEW7haF3m72MO
qJfwXAcArKFQMpCprBg2ZLjlJHyQt/2N0f2A3aoax3n2qQjEOqkhrF0w5Zz+TuR/7IsVL4WAJedo
k80XvW3n9vhGyKSSaXW1au3cN5P1qiWjm2O7j6+yUbr6lF1HlEfAEfn/WX6zuPdmcUmFh3+Xi6Iy
76ki/SAgpcUfU5Xmg7n6UprbogrUVZIkX3pWflfUZTdvHCacM0NxKZggUx1be0cTlEQubRoyRMUa
hmL1mgTZeUlBcATummyXTrBkSk/Z59o2U50AaZnjCanRXueoF8vt1YncXufpTcjtTZiEcJ5PZmqv
pdrm8l2YmNhLRCuEXHvEJASdUKM2110jl8VTuyKRcE2JcGFCJBNGwk51uGOb6xCmmISoxCuR7KwD
iPxoRbJO1HSXOnjawAmuE4hXgJuYQLyIqMuUh+6qJXKZYxKCNkfdMTxsqN4cBFAn8njVdID5YSVI
AnR27tSnkp4awZQ4YY6WC2mC5fKUYFqySyBBbVFIAgSV+g/yj6S3CmVuZHN0cmVhbQ1lbmRvYmoN
MTk3IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA0NzUgMCBSIA0vUmVzb3VyY2VzIDE5
OCAwIFIgDS9Db250ZW50cyAxOTkgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3Jv
cEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0xOTggMCBvYmoNPDwg
DS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDQ4NiAwIFIgL1RUNCA0OTEg
MCBSIC9UVDggMzQ1IDAgUiAvVFQxMCAzNDYgMCBSIC9UVDEyIDM0NyAwIFIgPj4gDS9FeHRHU3Rh
dGUgPDwgL0dTMSA0OTUgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDQ4NyAwIFIgPj4gDT4+
IA1lbmRvYmoNMTk5IDAgb2JqDTw8IC9MZW5ndGggMzAwMSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+
PiANc3RyZWFtDQpIicRXbXPbuBH+7l+Bj2DHYgjw3d/Otubq+uKkkXLTmaTTYSRaZmNLOpG+JH+j
/6L/svsGkqJE+W7S9uwZgcAuFot9ebB7OT97NZ8bq4ya358Z4weRCuCfv/IAfoNEpVHsZ2r+dPbq
qo7VoiaWQNWLs1c/zoxa1WcT4AzCWM0XZ/iVhWr+5eyDvtqs771J5od6s/MmqR/pJx4KL/etXi9K
NS9rD1ca5lOzbUm0hTcJ/VhXsr9aFMJRbdbKM4Gfayfamxg/1TsvBDFqdjV/G6RKWA5GNx3Of+f4
O9l/LuX6ytDlfNY8oMlHjbRY/7CVK9j4XIxhmSMIPnre3+d/IV8F7KvczxPyAn04T4WZH9vAoK/Q
D1GKHiHnmFRc4uV6s/2288iWXgwHrh4aGhUY0vpG/9uzOeij/uxF+nn1AA5iz2zuiY2Zv4CcgqWU
avaNeZhUPsFGXjj30DVwjyBwF8gk1jLfJFkKF5hfk66haXXFC6Cuiv88Y/Xw6+ji//MrjtyFJHkm
sZ+nca4S8HMe4a34LqFLilCS4vp5+wjh7E0Sstgk8hMw4c3dDTo91XMwnnrtTWyApoURAqCuhX3F
gyyraq2mdSO0T49VzSIeyqVql90JA/uTq3ObKZAUhmnk3BC3XrCs7hyiIgChU3BlpGeeydsldedF
cMJ7+n3tWTjmcvoOQhai5QJCATgi3zORhqPo+On8zKhKnWWRH4GTkzyhKPYjUIN+d+XZ/cvULGup
UQTq2z49tqlvx7e/QO6dDUtMtSGC4cHuY/TL+UhiJkkI0y4zbeLCAraSnd95oBC4CQ17j7gRymQH
3jZo+zWkVKIX5YWaMWJc0Rb0Rghp+5YXKUKXu0JkNBMeq7Lh4LhnuJTlGkRYwAEireiAZlesWypE
daYXzVYWgtRvvjKXcnDBWjwCdoW6eGaBrDl4H8LUed6ZNgVcH3crU0+4dXS7Ex6c8tsIfdxvEfBG
zmumfeHwy2UH3FLfEFC72U8wy/VUXSh1/eyhVyjlm1K9BjSNwWj8CykaIAATSzk0VBzQczxiKKae
MNTodhIe5Z0ZjxlqhD5uKANRYFtDpa2hBPVm7y8Bj9hCZK1Ivn/CyDIALxCWub5gg6WtwQAXmU9M
F2r+JdNZMl2KeBgwHtJUCWdTACZ6kxzClRce+tyAkYiQKSCkxZKkOXCATeA1HXUAU084YHS7E966
55gDRuijDohzKB5aeMlaeBEYJ3RArMaUfQd2MG7pzWx6oeYbtXiAxM50ufhMo2pkropFg0XXhhAF
AIaAJNaOTCCR6G80xfTHEiGkgEbcslDzUTmxWbPcXbkotyiRp63Y5TMtyONIO0WOCwKLtdSTZw29
Z1hZydl8arFijfyhH+ENHnMikE548PhGlmk75x5z3wh93H1JDhq1/muBJoh7/kvolcj0lODYCvRb
Th4Dj3MkaYWL6op439xd3+xz3yA3Epj/Qv3gwXqmdwD8aEK0ODkfP5ZFUyh6HzJ6gMBRUx6X203F
X+gm25aPIo3jItfPxLIgj3LQxNqJL2RVBBRygLib1sjdocRSTJ428ut2i84QEAlAANMUD27bnp7N
5tgVMGYChXaMosRVQ1FXDjnEv3T3/OKBr3O4EYVviTiDB3EwFzUWwIabE7g+VtoWMIYGngjJ7agQ
jDLN21TJI/MXVFp9euxtZjIWep/wYcedok850GR/ijcmATLnA3quw/ceHcHcqjy973KYa3Gad4XR
QboJdTzjxreLcCGFEb5Ow62HxPF0AyaYjqbb9G+ScJJanEttvl2r11POHv6VmP9xqnguu/76fnpH
tXIoAqAk6AVanLSBFiZd95OICmsPXy6yPBbYPG3ou+ewCEHxo57WgOlWyPDu0cgba+wAMgjUnHAT
q7/lR0+1f39AA3XybpcvXQcpg9s4q0JgGWy0rkeeQdQAWy0K4vmIL2gT899tsAYB9XTFlXSq+SVK
ISvRxSsgYb7kkCz7f/87E54m44dcsVP2HxQpGIb45N8eR7sgd+ayhq//c7mr7qnerzx8daEkqxC3
UkICrPsV17wZoTFY46hFUdyiPUL8cE1J496rBGK570N7zBt/ZMj+tzw0c564HUJnFJ1ojIR6AjpH
tzvhbeNjDIHfwfajDKMQGpm8KziDtuC3YdcZxQiEWLXN8M6prKnr6ezq3c1bfJjI/chx8+buYmCQ
yOZj1kDSuClGNrLMrKvLsDSww63H6eNWCNLOCkkbq9r43vyfZ6/m80hB8N8DOY1BK4pq5AIIZ3rG
dAPiMisMWHlEXeURsUXpdU7p6TXyW3J38+QZxKItvjqJkBQPG15zDwaUUyFVFLTvM4JEBFIs1Sy8
uOZFKGE8KkecCKphDNcwRvME2gIo31HwzgvktBB0lGNUuSdSigjj5qJov/hIh3qXp/f2qjHa/eBu
tHeVTxtmF+oJoZOEugqogYRXjPLrvqXWxwHUtHWEqxaLmuTX7k4RFYMFtT8piqLyLafyDe6RUflm
LBVsqVTKqfRSuPoEYGw1V11YxQepPQDbo48e/HHXVy42u+Wgw+uC44XWynHyKjP+wn1buV6U6rnX
BFbcJq69CYYCC1CF2iOuuAksHtV+s8hyHqn9K5rNji88/9Mwy+x3ZtmRsgtfyNyVFwuq3iJIlLyX
RFJ1XXC50janRk8wD0OgI6KxoFv67ixMxSCXLTVXMmBbOgs7gBSXaVXxUIoCewWSMPIa4BOzbje8
4DYaSqZNXz/spiw57sj5J4OqZ/PwO21ubRufmTN5Iq2hZZNje/qZpuoSwzAGW5MZb9a82ghz1yrG
ekL1RAzSaMeth91VP7SlG8woG91vIWsrFuihe87Vr73ZrsIENfoezARlICmy4AxmXfZFuBP77OXj
EhtT6q14cKo06KH2Ntuy3P2L9gmzyFqLOrznC9/z4GBWuiClH1nnZxG8Kxdl1b/UUsmt1ocV2wfd
KrRkAdvHCm68Z231uyz6W2Mr+s7YElkYZfJoXj1AcEkmh5TJOFVXF+oGixHQc80rjTC6SyJgY0gZ
SuUJQuetNwl6DxYkc85vDUmu60K+ViwJXzAMphs+oWqUk1swifkgMlT5CwZtBP7CFSE/QmzwMryJ
EyrnWx1fEukuNdhXfuV9slwDnkCT5aZrPk1kFHUtx/ODRWV/LOY6dGjvGew5NP5esGhf1CDuwCIj
sIgdWMQEFlhYXjjfMNdmw4SqPKd3x1A4Ql3QoIVoS4MPUSuvi3Crqd2zCPZAZ3m39N35P5cAT/i1
zDUfQq8lSDvHpE+4Fts7pZfWseRQzGmNjx6xfvNs0HtyVnusbiNy7CAxl2p4315ZhEIrD2+0p8VQ
p2p9zxfe4IMdQ0GHZsi5KAix7CN2hL2jPZ5pOwAjHUCFJUwqJUyKaAIiE4pynA9AJSJICfiWqEeN
xVhKoBKiSUnGbwWS5DvijsqBOHLXyVokKREGQo1Bh4n/WUF3g2XABHubrjiYJAT/0J2gxZEmG3cI
ucBZy3y9JH9SNWQSTkCarxCckPWOhckMWyXDsETL0ELS2AOkUAApbwEJv1Zy4Dn6EAy93shByn2I
og8DTYv2xml3m4oHt3WtnPo1YlBGkYUMsvmz04cYkeCzGnKWzJRMv1JUD0R2J+/biXidloRXtC76
Vnt6jGjvLCHr7g4uRTsDHY36OGxj7oNeVh4iQQZZ08DXM1eDO8/oT+XSH3a3kDBj3S2QTnS3xzey
zKTXvYb7RJv2WtuDreNU1Eiop5Q6drKjjgh/gfzqqo7V1QySEv//U3XZ6zAMwkB45yk8d4gMdcCZ
u0XqlLHqVnWo2rmv3wPz1wnl8mHOMRA4Ls7TjtX6Aoi1/yXPdKXbnenhvKIY4mllHP0ifdyZw8Jq
ggi93QEJhS2Mz0NkBudemZhBYGNXCM9Th2RD4XNkr2mJbAJb5CxpYdYCmJcO9Ndog0XtTEK61UrQ
9mxuNyNizOaA4AurDKQDCf9waWGrN8H9JM6dTPgzK5inYfbbmEEg5Wr4B6XiCNkKZW5kc3RyZWFt
DWVuZG9iag0yMDAgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDQ3NSAwIFIgDS9SZXNv
dXJjZXMgMjAxIDAgUiANL0NvbnRlbnRzIDIwMiAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzky
IF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTIwMSAw
IG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgNDg2IDAgUiAv
VFQ0IDQ5MSAwIFIgL1RUOCAzNDUgMCBSIC9UVDEwIDM0NiAwIFIgL1RUMTIgMzQ3IDAgUiA+PiAN
L0V4dEdTdGF0ZSA8PCAvR1MxIDQ5NSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgNDg3IDAg
UiA+PiANPj4gDWVuZG9iag0yMDIgMCBvYmoNPDwgL0xlbmd0aCAyOTQzIC9GaWx0ZXIgL0ZsYXRl
RGVjb2RlID4+IA1zdHJlYW0NCkiJ1Ffbbts4Gr73U/CSWtSqSFGn3DWxMc1sm2RrZWeByVyoNuN4
2tiBJU/a19i32Lfc/0DK8kFuiwKDtkEtkv+B5H/8eF4OXpal0kKJ8n6gVBgZEcEfj4oIfqNUZCYJ
c1E+Dl5e1ImY1sQSiXo6ePnLRIl5PRgCZxQnopwOcJTHonwe/C4vVsv7YJiHsVytg2EWGvnInyoo
Qi2XUytKWwe40jCfmDxZok2DYRwmcuHkF9PKcSxWSxGoKCykVx0MVZjJdRCDGjG5KG+iTDiWg6+f
7s+/8fuN7P+27vpC0eVCPnlEkzuJtES+enJX0MkLZwzNHFF0FwR/lL+SryL2VREWKXmBBt5TcR4m
OlLoK/SDydAj5ByVOZcEhVw9fV4HZMsggQ3nDw19BRhSh0r+L9AFnEe8DozczB/AQeyZ1T2xMfMz
6KlYixWTz8zDJPsIgrzwIkDXwD2iyF8gd7GWhyrNM7hAOaKzxqo9K14Azyr4X6C03B8dXfw7R0ni
L+SSZ5iGqTKJSMHPhcFb8V1ynxRxzrcabZ4+QjgHIJBj2Cdgcisury6DITq7DDDuvS8eYT+IIAtT
A+x17eTm/IF1jQZeLMXkAXgw2jZO52zFPM+wHoepXIIvlBS1XToGUbvB3ln2PDWEYpAkRgvYKo4z
4x2WtP7SfLGSDpDJMWxk5CRQRbskrgID4XBLv28DDcc5H7+D4Ia4OoOgAQ4TBspIHWraflwOlFiI
QW5CA+GQFinFe2hyMaTftR3cf5ma5y3VGDi+7tITnYW6X/wL5M7esMRUHWPZPJA+Rj8ve1I4TWOY
bnMYllwAacN2fmfvOe+w8MVybcnBBhwMISin9kxMMJQSyHUTsg/Qrze8SBE8Q1cbqJlQZDNZsb5m
yEXBNs5r90zm5RqUaagYTJrTXs26WrImzwOVLJfT5qm7GvEk40+IIQtV5BNr8IF+8bFy19gQobYi
3xFo48IbPoM86Xc6U084vVfcK49OebWH3u9VA7zG+1QZ71OVbnMHc+MSckK1szcwy+VYnInRhrok
VY7GirdQlBOJ/yuyXwoOQbrdN1ISUUvvMRJTTxipV5yUm2JrwmNG6qH3G0lBpmk00h6eSBO20uT2
PMBypMlCWC0v/eDNGGMPihra6olDHYzFIVTxp8FIoqJJ7e6So/UqGGJku5nXJ6DyJpxkyEyFV2Gb
nnvxhavJSyhnkFZYf3HTTTPjAZRfrcAzz0G25XLRXjslS2Z1B4OCvH/SPXfqFPp7rzuZesKdveJe
eevsY+7sofe6MykgnX3I68w7M3Lg8IYh0W2g5bsg89PryfhMlCsxfYDakUk7/UBf0bi5qKYNQkAA
I1CIwA0EC1PpyTUaMJOfaVpDKUFUElNqYOTE0FELFFstWe/aTu0TauRpq3a2oQXXqknS6cFWjVES
Y4yAhxNQHWFv5p15z2ruzrPg4zn1E74kHxYiZUW1GdGUMi2PPynPG4qBSECtV0matsBCazIo25IC
x0BgYemmE+0FDhi9L2qAdCJkjguyTr2Npthgqu+JHqf3x0uSI68PmDb7o6QTMCkEC4KV8RAdxYUg
hu8YL64AdcDh2kVxQbzXV6PLXe5L5EYC85+JVwGsOx8W5EOFCYxQbLqoXHwkkt2ZOwZh+dtU7z/u
EB6IGcMilTPx3jZMfOZNrHXK2NGJ5OnsabXgEQaabmuFO5qoHJs4D/1x19B/57yXcHu4rcWsaiqA
hRQH5T8YgHYCZrwE/M47FrRf1t0Pe4+oN0CCNCxcjsUSx1UjKB8kJQqEp11TDi3+AuKCFMGRilbb
hDDI69uS5pkcXf92tQW3WlGVQ8/VNfX9CoXtC59khG5bPtyX2RwzrZAEg9sFrwv+sEDnhs1K2CMX
B4O+CZSiIoFqmu6FbdeEZvtIUWrbubHMawypAiCPwrNOAixJYCEFeIY+TYDNgjKe8p3LP5Fwu4zB
FX7guoT516JiIQwUyBTPjqcPuPN0NItzwas19Bu41Cenm6d2Gu6VhAQeKv2g2VH7C0O/uFfeol6T
IOeB9DF6f20AqzI0OF4bxv9x1cHVAU78tjiMxNsxpzr/uvz5ZSx47qT+dTu+IoAbOwUAvXYyKN6+
UeNtIgE7+0TyBByym02pf7V+xQNzO/xavi+M/Anp9+CY59+ijGwRQ4WLwQORfwjquPVGxkbZSty+
4TJxQ6JDL9tpZqShaDW4rLqTY8xhroWQ6FBgeY71jdJdzu6CrlW/2h7fPjpc/KbjnVTOJsUMiIuO
SfPWINqZdE8Wf7hAFtRoCrmmMplK6kTcVHIo19ZZ3m0BuDKOlO63/N9gz+8YTV7fYkL5u+fUTw4R
0o9+jTs5aap1w17UBGVSKk3QwDcUQh4basKG8FnSsmjIvYZgbEqBtr4LdmqUadu8pCZa/om22XU7
ZeyPbaSR6+XTaj1DNMB15BATEHbowQQHcfEThvzEY6dOrB8BdD/wHe7wfQf9xrKDKPC9HwE1xXLI
vmWoiJhr02IzlwWKsyAmMNcKLxil7YTCXjZExjlbGdebRivE+PgiSyGN/gtZhYCvtjyfMRFPjuD1
Ne0Ej9SSjhGjCxhnXA1fIdLLACgY+P2njzXIM4UwYfQzeWh3xMNPaGmHox14PCgjP1kqnegeHVwM
wdQ+Ww9xMVNP4OJeca8cQpKpqkiOih9l6EXGsSL47JAxIrBpi8r8+yRBgItIYYLXz9yaGI0nF+8u
b/BxYXANOS6vr872LAKALUx6XwqO2m+RfnGvPPIvAUW2O5A+Ru+3RxR37JFum6EKsRW+LEsjIFjv
gZwlHnIhFyQ903OmoyNyvcVkRm/ffrr79kvkOhjiW+szPtxifM5hIcPKhe8yntkASWuKO3rixXJB
BHrEaWxbBXA7Zif0wDQrqhqfcbnXOWXRirkW3e2cOvHe0qNS8VMzkdbyBp5u3cA9JttzsMrO6wWF
RbUjPINXw3t/WT7YrvYZn8UrpsncbQw1NQaVt/TrDTii2TX9QoHFt9kVTQRZymnnrfi3InvOrT/p
PVbjwntiRQ+/Aux8FAIwRhr6BoGutPgmMmQOHqEhFLyPQvGKdEOXsGuBnSyDgmgXaN1C/kW8bsKC
c/qFhyX2i4cNAznMumdOPuby535EsyhqXolEL8uKFdgXaFq8OoFDdzxMUmhPBOxQQUwWwpA6omHH
Noptw4GC53ByouHDPziZHkNwB0BPRpnet2cny/R3ZtlhAbt4gCaENiefxvIDTTsRquUZ3N20VqGo
UQUGvROp68qN5qwLQxKuvqgFNXzMRdRQI9jkBcfiZqJakqCfOlCWeDwQy6uOQ/3WIA/+GGLEVG5j
sXD+rANDpWINmkmnY3yEAIOAahrbbs2i1aKNBJx+rT/i7/AHJUiivENy5R0Cl8sk+qOAC38Q566b
ngVDg37AVhLBXFN2KzmcQBowbeaWIAh1TI+blN42vNpKLpgbbBmzuzKMXsobNAMitRoNDK5268RT
u12qjoBbIrrfXRDDfYC51KX7PWrr7rb0Eu5A/qBzLGPgnhzqGH38wUc8vebPbxR1CmoZTXnbeYBZ
SEN/l2W433JB7ETLZeqJltsr7pW3LTXJ9sk6AQTcJ9tLxHMx8fSxjm3s6ceVn6a+vKgTcTEhHBCJ
ycVAiV8hkv8ERsiLZ6Ei8Vb8/kckZgNVwDFBkckA0hvxOIgjHLQLHweTwf+rLHckhkEYiPY5SgoG
kFDEhVI592+zaM3H7c7TrgQ2o7Fy5ZBwL0CKI/xEFmCObq7X970ZlWSjqHaexy0M3yHZYKQn8zN7
MovQOBg6z47xYPujYwqPjosnPzueyAYKXRXPSLh2fMqGEjUISiHTFTCLUIxtBwzWqqqr6NoE8nDd
dFaL9lqJley3BKk9fSya4USiymzBDzCyb+GcSNSZPUdazCbyypZWaYSEFs5TaCUJnf/mT+TWCmVu
ZHN0cmVhbQ1lbmRvYmoNMjAzIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA0NzUgMCBS
IA0vUmVzb3VyY2VzIDIwNCAwIFIgDS9Db250ZW50cyAyMDUgMCBSIA0vTWVkaWFCb3ggWyAwIDAg
NjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9i
ag0yMDQgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDQ4
NiAwIFIgL1RUNCA0OTEgMCBSIC9UVDggMzQ1IDAgUiAvVFQxMCAzNDYgMCBSIC9UVDEyIDM0NyAw
IFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA0OTUgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1
IDQ4NyAwIFIgPj4gDT4+IA1lbmRvYmoNMjA1IDAgb2JqDTw8IC9MZW5ndGggMzA0MSAvRmlsdGVy
IC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIidRXW3PbuBV+16/AI9iJGJIAb36zZc3W642dWkzb
mWSnQ1O0rbUseiU62fyk/sueGyhaFpWk227TZMYicC44+M4VJ8XodVGEkQpVcTMKQz+wKoD//JUH
8DdIVGpjP1PFw+j1ZBOrakMsgdpUo9c/zEJ1uxmNgTMwsSqqEX5lRhWfRu/1pFndeOPMN7pZe+PU
t/qBf0ov9yO9qmpV1BsPd1rmU7PHmmiVNzZ+rBciv6hK4Vg0K+WFgZ9rp9obh36q154BNWo2Kd4G
qRKWF79uubv+xt9vZP9rLddXIV3OZ8sDWnzQSIv18aNcIYpfCRgRcwTBB8/7ufiRfBWwr3I/T8gL
9OE8ZTI/joIQfYV+sCl6hJwTpuISL9fN4+e1R1h6MRx4e9fSrwIgIz/U//SiHOxRf/asfrq9Awex
Z5obYmPmT6CnZC21mn1mHibVDyDIG688dA3cIwjcBTKJtcwPkyyFCxSnZKsJO1vxAmir4n9eGOnd
r72bf+RXnLgLSfKM4eoRoJyAn3PrbhV0ORHFfKnTp8clRLMH/DFGvfEzQPDs4gyjINeFZ2FjfDw5
98b4pRYrNWmYW37uvQhQXgDsNXgMs2TVqk27o3IHb3RtCvEwjnxjUrKPsbbOQGPZwAKUJhAGUzBA
zzw4IOn21MW7NycYnEK+UkfKeuME7PHB4Yk2dOy0GIVqoUaZ9S04M8kTilbfZmpMf9f16ObL1Czr
qNaC3VGfHkepHw2Lf4HcOxu2mBoZLHovpPfRT4qBBEwSA8ttBkaJgzcQeK88MAjcE0Bi3GB9MLJY
ozdDQHJFSFb1kZpxZZiQSEHODvVb3qRInK9L0dGO+XdRU51E3VQWZXsDKiLIdyLd0gHtulx1VAid
TFfto2wEqd/+xlwQ6xMkh3oJ5cno8ol1sdHK+uAY53SHagpBOexRph7w6KC4Ux4cctkAfdhlFnit
c1jYJWwYb/MBbqnPqBa71U+wyvUU4l+dPnnoEErrtlZvoGAiXPwXsjLAGkss9S5QcUAddwAoph4A
alCclNt8C+M+oAbow0BBCcijDqisAypioGbvTjBQXKTmhFjcrX7C0IqwboRY144Yt6zDDUqgYx2T
4LFH8Y7RH+pz6CRQfyCCkbQiSdewmKNp7ml3UbP4jJtojcVRGlcE23DUrheiBLrmoBeYesALg+JO
eeejfV4YoA96Ic5hSOjKS+eEQJxA1cHodx4CcwWAhG7rcjY9UkWjqjtIbGgQ1T39qlbWqqxaHK4a
qihQYKiQxNqRqUgk+jMtsQYgooaiGutWBLMdjQ3NivWu66p+RI287NTOn2hDuiBJih4XAhGFAHFD
DFjyMDTDHIIAb+Xc/uBFIRjkjmeT+K9TfMu2eziF+btuD8ygz4F0wOH7BVlntI2Ffd4eoA97O8nB
os7dpnN32nN3Rk0l0VMETfLNcqIZSAMrZYuGywlxXl6cnvV5YfiIYJN5j9Qxd/0NdnYuZDkOHwYK
frUoxaeGs1HIireEq1U1b7fl9VK4SNcdT4we1sS5usZmlcMsGcUgVLMnUy3aa/6dPzaLlYyXpnO+
mKjKZzJzdeI769fQ32jztnemogPFCjUv2xIGLAqMQAFcobVJN5DG24FUWgFYhCHOFuU0bCFgPZto
ZNs8ERESLZc8Qh/xqmy3UR5hlGOYHkNcZxDkyHZO39sYp6JZexjpmw3lc3lLmmqEP6VcxF3FP4hh
QBWyZ1/bqCHTTxROEJSE9ZpydvGR6KJ8xYcpNu4Syy+UkvOzaS8LI4K3b6EYIYbuZl6c5tup6kXy
CXU4/4bFRbmQjMX+tiv6kjicfMAES5d83WTgwmH6d0q/hFON+1AmOQWN7lS9mWJGWc1/KS4z/cNU
8Vqk/vJuekF4GVEAQ0UvIuNkG5FmG5FGTEBnco54VvMCPPs8JBP3aPqK983282v5Br8GbTv5955c
BIqBKmLAFd27MeoeMOAxeTZ2su9o6MigTKLs2Anv4vry6fmBstHqZYMNJaXwhnH7g/eVMP6Xvg6Z
9e1eYkCtn+bYkzpAww7QXADdlaVItlT5U/lLhT+n9lAL2KJ4F2zS7jz1vwRz/xdVZ7xA8Sey10Zo
8HuN+/+Ai8f0IMPB6NxlKRQqGoJPB2ay7/Cak0us4TDRxQZnI4kFvgukCN6F8iHp3q+5y64zKla5
vuCxEnsZdYDxMW9Mzgeq18ss+w6BOV1wZlXlek7BwAWkwGdczFNpxlXV9m76PAIwb6oulz6NtMA9
PgaJ4peX0ESdwHeMDFaeiPM8pFk/kb9PvIXDVg5jA85eMtmHWmbFvGtIT7R67GcYzrJdSTg9xvOw
h+Lw3w9K83+FlppRkESaYTvfHYEszR9DIxBTD4xAg+JOeeAGpDCP94rvZRgchYzJ3Rwk7pLnCMLP
3oJqgg+3GV47lT11Op1Nrs7e4thocQ85zi4vjnbgMDY7MBEKdRiOYXFR7q4a4utrV/QlcRiGKHUw
JF3Q6tDHrH5dFFZBQN4AOY1zaajIBcHP9IzpISjLeh3X2q4yhpYhpUYD7yjoraH8rRFEzDlKrEcc
HhMhKf5peK83meMcWrLcPZYuC1oiHOdlc8Wbqtx4+I7InIpqQQpL1suLZqXgpYCK1/CU4tPwrSfH
qPqZSpr6YioLtBZDT3ZMrQ+zCww+jDnbmXYGBdrIRZy4qDu78NAkel+F2JM8NwWjGqi+SO29rULC
FRVt8PbwsmKQ4FHkQEfien9HC7vm6Nwm7yd8Eyw8bIrwfMIFFM8xzJ76cuflxB7BJUxTm1K+WKbG
lmM0P57g5CxIXwxTg7PGFT8Gq2Y9h4IL78n2jn7r3uEhHYKtfAODAL7eAFiLIDzj5F1m/PWJaauq
VvwpoosVS6lSMT88H3FGul3RdrnE8KBn5gO9CVl4Cf6IIcqatd9vCL3Uin5nakVdsXIvJqjHGrGA
4bmSKLmnZf/JpI88HHB5GIQw58aPTzgq6FDOo14Y5YKPoJESZIaBhGMURQXikeiPvEXMc7VYPTsZ
NTcNW7Oo5cgZTlWgf9UqVtuSaTBmK9HJ22q+4A+cXOr5wbDpAWx+L8BdDgTWAZxApCDEiYPYEsSQ
BieIT0joGkqKWEaCRK/X9Yo+WibiZSJZdJdlaAF7ZqVhBIqF3B3ZiUk0YlFI9XU9VyXzdx9Y8ODs
TNSJHny88LwCHJVjva5VheUKB3/KGovFF/mXdQu6r2s59RO+inJdyz168YTbqhQonCmCxdc6yv6h
jmKa+OlvaCmEHERt5wC5s0j3c8FQeKf6GcKUC8jIS+b4VVBldwlsUFkcUnJUed18ZI6XWFm7D6v4
P47VFeHBZj/WZcv1FC+0tU61dT9oVfX8HizskJJgES3PQqOrOsBGRcBgDAEzO+WcvnfyQRpPJiU9
dcUFtDXtXb3eTScRW4qW+57kthrhaUuSaOQK81dqKprK66Uk3R1s72+QL9vT7I4rf0uVf855ZRAN
K08I6CEz1ytWPV6JCrc5V1+lyvVBp5EwggbmqzPhKJfcqZbbFlmVruexEK+cW3CEJbfE/A5EpMaW
HIOwKemIrKyRRodlQi2kG1K5iWBYkCrdm4NNcmgOZuqBOXhQXJS7UTcw+HzoEyMDk4cdEh2mol1C
PWjXnpMddUD5F8ivJ5tYTWY0owdqNhmF6kfI5l+AEWrDJxUG6o16/3Og5qMwg3kKnz1BjIc/jEwA
k6rlDVC9HM2IJ6OtHJ8BD7CBM38ntOxxhHjC8l9lV7sSwyAM2/sVmTsFbCD8UKf8/1wJG2LaKXc6
WZYfycWvzxtCGYdUOrRj8WuIInCasoDPOEV8Dsk95n4IvZjq9Ku1734J/PjVJrtfD3r8ai3/frXx
rAlRSvLuF5lCaosIbguernpl/gMfJVVT1SLWXwOGKjiZEP55+2hDw2pFzmLww+d+NTUTUtQwlB0Q
ZBer0guATLJeeYkGbBXh3d0mMCmLkE/PizWlF+WsR96KvNcCqEqIBUhH60hpJcbci6DYoDona26l
65ysuXUguhUcnXH4i/IQcPXuGyPV+7SCDIgbI1iQFjdmcR5G4oyG8hfFfj4WCmVuZHN0cmVhbQ1l
bmRvYmoNMjA2IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA0NzYgMCBSIA0vUmVzb3Vy
Y2VzIDIwNyAwIFIgDS9Db250ZW50cyAyMDggMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBd
IA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0yMDcgMCBv
YmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDQ4NiAwIFIgL1RU
NCA0OTEgMCBSIC9UVDggMzQ1IDAgUiAvVFQxMCAzNDYgMCBSIC9UVDEyIDM0NyAwIFIgPj4gDS9F
eHRHU3RhdGUgPDwgL0dTMSA0OTUgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDQ4NyAwIFIg
Pj4gDT4+IA1lbmRvYmoNMjA4IDAgb2JqDTw8IC9MZW5ndGggMzMzMSAvRmlsdGVyIC9GbGF0ZURl
Y29kZSA+PiANc3RyZWFtDQpIidRX23LbyBF951fM40zKgHEZ3PQmUayNIq/lmFQ2VevUFgxCFGOa
5BKQHX9S/jJ9GxAiCVlbqqQcuUxgpnsaPX053X0xG72ezcJIhWp2NwpDP7AqgH/8VgTwG6Qqs4mf
q9nn0etxk6iqIZZANdXo9U/TUC2akQecQZyoWTXCtzxWs6+jX/V4s74zXu7HerMzXuZb/ZkfpSn8
SK+rWs3qxuBOy3xquq2JVhkv9hO9lPPLqhSO5WatTBj4hXaijRf6md6ZGMSo6Xj2LsiUsBw93fJw
/Qeff5D9b7VcX4V0OZ81D2jxQSMt0edbuUKUvBJjRMwRBB+M+cfsL+SrgH1V+EVKXqAX56k495Mo
CNFX6AeboUfIOWEmLjGF3my/7QzZ0iTwwcV9S08Fhoz8UP/bRAXoo/5srH5Y3IOD2DObO2Jj5q8g
p2QptZp+Yx4m1Z/hIG+8MugauEcQuAvkEmu5H6Z5BheYXZKucdjpihdAXRX/mTDSh28nN/+Xb0nm
LiTJ46V+WES5SsHPhe1utfdAIB64fAArpXpLvytjwWJL+q3AWLku21qNb26uryAtYj0xufYMnE/1
+fhaMeOajqoa/BUAT0OcbfnxSGJjPAv2vydCTeLnfFbOsGT45IF3PACAIksK5UV+HGd0Hb6EdTke
W77ODLSAq4OmntVTE8Yg0O2pt7c/X2AsC/m9OlPWgKUspEAOjJa+O5mNQrVUoxx0Bt+nRUrB7dtc
efS7q0d336fmeUe1FvSO+vQkyvxo+Ph3yL1vwxZToxgx8uj0KfrFbCBf0zSGZS9h90kQShK8B0NB
TpkIgODOhOhDXuzA/yAMogGiINRVfQY+zxEB6QT6IAQTvwN7awrb+a4UAS1xerxY0oJltghF+B1Q
IXIMGCsZsBFpwV9jCTvmK9cdJ8RbrCumbmU3yHze+Ff/LCYRa7qidcm3eUA0L+SbrJRS1o/8xIWK
80UG9WE4Dpj6RBwMHnfCg6ccPUAfdrQFXuvcHHaVEt9cFsEt9RUBvlu9MWiSCWSNAtTAIrFdYSWs
HVR/NhEiQI1+oHRPyXYJkMoFHagPzZYEVOQHzMbUJ8w2eJyE22Jv1FNmG6APmw1gpIic2YLYmS0S
LJ3eXnBhRYth7bkCvHTvbyC6MgSeGMvXGZowhbet8RLYF0MS1E7khAenz8csEcB2TfyEszGcaKA8
F4SzIqBhaLsnNuSCdJszUTWtQ9We7aMUyvOg7Zn6hO0HjzvhnWdO2X6APmj7pIBuxJkeCpuYPojY
9O/QTLG+NRiH7yHWQrd1M52cqdlGVffgAECW6hM9VStrVVYtdnHQTwAeQKNBnV2iHblBE6b6Gy0b
k1LPEVMsI6RFEPXUn2zWLHdXV/UWJfKyEzt/oA1KGTkpcgB4UN8b0v0Gy6i+pvericeHzw0kYAjd
EgBaAURk2SddQcoElGspJV5KTS1/ZMH3ILp/GAIQw0P+B9ITzj99kGVG+7g45fkB+rDn0wI06lzf
ZZ3rYMjPOTg9BTeRxSjnsHnFTIIQmBorMEYd7Zg4b95eXvV5r4wXwSbznqlz7h0IxEICsQJ7e8y8
almKfyEdoRAVQla8JVytqnkbUnQlXCTrnttUgxg5Vx/rFmlfTYSJWnNQZVqk1/ycbzfLtfS0ced5
UVGVj87M1YXvtN/tSt5c9L6p6IOihZqXbYnYgoERKDBXaG3q+sUo64wtMxQplHUKZRTDtq+S1Zwy
mX4gBsq7TNIq1bwqW4E6CnBL3WQvnq0kV0yx7H5L2VuQCLwM5NeSaarpYA9ZHunWbtSQ2heqvGMN
2nqnSlGcZW0YqvfezsjbOUUFQzE/xcF7wn1PQfEwEr+iceq6b+sk7Wx9YjqqqZlitWmWkfXjAQls
jkHgeNV3Tl0cgkCSFfs28QgHhDoMBcPHRbiQbIJJfXj0mDiMAwAW1u6706hrWwJpWyZ/JyxIOe8R
L1M/lwSP9ORS/TyZ0iTCv5Qkuf5pongtp/56O3krswwLgI6HTDb7E48a8X6IkqyYrCFoOU0N2rug
TH2cFpipvb+n57r963P5nnzr9KPHoZIXz9PJvZEtYkCyGDwQdFBx5I2js7dvMBALAGyU4DkRB3kQ
74eOQIaODxorJLTmG8yvjGZHGCA+mGda87/89rR6z3UWm9X6WYHVsTNrN+FCBrBZB6VQPBN60X/C
r5TwqxaLi/RDi9MnnNN+BIueeLt6e8UwNjtdqmyEt/gV+Wa/gSUSaIpwoEugXZIDgGAhJu/lQA/5
I97dDQRJEmPqSJgIEgW257ne6BDD6ODhdHBuqDEYcyd8PVDki84Q4Q9rCMywiEOaW4RUfh94C+tz
oZeGIp4bhVBL3Qaz3W5PB8ELLNhLoOM26Qe0oFKXy6Yqd3OZQB/3X9iawCUHsyXIeoa6PEehNNjC
yf/foFJqSpU50hxe14edURzvh9TjzoipT3RGg8dZOMxBqVDDIjlxfIBhsEOK4aTtJqWgi8pIopI9
BhEeQWRP8eaZ7KnLyXT8/graJ2y+Z8xxdfP27MAicZz5wWCvKNRhiwwfZ+Ewl7n7hjgkHhw+SR62
Rpj0rJF28atD38z+OXo9m1kFsXkH5CwppOQiF5RYpudMD0Fe3q/JaRfblg1LlRcmvZbnD0vYFOst
phqMFjiBdNNNhPRS+D4ZHAxwUsjcHGcJy7Cjx24i0vy7YVEyjCgaWmK9w441QyLVOxGu6keC3NCT
0tBzMD4W+/HoBCdMktgaJ6KhcLEqfQCJnTCEEBB9Tf1zpPszXSxCaMbK5Vruygu2g0xjMU5jx1Db
tdxV14fTlNTAAGY8HLxWMA16OHvdG5zjljTvrpm2oC0ysqUJkZdNs2E6mxaoOZ0hqoitMR8i3cIA
F9KIafebwtnSRVL5sOP5DJe02u/X7GNgfE/YU1eb3Vy191Sv6kfhQh0l2y0huyW6XDzm411k+/2B
KVICuf5VtXpgluWaT6pSyQYaDBzAjOVKuZOuvOL2iupq2W52fBdwSh5kR41kL8eiF+ZY2OVYKDk2
BssWYF+c7+qK7o35g8teRCNunZmoF+Z8jmP1nBfXe/Pm7EkS1jSlvC34K8bDWASYqerll/7WXEGe
0JcnDYZIriEEKfjw/f4xK4RnW6tlo+Zcf+u5+/xX1nfZ8gkMPnTJA61a5bS5o+zh37pqEaMzciRp
UDH7bueuwZq1p1uVsN/wAMJgQCX4ZSujArZMWRe0fUf3qjs5R8cvxdEulbFUsY9TyiHySkWBmBFG
IhZh/FtwLrz/gu8ZoAfmd0M+5dSJ+6lTEOIgA7glFD7KHGTjJXP8TgCaU7QDbU0PSJpSVJBPlB83
X5jjuWlgX2AigrskcjbKZUoZ39fYjIYa7VMAcnxS4zP0X9ILeY8C6wEul2ORKIAoDzm8buVIyWuw
UYg5jmgY4vha8f6S2YRLDsmmY10r2UAhvXRcOwb3rbmsHXvrAl50+yh00dGxP9fYyQvjMeigOXLQ
XG+5oNVliwGWEuZitcHNDT++yHYLhUjR7IEDSVNDkc45q5Frp+SlNVwnUkFpoBBCuHNUb9VqSSUU
Ea5jVOOVyGCmes6rV2q8eaQRn1nWv/HyFzZnuWxfqbqtfKzcZFpAQoNlGqs4qkr4ic0wwdi18DxC
K3DeaqXEAPXAOBR2eV2wHQH5qC4K/FGTAfcpQVRVMqnmx3N9nb4Ue5JOx8SVYbw04kH6n8arpqeR
GIbe+ytyrFaiJLEzkzmiigtohUSPiMMABcF21VVhtX9//TVpUmjFrWM/28+O09jzP3bemavM72SQ
85WC6BMcZESiCedxNH2jrGoG5PVVsB/81Oa5unWXtxrxhvohW/R6XorGRd79wfyOFuVFqX0jzOP4
V35MLH11QXm2Q0tk3KzdUkhst79e1+5yt9vu9KTajNfjk9vKmEbZq4U8rtK/cX6mmgtlpPrrIzti
WVC8jXKcNwrJrHn3Ehr0X5uaZOF4XwFJjt5AVVZVQKkB0sByxg29kQ/qMwXKEE34hzW/xSLSjlwc
rjkxnVpzVHtizTlqrs5xv8dAqwt5v+N8MjyqZFKqPMXpi6iT8mvPp7Xny/fklivZu7xbLWfBXdFd
eyMg3dx/Lnj3093de/c0C5kmEnKEA9I1dL9n4Gm2xCLYzFaCySLKBAiZl7gKsFdTd9H38w9yEqnK
JOrZWW2kAvYKPqhZnxZdriNPmILIwKmJ58I35QO+Kmj4drEOPQGKOuEnvrTHYsNXBQ1fiMymijxh
CgKpEIWvOfJRTCyOj41PGA6zEUBx6GkCQqOaBzn5RLLUkQl2XkAsmKgSBkVET7fEzUHcmtGmQgRu
CfGMQJ5ZBmEB4tkEQAkObIUeRICxM0THTaeCqLFZpJjIRWBM1gpMmIIAz1exKRP0kUPtK2WCpljd
UFWqAIq6p/+16VgNk6iB5FS1efS7bhVIvWZUiBikAHDQypHb/y9w5KwKZW5kc3RyZWFtDWVuZG9i
ag0yMDkgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDQ3NiAwIFIgDS9SZXNvdXJjZXMg
MjEwIDAgUiANL0NvbnRlbnRzIDIxMSAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9D
cm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTIxMCAwIG9iag08
PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgNDg2IDAgUiAvVFQ0IDQ5
MSAwIFIgL1RUOCAzNDUgMCBSIC9UVDEwIDM0NiAwIFIgL1RUMTIgMzQ3IDAgUiA+PiANL0V4dEdT
dGF0ZSA8PCAvR1MxIDQ5NSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgNDg3IDAgUiA+PiAN
Pj4gDWVuZG9iag0yMTEgMCBvYmoNPDwgL0xlbmd0aCAyNTU1IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl
ID4+IA1zdHJlYW0NCkiJzFfbcts4En3XV+CRmBoxBAje/DaWVRPPJHY2ojdbNZkHRqJtTWxLJcrj
9SftX27fQFEXyp7K7lScigigL2h0n240TsvBm7I0VhlVXg+MCSOnIvjHoyKC3yhVmUvCXJX3gzej
JlHThlgi1UwHb36eGHXTDIbAGcWJKqcDHOWxKp8GvwWjxcO1HuZhHCxWepiFLrjnT6WL0AYP01qV
daNxZc18arKsiTbVwzhMgrnIz6eVcMwXD0qbKCwCr1oPTZgFKx2DGjUZlR+iTAnL3tdPd+d/8fsX
2f9Zy/GVocOFbHlEk88B0pLgp6UcwSY/ijMsc0TRZ61/L3+hWEUcqyIsUooCDXyk4jxMbGQwVhgH
l2FEKDgmk5DoIlgsn1eafKkT2PDmdk1fBY60oQn+o20B9qi32gWPN7cQII7M4prYmPkJ9FSspVaT
Z+ZhUn0Pgrzwo8bQwDmiyB8gF6zloUnzDA5QnpGtsWltxQOgrYr/tLHB7ujg4t85SnJ/IEkeAKHL
TaFSiHPh8FR8lkySwiQ5n2ryVg/T4Ko8u8Tvpws1AgSn4Ka7u3kzl/HDjruGJg3TPM3U0IZxnHX0
O590sWP9pUZmE4z10AUTbeIwbdfUxdX7UwSXkD+qE+VwRweYzIExoX3H5cCouRrkLnQQjLRICW1w
QDWk31U9uH6Zmuct1Tmw23bpic1C2y/+ArmzNywx1cZYtPakD9FPy54EStMYppsMgiVxrxX3fqyv
GfVYduJghV9M2wcNEQqm9Yma6CHmz0g7yH30fALu/sCLhJ+ZHmKerLDEZUHF+tZDTska6hxUjQzL
G5J5uQFlFvKVSTe013pVPbAmzwN1JA+m62V3NeJJxh+oPBZz+N+swaf86K6SYzwSoalVviVgPS68
4zOozv1BZ+qRoPeKe+XRsaj20Puj6oDX+Zia9p7CkU8Z9O85lVs/ewezIhhDiqizR40lenmH91Ct
3kNNxKDyL7guwjJKLPWuo5KILtUeRzH1iKN6xUm5KzZuPOSoHnq/o6BKFBYdxcWl9VQsnppcUfmw
UlHQZVln9g5mBZUWLDaQCm+vPOns8hNKJoEveEmn4CVS8Dp+s7Bqe/3G1CN+6xX3yluvHvJbD73X
b0kBuePxZVuvReK1D5iZUPPhNsyDj5BhuV+6nIxPVLlQ01uNvqmnX+mr1jJX1XSNHQ/cvZD5cPVQ
F5QHntxglhbBM00bjTV+DV2EpfJkYO2eIK0WD6x3VU/rJWrkaat2wuZwuGIfroTCJTXiXltDdS/C
AkFb8W8lW92wTUT3QqJ/hcUyp1YtAaqoUl8Wck5Vs0EzYWgIDZECKZOkaXvbwf2KrmWvNnOxFfoN
UP6oEXR364p0FIAonNdYRWlnROYjfxpqS+5E/FkTQMNdBEZxL/yAdAR7hwVZp93AMnaYnDuih+n9
wEty5H0JeYy58ZCj4WM8xqgY6BHAuHZRjYj38uLsfJv7nGN4ecH8J+on7C3yQCDIWFhw2z6dVxuQ
zRmyzKBqQWn15W6LcNtBz0x9qQXoT7xJLQBRHteCl+ViziNGvYedmKYqYVOnoTd3BbemIHU3mWbV
ulJzrkTlD+C9+nW7NI9ElBze1lqtFfvrLd3dcdDNsAvVJhWf6sW0mosXxQKeMW3LQi8s+beuV5T6
8z+JSRwvfvAGblu2m/WvNPB4wu843Kc/y6684+np0kl0CIOJgtlugibQavc3nkLtT9N+ca+87Rxd
gpx70ofo/ZkKvuKr9XCmjv8luSpZyWnYpuqZej/mOPGvYO/nsURPpP5xNb4QoLECaF+6bo3jzSsr
lo0f4IqICeQa29iCHnKui3KHke38HX8ibYav5dsf9Rp1+k2vNnJFDOCNIQDt09O2byhs9/nl2cpe
vUNE44WNskMv3LmZSEXRqpDH6+dgjGnCGZkGWO54jpAvAPImmH3WXa/+H1+tNHydRZ2b17n2fHEn
Hf8Ge/+Hp35xxJiAalWYtIOJvYC+Th/+lJQ5OXl0RaUv45LrqEgXcCnUgibZtoOm79C/0sXjkfBq
2NyP352ln4PJulqtt6JgsSUxAfU+KVXPXBD/SL+cDTO+qiw2HPj4e2AptZbAYR+dckQlR6SibqWG
eCoBAWqgM4j8hc8oeCIkWd4CLG8BZr/TvGrjXlDcyYMJ3wd4P8Ejrwh+3e/UqV6YzT1jvtPjIVgW
S8aKHXKVn2goh48Qa+hQGRIMCL6DAA/skJTz2XJjQ7UTm55tZBwsId/DwbujkYZ+htt2IyDn30de
4oI1pxyZcscHruHevgjU2V7a7PRo4J72QbPfozH1SI/WK+6VQ6PIVOMKZN0TP8jQ26XFabdLizIf
QSvNEmU3NluYFBM8cyZr6mw8GX08hyau4NcUcpxfXpzseCTOjnlEqP0e6Rf3yjcHNnsO6aP3+wOc
tvFH2pa6wIS6/GPwpiydAnBfAzlLCrk+kQtuQqbnTMd9c7u5X92mQBiz8a2hd8AQnxDP2lp8yqyp
YiPOEHA8q7WVRwb4CZPQEkiRhG8FfpwUVNyJXcRumVarqmk01mbROmXRirnm3Q1FHT9IMwY6lve6
5g08vZYBd6wbO1hlp5dGYVVtCcPzVH3xx2XDtrXP2BavmCY3svHkLeSmC67o17vwjGaX9PsJE7mA
awgnSnwl+nkz/q3Ipzd1uGPsHe3q/XWw2ju3CabjYDaao5TwGRyfIcXHZgohQ6MzMjoTo2MyOiOj
MzY6JaOzoPMWxbcQ2Z7SDvi/4ukNb8N74jMUJVYafbSgR1Tm5fEVmsLhb0UCnqE6AbbbroaVkm28
+RjXhAoizVmEn6T41I0yu9szd7LFfmO2SPUZ3WroQaZwHBd8hWEnUujAEzhtRojgzkd6kYx7kTy4
gOibnNIHNTRNRd8bVCrpNW+gIDRLcBB6DU+fYuRaBhr7bZ942zltu5Yooomq7YM2ew8JQGLpiFuj
X/fc1wFVx33xtxabbIPPTFypBQAZORTfl195qk5PNCUp4RLbR7R4iIByAaI39YKP/FkT+4xR5tAr
KSdpjFBD2hwBhxcrHJ4BlgPA5kQDCCMjf5h9sVzWs3D33kiKY/cGU4/cG73iXnl7LyTZHjmCqyLt
Fe6lkmVMPW7Zob1b+mH1L5DfjJpEjSZ0o0VqMhoY9QuA4w9gBKg9KROp9+q33yM1G5gCLAVNLoMI
O3U/iCMctAt3gwnwJGFES2mILCaH3bssLUOahynMr3/Y8DgoZShkC3aJLKBeXEqRJ4Zak3f39jwt
hyPXsGZvMfQf+ZbFvLBlMWZ812LPsmEwrDUuUoqnyyNsAe4HLol5a15ArcjDSw77Atg5B/VdnpYj
y0JjWbOLLW2VQP0lD/uFGNxn0RiHRRUXQB3pdSnGsl3AvXHJEo8T+8DXkevwtByFDTOJwn8HANBd
CMIKZW5kc3RyZWFtDWVuZG9iag0yMTIgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDQ3
NiAwIFIgDS9SZXNvdXJjZXMgMjEzIDAgUiANL0NvbnRlbnRzIDIxNCAwIFIgDS9NZWRpYUJveCBb
IDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiAN
ZW5kb2JqDTIxMyAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9U
VDIgNDg2IDAgUiAvVFQ0IDQ5MSAwIFIgL1RUOCAzNDUgMCBSIC9UVDEwIDM0NiAwIFIgL1RUMTIg
MzQ3IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDQ5NSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8
IC9DczUgNDg3IDAgUiA+PiANPj4gDWVuZG9iag0yMTQgMCBvYmoNPDwgL0xlbmd0aCAzMDU1IC9G
aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ1FdZc9vIEX7nr+jHQWoJYwa3qvJgSay1
sja1Eal1qqLUFkxCFGJJYEDIx0/Kv0wfMwBECbIcVxJFqiIw0wd6+utrDpeTV8ulNqBheTnR2g8i
CPBf3vIAf4ME0ij2M1jeTF4d7WJY7ZglgN1q8urnhYbNbjJFziCMYbma0FsWwvLz5K/qqL699KaZ
H6q68aapH6kbeRRe7ht1uyphWe482mmFDxbbkmkrbxr6saqsfLUqLEdV34KnAz9XTrU31X6qGi9E
NbA4Wv4apGBZHjzdcn/9nc/vZP+ttMcHzYfzxfKAFxeKaLF6vbVHMPFP1hlGOILgwvP+tvwTYxUI
VrmfJ4wCvzikwsyPTaAJK8IhSgkRBkenFhIvV/X2a+OxL70YP7i5avkJ6Ejja/VPz+RoD7zxInW3
uUKABJn6ktmE+TPqKURLCYuvwiOk8gYFZeMnj6DBcwSBO0BmYy3zdZKleIDlMdsa6s5WOgDZCvLn
aaP23x7d/G++xbk7kE0eRCwIEw0J4pxH7lRR2CNgk+IYUU7UnZcgslv+vfZiggJj3lButOhQ3n+D
gKhzZl9SOkRW9pT233sROnjOGw65G09nqvSmOTqd0iq3v8WmBPrALauFIxaq64+8JELJXwbRWUhC
0X7rBQpEB72iaXswTjHAdWhimBo/DNPu3HF3bCOnxgMga6pmGBGRWng677Zgzp895993aEmiDmdn
GPkYdAcYUcgR+Z6OVOJr/vxsOdFQwSSL/AhjJckTTgY/ymDKv005ufw2Ncs6ahSh+WZIj03qm3Hx
b5AH38YtoZqQauoD6cfoh8uR/E6SEJd9gpuu5JLHyc9niCnFQIBevKTyY+yiwbjAsk5BgEVCrcoD
jDIsPAmWBBIhNELk/lU2OdDXTWF1tFN5ViWX4YyKr8aH3d6hCo0Rw6QNf6BtituOOo0xglbt1m4E
qd9+ES5wsStWXHtkQ3EnCsVyyHzjcHeOTbE5jIMq1CdAHRV3yoOnUBuhj6MWIW/kMNMdZjrucyPC
Y59wtXert7jK1QwOAI7vPOoQ22tqgyW8w5Ico3vkF9M1oCrOLOW+o+KAe/qIo4T6hKNGxVl5lPdu
fMxRI/RxR2nMJuMcFWjnKJOLoxbnhxKd5KMYnyd46KxbveWQmsnkgH47vuMo2kr4Wect3pw7/uPT
96QuV/NhAcV1KcG92xWcFDk6V8KRt7GUUiYZLqcay2ktH7CPj5ILJVjlhUhVLRbSqXTJANeulg6w
Mgl271GshPoEVqPiTnmH5GNYjdBHsYpzbEhdHYq6OpQIVFxGUizq1EqoKKVu63QxO4BlDasrhAun
hdVHfkJr11CsWhryai496F+uOLlyZPRior7yAqsEejO00GiE9AaTBkXqW9HZlKtyS9pk2alc3/EG
J5SVtHpcfIQIFMcHBcogPoy2FTVWbAiZUGzENH8f0CAcRRNJT0D5uKDoND3Kj+E4Qh/HMcnRog5I
nlcsfBkDl6gZlW3bICLKL43OWXiRLVY8tB4x5+n8+GTIe+JNDW4K7wG89jRNHuQ4W744a0KMilVV
WJxCTrDckkG2LFcLpWy3xYdry8W6rmQS9agSruEDdakcZ1RD00MpwZEqq72U53pbV7d2bA27Ecqa
CMU9mTUc+s76Bhsbb24G3wT+oLUC1kVbACqncAgA3aWjKHGjkUm7XLETIRuUdgalHIvR0CRc7O6Y
xFmT2qRIlKyKFsjFCU+MFOASwhTAc+CYjW2GhNyq3W9h9zaspeS6BJXQ3NdlJbR71rU1OJ0j9h+C
jA94ZygbzsXqE9MrMV6Y5eNwMj8Ro7/bYGuo/VRD4ZnwrTDmCycrg6rdz844zfvh60GCWup4jo6L
W+WWFEbUA/dFHxLHExSZcDk68c3+Ykc2Tky9N87NjuHdjIIjUvLLUZypn2cgayv15/PZnIMntApw
8BjEb5x08Rv2VxoXwLNbntYpAPDqJ4vWux/BlFSDv6dvWf3rc/lG30ZtO/z3Ln7slDCRW093e30I
ywPZ87cUoDmWVtIwdSr2vWt679qr0wUiQrPddb2zwz2lwPrCe6Yz/1Nvo3bxAZd/kPOwX5xL/qf2
Pv/teYwSCTjb5Tp5OhKe0mLzUS488lvLBEstsbTBYr8yxWoUaNMFy4t2LlZ0ivgUa9GjheRhI3xx
Z7hQi7ZoWl5Jd9KETSj3Xp5vdNfIcMJvbWfrWhg1qMZmRMDw6bCD7x5+3b0kcveSVM0HcgPYTdY5
zrxQx7kx2mDBoymE/RVLI6AWNcWepn55GBcv8SgX6reyqS7lBHSJlDk1U79TLEhgGL7oBXxVJBL8
EYK+EL7EU7mQJsu1HMSCxEEdKzljF9SxBHXCQZ2rBsovzLCtGpzJ/38qPs+Ze5NgxGPY2CQo1Ccm
wVFxpzxwc6LOQprlHog/yjA6EYYxMruBMOiqqLFVlMsIzXUE7YIyLrV7cDxbHJ2d4LyIsyvtEcfJ
6fxgzyFhEox5g0jjrhgRZJ1x3l9McYjH9/uiI/RxL4RZ74WkCzqlfW/598mr5TICDctLJKdxbvsz
ceFUKvRM6BrVZaZv4GHWT2BZ71FNQe9NKUG+UiLkdAdD4KlbG0weWDVlITslFDRnYhUodjghRUp+
LeOqYibLWw11WCm+vtJk9dnDfqDlAhv09FKeMtJyptJS9A1GbhLle2wvivdY+ODMF6toasvV7bqS
TwrfRj50MseLnFYn7vx0NTNcAkTp8HTuQyIqWn28Y8R8UeNviAnWXUJ5wx8451/3lWNenfLve+oU
pm+E2CmiqJsgon5Y1rYT3ng8ZJeeoUsjmZapYuOxaeXgqtjByeMWjmA51beQQEU/aHXlRGrya96t
WW9DEPDaYkCH47Uw+yM3p0FlPEPLQlWu6mYN7ZWX98ZxmRUP0kA4jdnFCbodzzHgkz1h+8cdUch/
5GW1KuFOyNUtyXAUCAmE6waxSBVJXaOfU4zGuhGr0eYsSM2+7ZxgyvxgbmGeu2KVix+OrnjkLVcW
hI+8HESxxuMf8ByFMwVvp8pOSomblHI1x9DUmS9OID27XWHfNvIBamqoo9phWdltya05IR8zdsSx
loVltCv4gMsMMx6VU9C+eeTTUw4ya+oRbSY42oilPahyQ2LdO+qnGJ3ieWfft5wv1S38UQS664mJ
BwjEDoGYEcA6ckgHMeh6TQeXCYh8UPEGTkGc7zggsBNjdiKKtYVVs5H1UKi8XgsvVFbYCnVuNc6t
MbmVJF8fiR2/dDI7j0ZI2JU4mdhvQyDPb0ewODH6QSfq0DlRp50TJZ8t7h95SU5MOH7NMKSphF5i
6rVlw+lIAl9YYEvlDm8SyN+wQzSFHjVrqIVEckDOwq5KcxvtTXEPh7YQ3UlK7MimA4w6jrkAv9fI
4CNyVMcDSQqi7aTk7bh2YTzyScTfdhPaBlsaf2xHSoXWtuVaNsFKFUIQO56LRvyjaHTXIdcEzlzK
0yG32JapxFKSYmf+UH+yry3OrVRcW6zpGEOrgqGgrhZzX2RpBxu24pDbQmrzWPp12tUlLVUplAsP
4Y5tC8sNK8OasyqrT06YFK+hsuJ1ezUkNDA0q2jLe2bBdUXTW8wR1snAEZ+4rmW3Kn9f3LexRaVT
agidVv/xlmqS7m4Z9c7MeepPuecYteX7T2JXQrnnp1zxlSFV19f/KrzsdSMIYSDc8xTUKS6AIQv1
dpFSbRmliPJTRLkqRV7/xjZwIIVLdzt8Hnt9YjEYZrj5jH9YDZDDCK/CZxC18FddQ1P4BObYFiT/
mP58q1QtfhhYY14OrHi+MbD+Haie2zCQOuIZf1wPUUb1RfR6lYuqq7fqWiRvwML/n+X7/SfZ/ZBh
2tljN94+YlN9AcQW/bXe2Sf7/OLsu/EFpcIpZsdOZ0MunGLswrc5wCTsRZbwkQhgfEb6kenEhi9M
gPB5d4XwjhtHhaJdqQI7s/QgDM7IKXtjOpE8N0edW82BTjRFqTDVjE7RVHNjOuHlRjI5E+DqXCR9
FUZnKn527kwncMtrzpSLXgNd5A6dDTaj1FwFdmZGpcxXRWTPXrJ35kpgCs3qHANqZi0m7WETKGVt
2WEuqEwnmgplbmRzdHJlYW0NZW5kb2JqDTIxNSAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJl
bnQgNDc2IDAgUiANL1Jlc291cmNlcyAyMTYgMCBSIA0vQ29udGVudHMgMjE3IDAgUiANL01lZGlh
Qm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAg
DT4+IA1lbmRvYmoNMjE2IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQg
PDwgL1RUMiA0ODYgMCBSIC9UVDQgNDkxIDAgUiAvVFQ4IDM0NSAwIFIgL1RUMTAgMzQ2IDAgUiAv
VFQxMiAzNDcgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgNDk1IDAgUiA+PiANL0NvbG9yU3Bh
Y2UgPDwgL0NzNSA0ODcgMCBSID4+IA0+PiANZW5kb2JqDTIxNyAwIG9iag08PCAvTGVuZ3RoIDIz
MjIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIncV21v20YS/q5fsR93i4rhLt8N
3IdYFho3jZ2L6PaApDjwJNpRa1s+UUYuP+n+5T0zs0sxsqm06OEOqA2I3J0XzsuzM7On9eRFXVun
rKqvJ9ZGcapi/MtbFeM3zlWRZlGp6rvJi1mXqWXHLLHqlpMX3y2suukmU3DGSabq5YTeykTVnybv
9Wxzf22mZZTozdZMiyjVd/JoTBU5fb9sVd12hnZ2wqcWDy3TlmaaRJlee/n1svEc6829MjaOKh1U
m6mNCr01CdSoxax+GxfKszx5huXh+nc+fyf7j613X1l2LhLLY1580ETL9MsH74LLvvXBcMIRxx+M
+bn+nnMVS66qqMo5C/wSMpWUUeZiS7miPKQFZYSTYwufElPpzcPnreFYmgwfvPm446dCIF1k9b+N
q2CPemVS/XjzEQmSzGyumU2YP0FPI1patfgsPEJq7yAoG98aSg38iOPgQOmxVkY2Lws4UJ+xrYnt
bSUHyFYlf8Y6ffj27Ob/8i3vHfKHZ5pHeYYU5MhzlfZe7TMQ+wycmUQ/IlC5fuDfW5MiaGv+XSJe
pW52CCnTXhG2c30FkdpMU5a9lL2fAJZCX2Aj5O3OWMJYi2WM2NO5Cr/NTavkC/esVy3lqxshtyvZ
lRUOWowVrDjI2RRlIbOlVVMXJUnRO5n1PjpxsWYTCj2HO6leGFv1W+oCH07gEf2+MQ4fOp2/A8zh
xwmsAEcaGZvqPHL8+Xk9sWqtJiXsBTDyKmfkR2mppvy7bSfXX6eWZU9NU5jvhvTMFZEbF/8KefBt
bAnVJVRAn0g/Rz+tRw5znidY7k+z6+srRZzi/M7kgEtrKF3XVGucX2wJBEgW0o2KoJftCQCFKpPj
/JMIZSMB91vZZFSvto3XsZvKc91yzS2p0hIu/XYHFRaAZdINf2C3be576jRDzVvuHvxGXES7fwlX
SGiIWIESP54toR7J1qh4UB4fS8cIfTwdKXjTkAzbJ8Nme9Cn8Peca3ZY/YBVpefqRKmzR0N1/uGW
mlmr3qCwZgik/DZ06FCLmaU9DFQWc2ceCZRQjwRqVJyVp9U+jM8FaoQ+HiiLY+JCoOIkBMr5Ari4
OpVuSDGihnFuyv79ByCFCge6P1UEClqOtwdCVaF96BavrgL/2eVPpAyVcFAGKzxaKZNd1zDWC4SW
FPltVEMcEBwP2lOz243o71BUKyqHvEI9BMYtcGv7ajhIisvRbEeTItQjSRkVD8r7lD2XlBH6aFKy
CrNFX0nSvpLkkpO3EsQr7tdUVoqwdbmYn6h6o5YfkRl0l+Wv/FQ7v1bNckcz2YaLhwWBglbpQEYM
c/2ZFygciGXik0NpuDOUKrW5F53bdtk+kDZZ9ipXj7zBJ8dLej0BCoQWhgL1sQEUnPU1MdNsCJnQ
3HjT1mKp/9rydkNUJJ/yHCvgxGZ5HpqcFRxLuDq0rwo2OMJFdAgMQH4MFSAdgcTzgqLT7dGSpHQg
D0Sfp4/jISuJNwCiL2Y9HAj47/h4zKfIUuF7Bp9NSsCCj0rYVDNmvbw4O/+C+dzQrIB9YT9RLw3n
aouGgTQgCYQjPFbNrqGE0CCAhGjV0u/qYbOmJyJNH/Fp9TrCsuPhBRChSwMaGSkUtQ2vvbBYEOBS
EFyGQIl9J7UMFEYrqW3ESm9ZF+YkerSsfWDebsNIqL+R0a/aj36VhBU+UTcgrwCgXMtyx+/qNBjz
yaCykRtEFMYlT0/W7ynZ7LhXkGkFD3ZM4sEul8EOjWSl5EW+0cjjCWIzDK3jY5OnjuN2XDwo7+ee
Z6A7Rh+HLupdmh6bi+Z/84MNY9UeDD3zM/VmvuD5V34ZT6X+bq5k7aX+ejW/8LO0KEAX/yLByT7B
/sI7v+dJVhKsZYGYD5HLuR78Hb9u7F9/K99/Q+GoG6df+D8oiL/Rnf//2zHyB+SZLkDcCPiAk7dI
c39JzcllvfpgTP3LZAoKxpQ0K8pAl5hgxHluQAl9BcfI4iB5EVf16LV/olhSYzY8AdeM/RJ3V4lm
VBVZtQ9pXAxgJLFK9MWUe/JLUjYzmX7NstMgfNCa/6Qh/KB/bLfrawkbIgjUPAkbee9rD43Ga55j
E55rC/13WTASuRciGzdMUX9RsRAB5YNekCRH7hqeeqQXjIqLcre/S1i6WLhD8RGG0W6QFIm/lr33
ns5p5qhQ2wG/wu+ps/li9u78LbVxvngQx/nlxcmB90l5zHtPHfd+XFyUD52zT5wfo4/7ntvBlTTv
D5K2ERWoF3WdKpyIa5D3Z45LmPL0UugW+kq3R1dS7ltbub/eWgRtSxfVDBO9o5WiiSLTGwqo0zxs
YLI2lsfqCqd+5SkLQzeqVzy1X/FvUHjGq0v+xfGnknHBi8Fw5rgaE3cnn8BYRtrbwIObAuIVjIM5
yH0SJOl+Idwt93MXbJM5LPNLceWLKYwmLrZf+G75Vwyhew5NVh+96o2I+yWzbFXrP6REXmyXiS18
VSa2TCa2NExsqbemkYef2J5cSoYt+B33rna52a5o+q32weFrkBjF020mdzGZbgd8oesR2z8fiUIp
Ijv1slWPQl7fk4xqepISrjue+0nq1tB43ew2W7EaNpdx4Q5tl17q/iBS91cX54E6+wg7celb8rhX
6l95OZjACCgnmPRh+uIVb+fat+sstOsSl8g7YyUEpKXrGv92I+qpnKKQrjuc0e6BglrqjTzumWMl
C8/oV+ofWGJaxvmxJd1h+klh+OmpIRZv6kzQ8tpbuk9qHlVBe0f3NYcHGdh4C59GP02/jL4Ui+SP
pqCfv102SEEWUpBxCjKaHuGJQ+ypESlpbiUfLtpA++LTWWrpYhnHEWK7xqu5kfVQqL1dCS8dKhb2
Qn1cXYhrJlOF0y9nYsfrXqbDIUO96dod3eFEXyzPw6tSUthjDUKoRxrEqLgoj/cNICuekBGFuBwV
HqWyZUI9Ztnz3+7pz6v/CvnFrMvUbMGtK1aL2cSq74GiX8AITH5SNlZv1PufY7Wa2BKaUqvSvCJD
7iauEtNpA13udrLgrZx5MvrE3SSJHWgDnp4DYwEqwu3k+puJJUWwEZfGqMiHUtjIRbOtMiSGtlKy
7G5vjgjd7jkSHDwnmv8zADzh+3gKZW5kc3RyZWFtDWVuZG9iag0yMTggMCBvYmoNPDwgDS9UeXBl
IC9QYWdlIA0vUGFyZW50IDQ3NiAwIFIgDS9SZXNvdXJjZXMgMjE5IDAgUiANL0NvbnRlbnRzIDIy
MCAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIg
XSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTIxOSAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9U
ZXh0IF0gDS9Gb250IDw8IC9UVDIgNDg2IDAgUiAvVFQ0IDQ5MSAwIFIgL1RUOCAzNDUgMCBSIC9U
VDEwIDM0NiAwIFIgL1RUMTIgMzQ3IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDQ5NSAwIFIg
Pj4gDS9Db2xvclNwYWNlIDw8IC9DczUgNDg3IDAgUiA+PiANPj4gDWVuZG9iag0yMjAgMCBvYmoN
PDwgL0xlbmd0aCAyNzY5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ1FfbcttG
En3nV8wjkDJhzAU3vVkSK3Y2lr0mtdkqOw8wCUmMLVJLUlb8SfuXe7p7BgQpglYq5a1ELhOY6Z5G
T/eZntOnk8HzyUQbpdXkaqB1kjqV4p+8VSl+01wVLktKNbkdPD9bZ2q6ZpVUraeD5z+OtbpeD4bQ
TG2mJtMBvZVWTR4G76Oz5eIqHpaJjZareFgkLrqVRx1XiYkW00ZNmnVMMxvRU+O7hmXTeGiTLJr7
9fNp7TXmy4WKdZpUUTAdD3VSRKvYwowan03epoXyKo+eYbg//oPPP6j+r8ZvX2neXCKepzz4EJEs
i17c+S2Y7JkPhhGNNP0Qx79OfuJcpZKrKqlyzgK/hEzZMslMqilXlAdXUEY4ObrwKYmraHn3dRVz
LOMMH7y+2fBTIZAm0dF/Y1PBH/UydtH99Q0SJJlZXrGaKD/ATi1WGjX+Kjoiam6xUCaexZQa7CNN
wwZKj7Uy0XlZYAOTc/bV6tZX2gD5quQv1ibafzs4+f98y3XYkD88Q2SqrIzKkefKhV3pIpwJ7c/E
+f3dZ0IzovbychIP8+j8zS8XIfa3seYQ8tAiiln7W183ar5Q4xsCBzKzmS0foKaxagHg5JF610yb
+ZdGiT7Oi8EsvrQXeiwviypTEFtbtK5mbfyNeArnAN8iGiGJLhrHumqn1EXs8IlL/n0d03dOR+8A
VuDkBF+Hhkti7aI8sfz10WSg1VwNSpc4pDevcsZv4ko15N9VM7j6trQsW6lzcN905ZkpEtO//Bvi
zrcxJVJjqQw+Wn1IfjrpOZJ5bjHcnknTVkmKOMX5XZwnJVKeIopXVDGMH6wazm+G/OJcR9PmRI2p
VuQ4xbSEsmGh/VYmGZuzVe1tbIbynDdcOUuqlxoPP72GCY0KwKJr/sBmVS9a6TBD5Zpu7vxEWiSb
30UrJDRErECh7s+WSI9kq3d5MJ4eS0ePvD8dDrouJEO3ydDZFvQO+33FlTeMfsaoikbqRKnz+5iq
dTjErxs6bTqS3zqmLSCcpNLsBypL+X7tCZRIjwSqdzkbd9U2jIcC1SPvD5TGMTFtoBwF6n00vjxF
ycIxl8hYjpNuRxSnEgUDpQVl8kSC5aLdiseaKHpkKI86pc8I9LG5jOLJ/2uW5hxSF4QKsKWELHiS
DkWJknPDo3tPJ8jkjLhBDtEDjgYei3jouFByiaJqKXa+7Binz8r6UDs7OTQ5btjeHIr0SA57lwfj
bYYP5bBH3pvDrAKhaAuPawtPLljnulGgitMlTVWoCFNvxqMTNVmq6U1Md00z/cRPtfFjVU83RMSW
XGs0BJSCKgriNd1rX3mAOoNoWihJNcuRaIKMWi7E5gp5uCNrMmxNzu55grHjV3o7AUc24Cjbw5H2
JZQgBEfIhfrauzYXTxec2FShJOosz+kSBLpv5JvyHUZPJuixjJ7W3/kXscbfCB/e7hS4SfaBk9pe
1EB0BDKHF4pNs0WTdXS+95YelvfjJStJNwCmrY0tXEDaGCg2Gg2RxcJfQcQRhpSgMbZftZPqjFXf
XJy/2lF+RfWB5kX9RL2IOZcr3D9IE5JEOMNjVm9qOeuWoh+phn5nd8s5PemMFm30vY1tMggUSCd1
ErgXyaCY5YoSFosHAU7FHhdDQZKLWTOQGM1kthYvvWcyp+TBzC3quLdZMhImPwgj37Jc7cOKPTHg
aVvgU2XkxxseqNPgzoNQwxuRiupU6pefUzJJDVXBNbKgJsvLGpkWq3VMBfrjZx6EVUOqy95Uwwoz
tbNIHo+gnYHy9tM1L+0HeP/yYLzlWwcw3ifvxzgKp3PH+Njo355QMaj1HtkanavXozEiQZSYfhl4
ZfTjSMnYr/rn5eiC2bL1BsAeukiwdtvv+NZgtGAGLUCIZICYdyHO11fn73izsn19qt7Rt9Y/fuw7
efo0n8Ibx8KCg1pkoO0CH2fj8drLnwmjFeoRmRgGG51Kzpaq1pI/aB+iEZHejIs0DvHHz3MZ061V
AfI4gx/ibnS/Yx+5N/k033bww9sLMfru/n6XXfe8CTTQq1Q6F2jwFp/2EQoblWE6g0BnNPMo8eYI
Jc4dQclfN5bnfP6lKTEoKC8eU5hQTVpkeKZEFwczJarmF2EdKjJOzt8xFAdiwcMP0aqhLpYPDfew
GdPNXBpdZqPMCul3zkdNSB5f2VjjzxiCg1siK8r+utRyUCOk4UmhempBftrbnDhtxp5ntA+Lx0rI
E7Wfas/FnbRbvzOd6i5cXhB5drixNF1l/+gWHFO2ITB/eXz4rRuklLY+pBsjE5TQhQ6qU/ndpfsl
4e9SWM9AzSynnSFe+N/7BfolbqeqljjgwqSssq7Ux80+h7N221o+5nAiPcLhepeLcUO8TKS6yg4s
71HoZXHWFJ1OJS0CNI2nUlz0iIoRAsaU9sLPqfPR+Ozdq7fEnB3NkcarNxcnexGxtkjSsi8iXtof
kf7lYhxJCPvV1KTtLT4o7o+GzjrRyFsARzqJJ78Nnk8mTuGYX0FcZJVnW6QFhIi8FLmGvdJs6Zhz
23bFbSOrqVnjtuhrbJA6dDlofjTXUiKoMqIeAgWJGyL0UlSG5izglsRRI1YxFFnZL7oRWaPq9RpN
lLc4lYW16My7H/PG1MdmQy1aJX1SETWNmA/yxr8wu+54ISY7FJsWq3pn8Qzk9mPYKrm1a3smngSz
PLj2nx2/jKmvvOTfELtzHr3h31FMTeYFv3c6T4qWBJDjUHt7TaJ+8SGay3Y/+1gf5AKmPRihx2jo
tig4CvJGhJPZOxNOi75R5tHNgC1Qv4l7xUb3HeXZ0lMKhNpFXn3VTJv5F35veEthM2JWVtab5pmS
icbHwvsjX1G1DJd8hwVLK+6s8ugl91M6kltNrt0rCcZKoh4cu6VrLOOkH9xtp6GKkj5W/Y4LbDNd
rmZ0p4KFd/IDOulJJtMM5+sq8tTR63LR/9yThDbNtHTaqHsRzxe0hhDnRUq0fDmPKcUEjnqzXImv
2GqZFmY/2XzuI/Mnjvww3O6CGevv+bMbYAzbncIvYlmfeNgJIu3vJKYblvBOufGssxLWWWLRhbqN
dcnhECvrde3frsU8lWKcxPlazRkbGQSAOFEzki9lsGpm8vLtWEgNtH+2BmbbGui53xmwVEqpyjgs
FZ6fZKhOT2Lik+rsXiZWKyk9GZcawwUE+5RBLY9GLZmo5RHwbEgprPHlykS7NnBc+UVshVR4Ha6M
reqsqylzwTOkzEQfm1myf/eZ7NjdJ9Ijd1/vcjHu2sutAHd3O1KT6aTI+9b2S8kxLz3m2MFPB3GP
9W+In5+tM3U25ls5VeOzgVY/AUm/QRG4fFA6Va/V+19TNRvoEpacVi6viO/cDkwlntME7trPgzFP
5azDd/rtwKYGso5Oq1HgkigxcfXDQJMh+OicI2LQWSUTZJmIVcpT6HQMdFp3gs5WA6fJiGVb5Rx6
B7KBz98OXF6KkkyQZdJhj+AFqdgS56Or0iqURGzE4/BxKgHOe5yW7QTbTbXYAVyNxKISO0Fnq1ES
5HYsWzxt3rHsJ7qWbWnFY2+4VWkVKp2YEOMcGcUUMlOwXSpSeTshMcadzFMVZZ9iXCW6q7PV0JQF
tuyAS/5YlklmUIDEY5kgy670DgGFnGFXepeDzlajkk+RZTBrSlZmtcQiTBDFrGSjHij4JEWiRRKP
d3CD5LGNNnVepVUoSoI1f/h/AwAYHl6wCmVuZHN0cmVhbQ1lbmRvYmoNMjIxIDAgb2JqDTw8IA0v
VHlwZSAvUGFnZSANL1BhcmVudCA0NzYgMCBSIA0vUmVzb3VyY2VzIDIyMiAwIFIgDS9Db250ZW50
cyAyMjMgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIg
NzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0yMjIgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BE
RiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDQ4NiAwIFIgL1RUNCA0OTEgMCBSIC9UVDggMzQ1IDAg
UiAvVFQxMCAzNDYgMCBSIC9UVDEyIDM0NyAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA0OTUg
MCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDQ4NyAwIFIgPj4gDT4+IA1lbmRvYmoNMjIzIDAg
b2JqDTw8IC9MZW5ndGggMjkyNiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIidRX
W3PbuBV+1684j+BOyBAgePObLWs23mzsNJKbziQ7GUaiba1tyZXkdfOT+i97LgBJS6KdNLPbxpmI
AM4FwHeuOJoMXk4m2oCGycVA6yi2EOM/GZUx/sYZ5DaNCpjcDl4O1ylM18wSw3o6ePnzWMPlehAi
Z5ykMJkOaFQkMHkYfFDD5eIiCIsoUctVEOaRVbfyqYIyMmoxrWFSrwNa2QgfjO9qpk2DMIlSNXfy
82nlOObLBQQ6jkrlVQehjnK1ChJUA+Ph5G2cg2PZ+frp9vwbv9/I/vfaXR80Xy6Sk8c8+aiIlqrD
O3cFk75wYBjhiOOPQfDb5Be2VSy2KqMyYyvwwFsqKaLUxJpsRXawOVmEjaNzZ5KgVMu7L6uAsQxS
3PDyasNfQCBNpNW/A1PieeBVYNX95RUaSCyzvGA2YX5APZVoqWH8RXiEVN+ioCy8CMg0eI849hco
nK8Vkc6KHC8wOeazJro5K12AzgryF2ijtkd7F//KUWb8hVzwhGmU5BgCGdq5tP5WaXMpI3caBxl6
xKsA1xJ1Hlj8naCRE3XM4zMhvA9SdcoL4SF5R4F2o9lrIQMZLlcL1gVCWi6vA12iScOMbIKupNUn
0lMJ8wbIJBnaKMZZtam3DEK2z8vUQGiiJMn5BmIN68M6sXKHCTpKhupHQWjxQjpBtX4NTs/fHJH7
OvI7OABLZ7Lo9bR/zvuOJgMNcxgUNrJo7qzM2J8jW0DIv6t6cPE8tSgaqrV4btOlpyaPTL/4M+TO
3rgkVJNQWtyR3kc/mvSEaJYlOO3EqGlj1PnIOwQqRRPihTDJYS4u3WRVB2GJzrCgvII5sj5A05eU
9FiCbKDx+zZAZ+QsZdRsVTkVG+YNZTLniWjdkIdpSqcxfhwDZeWCvIlIl7KfaFgJX7VoOENLhxHq
nVuN80gW/tWV5RDCZBdp+KimLquhL3iwc8z5/YYW6hOG7hX3yuOnLNlD77ekRV7r7aib6kcjHyaE
zAkncT/7FWelGmFYwPF9QIn/7oaqWw1vMNMiMkp+K4IZkzOz1NtApTGX6h6ghPoEUL3irNyWLYz7
gOqh9wOFmaE0HqhYe6BM6XLi+RH5mSSRFL8n7Hx+9is790gaggMYvzr3lOOz9yRYqtOQJQ7J9yzm
Stb2GtMkBYThRImpabiUwHCfa16d159k6lRVc8yUG7RHtI25ybC49mIu1Ccw7xX3yhuL7MO8h96L
eVpiL+EhN00KRwpD/pYum2MBovr8DoHI/dLZeHQAkyVMrxB2LObTa/7Cxs2hmm6oB8NuQFMeAO7L
SuXJmA4y9YUn64DKDRWimg2RYftXkshyITpX9bS+I20ybVTO7nmBA8NJOj3e+glVTLI+uQFan+UO
qRTlaH66DpZKHUtXYywSZesaq1/KB6P/XvmlnJ1pO2aPk16bI+kJg+8XFJ2m9YV91u6h91s7w7LA
LXpjWjHqyEHjMRtRs2ywaEvjIYsgiJ2dHp885j4h7hIJwn8ADmG2MQG4pKDM1HRetVaciz8QGWTJ
cW2gZo+oPt80PKjnqgP+DD7Xzp8eAoOvDlV713Haa/nO7pZzGYlj+N7VHRCqR1IzOIr82VerShYv
H+275cWzalMB7kC+EAOioK3Nmla1Ldm+rRstOMnLsUqudwmX4OZYllrq9b08bq74I5tqJbNqA2PO
/K+oyGeK/Rz9gPxcPLxUh0MuB6+93lsuJjVGcaLWCC4CVrHfF3g9UlrDXJZBPrWjPjrkZkmw7j3/
EVQXsvWmXnG8zv+YL0Q3nJye+DPCbWDMkwfZjqs0L9vGaSe0HLU/uvrFnXJHSizVqm3RXWJ/aCET
Tn0mbap87Kr86B9vpdxwaGnOPoWLIKNGx/BmRNFjlfyyFxbq5xHI3En97Xx0ynglTgE2CB3nS7PW
+ZLW+ZKO8yVsPHx5yQT7rcfel/mX01c8ctrh1/I9PWoOyJ/tUx59kzJGJcHKnaAtmtejaZqKuPSP
R5E4/5X8l5piEgy95DaquyEN2KJKuN0sffCQe88+Bt92+z9p1Hs6vujkJ7kXw+Iv9H9x7udHX8co
jqCjotRZxxGyxhFsc+2v0seRyXUL41Z+uXBZLm+1cx+3X4h5id9rxz8WzJiyKRxyTFB7swu15NOm
Tf+LrvO16WZ3JDGAhlpSl1pSM/+eGvgxNfAuEmI2lk5Mv4s0TaWWYutcYUjtpcZq2/n70wxD7Yj0
K5n3u1Wn3dVtG5CorfP1FIofxSfp3ZtF3FBG1JNTPcSmwT16451Y48fMB9V0H4kK6d3n6lzOLpH3
ofI/cfD/ejQ8O3t9Muom9Nh2zOrIoU4ZhJCc4pCwIBCwKUkcCk72h7q7C2y6lPS5mfu9X+Cr0D03
sEM9v3sET96B5/iQVJGTpAjL3lb+h4IEYMwublzWe73dUlvuZ/taaqE+0VL3invlsW+4DeK8I7tL
7W2qExSzhW+qndHIHK6jFZuhZxs08VjCWtbgeDQevjt5S28kS2vEcXJ2erCFRZLk7YF2sHDUfiz6
xUU5ZipHxGhLzbbwXnI/Ghi/LRpZ48FKR8Hk98HLycQCeucFkvO0dL0OcWGHL/RC6Br1FaZthpKs
7WqzFll6E6yCkNqAL4GhbIEvUUudOcFp6a1I7kUNZc6NeqZmjkIv1BRfqIT6Of96hcc8O+Pf90FI
b5tTnoSy0yFPyHFLdFwat49YLmqynWwtv/KCtPyCzBzdCz2QU2DB53NvKNnl6or5YLpc4UNVbgR/
dGRXwn0hH0wi/J13ry63dXA83h8uKLMmHjkUwBOk/vSwFNEaaocYv8aQIlN3nMenv5JNhe+Gf90t
H92o3l/KbPsS1C5ulpsgRSGHJ+le0Xl4PoM5EtdsAB66dX+mobQe2EnxMnGICmqpcEKqQcRpWNFP
HfU9Nt4FVH5qtMUMNldUzVtzo8vJc0XjcbCFsb70X3b5ZE3Y/nnP/QBGE8GppjXcC3m+IBmoGhII
F5WKXJHUTZDgqNosV3JWBLGIc7MNJkeKMt8RcBJmiU9liTPJ8ApDJkck2F8Sdc1Tf0mq1uogiDm2
XrlOj1u+jBq+ICxQhBtSMpDFXrRBMUOZ2ildrys3upTdyLGwZMzXaGnKQZkjLPgXfTcjT65nMuhE
YhGlz2l9HkfJXsl3Zi9rWv82DsyAzscObhjSEj3pWqZwdBBQUMHwXhYwCyxktBECOW/hJpV8algy
6KXi6Cb/cTIufkv1WEdrN0qEhG7OvkqawbGSymYjmIkavznz+xNSKtHqcz2LdkHtdCkdUO33gtpi
6gO1cMlCq7uaYXH1IGegESKZCMvaMUwrulDWhutDwF0opTTFGEooxoyfRzOXmdMhK6JHkEyEDsvu
/rzvCoRPCO6YNdyIlGi6btlh5A5a8fTzDU/8hlydOspnL2DIMEj2c3xC+0Qlr3RXcgevOhdzkrLB
0oEyi7bbEZM+1Y4I9Yl2pFdclNum3yjipt9wVNNtzXZk+6l0MEd96mB7t/bkHu3PkF8O1ykMx9wo
xTAeDjT8gt78OzJibDyAjuENfPgthtnAxCVrsrg5dlS3g0RnUWGbhZvBmHksL2EcGuRBgSjr8jQc
OQanwYWLn3CtEEU2i7TXbItmgTTTkmEezIvEgmjEtsPSMKSxaE0KOW8aG+q1bwc2i3kbt/Cfsssl
CWIQBKI3Sqng705z//U0ggTNtquFlxZjuaoOpampSaAoO5TXPdvBc0giJ2++efOXN1+8+eYtxluk
iOSbkvL6EhVWvvCsOBMrr6Nsz3bQbB9eGjjAkdeEyEuDHg7N3eKGmR+ry7lrL2zuygG/PwyZC1IX
bbR3bysHRp5hze81DL5oGy7Cg1aFg7ZhcaTdlteAdme+VAkEYX5NiPlSxZeFeN3iBsZ1aClgInuR
d5nxbkHeJnYu/tz/CV8KZW5kc3RyZWFtDWVuZG9iag0yMjQgMCBvYmoNPDwgDS9UeXBlIC9QYWdl
IA0vUGFyZW50IDQ3NiAwIFIgDS9SZXNvdXJjZXMgMjI1IDAgUiANL0NvbnRlbnRzIDIyNiAwIFIg
DS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1Jv
dGF0ZSAwIA0+PiANZW5kb2JqDTIyNSAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0g
DS9Gb250IDw8IC9UVDIgNDg2IDAgUiAvVFQ0IDQ5MSAwIFIgL1RUOCAzNDUgMCBSIC9UVDEwIDM0
NiAwIFIgL1RUMTIgMzQ3IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDQ5NSAwIFIgPj4gDS9D
b2xvclNwYWNlIDw8IC9DczUgNDg3IDAgUiA+PiANPj4gDWVuZG9iag0yMjYgMCBvYmoNPDwgL0xl
bmd0aCAyMzk1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJzFfbcuM2En3XV+AR
TEU0AYI3v40lVdZJPJ4daba2Ks4DR6Jlxrbklehx5pP2L7dvoK7UjHeSVOwqEUA3GujbQffFpHc2
mRirjJrc9owJI6ci+OdREcFvlKrMJWGuJo+9s8E6UdM1sURqPe2d/TA2ar7u9YEzihM1mfZwlMdq
8tL7RQ+Wi9ugn4exXq6CfhY6/cifMihCqxfTSk2qdYArDfOp8VNFtGnQj8NE17K/npbCUS8XKjBR
WGgvOuibMNOrIAYxajyYvIsyJSwHXz/dn7/y+0r2f1WivjKkXMg3j2hyo5GW6DdPooJNvhdjWOaI
opsg+HXyI/kqYl8VYZGSF2jgPRXnYWIjg75CP7gMPULOMZm4JCj08unzKiBbBgkcOL9r6KvAkDY0
+r+BLeA+6h+B08/zO3AQe2Z5S2zM/AJySpZSqfFn5mFS9QgbeeH7AF0DekSRVyCXWMtDk+YZKDAZ
0l1j094VFcC7Kv4LjNX7o6OLf+Uojb1CkjzgMeNcqlLwc+G8Vi7feCBnrYaBAyM/BylY5ol+H8Bs
CTkjgbi3EDFlU6kB8S2X9wHYKhdyRWR1Ba5KIDJ4irZ28lvOK/UC4SP8zR2doHi2oMmncvvAGTOg
Xl4q3zBRLJHZ5ry3bPjiKzq42nNqH8I9ss6ovg3jOGutkLRGsGyDSYCsmR5BfDg9DkzRLqm3cHqs
P9DvFRyT6ovRe8gDCMFzuApwuDAwToO96fjRpGdUrXq5Cx1ETlqklBohmL5Pv6uqd/tlap63VOfg
+nabntgstN3bv0DeOhuWmGpjRNiD3cfoF5OObE/TGKabdLepB2DYSnZ+D85CN6FhbxGMYpmsKjA3
2n4BPk71tDpXY4ahAW1Bb8QQBO94kcJjtipFRtPnb10RKKNswmBZXoMIC3FDpDkd0KzKRUvtw3Oi
p82TLERZ2PzOXMpjEN/iAQAx1uUzC+Sbg/dt6LznvWkzeCy63crUE27t3O6FR6f81kHv9psDXue9
hr6atv7z2ZGA4pdgFNPOfg4QBkbqXKkhJqED9ABLpvoBH0fAiyVP5XNPLHWlrqr1uiR3puAMXKz2
rZdE9PB3WI+pJ6zXuZ2Eu2Jj22PW66B3W89AaNjWellrPSk6xh8uIGjZbGRCJ+OfAUQMQE6fIPSc
rZixFeNdK8ZaPvfEwlbEVMggfBGYyjkRKh+vL5ggNUFYugW6PF+wrE+MoJgqFo6b8aq6GiYyWtdz
Hnmslf0ecvvowgPn2RTe/E7nMfWE8zq3e+Gta485r4Pe6bykgBKnG68Ebj7As1AIeMnS9Xh0riZL
Nb0jpKim9/RVjcxVOW2wNFwKRClBJk8W1PlMU8aThtDFA+EjPzFLBkRQY1o9oUSetmJnz7TwhOEi
O0WOYsy6prtfk+us/olml6NNnNjUI6NcXcl0gf51ECW4WBLWQZBQeKDHIwVxY5I09Y+q9caTamkd
YNrX8GJm+FrnFD+oE9wYg8fSJWukKAxmRIKm/PhQyxhuQxBr9EyxrIZkQVaE+zEXxZ0BB6QT0XZ8
I8u0m0CMHWLC3tbj9O5QS3Lk9bHWNidYjbSxllKUAazSW2Tl3bOIEmBtqEycwAcukodzff12eLnL
fYncSGD+c/UmgPWcn7qCws0gomBHM61LCatEXJ8LA3oFv+SUbcIdMaNvUvDNR350c8QcPKSqRBhH
cqJ5Onta1jzC+LRtdS9XU6WwqYvQX3cFj/Scz1JyhhytZmVTYuxgHEy+44Ldbgp2KevgJtiv8NGF
pFixfbTDi5JZLMQlNXp39OEDUVeclY0aXF//tMmbx8BaStVIrOJ/S1mb074K0i3WW6DsqM7FS+zI
Z8Mbzbf8xGfS3gcm8B7KPsUH8cp8IfdjNlZhxcECycWsssNfd8cUzRIMvpdOCfQM3UWpULuTqnu7
F95WlUfyqovenVeA885tVZ0HmTX6t+SWZBGnTZtaQ3U14kThX4m+H0aK57Lrnx9Gb8mCsQiA0mcn
/uJN/MnTP1oQiGP8BU7zpAncbgCmvoX8im5vM/xavj9CYKcaFzv6k9lZ8Rs9wphLKcoAsgnVcQ7h
TkkBoH4TbOv96ob3/9HxVaOv08G/hZAMkbHtW3hQSXj8OKrxn6j8q0fDej0tVzN+/DflDF//8OWn
eG+1LURZdaMlVS7lu/hUYg5iD0UlZc2fGWYC1JwIX04P8eXPdLIdViZv6wrrpasxVKYZQVnGmItl
ApUXCWAgrq0q8Y2IkbqcJQzfoLpchb/p8GDRetC0x/5NXPQN8T4myLGAYBlVg3vAH8cnGi+hngD+
zu0s3G4aKxMf7D1G7QT9GITCtLPpYt9KbzVGnX0Hpoaj8eD95TsMFiqlkOPy+u35ni3iwm0udGAL
oXbbonu7Fx75Rw6LJHu4+xi92x6Z3bJH2sa6NmEw+a13Npk4BXF8C+QsKWA3hjlywVvE9JzpBuTl
VhiOIhm/m4arjAw6GIutARYS3MZU1Cpwn+JhpPTNyG4NVVC/E1EXS+0QSyjnAjqbuglrlde2KXKf
mtqhOV+olDaMuyZRgbsQ6t52m7SRNGa+AM7kgkKnw2Zqu3vb78GkTZODlhiBAFFQPSKTqha+Kk5l
x6YyONpjRW1tY6W2aZZouQTf4j6mdLgNeocg9p7yvpouVzPG9mJjZrpVhk8buyMhbRN2xxYfryLb
f56ZQkob8nmhp5V6ZpZ6wTvB/bLAMD9nxvJB+Z0YCqlmaQ9gCHTUcsW6YCsTZXbfFFsxbr8txk0i
xhncBeDVKdzJ6XsYYh+CNfg5Odq/4I+ByaWadnq9Luk7x53oZOwuyEr1WgaQAyloTlHOL2vLSuND
LZ07pmX8DVq2XdG0bZVEYcw6Vhni4p6mHEoFqQ2BNfqdVqH46VOcQrz2MeDnzFzK+nrJy9xP8njB
LLU0guuAwIBXhaVRMx7UdNq6Ed5nYoK8wY7pI7NUCNZs0DbStwA7t6cAm6knALtzuxfeAnJa7NIA
nVra4c5OKl2LqaevdXBwSzwu+wvks8E6UYMxPSKRGg96Rv0IIfMbMEIAvigTqSv1y6+RmvVMju+L
US6D/HTqsRdHeJ124aE3hiUIXeJJwjQnHqRt8bQceYyXeOjdfreR7OCuO5J5YUeygz5tR7LnaTkS
g5qKZGj1QHsHfWGcbu/iBZSMPLQPLAV2f9xcx/O0HKbA15ck/28AYMRXTAplbmRzdHJlYW0NZW5k
b2JqDTIyNyAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgNDc2IDAgUiANL1Jlc291cmNl
cyAyMjggMCBSIA0vQ29udGVudHMgMjI5IDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSAN
L0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMjI4IDAgb2Jq
DTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiA0ODYgMCBSIC9UVDQg
NDkxIDAgUiAvVFQ4IDM0NSAwIFIgL1RUMTAgMzQ2IDAgUiAvVFQxMiAzNDcgMCBSID4+IA0vRXh0
R1N0YXRlIDw8IC9HUzEgNDk1IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSA0ODcgMCBSID4+
IA0+PiANZW5kb2JqDTIyOSAwIG9iag08PCAvTGVuZ3RoIDI5MzkgL0ZpbHRlciAvRmxhdGVEZWNv
ZGUgPj4gDXN0cmVhbQ0KSInUF9lu20jyXV9Rj83BiOHRvAzsQywLs57EdjZiFgsk88BQtMyxrhXp
xPmk+cuto5s6qSQIdpG1AbG76+i6uo7LfPAiz/0AfMjvB77veho8/JdV5uGvF0OiIzeFfDF4MWoi
KBtG8aApBy9+m/gwawZDxPTCCPJyQKs0hPzz4L0arZb3zjB1Q7XaOMPE1Wohn8LJ3EAtywryqnHo
pBU8mKwrhpXOMHQjVRv6uiwMRr1aguN7bqYsa2fou4naOCGygckof+MlYFCOvnZ7uP/O73ei/7My
6oPPyrkiucebD4pgkXq5NioE0a/GGIFgeN4Hx/kj/5195YmvMjeL2Qu8sJ4KUzcKPJ98RX7QCXmE
neMnxiVOplbrLxuHbelEeOHsoeUvoCED11d/OUGG8sDfHa2eZg/oIPHM6p7RBPkz8imESwWTL4Ij
oGqBhHLwq0OuQT08zyqQmlhLXT9OE1Qgv2JZQ7+TlRQgWUH+HD9Qh6uTh//LVaytQubxsO1SDL0Y
HZ3pTq10q1Yqal2hm331hLZK1Jp/546mWOffEk2Gpm0rGDHeavXo+ImbGnDFYLhBX8UYGrKVJyS/
xayCz84wM/jtA98An4rdS6ZySMpYTiJVhAGXKhBWgjtbMnLRisSbCj7yQrb4Kj0KluqZKUUfIdxU
5pq5BLic3lfQ1nKwoECLUYf90BhGbpamMAzcMEw6Q0adHQMxY46Ce8h+jCbQauL4WXcEt3hVqN7x
740T4CWX47coIIbxhcikXcfXKnUDvnycD3yoYZBqV2P0xVnMz8vVKAb/bqrB/dehadpBtUbxg114
FCRu0E/+FfDO3Xgk0CCkLH1EfQp+mfdkjDgOcbtNGUFskziSsp3fOigQOokMe08JLTSbTYXmJtsv
8a3HqqwuYCKOHTEJeYNi6o0ccrRNN4Xh0Q7lW1ec2Ik353Fz3DgUlLWAZnxBuymWHRSDJFVluzYH
XuK2z4IFNo+JFHOM61AVT8JQJEfvB662nremTbDg9LtVoGfc2ktumXvn/NYD7/ebRlxtvUa+Kjv/
2dcRoeLXaBS/273GXarGcAFw9YQG0fhg0ZKxmlOBxZSzkq35PDJKXcFN1TQFuzNGZ9BhdWi9yOPm
ocd6Aj1jvV5yZq6zrW1PWa8H3m89THlZ0Fmvi/nAxPzk3SUFrTWcz2YMu91rLH5jbFAwm4gdY7Gj
3rejVubzyChiR+KbYgBjCGKuZkBlI/az41M6r00aw9xNYAv9xDtyA4oyr6fCG26uIrNqLKGwXe7i
twYk0nISZyLZt1Cxd7V63tWmdoiU8rhcMMd2TCp+a69aYKUIj6MhiLER6Y0GgZ6Jhl5yy7yLlVPR
0APvjYYoQ827BNh1sVRyKBg4f8VYTXx0HGXD1B7dTcYXkK+gfECzYG0uH/kLrdlDUbbUr64452Hj
wKkuVRbMaSxTX3hLCcpHP4WcpiizUoWk/g9WS+G7qcpqTRxl27GdPvHBmqLPUBo+MGJ571j2O/ZZ
qF7x7nq8DbsgkrAj4YzwYGV4Ft41hgEHAF8pEUDoIiLl1Rj72oMw8MLeGEDQmQA4TSg8g21snPJ+
D7zf+zE2Lmnnfr9zf9a5X9yu1XjITU5uMuGYnlaErYfujtjeWt3dXl3voV472M4EeE7IF/DS4ceG
/o+5mlFLsqKJJ1NlXRgP+wrQxmRdQQA5NHj4ZOW4LT7OOzzm98B45BIsuPCRCixB2c0YduLYTJk7
KvlO16taVi02TGmXdYyoUOxRTeHShdcUC5G5qJWox3vBinPPJhAwxwsdLrgEmUOMYIoYD9CQvtax
bfb0dhjwzTBQciPs4QXURxIHMih3qonZLAXeMpwSHHZ4X5yA8S5ByATfKvcsFJZL6e5oTRlvgy3H
THAw4pnBg91OCzkoRBDuaTsZyKq8ILMy2r5w+9dA8yTQ0nCnREHczLYg02WWdoQWxBDjYfFOGqRX
vNm+6AVpnRmzNKJd0SmyrTaS5PmqPe3o8dONxj5rUYEzAK9kf0/lCj3RmjPms5CZt9pxbBR3jvW6
7BqY7Fo30EjxibhiUeryOWC4eGIiuhTGUFDxQUGrDYY+Rr2A5zWX1Ew9MLHUpdSwmvEvFEvDqmga
w5WemUGtzZGQ7NXilEtgoCzqg+EHn3jBtVXbWrylHd3dvboeH2bDKMm2vflRQjTQ/pzYT26YG5CO
KLsdkh4D+xMiZk2td0aCo4o4/pcpgJwBpdO2uS5Q4yu4GWOe46mMfjmFpOq3McjeUP3j3fjWVCRh
gH0pmyz/hW8Lwy4JYDmQi5c8xMmjUrLB6Nt9T5qy8M4fTR39q+3yW/FOrHqluvwa23MrNkWIPUGI
DvDsAzp2xjHtu9fyBt8wi6HlcfAUg6zjZFLsBzVuzAukmkV1RfaU2OlJYzr74Owa9wfU+zaLf5tI
Ntfg0/H8wCoYylBEuqnr2+vcyf88TkgcY++3EfPfU+g7Vyixwx12zrGdqKFsOcTpxSTcye28lyDt
HBrY0Pi5tPrAYmMLs3rkLqCubEcZdR2lNL3SVWQK/gbPjAqNjJ2lu+dun5KEKS077pYEvHX4Tmtx
HPY/m5UARHx2eCwOD9ByQ6qyr47r6s+oAZCjA+lVffZobH6f5GjJ77fmV22GFmyOpPFFt79bf7+T
d3Nb3DlZ29zWcKMbY+tacMiF3Ek885mtH01VmqkqlGmr/lRjA8gonEKowvnyFEPyDMpKtSvjmSpT
X8uOV3VTFpuptMqxGc8yJYqcTGJe0in8Xl29JD4kRYSXn2yw/h/CGyZdTFOQvDrsk0Ke2vr6JIGe
6ZN6yYU5joexHQ/Ruge0p6C9nVLocztl+iTjKnKCaVfEU2Oa/TLshVDnxJzB1Xgyenv9htpsnh4J
4/ru9uLAFiGNbHGfLQy03xb95Ja5ZztKfIBRcEx9Ct5vDy/csUe8faq+S8/0RZ5rwKi8R3ASZaap
ISx8gAJPBe4jvzTY6Xp0F9Xx1rQhvsEN9ZIZjXlURHBooELBxSPiHKPVlBJOTE07PbZEHtt2UMpo
JGJ0nCNiRdTFjAl3B6UQCbk84RT2wFAakdAmsXrm7brm6Uiqmd9Vs2zvBqhFJBrvUh5Z5B7qcVRL
zY2csyQGyIRT1op6IBwG2wrMLUb5FYUUCohTH09OVjKjP7alshL6nV6ZtCKTXbrfmkze8outypVN
YtnWTHx9wj1ZI/OQtGpszh08OSW0fz+ZLk7Sv+T+soInQZHUm5HrGjvckR4zQSzmYCltaaHjuXSK
7WojWqFOqZcEh7rtRGfwY9HpR8Y4owcKvRJl0uoRl/CSZshQXTjUuJmqDgvHp4amYrSmKfg746Bl
b1KWRJXqxiymFAw1s+DiQVuDOv1GBcMfUHC4n9rCpNM1QtVEWxTtkbcwugCa7qhVe+YTbNeHGZf2
JQqOiDNBLMx5s5Ljsi6w+st6KSg1xQtGC6VGkDOD0MJUFmgW1bSM98QI+CIi9VGAFWXVWBlU9zCz
YvSfyawCPZNZe8kt8y5zRskhOIgit5e2F0hyCfC8WKcutvDTzM9DX4yaCEYTTvceTEYDH37HOPkT
ETHqPoPvwQ28/8OD6cCP8H1qH3SKMQmLQZASG7ufDyZ8EhBGkripZpQUo22L0iGkKIvGg/tfBn4c
u5SCdJyRdjtEckCMCUcYc/lf/KfMMkhiGASh6L6HcYIo1UP1/tt+UBDbVcY/T/KBGDxenAlCOp47
skMst2FbX4ZxNbgNbySA9vwbrphRkjct4TKM4qOZybAzQdDU2WuRG0bs0kiT+LxwUJFeCBrZSqnM
g7YOY/B7bIkJgvqqjUZGgmpR70BT/bjAtRXS17tBnqTf/qnWFnK5eLxLTjyQAGYvP03gjv9GDmvr
K2qvIHPYjQQgz+mtYL5VaDgtdW3ClJQQVhP0xqISSm09kEIZCYCH2/0C/zWk0gplbmRzdHJlYW0N
ZW5kb2JqDTIzMCAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgNDc2IDAgUiANL1Jlc291
cmNlcyAyMzEgMCBSIA0vQ29udGVudHMgMjMyIDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIg
XSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMjMxIDAg
b2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiA0ODYgMCBSIC9U
VDQgNDkxIDAgUiAvVFQ4IDM0NSAwIFIgL1RUMTAgMzQ2IDAgUiAvVFQxMiAzNDcgMCBSID4+IA0v
RXh0R1N0YXRlIDw8IC9HUzEgNDk1IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSA0ODcgMCBS
ID4+IA0+PiANZW5kb2JqDTIzMiAwIG9iag08PCAvTGVuZ3RoIDI3NzAgL0ZpbHRlciAvRmxhdGVE
ZWNvZGUgPj4gDXN0cmVhbQ0KSIncV0tz20YSvvNX9BFImTAGb+hmUays4kjymnRqq+wcYBCiGFEk
l4Bs6yflX26/BgQfkO3NOoeVqkhOv6b7656envPp4OV0agIwML0dGOP5Efj4L79yHz/9BNIo9jKY
PgxejuoYyppFfKjLwcufJwbm9WCIkn4Yw7Qc0K8shOnnwXtntF7dusPMC5311h2mXuQ8yFfh5l7g
rMoKplXtEqUROZhsKuaV7jD0Ymeh+ouyUInFegWu8b3csabdofFSZ+uGaAYmo+kbPwUVOfq2y8P1
d35/p/hvlYYPhoPzxHOfFx8c4sXOq42GEMQvFIxAJHz/g+v+Pv2Fc+VLrnIvTzgL/MNmKsy8OPAN
5YryEKWUEU6OSTUlbu6sN09bl7F0Y9xwftfwNyCQgWecP90gR3/gH27kPM7vMEGSmfUti4nwZ7RT
iJUKJk8iI6zqARWF8MKl1GAcvm8DyLTWMs8kWYoBTC/Y19C0vlIA5CvIn2sC5/DXSeLf+SuJbUB6
eLBcQx9PUoJ5ziMbVZTvMpBLVBduhDl9dBMvczb8uUTYEk5GgnUfOkVTwaeiS52xHIxYdb2+dxG+
XHkVasAV5i7G3NGCoI/1s5hXB8APTeRlSRrDMPDCMGVP2b9A3JuiJR+TNsbURc7ENXlLgmvcP3Te
8eeVG+Dm5+O3WKLowBn6ghKR55rIwdTzruPpwMACBlnkRZjUJE+4ar0ogyF/bqvB7de5WdZyowi9
Drr8OEi9oF/9K+zO3kgSbhBS8zvSPsU/n/YcxCQJcbk7iUFieyOqMs5vMaU55ouAvaU+EepiWyHc
hP0KM4gFUZ3BRDrEiFUoGyGm+o0QuSJn20JtNEP5XlTcL8k2t0cl12giwMJh1pw3aLbFquUOsdM7
ZbNRgp96zReRAtsexIsl9iqs1EcxKJ5j9gMvspm30KbYx/vTKtxn0tqrbo37z+Wth9+ftwhlI5s1
ylXZ5s+ejhgDv0RQTLv6FVeZM4YzgAs62BEe7CGdzSXdWxWM1rLUr3sWWVRwVdV1welMMBlErA7R
i32+k3vQE+4z6PWqs/Eo32F7Cr0efj96BksjaNEzLXra+ibvzqloEwUuQRhTBM6ufuWWNZabH8Fk
LI1gmVssPzGNUKPOuZgJUyHOHf26ZymGmPHNHYt0zkibY6SDBO/OXqSF+wzSverWeJuHU0j38HuR
jnMcFdrm0g5efixAvxGY37kE0lu+PJR0MxmfwXQN5R2DXZX3/A2NrqEoGxqx1txP8K7jNpI5ll0L
vk9yxzTSq2Kc62hQgfVKrG2rstqQHVm2xmaPTNhQLlWzwUaCDQTzyvcVNhI6NjO863CjwLm5eX05
9g5z5Ye9iULWM1k6rSg2g10CT6Woh9+foiRHjyhHbT4kE+OhoCGNPKCCN1iQE7xWo5YII5a9ub64
3Je+lMq/uRb5M3jlIj1zNDE1F/dazlC5KHZJWEgiRQAq+W6Kj8s9huaZ0zCDj5Wm/7NsUlVqzOZd
lrPNeiG/JJv2qlDXoFAxOPesu1u8deZaUwclNiuaAtAe5dwHwiaKknagCncDlb4y0Ce+rMgLl1yS
i9CNu35Qf4H6UXhY/PxNO6eOLoquxiel4ZAT0XxGsxZOYXyVYmroRrxxQ/4ckteveXE5tvoPbhBy
kyH9mp44OC7P9ZqnVKSOEEG+EM8cTXd9pw992yBuBycgTvPdQHJ0CJTbfw761dW4ssKILoBD1WNm
/yFAIVz2Nqrxv/Ro6CGQqm9PxgVcjaXO5VOL5+cxyFq1/vlufM0zaqgG8CrulE+ctOUT7srH1/IZ
r3iC5eqhoSvnBETd4omoeDp/zz8Rdj+/Ve5/YbA3jHNGYvqTxM8JkMA/OGM68wkf2tShTiDrO5cK
koCdfXC7cf/Ad9V/qfxtMdhawONgqAKkFoKsrUZ9+8CIrxvspHEUOj803m/+dbILmvY5YfQ5AR+w
Z9FBKngmosPxHXH/+Pz+DVXCyeOQQ2wSfoqXdXvsk07d0/1r8HTwwc6xYyBaBjs4aQ6t6gFmpu1c
RjsXXKB+oM0KHz5o7mSqaPYt23n4/wdt/TWRsMPAw7dGskM8TVvEndFrd/pH9/KKomeehMp95vLq
VbfG2yefCU/oHnN7r68wT0jSPmjS9kETdp6DdAsFWEgTqqdUaXAxnozeXr6he52nOpK4vLk+O7jI
cZedQ0dYKLcfi351MY5jjw3W0Ph6oHyS3Y8GmW3R2B0px3iU4JfTaQRY47fITuNca4Gk8C4VfiZ8
g/ayzvGMzG6oMztkDbazrTuk6ffJDQJ5jSAwMhbp7JTykBXI6GRkRkNWAZ+EUDB3yXoL/rQiNMZF
MsClPM1FPMZFNGLTnmN4IBOZDGe5I7vJZyGkuewhHoCYV0d4tkTqnYrAWDQlAvHqo3WLJYV/1zU5
g30l3lQWFdxSG8ssQoRJRHMnFRqoyxYUHgp2vomFvek4OsRWR86jCeq4n711yfuqXG9n8ozEm7cz
BxtOkZEHSszPjJhm4T05oZLYvx+Fw/k3/MDInbKCRxFZrEQTE6wEyl/kzEWwWILVpCdp4oi1JY/n
RbPeSlT0hOIuvx9bp6SDv1DSQ3u3Ck6h3rKjOzemxJV6YdzzspMF8voMX167Z4jMI8NXo9c7QAUo
MVHXhf6ai23qM1h7ixpqK7NiTiN2F+27jffeVvXGHSZSPkkrXOObTAl0q9I0jkcDw8r3njiGnkFf
ceVb8Q7/YgsJ891gnyvemHo6f3QQGHQq/XtewvmZy0P9+AuvF7yqaRKI+XQkSlpJFHPRKvglx88y
opYiU3QVlLUSBT7ZkSNaIESVECWY2a1T3pnFH1mOz3XkfKxmHkg3zDSYrgqUhfyoYI8sC25gibNZ
8qpSDJRql+KW+IN9yekPpz2stMVGWJWiwN3IqpUejNVlUdUOlOxtBuedNhFIV2WPnk63Hr+degOd
eotlvaa2EnEpN8W2oQ5E83+FySI0sZhVolwUzUJ/r1gGPuJ+FMoTlXJKCUokZqY2C3YndW6Vb9cr
MTIXI+84hsD5FV8cfN0j+oVYmu18q5pmsa9XLJewaNRkDSpLENDLDdtbs31kydIKyRLrgp46VW3B
u8U6Dx2NbLsDoFT5baUbNz2PiagzHCNq1KO5xjmTjNrKpbo8OMv7E/LxcHTNLmEs1Rn8Js8SWuoj
q9NGcu1oCCKFH6LQSmRriQYro0GsQBJANR6RIWWpyideWRE1MGcilOoKYlE2cHURqyv1QgRWrSWP
6l9MPDJxW70AMa0ubhe3PDjYnUopK5NqXeF2DV5v4r84uh+q3aa8E6FKA2iDxe5rgxL31MwutqPj
8d5pdUv1W9OO+LuGihCbl6JgT0LX5UK+bY6Wdi+JVUOHxpIfuCAsWXRtusEG9IXJGyEv2IttpTt4
B3NwmHcG86M5WLn9c3C/uhgPO4NuTJJddpBmNPz2KPdzyTPlPufZ6b0tv8f8V9gvR3UMownP6D5M
RgMDv+DF+AcK4tH8DMaHK3j/uw+zgclofMdpP8dySeBhEPoBeiEEP4LlYIIkPNQkk6XkIMng8BR1
ZFqJnOJGwu1Pg9AkQotTLw9Qy6B64rcEskwklkkM6T3s3LEyrUTMKWTLrVCIZabuBJldi8e5SuDE
ziLWmf8MqgSuwASYRE1gxkLdByzOLZD1gPkozgXVR2bIzoUqgSsANnWAXSOwsQA6tFHoCmVuZHN0
cmVhbQ1lbmRvYmoNMjMzIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA0NzYgMCBSIA0v
UmVzb3VyY2VzIDIzNCAwIFIgDS9Db250ZW50cyAyMzUgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEy
IDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0y
MzQgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDQ4NiAw
IFIgL1RUNCA0OTEgMCBSIC9UVDggMzQ1IDAgUiAvVFQxMCAzNDYgMCBSIC9UVDEyIDM0NyAwIFIg
Pj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA0OTUgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDQ4
NyAwIFIgPj4gDT4+IA1lbmRvYmoNMjM1IDAgb2JqDTw8IC9MZW5ndGggNDAxNSAvRmlsdGVyIC9G
bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIieRXWXPbOBJ+16/oR3ArYgjwdtU8+NDMeHOupWylKpkH
WqJtbhzJRck55mfMv9h/uX2BOiw6zkOm4lqnQgHoRqPR/fWBo8ng6WRiHViYXAysDaMEIvwnozLC
b5RBnqRhAZOPg6fHyxSmS2aJYDkdPP1tbOFyORgiZxSnMJkOaFTEMPk8eGeOF/OLYFiEsVm0wTAP
E/NRfqqgDJ2ZT2uY1MuAVlbCB+ObmmnTYBiHqWl0fzOtlKNZzCGwUVgaLzoY2jA3bRCjGBgfT15H
OSjLnV8/3Z1/5+93sv+71uuD5cuFonnEk/eGaKk5vNEruPSJGsMJRxS9D4I/Jv9kX0XiqzIsM/YC
D7yn4iJMXWTJV+SHJCePsHNsri4JSrO4+doGbMsgxQMvr1b8C2hIF1rz38CVqA/8HiTm9vIKHSSe
WVwwmzB/RjmVSKlh/FV4hFR/xI2y8CQg1+A9oshfoFCsFaHNihwvMDlhXWPb6UoXIF1B/gLrzO5o
7+LfOcoyfyENnqGNQxu7FDJ0dJn4a9nSB4XVW02CDH2KqE3Q1qvqGua35G6HsWHTMDPniILC1C0s
LmC6mC/Rpqmpp7er5lMNbb1qK1wbZrioG5pgWIZkcWKUbxM4JGCk1OrTLxhkpZnW9UwY4BAJhM3N
XarTtKlWGGXhC2RBL2Gw8rKICCnarDlTPbadOkzDKM4sDF0Yx3lng7TzrPMmoMNzM0J4JGYc2LJb
gpdBgsB5w98XfI2j0RmGASLwALVEjjQMbGJQCz59NBlYaGBQJGGCwMnKjCMjTAoY8retBxffphZF
R00SVN9t0lOXh65/+zfIG2fjklBdTAn2zu599KNJT7BnWYzTdbS7Lv+SxcnOZwg1hFIQoRUvKBc5
nbSEC4sun2OYpoiLAxhTFsowP9AW8kaM3K9lkVE/ayuVsRrKb1NzTi4oE1v80eUlirCESiJd8gEE
lo6KKEEorm50IcrD1RfhAp+CRIvrgHSobkWgaA5oLO93b9gcK0W/U4V6j1N7t3vh0X1e66H3ey1B
3sT7DBfUZy5Zx0aK1z3lBOpnzzHdjuAA4NfqFq2RmesV/F7NeTgjiybmutEQktXLXSulEVf3HisJ
9R4r9W5n4Um5tuE+K/XQ+61kMZRch+y4Q7aWsfGbI7m1IDVBc9momzwPNL0gLGNzwPD1tAU1Frkk
XjbxrSx8DBwltnOZcfolkT4Fl5SCtcgNS0R3bD5J9UNYYu3cSMwWZSGHjmUz8S/kPJDYy80Xnvqc
XHb19zBARTOztV+11tTMGzET0yVfVFvidPWMMSC6oWLKIhuXu8hwWExcLzKEeg8yerd74R1u9iGj
h96LjLREL3bASAgY7yRP5Vg1rN4990uvxqMDmCxgeoV3x95k+oF/YSXzauWt/pmsnpsrMjRabg6r
hRRnBoYz5x4SyIug4LgUi1LpxR1TNnJmbnlphblLk2DJSMGzFSS6ZZgRTtZMJIT+N7xz+wBUBiq4
qVGH+guvCGyy7iI1OzUCqs5plvnSK5HzzhwKjPaAic8pzA6mOjChbYpdNGlAPBFm0YDawFktBLw7
NyUq9M4poFaIVZ+bRbuCajZr600todkOCw3QirXAftpSU/JBjp7BrQhs62oq6lTn1zXoMTOovhVN
wArridPrhcb8LNwNlijujRQk3RMm+zeKTLeOoDihTLmzdT+9P0bSgnh9kHQ1JtIa81peHORWLCtc
h2NNkJazJvZkeEy3BMfM+erlyek276m8vV69PADOWoxibQGcmDlhMxPEcyPGzti1xKCpMFH+Ffqs
4f6gMFfMSJDL0X3ntUr4HDhcxeisRdLsZtHIiAIu3s6h6MlKD1BuOArB664ngF5JbUI4ZEIrV6s3
LyTqqO6SDO4eifoQZCb/kGfN+gnma1dFL17Cfi6vV0dVoEGDUzriH5koaY5JIjcbaYrae27LhPlK
6EdQtTV84ckT1tNv+UqBU4gtok7gDP4UWziVUJMLU/Nw5WzChqW9oRxIeUOmYvWzgLpPOly2tpQx
MkMJhMRjGr1l/rmcI0yyoQU0r11boSWPs97o8WB9suzB28uiCn4bxF4nvlTbbl/+Um7MJ8FKrKlW
2HSeK7rI0ZfLrFpVwIjDjbX8egwWjMF0ExCUomB5y0SpD45xV2jWLDYKkIjgmEF0cTseowxph3P8
PuOxxA5eWX5qlbqlAFeUVNegrYX1ZiELfiM9/6iwnJBpvLaMCCR45dt6Wqu4T7xb9s2A0Z9KmKRa
rmJJ0pkPbK/WHQthGD4PmEHErbw5tswf5V1zHIv5qe6m3LNl2ugSAggmWBllWnF4kya5mofMuY4e
cgDLaKbKecX74AP/1PWNkJdUpTyL0EBPv/A1WabUJmhlzzg9cOMh50tPjoV9yTUwZ9yyrGYJmHJK
XNgtMWmW3/NIVWp/oenf7oV3r8w037t7H72/1kTRRj925wk6eqtvSG7G7c77cnQCL0Zjjlz5chIt
zG8jkLnu+teb0UsNYBGAb6GtLBuvs6xCZUSRHmu6MDLBZLEdnYjUjT8CR/9oPf4G3/1kHfWqd/RQ
CZsKkSli7G9idEDU9X6uc0YhNul2vOEXUoZFj3YO/VaydZKsm8eyE2BFwHszouyRchxnRuo1zSl6
S0qoZvY+2LTpd9/l4aOdxYfptr9NlvelN9IP1/yH3L9nJNjAQlfabAMbXWr18fIteWOudlh/FTIq
8XEa8oSjP9ZqlxudwntzyukKC98v1EsZBQymGU4uqQ8p5812QjWAXxRS7/7CboJaZ1jWImg+UxId
HVJnLZXyUDYeP/OIxHweWffIDElfb8QYWxfDj4lc2oLYkAkpHLHe1TS+aagZWV/YUuLuSzY/8bUV
QP7uhdEpdAhygiDKPIihIbUocDrn+bStuU3KtXmT1o+aIN0Z3k1SPxZ9vor+X2BuI8geFeZ6Ibfx
p3seADSyx9PJxAFe/EKxVlDD/ajSz/ZIh3vC57FeAgPzsaqO4Co2wUX95eMKu7Mg5weqNfy2o8iR
hjIMMB3TU4boi1sfVLWk+2ldz5aPCoJadiq6qTTL4YtKLhOqEcgC+LCN0zjlR9PdfPqT3q8va27W
aSqNeKmvmCvXxZr+1nlU8+e96XTH3ScLIf8V8FNr5R+egiGCldCxQsfUcI5FncPA4Vew9YzHsPP3
w4zFhTUeir6t2EFgIE8qj/B1Rf3J89NDnH/X7d/n9b/jaYCnJkn3xnJFlz7dT5w+u9FroKRSYH6J
NIUmCqWCk2U9g7d7avYjqhSKK4ls+S4kqqdNtWo0EUATDAu8uzDA9HqhqWD2GGJJqx1D1GFIlJgQ
6JsbLYDNlK6qdL3x88BSS67GWBKuU0wmdN3RZFAkYYJ+TW0EUZgUMORvWw8uiFQUQkoSLDJuk5g6
VKV/I8uMyhAjUqgxJrQk2dnbx3A0GZRhmQGKBh6UCL8kysAWJTITDj8KInOPTacBT2kmNaMAq2KJ
wYyYyHUNTkbj4zNKOiiD1ojj9NXLgx1T2LIMo6LPGkrtN0j/dhFehJkS0S14+53Ne8n99shz4lVr
ZN2DwdgwmPyH+r9E+78wT0vcTTFNXJjuhK79oUV5hVMGFIWeQC5OqjYRy/6KgRJjSaK2iyBGrzvM
yjHlTmzNyH2YUsi6mdHp7GbRBCmna56veAJba1AvZbnCQpua82ueCAuCNTFXwlf/j/SqaW7bBqJ3
/wocqU6tigBBUrml6qkz7SHu10ymB1qmYjWM2YpSnf6N/uLuewuApGIpncnFMheL/cbuWx4/mGFR
BzmN/rRfk3amGaNEpuV3+tylOfhQCDmbOz+NCugDb3SiV/JM7+F/ebYUfQhLkBjO/mXIgu+XTZ1r
NXfBSJlAEBmRy07H1HkaXu7cLnXuSnNICC29gBDTiSHQJb4pGU7pf4I1JB6MVpWFQ9O1RxMvmp+o
usgc2kqVAbAArliClSDgKM12jQY1KtJTgJelYPtS/NYjwbYzbcMC03cZMMOGnL2qOpHhST+OZqvg
X1S2hxik50UOrLTvOnPfmuBTxBKVWhQvPSwNqkSi7lEXuBd9ex1nAkOYxqANY/AZqbBSqkhfRxGF
/DKZ92izOeFKJm+Yy0vJySuow4sFFew7inplNMc+/vNIxtYMjXK1tEZOtHXhtYVL4eeAUEjJDIM5
8a6qOu67GI83agC5h+UmqDrpT+CWQAo35stMCN1pWf604iPJgAxBnAlWIX9ZMJ6rS6mry20pCZzq
XxRc36ahTWDKBjD1eifZ8UwpRdYUj1YDg6SXU7sqxdtqxszbgjnRhKIAlLNVzjEXdTYgvj7xxmTY
mAwbQ+5iyK2EHDcZcc+IB73/LHKuahfQ4icQKqx02/7wYMK+10ZZCeqmaa0YpXk35xuXmL9OejID
x9vWnJRl/6Q3TWMCQbviO2VsOjOibDQmldZx32iO/UG9Ep/qVWXPm8xk6NgvHDrWpzB5DdOG4X5k
MbRbGumz9/yMUeCbrbNXCw6iXwNvYH1S1iP8TXIkvUfxOVQCSAP8thqWmnHNw989xfZRTm/mkmPH
9NzORP9v2uI8X4iKSIZO5fZaQQpNidfKIFJ6HqrR4AlNvt8wElH7aLmqmDt45rxSm+PLQ8Kl/L1F
U1wHn3TflLmzH9h8x+IE3GwWqJbDezTSB3MC+6Ftto/y29x37ecLJnNfWisJ+cVVT8AxA1DFSnGs
FHHhW3lFLBBBGz8TDucZd0/5bg6tabqB2IZJcegRf/YH6QYE3f0u4JTwiw2qltGCiOtTqdAP2Cav
+p2nJqf2/ogmIy3ulfml6U5ifGtI2anRGEIArw6026gG9n0UXrTBSiesWOU4UNAybrHeTeegwFSd
gxATzs226bbQ2LGrZtr4JBaqGl23/RsGHViZBbrbOjVPXnmS40FDqKqjIcOw1zmSk2d5Dq7r6hq4
1tMr4PridRVejuh5Je+rnB3XTmro0t2Lh7BLD6+Z9bLieP6y8Oun32wGbzZ3xPwrc7e5yc338hT+
EEaprWcje9cP5u3vK/Nwg6iUIqjwMOPDjZO9qizid3dzR44alHIF4z4IARvEyJIYvF1WIOy+SmKd
LCV1PZEbCDPBK8FpxURw4okcbu3hJiU7GdLUXsiIwa1EWFUgdIng1tJWpxyutCrXySqI6BVlrRyF
d+q1EmAdeAqQKgFqEFLnc5bEUEoVqG0ytknCcpojVJEARyzuhCjYyi01lBom/Z4Gxcp2Not2ZEkM
5TpFO4n1dirU27lI77H/TUSSIR0XNYxWR6R95KXQVuWSMosqZ6kHAsSCpDxWLS0qGf3lhCdx4HWf
meqkWFAX+VqeySp+01wmG5QSDqo/thhZEkMBfUGsy8mDqDDl8dt7Cv1vAF5ul10KZW5kc3RyZWFt
DWVuZG9iag0yMzYgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDQ3NyAwIFIgDS9SZXNv
dXJjZXMgMjM3IDAgUiANL0NvbnRlbnRzIDIzOCAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzky
IF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTIzNyAw
IG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgNDg2IDAgUiAv
VFQ0IDQ5MSAwIFIgL1RUOCAzNDUgMCBSIC9UVDEwIDM0NiAwIFIgL1RUMTIgMzQ3IDAgUiA+PiAN
L0V4dEdTdGF0ZSA8PCAvR1MxIDQ5NSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgNDg3IDAg
UiA+PiANPj4gDWVuZG9iag0yMzggMCBvYmoNPDwgL0xlbmd0aCA0MTU1IC9GaWx0ZXIgL0ZsYXRl
RGVjb2RlID4+IA1zdHJlYW0NCkiJ7FdZc9vIEX7nr5jHmdQCBga33nQwu4p8aEU45ao4DzQIiYgl
UEVCa/tv7L/Yf7l9DXiIkOVKbMtbkcvgHN09PX183XNUjp6VZWhVqMrLURj6QawC+MejIoBvkKos
TvxclTejZ8erRFUrIgnUqho9+3kSqqvVyAPKIEpUWY1wlEeq/DD6lz5etJfGy/1IL5bGy/xY3/DP
1BS+1W1Vq7JeGVzpmE5Nbmvaq4wX+YluhL+ppkLRLFplwsAvtBNtvNDP9NJEIEZNjsvzIFNCcu/X
TXfnX/j7heT/rOX6KqTL+ax5QJO3GvcSfXgrV7DJT2IMyxRB8NaYf5f/IF8F7KvCL1LyAg2cp6Lc
T2wQoq/QD3GGHiHnhJm4xBR6cftpaciWJoEDr+Yd/SowpPVD/YexBeijfjGxvruag4PYM4tLImPi
DyBnylJqNfnENLxV3wAjL/xk0DVwjyBwF8gl1nI/TPMMLlCekK5R2OuKF0BdFf+Z0Ord0d7FbzlK
M3chSR4vBAcnWQ47flzE7lpB4ZLCyq3Kea0qCNoETH3XdvVyc9a0VzxWnSx2U/69Vu2d8TAcbkwY
+6l+Z6yfa2AXwkvMGPDisu6WwtOuOLSEowFvpFrWVibG/BLmtj9POV4Sr+p2dis7TdupZgXyIU4i
mK/qzp0txMu6qpvfhJoO668jUtXk8PjMeDEo6u9EBLg+C4NcedaPoqw3YNKHhRX7wfFAqsdwQKwn
Jiz6JfUSLhXp1/R9ATql+mh8ATkE4XsAsQkUiQ+20KFv6fRxOQpVo0Y5KARRlxYppZUfgxr0Xdaj
y8/v5nm/G8egvt3cT2zm22H2z2xvnA1LvGsjROd73Pv2j8oBpEjTCKZrqLA9eKPF0c4XJsX4MgFY
8RKBzMqEAiCE4GkhxxNd1QdqgjGVArggS0nxYfU5L1LKzJZTkdF5/NvUBOg5xm0IP7K8AhEYPLR1
RQdAOLf9LkRRoavuVhaCzO8+MpVy+MVaXBvUYXrHAllzla397gybQZkZdirvPuDUQXYnPHjIawP7
w16LgTZ2PoMFhy3xOjcwzU4Jfd3sOWD1WB0o9ffpHVgj1ded+mXa0nCGFo31dSMpxKtXu1ZKAmoN
BqzEuw9YaZCdhMfF2ob7rDSwP2ylEFLJOitFZCS2zwSQoQB8AEX1UUnxkoGx6OZu+tyECCxj42HI
HFD4ur05WBLR+w5+W/jfQZBlmiD8juYNV24cX8F/QNVueu0CE1cBwyPA4wLY3uEQ8fuSFWDkRqIV
EzSrFXmjoVMW4s2W5QIywwDAuVkrAvBMDCCJB5SpkBoLYhJ4LrTTklTk5A31IRaJSB+f+bvOtyl0
FYPO590HnD/I7oT3obHP+QP7g85PCqiCfQO0bipCKb/nr6nLuoAMiRGiUv2KFiYm1eMDiA+oY+VC
VXN0CgBH9Z4HqqM9WZ7yzHn2gwkxi+YIZRAhLZQ5EnpMp5xxX4dlPsQW2FokwmIOrobuFxx3iUGX
QxPrIaptEapFhw6y7ugaotfqJfqf5hgCpIzMtzUTwQvWbKmm6oS0OWSNS4Ly1E3334fFV6ywaLFD
OSWl5DLvaqcQsTOYBAomYZKmrrDbqK840ptK/GNoAtAjbN9gsHZdPVPdnHtN0jfTTAU+8VAj7kIx
LTn5PEwG7KxAuwhuN+eVphJu5uCkpb51ZbCsbIvj1GWdeP+GUwedlpDrPK5V8AZx+iyUXADdg7+c
oNwcw+oGOyVpQpEQYFt9L+0AuYZyDrYeSLj9jCzTrnMxihFWd1j37w9nW5Ij7WATIT0A9xJjKdqu
QRhjfIQEynG/qLh8v3p5crpNfcp9wquXB+oQ3ZpLr8DfBb8Xq2YqbUWz4PaEMREC1nUtPO2m764b
aSfmRMgtwgyiVyR8MJbcA+lcsyznzITw1vZJIPpgk7vRGM3Uka+c9u4M9HH5NwYnuwYn6W0RNRJK
o1y+C7511VDlItjhhCxoC5o4znt8VEJXq19MP7qpR4/PCznYUggiH4EMQFjLJ1DeEEvLZzEVcywZ
mQqnh4Md62CnP5651JHiVZH9hi7EqikCmUQv8XlSOMCygA/SXFpJaaxGc1lUM7nzlLe3zlT1lqAB
ldZOwtPVSm5byRGKyeZ8QTmNATwhAE8IwBNK3owCbsOJ0fp94mIer44wTe8fKOQJKWKFP5c1Sn8k
vF3wwiYbAskJ3i3ispxLB2LdlGs5y/uN2Jlxxv6y7GQOH3z6US2JOAkCitCij+cNDY+UKHPNoj8Z
S+qswZ5rILzR4ES5SMe0c1bjM3qLJCaeyoMULw55V/eWoRfshqJMciMvBz6PysJmlaO6iYotnUqQ
wSnF7obDsNhUfQFCf3X0iMXQmwM0ZFCGAPy5H0bDhWxdzDWoS76Cbpr85OGJHR5FhMxbU5VHaXf8
09Iy1iIeTUXQDdwodlI27ItIQYxUrJCSBav3LL++5e2VAhs5Et5TcvIlNR3KXWtdxYhqhabJ5Hx3
y9WqwUjBJaYC1FTn6MhY79alJM0GHqpYmmR3uDoNszvh/Ts2yfZy79sfLlBBsG4H79en8RupUFKL
tl+w4xP1Yszlib8C9D+PFc+F69fX45dkyUgEwGtrCySiNUhI0I0xsCOBLM0TSMJNtMK8VRt/GBzD
o/XwsXQPjQbVO3qshI0RmSKCqhuBA4K+/7O9M3K2Sc/x+rmhsDwnTs+xoq3jeN1AFr0A6e3f6jFW
dy7PqeYSj3OsvljSoFt+azZt+sV3efxoZ/Fxuu1vlTefsN9A869y/4ERxwZU3iJMN2KjB2mXL5+T
N6EWLdMzCRmRuPvmuBcyT9icJ4QBVkpoDpAgkEJAkrj0sc5EJ9zNLqgJhW7udyhNMXU8NTcu7Uy2
8ABqvL0woVJNjMdnW5j1Y8QcftlAmY7gDaDpjZFh/xPC1T7Ckw0TDipajePbBtsuSTIoUdR5n3y/
Kz4KtTkQov6eMoWdU0BmXS3paYM9HnawPMGNjl+4BbUf5/eh5f9x9D+Io2dlaRWAyaVEVIjF/jtG
1ONRFzTPWXMb+2GQxz3+hlhkuWEJAUQlKuixeWgs+riUX4xBQ41PayyW7MqQCZe8WN+YKMI+V3Y7
Q4GihGoBkJ1Cp5zTS2mTot4SI8HrOT23G4EQsbyPMXi4QRrE0IiF2KGd7a+oP1QhUOoCunVLPQL3
DDii7KbeoaUv9xV9pv9Y6bc9+ratg4z+Uh3EYO8AibzgePndUI/duRfHOrJ4H0A+gmV46XgYfJBW
8D2mQDyjsdr5+x5gnRNYg5oe34bgOga4XmcEAjbO1pBNZniSbqPRfd/RFIs93kPKvY8Fv8CMbzeR
gIyxW+8FK/8Kvv8vXf/jPa2Gmr8vbv2kIOwBsK8VFV+5ebHr5qWwuVSA3p3aN+V/uGXAXXR7HmRb
bn+iHncj/37E/hAar/tK1t0GyZPX/ZxfNtzcV3U9w9gHAHkzgBrW9ceQUE8TPMaQ/ZCSs9tFYyIq
DTjtaKwIROBFx1t411y7rMeqUuipwWcPYmoEbO+JuZ6pOxqwLALcUNfTCgYBSJjTMnO+uybR9Weg
54kZbT1iWFvQy9ZKpcVvpu8YDJtq2jVun5fUcxPi3ReMkyvjJWDkjkwwLkc5vEfg4kkYqMCPAZLo
u6xHl7iV57wVx/CItJubiQVVhhlJZlD4iZXdCJwRxzu8QwRH5Qjcjf1zoGhQgH/iIFVhXgAxOuqG
Xdb31Vb6aqxIiR4bePUWeoIRlcmaOhlPji9OIalABq4hxemrlwc7pgiL4k/Sq6XHbSMG3/dXzHFV
NIpHr5FyK1z00KA5ZItcih4Ur3bjQmujtpxt/0Z/cb+P5Ojh2kaAXmwNyeFryG846aq+lg3jXk/I
9e2qHM9KY+JYEP3Z5ovs6/kIgbKWjWq6Z7xcNAC9wkAvDWUzu43QWMo3UPTQV2fTgwUnEbHEF5rZ
n9CQbL4VqmgvLRh4xbMTXbvjLV0Aqpjd6t6W0udl6uN6kIVb0Fx3VHKL27pki3KhIijWAg0scp2w
H90xqU1Pq3/d90I7s0wYAFT+mLypsQS0lFYI7AVbOlWwN9kYxF7JC7uHb4oshT2mxTQa7x9JmcV+
3dWlVfdgTq7fi8oIhE+J/J0fw8ULIctHaAt6hi0xAVgwfJH/LqEtxKZkBqVfQGTkQ7IV7o3p+m5w
caP7VUwXOu4GGXeJvZmMuqZg2CJQAtRkSLkcfVP3UW4zZQ2HpbUjktFgWtKZei2SezV1EoGdLmyk
FJMYKi1Jr4nnpL3te/e5cxZTfKIE9ShuekwdqwRZL1kX3Bdj+2F+T/gRaTSVrzyIHIVKjb0oyPHP
lfsMkOUpr4i/hw7B7ZLAaka3wnqAzHaAaYo54ennZs+/E39IZESRxMTgY9jK33PC6hXW0PYxbO6R
zWpCvTg4EXtCuOGqM+b+8SiXRzBdZsEdeTY5ZH2j87zEpUiKkm7Fefk58FRQHsfjdBQYdoubaZqS
7LMwwk5jJbtN5CzQLAxgk8ilfkjY1d1Lkns+Bow5qGinMo8omoAS4vXoPvD+ZDTgvyZ5Rb/HB4Wv
pBdkl6nSzdKEfE34gMcEvtL/vl8vzxAf5abuNvvDo/YMKm6aZTKGzyeM3cb6pmmfl3LTS+fPk3Kk
fuPDZ9O5k4psd7rTtc4IinrPKogCiTt1ZFBtvbxG22F/0KgQE94i2TmIzC6V7H9eKnjxxDRZE3Gg
IebVrKuNOMm5rp5NfjIV+vt38BalqA/OJm5h98vXTn4HEZKuORlFUlEa/5nlietqiNuH/aJ9SDyp
DDNVsoW4YBM9JQIR1kFH5W+Z7+IebaOboVDBtB7BNHp1Fo+zrdCnH51FP7io69Btuu1X+Y5RPF8E
em/gpDlFzaK+ClYtO+99wnHn7IiBXD7P47mcQ9sHBZbunfvU9oSeboEhPAOOVTlpb4Rmff9XIk0o
V2vEFEUYA405Qgt6EqHnYLlp+w0t9go5I0aqaQJi95UOHWTGLe7/JiZ5OxXZ8q3glp6PfXW4NfYp
98bYd3W7Kq+muW6FcqgW7DpHp1zbe5VJv5R5y63LhiP/svLb3LfrY+nWDzKNrtzD+s67n9Hwf0AQ
tfXq8CL4xf32+8o93jErFRQVJd14ucsx8VdFXPd3DyJRk1Kt6NwLCJxtJ5FRoMzSQMLTd5Nazkpz
tbJeqEWl5gu1JjIKrCraFbU5rio1nau3cY2ioci0NrO2zqHbiwCeJ8xbUdVpRgnRVIwEekaZgqSQ
pRmV1H4pMgpUhXgKx3DVCIkPJk/PIgHG1DNLQJ6tUqDsy5ghI8xTQq/FuZiSUWaU8NRuOTHNGV4m
2Uyxrhd6V5k6F/VGkSiQNXIWGhFBsGIAJSsXEQUv1W4EKiZJZbyeYRFwb1UzmUmi0QOYOZwjfc3c
YyMsXEbO63qeiigzSXi2tVUduww0VGItVZeBF9dytvBUdhXQOy/MKDIKsLjPMxy06sYMy3rubobX
3qJHosgoUDVjj7ChxBRGJKmzppIE61q8bSp1Li/14PK6nm3pJwHAQTw4iURodiiRkDVmeyKUajiu
Q6NaHu7+HQD3RwwKCmVuZHN0cmVhbQ1lbmRvYmoNMjM5IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSAN
L1BhcmVudCA0NzcgMCBSIA0vUmVzb3VyY2VzIDI0MCAwIFIgDS9Db250ZW50cyAyNDEgMCBSIA0v
TWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3Rh
dGUgMCANPj4gDWVuZG9iag0yNDAgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0v
Rm9udCA8PCAvVFQyIDQ4NiAwIFIgL1RUNCA0OTEgMCBSIC9UVDggMzQ1IDAgUiAvVFQxMCAzNDYg
MCBSIC9UVDEyIDM0NyAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA0OTUgMCBSID4+IA0vQ29s
b3JTcGFjZSA8PCAvQ3M1IDQ4NyAwIFIgPj4gDT4+IA1lbmRvYmoNMjQxIDAgb2JqDTw8IC9MZW5n
dGggMzQ2OCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiexX3W4buRW+11OcS7KI
JjMczp+BvYht7W7axkmjSVGg6cVEGttqZMmVxnEC9Cn2LfqWPX8cy5LHmxTYIkZrAyOShzw8/+fj
cT16XteJgwTq81GSRLGHGP9lVMX4jXMofBaVUF+Nnp9sM5hteUsM29no+U/TBC62ozHujNMM6tmI
RmUK9e3or+ZkvTq34zJKzXpjx0XkzZX8NLaKnFnNWqjbraWVTvbB9Lpl2syO0ygzCz2/mDW6Y7Fe
gU3iqDKBtR0nUWE2NkU2MD2p38QF6JaD3zDdn3/j7zdu/3Or6kPCykUiecyT94ZomXlxrSq47Jka
w8mOOH5v7d/q37OvYvFVFVU5e4EHwVNpGWUuTshX5AdfkEfYOUmhLrGVWV9/2Vi2pc3wwovLjn8B
DemixPzLugrlgZ+tNzcXl+gg8cz6nLfJ5lvk0wiXFqZfZI+Q2is8KAvPLLkG9YjjoECpsVZGSV4W
qEB9yrKmSS8rKUCygvzZxJn90YOL/81RXgaFNHnQYzEmUo5urnxQyiUhJeJKdHrbdptmtUVDFRQG
FB4n65tVBzP6thtoP6PlEjNr2zlGgZGd0F228KbpLqNXdpzhmUZ2RYHdfeOOMeySLM9h7KI0LVgc
sawP8qRe5KnR6TlymtixN1ObpFHer8HZu1fHFIpKfgtHkNlxjj6O8PrcOL53Uo8SWMCo9JFH1+VV
zrEZ+RLG/N20o/Nfp5ZlT/Ue5Xa79MwVkRs+/ivknbtxSagupRJ3cPoh+nE9kG55nuL0Lt9cXwHj
TN1t86g0rY3RWudUDZxONi0aOcE0W6ElM3T3EUypDuSYoXSEfJDi7jeyyHE33zTKoxvL76LlqlhS
LUzwR5e3lty3ENIFX0Bh0lM5hGbdtS7ERdR9ll0QioBIsbQkQ3MjDEVyQGMFvwfDFlirh50q1Eec
Ong8MI8f89oAfdhrHvf64DNcUJ+5nZTIUN2XXMLC7I9Y8CaYAPBjc4PWyM2yg5+bFQ/nZFFvlmhx
NGhhZPVi30pZzP11wEpCfcRKg8eZua/ubPiQlQbow1bCElC5PrIPCtn03TFpnWuk5miuqo/bHM2F
lsioblCQHwElgucIchyLXL7ul0HeQd08NzdC56rIoxXBgcrsFchQHO2Y2uQlr2OdpLrZyE2yFr0K
9ZKkMyrLbiHe85TLsY8Oekqoj3hq8Hhg3vvxIU8N0Ac9lVUIG3pHpb2jtONzBSnNO2zFOaueh6XX
08kR1GuYXUofn32UTt/JvOlCMbiVvnBJTihMuwJhQ9705E0uZQWXspSdWrGlHd5xwjvXN0KTNifD
4Mq0d2UlrjQqDqiYjVwjq+rKtL9ARQnOrMyzIH8L81aWOktYBzmvVLHFmrO6xAXyfAwYpdwwQ992
vRVLsaLGrGP1SnO93nTQzOebVubyhYX+qt2urEtY/BTh6TjxePwjM2nnsBB2zawjyXDzJ6EcxGKc
DgYikh6JwocPCk93F6Cpp8Kwd/Rh+nAIZiXtDTHYl9TY78Rgxr7CKsptJ9VSwdgiQeiB1/RLcMI7
X5+dvry/96WA/ddnR/CCgrLiXuf0u6YA9Wa2kMdCQY8FBirkGNoA0nW97u+aD8sFt8OSg05CujBz
+NAqh1vrcBVDvhVO8+v1QkYYVJQs6mqVBhq9QHfDcQRBdr0BVCW1CUUREzaiWrurkIijsq/P5eD+
lQsJ4vp3gvnTO8yvz7CGnlhkKfrqc2mG2B8TAT800MXV/Qsw7anAY3wWBO1RASEfQ7Np4bPOGj01
D8e+WOfoOdFQXPdM50A5g1yALhRZoInIjXTJBvPrQna2sHMZJjFL2VjmybIEMdvAGn1is7DMd9yZ
iJjD9kZoMxEpKLJzjwrLh5WRGgWmyuXkDzblWLqTX6+RWcsi7kqh0u54J717kYX6TCWkwBPXGKsV
e5tmrSU8B90aTul6SgDnWR+DuThrF594s2ybA4YGRd2GWmnOkmOmU/1xFGIt45LUyAUSwqIt7cIY
3as5Gb5ihkG6Uocrz/DxwLxH2T6jnQenH6IPFx9UfQepHGDwyV8URDMYSfYA9uQUXk2mbAj5clqV
5qcJyFxP/end5EzNKAwQDN7z7F3exZp3E7Kyhqc3MkGT70anp4Da+Xv88Xk3/Np9j40GxTv+Wg47
IzZFiq+EFB0QD/fR/sQ7RoiERejkOBzdb8RVzyARBu/NhOphxvU3N1LBaU7llZIwMfP3dtem36zL
14/2Fr9Oth3I4X2vqeC2YKTfXPLfRP+BkcQGFqoqyXdio+hdm/ZqP8pvyj0YC5iGjHLcC5knYshT
zn5BNg6V0im8Ny+5XCEI+gF7LDYZxpo/YDtlFKHxg1WHa00WMswFK54SnpE+n2B9W/2CSIawFWxb
4buaK4kkiQh6ERZOUQI+iG1OAxTre0Jl7UnZlb7BpiniQcNosxB4lRqyKGUn9vWWxtcL6r93CseJ
I4W/axVfYq02s01LzwtsRIxpqX6b/sH2tscQiZGXET2SIhtj7yIKPcLIDg8/fg5q7ndsC0mj4PLS
6BT6PHKSR1R/nxE6wrx6own1/1R6fPQfpRIq7s0//6cz6nldO8DUOdfcKgnqf+cWuD/iYXRYHp6a
ChCFDH+ikmMolbuhRBD5aZVpShzH0JfShuuwYOJIqvEJ0yl9iNRRKaHBrG3n20Ok/J0qSSPtNg1p
Kng/etWIMpEaQQrHOM3SjN99TyrB+nZKQNTM51TsyY/y1RYL+uAJZZMLasFGoa6RIumjvIXmsBCX
N7NuYccldo1P+krSlH0SnfKs7W6ty1H69eYjofWpIANpjE13I40CTi6R2PR95cIGRSf1qPSRxxzO
0FSIQeLIlzDm76YdnRO1LHuq99hS3S49c+iVR48H5rFXqivyw7OH1ON6VEUVPdli4EGFLvFxDg7j
13uor6T89A85p7iJQENmJhbbf4WYCBFZoWtwOpmevKVQqtBktex4+frsaM8Wzmd3Ah3YQqnDthg+
LswRxOVKTdhqe6cfpg/bw6U79sj7mDVJZOu/UxH3WsSjIqvwNJVw2oV5InQt8uSF0ukGZEVMZ4JO
Ey+2/RHjKcVkotq55pQqKMtSzsyVRYDmEY+RfXOj0/n1emEzgqsy73gC99ag3cpyYx0m6YclT2QL
lixvLmVfy+Q5bG2pfBr5aZ/x2t7NhBQx+k8lwRGcZxoKCaNknoIwWOveoMRalu/du/kqzSK8j8yi
HJX2C5tMdR8W9f6tMFUhEcoz0tW6dm75Z98ND7+nXN+oS/Eh90FsetwnqDnG5FJoZZmUklFnKT2A
ywbCUiXDsu0gHIVayyoBdNwzthiZVGtJvM+7XKjKVlySpcrqnbKHsHuEvZpqt5CwV927dot2Kalp
J8TthHeu5c4b3rCSSQczaeZ4cbsJ9rq1LORiuYQPLah6CLj1CpUpHJtH4dyLC15q8MQBFmDbBtMq
BCIpc9aAYqIkr3oOP3QnPw5TVK1Wf+kULbMk06RmyRZI9bx064xh/jhhlVP2dY5E1Jk09qJvP2nF
ogpfuMu/odinvGKe6DbFBcw15acF37l73cNxdAD4FFbM1ps5KOZo9zovAS9+lIVG3Vzc37dVnyfm
HzcaGeQTNh/jMLiRLYuVnIQGdEGS+kLb+BLCyStLeSXclpg2OdaI9Ua0Qp3wOeT+TXrV9DYNBNF7
fsUeEySC98t2emyEhJDgEokL4uAaRxg5tHJCK/49783sOqZqIqReIntmdnY8H29enn/bDDPdazHT
njEz5Wm7YqAy0wCqlsXegIfI69RpnPOwvFlhxSzN+1+qFYAJMgRW4UPUt0YfRnJYtCcKVyHZD/dj
MmiUH1Gov0bdpJdzjThMhFy3HFNAZEbKtNKdIEhyNkkfk9n/5tO/Mp/8x5HaLuZ0lgiH/RYlm1yR
Quuw32/Zaw5plIWkg+d10uo0eC6/mvaHIAUOs6NQi2bsjD5yBMulak/qjKMXJ6FpBkybPjenzmS8
ikmvbliRXIwydTtX355JpE817pS32oy1UbgoHPdDczcAGT/ky580dA1PjfR5REtgHnJesr9ehceX
R9qWE36l9S4gLRud++dh6KRVgiCkJ0JWuOvUJOmpv1eJIXIAxgFCXFttcrNfEdZ69Jdfts8aBrLC
uimSicNpHJ/xwch8d2O+NMPvFYDEiGSPONDArCRZnafsrchG4r/HzqlQMCt7vU/lP0jXdxwW7KbZ
TmBcshPoJulN2wwtbxz4lZ7rgFrT6NUCsY8MaJSShOWfleVeA0fTHvDoAI4dpiWkq3Mgx2PPQlYC
b1UC2hnr9P4a61TtFdZ58bg6dzNWWXi+zPUW+H7h6AUVg6LqWkQX7swGL3m+pnu3PUaz3QkFLsxu
u7DmI2DjJwzRU0/GFuaT+fqtMN8XtkZjwk0osf6cOSx8gbUQJsGw2IlNTVHl1iBHBwhIqWc2k0UZ
1q6GYP/m7LkoSLtnnlXwj+cCKZw7zibZwG/w/0z9ehfUJoIClvSbBWwwGmWBB/P3cwsfqmRRbyR5
ocL80SJEr7FVjFFio02gqPbMGrzUdrKpshexqOJ64zQ6sB6RRSBDyVxlAf+uMDMBsfCLXFno1REF
L2sVpKspkjOxVCcRaOfCzGayQMJDSvhfAQYAgG+55wplbmRzdHJlYW0NZW5kb2JqDTI0MiAwIG9i
ag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgNDc3IDAgUiANL1Jlc291cmNlcyAyNDMgMCBSIA0v
Q29udGVudHMgMjQ0IDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAw
IDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMjQzIDAgb2JqDTw8IA0vUHJvY1Nl
dCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiA0ODYgMCBSIC9UVDQgNDkxIDAgUiAvVFQ4
IDM0NSAwIFIgL1RUMTAgMzQ2IDAgUiAvVFQxMiAzNDcgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9H
UzEgNDk1IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSA0ODcgMCBSID4+IA0+PiANZW5kb2Jq
DTI0NCAwIG9iag08PCAvTGVuZ3RoIDQwMTQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh
bQ0KSInsV9ty3LgRfZ+vwCOQMmmCBG+q8oMus2vFa9nx0KlUxXngzlASs9aMikNZ9v5R/jJ9Izk3
yvYmm5KSSFVDAN24dZ8+3TgpJs+LwobKquJyYq0fOBXAP7fyAH6DRKUu9jNV3Eyen65jNV+TSqDW
88nzH2dWXa0nHmgGUayK+QRbWaSK+8lf9elqeWm8zI/0qjFe6jt9w5/S5H6ol/NKFdXa4EjLemp2
W5FsbrzIj3Ut8+t5KRr1aqmMDfxcd0sbz/qpbkwEy6jZafE2SJWo7H277m7/O7/fqf7nSq6vLF3O
55MH1PmgURbr41u5Qhg/E2OErBEEH4z5W/FH8lXAvsr9PCEvUKPzVJT5cRhY9BX6waXoEXKOTcUl
Jter2y+NIVuaGDa8um7pq8CQoW/1P0yYw3nUS+P03dU1OIg9s7okNVa+h3VKXqVSsy+sw6LqBiby
wDODroF7BEF3gUywlvk2yVK4QHFGZ41sf1a8AJ5V8Z+xod5tHRz8T7aSvLuQBA/aLk4B+Qk4Onfd
tULbBUWQ863eVW1TLtdgqhSBgAA5Xd0tWzXH36pRNctUU3GjahVgvqnmVf2pXl6pl1OTgJmP34G/
ApAX1D0xXuwnWmRgdycCz3ghgOj4VNRfqVWjZsenr/wdl8D8OIewB/UoSukG7A7XXSFyfIUClkoA
KVPjOT0zNoKNuzF18f71CeJXxO/UkYqNhyfxAROJjmjbaTGxqlaTzPkO/J3kCQHad5ny6LepJpdf
l2ZZL3UOzh1uyuMw9cPx6V8Rb+wNQywNI+TFvdmH5CfFSIwmSQTdIUjDnjaDWBACfst0ZQKw1iVS
SCidpgIjW4jNJVgy1vPqSM2QPBIIa5yCPohA+y0PElgXTSlrtB5/64qoNEMCtfCR4bVB99UsuqIN
EKi9FOCR63l7KwNB6refWUt1zMGn+GjwDOUdL8gnV2Cszu+dYVMg+HGnsvQBp45O7xYPHvLaiHzc
aw50XeczGBCfhRshEcN1z4n3ut5PwJJTCAD1Q3kH1kj0x1a9LJfUXKBFnf5YS1zy6NWuleKAkvKI
lVj6gJVGp9PiLh9seMhKI/JxKwEF5GGP7J440F5opdl7oqlIkBqBueDutu/+hN0MicMChI4URkJK
EGIwgnExtSRMnAz7lCoAJMo7lhOTUmuJRUSihVQTptSkWw9YlbSYWhH3uf5EIzUg2OrlFYtfTo/5
HN0p5Q7TY2S+Ydjju8joKSu9Iu/CKki6GJbpoIBrvqIM6e96PUwgkY96naUPeH10erd4j4lDXh+R
j3o9zqFu6Z3e+VyS+FvOBe/hnhExW9QNvZlNj1SxUvNrA2w3/wV+VYvtsu0I5d6QZa8xkVRLzHwe
2e6Yx3m5QgbJLam4ZRj2oIZKKf3FQ/ZjlW6MztbteUn6K9yyUQg58B3ASbdrzmItjS1QDqDJYSb2
r1Cv23IG+Mn1BWfyRAD2yTCnW73Y3qrBBM11LBLmjQkxBlRJmAgUhIKNk2RIx31FEYmJF3gwZFoP
eLqtlwaZumxrXDHDOpsGFAUQaa5v+bviDxzAUdyUstJia7xar9EvuEYlS1ENA6s7DBMaWvsUhCHU
Mjz5jj8sxZA8NAyB2QkaiM3tY7GOnKWmNMJDV3If0VMtZUWnr+XiascgIt60y7D+A5eu10gYldyz
3QvSIBqNUBA9EJ6HJ/Ka4RC5kUP23Zl6WD4em3GGul1wZj0jh314phRJKRZsRGExhU4Itpkiy2YA
Zyc0h4PqlHTfXJydb2ufI2vHIDhSEF9osjUVoPy7Qi6Gd13ND7kYH3IGSw2iZmRILm5C0W/Lnz/W
ay5qr0kRgwfwoH6uZIV7A0wFtREwQ8VrLW5XNbdag8/HLtDkPArfWlSt3vNAzQuxMu+izsUkAIwF
5Yv+CuoLhiZCRk4qm6pfiSeoebtqWsJJ8Qd+gg3PGivhOv9gUN8yFZz4CrIeeBXuh3V6C8ZGIqTP
NWtV6m25NeC/Lj9LC48C7sNMVbEOvS4w0dCLgtVYwjs0Cl5yFis/NBsfA+xGGlvq6kTxqCzXb2nR
loNpsYxpkA8Aed0KV3Jy2hEjFPA7XGch1ylZvLU34mBjoZGjbe+u1ncsncsWOzuWWz4J++otkOqN
MnPMaSWnzJxTVsjxbACRlBAAJ+VP1TMKPmgQPQiXS6SzM1kDgiKMu2ogF5CHQyrwuQxJAQGyAy+m
SlCRUifhqjuDlIBpZusk/FvT1itW3uWnGF6i468mkY6z1Pj0bvH+2eNi1NybfUg+TlRg0Y3Sce9R
NP2LvGqoOLQ7L57pmXo9RZ5ymn/J7pn+caq4L7P+9H56QRVZJAtAdb4JjSjqwxVImjdekvUZh5o7
AMJtbgHHbfzhu2u8NTS/Ve/hVn9A+uye8uS7FiNbRJAHI/BAgDXHYW/szX1PpXsO+QRX8LolNooX
WijvFxIy/KCnCGXm4EQz6SfCxlBwGGAA4Mtvt+6/0tod/LbDbdRpzvVXJSAFnbV+96P/PgY43GKQ
QALJbbIBkr3a4jccYdYlcoGRbPJVGD1iC58RQYRSJmVaugAurjSg+QIKC6ufKelTqQSVaKteQDoA
9O86iB0ApJrG+eCAPcTtnwnqH4tJh0q1iIs/SJYvsABJqb5BkhRIe90OcBqX5Dnu86gtrYrI4/s1
fL/PJqfQhatV2L6tsaCTcIW8F9jw0V/qHLhcz5vqBn2TcemB/A5vKklAWLtHSEZYHVHxl1A1EOhT
kmARiHbYe07+r4XSQNUDoJ8SVf8f3t8LbxvQ8wsK/GNc38EUi9Xgq63nwFMKAbRGSJWHPBJyzSUJ
PAQDKosF9vAuCvUdKbAa1zDwJhyVwfOF3hhOllQIp4ReplYM/LwoQgVWuuwL5icSO1utb1PcL3N+
U0nT2S1ju6V+mkWW1/N6C2oofBam+Dsk3dxPUpf+N/L0d9P0UFE/6usOLfztLh3xnYiyE6ZsB5S9
EYqtRBtxX0pR1iCTo8oWlw9QeNR2+Le4/QkzjE+tnXgPY98Gmdt4J0V9JKd8K7QXVCSMmJQQA1kP
sxxiIUK4MFhyhooFqASgL2CJNsAyWM/rNkb0ZLjV0yp20JwD/KMwfszw33F55EeJ3XC57Twest0x
UKA+I8c78Lh0Vb2GlEt5PYUUDCGC3AAJQ9dtWy2MFw/oEi/nvstsvpFNkt69+rPChDIcCypHyCuD
KmICayNEVugAVTcmwQIsBOCt5QUY+XEeuE0mfmLJqKee0thILxZdSSMVDvER2J17UnHeGMjBukQ6
psiM9S/EydVC1VwvlfOOuz+x5Ikx9UXV8vHvTZhgDd3wDdWsLUVyJzaZX/ONsTD3rdSLVxu3nhaT
DGpqQEIM3BSHCqgpUx79NtXkEqVZ1kudA6iHm/I4BAc9OL1bHJDI0gg6ebI//aDCSQFhkmMJFyhq
5IBcB5FiMwwfhPDNZAiIjqM7Zo71FGMi1zNDwcpj6mw6O32H6II1cAw1zt9cHO3YxOa5H2RjNhHp
uE3Gp/PimZ+I0JLxdiYfFI/bI01RV6yxwSTWFyZxPZPEQjoBVa87TIOOyMKB/5xDLSIdoEWy7A8G
cdcYfLOsKMpSTG4RheoSayYHr1q0bqKlu7hd1SYmDFK/pY7aGlPVmodLEwJ6f/5IHVYBRnX6mvUq
Ei/U2mSyTsmf6hmN7eyMxRsUbGccGkDXsQDBwiWkq3iBleh2l1jx8Na+zTfdzP8n6VXT3LYNRO/6
FTiSnYlCgqBA+uZoMtPW0xysTC6dHhiZlpVSkSvJTvo3+ou7b3cBgnasyYwvtrhYLHYf3n6AzgMs
alHX/mPINPaXXZ2ealbq5PKKTYZKd5vzv6fX8KyYcU7YWPQbuUN+f9IUd7rj/xhKKsQmYgQlv045
ksNICWkyXTZDfzJhq/molZZnoIZmIGImyi/c+55a4TmIi7SUID1TdDAIzc21PlqxRN10cuyRcGmy
OcffZkvW3MuZD6zwVT5OZr1/UPf7Q8DrW85ObofBfO6Nhrc+9HqE+hS23czDvssNizraAWx1snXl
mBbaR4/c7sESKzdayo22Sj4vbHNKvkX4BLhALOwxQ04VRg2d+LeRf3eiIYjDQiX2aepECAR5QVu+
i9Zk51Y66Q5LwTQjz6r3W1Y69KbbiKTTDeoTTceg7Iccoy64xt3HJ333TPDEX2xb5si/K/6dcDhx
XAxTJQmUS1DZTxEIAYSjkISOiZLGPj1lL/4cnoCZ3qptYp4k4x7mq4/KOv2karzueYyoeYxomLJt
dpMOvmenrusc+Pbr/eFGMonINw4x8VFJha+OI0+3meodNVnK7J8HTam00697o5PA9qvsNJ1RgVTD
jY5Egwk7ZX4SawM/dbvT/iBRUUz0GLFPi0vSbOwrm411EaaFwIQs99kdc6dfK+3/5s+YoDmXvosc
79EgvOZ9uJQ646kcOyh2LR9eDUudcGPJcFwyMFTijo88VbMNA/qgDIuWEOCRfzOYrS5sJr6tkEY+
uLjEZVaUA7jdn8W0ei2mcTIqqoCpIOoDohUjSq3lHd4pF5Kivx25zQs5fUrOlpshCgmz02eiyez0
U3ZWqsj89MrPiqHy4Genh3Sf94+i8bOwuNfC8qwlpq3nvu+SBqfe4eeply6kHW0dOpRIZfOTjhM6
bNrKzK/vtWleyrGhh76TfH9/KXuDWHrqpfS8q/Eqxj4qDsjfjiWbnkjNpG25okQXRCm0QHM/dHQT
+1s+YkLcNlM3luIViFufJ24Zx3AB9cMelDr1F+ZTNzzkoAdLboVwiA+DeQXZG5Yd0MQr6mKeQC55
OKMEKxHRTpvMm4Lr+AgzjeDS2GFG1+luhjVOHHBHFXo6Vk0nRyPN+0c4dGCMXPZvXrZS2mXwAE3B
bQLC6dHBkeNxC2Q9l9qQysnDofHnHg6yeubh8OJ2Mb4YXwYF3c5istxU40vq2d4XF+GXLJ5z68cH
h/UfGz+/+nZ5rM1yxe+ZwqyWs9L8Tvn6hRSJW99MWZg/zJ9/FeZmBlQWZMgtmnlpzW5WFdSqXBQM
sxXrNBB5CwR3JMD7KNGJGgs3p24/zG5/GS0X5JhLLYtgYrkgJFPDQSUoVC1QinYtRLYZ7domCmAX
ooJ1HEAhnXIhdoJO1Khs9BjaEhZ1aN4VBJaxHaKgasupRuUa0ShbunaK2rYUfXKwfHPMbS1bihKX
vYsBBZWgYFvqbiHoYNY7DTrYFUFq2PpGwVS7QWVUKAKYjsJnEdULdsYR0K6JAtiFiO2UBYdUFy7d
MyQKOFjsNpbORJDEELZrayasCtguiVgH9QbUc5T6C5foRA06sbJqWQ05okrLlvUoFaSWHeVgm1qO
OlHDe2EwLNcVK9VWCRsEltioPv8/AKUOpC4KZW5kc3RyZWFtDWVuZG9iag0yNDUgMCBvYmoNPDwg
DS9UeXBlIC9QYWdlIA0vUGFyZW50IDQ3NyAwIFIgDS9SZXNvdXJjZXMgMjQ2IDAgUiANL0NvbnRl
bnRzIDI0NyAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYx
MiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTI0NiAwIG9iag08PCANL1Byb2NTZXQgWyAv
UERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgNDg2IDAgUiAvVFQ0IDQ5MSAwIFIgL1RUOCAzNDUg
MCBSIC9UVDEwIDM0NiAwIFIgL1RUMTIgMzQ3IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDQ5
NSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgNDg3IDAgUiA+PiANPj4gDWVuZG9iag0yNDcg
MCBvYmoNPDwgL0xlbmd0aCA0MDg1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ
5BfZctvI8Z1f0Y9AyoQxg8Glqn2wJGZX8Vp2TDiVqjgPMAnJzEqkCoRW9m9s8hP5y/Q14CFCK3s3
KasiVREz0z09fR/H1eh5VRkLBqqLkTFR7CDGf1mVMf7GGeQujQqorkfPT9YpzNaMEsN6Nnr+/dTA
5Xo0Rsw4SaGajWhVJFDdjf4WnKyWF+G4iJJg1YbjPHLBtXzqsIxssJw1UDXrkE46wYPpTcOwWThO
ojRY6P3FrFaMxWoJoYmjMvCkw7GJ8qANEyQD05PqTZyDotz7+u3+/gu/X4j+l0bFB8PCRcJ5zJv3
AcHS4MWNimDTZ6oMKxhx/D4M/179iW0Vi63KqMzYCrzwlkqKKLWxIVuRHVxOFmHjmFxNEpbB6uZz
G7IuwxQfvPzY8RdQkTYywb9DWyI/8EPogtvLj2ggsczqgtEE+Q7p1EKlgelnwRFQc40X5eBZSKZB
OeLYC1CorxWRyYocBahOmdfE9LySAMQryF9obLC/Onj4v1zlvUAaPGOUKM5tAhkaunReLGt8UMSl
SPW26dp6uUZV5eQI5CAnq9tlBzP6bVpYCAyWqw7aRjZNB+j3bTNrFj8vlpcwfXHyEi5WLdRLWN12
gtTVyzkBqzBDM0zRCufP4A6tGiPwI24Xs4/9vqYAKwN9S18JYwpLfqtesoAmjbLYOsAYM2mW9dYq
NtYqRK76KnToNijBkonVXQMkKW8kyG94vWo7qOe8lN9Wc4D8RnueMiYWyqKAsY2SJE+IBXnYedUm
TlioULYMPXgSjkl+k0RZfwbn714dU1wp+C0cQRqOM36xQETH706qkYEFjAoXOfTDrEijFAMtcvg+
/7bN6OLXoUXRQ51Dvu02PLV5ZIev/wp4621UvUBtQvn63u1D8ONqIHdkqY2c2yQP26fzOFXPRb8q
2EkyTL6GfEU2bYNKNmj8JWoyDWbNEUwpqWWYbugK2SBB7DdyyEE0b2ul0Y3lu2g4xReU2A1+9Hgd
kvkWArrkB8iteug4RTeedTd6EOdR90mwwGc04eIqJB7qWyEonAMqy9vdKzazXAYHjCrQB4w6eF2I
m41ND1ltAD5sNVtEpfU2wwO1md0KiRTFPeN87Hc/YvaeYADAH+tb1EYWXHXwA4YqLeekURdcLTRR
yOnlvpa41AxqSaAPaGnwuife6/CQlgbgw1qKUaTesb2OtMxM3x2TyLm6aY66Krd2P5JfOUoaBvVw
BBQFCbuPYUcMC06iGSVzcTXpScjJbgnKmR2/S0o7fYJH3yPgig81z2eeLCZghEm+D8clUvwZ97ok
0CWBp5LOXmCRTfThl7z2fn/BgvATVCnoDnPSCSF5sqsJm6nOCRMrCCF68achlQksJErzjtJqguWk
oHJCmLsAobZmd4kfUTYk6TfId4k8lBFxR3WEVEA7qNkPbeC3Wmb4V661AvKICgL5tlRi06AWHK1D
WILkkXo+P1R9tvzcpINOjqAHPPzwRaHpNs6fOAr4vauH4YPuneaM6/27d3CvY867ZfAupBxN/pv6
o9fTyRFUKyBLUjqf/cRf6GRfdzvWTdHs2DVgDVhKgi/Z+VJ2vpSdL91xvpKcjy6I+xFlckAyEjlf
Ic5HyV6gc8FmFyRkccKUehmkeA5yiYIkkTZF0Dzt+qqjThvVZ5UgNSFq4zSSQEUfWuhX+imRnGnO
n7H5qz+I+npFWlUkqiUj5CV/vKTS0VEOwReiEwp+Us0tIwlqF/IgMBuGYV4gKNFokd0bWeqJIM5l
s2B8fe9SOOkUEZRDNJxiNzIerTtWNBbSpSIsPC8qTK0X9IN6JJ036zWqy0sqqPoWZ62m24+YNBcn
PRw0Ch2Om+HrnrgrhkNnCD4cOkm62/WUffCYreCxGDb0O+EuQ7pKizqYUHbJ2T+L/hBOGPf1+enZ
LvYZ2cIh4Agwbpw2N6n+cqiYYLaQUdfRqIu+WbK/EgI0akPZdvWHqwX3PxSXhIjpMJjDh0bv34WW
SxVGayOU5jerhay6MOFOTOyq3ADNohxwd3KwEEKCLG/AmSrEx9VGAPgkGLU+5ql/Dq2RPG7YhwTI
SXgr2txmVhXFz96HRMrEiHwckcZSlKZt5eySfpqQ6GOmR46oJtERzGtK7jThMHDBG75DaiByqIXN
oSDDMaxvaTtjKjsklR5S4jNsW3mqnb4IEy68BRdeWsN8xdUko/C0wS+Cqdc5+CmmrkNurJR5Jbei
Cy2cSp+rwlass9xvQWiTG8Q7zCtnIqS/lBDFsVDnKpgEn7buyEdvXofWcrLYMojt5ytqKzX9kTuw
M7neeU657jpiMun7psRv2XmJc+HbsG68U/VukXFn74KaPa5UFEnwTj3KbSV4RfAzJlG/kblSfJI8
khoy7vG5g5OyQVOBlwLYkclP+FxOo1eeoU+yp3KJtsJXdrhnobCvU1kwe/dlz1ALx8GcUd3b5ggj
ZEvBid10Q1Y0zJFOXQ5ww4I5H5ggF1LLhXQrqMglFtIE6r0P97KxSx+YZhT6QDYevC7E3WZaSfMD
tw/DB7Oxy/PtRubeBDr5q46Q3I2bvfFycgqvJpSKXSC/7IJF8P0EZK+3/vxucs4+mygBHIV27JJs
7JLow2SNRDNHIBsMoN0Eivbd+qMhd3i1WT4W76HVIHvHj6WwtWJVJDi+JGiA2Lfuth8tYx0tD1J5
h8FmsGYSjbEnsjcF3K+x74OJ1jSuNFLYst26htXg8er9Latd0zyOtR33Yem8jv7r7P7eQj+0EtfA
fr002ZZrFL09bS/2l7Iw5apC7ae4jj6yP0A+Cd2ecjpItO/LA91ieyXNE5Y9PZrP4TssCtg0KYDq
RoCF7DvA9kf6hC3CPjTL1BQb/SfZJl9ppZanUhlxMR1kgT6EK/XWsaeDdSWJjX1aKgaokrHohxoC
7m2kq0WFNbS+WVDdJUnjbS/6JoU6w5QdzNrmmoq6zGzUKKNAQHNHQmkGnUObEIZQEuIWh+vPCWNR
O0JK0GT0TYoKXxcdqz4m1KLotIYK9Tdq0a92U+e+XTf9bYmtDHZs+LyqLGD9v3gC8dmvIvC8F8K7
xbbPuK0+yfRNq9Gm9S3mYY5pGpJoWsFYTTF+x5h/afCiPhS7+BKROhwJ8Z1/hjxp1P+CTgHXWBst
5wXLd3cVOPZckB6LOH9qqTzaU6o4BHWOgx3jtysO+7vFqdLITFnSTPlJFpTMLQ+TS2kiZbrLZFw0
ON0JInAFwAPZzppm/lRKmV+dNx1Npi64C21Gtan9SUSbdrVCblUHM1FTrTIveXep7fWTa6wfkSNr
yo6IjIENn6nkm4H+74mUBV69D1p2bO5NxinaV7uZBVk70YZFfhdcAFeEuyPlptM3FOgzlHf6gqg4
7HBQjS54ue0QTyEtaMiHRlI/ObW4fUQFQTo3y50bgTqY9cumBdBZE7TNE4gmiw6ocyAwU9+rCU8q
ZvZWj0O8P4x+1eC5V3vyKC8SI/TGvQYDHE/nYfUPnJpwhMpdfnAw/T9QMctqN/Om7V3rMQQxB1K9
K4M30v3IcGr74dRuhlN9dCv3PR13/r1LwKQaFZj8MMm5AtWGpohcAWP+bZvRBUGLooc6h8OR3Yan
FpPMg9c9cTwSqC3LKHb3rx9EOK5GJRPGf16UaCwXZ2DyHLeUna8lT+c+Y9tErEg6SoNJiANdGUxJ
UbmewelkevKWNFZi4q8E4+z1+dGeTkyB/fSgThQ6rJPh65547EXG9iS1928fgg9rJPsP6cWy27YR
vOsr9kgWDbMvkkvfChU9NGgvCnoJemBE2mFLmyopx//RL+68dkk5llAgF1E7Mzs770d5YZEqRXRm
CqwwUIq8jMFFXTaSdlSElOClVBngGOyal96nvDSerftLjrPXnGuOK4NtF9qywy0DupHBlQSHTShq
mRy70zTAxmLi+UwHdQFT/cLgNsd95PNIByaB5u+zL0zXE7pTSx6ET8uf/keCvXoZBIST+pnHQ8ia
UoLBgBJyVMxgEtqoxMTgi3fn/6VZAe/RNMIcBfcvmUx0vy7q5avqIELuPxDL2Lbvc/q8dsNbc4+2
Ns00gX1IUwOMCLRN4CiBCyPoxmBUiv/h8ogllewVMkGrsT+reFV9pMfLzOEIEbJ3UHMbkOudlV0j
ceHF09Di2axvMs1pmPsCJhuePRAFs83FswvtvAXp38CMg5QTv/lMBE98SPOOpXlH7PWSk5DDOKrP
vRL1jnMvT4hM8VpXxHs/PRCohRvbKdEli9ZsURlUeSqFRoRqNtlwxsgDT5YYaw7cy9by8ajOk5Jr
qh1BXkB7mcocRHaveLGDBM9OE1RwKPI4opU08+GvmnDfy9gfDvwx98d++MqHHGNoLtTvGCFoPtic
yk0UMQs2Qi2PdmhGIDlg6whR0D0N2R9yCtE1BjV5OovsH6XtnHqwPKEn5jYn+b5dQMigIRlU2j83
PCMNr8nkyOphNpcZKhlIySbriiux/808L9PzcZo7FgoMEDUi+WsafmnhKGWwbh8u6dYZ+Z9niebt
onnslSyiwxPfVK0SABeiByZsRxVvQriAaZnbmKPJ2/M0s1agU9C1fa3bps7b76zzNjVRLU0UlogM
rQPWOEq5/JuOKTPAIdldjsEcQWBackeIi0lNlnKStZ6YcnLWa57WlKcDU27Xkpqjx6W1xEXuamL8
Guw1Wxaq6QNjKHw9S7kHX0LscoNCbKe69tymNyNvVlNkYs3iQ+3I7EFUhmBuSjJWsoqu0sP4palY
3fAeb6MxRtHkmKUlrWl3VFVLeO9LjrVkWNSxXaBuLdA0UUoL8WIwVE58ZSS79FRcGsBVm9MTsTi3
5wHTNMhZLXK1P0aW9zkm/ECsjsW23pnUQUxYZfXoit7wnzsoDRDnf7TjMyeYEop7ToCPVNmoTXhq
E4HbhKM2UVObMLFNGE0ZUXNmaSogL9jxKIEIi4WcWQkFWGg88tsjOKdjJPUum8TASOu/soAzmdiC
s0yDvpMSTtcWjB4rIgxyWgZR6YkYFK+Hxrq8NTQy9sbQePV6ZJ6GwsamMVnQwSHkyt2rSJSLkbfF
euvhiH+b+W3s+/1Sqv2BJlmtDvudUb9CXfoLCCFPXpTR6jf16U+tuh0OwzjaeufQOo87p6FO+gQY
dweiCQSqcVh+BABOxhuaRGEbfGHc3f+QOLsGelrYcBbAlrNrIBf9hnOiSRT0jZwdEdkayjgxRhPG
M/J12tMtWzXM10GMVn4lSQSw7Hhh66xnrcC2LHAE6ApdNO48+MoiwFfM1mvH1mMAPo0gMkWpWbim
YiaRJBFASAR+OfK1ZF0P+Rc0n4ijMaxuiWuIvBrJxxXtQ2EqYVg6diJsf4EEFQCaEy9F1RyY0lQb
XV1l2KXRWxZcwz5nd/J56zzcKolHdF4kWQmg7Itkia2DcN2ypfMFW+fx1oatkCQCW7GoqLBlfzod
WBZfc/ohQItnAETxB77X6F/o0OD8DU2iwJlVfPPfAJPinZ8KZW5kc3RyZWFtDWVuZG9iag0yNDgg
MCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDQ3NyAwIFIgDS9SZXNvdXJjZXMgMjQ5IDAg
UiANL0NvbnRlbnRzIDI1MCAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94
IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTI0OSAwIG9iag08PCANL1By
b2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgNDg2IDAgUiAvVFQ0IDQ5MSAwIFIg
L1RUOCAzNDUgMCBSIC9UVDEwIDM0NiAwIFIgL1RUMTIgMzQ3IDAgUiA+PiANL0V4dEdTdGF0ZSA8
PCAvR1MxIDQ5NSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgNDg3IDAgUiA+PiANPj4gDWVu
ZG9iag0yNTAgMCBvYmoNPDwgL0xlbmd0aCAzMjM5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z
dHJlYW0NCkiJ1Fdbc9u4FX7XrziPRCdiSPDumX2wHe3anayTWkynM00fGIqW2ciiStFx3H/Uf9lz
AShKNh2n6e6snQkF4FwAnMuHc07yyes89zX4kF9NfN/1QvDwn4wyD79eDEkYuSnkN5PXp9sIyi2z
eLAtJ69/mfuw3E6myOkFEeTlhEZpAPnd5O/OabO+UtPUDZymVdPEDZ0b+SlU5mpnXVaQV1tFK53w
wXxTMa1U08CNnNrI12VhOOpmDcr33MyxqtXUdxOnVQGqgflp/t5LwLA8+LXTw/l3/n4n+18rc33w
+XKunNzjyUeHaJFzvDFX0NErYwwtHJ73Ual/5H9mX3niq8zNYvYCD6yngtSNtOeTr8gPYUIeYef4
iXGJypxmc98qtqWKcMPldce/gIbUru/8R+kMzwNnKnRul9foIPFMc8VswnyHegrRUsH8XniEVN2g
oCy8UuQavIfn2QukJtZS14/TBC+Qv+GzBn5/VroAnRXkT/naORw9uvh7jhLfXsgkzxRdHWdpCjE6
OgvttcJw54JQrnU2Q9skzjF6O3Eu+Zvzygk6gAw4pAsFXaNDdM2NIrs5ldLoIDQx/y+WFZAnfZ4B
fYRh3cFGxeShVujNgqcyKZmnWPFEvveUSrEDXQPFmlmNYpETJtENRdkJ7UvFW3bKw0lhFhvRtD7w
OiVBnGUw1W4QJGwk8XhooSMwRspRQYyKZmoaOnPlB6jNrsHFh19PKEUM+RKOIFLTGE3norliJ+Jt
Z/nEhxomaeiGGFJxFnPOuGEKU/621eTq29Q07alhiOfWQ3qkE1ePi3+DPNgbl4SqA4LeB9KP0U/y
ERiI4wCnOxzQPTJ7kZj3Eh1KYYIxiziKoavNpK3QyD4FD1oycsrqCOaETzEiB4mQDwLkfi+LnA+L
tjA6uqn81hWjdUoY7eOPWd4qcl8tpCVv0LXFuqdOI0TLstuYBS9xu6/CBRac5BQrRWcobkWhnBwS
N7B+t4ZN8A0Zd6pQn3DqqLhV7j3ltRH6uNdC5A2tz3DB+EwPUoJy65yh1c7eIhDPMAHg5+IWrRE7
qw7OOHtjTNsp4ckKLY4GTRxZXR5aKfL43R+xklCfsNKoOCsPs50NH7PSCH3cSggBme6t1AOHjsVK
8w8nFJrWQAGby+9nbxXF3oyqC+0cwdnsWPk+43DIaCtcRoUl2mUbhAjDGWfMlDJluy04KciyhEFm
Geqt5d9Wa/JEjCDpE35tZGYY27qR+UJ+amYqi9XqnuA+IjwWiqDy7qWujcSqYjj+ItsjHE9TsxXi
sZEVSffQ9zrGimHU90J9wvej4lZ5HxmP+X6EPur7KMMCaTxBEJOocPmgpvQUXZrpu/nsCPJGUgHK
a86BqvzMv9DJvOisTe/I5ZlzLfziOJQrwCQTOy1wtt1+UllDh2YOCGwcFXZhuxGy4WopAhMEtsLo
XeytV9stxU9tM7iCK2WKXebC86z29luaXe2pbriqNoeFzqyay5sjYiEiGHJ8adGEA983gZ9h4FO4
eIBa/CiObVGj+6zzTNbdYKEqQEx1yTQmqMfCBM9MAcmIn/Ea0EfemJjfGCooA0oKLDrQGbRQkFUW
bUWs9P9B0HrBaMQi6YlwfVxQdOpdJAchYdKB6OP08ViNUuK1L3DSWyzog5U8dKkSZ8bvXShvK2ET
NQ1zBKTYLMEpcr27eHM+5DuXEuvdxRGgt0J+XAPzbSiKAqespWuKqWuSQrIWBhAXWP6u+LSq+f2l
GCFGcmXqLOBTZTTcKc1vbbWGSnQtNk0to04aF5NBfBrqanyK5Dua1aKjE91wbi7fu7k/iNVxrzTt
T4DHW8G/d8NN03YcEfmfpGRMd51DKsYtPyriz/gKJy4ZiKK7bc3ikr+Vohin5KD+61rWYIE2C6ky
FmrNExEDujorxasP1kVgcH/aDApOOu305wBpdW95Xsp++7sX+5pEEp2pUQ28QTyzynN2Xz+FpoWy
GR6mbVaiyuxzK8TPsmktm8p5oPpqTrR/4qGRTCCQ0J1siYFgnSCmz8T0HcctbZpxnnv8XmqNrnPt
vd5i1UhtidKGXawQWjFMLVlvKRcQENZ00giBgDKjbG6ZbU128a2GR1dphxahk9GmEUorTsysE2NH
pkbP0Ila3B87sr2lfWX+Q1SKsPEb7yAMdRybxsWt8r4FCCPifCD9GH0cnih89HiDMPubqfDpjejr
blv9z97ArzNCqNCR7zF1aKnzywxkbqT+8mF2wTEQGAVYqe6lbrBLXYOLM/JGYJzjyARds4cu5KfB
H/Ug46Pd8Ll8T4/6A/LP4SlPvksZ2yJAXA3QA17/vD54LL6h78NbinAf3xTSN7UKD1/trFfri9qP
zoxgN2IAx/eaH4GY0Sjl9PWdBSLp8239I6MHi8873aBCCcP+roG/Cyzf2vDHrnDRAOKYLzvbdlXe
rYRKHS6ApNTRZlWQFWt5zoGM4Q1rcjNb88wIssrFoAilLKpVwIDOKkXY6BdZKG/5t22rdfd4qcYJ
5v1/LABnVdF2nyqszzYVJbxPvcvCbozIhmE3Hm2/Qwz9zxebMaxoKsfwm7MbUqqGQwItQ7TLH53z
9/ATYI3iO6+k2QBGSy2FF5qlQ3q5F5y/lU9+uxFeE8PMKduK4z6Vsp1CD9sWMlTAYYtvLbc6Qtly
a+GaOD5lruaWZR5m6h/6+gDm9OhSqtnk4oq7s3bMtS8k6k85zG8ZRwk8eCAwO0jyc7NetV94UKz2
Uj14WfFscjxwJHQlmRPJ8cSxRLtMOU4pjan9k+Ks53x3KeM9k+6+xMZ4sv+RzfGs7KaVjpumbyY2
VnR/5Os+L5kxrj3/ZT5hw9HcZPRCXqPvfN7g68uK5P1RV3M8o1+3e53Gi8CoHnNoViwWrcJKka8S
cxcaDzpUA0dQ7y/fYEWI9Sg/zO1njPJqIUVpwDFflJ2ZfSHa0EQvLNwvKi6MQyyWdUypjbeloId5
VxiKPHDSNMAAubRpIbhscQn0OE+Wpq8gm8zySYolOFoiQjNHGjw3TGHK37aaXBE1TXtqGCJ06CE9
0rjPk+JWuRcaqg48mjwQf5ThJJ9kbhZj1+gBDzKieTHo1EfV5MIbcWbfTWrTTVKiR85MIdxlzpyS
PzFr8GY2P72kKMzQfLlwnL+7ODqwic78MYMQadwaI4Ki09sZymejHYg+Th83RJztGSLuIcDxXZX/
c/I6z0NA8hWSkyhDeQJ+4sJoEXoqdPJBqg0Dqgr77tJkys8qolKKmgF+ZNCmlIqa8RTfTx9rBnpO
PYfHi01TKzI7zzoewmAFqq0sFopi9tOKJ8KwJdQOMYKRr2LyArYY1LHRU8hP9QoWDbA2PI+2mwin
yMlRiIhHvOd9exAR3GG2rchgi0s7gihqjBjr7wi1guGRWqjGL7prciOUEvpQRS1jsYTIXNN2FfW7
uMYVK6t70FFwmPcB75mAH/at3LGmqNJ9bgUvj2ZVNu0COgGOamcoeWuUT36JEGcEbYrlPp+sEtu/
bg3KWOihWVnBrbDUa5GEAsyCQNlybUpwsJIE9LGBuBWX7kXXtHIrvFPqJfrwboMM0D+YAUHSpwAB
DNnpVKXoJ3p9qpJCHV34mafWCFhnRM6RouiFMxUQAiGWHysqyVMpP7gm+W/p1dLTMAyD7/0VPhYO
o0mcLL2yGxKnHRGHDYp4bDAxBH8fv5oGtE1IXNrGdmzH+Zx8FUYSTQDSRVI76iXBYuDyShwQqPDN
yFLYF9ra6XUnwJJ4lsLDGdUOtVGTNSq2FgLeXs3toB+GXvzpSl/cABxTDT5+5LEbhj9vRPjnRvhY
8BrHfUizLDdc1J2gs7J9kSFcMkg9bUKgJ9H8JMSfa8E0nxHnmOPTSWtuuETRcBYFrVF4M82+O64b
3pVz5FZdwpNq6W/D8mH0+nYc2dzh/q9Vw//C10/w9VObK8xCu6OzghbS82bz61GzhdX67dM+VaHm
eymVzbhbCf6ySdWiOvOQojyW1bPhq4xASIsrsQYVCwbZsQ4tyNRRWHEbnbqqcoL1YH5qftibDfND
jmUM0VkM4ogSxYS24tlvDjDvj3IAUp3gAIcnqs883fG5K3e8qV2fj808ouJsWHUqm8MhR/0hx6d0
F4t9hMVS6EgHy0Xj4Iow+EyGhOgvcB1cw81tB/eNy3RmdEyXKIUE2yZ0dKRjEWyapdhkFkXPqW1J
wPSmsikWiBxh0zycF88hUw9WjnVc+w29n81T5Xc0KQZUxT6p24BR3SRnCY8Cj2SBwasLoqmsxT5R
WcYxR2WJF3v6ZUEyiR1WUzaTQaBtRY2KoRdZpEN6ziUYBT5zosElWz9F45xsPK31G0KsE48KZW5k
c3RyZWFtDWVuZG9iag0yNTEgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDQ3NyAwIFIg
DS9SZXNvdXJjZXMgMjUyIDAgUiANL0NvbnRlbnRzIDI1MyAwIFIgDS9NZWRpYUJveCBbIDAgMCA2
MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2Jq
DTI1MiAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgNDg2
IDAgUiAvVFQ0IDQ5MSAwIFIgL1RUOCAzNDUgMCBSIC9UVDEwIDM0NiAwIFIgL1RUMTIgMzQ3IDAg
UiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDQ5NSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUg
NDg3IDAgUiA+PiANPj4gDWVuZG9iag0yNTMgMCBvYmoNPDwgL0xlbmd0aCAyNDkzIC9GaWx0ZXIg
L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ1BfbUuNG9t1f0Y9SaizUrdaNtzHjBFKZGRaLra0K
eRC2wM6ATWQBm0/av9xza8k3eUhNzdYGqqzuc+vT596jYnBSFNoorYq7gdZBaFUI/7zKQ/gNE5Xa
OMhU8Tg4OVvHaromklCtp4OTnyZa3a8HQ6AMo1gV0wGuskgVr4NfvbPV8s4fZkHkrWp/mAbWe+RP
6eeB8ZbTShXV2kdIw3Rq8lQRbuoPoyD2FsK/mJZCsVgtla/DIPecaH+og9Sr/QjEqMlZcRmmSkj2
vm67u/+L379I/s9Krq80XS5gzUPa3HiIi733T3IFE78TYximCMMb3/+t+Jl8FbKv8iBPyAu0cJ6K
siA2oUZfoR9sih4h5+hUXOLn3urpz9onW/oxHHg/b+irwJAm0N5/fJODPurct97z/RwcxJ5Z3REZ
E7+CnJKlVGryJ9MwqnoERga889E1cI8wdBfIJNayQCdZChcoPpCukW51xQugror/fG283dVB4P9y
lRp3IUmeoQkSbWOVgJ9zi7fiuxiXFJHhW537wxjMW/lDNHbpDxNwcc07iHELuFsyWyU4Aaqr6o/n
au12T/UC/KVh+ehrShXBLF6Yrdqx+FDDsbE1Ck6KonRDRduqaFnFAiQnoM4YJHoTFJ+0MPXp+uMI
41PQV+pUxXiihbDOgDChc8fFQKuFGmQ2sODPJE8oYAObqSH91tXg7uvYLGux1oLeZhMfmzQw/exf
QW+cDSDGmgjr3h73Ifyo6MnBJIlg2yWhactiGLN5r/wkyMA/IVjrDkuEkU1diUuXYMnYm1anaoLF
IYG0RRb0QQTUlwykYJzVpchohvxdVFQqMyyQGj4CXvvovgWj7umApi6XLRaiMvemzZMAwjRo/s1U
ylUG1uLBRx3KZxbImqs0iJzfnWFTiMp+pzL2iFN72Z3w8JjXevD9XrNAa53PACA+MxspEcN1L6iu
ud0vUAXHkADqx/IZrJF4D406L5e0nKFFrfeAaRpCOjP0ftdKcUhNt8dKjD1ipV52Em7zzoaHrNSD
77cSlIDctFbSrZVyttLkesShyQZKwFypxC3ufqF4GnNrP1XnVVk3txx4VdlggePNM0fWulFPDKix
tBmPK57BipcBdNE4wIuEIsV7sGtik0BX7DUxY4+YuJfdCW8dcMjEPfheE8c5DAHOwjp3FtbSEy8x
f4137eO1sZAYB/o8GZ+qYqWmc7A5GHT6hb6q4T3YV7L41aciMkebgtGW6poiNAf3wCdy8tTa5z4V
QuiihBkziNvIYT43mtD745kPlSOYteEmldPcZzAHyGO4fxHyEPRjiGjNR6nzMZW6zHvPZxSyHWE8
ZN74Pd/BgZXI3z6ff0uB3XdHLhjT3pAJ+OiGoidUEEo6TpIjjbxZcaNFC6NSYJByxqBZ29WxI1fr
9V5MhlFvQALqSDQeZmSZpgvUyGJm77AexveHYpwhbW8fkzbE7WwsfcP1KHQgGHXig3ItUHEH+fzp
w8U29QWn7udPp4pcm0m74t8VV4zpopTOBo8AKiXoSRpKXOPkbVPePiyko82JkLvUTN263vjqGyo7
EP4Vy5o9rRa8aqjBuXQRfVS51ZtnahQ4VWtoo9xQK4wFXszKplTSbZfk/eIHHsptN5RLcwENwBqW
VPBjCkXaN7RRIwjUDIoiwaaYLglci3aKSWRXCsM1Hmsxnw2cfqm2hIq4iuW4k9H+Cc78EU2eNUu6
ZXDlBF/B5TDLIJAw5YkV3wdOU8p3aBFYoTVNGzFNtTFPHoh5ES6SsZsWMUzP/YOgYPuTo5/dCW8n
uQP50Yfvzw+o59Yem/TG/5IckWzYHuPGH9THMScI/0o8/TRWvBeuf1yPP1GJjkQAjBybERVF3dMp
koOX8HKMOKCsx5vGt5tBbdHfG3/H3z3d8q10byLs1XP0dllkigjyPgIHtO/JfWfs815Tx8uhkKGI
oZOxUfrdcDNtBx6UdOONsdBwpUg8rja4x+THHqO92Y2/adzv+CI9BMTF25TciiO6pzPWd1f8+11/
f8UxAi0m18lGjGStZ0177V4p3dxTV1D8sLBXaFErM8PQyYdmZeM0c6f8fcx6Pqa6EEFLT+WVY6De
j3CMST2HLPYnJLqm7qqQ/v+97Y2HOZ/xxGGo5GhoqriuKxmEYZrUnCItBSZR1pZPtI8VfAPdH8Mg
hW4WoqzVs2P52+UW6A4vWlCf7gudvpYKsdGio+jIg1WwR1p0LzsLN92DVIfRfo/uI+ht0lbn3Xsq
TNsXqzRKeppiozXg8AkGeCow9WE8Obu6uOTnScEUFzCh7hjEQn/osQai+k3Rw8gys25Ux6nT7LIe
xvdbIUw7KyRtLHo68IvfBydFYRXk7B2g0ziXAolUEPGMzxivQVxmugpqu9FDi0V/9PnpE+LYTvMM
pFPUjqUxj6UpjKWrOwo6nn5lCIg92cHQiFPABkRBteUXGj7qDDjl9gGWMFemHmPmTFgRcqY2yPGn
eqfa5yE/BZHMHY7lIOUBOJEBmMfflMdfHn4T4eLhN+Ip2h1PVDQCp+7OqH6De1y8CI9Tg66/4jPq
Y2bohrYYNAg26q+1R8YUrFLGq6aresbvkrw7m0pcSlMAPZT46QSWut+mYyiSUctDqw1ptF/Sblqp
ZyZZLJlTlUoA/Ai5Z8LyQTnORx8fHiztgWeTZlXzrfAVGKZmt7dsRKz51og1XcRK0z+jJ9ucX6QV
PbAy7wtvt2wfe6cwl+ccJVQ16EX4nnZXJKUQ2IifrGPhc2CFcUExFHlrjJoMLc4H42sxleiEVsOf
irVZMk3Dx3fxg22q9ofYdzjbqHlFLqmMTNZBviNhpHhB0Zd9lXzbCG91VfSNrtof4fn5MydLo6PI
pl9oq0YYxgY8hE8rSNaErBdCeLkOrUFzMFUsYvDusURiTPHMszL1wV5cVSuK7MxjkWrB2GldiT4Y
38ZzO+GtZm+1mv1Gq0W2m8NsVwgo10GTJ6xmFhXnz9zH9lap8nb1IktGMDlEoSf005LGo4RgjHWB
8cqNU2QJ2ZJ2Cssf1WYWvto6lqRQ7cOtRJ8WVjlXzmCOstVK3VbCBkmlMQOcfvUXFj7jjMpFXDll
gQKU2wa77Vynve0cUEfa+WFGlpl07TrJt3CRTTvcHmc/FhUS7DGdDhzskD2yv4I+OVvH6mxCI0ao
JmcDrX6GQPwdCCGsX5UO1Uf162+hmg10lgYJapFAMGbqcRCFUPltC3gYTIgmI5DFufARADiybNC0
FDHMFRYAdz8MLEx+JDk3wAJNMLCWdygTscSRxzgDwbl5wjKJoEVnWQCvNRZoLMFwPE1QDQewUYgz
Jor97wDHCMuhCmVuZHN0cmVhbQ1lbmRvYmoNMjU0IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1Bh
cmVudCA0NzcgMCBSIA0vUmVzb3VyY2VzIDI1NSAwIFIgDS9Db250ZW50cyAyNTYgMCBSIA0vTWVk
aWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUg
MCANPj4gDWVuZG9iag0yNTUgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9u
dCA8PCAvVFQyIDQ4NiAwIFIgL1RUNCA0OTEgMCBSIC9UVDggMzQ1IDAgUiAvVFQxMCAzNDYgMCBS
IC9UVDEyIDM0NyAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA0OTUgMCBSID4+IA0vQ29sb3JT
cGFjZSA8PCAvQ3M1IDQ4NyAwIFIgPj4gDT4+IA1lbmRvYmoNMjU2IDAgb2JqDTw8IC9MZW5ndGgg
MjY2MyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIidRXW3PbNhZ+16/AI9GJGBLg
1W+ywtZumqRrMTs7k/SBlmiZrSxpRXq8+Un7L/fcQF1sqsl2uzN1JgJxzgFwcK4fLsvR67IMjQpV
eTcKQz+IVAD/+CsP4DdIVBrFfqbKh9HraRureUsigWrno9c/zEK1bEdjkAxsrMr5CL8yq8qn0Sdv
ulnf6XHmW2+z0+PUj7wHHiqd+8Zbz2tV1q1GSsdyaratiTfXY+vHXiPrm3klEs1mrXQY+Lnnttbj
0E+9nbawjZpNy5+DVInIs9FNT+ffOH6j+N9rub4K6XI+ax7Q5LOHvNibbOUKJn4lxjAsEQSftf6l
/JF8FbCvcj9PyAv04TxlMz82QYi+Qj9EKXqEnBOm4hKde5vtl50mW+oYDlzedzQqMKTxQ+/f2uSg
j7rSkfe4vAcHsWc2dyTGwk+wT8W71Gr2hWWYVT/AQia80ugauEcQuAtkEmuZHyZZChco35CuNux1
xQugror/dGi8068Xif/Pr9S6C0nyjHM/MUmsEvBzHuGt+C7GJYU1fKurYnJTXuqxCbxCR2DvSQmW
N/j1oEMM+hqmMGvbSo8T8P+SByGrplU7cAqESOJtN8xbL+qFegIHolMD2KO7V3iQnDMpx5Pp2xMX
wAZxZIyCXa1ND1SOepUjVrmEjRM4utDjyJuhkklPU+8/vrtEZYR9oy5UjEpFEOaoYkrHFuUoVI0a
ZZEfgX+TPKEA9qNMjel3V4/ufp+bZT03ikBvc8iPTeqb4eW/wz44G0jMNRbr4LPVL/Evy4GcTBIL
031Smr5MBjGb90YnfgbuDcBad1gyjEx24HIoxbG3BkvG3ry+UDMsFgmkMS5BH1iQ/pmJFJyLXSV7
dGMem5pKZ4YFM4RByK1G9zXMWtIB3a5a99xxDKVr3m2FEKR+9y+WUq5SsBYrjTpUj7wha65S3zq/
O8OmENvDTmXuGacOLnebB+e8NsAf9loEspHzGRDEZ+YgJWK47jXVOTf7CapiAQmgvq8ewRqJt+rU
VbWmzwVaNPJWYHEwaOoxdXlqpTigJjxgJeaesdLgcto8yvc2fMlKA/xhK0EJyI2zUmz7Em4EAcyg
uRvvI9S5xLss6eYR2Cxkk+HkJywnKdQO7BQXOqG+A9JMmOgQrXQDfTDpl2BRg6EQpiO7qHzQVExr
6qbYh3L5rTDWUzA55JQVvmrgSGZTVcWP7WbNIlhUZdMnPgulO/h/r8fow15X1uBI28sTqlNzjLcX
GtRk6v3+aRSYBBr5YBQw90wUDC53m/cx8lIUDPAHoyDOwZJ9qvTlzUh5g+qE9viIJjPejUw/zIoL
VW4wKQBrzO8hG6DzzX+jUXU8r7oD+2Ptumf5ei3rrgrKPIMGRf4N+COTdDQYKBh+hTAdeR8oYU6B
AGUx4nZL/XfJujBZcb5mECQYVap1Z3cQoLBX565AaQ5js2DCqlby5Q7o3FZruVwja2UllF/RgAnt
ltkitUNInEH5rWTfxRG9bttXqukAHlAwBQoODeMkcQDL2L7vCBbEeI8l3jMJ99sv2lAykWUth6+l
oHZBbDkFY0lBe0DGXuFNpsx8e+A7S7mDCHGcgxMJUHb3Ah8bJK7xFin1P7ywJUg/DhkWGbiK2As8
mHmsr5pXu10DSjfrkx2v6mrX3db78JEtuJ+mHt+bfyuhLXmtDgi5nORjYAeTEVhnMvHlhbyn2Sep
jbDwnix9mT+chnGGsoMwQ1ACo41C2rqDEOhtMNAMgjzqiYob/If3b66Ppa8ZSXx4f6EoAjJBE/y7
4bfbvKkEeDQbBjAYm4QZHa7haVfdrhoBHPckyCACotFBlydtkFvXa1XzXovtpuGvjvCH87Too6oj
6LRQl75TdQcoh/FOzRGDH4uqq5SAoTV5v/yOMXC+f5fkbEjQAAxPGlD552lH3wdqUKlpH4kJ9Q0H
1fE7kGeVLLnSzgNo1AnNbkAvtjfSLjnFC9nVkRWEtYHQrTUAtlZjJ6mWtDUlVUr9D6mKh5rqT3is
MA8b97igGdNk7baud6cJEcMzZxihC3c4LYaXu817iP1CZgzxhzMDulgUnYPgxT8kOyQPjvF18Ua9
Kzg1+Fci6YdC8VxW/e1j8Z5MbGUDwIJHsbQHSIEApAJ9YSWWPJ6A9Q/jiLx08Hf+gbr//Fq5/8WG
g9e4PLo/mZ0v/tkrWmopmL6pxyUA55AbEKhozsVnfXjvr9b427++fQl+fN0VXDeGXAhC47pxSLb4
5F0Vk5uS+hw11USaqqGmul8ZYui82Rvx0z4i/jyr/Om2vSoovC1Uu1ReUVjOwA4RPQnw/pDfaZxD
RsP1MXNCgKNkgAmIG2wfYwQc+PGWFoxlxQn8+eub7RrSivAR2AZbrLcjVJMxgvE67LLQYthq1s8D
m7DZ8PqR6UsPBiFm4HyzxWoPobpQd4iQc0RcATdwqG85oiYrPSuEoCYIUIuR5YCXrCwZ/hc29e8E
pjAdWYkf2DQ24UTvIxbNRLEHLRoWkLuw1Sw1vmLr085q7f719byzMvdMZx1czpsb7JbMDeES+Wlr
HRIY7K1R0ENOfFfM+7cGhgC9uLA7GoimGVotFZp6U8ymN9f0GCTAiRLXAChPzBGFB73+mTmEO2yO
4eWyeX9VxNqnS58zB81g4VvMkPQ54IW+Ln8dvS7LSAH4uAN2X8sClIJsZX7G/BA2y8xB1ob7rA3Z
pN/rhNPUUJpGHmHAnN6fBO4QXCO8k6mg1MzNO5qoI5qqWyZXEJLGu13RhEVajHnL2Y8PKBRYEJ5M
Za+Kh/qVUE/OR2iUM8hFoBQApJzQN0LcSLBswhA3EYi7Jyu5nmzKJ/BvxaTloWaKddnIoc4mGyYf
XWL3VYbyXRM+rnMm7xGk+AUrBVTH+Wa34FcFgvDD1ycaBl9I8Mzhhw+B9SM5pqLYPx+ZQ1YI6RED
j4haPbJIs+aVqlJCwJdL5C1ZsFopt/IBoFji8W4rjRauuo3AeXzDBak5vdtB/Jo/GL9YG6QiSNOZ
3hMwrucCrX+j6QHaxeFC48sNqjABo9xzEClniJQLRAo9Rx7TK24yfbu3uHvvkFkJ2rcE1cHmpICT
fOKdGjpyRegdR1LgFp1l3DaqhYcfru2Y24gwE6E+tFuW3/DA9BYemUL4hgtB2IfouHM3+Fon2j/o
RBP2sZ6LE3VCj9gMk2lOkZaDJ3EKgB/umoALDRrlek3UO4hCykrLIIPa5wOwsHogbqGl82q3awCM
NDLvMD+NO4ethxE8uaHzS5nKiQU9yvZkrBwB5RDWyhbtbGGIsXIsZcuGT2Bqf/5tNZfLiCbdhlP6
v9Bi/Lx+cDl3BQS6DNkUg/eBCymaCQKnRaAQU4WLqGoR2T9tkEF8rkEy90yDHFwumwsryY8Y1iZD
awZYqA2yzqpycpjjvLTlOd7raRur6Yy6dKBm01GofoTY/hUEIVOeVBiod+rTL4FajMIMGzgcDiO0
8IeRDYwfZEzIIrUazYAEOYYyKeRdRjKQm9GBTC8BF00yINx9BztDyuK14ty3yeEqIBjeGWVoXWLR
KA97dXjRai8RxwhCaOf/DADI4urFCmVuZHN0cmVhbQ1lbmRvYmoNMjU3IDAgb2JqDTw8IA0vVHlw
ZSAvUGFnZSANL1BhcmVudCA0NzcgMCBSIA0vUmVzb3VyY2VzIDI1OCAwIFIgDS9Db250ZW50cyAy
NTkgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzky
IF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0yNTggMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAv
VGV4dCBdIA0vRm9udCA8PCAvVFQyIDQ4NiAwIFIgL1RUNCA0OTEgMCBSIC9UVDggMzQ1IDAgUiAv
VFQxMCAzNDYgMCBSIC9UVDEyIDM0NyAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA0OTUgMCBS
ID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDQ4NyAwIFIgPj4gDT4+IA1lbmRvYmoNMjU5IDAgb2Jq
DTw8IC9MZW5ndGggMzk0MCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiexX3W7b
yhG+11Ps5bIIGXL5b6AXtqxz7Oa3FlMUOOkFI9G2mjhyJTpOij5F36Jv2W9mdilKFn2cBk2dtjYg
7u7MDjl/38wcVaOnVRUZFanqfBRFQZioEP+yKkP8hpnKkzQoVHU1ejpep2q2ZpZQrWejpz9PI3Wx
HvngDONUVbMRrYpYVbejX/R4+fHc84sg1suV5+dBoq/kUXtlYPTHWaOqZu3RSSt8anrdMG3m+XGQ
6oW9v5jVlmOx/Ki8KAxK7UR7fhTkeuXFEKOm4+p1mCvLcufptrv7r3x+JfsfGqu+ili5QL485M1b
TbRUH15bFUz6xBrDCEcYvvW8P1W/Y1+F4qsyKDP2Ai+cp+IiSE0Yka/ID0lOHmHnRLl1iVfq5fWX
lce29FK88OKy5aeCIU0Q6X94psT3qBMv0TcXl3CQeGZ5zmzCfAs5tUhp1PSL8AipucJFOXjikWug
Rxg6BQoba0UQZUUOBapj/tY46r6VFKBvVfLnRUbvrvYefs9VnjiFbPL4cHWcIwcyOLpMnFrJRq3I
qnUygW0SfcjePuPfik+O4IAU9urTheLLZsy/zyjgDbnLJHDXlRflQaEbz+CQkim3v/VFo2aUHck+
HnW+2qKp+qOXabXwEmxoWc9a2Xxq1Bz7/mXkYohNj9nycjKWONr2NgI8L1OjfBPEcc7GEU8nDjLi
RIxTQUAGrSaen+ipF8VB1p2pl29eHFFqWPKZOlCp52ewSQAzZbrg106qUaQWalQkQYJQysqMcyVI
CuXz76oZnf86tSg6apLgu02fnpo8MMPXf4XcezeOhGpigtw7t/fRj6qB9M+yGNtN/uPImtdY8541
55Kz5KdYr+hJMQUfwn6z5kBNPZ+yfwx3lmz5FOZ+LYcc/XPPpyxfEUAjyERe6wugNIgMJEJO4Exk
OV5DGEWLkC74Xe0KAceSHI9PYThrr/unoWxyeQA3DSHQZ5HgAGv8obZq3DBh3ajtC7GLC2f4HLVl
2OlCvcfpg9ed8PA+rw7Qh72agDchn/7SOeSUreN2zwHGEySD+qkWC3xo1UktPrXu+uCsL6cXuxZJ
Q679AxYR6j0WGbzOwpNyY699FhmgD1sEcFCaLsqjLspLifLpmyOKpswaKIO5KLbc7jmMlxKEUIdx
oE4mhx4aHsLihBFXuKwIR3THPpAHwWxPx8L0zIUiwLRA3khalXq9ru2Kgj6StAPWMiwXfW6crp2Q
c/7albxoi1M5cR9ZnFrIs57Z43bxSd6j2O0b0ZSWVDTchW6/FD45DnajwmToJwajQqj3RMXgdSe8
i5l9UTFAH4yKtAQEuKAwXVCENiiAYYV+44mjqWbwwavp5EBVSzW79KiuNLP3/FSt7OsOZG49RphL
ihrY9SPCho2eUSjEndDKHh6RXSV64t6xj4au0IdjofbCxoTWW1Q+117KVZx+a48qrSvl2X5Wdc5y
VwR3EjIdI4eM1GRWbEFQbuyOazzvP4n6at6IxHZhOeztFn23tQyAW3iul6uWIyZUiLIozTLX9YRx
l5K276w5IHNtHxTculmvn5ChM0AZDG1JHLIA8ZZjNdYS8vRFS2GQY1IkiqB/zA15l36l/WiIWNm+
4T1faKx8RUp/kiPlhItMx3HWuOoELwRj+96b/utb9sfd42a1yWJuh1jb+7RkNayquzr2PuNansue
/Vo1YFW1WPf8kiSdXzDpkV/EJatmzT1bQ80c7Hsn++HFodQH6Z68339RZJoNJGCsRPruXN1PH076
hDssl/VFl/Wmy/ocljwDpKJr9GkgSzkbDcJmQpoXaDMT6O8O1Zh5X708Pt3mPiWXpSAcKGQ1td5r
Tnn5XRIwYG5dyKCaakkYgP1CGFRjMVe2bf3uAyiMA5fM2HiUr3P1rrESbj1AoNENwKYRWfPr5UJW
rRdzQyaxZr9H0SzJOHMrBwsRJMzyFnVqTYLgmVMIbFRQX7YgQ0ACL1V/peFAlsM5j9GnG+BSMf7s
rUc3qXWcq6NAzAaYWtnDC/5tPMoE1UoDeClnag47Uv2rhbrgjVwja7BMWKN3LPxbJim67ZqdesOM
M26FUvuq7Rfbt6oTTDsFBUhkuNrT7qzrIujsSOrzxL7IHfsem86ejoXpGd/vob2xPTh9hnya/Nb2
bMsyoqQwbOsjDFvqy2NJlSB1V62GVsJ106wC9dxjXBcJW3etB9jL1W/Et+XGt66csqUy5i518KL+
LIszBApiVogr0SfiTyz5A1Lqfm5kL0wYLIGQ5/Q9mXx4hH0jLNbHme7f6Pk4pe9ekH6JE28/ZAfN
0jS7p+e31GFMG77uhHc9/R5YG6IPw1oY9nqZtEM1m1iTP7623SlhEiYg5G9hmwyE5LF6MZlyMyu/
3IQU+ueJkr299fs3k5fsn9gKwAyx5fV44/XYvpjcEFuvaNnAJ9tZBwf1/mhmHF5tlg/lu281+HlH
D5XQW7EpYjQQMRwQOpgzpnNGITbpbrx5TgUjQ82hm767ulODTdkJiETAWz0hABaczrQUhswiNqeo
ngNJH27Ub1ntHD7s2wYqQq/Z+A5f/m/Rf2AlsYHRqoyyXmzknWvjTu175U25sFMDJyFjJe4Y8m7I
PGJzHjMGGFsQC2236E2k88Dyt9RpRPoJtV8oSPaYOyhAfwv6zMYUkIjxJ3VZZ5xlj2VwXbpW5e8t
lVrA/7ohcSg5c0ui78J+im0KPDiUi+NnLmgB+dwY/1BBS79i4VzHMJzm1pZHgAhKogZyxmKYaWh9
vaBWb6NwRNh+/LhVPAV+69mqQbsUyZjCgxIUc9WGGrKYW5hIy1iaAaMCL9RjpnCfoQf61f+KpFJf
mVZoBPT/U+v+1b+UWlA80X/7n86wp1VlFFLp3OZaEeaP3gLbK14Gd+HiR1NBBTQEYZ7DYFTAS/Bv
wf6NeHK02f/jaeXCrOiHmaGh6JH6aDd94JSBDFKSfOS2WdPM1z9wzaKnrT01xoNWJoXgRf1ZFmQU
oxvYg6sIIQ6dA0PjNE4JV1V/Ct3bVD8OTTerUyoRiaiNcRN1OETCKZ6VYu3Q9AoDaQKjEG31nhv/
Zq4WMgLUMzYHBtbFJyH1rRCaR6v7y6a99UxGrQaVSBoTSTeoP23rlhAo1Td8QNZIOmtQ/Ec8Rxa6
dr0GNStGX3iCVz0D/Meah83yW+7etxoYJvfl+rCUk6Zete+aulWrhrq8v9xwVjVk89RW6K35Mkke
aW07mdjuVoDCtbxH1IQWerLTCXMD/LCJctD0eVCGcc/0MbfE/k7e8RW8jVK9pFTP8IBkYDbeZbtq
3wnbRe47KAY1oSDrEZNyqahmD3wBlEMkiX6mdv6+ISIHAKuezxlzuMfNJGpibdHrDoqhW0zvwFg9
k3Yj03vg64coXB2SoSqzXmWns0OyRN/YYkVZpcZS27YL2YUk3ncCr28PBpkt427msVvV//sKHAP+
50new7G99ftBAqeNlMY5S55UoyIJEgRQGoUK0Vson39XzeicSEUhpCTB/GX6xNQADoYvssywDFJj
qTG0uHN3iOGoGpVBSfARKl6UUDYJMxVlKHeJqq5E+84OxtqBDI6s9zAulnpKVs/tmTqeTMdnp8hO
ahgq4Th99fJgxxBRnuFVQ7aw1GFzDF8X4WmQZpaK+IbyO7f304ftkSY9e2RdTugo8Ko/U2Of2MY+
yNPSRhBxIQ2Fbhv/CPIK08PrbIPXmdj2Jw8fR3AGWVQHYNyUkMsw2qHlBk5xz00oKNv59T9Jr5re
to0gevev2CNV2Cq5uySXubVCgaBBW8AOcil6YGTaVUFHgaQk7b/vvHm75NKVhQK+yObs25nZ+Z79
boXI5+dJ/zc5yQxHUmWuFbYfR/0g4sj29KcCBz2/N0ftYPEO/wzXqaZ8g8c7uXEDpchlqxfJRERL
cW4LMlkoIrWWZyR+pdDrKO/Zs8jfvF0hiH6Kwn+gcLTYLmZ+xRZbxRY7k6UXYS6N1A1B75Td3BNE
opskUw/+9pH2mFnG0Bb7qFr0x57U3ISH83uQryaHV7GfSKmo0PujF0MRv0/6YRY0iVPo1haf95/4
z2CIQ6TgWW9Xkt9qLLRDeXktn7erwGxU4o8YLho1Vp2RjQYZ6r/kbleQPX97kh6pxCAGtMU6e2Cc
yM73y7g1bfeHexNXqmHRkdFxK4QhAp/9qX9c4kgFLE2Hi8a1HcwXQnafeNP0JhLY/B4J7EeTbj6p
s8htXMEg/Wl/4KvkTaFs7XPnZYlvX5n41k1mammmjajb6FIh0ciNqtV1ZJ5fxGHQ881KSL9pcNZq
AIe42A66fSGrb7pCzeAwkupi49PdW5XyPhIxvCFa4mEiY4TDAKeH7xa+qqLlERm1Rkk9jRFtQaHD
ClljHsBF6phOsxJpIXFIDHfUXUtCV0TtJZ4PiR3PKeLzXoZhGfaQALNgc82QQpHCxec3zifhfxt7
ZPz60fH/xo97bfz46QnNHD+txo9P8cN1VlyhfnYIHJj/VpHwkqxXYjN5qWSz1KQmMqG/Wk0Or17w
Uo307vbls+GQjPXAOrFnnTnQRT65COJybzYwOQ3O+tYk3S4as5qGEr7/1z02kdPwxnzoxy8rVEal
PKhjzHvtpG3hQLtJK4MTq/wt2FMs7jvNKifu1toKo3TFIet7Fgk2juYj2MRzs+3HLSSOvW5Ap+Ee
p6an6JMYZvgKhQ5qO1/8s6o6FnPGOpojEko3GopOihyPO1i81VLXxqKbjVGNvzRG8fTCGPXidTJ3
85gUymlMisfBXbj74iH04uEltc4LTufnmV8+/X5zrM3mTme70txtrirzs6TWXwKU2PpmZL7+xfz+
R2nur6rQrhth5Guplebpysn83Pj0PV7dKSKA0pRQ9EkImBRnyASoZS8B4eG7ia0L0nJsxjcScsau
s2KpjPGEmRChXpeBnJ31lO4l3zw4J0LZgjBOBNcGuZ0hnKsjInRqPd+EtQXC146vJgHaAeNBamUA
AJNQLSETQOLKUzcvgqCv9R351qXwDRMBfEHyiqnXFq+upXhZn2EmhCiVXp1MYyt4wHaMLXyBJ74b
PbUIB1jbkoUC5uMOBqEZE0ICyavt6TB+5+6xTsbK3O8JMgGsRjAt4BuydZL0uORhgXIigDFItJJU
UjVt15BxwkwIcZizy4iqOr/On8jvXOGqC0uFE2QGlLPCIbERkdBXKlEo07eqW1WRS4vw5pOsnyET
IOgeRbauUwzWUV6KhEqCUmX7qqVTSq+JB0XKkL5VsEScWqEsGek+dNmVMQMEbGwq+N8BAN4vhbEK
ZW5kc3RyZWFtDWVuZG9iag0yNjAgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDQ3NyAw
IFIgDS9SZXNvdXJjZXMgMjYxIDAgUiANL0NvbnRlbnRzIDI2MiAwIFIgDS9NZWRpYUJveCBbIDAg
MCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5k
b2JqDTI2MSAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIg
NDg2IDAgUiAvVFQ0IDQ5MSAwIFIgL1RUOCAzNDUgMCBSIC9UVDEwIDM0NiAwIFIgL1RUMTIgMzQ3
IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDQ5NSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9D
czUgNDg3IDAgUiA+PiANPj4gDWVuZG9iag0yNjIgMCBvYmoNPDwgL0xlbmd0aCAzMDMwIC9GaWx0
ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ1FdZc9tGEn7nr5hHzJYBYwa33kyJSZTYkteE
XVtl5wEmIQqJRHpJytr8pP2X29cA4AHaWqdSsVOhMNM9PX18fcy4HD0vS2OVUeXNyJggjFUI//FX
EcJvmKosToJclfej5+ebRM02xBKqzWz0/MepUYvNyAfOMEpUORvhVx6p8nH03jtfLW+0nweRt1pr
Pwti757/VLoIrLec1aqsNxp3tsynpp9qos20HwWJ18j5ZlYJR7NaKm3CoPCcaO2bIPPWOgIxanpe
vg4zJSwHf91yf/3Ev09kf1eL+cqQcQFrHtLig4e0xHvxSUywyTNxhmWOMPyg9a/lzxSrkGNVBEVK
UaAPF6koDxIbGowVxiHOMCIUHJNJSHThrT79sdbkS53AhYvbLf1V4EgbGO+/2hagj/pJx97D4hYC
xJFZ3RAbMz+CnIql1Gr6B/Mwqb6Hg7zxTGNowI4wdAbkgrU8MGmegQHlBekamVZXNAB1VfxPG+vt
fx3d/Cu/ssQZJMkDmps4TlUKcS5iZ1XaGiUpcX1dIigib6zmAHxwog69bbVYa5OC7yuJwf2eu3zw
V2hjo3wbRFFG8tlXsUu6KOYbShCBoibaj72pNlGQtnvq6u2rMYJLyG/UmUq0n0LUAghY6hV076Qc
GdWoUR4HMQQjLVJCWxDnyqffdT26+TI1z1tqHIPetk9PbBbY4eNfIPfuhi2m2giL1sHpY/RxOZBA
aRrBsssg29a0MGH3vtFpkHu1DsFbNxhKK4t1DU42kDhL8GTizeozNcXMTiHn8AjGIALu17xJSJqv
K5Gx9flvU1Ody7G6Gfgj2xuN4WuYtKALtutq2VL9BKA0236SjTALtv9hLuXSmrW406hD9cACWXMF
kHVxd47NoPoOB5WpJ4I6eNwJD09FbYA+HLUYeGMXM046il4vJRIw95KKklu9hBI2gQRQP1QP4I3U
u9uqn6olfc7Ro7F3Bx4Hh2Ye7y72vZSE1DEHvMTUE14aPE7C46Lz4TEvDdCHvQQloLDOS1HXG0Lp
DVMo36n3VkNxQh9Z8BcAOvZ48VITjCYAGeOd6Rg7xjvgrbQhXOFGQ7/gPIsdYw49O6Zubwi1BbVp
HyFXkV8jqHPWYq+ZYRePaUCgjZqO4GgQtX3phrURCXsHlJO4pGtUNZ+vaz6/K+VRm0T0ZO1u+UCf
fMsGMNdMBAtfzRfMP62YzEsW5YQwa3XEBuZeiYOqvoKyOWOx4jpeCIkPBxoBqT541+B8/J/DMyZs
hgqqhknS1DUgbg8cX44HKoaqLKBUsDMjDge7Mvdk2OjB3KYwVgzCnKknYD543AlvkyCKEdIHp4/R
B2Ge5OD2fLiAS/19S9Hhai5b19PJmSpXanZLpbOe/U5/1ZbX1VZViOlK6jyX4TXXabcJPjQ4+ICS
s7r5zIKoys57OMYaLQdXVI1SdxCvqLk4b6lUS81figow/rJSAnBk5F/IobXb+SRc82a5EBtWPYRH
IJBtamai9+2OqfW6VnLxpocrnG8crrpxzci4tkS7DM/jhYA78/hXNgncOYM793ghJDmNEyPY0mBE
rBxWnMkZmUVc83remWNxemZZWz52y1yO5QXkNGTRGJ8UKaYMLN6AnVzZDDVjN3ZBBhQQMIuX86UQ
WcAXpQt2zGAvOZLCdCPGQXIIdTg5ho+L8OHMOEocTouYBqkvpQUnxETmCDezTDBGBhpELE7DTcUT
xfXVxeUu9yUj+/rqTF2tEAcdSFf8rJs1PSTXPKm0eCPsC6Y/unFIUFvvDllYjQnnUI35i5NGvWB2
F9dq59RcjQPHsYYpijYXvVRVcqkkAyW9atyVu7L2b24xd7wc513a5Oz4DSHxAV2YY7MpHIBz1COh
3KRVxTTeUxegIiIb3VRSiyrcUjXEwoKdQrxCZEuu5U4S/6E0tGQe3iIs1OYSsrZ/ZHyQBUl6Yl4U
6oksGDzuhLfz4LFEGKAP5wIEsJuEDnNh8i/JBsH97gA/uVCvJpwK/CtQ+nGieC2n/vl2ciWzAwuA
YZPcVv6DJ7Com8DkdTjBFh/JcOHxAmplv5LFiM/ev9PP1e7za/m+hnFQzfETZJErIsBrBAEIXYLY
rA2G+OS4lLcvcRo0ULZQjO/k7KVb1HWp0DhxT7T4L/36AFDJ8OGxwgKY0RwMz0QZyaCcQAaFxrb2
9aa7CwKHjINwVJZq/9//EfQ/4es1tYHU49+aujx/72A7wsdD5N3Va+pAmQf1AsYxaMk0qHi/w+eG
32YP984nkBImTloEFS2CvouQKzIcB3gfR5jrNzqjXnq0f9i8Nc5+D8ZdNBhkeERV6zkPl9DDFUPV
CFQLaZauLPYw/fc27smpxCUPZqPCpL2Sl7YxjVuznwCeKCgolaz80owV04xVS3WUK/er43fm6cur
Sy4K5Q5e6In73gMq4ynyfO4NhLKMKmrm/dI/893ViPPr618uJ8efYmHci6Mw4psS/eBHPBYa8gPM
NJE44qCyROzFv7kf/qSMO1ZFn6bClF4eMCCfzLDvDmf0dSEdidMpl/LcG/YtvH/s4LDP1BPD/uBx
JxwQzVQbZodnD6mDg34UgtDYDfphO1tamS3RwgTndexCUy4XvKcuJtPzN5ev8TVET17kuIQn7Z4v
IjjTKnTgC6EO+2L4OAuPumeRIa/tnT5OH/SHLSz4A7HIHknbyuGZQJe/jZ6XZayAfAPkLCkkZZAL
5jSm50zHOOS2y6ko7UbtlL37Az0W19rHmo3vS3iaeffaWnyW1vhsSOUNAWWJl1v63hkJC++ZDnFO
3NBgVNOTKhb+OQYGpH2mVaWxzt2RDJbq6Bf8qhWB5a58d929psdaTVI2fF21IMm1Ys1WIm9Pi6NG
jJ+pR77glk+JySDKx450y5LXteLDfKFThnndfRUT+Vc2Z3ys2vbsFZJc9LGWq0SPulP7oAf4vQzh
8MG4lpA7fMoL8E4OegWn+yhPr/Vs5eY9uLXzrzX8puEZPqGBJUEf7/DxLrL9+4EpOPuTT3A1q9UD
szRLPqkqJRvaz8G8BTNWd8qdvCeHsLQ7HSFWtqs12wJOyMPM7rfVXm7Yb8gNv9eig9AkifRpdG7K
zxpIdnjY4BLHuRBUPNMIRLcao1UGXgaIW3joeopiEaNfLAHHx1a0AbsAsCJwwfIRgiijubvD4g6H
P2o/7c7K5gawSdtbuvnQMb2m1nNM9I1FwyQOP8b5BdTOITUyRMCMAJGAc3CpxqiiBedYzJN39bq5
0ZjVDW3MIBEgyXOvWS2Zf1vJ+QWvG7d/W/cqDHY4kQxvL7y9JBd2qfioLWZPw+LBkR9rwFsClBpr
GzhN1YBUlF3xxp3arhD+ZIUT85mXzAG6N6Dxl3XlS52odT2rmx1Bc6xtgPHI2eK0f/GVMYy/tfDn
XeHPXRARr1jfcg5iCPr8TkvFtDONvcB5Bqszqp/Im9AE7ZJqY0KFD8rgvL/CN2U9/1qoJt9oZpy0
ZnZYzSk0YB6DtSCs0hKiEgHxDGACQJpqzq2EExT5eFGr1Q2GzVJDpJPUTJAma2ZUY8W7G/Jf1yWI
B5trxzrvc/LeA/OtNUbio/Nab4wJ7akxhqknxpjB4yzcdGNKQZx9sg2LE/PgMBU1E+opzY7f7egD
4r9Afn6+SdT5lAasUE3PR0b9DLD5DRgBhI/KhOqVev9rqOYjk2dBCpJiC9U5VvejCESmcbtxN5oS
T05bcCuwmP9VXQbnDoMwDL6/UXrIR7ABM0d3ePuPUNkGY45V/iiyaBIiul9LSAAvdqP4/f85TJ86
oPpiOnGB3VeHt9N60+jp2psJYuBK4s7cxZ1xbJjz7LYUSzBnSGZUmk4MRsSNNrMJmuOZ1Z0Jby+F
SDSGDerlLCF3QRNv6dRFIAEIntV3FzTG8/Y1Z5UQvIu5GLKOI8tGAsB5nnaVRWhv9JzWhSstCh15
6YI5xBs9BNSwZ7vyunDlbfjb5bwbOYA8y5cH7nWVmL0HLuSJXVBflcyH8XSoa3ULJ+YQRW+qe+XI
bqHUhQtXF3St2wbicD15G1nDDZ8E1t4W9MPGyvr+/QCedYSqCmVuZHN0cmVhbQ1lbmRvYmoNMjYz
IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA0NzcgMCBSIA0vUmVzb3VyY2VzIDI2NCAw
IFIgDS9Db250ZW50cyAyNjUgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJv
eCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0yNjQgMCBvYmoNPDwgDS9Q
cm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDQ4NiAwIFIgL1RUNCA0OTEgMCBS
IC9UVDggMzQ1IDAgUiAvVFQxMCAzNDYgMCBSIC9UVDEyIDM0NyAwIFIgPj4gDS9FeHRHU3RhdGUg
PDwgL0dTMSA0OTUgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDQ4NyAwIFIgPj4gDT4+IA1l
bmRvYmoNMjY1IDAgb2JqDTw8IC9MZW5ndGggMzMyMyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN
c3RyZWFtDQpIicxXbW/byBH+7l+xH5dFxJDL5Zu/xY5w5+bOzllMUSApDgxFy2xsUaXopPlJ/Zc3
b0tRsqgkKFqcDVDkzuzs7MwzbxfF2cuiCI0KVXF3FoZ+YFUA//yWB/AMEpXa2M9U8Xj28nIbq2pL
LIHaVmcvf1qEarU9mwFnEMWqqM7wLYtU8eXsvb5s13feLPMj3XbeLPWtfuSf0st9o9dVrYp66+FK
z3xqsamJVnmzyI91I/ubqhSOpl0rLwz8XDvR3iz0U915EYhRi8vibZAqYXn26z4Pv3/w9wfZ/1bL
9VVIl/NZ84A+PmikxfrVRq5g4hdiDMMcQfDB8/5R/JV8FbCvcj9PyAv04jwVZX5sghB9hX6wKXqE
nBOm4hIv1+3ma+eRLb0YDlzd9/SrwJDGD/V/PJODPupnz+qn1T04iD3T3hEbM38BOSVLqdXiK/Mw
qX6EjbzwwkPXwD2CwF0gE6xlfphkKVygeE26RuGgK14AdVX854VGH74dXfx/vqWJu5AEzyyMfGND
lYCfc+tuZUIXE0HOl5p7Cdjo9vbm1tn70QshvnQNnyGgZQtGTOVZrmr1BdYDeG88A1z9varKJ6aC
4fvyoVaXbfvJCxMQ1dSK5Xdd26mururmc71UzRp5QE6iB8bfF/W6RwF9feCamfVzk6ZqZvwoSukq
7Bbr7hJZvkuBIkHa3JtZvfDAAsmwpq7f/XqBOBbyrTpXiTdD5XzARqJDOnZenIWqUWeZ9S34PckT
ArZvMzWjZ1ef3X2bmmUD1VrQ24zpsUl9M739G+TR2bDEVBNhfny2+xj9opiI1SSJ4HMXrCYZoCLm
vQVX5oAL9P4dppJIPjrGitVrsmRVn6sFJ5FL2oI+iMDwb3mRQLvsSpHRz/i3qSmlomzKoLK8BREG
0EakFR3Qd+V6oM4QrFW/kYUg9ft/M5dyiGYtHiCdRRrBigJZc2V94yfO8860KaT6abcy9YRbJ7c7
4cEpv03Qp/1mgdeK18J4SLGhkRRbXHkGE3nxi2cswZ+Mos4x9CDNKlm49UzAjxvIAPB2YJU4oHI8
YRWmnrDK5HYSbvOdzY5ZZYI+bRW4W24GLJsByxkbZfHuApETCzZjfQWlLR++fkEwJZgpENbnao7Y
jzU/wTzD+y5pZhIbhElEGCbFDFoLDI2MkAuoc/xfPDoHk2iOzUYOa/fEgvmUXng/i3TbJMHS0Zhl
kQ+T7Ci/8jm0CzMtyzzcAdlW9GKGngMWVUGFIAn7h+43IMFMup+pJ9w/ud0JH8BxzP0T9En3xzkg
fvD+0AgGMXufElGi33loAXRk5pZuFvNzVbQKzRiTGRPdNXdfISzgTVGGyshTMViJcYEiAEsGgDGj
HMSLO2iYkFIlGjymfBbKs5S11ei0F3sQyQAiETpofDCXXBTAW6TujrJdJr6OB3S82MHDnSTwiBke
4y1YjOm1d0L5uJ50cSU6UBAdYZwkrrsA7wz9ncQZtnQxdV+QaTZdu6m7B1oCiyLS1D1GGoUJteD8
tcS4M5o5a4Lk8hkgg2gSjUA6AcXjG1mm2aE0sphyDrYep0/jMM6Q1wExGoCYjoDIEIRsgyVMUpDl
3BNBGwMlalgkTwFKr19fjXmvvBmg75p5z9Urbn0oD4WUR3IcSyIoeFVT9jCycAsNRTUXsuIl4epV
zct9+fFBuEjWPXfYAB8L8PmIFTsHoBpq/xjhqRbpNf8uN22zlnZ8l8hERVXu7VmqC99p30GRp8XV
6ExFB4oWaln2JWIYgVH8hU2cDyaWrp3UyAc1cgJxMlYEjaa2XA6eiKW6px8Od6v5i8L9FqZDCnSs
FvyhHqF0JBLfHCmxPEtZW0l1CPUouC21NajL3jEuuGPm51fWGYO84ijNMbBrSvsNs6jdJmik5a4A
T17etGuhq74FFNEtbt5czcfGC9l4bLdHaqLA7Oz7mIACV1p5WCee1YcYBo3pXlio00E5vd0JH5pZ
GyPns93H6NNxiaONmS4Q879LPaAodDmVw83o+Wv16xyDzWp+vuJU/dNc8bfs+u3d/FpKAguYQ9M1
sncU7WbMSA5eA5g4aDzsp3OKG7sP18RNnd8xIO5ev5fv1Nukehc/MLO6VzJFBGklAgcEw4j6zBnP
pbyj/iyH9IkiZk7GQTmKwp15JRl80Ah9qx9ajIYUowX8ufzgfac1/7dv39Due53FdrV+mmOtOmHX
SSmu/C/FviIL7Wvtzr6jbPGnsN/xt6trrJVgzmKia6Hh4L0GvuJ3iK+Y5la8/hu3AbIWAGywZDZY
0vzpb3/JWX4WxxFGjKCD7wQzIt7pvb6hbBfpOVY0STIhpTtsva5urpVQ+El9rryrvb8f1/IE+bo9
1mi+1zwgZVRjLTUGObXAVGyxa4yozl2Sflwus6EPPixb0JtPjzVCPVG2Jrc74cPYEsIMc2z7UYbJ
whWBaPiUwoVtZDW0lohE9FmM9Qcdt0A/prKmXs8Xl7dXb7F1sbgmrj0/sEiUU187YRGhTltkersT
HrhCHZLtnu0+Rp+2R2pG9kiGjKRD3yv+efayKKyC3H8H5DTOJRsiF2Q/pmdMR0dko3Rpd8UjlOJB
ucFivQM88bPmRvCRx5YNlv1cSIp/Wl4bDYNo95L3fcJ9IU04hnphXFzzoiq3AOBU81PEVA0JLVk2
f7RrdeeFOMl2HuhriNe6k1S9J5UrN/DKt+i66y5i7rLHqkNPvvAS0dLJEdqNh/MHgApapVf0fkuz
XkHBmADAaPGanphFsoHlZsS+Mw8Zko/a8tWh42QrjXpn1LLBnGXkBvfHc7sxQ6qWgZSTBwivh5SR
QcpAU9U0XcWSMsyQMlR556EJ+7oDNFZ185nJtGm9og+nG0ugnDtyeSjTAeSsrTuT92H2irR/eoTh
OaOu2m6pep4S6rF0bhW0jDAyeqz2+XbTwb+eZBrh2YQHhapWMnU0a96pSpkoGp5OVsxYPii3k+ce
lvbAA0rfdnwX8EMWpObQH6MANf9lgJpkMJNlM6Htc/2zh8Cc88ebAdnnirt3nmEBzaqs+qZd04fq
y08y7uDVrJblj5g5wQRfPYMNhCplfZ/NjZYJjWkw4zqpBBa0Xqo/00pDdDIwkLnqQra+pfkh105D
KbgJjZj4pIILEOCvURzgLhba8zl8OTdDMr5AcRxLYlEPpshRsIz6ORvvUl7sTIq1EwMCzkcoxCTT
4BkcG1vgQJsSvX3i3wfioxwBhedjjRYhArxBrqJs1xPPvVuXOwm15a0sh58tGSfh6M9ElfWK958f
D//RQKvLZ3hL8iw7CbgwyOwOcNHOPK6DXngxdSCY6XAYwo4Z6mqMwcPfNXkuRq0p0V5dg/EyfcW9
FZiB0nQ08G2paeFnKWsrkRQSUsGTZAw6hr/umUE5IaIKp3ojn8x6sH8sej1670rmk0NL557jl6oQ
IDnhY7xJ1IAwEGlOJu+Wm29YlUE9CIlsuBEbwu1gnieibWQ08ZPQPp/8zM5Vp1v0TddWNcZRxK7L
SLzBUooprt7LzOHQbe3LREGQKmLI4zMS/rrZVmW3xCVM2CniG3jQ6diQXQJsIn0BRVOSSqqZt6s3
+NvCQtervh0LeIInUelRY6nPdaceyq9emLORaGWLNgyxqvC+BsWXpF7zIJTGschehcGVUvhhElHb
uu8bYVnjzhXI2GmAKqEO0KJsSceqKSGXigw8b89s0R+FVz1z2zAM3fUrODoZVFGkSKpbz1vv0sVj
r4MvVtP0nMSxmzQ/vw8fpEU3dhbLBB/BRxAggHi8jVhb7raleI80plgK7DuJ3SzKhbgcS1HdwMHt
eu48EEtOI0njaCgYcpz8u1bZnWqxuTrzEgcuj34JwEzl6ExD4sjrUKBmvdnMpaIbVDUW4kJmdbfd
fhIu0/6VZ9csF11cyITF65zebr3PtMvJjivkP1Ujzy+y6pBVCSU+1V1VVbiSLuO5iODawpEB3vjP
n+mRvwdcDfLME2fDtBChZDl8t+A/0sPdcbZBgXyPykBTKWzyxFNiGFpwr0FV9aDvdzPfyLuYyGfz
hWjeUljiIVFno6MGrpE936LCKW8P+qjyo4LsHtSBOAHzyGwq1K4aCUQR8HwaKUI3USWwGas2Ei8B
10W8FLu9snxdsq9MTY96KIkZ0XXSg6X+Ug8msxd6sLPLs/Jjj+XH0mTpfO8urT4/S9R09jK1dzfP
gDP6P5j+tDwMZrni/rAzq2VjzVdk8d8Aogj9a2xnbsz3H53ZNBYtZoImT0bqzUPjbGiTL4JtswJm
aDsWBdriobEJ288xBRFRbyUIfl43rkPmgBF8QEnUz1eJgDQThtcF39ow3z1jCiJa6mxZc+Hswwln
EVSch+6Ec8YUBG7nP869b8eKswgqziiCx4pzxhwRSB/KmQ7EstHqScfAHqQC1gxRYMwgFnMpieaM
KQjQcr1qxrYEGmwSa2QBgdXO/wBt/nfqCmVuZHN0cmVhbQ1lbmRvYmoNMjY2IDAgb2JqDTw8IA0v
VHlwZSAvUGFnZSANL1BhcmVudCA0NzggMCBSIA0vUmVzb3VyY2VzIDI2NyAwIFIgDS9Db250ZW50
cyAyNjggMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIg
NzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0yNjcgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BE
RiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDQ4NiAwIFIgL1RUNCA0OTEgMCBSIC9UVDggMzQ1IDAg
UiAvVFQxMCAzNDYgMCBSIC9UVDEyIDM0NyAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA0OTUg
MCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDQ4NyAwIFIgPj4gDT4+IA1lbmRvYmoNMjY4IDAg
b2JqDTw8IC9MZW5ndGggMzI0OCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIidRX
23LbOBJ991fgEdwKGQIEb37zRTXxZsbOWPTUViVbKUaiZc04kleiJ5NP2r/cvoGiLnScSu1u4lQo
AN1oAN2nDxqn1dHLqjJWGVXdHhkTxU7F8I9bZQzfOFO5S6NCVR+PXp6tUzVZk0qs1pOjlz+NjZqt
j0LQjJNUVZMjbBWJqj4dvdVny8VtEBZRoperIMwjpz/yTx2UkdWLSaOqZh3gSMt6avzQkGwShEmU
6rnMn09q0ZgvFyowcVRqbzoITZTrVZCAGTU+q97EuRKVvV/f3e1/5e9Xqv/WyPGVocNFvPOYOu80
ylJ98iBHsOkLcYZljTh+FwT/rP5OsYo5VmVUZhQFavhIJUWU2thgrDAOLseIUHBMLiEJSr18+LwK
yJdBCgvO7lr6VeBIGxn978CWsB/1KnD6cXYHAeLILG9JjZU/gZ2arTRq/Jl1WNR8hIk88CLA0MA5
4tgfoBCsFZHJihwOUJ3TXhPT7RUPgHtV/BcYq3dbBwf/l6089weS5AlNFuXg8AziXDp/Kpv4nIgl
AKMgizJ9fX117f39MTCZbqCDvlqDC0v51rNGfYLxGBMhAPfeqUn9yDJwelvfN+psufwD5mMwG8W2
V6vlSq2aSTP/s5mq+ULxDMgfq+u2Ucv2rlmp9q5ebM1+P24WLVptm51YQX45CwAKbZQkOZ2N4+T8
4RLHh6sCdIOBQ4ZOjwOTwHb8mLq8+eUUgS3ia3WssiDMADERgCXTlpYdVUdGzdVR4SIHQMjKjJAe
uUKF9F01R7dflhZFJ3UO9m378tTmkR2e/gVxb20YYqlNkDD3Zh+Sn1YDyZtlCXQ32WuzDjvi3muI
L4Q+iAEot8gtiXRWDB+nF+TJSXOsxswqZzQFY5CA49/wIKF4uqrFRhvy77whjkXbRKkyvAYTFgBI
ohkt0K7qRScN4XbQk/ZBBuI8av9iLeUhzru4B35LNCIYDfLOlYtslPnIe9fmwP3DYWXpE2EdnO6N
x0/FbUA+HDcHuk6iZtKOc42VlK8uAovMXv0cWEfwJ6eoY0w94F0lA9eBjflzFZgUWjteSWO6nwe8
wtInvDI4nYy7cuOzQ14ZkA97Bc5W2g7LHVWAiJwyvjlF5CSCzURfIHxM1/0ZuwVShQGwHKsRgj/X
/L2ie4XbGxot4YuoShGUGeIWCg3Mi4xgCzeT1/2E1JQjqUKHQF/qO1JBhqUGzmZjfpIQLi2KvIla
SLo9vuVVaBYyL1tESy2txOzbX451kY2p67crM3fXAoreUmgJIbECF5k0y/ylI7yMftbE51FQ/d4H
ks2gTBgEEkufANLgdG+8g1niEDR7sw/JB4GUFgb21QGpKzLjlIFEnJbpG4BEQZAo/NDVeHSsqqXC
sKTkargc57efIcOgpSgQBQUihdAwwtAEwNICxEKiMx7cgMwaYl0MQ0rUaORby9ist9qLLcAVBDir
txbmKz0T6MK2GGY94iwEAWmHthcbuPmVBG5gr1ZsrqW15MLve0BJ12940UORcx2KnNsUj84Xj4Xg
EVzjqHzEbVsw8n4cYBkBJQQNwh4Kzc2afxo1x8seaxtw58Nq+dCs7kkC8UAL6o6twrZKQjj1ppj/
mb7vLTWNdogxLc3mpt3Ds0iH8Tw8XYwPg/mgcBjJjuoJj+S90pBgyxjO9AivU2FDxzSYQEkF12U3
SPwAML88v+jrXmChd3XJusfqhMswpETCKtaCS3xd5Xoyr1t4T3F9D+HxhafiIdFqVSMVZP3hXrTI
1h2X/wHFSX3A6qEEpNsUJjW+oBXrDf9OH5bzhbwVki6rZIuq3pozVaeR3/0KCg4anPXWVLSg7EJN
67bGJDhIibbsnC2PC9pQ2W2opHzJ+ltC9ykqb1L9SCqTO/ph5nCae8Qc1/CIJc6AgGvuKLyQfGHP
JJHKt5axGRloAqN7POGo2MK9bC3jeSJlfW7ynpEvJswRJXJEQzfSnFXUZhKU93JWACoPPywXIlft
EvBEp7h6fTEiN1Z/I5eZsrtP3gIDFnSqmFGQEmTgSDOYC2fZy800e6KUE+kTuTk43RvvSjWXYnLt
zT4kH87QGHSHr5rRP+RmoXT07Mx5Z/XoXP0ywqxzmr8nTPo/jRT3ZdavN6NLuVzYwAgqwZ67k6Qj
3jiRhReAJc6eAIv8khLIbaM1kyfqc56xm+Zz9Z5qDW7v9LkWei1yRQL8kkAA4i6B94KxP/eGasYS
eBRNhN7Gzr2WmI17hQveaUS+0/fLNVVckCwQz+m74Jne/O+2vrC75waL/eqivMTirfPrXmH+hJUT
LpuxoMX/dD9kdIs04nIxv8O+SY8/vguXHm5dXNIbJIeM7qWjs7j7txqk1XvwALLdGRVQr/1dA+xl
MGvFpUXnUvvdn/mM2T5M0wRTR2DCZ4IX7IEnBZSBMsfg8y1EEJTIQHhznyE/JhvPfOkW/o49o+Q6
JJTz8zKT7yMP8V3Kd/XE3+lSUIErbx62WP3HyIHt1vMUmVng+VWarMcsh9Lg67YwpiKtgEcAs4ss
8SOhav+iPZfSsqK7u4DM2aDExKYHk/EJvjYdJJXB8uH14dTc9/MIC1Cj+UvvWGmrrb//h0vOqSp1
kC6rKb9DCyg9ZcNXV7JNqWow2VIpoK3mifytZWzGBvbZ5i3dmfD4DJDVHnlWo/gXq+a0XzUXUDUf
5nLTYct02Dqna9A/w3wAf3SyU2PBJbPe69063sSDRTyInqjgD08kmzHE14rUJliD78wdUhgs4G3u
Hc41fJz7IFgppTFqKZbiFoAxxiPnMqbOR+Oz64s3+IhzOIYaF1eXxzuusHmJGxrwhkiHHTI8XYyL
CAAOZ9+dui8c9kVabPki66hFmyiofj96WVVOgfgWxHlaCnWjFqQgywuWG7BY9KpGt6mhfV5QZYS5
BW6Qb4OeLCGNoagq9AO+fkoRKf5Z8tgm4S36vOZ5f+A8A1Ys4FHJ4IIHVb0GmGIpil8xM5mT0Zpt
c2e5ULdYmhR6FcB+6To3zq+kmi2r/IABXenLXjePLDzhztZPI3jdZbJLb0dkV0A0Dp4jIbwYT6h9
DWxD2IItZQAuGrykL7Jg0alc9dQ37iFH8lJrPno9Ey95pU+8yzkWYlZOcDfAUEnHUDkHcVI/wooJ
uDWF/TdAnrD6uGW6zfV9kMBC+GiF4p+YMwHmVKPVarlS8wX1VcOT2/rDPZB9CI8wfUcSNjdVIgdb
8G6I+jXSPmVeExk1k6W/LsrNST/i7UjPIdhviGU50nuKLtnS41FU+9cjS6RU4zpt0qhHVpkveKaq
lQwEIfp/xor1vfIzfRmIw/dU/9XtcsVnAScXcb73Bupln/3G7LMdqcVCasDZ+lVg9QgbrzvAHiOm
whS9CICy9NvDieMDZpo8CyIpYhM6Gb3zMGyA7zCXa9PRtYmrcPzzXvxZXU2lgVd8M32uT5Jv8Anx
kOuwAyTJTnmFqMiQ6wt6s4FeBhcbDapT8kOmj4MQb71NknOVgVc75AFmOVYQEwQycgop19xruSeD
XnWhYMBkVLGE6Ey18CKZoKbSl5nrViY8rpCOrP4g8obX8er7vnTukC/dt+LLdvgqfBpyCsVwnIem
bjkXITFV/WH5pzRbynx0C1GrgKnQPMqTe+jDGkysiOKCeozZKJVFqX6FOHFP9ZO/m8gr8NevOhPT
tOqcZXBhTpo5+tjo/xRexToRwzB071dkZihN46Tp3A2JqSNi4o4BHQIBAj6fZ8dJk57umE6xn19e
bKfnfFf+Q/p4Ye+3fDCxf5j6RPhaNfuZ469gn47vX1nWIirT3Rj5bqzt4TQ3O9p+P2GE6dqEkbxX
JoyL4UqurjiUIUJ9NoYrkZe9LEu9V2Wdb5ydF7j/cd8un94sq8w+g1mXzpo79PQLgLghPwaz5715
eBzMobMzZIKJJmte8VrFxaK0OnUrvL4fZE08Qr12NmLjAihuZBYP0FP3fNM5DKcjzk0ef4d1hKyZ
lBES5fGhoXpXhRRAwJEo0RadztcRWDU6XdzpFMDmtuc6ceOojpB1oxO/1OhUSAFYDm11OhTThipI
DbVahxbBg3Xbu2AKYgrcNUlwnKXmBJCckUJM2yeDSI4slU2oFzO7iIGqxhTENPHewsz6BTRgcBDm
qLlJBmZmkyiapz4yZNZcZEgG0OB7TTFNXo8VkxqyPHoXg/DCJJh5xHURzCACC6YgInISNctwBgh0
wSfFznJrF4PkgokEY0WxY55YQTbAnBWXQhBp9bRL1FC3hSPMzXWBM2QDxB0rRlDXsCZDw4qvYt1r
BbIBELu1MNdtRE2k6bX30rrpNFTJ1/ciQzJgnF1KCpfNO6HlZ2ZqBzXwE03l/gEMRshgCmVuZHN0
cmVhbQ1lbmRvYmoNMjY5IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA0NzggMCBSIA0v
UmVzb3VyY2VzIDI3MCAwIFIgDS9Db250ZW50cyAyNzEgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEy
IDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0y
NzAgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDQ4NiAw
IFIgL1RUNCA0OTEgMCBSIC9UVDggMzQ1IDAgUiAvVFQxMCAzNDYgMCBSIC9UVDEyIDM0NyAwIFIg
Pj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA0OTUgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDQ4
NyAwIFIgPj4gDT4+IA1lbmRvYmoNMjcxIDAgb2JqDTw8IC9MZW5ndGggMjY1MCAvRmlsdGVyIC9G
bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIicRXbW8bNxL+rl8xH8kiWi+57wbuQ2wLORVNnLOUwwF1
cdhKK3tbWTKkdZz8pP7LmxdytZK1insN7mJES3KGw+G8PDO8mA7OplNjwcB0MTAmCGMI8U9GRYi/
YQpZnAQ5TB8GZ5fbBGZbZglhOxucvZsYuNsOhsgZRglMZwMa5RFMnwc/q8v1aqGHeRCp9UYPsyBW
D/IpdRFYtZpVMK22mlYa4YPJY8W0mR5GQaJqt7+elY6jXq9AmzAolBethybI1EZHKAYml9OPYQaO
5cXXTw/nf/L7J9n/Wbnrg+HLBaJ5yJNbRbREvX10V7DJG2cMKxxheKv1L9Mf2Veh+KoIipS9wAPv
qSgPEhsa8hX5Ic7II+wckzmX6EKtH79uNNtSJ3jg3X3DX0BD2sCoP7QtUB/4u47V0909Okg8s14w
mzA/o5xSpFQw+So8QqoecKMsvNHkGrxHGPoL5C7W8sCkeYYXmF6xrpFpdaULkK4g/7Sx6nB0dPF/
OcpyfyGXPORDkxtI0c9F7G9lfUq4K71Ds2Sq0iHaeVVtyobCeb2AarNZb2BWPm3RhCmadMzfFUZE
oT6Xy3oOk2ZTleiiFLc+aJsFeesxYZ4zc7Vq6kWNAbdv7yGlNCb60AZJRvl55Wwdew2jWFScujNG
ehiriTYRivZr8OHT+wsKTke+gXNI9TBFrwd4s1RFfOxoOjBQwyAPgxxvnhZxkOYQBnEOQ/7dVIPF
t6gmsHlLjWMbRLZLTywq1r/9G+TO2dYRcQMa48XmI+SL6UH65WgASr80NXjYLv9s6o0bOuPe6JR8
hP7PEL8QHSI32VSaXBSjy8mOs+ocJoILl7yFPBCh2T/KIsfhfFM6Gc1QvnXFKEmyGRTd8hZFWMx2
Jt3xAc2mXLXUIeK7mjWPbiHMguaLcIEPMdFiiSEWKYpSEiiaA3omKLzfvWEzg/nd61ShnnBqz3Yv
PNz59Jjbeuj9fosIjZzXTNKiprEONadjbQmbpz9pG3Pws1HgXBuKfQC3cKNtKD/X2iQ4OrBKnAVZ
v1WEesIqPdt3wu0pq/TQ+61iMHViH8umre40IqNMPl1Q6luOTUwUhKGiM/sJZwXBBBnmHN5VK02R
i3GOKiiGPoQQXJF1cLMFC4G5zGptcSZrCxKVq4pTxbYbGwZPYWcI5dUtlq0D46PnbNxrfKGeMH7P
di882rnmmPF76L3GTwrMANsCSYvSSGLjMw5k6hMXWEKVzC9dT0bnMF3DZ8zgmHMU7VIvvmJUkpkZ
IAp1z9SygVrmDCQY0SXMy6aEGjNcAf0ILqWMS1T8CYSgWSOjrKypUfNkOe0L7h6mjrdyGz2QkEyh
SDkj2VjODDl9T7f9g6F039GN3PYayRRIMvPSnSS/lw6j//6gu46W8Ey1LVPOAHtnSyWmy1MMhYBg
apI09VXdmDYXCnHHmGLRqM/8W1KI5wqLNkUl9n++dFucPGiu3GNHq2RjU/N1KMhzJNfoVop09ENr
N8/JpOAwuEOEYtsb3EI9Edw923fC29CPMM/Sl7uP0fuDO0mDMG+Du22SaK0N7oJdm6jRkIFECmBC
gEJlcqIJh/0iXDLr9Yer8R7zWNDn+oOwn8NbzetbAS5qtnKJYKx/NXdjaH+MRHRHwcFKDFDJtyl/
Xe4R7pmZwilSc/iVii8Rn+WQqnLCJBpzJdP547qWUaMtPybEwU41CXRkg4vAq7vsHurUhWXVQOM0
gPdjuaEXtmAzONZNJ4rjuI3i2O5eB1YMjxpzFJKOmsLTzRuewAXI6lZi+IsQA83Ju7tGQoiD/cWd
0CuQ7fd+igjDCyXeP2JbU2C7o+AbOuwfA9snoc7IRLk/Y//EUmhOQAlXmozqJGCo2M50/4byqWT/
vh7y4cdn/k2lL2Dtr1c6oUJhXCDhD/5lKdd7Fm3uRbyInLG57o9AUtvCixcRNFYIXmsGYai+0Lfe
MsQYlLCi+R3h+0JTwWC+DcUSPTwIp/D5tuVVyQkakcBD0EnS5ETn7qj9oNO3fSfcI1KcEHq82HyE
3A85YdFpZmzbzISumRn9i0EnFXyRfjd3OGLV6ArejyjDBHhiSdZcvRuBzN2uf3wafWAgj5yAEbaI
ZLTpD+KgaPfIdc4arTBVIxc4SiYYG91AxzbMP3tf8ULdDV/Ld2LUq91F91q2aM3p3rm3arRlSKZS
j/UXgVPmBFj0ADJqfqu7l3qVOv/dndvh67TyCYZxy8AoaBnyqyCU6129JZEUHQQcx3uEF/3yrdr1
AQl1KhQm/3Z9rut34W+IqtS/7qlhKG6uekz9XQz4vUejG7yFVfJ7zU28jNEH1KLnjLEpvwcM3Xq8
+syLJU6xcWpbJsNN3VEL42PGm8L+H0zx2jzj0XjOzQDCfs2dNnocu7sd2FPtrrkscR8qEckFKHVd
d9L2y1a6XMSEel65FS9cNvsjeFsl5T/ChsekBeJiWzHIaBRo09+6oG6KE88kRz0B6j3bvfB89wwy
Nj2yvYehF9ij3FIVccDuspSiw+GrJCk/QwsEb7R05tbgajS5vBl/pAIccx+AHOPrD+cHZS4qMHx7
y5yj9lukb7sXjgXe39cEiT3cfJTcb40s7Fgj3bnZBOTms+k0BsSNBZKzpBsMWG+Engvd4BM1t46B
zNk+eUL35OESiLHZSAzSy4Zi8JF6TnxO0RuxXtUNdhDSVBjuinJ+ZFInmyn5XcsG32qY1HNRD0vN
65DQQygMmoXvqL0831Eb7qjz/Y465tfqhR5is4EdzJD3Tyq3U87GjpCKduZ3SNlPWwHfTZO1NwDw
CyRybD6zi16oi1rrZ2J9EhSp9WqIqa6qLzXZEq0u6mSOjLjReREgI9s6k2aPGCpxRaHk15HdSyg4
XeIFz6vZejMXcVhA/WEMUBlj+5YsnziwL+9coRVgl0V4ki+DV8yqF0oY2VAd2p0QyyVUbW3Avk49
LctmvRGFqWMO8TF7YMJOLti/mAvx7t0kprhkY96zK2YUSup3Gu+9VSJ1rgl7sDTeMPs1XSlXMukY
zsqLA/fTQyF1vyWv3PER2nZees8ivGbhDfWwThPAOit73QYqsbhe8mzJ/LILswBL1EQiiFckIEOv
DpUvntMjxrHI1gUllD9dztmAzORs8CocbAf5rPnoERPc2ynbY9s34Ws9HP1VtHuRb9TOp8plzcxl
2e/iOwaXGP0bkZFlrU2wEWNJjH4mAfJ7zXCTuNnO95QZiPWKwcG4pOScQUlvOj1RxsxU/32iDwsq
92pBbcV6tRdTz5rBTBSqZ/dOQdpyLwm/n7dGeRTpYoM/2GnDesKMwDDh56vbKOrTBgyDYbE3FrVm
yyf+zt3Z88NnZYTfE/VWqCfqbc92Jzwr2oKaR/Qk7FJtgXZP+/b2UUUxRz2h2PGjPblH+jfIZ5fb
BC4n3AmEMLkcGPgRY/o3ZMQMeQYTwnv4+ZcQ5gOD1whjA3GaUMvwMIhCG4R5u7AcTHAJc4t5LDMg
uMYdhh2ZrrIcLH7Y8UQJKfWAx2SssFsgqbTE2yLstGLmcap4nh2HIcOw5P8MAFrG2HQKZW5kc3Ry
ZWFtDWVuZG9iag0yNzIgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDQ3OCAwIFIgDS9S
ZXNvdXJjZXMgMjczIDAgUiANL0NvbnRlbnRzIDI3NCAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIg
NzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTI3
MyAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgNDg2IDAg
UiAvVFQ0IDQ5MSAwIFIgL1RUOCAzNDUgMCBSIC9UVDEwIDM0NiAwIFIgL1RUMTIgMzQ3IDAgUiA+
PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDQ5NSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgNDg3
IDAgUiA+PiANPj4gDWVuZG9iag0yNzQgMCBvYmoNPDwgL0xlbmd0aCAyNzQ0IC9GaWx0ZXIgL0Zs
YXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ1BfZctvI8Z1fMY8zWyaMGQwuVeXBolmO1tYRkU5SZe8D
lgQl7kqkCoRW8SflL9MXDlICbdfm2MhlYqa7p7un7zmdj17P59Ypq+arkbVB6FUI/3iVh/AbJir1
cZCp+f3o9WQXq8WOSEK1W4xev5tZdbMbjYEyjGI1X4xwlUVq/jT6pCfbzcqMsyDS28qM08Dre/4U
Jg+c3ixKNS93BiE106nZQ0m4hRlHQazXcn69KIRivd0oY8Mg1w1rM7ZBqisTARs1m8yvwlQJybNv
sz3cf+f3O8n/Wsr1laXLBax5SJvPGnGxfvMgV3DxKzGGY4ow/GzMT/MfyVch+yoP8oS8QIvGU1EW
xC606Cv0g0/RI+Qcm4pLTK63D18qQ7Y0MQi8ua3pq8CQLrD6n8bloI/6s/H68eYWHMSe2a6IjImf
gE/BXEo1+8I0jCrv4SADXhl0DdwjDJsLZBJrWWCTLIULzN+SrpFtdcULoK6K/4x1+nD1IvC/uUrz
5kKSPOCxFOydgJtz31zK+SYlwDl0p3fgUatLE4KFN2VV1BjP25Uqq2pbqUXxuDMJWBTFnIM/0iAB
L0VwBOH4n3ebG9WgC8yURG+WkCEQbhYTAgHVF/VQVMW9cRnEEEusIRD3/TDOgzQD249dEKeYt2/F
B63mkWfN5yAvAfZTM/Z6ZizKaGDq4uP5KQatoK/ViUrMOIFoCCAQEu1J7HQ+smqtRlkYZODkJPdB
kqkw8Jka029VjlZfw9rAZS3WexdEro+PHSg2fPwr6J5sJ0g4AMZ4dvgF9On8IC0zMACmZZJYENbl
pUvasBDjXpsECgU6KYW6Bm6MZFOVYGILdtyQHRfliZpxvZjQEfQABsQVAylwllUhPOoxf9clVU/k
TcVSwBBPEBprRt2QgLoqNi12DHVfL+oHAYRpUP+DqVRTLFiLOwjKSFPwSqxh1gdRkDd+bwybWsj7
Qacy9ohTB443zMPOpy+5bQA/7LcIq5R4zcZtNbVOqun8zDis2fMPxnkKfjKKOjEWY18pAVwbF/LP
pbExrA6s4tMgHbYKY49YZeB4x9wds8oAftgqFlLHN7Fs266PKzTK7OMppr6j2IRE0WfUxZrdB9jl
WCbQMCfqXbkxGLkQ56CCpooIJQTLI8GV7FbERC15tzYOdgxbIatMl5Qqrj1YU01lcqqsBN1BOzsw
PngO6vSQ8Rl7xPgDxxvmUeeal4w/gB80fpxDBri2kLi2kGRsfKoDuf4IjTemqhI3oMuZoRA9UfOt
+s00TSHS1Xr1BUITezxUCWxPt4QtarXm/Ypcpgp1dnHGBSeGEoKwNyRnQnLe01qtdwbLRlMgeMeS
NsS3Bt/lLf7JEDuRVLNonOliIHrkA4oFXJKAS8BBHou4s2nDCBodNlaslplI5d9CYDe9OysR1NCz
Zmp6fS2SWAbv1D1g82/nfXgzvG5rWQy+UEEVtnGStO02ihpHJjI7L7D6OhSAn0dgkkLw8g57fwz7
NaUUzAW7ZrVBMRGog+QNmfDYLBkp2xrTJkFTIxAGVAujgP5igA9474rc7Btiml9p1oCZIwJbg3so
Z4lTuUcEEaBQU6Lc1MFhvoXQHdxgvjH2SL4NHO+Yt9kYQeonz0+/hB/OtzgJwqzNt9ZNYdrLt4wC
JdFTbJTSkj2WOAsWwLRzLZBCOdGXF2/P+rRn4AwAMu2JesPj1Q7rKKdQzmNdqhdrmhl5JsesEbRi
kFBB8WNwXfx8J1TE65ZHdoO1dql+xrkgh0h1GCclR3iqhXvJ3+XDdr2R+b6LblFRFXtnluo0aLSv
YJQg4E1PJpWYRgsFM2uhgHmXFN4nzfDsffd6kTEJNLKkOagE14M5mPc1bXqq4XXU7pGxi1v+omyc
VmRbyKmzC4Mmo8qGDhsb4YLQicHZ6D2t0dx4Ht42wNxgVYPcSQ6U4A+9ShOy4TGNT7ti4TCORAJj
Rc8txUiqH/dOsmLb7a8MZealwf5Hcz+rdo/ziWsUrXtE1WFexkl8ZN4W7HBeDh3vmLvhtBxAD2el
s91gFrp2BAllBJn+/YprEeUgT6mZJJvT07fqfIqp5jX/UsBm+t1U8V5O/eXj9IIaQSQMpjDYPavf
Xfnmh5PU7+nG5JI8Bqf3nPLH94MUC7bq/R1/eXbLb6V7vhpU6vSbH74vrcgoEZSXCFwRNkZxaesW
sckRLh8/GGvpHYO8xg2zQzu7zs6OeX4G3+Bgd7fdkY9Kgzm8/Gy+0az/idWgTnS5+Q98F7JOY5j/
ma7ft/o2Qo4HmItyfKy18fDs1fsdgilFc3mx8i+1Ok8NsZSoEZEHjeSPbmmaqqWuwI2SPG81pxb4
Scvc7bg72aZ8pBRn2J5erEph+zpwWZMsf+N5ZQ3zr9gQx9hH2sCcLXv5/Ergdfl/FbjTa4ODJ/9e
Gteu1WcNr8AdzV+YkdBE/6TO1wzgX2i/OJhsbp5PJH/Iu57DhJVrmOthqq+3FTzj6FrU/CxM67ir
CnwZURWC+QaG9UqJP3u9Pwq7Z+jz3s/YI71/4HjH3DWTgfV5ELvnx18kGOz/Udrv/2HbaJw0GkyW
GNs4Pr1mnCoMU2+ns8n12RUORB5hSHF2eXFyYJEoO2YRwQ5bZOh4x7y7sH1mkCH8sD3ivGePpE1Q
bQMz/2X0ej73yqr5CtBpnEtJRioYRxifMd4Goc9cr2bbtmbnbFoqxDCF1vxYyGHEzCC4HrAYw+Cq
6i0M9Osai7K8DXJ6G0BYFvgkSTX/bvkAP2eALmmoVjCVZPiWdFyfLE2xIT5xyj1+zbsEYhqyPNt/
meC0v1WnWMcSHZgxnZ+VcpJlKymr+FgZk1Q5OuFj7yF//L9RoSf+4nMMqy1/bunA9lHOvVjIfdy9
hGTCnZDVZfyPafx3NNkn3fgf8/gfCbzu0VRB0C/pLm/dbJk/lkwgXmyrpapRxxyea3Ifqicp1lB8
VcYgB6tnrIsbpiOjWAGqR/5SafVkqVwzoSrUHu6GkcWdaljcG3y2PN5hcWOFwTJZmLpDC/VC3v3O
kPfdjGldZ+yYn2NoE7QtNkfa7j06Y30CDwi42fT6ms5c4s0SzZue/SJ+kmVgpLT9LRh0I3KodXXv
Q2K/JvY113dRSFFXS6nC05FzptoxcM3EGyYW5tA5WJiAl/jiAQ1qOrmtSKrT0FCI45VEVNbo7vjh
QN7GdaVEJolUjTp9EUyuRALLwwcJy6cXCWVSn3jfts8joDfk9SIg+r1Fz7fZkDQBkEDAYxp48j8E
ZwIBgFuuMRE4PsLqdbZhaC3EakoFBmcQZMG/l/Sq9LLrwgKKOBgtpIQa00zCOQV8Xu1TrUlaS0UJ
xGXIaz4hVYA0pYR1whoHAKHHo2rNpxZ3DHukHVVIGJOWwWFfTLJjfZGxR/riwPGOedv3Mjjh99Au
8wgaODyEZc0Ee1yzl2Q3+AH2X0G/nuxiNZlRxw7VbDKy6kcIul+AEEL4SdlQnatPP4VqObJZSpx8
muLx+1EUQvHzLeBuNCOaDEFwK++BxsLlwz5NS5HSFe5Gqx+AkQtCsIH3af8I7JBnFFo+4SOA9+US
QYuOwczC0Cchw3JgRapm0MrCFkBsAeSJxgtb0DnxPZqWAqYY16oqsiFgiXNrFQbsGcHFzLm9UUPT
Uti05eyjf80IrMjUyBJiMkzAGBh0FhCTAfjoKekKZW5kc3RyZWFtDWVuZG9iag0yNzUgMCBvYmoN
PDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDQ3OCAwIFIgDS9SZXNvdXJjZXMgMjc2IDAgUiANL0Nv
bnRlbnRzIDI3NyAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAw
IDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTI3NiAwIG9iag08PCANL1Byb2NTZXQg
WyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgNDg2IDAgUiAvVFQ0IDQ5MSAwIFIgL1RUOCAz
NDUgMCBSIC9UVDEwIDM0NiAwIFIgL1RUMTIgMzQ3IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1Mx
IDQ5NSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgNDg3IDAgUiA+PiANPj4gDWVuZG9iag0y
NzcgMCBvYmoNPDwgL0xlbmd0aCAyODQ2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0N
CkiJ1BfZcts48l1fgUdgakQTIHj5zZZVs57Ex0by1lZN5oGRaEljWXJJ1Cb5pP3L7QMgqYOOU6nd
ytpVItDdaDT67stx72w81kZoMX7saR2EVoTwz6s8hN8wEamNg0yMn3tng20sJlsiCcV20jv7baTF
bNvrA2UYxWI86eEqi8T4c+8POVivHlU/CyK53qh+Glj5zJ9C5YGRq0kpxuVWIaRiOjF6KQk3Uf0o
iOXCnV9MCkexWK+E0mGQS89a9XWQyo2KgI0YDcb3YSocydHXbw/33/n9TvJ/lO75QtPjApY8pM1H
ibhYXry4J5j4V6cMwxRh+FGpP8e/k61CtlUe5AlZgRbeUlEWxCbUaCu0g03RImQcnTqTqFyuX75u
FOlSxXDhbF7RV4AiTaDlv5XJQR7xN2XlbjYHA7Fl1o9ExsSfgU/BXEox+so0jCqf4SADflVoGnhH
GPoHZM7XskAnWQoPGF+RrJGuZcUHoKyC/5Q28nB1Evi/XGX1g1zw9OMgNFaLBOycW3wVv8X4oIiM
s8B8twJNh6CeJ6WjIJPiRvVNCIbekbqW1eJlWQKJBdAXUGkGhgrBIquZ6icAE58BGTlgNRfXt9fo
MIkcKwv283Z8Ru6xBE642zLJlnysYEaOX3lgmz6eA2+Cc1GUWm+huDaQe8mYnpHKIYht5UjpvAaJ
WxAlkg/0e6MM3Hw5/ADeDI50Dk8CijRQ2kodaLp9OO5psRC9LAwysH+SJ+Tggc1En343Ze/xW1gd
mKzGWgvimzY+NlGQdB//Brp1N4AYCycgTx6dPoW/HB/EbAZ0GLNJEsG2CVpTp1HUOOr5g0rAB0ow
dwJJT4dkMtxs0Es0egZEWywn5bkYYTJJIMzxCFojAup7BpLzTjeF41H1+bsoKbVmmFA1fBx4Cyw0
OBmhZnRBtSlWNRYcPpeT6sUBwjSovjCVN6jXWAru1G0txr5irY7jDfPwNXN04LvNYYHW1hk0azJo
1vb6XF6DNuG1fvtekaqH6N2QPC93qJYMLEOfKarWyCUhF/S7YtCMCQRkV+InrkDj8kJp1L5n7rZi
ArnjiQ9ggm1y9mcmYM4VhnUs547zZO2EqAi7WbMUAkosVhdH1mJ8YL44pLagw3yMfcV8Hccdc5s3
xj1lvg58t/lAD7nx5gtzH0vG1ZTRwyVqh2PDwvdacebk3XtKUUNMmak8F4M5BEEOeRmcXaPF8PNE
MHHjoJiu3ar8QqgFWc16+hnTN5YyGHSQMxO0FFHyNZjIvSACsncOMmCEY7Bhh7CFbBrLgvmVwaGd
DBjddNqJsa/YqeN4w7y24ik7deA77RTnUIfqKLNNlFm20/0DFKoUUl8Gv/eoyFTeEWgEz484ziAi
xmvxL0U6LBWGz2ZB8MevylA0USzk7ORQ9yo+VaDrJxyCifS0U4cuiBMFGx97gmBrl1UoWnLHqCWd
cLfw3S/MlTEs1Ze2iNOWK+CzFm0WTlBwBXos+YPGqvmsTESJH1lsUaBi5riKBZ8lKafMDteTYjMt
p0d+EkadTgKoVzzk1EHP0zTOc8o9OvDd7pHkQZbVJTGqS6JrY6miZVQZEznEEuSKncXgRYWNFLZP
HigGRHl3e3XdpoW+yQCQac/FBeZw7JH6CakQK9waB5FUThZFBaMHt8Kg79yhBYMcVSVKBlfFp6Wj
Il5z7pQV2msqPmHFzcH+Bu1fchVPpeNe8nf6sl6sXFsd1d7nREQPbp2ZisvAS7+BIk3AWetOQRc6
KdDRCwHM0TFCAerS1ia+zTN1zvR9OAmU1wLlKBC1E7VIqD5BLUEMgYEkkzl9BLUWVvKuqPhqiCza
r56wyYBQKzZlE14YmYznTvgLrUul9yLHUhKNOIk2V/gcajiHGu1yqCaDJpRF8bdwsFnN/DBO4jRv
GrmjUHHY7mjpOl4zd6jIYoE7PHqM7A4VIIJtZ/c4/Kdr/ygw9EFrOLwSN0P0fyv594Jnkt+Ggvfu
1N8fhrduamEGQ+jjG/+Jk9p/oqgZ5CInworKKjqQwrKYk1PbfQ9K/Gj3himsWb6V7vVVLSB9DqW8
/C5mpJUIgj4CW9Tj7bFdjs4+vFfU7N0Th75ncahe06jXzWEfwSTYHyzXWzcpYAKcflRv1OZ/fdUp
IL10/AtrKKs15N6FofzjMrzZWd62ulrgGywVV1Fh0oH3iCtIazNabzBefH4xkM7aTzxygo/SJUSa
nHb0u8JaEkObmVG2OkrSdWgBK+byTBLtsNRErh+lFaTOmPMftpxThjqtH8ctNWGkdDX+y4sc6cbd
tHfcn8OrXlnBI3iY4VKQ8EybcaKxcvCubZXQ1qqUg7u7d9fD1vuPq+FP/nx+Ab038aV5oPo4U7zr
KPhHgfezPxGSieaWy1C/ELvfHYNWFIjYHMQQptC2gRPE4PkMFw8vpwMAe8s6pK4u8D50nxi02I7h
/zeHoNXoApVmnAu0mhxLHUZXk8PYV5qcjuMN89C3QDqLsE05On6SoLPZieKwGRudwdyAgKZgew0x
3+XQz4Dzpw4mroajwYfrexz8LMKQ4vru9vxAIVESdmkDUd2qOHnQ8YzzZvqBqgDr/aMd+G4tRFmj
haTJXjrAzHU2HlsBvvkI6DTOXQ9CyV04fMZ4DYNYZpomRdeZQLtMQN0gDKdVSYkUww2r0gsmFAPj
TrWGOWJRwXBU0khiKPxwNBMFTkJW8u+aD/AUBXQJhSPRPVLobtAisfQ46Nwxf4lyjydPILiqFFLv
DUVaojSXOITk0Mz3sfqKUelO8v1+OohwUnB3wBWhm/a8tP4lMzrrCJoBhUs1MfQTSouuPaSgVAsS
Fecv+Mz5zVj0Owp7XOeXLGcbTHjWnSvkvqO+Iscmgb5PBN0GOAPh9EM9upG3WOsT6bfo7xr16Xnt
6vM4tkGcRI7/2sF3tFuiNqlzIKD45BYlsxGPCybYuHs8r4rB9XWeaXMrHNQpGZZ06w6wDJ67v7bg
vaNB40A0yJm/1AOeIdOR6U9m9+O8/YEyYjlZ+0YO3tUY2U2O6Bg01rqx0c+L7YlS7Pi74EF0RSRM
KAqxh5sxslgKz8LNu8uiWm9YdBA8C1Nz+IBWnJsfjPOw7kON60MHc5KynFBwYPOZ7McXyCTPFcUU
9rqObEZkGyy7mfRAsAOOTq0w0FSO+9SCLZfoRahR1ACoBM0ck4aQ+xb76j2824liRZf5Le/WHjmh
vBJT+9wW3d9+fG1V8CNLJzafe6sJoh80gW36au38caDQQ+bYuWmyRE7xTVvByHOFfZx/22DHyM0G
shytKsaPVOKWBX9KgXFt5SNrQ3h6TKhEsH/+UjB0CxGSoqq1Tw0gkaOZMklZYXAa6UXBHGjkp3Ia
HBZWm3UWVti/UlhPHfQ806ZwJvkezqRZgzs62YVlgRz2NZlOXOyRHby/gT4bbGMxGFGxD8Vo0NPi
d3Cdv4AQHPGz0KG4EX/8GYppT8Mj0IHiMMbu67kXhQb6KAZYK5a9EYDA0ESj8QqkgTxjWzQNRQ6P
BsDjLzVnm0ZB2ubsAG3ONsmDNuOapCZI0yBhvjUNdDoR8tVZSspwAOSLIOYbodafG2E8TU0Rx6jB
fYnBIsY6cdCGDsAS544mwpcCDfQYmW3R1BSxxoaUZfZEURxo05aZAXsyRzmea8nsaRoKfaxlzDum
LTMD9mSGL9vYi/OfqqotB2AQBt1oWWxd7J12/+9BH67+EkQspBZnM/CPynN6FkM22jwncHi+5eqW
N6UIYqnKGzw9NNjTwyaLVgRAVV0ZOna/OsX6mfcnDMw8dTG1wQbqjLYVIHPx0dT9AExuc6sKZW5k
c3RyZWFtDWVuZG9iag0yNzggMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDQ3OCAwIFIg
DS9SZXNvdXJjZXMgMjc5IDAgUiANL0NvbnRlbnRzIDI4MCAwIFIgDS9NZWRpYUJveCBbIDAgMCA2
MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2Jq
DTI3OSAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgNDg2
IDAgUiAvVFQ0IDQ5MSAwIFIgL1RUOCAzNDUgMCBSIC9UVDEwIDM0NiAwIFIgL1RUMTIgMzQ3IDAg
UiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDQ5NSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUg
NDg3IDAgUiA+PiANPj4gDWVuZG9iag0yODAgMCBvYmoNPDwgL0xlbmd0aCAzMDA3IC9GaWx0ZXIg
L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ1Fdbc9u2En7Xr8Aj0CkZggRvfrNlTY/rxM6x5DOd
SfrASLTERpY8El0nP+n8y7MXgKQuVJ3ptKexZ0Ryd7FY7PXDxWTwZjLRodBi8jDQ2g+MCOCf3/IA
foNEpCb2MzF5HLwZbmMx3ZJIILbTwZufxlrMtwMPJIMoFpPpAN+ySExeBh/kcL16UF7mR3K9UV7q
G/nIj0LlfihX01JMyq1CSs1yYvxUEm+qvMiPZWXXV9PCSlTrlVA68HPpVCtP+6ncqAjUiPFw8j5I
hRU5eLrP/e9vfH6j+H9Ke3yh6XA+Wx7Qx0eJvFieP9kjhPGP1hkhSwTBR6V+nfxMsQo4VrmfJxQF
enGRijI/DgONscI4mBQjQsHRqQ2JyuX66etGkS9VDBvOFzU9BTgy9LX8rwpzsEf8Sxn5PF9AgDgy
6wcSY+EX0FOwllKMv7IMs8pHWMiEHxWGBs4RBO4Amc21zNdJlsIBJpdka6QbW/EAaKvgP6VDuf92
lPh3vmXaHcgWj5f4UQCVlECcc+NOFWhXE2FuA7B4XoGjA/lZaQPeFu/gC4Ion1Uol3X1tCyBEAHh
i0qAX6nAz+RqrrwYU+mFgpRacr0QVzdXnC0TZcD53vnwGkXDJpyPCrRlErXCY8vCW0i1FMqQlFrd
5V6IcHkYZrnwQj+KUjoTx8e4Q0WGDzUB5WjsSHlGjnHDpKGJm/t3F7irZd+JM5EqcJeBOshAMKR9
R5OBFpUYZHAu8FqSJ5ThvsmER7+bcvDwR1zth1nDNQbsDrv8OATD+pf/AbuzN5CYCyvAGwerj/Ev
JntFm4EcFm2SQLSTtmrDpo8GMbv3DjIBIxiAtx6wp4T2Y4NR1VCsK/BkLKflmRhjN0mgznHJhFIp
lO+ZSNk72xRWR+3xsyqpt2bYUTFHLHlr849Yc9qg3hSrhktJM62fLCFI/foLS7mAOo+l0Mr7o8Xc
E9HqWd4qD06Fo4ffHw4DsqZpoVnbQrM22bGtX4E34bTu860iV4/OoAlC97x4RrdA5fJjhq6FAidm
Rb8rJs1ZQEB7JX3iEjwuzxUVj1NuP8UUusdnXoAdtm3aLyzAmmssr1gurObp2hpRE3ezZisEzFgc
L1aso3gvfHFAuKAnfMw9Eb6e5Va5ydvgHgtfD78/fOCHPMTwebsNOLJTZXx/gdXAxQHABuKY2naF
X29pcI0QfqTyTAwXKqbm7KF7V/z4TDTxzlKxa9u38guxKipL4+TnLN+GCuNeUQXXVpK3wW7uDPHI
rHPlYUyG1207T4AMdQ8luIUGTkOENyCivx+9EFIh7I0ec09Er2d5q7yJ7bHo9fB7oxfnAIGa2kva
2ks4eO/vFY7GOwhSjl0N8/iWSGOFKU/VB2Blsha/Yzajp3BcbiqiP3xVIX4KqpCUUz+RRc2rCiwI
w4VppJOdWXZBmqgEedlnLMGdQatB7JmZS1pj9+Hdn1gvc9iuL10jZ50M4SzqqLCmQobQcSlNNMh6
2DUibBC4BIZ/1Ek1axKrZ2v515503t1eVLyTPdWMt+evabGZlbOD3Aqi3sQC1omsOrbQ6QzbhDuW
Uj38/pRKcj/LmuEaNcPVIuL33A3uqK5GOMzs2DTYBdB9Y0BWYUMUQ5K8vbm86speYfHd3rDsmThn
ELTlBrCl+lxzU5lWRQ23GEbV4PPcsgWTrFQtSibXxaellSJdCwbd0D0MZMwnnN05ZEwYw6KS8UAq
rfaSn7OndbWyCD1qksOaiFnfWTMTF76zfgPjnojzzp6CNrRWYHEUApRjYgQC3KUNli2j3zBrnB2y
s8mgrDEIRxJe8zomESYmcJFAKaHIdEEPQSAllvxV1Lw1VCN9rz4jXAHrik3ZZj/eY5jPyPoLveM5
8p1qMzQ6Ix6d7SauHYcgTigndhYOAckC8Vqhgt39WLs9ARtVzHnf/fqJ07yFigclZLn9VdS3vFFu
WZHBEbq/9JDZX0IgBJ+9+HT0iwWYVDB6D3yOLsW70ZhuJ/x7zjeSn0aCv+2qf9+PbgjuRFbBSJx1
8ipOmryKovauGFkTVuB8znSFHTynZDe7mZW42+MrLnrt62vlTr81BtJj38qLb1JGXomgGUQQi6Cp
toO4HKy9f6sITr4nDZ5Tse9e3brXgqaPEJIUZ9caMxoajUIIM/uoXunNv/ztlIGvDRa71fhpjgPm
hFt7tYxLvojNrH+trn3/kkIXon+G/468QfPDbEmhkPE0kx/Q3A4RCyvlvphCfYVUtyn8XtM7hIQ6
dOfvr7b4strSbEa0csJS6AQRIqWjM+tI8nNmIezLEfxzggmE/zmhfxwZgOdpviDlsDj+77HsvOGD
XZJIDaDFzTa8CNGFlI+J4xDH8/EG/H1k8O7bK91DTUD7Wa4TbgKYC9riF+GSCd2TwsQPNQEKnF8b
mjUSk0A+VRuAb9wErK6uC78bzx32AAq/wfh/kA08ijCFtBuzKVVMKq+7a8K8aaP6ezj+8Pb2+mp0
vEcEppP/VtDTMbnBw/vXuSJEPURUFMnr40V0iI7/2R4RGFXN95PQgl0HsYnEiJ5x9BTvONYpTBf3
T918wOtX48PLc9eVEGF/x1ljYcA5uiq0ge/gfUNguw/vM/cE3u9Z3ioP3G1A5/HR5UcFenF/FOUO
9NtwYUgs4uZojXiCjLnumSYuR+Ph3RXcCeB+gjSUuLq9OdtzR2SyE9cfy+13R9/yRrk7qvYBg+0v
PWT2uyFMnRuSJmml9tXkt8GbycQISM0HYKdxbmEjSgFMZH7GfO0HJuvgSt14VFuP4r1I1nVpW+oj
lI2RT3jTBLKo16JaVXVV1KUorMiK+qwotgrrjH/XvGBa2QrEC6iVe1AYkA0GJJGOBzMML7ai3NGJ
Fyl+qwHN4Q1FeXB9AiPISh+hQoSAd3cV7y3sYDDQD3N74cNmmEBF6OZKZjd2GrpncOebk1aQCKCa
2nXol2diIfjK4TAMvjrCMyf9gntXdAYruzjejk3YAD837QG/wgU1B3MI0E4XOAtDCUCQnoAEU2hs
PhyXeh6dGfKJhyFOAaQO6UZwTe+golnMD7G1SjEcODqe+XNJG8/QzdA6P5UQO9JZEX3DO7N1R5RW
OHi0tFRR86fdqRS755ozeYOO0+j6HFRDcDDKJ1vxHTW5croGtF0v4Jg56G6Dq/kaBiH1Yjg7wuZY
FnOWI09pSxTP/KwQSRuaF7lkQVGIHd6cmcVSOBU4ghL5vCzq9YYNRp8F6cG1q1O74Z+s3aC5E4b2
TjhckJXllMIYQyToYNYbhAcyeUYXA3EJ1yIrNiexDc7PTDrio9I55lubwZrmqkcofbkUn9ij6AEs
zRl/VqR9i5efHb79EsWKNnOf/LV2zCl1C3xf7Zjudj/cti74kKU1m9e9NgTRnwyBae9purmnYYZQ
lmuKBHRxLgloOsw8g7zPmrMNn5m52ZQrfquZP1aJfS34UYo19bMH9oZw8tgmSWB3/YVg6pb7rmWi
CrDIysxYpKTiDKUzhdvXp3Lm70/LKDk1LZl7Ylr2LG+UW1aS7zDCJO1bc5TF1iDrpCl7mznOMZWn
eG+G21gMxzSyAzEeDrT4GdLlNxCE5HsROhDvxIdfAzEbmBjUGERBsZ8m4rEhRDFMskQsBzpLGScF
McKsx0EU5LwECMaAxJhkMiLliBsegQAZaJpFy46ERhuWg4cfGs0mznGrVvP/uq6WLAhBGHajeUCL
ljt5//WE/iwujWkaG1B0oCrzRXtsr3JykjHn7q3K1AbOdMD4riW42poED1rBBLz2VULengiUP1ax
XNQG4ZCgJAMOq4ylKrVvcJJBY2flVpeuDUaeOoSsMsAML4PwAuTaPChJGNgz4dhl9sBjuNrIgKpL
C76qblBSFzFe7tc5hGdxvzYaB+okaPUztOQkQyhD435bCvuLrktRPEUDtjKLZ9NECatWPO9t/GDJ
Zw4iv37MwYBjvsK/I9ygJGGF16vZcgZTvdLCe6QloKqAdJ/gPLdUFnKl6HkZ+FD0UG74Z9SNMmy7
BcBzhN8/ftIjLAplbmRzdHJlYW0NZW5kb2JqDTI4MSAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9Q
YXJlbnQgNDc4IDAgUiANL1Jlc291cmNlcyAyODIgMCBSIA0vQ29udGVudHMgMjgzIDAgUiANL01l
ZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRl
IDAgDT4+IA1lbmRvYmoNMjgyIDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0Zv
bnQgPDwgL1RUMiA0ODYgMCBSIC9UVDQgNDkxIDAgUiAvVFQ4IDM0NSAwIFIgL1RUMTAgMzQ2IDAg
UiAvVFQxMiAzNDcgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgNDk1IDAgUiA+PiANL0NvbG9y
U3BhY2UgPDwgL0NzNSA0ODcgMCBSID4+IA0+PiANZW5kb2JqDTI4MyAwIG9iag08PCAvTGVuZ3Ro
IDM1NDIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSInUF9ly28jxXV8xjzOpJYwZ
3HqTSNZakU05JrTeKju1BZMQxUgiVSQY25+Uv0xfOEQRXHuPxCuXiZnpY/runvP85EWeW6esym9O
rPX8UPnwj1eZD79+rJIw8lKVP5y8GG4jNdsSiq+2s5MXP06tWmxPBoDpB5HKZye4SgOVfzp5r4fr
1Y0ZpF6g1xszSLxQP/CnMJnn9GpWqrzcGjypGE9NH0uCzcwg8CK9FPrlrBCM5XqljPW9TNeszcB6
id6YANio6TB/4ydKUJ596+3+/hu/34j+UynqK0vKeSy5T5sPGmGRPnsUFVz0gxjDMYbvfzDmn/nf
yVc++yrzspi8QIvaU0HqRc636Cv0Q5igR8g5NhGXmEyvH79sDNnSRHDh4rairwJDOs/q/xiXgTzq
pQn1bnELDmLPrG8IjZE/AZ+CuZRq+oVxGFQ+ACEf/GDQNaCH79cKpBJrqWfjNAEF8hHJGthGVlQA
ZVX8Z6zT+6uDh//LVepqhSR5wGM2c6mKwc9ZiFqxLlmdFEEmHrjdrcDSVt8ZG4C51WszcBgmO2P1
PUR5BC5fPt6XgBTC8eflamEGMcbRJzgKwKBLA7ydFtxboFPTl4jj9HU+uuLVu8mA4WdCNbxkQO3n
B9DFSzXcg5/ttuBb5LJyz2EDCOUgSAIF2PDtaBg2GoasYQ4XxHDB2AxCPUUt4+ZMTa5fn2N4C/it
OlUJ3hhCVqSAGNC94/zEqqU6SX0vhXCIs5ji3QtTNaDfTXly82tQ67m0gYYhyO268MiBYP3kvwLu
3A1HDAUKsMYz6kPw83wvhVPAwxSO4wC2bQ67pqr6EZv3rYnJbT5Y6wYrjJPNBkPGQuquwJKRnpWn
aoq1JYasR5KcAsHpN3xIsTzfFMKjGvB3WVKlTbG+WvjI8dag+5YMWtAF1aZYNVAItUzPqkc58BOv
+sxYtUNriyVQ2Pu9xdAj3uohb5n7x9zRA+93Rwi4YVNQ07agpm2wY/ZeYDZFzfaVIVOPT6EkQi09
36FZUvAMfeZoWqfvCbik3xUfLRhBQbElfmoEFocUpuSpmctWzaCU3DEB1tsQK4QVN8VkevrcCs/Z
Wq6v6MbNmu9X0GszriMI7LDcc1zk03zQ4ziGHnFcD7kwD7PWrYcc1wPvdxwYInO149oi5WL22/T6
HNMgIKNG8L0wqZgYd68MxvkYpxCnT9Xw1mCJ2mGYx+gr/NzRmXotp/fV8lFW5WcCLcVfgr9gfCm/
4CpLtdzCphJMvgaq+XUtyOjqHacrlHMU8GzIYl+qBxicLJZvKrBbjJMtdN6Crym9ffc5iAXX6z6G
HnFfD3nLvHHuIff1wHvdF2UwCzVpF7RpJ6Plm2uDWr+lnvEG7ZvqKzqamlgST6t8rf6NwQxDinFg
lA3kmr75YhxuFBg94agPNIyXgF9gJiSci4mu8eYELIgD5RyT3OHkmnXbqdU7BkFiaeKO9z0yNzxj
KT53RZp34gGDZFmTimCK9XlJurHSOZX5UI9ox1q/w0hN9IQ2A6zsZ8xviIBQX2Lhjp4KywJsWY1i
IVKpYlOqOYrBgFmxmZfzZ9HkB72hBKAjcXSIsObp2hA7FEQ98P4gijMvTZtOGjSdVIZhaoQpNdRY
j7FzSY8MMfMtWGNqQjB+faiGhHk1GV10cS9ggoJDxj1VZ6ZOSCzFW4ONcc3umS2LCh4wPFBDdcgE
rPhIsCpV8nFVfLwXLOJ1y/M2NHuMm4/YqDOIGxcBUcnNP9HCveTv/HG9XMlwHjTuFxEx3js0c3Xu
1dJvoLfT4aJzp6ILRQpMi0IBcwwMX4G5bBjG9TjvqOC+1yRG2IiBzwcaeruCwAsBFYTkQYTZLbcy
mkL4NihqFV8H2Uf7FSQfyg+h2kR05llhgZUYazCuUfLoSZbxBB1w1W2v4Fkp0Vx6g7r0Rlx6ITca
aYd4ihX4ydVsf/Q7/y9kv+iIsZ9FUZK10+GzRBJofy71kTfMBRSE2Dv3SZ8D+xMJkGBbN1MZRMc/
yyRJyWL3pszxSL0eY06Emn/Jeqn+cax4L1T/uB5PqPsFwmCsTjsxFcVNTAVtG/ClDYxXYHuOcmh9
vKlM2I2vEAO983f8fdcuvxbvyKpXuvPf8uQkowRQBwJ4E/hNoj17H3Rpr18ZmiveEPGgpt43rGsN
65jJB3BGAhF7v97KcwPL4fyD+Uo7/mmrXsFIw/xvzUsUjIKq6IvJRW7yf2E4QR751jVa21ZrW5vu
/6tc/wq04Kk8p8iO9S8U2iFZA9u7ZAyoaDFPRj1j7/Dq6vICMi+KwgiLnuqazaVNLLnv3SCsyC88
oJ8N2QDgTPLwXjMKmmh4f4Tt96KZQpfyMACtxVlw+oNBx8LTbDnjAaIdO3ewfmTvt7pLbn/P/vtN
xucSCBbJbNwpgVkTtm0ef4sIebkhQ+NcMKDxwuBcUFSllE258S9iWnk9OggcGGEmh0vDX6r67a2e
HZITpTA6zJVMD7hcTuEdcyujYUYjH84gc0guG+EwGJK3D44bLmnCSqYNMSxNhhOclEOaBWES7Pz9
wQVltMQ+F9Az7IjmAY20IReMiMbNVG+OzeakWFx3+zkWUhhaacamiVUGbT6/ow3N3HvzNoFx4JZV
PQY/mb4ZBj0aJMnaOPsjDFQLThdVBU/bG76oeDgc+wcLxp8dtN+6OpTFnZdDSGN738uBoUdeDj3k
LXO/fle4AAwVPic/iND7ggh8yLSweUE0qeUktXJKyDHn7hTzMpEzNRpPh28v4KkBjx08Q4yLq8np
nkUCoAExeiwi0H6L9JHXzIPWXhDfkdunPgzvtYfLHC5sbZG4HVith+PqizwPFYBvAJxEmXQ7xIIU
ZHjKcAtyp65th0HUVnZ5EtCsmOLbA4Yl/i3pzRVBHsPHwQgBdo0Epviz5jNVE2Babygks5psSSB8
2URQOxhPFcKaj1WxhXnGav4VnjMmBBJ4QKbCRmBC9rEU4CcWviwFUD5hz4+rRghRoPv8S0EEwYWH
10cA4ZPwCxZKKGcs1h5PFqTmS5sFXw79BKLwpcG0vKZfTlKnR7S7ot93ZgD5pSe0aSumwyGuvqpr
ldpifEnZ049cU7VSdusNoGfoEseWtRF5xlkwEo4wjqzDq8qg29Q59Cu4wjMDbBBqyuU61YKOxTRt
JgiIaaw9SJLqyYBuOxsyh8uOWmw/ZLM1UfNbyNmCWGMnCATSkuKYteNLsYfc13w+d2jmNfon4yJw
2RIrAXTyW8JRc+5ZO9bgTm4QrSEL+eBxveJFqap1980jmSdtsdPlI7iDlMf31aQV2WbU1wb47Nxu
CzJTCErGIJoce031fspkADIFZEF0+qWaCfEtEe/QsNRx8XNHZxCelAOMsWbQjjb3c95hREetSOqG
Llka3Gy21ddcAsaib0VhmAhqqeSGgjljc425BASAVGv+QK8Vr2fUeNZp3wI6eHa2hnGGXJjBRZ1Q
As5QaSBQKMpw9oHKsmA8Cg4rh2rH3ycjOyOqQj2BLWSev1c1C5xewBj3RbXesOggeOonbj/pOnXZ
/d66zAYYgnVBfyxDaP9urUIrnxr0AMSP9H4Jo4TDCNNQEIdQnYJuGsZkOmTLYUlByWEBJllu0Z2Y
Pch/i+MkbgVM6681RPA7DRG2DcpKgxqCgzDKqQqicbAO3vFWnZ9C5kIuD3d8sNlAdaNVxYAtUFvZ
FPwp1ZriM4YiSeVZ1TTUMCIq7P8tvWp624Zh6D2/Qsd2h8y2/CFfm9MGDDtkt2GH1PaGrF4ytOnW
nz/ykZLoYkkL9JJY1BP5REqkaHXcOJGKruhVxbCuDB0tUmSR2TUXxdtpfK0r67e6MnsyXq+AGsPk
f08oyZ1U8A7u5fJ8e/wjXyIWMBei9krxAwqSymSe8krJl5OL9NW920IZb1vXoKWqkaXpuHp4ziR6
5JXJaJVfsfMDdMTMcgUMzDCA14BHUe7wXFG5rHvKKky9AJO9XQ7aXDMg3InNQTZz4AOnxF4bwOaN
AeT375DexBJBqST0lkQEJUv6GDj5PKGs9dzOarQ4NiKTpcYJfAtUhwIPGJnMw5AbyfafhcAXTe+L
3FyqcsrOLc4M20N2ZlJcmFXmIhVrD2Rz+4gO01MUaRVq/5NyZAvjM/7U3XIIe91IqvoYHaQi3WEg
ltfug55H3at60XIcdpHlf2uXL/M7Wm/Xbn5Amj1KFxJZXPN75PGAvztBOBQwPm8sPD7ibx7pVUvp
QyCcgqdR3qZ8anciXlgY9rvT/igIymCn6V7VD/NRvkiDfJB3+dF1mtbPG6OiutQYyeyFxujM8qi8
tI1Pw22hnS+54QnnVp+bFWo6e4naGeMRcEb/C9PvNw+N22zRtBVuu1mV7iPd3p8EpFzw15WF++S+
fivcuCppI0VduqZomMmvFbwVRED97rzarphlAKZkE4yhx0dtMBnR08ZJ8P1dAtVkoWfNZehAmgVB
NLMoAENdDiDCJkESoOtEa0K0BTsr81WB5Vs3dMcrwzdhEqL16756xpfaT0OWRgumPsTdKBEA8jRd
wTZSVRVkrGstDREs1JInu8qqjZiI8H1nqMqefdvxwcqrVGCd4GmL3lpPmIToMueailbN5itdVXcU
mZAErJlF2AY3EgwJlV0zZ0BFL2XV2wbZFmVTuK8u5ASrAHpJBF9wF4iw9a1dNGdEETiwi7B5X4mX
o9tVYL3sfbv0csIkRBWyl8lRFTzfYJ9p7AnLbHyPcVM3YjkKPFdtsfwPFF56mQplbmRzdHJlYW0N
ZW5kb2JqDTI4NCAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgNDc4IDAgUiANL1Jlc291
cmNlcyAyODUgMCBSIA0vQ29udGVudHMgMjg2IDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIg
XSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMjg1IDAg
b2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiA0ODYgMCBSIC9U
VDQgNDkxIDAgUiAvVFQ4IDM0NSAwIFIgL1RUMTAgMzQ2IDAgUiAvVFQxMiAzNDcgMCBSID4+IA0v
RXh0R1N0YXRlIDw8IC9HUzEgNDk1IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSA0ODcgMCBS
ID4+IA0+PiANZW5kb2JqDTI4NiAwIG9iag08PCAvTGVuZ3RoIDI2NTcgL0ZpbHRlciAvRmxhdGVE
ZWNvZGUgPj4gDXN0cmVhbQ0KSInUV9ty20YSfedXzOMgFUKYCwaA3iyKlVUcS14TSqUqzgNMQhIj
idSSULT+pP3L7csMAFIE7ewtWatMANM9PT19+npWjk7KUmmhRHkzUipOrEjgj9+KBH4TJzKbxrko
H0cnk20q5ltiScR2Pjr5bqbE7XY0Bs7EpKKcj/AtN6J8Gf0sJ+vVTTTOYyPXm2icxVY+8qOKiljL
1bwWZb2NcKVhPjF7qok2j8YmTuXS71/OK8+xXK9EpJK4kEF0NFZxJjeRATFiNinfJ5nwLK+e4XP/
+3c+fyf7j7W/vlB0uZg1T+jjo0RaKt88+Svo9FtvDM0cSfIxin4pvyesEsaqiAtHKNBLQMrkcaoT
hVghDjZDRAgclXlIokKunz5vIrJllMKBt3cNPQUYUsdK/iPSBegj/hJZ+Xx7BwAxMusbYmPmF5BT
sZRazD4zD5PqR9jIC99GCA3cI0nCBXLva3msXJ7BBcpz0tWoVle8AOoq+F+ktNx/O7j4v3zLTbiQ
D54xxIxzOhMOgC5suJbKQ1BAlPmgWN9HCiJKLmux3LLpN/W8Xv5WLwIGn55X7AOLB1h8gVUFaGmA
pbkTi6qpxPwusHhpXtIe77x/WuV5bpYbfmtADAvphO3iNHZxCo411rExGd2KIbLhWsbytUo414Hm
02hs5SxSJnbtmri8fneG8j35gzgVWQSiLYRCDoyWTp2WIyWWYpTb2IIPuMKRk8c2F2P63dSjmy9T
87ylWgt66z491Vmsh7d/gdw7G5aYqg3myle7D9HPyoG4dc7AZxe4uk2lScrm/RA5wLCOErDWDaYV
7T82NQIOYK/Akqmc16dihgnFQajjFsTAAPd7XiQHXmwqL6MZ83NZU3rNMakqePjlbYTwLZl0Swc0
m2rVUscppLd58+QXkixu/s5cAdBgsQyy+TBaTD2C1uD2IDw5BscAfRgOC7y2zaJ5l0Xzztkxs1+A
NeG24fOHiEw9FacQXZBBz57RLjlAQ48F2lbLByIu6ddTbvkh1gSWQYRRrjgHy8s3EQVROMR/UgK4
532YbLv8/cIMfECDYZbKO3/AfO1PbIi6WbMynE2IcL/dhy5NqC0YgI6pR6Ab3E7CbdEBewi6Afow
dHD3QgfoDhSV2TVkIuuTk4bnBd87fAKGGE2QpxJ4nIoJtSeYRQs0KqVsh0WNUzat1hHiuhCYtfGb
knaLhnYEtyGrQyRpQAO5enkcP++93A5FMNHBffOeNpXfRSkd35qexH0kURM9iCRTjyA5uD0Ib3E+
hOQAfRDJtIBuqE2IWZsQfW/5njuq60hDbszC59VseirKtfgNIiKjDJnLzfLmc6TJ/cmODuyI1KoJ
tgaM5dXV24tpALXbzKDi9ytQFYHjW9cgtAcqft5v+3ge3EBo4huhGdgpP4cNmy2gSmne+F0Y+rR7
yeGaCEgtKnWubad05/m+8ajm8/qpgUtUK2orF3Db7dPaf+DloDR8AlPhMT3TgPeScWgl5dIAaYgp
b+N9JwOAhjwMSEfc6/BGlqk7zzMWM8Le1sP0Yd9Kc+QNzmVa58p6zpVT0XVyijf2ddRiYkD7zCIL
VguLYkKcV5fnF33ei2isYZF5T8Ub7oq2mJIV9WsFTi8GcJwvqwYmG+60od4Wnix4yXM1oublpvr0
4LlI1h034hG6DHgsFvMCnTRFP+YGIZNees3PxdN6ufJdewe3V1FUO3sW4iwO2m+g/tPibe9MQQd6
LTgEQDg6RvkNm7htg4M3khp5qwbmOBz4eopYzHXUYzj5TCzzO3pwGKeSvyCMQ8zR94oSKehUbWoI
Xl7js9CKUH/7cUynLOnoHamU95W8ijT9QumVb+kdksRjhPMR3ryQXj8+srqlvfUr8SS48ZJ7kaV8
2qm8yjsq1CGp25DUcfWefvejLoWpY7gb9tTh2BveHoS37eyB8BuiD4cf5H9rj7W70598v0rhpvZ6
2em5eDfFqLKSf8k3c/ndVPC33/XX6+kldU3GC8DOrOeVxnRJ0peVKaZDjg6YYvmjieyuX7owhX7F
wNi9fi3f4Nugbmf/2gxLpjCQPwwAkITK8RqM/t7rHzj9v6fN47D7y9Xnoy8lD+utH2UwjS4+Rl9p
x//O26BWx5MXCri4pM4Ru39fgSG6EqVbG9Cmjv8Pu+PAG+hfUi3P2KkNmcJAmvPXgRh1RRGuA/0a
3EdOuBUof/Uth7Vu58IINCTdAt2TEq7cb5ss50OD+bDYaYK5BXay5xP/kcvyvahpbht4rHG+H+rB
pzAj+DAoWtDVnxdEwXgQjo5x1IAjDDh5B+RubB725j/JdXoXo/K45pLNFZd/n3mJqyFX7jk2T+Bj
KcDM6+L6aSeC/z/ApLcZddbaw+cvkGS9bHL+BhmxGKYA+cHk84dc+GtL3dEL93oaY7qJ8XVPw9Qj
Pc3gdhausU/x4yiYd2/vIepgP2PA8+DTdzNJO6tq31QwVNCUaKicMwzSzK+J8+ls8uECmp0CEmPJ
HBdXl6d7toAa2yn0yhaeOmyL4e1BeBL6N2j7YZR6tfsQfdgeienZw7WuK1WMleOkLK0At7wBcpYW
vvWg8iI8PWe6Anm57noT1bq18m5NnZ+WTVP7GvMI8e/kE6ZABX1zs4ZJZNnAeFXTUIMsK3A3qDwV
zlKp5N81b+A5DPgcpRjiu4G0A3MPYmNloD1GGiunqHdk8jSDbw0MC253rAJXB23qAc4zHCSwsafO
VVyGg2iK6wY01hZmj3Ai6w3pkrbzONGagnSsd7bybzDFLQmpD1eKpK0U2leKT3iKhhTsaKhyPFSl
PFTxS2/2wccSqjyyCU+u+H5Y830zz/RnJq/4cU9r231Z0JzRmEZtl5cLF3dwhTBHiV0yzFARTlS8
dUM1Aqc164eqcB9/uKMBy7UD1mD5+EAZq56vNwtBc13RTX1gdkVmVzwdpjQdpjwd9vh4Fdn+9syU
CKNLUQkr5LwWz8yyXPFOUQm/gA2UlbfMWD2IsPORXJWlPUBpdLJq1hu+C9g9TzK9D3IvOvW/GZ1a
tWYq2EwTml7RPgqMRUoWNMGq3dCw8hSiIG8XeR9juty2nZqoVrR3ITwDoIq/Y+pi39IXNkMFiHpD
XxQWzpNQVLB9zZIaOjbez7ag0pFsy9Qj2XZwexDeZtM02yfrFBQe2jtIRL2YeFytQwcH+mHhx6kn
k20qJjMqAYmYTUZKfA/O8Sswgqu9CJWId+LnXxKxGKkcq4MStrBYlx9HJtGgT7vwMJrBEjgp8SSo
KvKAQ9seT8eRwaVh4eYbkJzFDlS0jspwbxcvoGTkoX0OKpUGnladwNNxgIPoINkzGWhGXV9nXtjR
GfoN3T88sLQM8H9XXyCoHX15YUffJEVtevoGnsBhwBLG62shEPAYAzSDkm1exDpvF1AyLiXEA3GH
LIVjOYGlZShUHORaR3JTo7xcv2C0JVXQ5+DLZWwCbBJc+CYjwQpzgJEIfFXAvTqWliFTDDScapTX
zOpgAzacX+jbyYBC5DHBTi1Py2FyMIWX7A1usnxPMi/sSM71nuTA03JktpX8zwEAJPI8kQplbmRz
dHJlYW0NZW5kb2JqDTI4NyAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgNDc4IDAgUiAN
L1Jlc291cmNlcyAyODggMCBSIA0vQ29udGVudHMgMjg5IDAgUiANL01lZGlhQm94IFsgMCAwIDYx
MiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoN
Mjg4IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiA0ODYg
MCBSIC9UVDQgNDkxIDAgUiAvVFQ4IDM0NSAwIFIgL1RUMTAgMzQ2IDAgUiAvVFQxMiAzNDcgMCBS
ID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgNDk1IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSA0
ODcgMCBSID4+IA0+PiANZW5kb2JqDTI4OSAwIG9iag08PCAvTGVuZ3RoIDI5MzUgL0ZpbHRlciAv
RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSInUV1lz2zgSftevwCMwNWQIELz8ZsuqWY8T2xvJW1uV
zAMtUbbGh7wSNZ78pP2X2wdAUgeVpKZ2Z9apUAD6ANDH142zyeDdZKKN0GIyH2gdRlZE8I9HRQTf
KBWZTcJcTJ4H74brREzXxBKJ9XTw7qexFvfrQQCcUZyIyXSAozwWk7fBJzlcvsxVkIexXK5UkIVW
PvNPqYrQyJdpJSbVWuFKzXxi/FoRbaqCOEzkwskvpqXjWCxfhNJRWEivWgU6zORKxaBGjIeTmygT
jmXv109359/5+53s/6jc9YWmy4V88ogmnyXSEnn66q5gkh+dMQxzRNFnpX6Z/Ey+ithXRVik5AUa
eE/FeZiYSKOv0A82Q4+Qc3TmXKIKuXz9slJkS5XAhvcPNf0KMKQJtfy3MgWcR/xNWbm5fwAHsWeW
c2Jj5jfQU7KWSoy/MA+TqmcQ5IUfFboG7hFF/gK5i7U81GmewQUm53TWWDdnxQvgWQX/KW3k7ujg
4v9ylFt/IZc8gYZ4BRek4OfC4q3A2NfXlxcqBROMKMgDDFUjT4eXYrGmdbGqptXit2qmwOB38NlA
MMgXGODKEwRELiuQwjAinjcVFCC3IEr9gEu4XqrAAEtdiukDaUlACWh6VDoDl7rNDghPl0vHs6hE
6fjmixWPaq+ODkX6tt0Y2DBNTSZg9yTDtD93LrQeC2LLzpzALVLYZqQCK8cKrJU2a+Lq9sMZxrwj
fxQnIlNBCiYLIY5SmdC2o8lAi4UY5Da0ECNpAZvnIgptLgL6rqrB/OvUPG+o1powNl16YrLQ9It/
hdzZ2ziiiRFK94QPkM8mPVmdpho2a9PaNEAbJWzcj+AtDJQIbDVH0DFussLg0SFGA0CDnFYnYoxw
kwIQoAh6IAbuG16k8J6tSqejDvh3URH45gi5Gn7cMsYIxA2T7mmDelW+NNQggZCc1q9uIcrC+nfm
8u709so0oEGvr5h6xFe94qw8al11yBs99H53xIhdDcbmLcbmbahjwl6ANeG2fvpekalH4gRgElLv
bIN2ycE19DNjcHgi4oK+jnLPP2JJzorRw6hXnIPl5amiFPKbuCnk7eblkeUQilt0f2MG3qDGJEvk
g9tgunQ71kRdLfkwpIwJj+td19kszPpdx9QjrusV98rNMdf10PtdpyFtbZNHcZNHrjqOb88waq3L
C4sujJrJe7QBYjk4KpYnAlMolYjxo+CUJwjsjOkAtfI3ro+QiVbOxN2Gpi/0nWF/k8mnatZxDGIi
gDO6pQCnUNmdlQTqXpakHmmyVgn1IjviIFo7WQJ3KvSA7QQEmZfCDKe9oDMBo2i3XrOvUeZx19MG
UMv2epqpRzzdK87K4zYODnm6h97r6aQATDCNp3Xj6YI9fYO5cwvtiSXwtLxwPR6diMlSoOM0Oc7I
1WL+RRkcCfQL/D4Qtay96YekgOKAIiUFgCwgWU6ZcNkEBMh2NbuQ0BQSmkOioJAgZ1rpZLa27QaE
5oAoKCDYhdl2QLQ6nPTXjsxC7uCEKa3Gcu1Hc2JeKAPf1ZrhPBKQFjpJ06ajI5uzuaGNKCQiEoQe
tT5Qa8rptHqtq1m4G2gRbGp6A42pRwKtV9wrb8IwtmGS7ksfovcHWpKGUd4PKVRZcwqyVI6CLp44
IBkryIxm0aPK1fkW9lxAgweLzHsiTjnb14jfPneXDA7TRVnDI4kRgODApTwvOa5aVC7jy7snx0W6
HrYxqyIselMGQ6uqHIg47ZXDstfl4sU9AOImWtwRG+BxvOIs9KdfQbNAi/edPUUH/CoOdlDeBpi1
bYCZ9slg2NpwIox2PhHnTtwBSdjYYkGj3sRAX0tPzQf6ETV3oDyD7G4Sjd6qj2tqmES5qjBtaY33
wtY730FySzUct97SCs7Fp961MvSFzISSQZMLCg0u4Cg8vGSq1/kM8gWYSBPwp1TW8VtSjmKPUFDT
h/RvOQdXre0t6Ww7+3r97vb1g9vnYMYnceMQTAR0CNQZfGeCs7ENwWOA7imeJcO2A49LjQoOdoEg
SZMjLbyj9gNBv7hX7lHCJpjRe8IHyP0wEBXdzmKvQx/907XYlPR6p/0enYsPI8xtK/lLGZLLn0aC
507q77ejK3JI7BRgM4lGm/zAGdE6IHIOGGGUco4qK3lSK7udEql73X793dsdfitf76j3bGffqmF7
RKaIAcVicEDko3LfGV3Z2/ecBDckHHjp3VqmW8NqVvKZEsbKpyXmRka5B2jwWX2jHf87o6On+n43
sUVtmBWJ6VjUNhZNnUX7tVAoY9+Z0n+qPylVqcqZ3KnfRfdO+/CnmvTw6OLqYuJREBBIY+q5g5N1
PkniwCSLobnS2udaRh7KAGidNJT3tCga2+aNbc1f9PJcPDrHT7LcH9/DDtyxbS/h/uDclO4PlACq
jOj8/RGUOTpqDkGFzm7tv8AaRCGJFdP3oofrmvbPB2197t+pwAJqbMCV2IVn3L9b7t95AF284fqL
iE0teEYtOOGuY4L6iuW1Lrdg/HDnzH3zZ8Vto9j6+7NjA2Oam0tqVTL33eACADs1IdCbUjMoqT8F
A92+dm9tiiby9V808oUYUw4bymHT5vA2dGHv3zjw/BRlEQkSCMCDiPF/cXM3Gp92r95p1nTRPpz2
mzWmHmnWesVZOfSLqaMamEC52BHvYeht2AwM2obNeazTuLLDRtjcF9CUEXDzmjgfjYcfL26wUba4
hhwX11cnOxaJu0/JPYs4ar9F+sVRuSmK9sJQXHYN0kfvt0eWd+yRNgEsdagmvw7eTSZWQHDOgZwl
hesFkAsAjek50zXoyzvNgm6CW7vgpo4A8LCumscNQvErIiKAg6iX8ORb1Ngh0OvROIgFxCjx0ZpI
/i5ZgB+8wJfSm4z45gofMSv0jZWe9qwMHB6erVs6+a2Y0dvEYCd8ho9DfOss8YF7kKX7xDXwbqHm
XIw9O59LDFmRq0AFF8CYwIMIl1QYis4bD81QqUj6WwYp/JT3pLXybD13O1i5bPsg0C6w4ZD0gKCu
O5FuVsOwc60Eb3m38axPQO2+bw02MCgNr0p6xyGXmJWopVR4LjF92PDyy+OafdK+SlH7nvSQbn+t
YvpCcca3KE6ofBs4FU6GvIaBQEq7KioxR62rtXNVQqdwd3jkn1BR7bxoQoA3X1Us9Lp0Kzyt+C6o
Cg2NwXNxxYdCLNBADHwJC3w/7BPndHhJqbNXHvbh/iNBajVdrmYC2oS8626IWs2NPAYEx4ULiy0+
XkW2f22YQifEO+JsWokNsyxeWFKUwi2gta28Z8bySXjJZ4o01vZE1y7r5Srktl2HeZSZ3YDr3N/8
QeAwujFT4ZvKFM6J9tFgLDpkAY7NqavqpKSVJ+C4vFlkOc7DU55QAwglh1ItaxtAUb6QPhis10uG
Fl7ZEajWdXn3tLXmDqaw2ZuFO9XA5PmRauCo/dWgX5yVZy3ap8U2rVsa9yV7qXQsph471oGNG+Jh
3V8hvxuuEzEcU4WKxHg40OJnCJBfgRHC7U3oSHwQn36JxGygYfcUNNmcSuXzII4gYG2z8DQYE09O
S9C2AYvOseB1WBqGDOIC5vMfWp4EoiclvSaM8mYB9caRZjGbk95ma8/SMCSp1+pOa+IwTrsivLB1
WrBRvHVcz9NwQMMERX3rvDHQ4u553UL3vHEO+dHZvGFpGAodOr02NuAhWEpjIIFQ8p8uyygHYhAE
ojfabFakcv+L7cyIBPvVSJ52YLAFN44pZIDnMjTIzEDLiAkUoDFFOPJfebKh2Ma57flMKj4BjMVQ
rjzZcwjYl7sgmFOMV0A58WQyw9kbZPDuX2OKMKtqDfwwlSifKvH2Za+7C4PzgjcXDlIAPi+R9pqv
7RQnKgkO1xXLgAQjJMfDwJLBtV7WmCKW7/ak4GMVWusSrPUlePpLcCIFoFuP4D9x+r/cCmVuZHN0
cmVhbQ1lbmRvYmoNMjkwIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA0NzggMCBSIA0v
UmVzb3VyY2VzIDI5MSAwIFIgDS9Db250ZW50cyAyOTIgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEy
IDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0y
OTEgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDQ4NiAw
IFIgL1RUNCA0OTEgMCBSIC9UVDggMzQ1IDAgUiAvVFQxMCAzNDYgMCBSIC9UVDEyIDM0NyAwIFIg
Pj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA0OTUgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDQ4
NyAwIFIgPj4gDT4+IA1lbmRvYmoNMjkyIDAgb2JqDTw8IC9MZW5ndGggMjQzMyAvRmlsdGVyIC9G
bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIicxX23LbRhJ951fM40wqhIC54KI3iWLFimLJK0DrrYrz
AJOQxKxEaknIij9p/3L7MgPSEEHHlWQrcpkYTPc0Zvp0n+45rUZHVZVokYjqdpQkUWxFDP94VMTw
G6cisy7KRfU4OppsnJhtSCUWm9no6IcyEXeb0Rg0Y+NENRvhKDeiehn9LCer5a0a55GRq7UaZ5GV
j/yoVRFpuZw1omo2Cmda1hPlU0OymRqbyMmFX7+Y1V5jsVoKlcRRIYNpNU6iTK6VATOinFTv4kx4
lVfP8Np//8bnN6r/s/HHFwkdLuKdx/TyQaLMyZMnfwTtvvfO0KwRxx+U+qX6kbCKGasiKlJCgQYB
KZNHTscJYoU42AwRIXCSzEOiCrl6+rxW5Evl4IN39y09BThSR4n8r9IF7Ee8UVY+390DQIzM6pbU
WPkF7NRspRHlZ9ZhUfMIC3nie4XQwDniOBwg97GWR0maZ3CA6oz2apJur3gA3KvgP5Vo2R/tnfx/
jnIXDuSTZ5xGJjFGpIBzYcOp4iLkhPaHKt/cVOAmLc+u3l+KBfg8jtBdFl2+bmbN4lMzFx+fl2qM
2M8fGlAxAMtc6SiX4gVeEwiqBbg2le29KE8mFz3nokbunBVjHbkMs/HMe9aG7RjL26nAXArWp2ps
ZangS2k3Jy5v3p5iKHrxtTgWmYKDWojgHBRT+u60GiViIUa5jSxAlxY2SnMBp8rFmH7Xzej269I8
76TW6sjoXbnTWaSHl39FvPNt7YXaIMO9WrxHfFoNJFuaAgL5Ntt0x3+xY+deqxQga1QMvrpFLtD+
Zd0Qik4uwY9OzppjUSILpJCfuKQizLV8x5MUdfN17W20Y34uGuLEHJkQAJd+eqMQvAWL7ugD7bpe
dtKxg/CZtU9+Is6i9jfWEoECeBcPCvdQP7NB3rnIIx1QD27NEsjlQUhZegDSweVsPN4iug+0Afkw
agaZBzGjjHC6K1q6ywiNrH0O+ea6t5/IF1N2qjiGdMB8PSV/FfJ5OSdANfiMJAt+LO8ElCfYlgGM
0JxAnBMH7yeMA+QuPSGvPWqQeg7LIT3vwenwvfINa93wI2zqjF+v+PHeB81lHx+bRdkwPiw9gM/g
8mBcH8JnQD6MTwIpbENOIVIMT+IJq7w5RQpKKEcsPM+hRpru7ScIaoRJy2PwNXItzwPbMnMB526I
fz3ZKkwwSMcYjCDv0vuSfucIopUPwMc+L16UBmyRdDEQoGYrhGGi0P0XfbdroBM76HaWHnD74HI2
brag7HP7gHzQ7a6ALNTDVOaZ6EYh0TCv+amrcnosqpX4RBzi+W1x+1lp4gtPUfckrduAieEKiJHr
ABOPxdYCl0B8n/f8T7UPl39hOfDnCW2Q+euCxsIzIbOYqGez5qlt5lEfrjiOMj0IF0sPwDW4PBjv
wNwH14B8GC5oM9IOrY7D4nwHrYJwcnI6hgwpfE1xmBxJhLXe+iTCSTEh1avLs/MvlM8hk0Dt6pLV
j8WJovk1FBQsLVDQRHvvB/O6rdHbBWguaU40/Jw/rRY8apWmBprx9NbCKyZmLp9JcUaEyvCCIf+R
2s96MyWfE0F3ko9wQWNOcgCfo0j3ooi+uvA2wzQfMYSnowaNgiQW4LHEpWno6hLu6tjXj9QKQdRi
acUd4Jch1O8Ubq3px5nLsmgwzFg4HGWDi9lyug1BA+Un7S/eLx8OMqO/0uBM/+VJgIIq6XUv0zPx
dope5WizDHcuf5gKfver/nEzvaQ+2HgDUyiw6LXqO+5VzfZq4G+W0yWxPsYVXDb4pVV2N7Asss/O
3+G+fjv8vXqvR4ObOv1DVw1yhQHyMgBAd1/SpgMjC9elsOIGqyBcvN7R0nFY24ti3d1NwoXrg5xu
FLcfeA+oPz4s+B0TBWJZwS3kg9p16l9406Lh79tRyFLNV7Bwvu6yA7HcXSi7+mNC/Umh/vxp8XFw
9MW3MRcyGXYArJURa6XbErVDPtZ2sJl0mw1pwA36loL6loL7Fo19C+SYQReB5d0KmmGXCT0dxiYo
3NMauEYSpU6ItS5o3IP6T0G29lvEykADShbYBr/yloKw3TnBerOfi6G5DCjrLcp/cWx+26jEYOW6
llMgQ1Oz8teAF0Xt6ZJkAaRrAAEuXNAScZv5iaQNNZuibOu2CfT4NzxtiHKMICyhdM10zMhYIaCn
Ds2y5/fXRPT3O5TAxNASYDNwikcKT/595qklEdKCaGrGbUoi28WK5wOyQMwJoO7NBGrrdQhQ/pPB
+5qXHugRBpez8QRqupcmOt2zfEBhsE2wsdv2oliMZl2BQiwxFqjrxIAoMQoyPyfOpuXk+vwddoyW
LrWgcX51edxziIVMGWyZWDjsjsHFbNluWyJAxun+4v3yQV+Ywmx9kXZdokwiVf06OqoqKyDEb0Gc
ucIXc9SCAGF5zvIEzOV6W+2N25K+770ooXLiSO1/G+qiHAQmPLR8Qo86LxP8WPGcCAsSvK35bPXL
FiRCBsYLG+uJ2pvmaVFviKL419uc8UJYAtUl92a8zC/zWXCLWaDxuzEoIhVaSietO/J3oTKEnfhT
7PZ3ef9QB1eeRuISytr2e1AK053U5LOwR7wdbxa6VQcB+gbj1MgbMsIMB3dYerui3/fIbXCbpRfh
jxMw2XVYcOYdfaZ5XefHoZ5RKiXOp9JHvGBoYBy82izpd85TcLvhgXhRxDx4uaELUOk76xOen/CN
6QJdX8hooKa+IuRrYr9mtlrP+SoGvVdwHBwUCzT2YhvsZpzntfruSz2eRbX/PPvujVmSKXLWiGdW
WSx5paiFn8AyaOUdK9YPIqwMDIzTD9whtqs1nwrOlMeQvL2z7SSl/oNJqTuuC9cSKBLUmYI3+P5q
5L/pdTdu5THs1Eq6A6UYVYBPIrkzpIpJbSBmQmgEsWvKqYtr/AAinEct2zoNkrZZ+8Vs/h4rjSEX
BWXfe1jqPeTyi/0BztR3fOJDqHinK2G7bANakP7F1sbmAEuT8ABLDy1my3rLwi7ri40FhrdDi4el
uC8vPbSx/d8O8gHzXxEfTTZOTEqqH7EoJ6NE/Agx9isowsdeRBKLt+LnX2IxHyU5lhbYCJQYqMuP
IwM7ivNu4mFUwhTEOurkKa5HHcgLu6PTaRQWi9jD6PY7sJxFKR7Rgafs7iqeQMuoQ+scJCCodLsJ
KlsF+BLbtRDPFqesxdL4OIKk4R3zBNq1ud8P/EcF/+GgsBVD4+ut2pSsOmvQjY/dhIV7VM5++N8A
EqFE4gplbmRzdHJlYW0NZW5kb2JqDTI5MyAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQg
NDc4IDAgUiANL1Jlc291cmNlcyAyOTQgMCBSIA0vQ29udGVudHMgMjk1IDAgUiANL01lZGlhQm94
IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+
IA1lbmRvYmoNMjk0IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwg
L1RUMiA0ODYgMCBSIC9UVDQgNDkxIDAgUiAvVFQ4IDM0NSAwIFIgL1RUMTAgMzQ2IDAgUiAvVFQx
MiAzNDcgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgNDk1IDAgUiA+PiANL0NvbG9yU3BhY2Ug
PDwgL0NzNSA0ODcgMCBSID4+IA0+PiANZW5kb2JqDTI5NSAwIG9iag08PCAvTGVuZ3RoIDI2NTAg
L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSInUF9ty28b1nV+xj9hMCGMXC2ChN4ti
U0exnJpwpzNxHmgSkhhRpEpCVv1J/cue2wIkRVD2pMm08pjY3XPZs+d+zqvBq6oyVhlVXQ+MiROn
EvjHqzKB3yRXhctir6r7wavRNlOzLaEkajsbvPphYtTNdjAEzCTNVDUb4Mqnqnoa/BKN1qtrPfRx
Gq03eljELrrnz1SXsY1Ws1pV9VbjScN4avJQE2ymh2mcRQuhX8ymgrFYr5Q2SVxGgbUemriINjoF
Nmoyqn5OCiUoz75he7j/xu83ov+9lucrQ4+LWfKENh8jhGXR6wd5gs2+F2VYxkiSj1r/Wv1ItkrY
VmVc5mQFWgRLpT7ObGLQVmgHV6BFyDimEJPoMlo/fNlo0qXO4MKb24a+ChRpYxP9W9sS5FF/1S56
vLkFA7Fl1teExshPwGfKXGo1+cI4DKrvgZAPvtdoGnhHkoQHePE1H5vcF/CA6oJkTU0rKz4AZVX8
p42NDldHD//Mlc/DgyR4hnmcpSB5DnYuXXhV4kNMWCuPmrweXarFVjtU+aae1YvP9Vx9etTDEjS2
mi9h94SmAPMYsENzqy5e074C9ZrotU7gV81uAwV/7rRxsQe97+t5CKGcpz5XQxtnBQbmhSjZBclS
x5JVcEkOrMd66KKJNmmct2fq6sPbc/RKAb9XZ6rQ8GYHzuwBsaB7x9XAqIUaeHgc6qJ0ce5VEjuv
hvS7qQfXL0O9b6HO2Ti1u/DMFrHtJ38BvHO3FaBNMdk9Iz4CPq964i7PQcu+CzzbpsIkY+W+1zlY
pwbb5ZC4IC1Y2WxqjTbKwI4QvNGsPlMTTAg5hCqSoAVSwP6ZD8kB55up8GiG/F3UlB49JkUDHzne
ajTegkE3dEGzma5a6DCD9DRrHuQgKeLmX4ylQjZgKZYaZZg+MkOWXPnYBqsHtRYGwrrXpAw9YdJe
cmaedBY9ZrQeeL/VUkxCwWamjdQuHBxkrzegkKLd/QQZ2UVjcP9zdP8ietQFmK6I5qDMaLnA5Q38
V1iWCtDVNZErNGop0ZtGkAGewJCUgocGT5pbpFfEZaqHWDaaKQS5xhuG6B3wcwe77aHKXREX/Spn
6AmV95IH5vaUynvg/SoHJeauP0wmH87RKW3r9m/YM8P2J66oY/RyE52BWl9jovLgpkR2qdH7Mb1S
1uL0Sh7NPouJlgON8qz4+BPzWIAREKQuxCjCGy63yFy2mHqZx90zY1jIG67XGAw9YYxecmaedqY6
ZoweeK8xshKUaIMxUrIFm4GSjYk+aHTR99CgpeHo3WR8pqq1+gz1v9ZohM3i+ou2uFLSot1ib9Bw
GkOPB5unaCCMn0tiyYZh7I4TVcESXL3EaEqjfQs5ihZ4YrRzDZqqBJvIJRWhF2HLlirRTjkmrIV8
p7NZ/dDU8/jQfEkSF7bXfAw9Yb5e8sC8Ne4x8/XA+80HrUbeH0pSMLjwjIf7cSQBNKEuJBwqzvXv
ri4Oou4NF5V3V4x/piQSpIBwsK25Y58tpg306BxIUnkkGmv+NtNPyz3A7X6AhlImUVnXwmy/UM4f
1gteNVSbgqeEIJ0KmjqPg7gbKH1cBGsld8jVaj6FbAv80B8ShbrJ8jw0cc53bbRn5YJMoCFPUkBX
hkLRvqHNjiz08O0jQyGd0xdvh3Yxku1UqCCXOaq4WCguaU3pim9aEtJeSHBxz0gHuwwxKny4vaJk
VrbCUEwQ2h026Q6thCxkw58aw8oevIo/NG+Bvl9QwflhcGVFEffGFgP7Q6uXmDnnXdylLs7yQ+Lj
8P7ISu0L7dz4HxJeEkj7vdr4Qr0dc6zwrzjgD2PFe6H624fxlZQaZgB9BWmt+o5TctrNRKlcDPkM
0EnpLuJNo92uyzlMcTt/pweabvm1eM9XvUKd/64Zi1SRgtOmYIB2ULRpa4wizImB4gP1BwXkPiQd
BtqDeLZly0EmzY/RGFMR55I8wgTFe8wPVJ6i+Ue9q9Q/cMSk5ddJtOcsO/X7T5Dyv/jWF1fsCFCC
SpwOWjP61oy2ffZXXjyhogLJSxxFeL/oKP/Lir2g2LfSBGH+l2qWxi4rfHhUVrZJBd9HXTdQQqqE
JERl/1Jjt6s+RlR8DLgbFB9snPaKDxIs6Lih39vjxfMrdPhccNri9IO+/ri6oy/7Pzg93OD2Mtw3
6OpEupvIvSNdkBIsykCNipO728bxW69lBwZGLvOdA5u2rBgpK60poR0RzxSiIVRGg/XghO//Md71
tQWif8WKNTwClKRZg+71l/VGbG/E9mUk225AyKLPFKnYHpYSr+xkzrVOlpquUP4fROoR/Z4/Ute3
ol+YflAXe/OPRQfE+cfz/GNx/kFN4ZgFarPgpei5jvTrIikOO/0XNFcm723AGHqiA+slZ+YGOiaB
GlfGmT0k70HobcJSj01YaMGw1s/a+o8GRo/JsJNCVU3QbQo5Uxfjyej9m5+xh6XpBjHevLs6O9BI
WkKI+z6NCLRfI/3kzBxqSniveaaPHnC/NopkRxt5W+sjE+vqt8GrqnIKPP8awAVkeM4xiAU5heGe
4Qb4edslIZd1w41koQkkOxwBQP/c1GfokTh60WABzR1EaSb9Ls4Csg3Oeg0eDacbjcVkTT1xHt1r
mGnTMDZkYWyw4YaGi8654sVaLnwBvet6UYBYE80VRUm4GEKnAPsHVJxvDM832eHrFL9cuI0uiU8g
vNf0VlbLltlMb5hBrT7JbY98sM94ScIy5W4JxVv4VTS/eZ7fMh7CzKHqmP65CWxKJjhafY8kxhnn
DayqJekDhqNd0+EMt+EZb03hBNdjD4CmoOQEluBVs6cfytzukNOao2+jGr62RvnLuAjonPfzlrrN
+xbyPhFolGQO5SKg3u6cb2o1W3PqXJI0c/WpViKxnEu6XDwsazWHwqqOa0Bu5acpPuR8u7oByofp
jNHrZr/vft7gvKcGop6tN3N8NvXrnReBaAX171s9zMDY3FqAJ+3h8Smi/fNROn6MNawQuJvV6pFR
FiumVFMlB9yx3DDidKkC5T2Ijw6Kx0ueKpr1JuY+A7JRUthD99nJM/Z35pnnY9tI2kb05npGQhbR
HW13fArlPNMp1zluDuGEaS9pjZbD7jAjLYQObboiTnPoPvqRl7wAJ03RBXhXiyjMoMG70ZkD1oZt
mna2uhAxK4pXJyKyK39mVEiFDmRZrPae1z0ppTeBPziRMz6sVT45VasYeqJW9ZIT86Jsi1FWPINa
4tpH2wslwRh6QrDjV7fg49xfAL8abTM1mlAVTdRkNDDqR/DK3wARfPxJmUS9Vb/8mqj5wPgizoGT
K6m+3g/SBKLEtQfLwYRwPB05AAGO8ViVd3BaDA9Z3MHB9XcdUgaKcsTZxolvD5Bzmhimy0j4ndsD
Tofh0YDEGRpfAHJLZpEqHGBTkSCSyz3dnSV4scNMnPAOb3XGCLTAFgMQEighLiB04AQ7PrqylQvG
vpw0IGqj/Z6SIL9l+a6SBKVFAGcvhK0roFVFleADSNKMBOE9yQoYfGJZiy6wFZQWAVRoRfX/GQCm
nBBpCmVuZHN0cmVhbQ1lbmRvYmoNMjk2IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA0
NzkgMCBSIA0vUmVzb3VyY2VzIDI5NyAwIFIgDS9Db250ZW50cyAyOTggMCBSIA0vTWVkaWFCb3gg
WyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4g
DWVuZG9iag0yOTcgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAv
VFQyIDQ4NiAwIFIgL1RUNCA0OTEgMCBSIC9UVDggMzQ1IDAgUiAvVFQxMCAzNDYgMCBSIC9UVDEy
IDM0NyAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA0OTUgMCBSID4+IA0vQ29sb3JTcGFjZSA8
PCAvQ3M1IDQ4NyAwIFIgPj4gDT4+IA1lbmRvYmoNMjk4IDAgb2JqDTw8IC9MZW5ndGggMjA1NiAv
RmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIicwX23LjtvVdX3EeicySBkCQBD31gy1r
ts6sve6K7nRmsw+KRGuV2JIjyt2mf9S/7LmAlCyL2mwz08SeEYFzw8G546IanFSVsWCguh8Yk2gH
Gv9lVWr81TkULks8VI+Dk2GTwbRhEg3NdHDydmxg3gxipNRpBtV0QCufQvVl8DEarpb3KvZJGq3W
Ki4SFz3KZ6LKxEbLaQ1V3SiCbIQOxk8146YqTpMsWgT+xXQSKBarJSijkzJqRavYJEW0VimKgfGw
utUFBJJX33a7v//G7zeS/70O1wfDl0tEc82bHyLCZdH5U7iCzd4EY1ih0PoHpT5V37OvtPiqTMqc
vcCL1lOpTzKrDfmK/OAK8gg7xxTBJaqMVk+/rhXbUmV44Pzzhr+AhrSJif6jbIn6wF+Vi57nn9FB
4pnVPZMJ8ReUMxEpNYx/FRpB1Y/IKIA3ilyD99C6vYAPseYTk/sCL1Bdsq6p6XSlC5CuIH/K2Gh/
dRD4/1z5or1QSJ4YTZfaDHKX6DQ3dC25TJcVlB90rbubeDwiD9vorcrx91rFVqPFRzdVgF/C5Xkl
y/M9w8UmlwPwwNSVbnuQ6w5ychBKQGIToVAXjZVJk7yDwc3d9QWdENAf4BS8inP0X4KuyyPD546q
gYEFDLxLHLolzy0GGOjEeYj5d10P7r+O9b7DOod62118ZovE9rN/Bb1zNhUvxtqU1q+4D+Evqp5U
yjEJXJdI6TaRQm37wFaqlUWL3VNUyHJdq7jEmF9S6qfRtD5VGVUlpibjGyS6VTFW1IiDabaeMDvm
ThTTApMyyMKKV6BsLXCqkyViETYX4cSyRvRkGQhih+6cEviJIbpIaPOvLTm0SS4KPSBo8iyS5UxA
78AkaD+DLCnbOGgNnZa9HkbUEfceZhSZfuvaQ87rwfc7T6N9ffCeyboyaGwog9WVslRsq3fKOs4B
tgqcKkMpAJfKYEVWtoiq830DmIz06LOBYI+YoZc9CD9ihkPIXhtk3hIt2oDjtshDeTCIYxuMKQqL
6E6aDRYD1CylGEXpaXTVLt6NOGotGQfrA7azwLGkxptHcZCDgW9pP0cwVZpHzoSMyWi/Ee4AnQUo
WpqFnWPvK+jwNOPdS5tnpeE7HrZ5wPbbvJ+9Fd555IDZ+/D9ls88bUPtSP22sXmx/O0d3tZwCTFU
DHK88nsGjRWZcnSqHHXgagXTzzgC+Kie/sxf2DBGgBPZwEIGCCwjhrYb2QZGmAWyCfZidN4Db2re
LOdM84IBpRGBTGUvqJsAeyl/KVyrNdS/PItaTC2cQV+c0SxF0LVUwDISA4BIlBP/XUMQNntaCWgZ
1GNJFy81m/y4q9veOUITLikyOaI0YMiaLM+7rpmlIS2sDl0TozvnoDXolbjBeDUlruYBQmFd0PC6
oXJLHYC3s4CG5yZA1hToGOCP1HhJT5HTNJNWYr0f5TmWuf4oF+yRKO9lb4XrNopTR5SvuA/h+6Mc
U6G0bZTrsp0+bJjebun+FoM8w99R3DVAvA2NHBbjfNzuYfj+5vLqBckVPQBc9P7mFM6pOKNB19iX
qITMVSgkhoMRW5XDaGQYzKgYmYhsHG0mAPcsdC3C6KlArkGXUI9ue+Ez8zYSTmt42hGx3gA0gp9y
xTLhJICNLCYBvFFU/KBZYBwvGnioA7xp9nUMCLkLrOS0oCEmkeyfO+HRA2wCkeQPWeeOQ6f6ToLY
Wja+2B01kEHgVXil6ZHxLGCPhFcveyu8m68OhVcPvje8nPfbFq5tN0XrMEWP/nFLeZZTLBkeaHK0
S8XGxXi7hOvRGD1Kgy/9nlMW+ujtCGQfuP52N7ph76RBwAi73LZSOJd375PtCKjDCDii0pKGchXJ
ButQF1d4JlUI2Pk7/rjYLn8r3bcL7JTmz77mF70HsFXSXB453astRN5Ob+s47t7REJljHSDOuGWl
Z4shYwYBXd3Ye/X98U+8r6wu2b2WQ85i5Jy/7jAcNzupeQEXiw2cmT/PQ/ZjNb45M2/Gm/WjwunN
R2dKY2XUbxrMhpw7qIl+OTOfer0icVEkvjT5Ni5Ml68ma906xvZe8OgnARF4jthrJPbCh+/vS4M/
fhXMhKXJY8/cpo/vot/uRn+fMJzlJvCXM7imjuhC6JWhG2wrvSv9kSdKwPZX+n72IDygjE5f1fnD
2N4qn6LQ7aisi26ICCWWbpjJuFBiJceEKwIMLkfj4YcrnjLYEkRxhePCni3S0h0ZqgK23xb97K3w
bmii6du+5j6E77dHYXfskXe5EJlEVT8NTqrKYTZU94gusjIEElFh0xG8F7xBeX430vIu0sKcO+QJ
4zPPR/WUx1cX/cxbmlg8WlqQkw3NOkyG/eFHzMgFVQeMS4PjFffOlUwv67bzcTFxPOrQV8jldxJg
c5HI5QaNMq0X/9yBzABPxXpBEOqvstooepDutNeUJqjJdo4joqXoEotmcmjdHcq4R254LXBXdj2j
99JEKhTWQ13Y/QK14xT753DK6Lc6RW5N9v1fPfLCZF93zLOgf78vdvLZ22P5LNgj+dzL3grv8jUr
XqEtznO9vH1I1ouRx9U6dHCHPyj8OPZk2GQwHHOR0TAeDgx8j9HxExJiVH8Bo+EaPn7SMBukBmdf
h9Xb8Yz/ODBYuLzuAA+DMYIyDF8CsXpI4/F0t0PTUaT48PUIuP9u4HItknN8wJDkDkC1nLgcPjy5
r2SsF1J4ZHcdgM4mGgE5krwjpaXpKFxOzwY++78DAMa9b98KZW5kc3RyZWFtDWVuZG9iag0yOTkg
MCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDQ3OSAwIFIgDS9SZXNvdXJjZXMgMzAwIDAg
UiANL0NvbnRlbnRzIDMwMSAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94
IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTMwMCAwIG9iag08PCANL1By
b2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgNDg2IDAgUiAvVFQ0IDQ5MSAwIFIg
L1RUOCAzNDUgMCBSIC9UVDEwIDM0NiAwIFIgL1RUMTIgMzQ3IDAgUiA+PiANL0V4dEdTdGF0ZSA8
PCAvR1MxIDQ5NSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgNDg3IDAgUiA+PiANPj4gDWVu
ZG9iag0zMDEgMCBvYmoNPDwgL0xlbmd0aCAyNTMxIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1z
dHJlYW0NCkiJzFdZbxtHEn7nr6inRU8gjrt7bgFaQKIYrxLrWHMUBLD8MCZHMhOJ1FI0HOcf7b/c
OrpneA0tb4zYNiBOV1VXd11fdZ2UvRdlaSwYKG97xoQ6Bo3/5avQ+FenkMVJmEP50HsxeEpg/MQi
Gp7GvRcvRwbunnp9lNRRAuW4R195BOXH3hs1mM9ug34eRmq+CPpZGKsH+amCIrRqNq6hrJ8CoixF
DkaPNfPGQT8KEzV1+6fjyklM5zMIjA4L5VUHfRNmahFEqAZGg/JKZ+BEtn79cnP9hb9fKP5L7cwH
w8aFcnPNixtFvEQdPzoTbHLgnGFFQuubIHhb/sSx0hKrIixSjgJ/+EhFeZhYbShWFIc4o4hwcEzm
QhIUav74aRGwL4MED7x7v+RfQEfa0Kj/BrbA+8C/glh9uHuPAZLIzG9ZTIQ/op5KtNQw+iQywqof
cKMQDgIKDdqhtTcgd7mWhybNMzSgPOW7Rqa5KxlAdwX5FxirNr92Ev/Orzz3Brni6aPrcsy8NAlN
YXMyi42xma+KxIXg9Lg8hhE7O1dD/NXotJfnQd9adNbwojxGWoIRKM8uMRHUxYbriFnkOeCJUVzE
zUlYse6kKJaTSlSUYkTxkFiNAhOFaUODi+vzE8ozx34Nh5AH/RTvEmLsUmX52GHZMzCFXh6HMcYl
zWLGiDDG8/nvou7dfp6b5w03jvHedpWf2Cy03ds/w27ORrxIHddGJLmxezf/pOyopTTG2rVNKUVt
KTl0e81uqgOLLrulvJDPRR30CwzkjIo/UuP6MEgIl1iavG9Q6CroI6YqTqfJouLtWD2qTx9Ylk4X
Yl6GurXQCSkL5CLtTpTTlgWyq5kT6McYzzGRH5mis5AWf7Ti4MtcLnSPpOqDaJYzAcMDlbv9BDDX
fCJ4TycaUaYzysLdE+XO7V55E+RdYezgd4fRIPC6KJqkAURjXTWWZ4El2C1fBTbmYmDvwGFgqBbg
NDCIzYHNFNblhiNQR5cXkLXHBbs3is609c4u+zv4nfYnRYQ38mmsrccIgiiyf3R9Iv2ndKhzxrng
V684S4bUjdEZh3B6HGACt9JuCSPMesSXHDOTM/shMJRQQpsFKbaxJbVwlDaYwtQW5yI52/Sqjsi4
LscKd49vO7c75Xt8u4vZ7diMZT0+tPAgfr26xm4eMUhEVO6EuZdMGmGXLNTwMIipN5ZzGL/HYlP1
+Hf6gSXTmVTJN1DJ48bZGr+PgAM10yaP8ylTeeU2nYDQqLZTBdW7e15SkRuvZU5a4LFe3FIYcb14
CCy1JYCJO7wSedFCAdXq7oHAIXOrlTNFVr6n7QFy76qVnrjj8VVEIMNg4+7pVDuLGdBix2o0GqrT
zbRJMgnT7rRx3O606d7ulTdJtSNzuvjdyROntHTJY1JflcZ17ivqzAlmD6dKH5+BEZecIBT6dORX
MGCZy4vTszWpM5RCd11eHMIxQVqhFgt0NDnyzseSnI+h4Hb1XohwXy0c3zeKp+mfNaVDBXDLRyxE
9ZxfEgmGzNILBj481Qt4rBZLgKcPrGLMGmKnG2ApH9VyTXX9hwjX9WTqW2d7TTj3Fl1vRjxJ246+
HXHh7ol453avXO+LeAe/O+LUZeL2bW6baUknEvPhr1eU9Yy2hht0ipVYMoZaNTyF8+EooHKQv8cB
Y+vLIcja7fr39fCC35SRUzDEVkaO00D8JE2bF3f7pNHuSTOccYAFT5QssFSb0QDPjDmS7b/9z+X2
87lyX0NhpxknK9LslAhhOcJQNGPIdli29V+/krnuilX0vQ56jxtyqtNUNJr8PHMC76ZLODKs5wCG
sqTqTHEYxBZruk37uvPLKUfScnYR3rslvPGE0cWRORgtqR9QYzjCjo13PHgKqOLrwKj/HJm3K3kV
x21esd1rI9y3n9f81436cbogK1LMiIj6JLa/alwDTrfceaACYaORGI87dkDOvY6aTqGW9UTQ8CZY
yaJCR+n+LNq6ywibN4H8pEkjVrJRpTvSaMunIxe+ASKmVT9jF7at1Pfg9fWv7SIWL9KAlkYrXswb
021jerdqDso/Y/Qpvl/OA+48ks6F6x19f8SGj41p+m/hDnrDaqT1pFgNcDz4+cjQc6RQB4S0hfpx
UVGLMupIC13qAcslQ4UbaLBeFM/2Gd/aa1wvs2580Qf0miuUBxiNthRfA3yf+bUNLrv7z/eME5gA
DAdiQ0Z4aBs8zBkPM4eHHioaRCx/+OYW3ajz6QTBanJf/7/4dhP4sD23r33TvHtOR4ue3dHwrZZk
+V4g+obR3f/1mkGpDuiJgrFfwikBY0WGxjzsbYEjCG+KDTFRf9YrTkiL4ksa0Xfw9Zw8mHFiUjLw
45pHmGe9chx6UcoT5GOfkQfdRuKbvzPxb9QrOj1SlVx7uf6iwdd6aw5We0GlP9so8pWhKuJZpmuo
Eu6eoapzuyi37chlE0vz0cb2DoHOscpmPiNlrNKZz1LrZhqKe0LTEaX6iLIhczQ4HY4Gr8+uaOjk
aiCJs8uLww2f2KygC3X4xHG7fdK93Sl3LAxiYre2bjO7fZHka75ImwarTBiUv/VelGUMyL5FdpYU
7qVFUjjhCT8XvkGNuW2fYlHRzoruiTTAJLfqPSZUoeoxj5xG/c5LWNIgGztmhaOXpGHGaSiS1Hio
sfr1jGVFtAqsciqmTJgLF2QliijNF7eU+shfcHFzIYtSqybwjl9vVn1C4sadaqhFpcyIqGL1fGxo
lTuE4ZLShZrkNQKk9YbINoeWCA65zuzmE2clAvYvRmB7pBhgWedoD80QHABMEQwALcnYvGFiC1g6
McKthGxwg2gzhGpgtLDcBKziEckglqxCCaGN0GsGSnk7RPJ2QO0yznhoeaZfor/ql7jxS9r6JWPT
Y++XlP0SO78Ujun9Enu/ROKXf2AqGA/mU7RY4XGcYEY9MI+cZNRk83Vl3OuK/ZM4/1jnn5T9E3+p
f+LvI298ZztYzyANcF+5XJHiEH9Qa2qSZiNnisYlO1NmBXfTbB/uCncP7nZud8odK8m2eLogtO3a
2cnlawl377W2D26Yu3V/hv1i8JTAYMQdQcNo0DPwE2bDbyiIufURjIZzePNWw6RnctQUG8DnbVhY
eOhFqNLmDeG+N2KSZpmI2gvKGMyYeEWmkUjx2ZQi4fYHpOGbkmhFJJpNrtlfjkCaiZSyTIbOIpnM
imYv00pgyuZOszs+wl4fxyv3iXSCwu4+vAvrzZ2dhaluCHJ2JkfZxJ2dazHCyzQSJm/PdpptwZ5v
NTvCquZIRxSSVnMj4yVsgRfe0BxlOUWp1ewIa5pzS/tazY1MI5FR+onmONViR44n4Ca/tiyQ6FjM
bri5hInXdCpRUheUZFWBF2kE8qQJ//8GAIKgQ0IKZW5kc3RyZWFtDWVuZG9iag0zMDIgMCBvYmoN
PDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDQ3OSAwIFIgDS9SZXNvdXJjZXMgMzAzIDAgUiANL0Nv
bnRlbnRzIDMwNCAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAw
IDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTMwMyAwIG9iag08PCANL1Byb2NTZXQg
WyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgNDg2IDAgUiAvVFQ0IDQ5MSAwIFIgL1RUOCAz
NDUgMCBSIC9UVDEwIDM0NiAwIFIgL1RUMTIgMzQ3IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1Mx
IDQ5NSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgNDg3IDAgUiA+PiANPj4gDWVuZG9iag0z
MDQgMCBvYmoNPDwgL0xlbmd0aCAyMzc2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0N
CkiJ3Fdbc9s2Fn7Xr8Aj0LFo4kIS9IwffNFm3TZOatGdnUnyoMq0rda2XIlpmp+0/3LPBYBkWVQu
283MNpmxwHMD8J0PBwfHzWC/abQRWjTXA62z3Ikc/vOozuFvXorKFZkXzf1g/2RZiOmSTHKxnA72
X4y1uFkOhmCZ20I00wGOvBXNh8EbeTJ/uFZDn1k5X6hhlTl5zz8TVWdGPkxb0bRLhZKO7cT4sSXd
VA1tVshZ8J9NJ8FiNn8QSudZLWNoNdRZJRfKQhgxPmle55UIJs9+4+fm9xf+fqH5z23YvtC0uYxX
ntPHW4m6Qh49hi2YYi+AYdgiz98q9a75nnKVc67qrC4pCzSImbI+K0yuMVeYB1dhRig5ugopUbWc
P35cKMJSFTDhzW1HvwKANJmW/1amhvWIfyon39/cQoI4M/NrMmPjDxBnwlFaMf7INqxq78GRBXsK
UwP7yPO4AR+45jNd+go20JzSWq1Oa8UN4FoF/1PayM3RVuG3HPk6bigcnqHLrKudKMvM2sritngz
Jp4Ka3hb4xEmvJYvVAkwv1RDk0OSR+dNkJ+K06OGh0fiYnQSxK+D7OzV+QaWQ20zr2srhmZjbpfm
djw3xNAl5BhiOjlW4FgmmTi/fHmMzAvqC3EgvBqWkNIMsllKS/OOmoEWMzHwLnOQqdIXWQFUzJwX
Q/q7aAfXn9Z6n7TOwbrNur4wVWb63T+hXps790FrLFa0Z97b9MdNz+kqC5M5t3a87Op4hYp3QUC1
CgyhPgFXeLho1bCGk/CABcHKaXugCqxVZI34azB6rYZQZyVR7GoxIXc4UXKIAziqIRbUwQpi5yzH
6lmDFmQ3HBxdFqCePAQDYKaWUxQ/kiSvMvz4c2Uu4tHnBd2BaPKeI/OcAhIkJmH1V6LI6kiFiHVp
6O7oyTNrd+S5152D61WatyWyR9+fSOOz2oQ06iJVSW1ClWzOlMFa3PyojKPzQPCIA6XxOIhTpaFg
K1PJ5mgTCarBvUiwdgcSve4xeMJpGxI9+n4kcqjYkc8mlSo4FlyqLo+RlAVxFO/jM7iQ6vT1IxKi
xGqB/IVyMW5v7pXRwBqktAe+eyhtXXslALIhGR8pco0hwqe4oGLYTtvHDm74TUx10QsoqHagud2R
Y7oV0Nug7NH3Qll42LFPWKZmKC8Yy9dYvkt5qRAY3K6PoldjBWuSowPRzMX0FjBDJH6jX9Hx96QT
M6zNjCnJW9Hy+OpxPuNRBx0E3E/HYrZUVNInv9y1opvD0qft7A+OrDANgg04UYWktOFdHr5DOEjc
1aSbbKSjqDWi0pORoO1PSr97CN6flK3K/owUHm1jRqqUEbuWEbjnVCVHQ6SyY1oiobFvw7SUQSRO
wOrV+enZut0ZEh/yd34ggMdQ5hcTBA5LMf5FpKGeU+NayluWEfARaIvA19gzPUSsg/49WU+DFfsy
FyrkQnTn6SIBKiKAQwKkhKdlXPPKZ2SxoONXSZ6sE3uC18HaqytgTdjKFbMMBsSCXMCWdVGWO/q2
x3YCnf2cJoSJeUu4Dg3kZKbVBACC/ADz6l6mlRVltodprN3BtF73GDzx0Dq8Qp55b9P38w3vjLX+
4HkNGP0rHHkqmXjfYhngWggt4Kl4OeJawH+pOHr5YiRChWCvny5H54SeDQFGcDEhcM13nJJVXxKp
PkKYLREFmnP+6NSq50f6YlVY+7e7D14NP9fuiwOmNdPP5sKP+9dJWFgobxYykB4YRqds1PF9wR6X
dI8VUA/QcRg9sZvW1kZ/Z1bdXujk4VILd1i8I/XqU7yJgjGV2nOyPdR7/AmbAPYvCH8j4VBYeajw
YOR72Hl56rys/P1Qv4sHD75p6nDwaDtPXkr/y4fP5yb8y+gwJuIBj3/YXl1MnZKmv9lW/4vRG+6I
Gkqrl+NzuhggwXB9wN8fIP3/WEzweqjlYc6ZhaNfVXqTbk/T+9kLYQavIq4RZguBv4K/5uv5C9Wx
rOv/19Sus3j8NKtrGywq/9fibb8eb6jopiz+DniHYQ/ssE/t0j5dsYK9WMHuGWcfYDfxM8JuCHZH
sHt5+MBXwt64UwXoFmRTE+4ZIo9JQOQ9NdEGzvw68p9skd7i2wlzPeHeqBMbTVNsmbhJoi7Rr3WJ
b9X2S+FvkOQteUawxeofV004HWVp1+73Z/39502Of7idn6shJreb3IUyGqbYTOe3vXj/cnR3jBhZ
eKDWulxD1idkzZcguzaittfKCb1qgcjdZqNv6T3X1+izdkej3+vOwQ0277GRLzZ9t2l7m3xd4Zti
1eTniXYm0A7JVGCvbugNCUyugkycjsYnF2cARs1vSLQ4g+fjBhraV6slPUMjaPvR6HePwfP4rMEa
ZJ57b9P3I1IWK0TS2ZBaNb8O9pvGCdBcA0JFHjgFZ45VnlWaS9iKby7xrWRIT6ga3gJ3nGynVItL
+Rt9ik4NsZti5aTj56qjpw6POqjomh4MM6iq8B79BV633Rx2NW1nf3BMhcVeTOeYJpiJ3qhGPmJB
KOVd27VUdcUjE9hFAkNl8HllnvRuce2BDecQs4T37YE465biARbAAhrCCmBGJ5fLCd4weP98VBrv
FFggmsX32Q0a4+uvBs8x3Qr4aIPsVtA7ixlBYiXGFN0tGovlhELfp4sEfGO4Zfs7Rn8fojpynLbZ
Jg+rYhcPWbuDh73uMXjimXVo+UTtcqRen3OvllbG2t0r2zZ30m8P/wn1/smyECdjOiG5GJ8MtPge
GP4rGAJHPgidi5fizbtcXA0gSlY6LVxdZLYU9wMLfUXpWQD8vxuMSeTIBrjo0QYqs3FrNiuLGrdz
N7j+DiJDgUUZsElTZJsTKCjIQ2QQ0exAhpwjew4UbVYW0HeEyGn6skTA7mGqmuBAgePIKKJAFcBC
JmGf0SQZlNAzhRXDLjCudXGfDvbnk4BWDKIcbWyFKQWbwtA2k02ygF8oJhwZdoGTmQJ5EbycTwKK
DCJDNtBoUeQyp0DJZmXhMY8U2RU27AvTBl5RYOD0kpcrK0poEoxJRMuBK4GmclXBkdedyMKYNFXM
jYWLh+AxWCfyJCDYQYSzW48pItyZBckmWVSWE4GRA4am9kwDxMvnSUCRIekEa26QGfcpW8kmWpja
MSsxcsQQCzVH9tiPRwFH9mHzBawszO7cmk2yyOF9EyL/ZwCs+3owCmVuZHN0cmVhbQ1lbmRvYmoN
MzA1IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA0NzkgMCBSIA0vUmVzb3VyY2VzIDMw
NiAwIFIgDS9Db250ZW50cyAzMDcgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3Jv
cEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0zMDYgMCBvYmoNPDwg
DS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDQ4NiAwIFIgL1RUNCA0OTEg
MCBSIC9UVDggMzQ1IDAgUiAvVFQxMCAzNDYgMCBSIC9UVDEyIDM0NyAwIFIgPj4gDS9FeHRHU3Rh
dGUgPDwgL0dTMSA0OTUgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDQ4NyAwIFIgPj4gDT4+
IA1lbmRvYmoNMzA3IDAgb2JqDTw8IC9MZW5ndGggMjQzNSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+
PiANc3RyZWFtDQpIidRXWXPbOBJ+16/AI7BlMsTByzV58KGd9SRxshEzla3YDyqJdjSJJRetXD9p
/uX2AUC0LCpOTdXuxK4SSfSBxtcHuo+b0ZOm0UZo0VyNtE4zJzL457c6g9+sEKXL00o0N6MnJ3e5
mN0RSybuZqMnv060uL4bJcCZ2Vw0sxG+VVY0X0bv5MlqeaWSKrVy1amkTJ284cdU1amRy1krmvZO
4cqa+cTktiXaTCU2zeXCyy9mU8+xWC2F0llay6BaJTotZacsqBGTk+ZVVgrP8uAZPre/f/D5g+y/
t/74QtPhUrY8o48LibRcHt36I5j8wINhmCPLLpS6bH4jX2XsqzqtC/ICvQRP2SrNTabRV+gHV6JH
yDm69C5RtVzdfusUYaly2PD6/ZqeAoA0qZZ/KlODPeJfyslP1+/BQeyZ1RWxMfMX0DNlLa2YfGMe
JrU3IMgLBwpdA+fIsnCAysdaleqiKuEAzSnZanW0FQ+Atgr+U9rI7bedi//LtzoeyCcPBGGd60oU
4Ofa4an4LDEpMD3IA0fnJ2N0sJHPRWNVUgDYSbf+CuDl0QnN2QuVmAxWxhAVlXy9hV+ii9ToohaJ
Sa0texu6uKHjDRuFzBoUJU5OlLZpEdfE+ZsXx2iMJ78Wh6JCkxwEaQWMjvYdNyMtFmJUudSBd4q6
oPBLXSUS+u3a0dX3qVUVqc6B3aZPz02ZmmHx75B7e8MSU43FKvZAehf9uBnIqKKw8NlLKbdJKY/v
awCqlK0y4KwrRd7jj65VSQ0YLrEMODlrD8HFGmsUSaAPNCTJK5XkmCUYWvNu6lWsiTfhjwV9sNY1
ugerX7ahQ7YBD61f82Ys3hHTdBnZwMUzJt36taxMeeFrX1CEOGRTP9Li9BPuw1YIWBAH8GtZLIVM
d9KIqT/sHEgYak5aYPExFJxUQmkfDhCm7gmQQfGgPNsXAQP04QhwwOu8/3UeS6o2vqQ2Z8rgQZvn
yjhKJEJOHCqNeSROlYbqrgx4/GgbiTyjK3cACabuQWJQnJS7eoPTLiQG6MNIwHlqEzJB61BodM1A
TN4cYwxydXHwPIPgqeLXc1VTOUsofg4p3gMNyqCD4E1IoMO730ioiCXiuIbIhpgy0DxosAcCEM4K
XGIGwYYcs5aCtYYw3YLXQG01g/AydQ+8g+JBeQR/F7wD9EF48xqiKKJbR3T9bfiK74w3kGgGag6U
/7D0cjI+FM1KzN4DHIDP7AM9xZq/p2sx9dl8pbAerdsOTJm1i89EX2CVcnJ5zVITVnpE+5zQPs/o
XZAnauri8GpoVQZOQA/iBUUexIKEO3ToZMceBJWLO77b2GE1OOxjO9/2VWYHHQWkPV7aLcg6zcaB
u1w0QB92UVGDRcFHpgg+ylz0EbZy6J1ajhMshVYyQnTBarh/HTCEJXFCnC/PT8/u855xU/vy/FAc
YRmtZdcBeAj7dQAf7wxqikv5ntfEfLqeigXzibHXxZ/z25UnrKGhsLHR8OrFHXn6E6Ye3BGs8L56
iKOJb1UhHmrJtj+jd7FgTr9117K62xUv8Je3GRv2nO9KPDLUR05vb0mAIBjm7byBwLJeBavj3ynd
ou4eLCnFViYAQ+1cEVvMatNiVpveCO23oL0Cu7/Sc01OEvxY8JlvlDG0AbJ3cF6k8ewi3ipyJn+1
MxGzDXTnOKAYMLQT7ZK0oydIetnf7HgrH/Ky3nQqD1LCU4ezYljcK/ck6/AO2BZ9SBxOCWCCz5AS
sd3NfLs7fktJUVD4U0NR+DsBa/z4VLwYY044yb/k9Ur+Ohb87aX+/WZ8TmFivYIxXK8bJ+fFxsl2
42Q/ho6XFDuMu+QPQL2fAngHid7f/iFg8/pYvscwDpp5/AO6CBQLrb0FV8ThKqOuJWM43uBFrKFW
IWsSeHGO0AgeS5h4/2xNY///0UucksO4eTAQC/4TKO/C0uT8qYaCUMvL3VFiqng883c73oWcrKfd
GmZDukByvE2xjsBtit0R3cIVVyTtSx5UpAsVT7BLKccFhLkpenHxMF2HTZu0WMtzOfdx43Vh3EAv
/DPEzSPeQvwsoKIXjDCOdlo+Ff+hKzLH+n4hf3l7oUJkUeJsAIhtcVZvATA54okIK5iDi3N3ZJZR
3pcvCmoLIY2tAEqX8tlTc/DPbnpNw9nT7FL0//4qBhe0BXUbJbZq3OJhg4d9Q8LzHcVkwTFZhpj0
iOUUkxXGZDgjHDsvq58iSB5XXXDGK6RBTLS8fLx+zkNof3Jnenn4oJPcq4VTsYip6NVBA15ol/8U
KO95+04evg15CF8zBiDjEtS7wt7t2eZvEk/9aDKX292fo9ZrqPtj6p7ub1A8KM+qOPZkD+aiQYbB
LtBmoDoOr1msYcZu+uwcmzkDd9UEESj9mjgdT05en73iybJhjjMYfLYQsSADZgwg4qnDiAyLs3K7
wQubdrMtvZs+iIeBlyLiUcTuS+pUNX+MnjSNE5CUV0Au89oXAuSCC5jpFdM16Kv2Vgoew/wEOPPT
0Ifd85tveL/waOVlvMjy3tdn/urEVKzD5HmnkhzilScxP/D1R7EFDZZ+5BP3GPpTnIOZDae0eSvW
KzFdflOG5sLpfB7mRv49UOgpOEUYb72S/jQZCiGNrWCut5ElVp/o8XHup1uefLG3WnNvZfkeK6UH
6quHbRGmTQajo1jUhvwMD1dVEO333bxxMXl4ICzKajsspPmrEWFjRJSbiCgIAhsioqSIsBQRtSdB
PExhRM3kGnDr2lm7QNpnooEr5fL6gUgrprMPS3pdYfYC0hRLgDEItHOWaP2WAGJ8ZyFwgOR2AlCl
hqJktA0OeWDG4k7lEJliNr0nB11IO0+3K0Jm9lUEpu6pCIPirFxvMj6vQeU9snHQ/VRDwsNUtMxT
91m2e+9AH1D/HfKTk7tcnEwoKDMxORlp8RtE1B/AWBrxRehMvBDvLjMxH5kK2jcH9wAYAuF+M9I5
TB5ZXPg4msBSDfDhUo53BfLo1LgeT+BwNdhVwcLVP0a6yCEBYM1ZLKI3sFUJxsYF1IxLDnlsjTAA
T52T5sgTOVyZ2oI1u9yS5mhzWMDaXaMUZA1J5ZlFSIGj0Hzd8QLujUvMUwICPS2RZ8NB1yLtHQ2E
NUt4lZY0+wXCC5bIZrgpDeEVoAg8gcPWBTqNT+VtjpqDzT3NwaKoOdgceQJHX7O1FUuVNXsiLmxQ
rsh/1hrm0EWRYi/pF+hUsGSIhzRzpDjX44kcpsKo5L2NY821ZV/FBWxlWfN/BwA6+nh7CmVuZHN0
cmVhbQ1lbmRvYmoNMzA4IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA0NzkgMCBSIA0v
UmVzb3VyY2VzIDMwOSAwIFIgDS9Db250ZW50cyAzMTAgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEy
IDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0z
MDkgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDQ4NiAw
IFIgL1RUNCA0OTEgMCBSIC9UVDggMzQ1IDAgUiAvVFQxMCAzNDYgMCBSIC9UVDEyIDM0NyAwIFIg
Pj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA0OTUgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDQ4
NyAwIFIgPj4gDT4+IA1lbmRvYmoNMzEwIDAgb2JqDTw8IC9MZW5ndGggMjU0OCAvRmlsdGVyIC9G
bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIidQX2W4bR/KdX1GP3YE5nj7mEpAHSyKyytqyVxwHAWw/
jMmRzIQiBZKK5E/KX24d3UOK0tD2ZrHrSACnu+vo6rrruB48r2tjwUB9OTAmST2k+C+rKsXfNIfC
Z0kJ9fXg+ck6g8maUVJYTwbPfxobuFoPhoiZugzqyYBWpYP6bvBOnSwXl3pYJk4tV3pYJF5dy6fR
VWLVYtJC3a41nWwED8Y3LcMmeuiSTM0C/WzSBIzZcgHapEmlIms9NEmhVtohGxif1G/SAgLKo2/c
7u+/8fuN6L+04flg+HGJSJ7y5r0iWKZe3IQn2OxZUIYVjDR9r/WH+me2VSq2qpIqZyvwIlrKlUlm
U0O2Ijv4gizCxjFFMImu1PLm80qzLnWGF1592vAXUJE2MepPbSuUB/6hvbq9+oQGEsssLxlNkO+Q
TyNcWhh/FhwBtddIKAfPNJkG35Gm8QFl8LUyMXlZ4APqU5bVmU5WegDJCvKnjVX7qycP/5erysQH
heAhJ7S2ghztXHl6Vaf3SWcMelXtyN6FGuphjl6Lbp6T9+fqXnvSc332Sg8t6W2kLcIuYPTrGzQN
+c8Z6rNSF6M9ZQ5NnniflTC0iXPF9nYM4nC78+F2TcgGeQ+9GmtDt8czOH/76phcL4Av4AhKlAwv
TtCcucr43lE9MDCDQekTj6bKq5x9MfF4P/+u2sHll6Fl2UG9R7ntLjyzRWL7yb8A3rkbjwRqHaW0
R9RPwY/rnvDKc4fbnfjy2/gK+r1ARRWqRctlmKA4nmSzavWwQh0uKCd4NWmPMFgMJSymIBsYND9a
OqOQIT+brprAYsO4Q9nMeCNcyXE4FaZbOIYe4vD5lVwm5CtGahYdGpp4IqCbcJYWiRzc7xJCzAwi
6pwPm1u6R6QAPIBn+OuELEE39cpCEx47RRC5mlcOUYIPRSMVmOf7HUSgBxyklzwyTw95QA+83wM8
4vpgf5N1+dXYGN1n2tJD65faeg4k1hwcaYpRBafaYKrXFi3+Yl8TWcr1t0cTAj2giV5yZu6rrZ6c
p/VD6h54vyZSzPUxEEyXZ0wuehi/PSYXdOzYlNfOsJSZbvcSdyVlGYv1DdMMuXuEYX70GChDJlgR
SqU299wlwGZGUVRhH2FTpMSYSim2oBX4jZDONOkcI25PwSbr1S6CDqj2aULhibqyBzysB96r16w0
KFGnWNspthTFvqEEXam3mh5+EXavx6MjqJf0+lLB5BMqA5Uz+Z2/sJF9s4GGA7nEfEFUmzYozori
KG1QfUGdmwwPP2tTUUVacn2oAhXbwFAquUbSSmyA/ReI/TKxX4n2K4WXowQm18REQuaLhGsqhxY/
RNRcCXEbMe8ofrAPnM/hYwAJGazbhRxsWGhAUn5llG7B22TPB7LKbHP+IzcI0H5P6CcPzPs94Ulg
vxtkJeEGN7B5dIPUd25ATeOFJsOMhpRnJdacVG+DxZ2MEY/ghDFfn5+ePcQ9k/b59fkRvKAcXaEl
crYH/S7JfFgmZtJ+F9R+cysAM0GAlguXD/ib5uMcIVjDSvWJEVtN1prCxzZwuNMWT9sFtMJperOc
yWqD/a/rfCRIwz5LFwRsOBaTpoBymyzPYwPp7bYYW1ESssgoPayaBVdCjAnYkOIMChf2U3yZx3sa
zBl4+Yw3C4HCKCxIxl2AkKDCaEaJAtMgU6pbwZhQnirjNXu3hishcOMJBuN2LPyoymbqn8J7JoRR
oFUrt9wsw4lsWxEeO3TDsXBKqs7j+9HUlpiF7U4QOtWKnMJGfhs5ihpj1o/CCNvc/rYuQA+EUS95
ZN4FGc6eVf6Y+il4fzCRVmwXTN2cmmbiJ9xgF6gwChzuc3JUgESIVaNTeDWiaPJKftkzS/XTCGQf
qP71dnTOuccFBiOs+qS2+gdpwd12wnHh4oWmDCvupWSDvrEbA1TPYOfv8HiyXX4t3lcidpLyZ1/c
46+RjnXhcNBwaIFu7nuc2p6gffsSHRtzHnEYRhY07HCoB0ZVx+jh/Pj/HxafWJ2yaaXpoYoctu/i
fnz+o/nwdKKzZfdQ+/0/9L0ab5rVpuvwqJtzVFWs4qqVcbtBo8w95r1S2gtKgJieTKgf2Ea81w9C
iTXw/T/+werrECVKsB5UJt+Jkqds/o0ijLnglmoawijcse9df6swerSqHXtVLl7lxauq6FUevapi
pzIyNBDsZrZqpzHUMN0an5EyvuuH/4fp47t+0+PVf8+Y33vSEHu6YM9ChS3B30E8HHPX+HcuDLEY
BMN+W+7f6T4Rmtne7lOgB7rPXvLIHFuRMKp59Lv9Qa4Pobf/tEXMp9KBpkU0lA2NIJk4o0aSyuOY
jF+EMzgdjU8uzt5QU+65lUeMMxzX9nRii+rAYBug/TrpJw/MA8iw6vZJHwP7dZHlSdoNtnkXk8ok
uv5t8LyuPaCiLhFcZFWogISFTbHAS4GTEUp7qJGUkTeMoZMwRv4u42sYRgXYbGLDfSdDZxxddyfP
uPtDditoYIODJe/CxHvNHfFMWK/xdht+ZzzZLgUZHiBspzGyb4MeX6gpjqlLaBaftaUtNNMpDX5b
fs802QhfEQTdjqA5j2xEJZdNqdXyJG6QUSiWt/yZT0FINiwgheZGQtNJaBYqKOo+qG0mb4zKWLEX
Gst2xo8vMS/vmXlrYrZwj1t4rF87IcLGVPav+kR0CbP1CEcqEH+w5A3sC1U4Rk+YNpsGZmud0Xvl
0zIuKhS1YdkgV4Q7Ezo6h+Zy00oRohKE+DQYsv2MgiXucWhRl6g7pJbBsqA22GMTTGcrimvHeVCy
IDG+JvKSzYkVLpG2Dbu2tLD7qX8njtxf1Znr4qjYai1nx3ExjgqOIye6C6C9KOooAsFCCLbqxUK+
ajmGZHeJfoeOivWb9UscSRGRULTmZXgoxBUxExvy7civCwPaoU+TR7fTPc2hoo1z8bmmS8Xy2HM0
Fhak9gh+aea3usDg4pNLXUbbebFdhrYrxXYUPPeagsWIaIiVsgUL3LcUrVjHdtRDxp7N5/CR2AQ4
TJr5hG6cN/RUlGFKUHQtvob96w8SiNwrY/cyFbnXqkUlMslCU1oZFtwb0dVRkPV6Rk5YIDrhJPvF
Iy8OFQ+BHigeveSBeQBlFfJ7CEtRpN5S3A9lsQR6UKzHF3fAp3l/Afz8ZJ3ByZjzVwrjk4GBnzGM
fkNEdK07MCm8gncfUpgOnMfU4Q34HIMYrrf7tCTO84GtssTSAXYHRY4YpnB8dziYD8Z85BnH0wWI
kwcuEafDyLHYEdvLHzrODpsTs8s5HOxyJrHMLucOp8NwBSn4AWefZpS9d2SWgwcypxVJtCNzxNli
WFEFcvZF1EYhnOOBc06oMEthBO9gZKnH3NUd0N2+dHJUGrl7j+18i4EajXdH0zhm2+18QV5DbP89
AHAwBBUKZW5kc3RyZWFtDWVuZG9iag0zMTEgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50
IDQ3OSAwIFIgDS9SZXNvdXJjZXMgMzEyIDAgUiANL0NvbnRlbnRzIDMxMyAwIFIgDS9NZWRpYUJv
eCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+
PiANZW5kb2JqDTMxMiAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8
IC9UVDIgNDg2IDAgUiAvVFQ0IDQ5MSAwIFIgL1RUOCAzNDUgMCBSIC9UVDEwIDM0NiAwIFIgL1RU
MTIgMzQ3IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDQ5NSAwIFIgPj4gDS9Db2xvclNwYWNl
IDw8IC9DczUgNDg3IDAgUiA+PiANPj4gDWVuZG9iag0zMTMgMCBvYmoNPDwgL0xlbmd0aCAyMTYw
IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ3BfbctvG9Z1fsY/YjAFhb8BCM36Q
SE6q2GZcA+p0xvEDQ0I2U0lUKSqqP6l/2XNZLCiKoO1p2rSRZrjYPZc99z3nvBmdNI3SQonmaqRU
lluRwz9/VTn85oUorcu8aG5GJ+N7Jxb3hJKL+8Xo5PtaiY/3oxQwc+NEsxjhlzeieRy9T8br2yuZ
+swk641My8wmN7zMZZXp5HbRiqa9l3iyZTxR37UEW8jUZC5ZBfrVYh4wVutbIVWeVUnHWqYqK5ON
NMBG1OPmbV6KgPJs7bb7+29cvxH9L21QXyhSLmPJc9r8lCDMJWd3QQXtXgRjaMbI85+k/ND8QL7K
2VdVVhXkBfroPGV85nSu0FfoB1uiR8g5qgwukVWyvvu8kWRL6eDCj5+2tAowpM5U8k+pK5BH/Ena
5OHjJ3AQe2Z9RWiM/Ah85sylFfVnxmFQewOEfPBComtAjzzvFPAh1nymCl+CAs2EZDUqyooKoKyC
/6TSyf7XwcP/5lelO4VC8oDklfeiKDJjSoNasS5llxQmeGBy+fb1xRhsjfF9hsFrkwYdbpMpBECR
iMlZgDZne1ZLVZkpDzxTvXeNjddYvgZYqgK8OZWpTWqpkHN3JmaXb87xygB+J06Fl2kBImTgtyIp
6N5pM1JiJUbeZhZ8UniXOQi6zHqR0u+mHV19Gep9hFoLcutduNNlpofJvwDeuTv3AaoN1q5n1Ifg
581AHhVOZ9b2iaRjacsdm/edLDKftDIHa11hmuuw2bRgZAXOuwVLumTRnooaE7yA1EOShnyrk7d8
SAG13MwDj23K66qlcuexyClYwvG9RPetGPSRLthu5rcRmjooN4vtXTjIy2z7D8YSXXazFNcSZZg/
MEOWXLhMd37vDFtoehIGnMrQI04dJGfmqvfpIa8NwIe9pn1W6eAz5WLxUzqkXnMhNZbY5rXUloKf
TCJOpcLYFxOpMCV12WXejiWotA5agqFHLDFI3jGPdjpkiQH4sCVyKMRd8OZVF7w6FNb68hyznYMR
NEguKOu73Wt4dQxWBo3F+1RMHiBKquTuGl/hFssTmE1H9GemUm7QTgA6YqTDhMzT9vY7ZKEB+KCF
nIe08sP5HdLzUmL2cbKHox/r6alo1mLxiTKrXfyNVrHl/Xwr5rECUA/zmeHLB1o7Ky7n2znw4MOA
GTht2kW7+pW5U2YuRUhtvmLNRNdL8XMLyHfrzbZdihUXHFGfcYq/ItGzPee4SqGNBvwToMMuGiYP
zIdddBA47B/nETf4R8UQVir6x0MMomd0Mk0hYotQWj1GLrYdtTSx3vpEjAn1x9nk4gnyBYa5hfNT
cSapMm+gokJPWkGBxV9wAThXphVgfeITdt6KscQ0cOLt8m4dAFupqcBz3Q3MwZPwkiUP8OzC4YIZ
PmUPEbTadmSPTLZihOvrQN8GcLiTuWGIlbuJCkjYf4arO43389UVJblgICQYeiQkBsk75jFgjMWC
/oz6EHw4MLCCH32ap38NmUpxoPbe3elEvJnWEqRL+Jes45Pvp4L3gerPl9MZ2c8EBlN4JtBwuUC4
K4rYuZq+cw2Dz/SWSijGAvTCvNlKuxsMFmNj5+9429l/fi3e1yAOinn+DbzIKAbaCAOuiO28jg0p
+Cx085H28jX2J1hRkTbtiLGpVcZ0LFT0rAqeDU9P927pEMrsEWujR7SPl+tA+R5vdESoISXq2Uv9
ot5uKCgKGEu1guWlRJz8BXZFlmpvlfz9pf7wG9j7t/iaYNWZb+hpwN4z6A75UFRV1D2Wyr0x6vef
mb42eGtKDw15BzUC3rHDWUdq/j9qSKFYhlCEZ2omSF9D+prkFQTcjmtd6TuVeZaECRKzgOjdkwzY
sY7VsSapnRRQENBN6E5qav1nEhsPTAbaQvYDyoZE05gWBpICqTApSoo6SFJKisMy/gHCL379weOw
/zoSkdBYlH1INt/9r2s5W9Pn+opVEtgT9R1R1JDCfPZSkVYVR/CeY3UZI9n8Du6dYJNfRsm7jDck
ewGy6/02zph+SHzexjH0SBs3SM7MNbZmoX+3MATsd/dDCIONnIYJzOZ9I5dHe+tgb65wNIfCi40R
WYYzMZnW43cXb7krbhjjAnr4PZvoOHM8MwiChq0xQMg8837UxEqq90kPw4cNUVRPDFHEipKoTDa/
jE6axgoAXwG4dFVoshALGkqGe4Yr4Oh134UZ17emrjcq1vY1dHtgSJhAqjDF0h4fAJ3w4Zz6X5fw
mZhJbL0e0NgOngYA6eRn3rUbgRmnEA0TjuZcolrRL4QwrV0GanCnA88xS3xZYHoJDJiiDXczl6VY
rG+JLfOZM9JtoNwVuhVxNKp40PoPibvFIcPHW1u+j3tplC2Ie7BBfT7PhtEPZk0e8CBmFi10et0E
uuRWWWU+L/V+qdqJGP1vRoyKrXPXN/DgVEHAoLqCRlZPAUN7GnZ9nGxqmXp4OGiowtErdUD6SuJE
JcSWaWHApUnVP6nLhpLcQI7POqZLggYX3JMLxPwZcs/1kW+dP6WIlsTuBXJBQTitsHK4JMj+VJps
v4iU1WARAdCRInKYkHn6vkjYIsv3wFBN7WAxHoaSTAw9JtbhuyP8MPsvgE/G906MaypvuajHIyV+
gBD7BRAhYB+FysUb8f5DLpYjbYDMQvn1LlOFuBkZByx9PLge1XSkCQeyFFEKrJY7KD1CBbur70Za
GzowFYxyHkmsy+CR6Q6IKxwhF+NLlIpv9nYHJ2JUDo1EnCOS9ajuDSng83iAnLVRTOfIOje9OB1O
xLDwflvmbEEr5GyrCl/Pm3hgCmhTUE0oGsFWwBcRSvYy7/FmPCkQA9xKNxPI9igRwRcg0VOVrK3A
RjsqhYNdlaxDTXZUijgRA4xmA+d/DQCDEwc7CmVuZHN0cmVhbQ1lbmRvYmoNMzE0IDAgb2JqDTw8
IA0vVHlwZSAvUGFnZSANL1BhcmVudCA0NzkgMCBSIA0vUmVzb3VyY2VzIDMxNSAwIFIgDS9Db250
ZW50cyAzMTYgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2
MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0zMTUgMCBvYmoNPDwgDS9Qcm9jU2V0IFsg
L1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDQ4NiAwIFIgL1RUNCA0OTEgMCBSIC9UVDggMzQ1
IDAgUiAvVFQxMCAzNDYgMCBSIC9UVDEyIDM0NyAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA0
OTUgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDQ4NyAwIFIgPj4gDT4+IA1lbmRvYmoNMzE2
IDAgb2JqDTw8IC9MZW5ndGggMjY1NCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpI
idRXW28buRV+16/g43ARTUgO5xbAD46tbL2bOG6kFAUSo1Ckka2tLQmSvN70H/Vf9txIXaxRkl20
zSaANeS5kOc7V74cdJ4PBtYpqwaTjrWp8crAf/6qDfw1hSp9nlZqcN95frbK1WhFLEatRp3nP/at
ull1usBpslwNRh38qjI1eOx8SM7ms4nuVmmWzJe6W6Y+ueefoa5Tl8xGjRo0K407a+ZT/UVDtJHu
ZmmeTEV+OhoKx3Q+U9qatE6Cat21aZksdQZqVP9scGVKJSxPfsNyf/2Nv9/I/rdGzFeWjEv55oYW
HxOk5cnpQkxw+TMBwzGHMR+1vh78RL4y7Ks6rQvyAn0ET2VVmjtj0VfoB1+iR8g5thSX6DqZLz4v
NWGpczjw5nZNvwqAdKlN/q1dDfdRf9E+ebi5BQexZ+YTYmPmR9AzZC2N6n9mHiY19yDIG880ugbs
MCYYUEmsVaktqhIMGJzTXTMb74oG4F0V/9PWJftfBzf/l191FgyS5IGbuzxTRZFmWZkFq0wVcsI5
Nuql7hYQE++1Aahfveq9U/2r07PeHjxdW6a1zUvVdVEfY+ODwsyzwgG4rQBdPd31SV/bLC3inrp8
/+YlBpOQ36kXqsILeIjBChhLOrc36Fg1VZ3Kpx7AL6o8zSG6Ul+pLv1dNp3Jl6lVFanew73dNj13
Zeraxb9A3jobIGWqy7BIPZE+RH85aEmYInep91sZ4zcZI/i+A6DKpNEOcmKiKUN4sWx0twYMZ5jl
Phk1LyD8LZYgkkAfWMiBK93NMQkwcsbLoahYE2+XF1NasNY1x8eE4kPokEzAQ/s3fBiLL4lpOIts
4OIRkxayZ8qUN37bFlTwRw3l4mNYAWuIhAB14agbtLiZqUfc3CrOyu3Gy4f82EJv96Or0tqJFzFv
xIvWSd0bXGiH1XXwWjtP6UDwqBfaYjYoda4t1GDtwHGn+1BQWW2FgqlHoGgVD8ojUIegaKG3Q2Gg
CCMSFMVFHepFXTMSfYhHKD/QcwosRtZzvXAOfi/Cx2soFxAcOQIEcQc1L7A+6C4130mDdaWCGMQw
B4bVgvoHtAUmjPin2QfT5q1IAukIjIcFWaffIHwIwxZ6K4Z5ZeFGoSi4ONiYnDG8YvjeQ3uroEAU
8Fe23vZ7UGMHc/UrFIEcrDewuZxOPmuHX2rNqNwSdbhWU15PMBUBxOl6palwL5pmKZ+IcAa4PmJt
r6DcoOiY56MgL5s4JjUitn/SzrqhA5QQ6ZIixprmov7Tw0SuJpYoZlswfThqnqm1qGRJNR6uh8AF
Ra+Ww+YP9HM3DhPGzhlrChCjYIqz3hehc9rY6GzBoH+C8gZXaDAA4Zz1EgoYDlVwVgmDpcNbTrEk
18l63Yz34i6vLbq/JfSE2h597eKiXEiZx8K1L/qU2B56vsBlCL2Igim2Qq+koCuTXhedY6nXZNBr
MGsBhb72sAib6ox4316eX+xyXyB3DQTmh7g9xRCDWRqgvQEfwSzH3sUP8iuFW00OhKLZ49/xYj7l
rzVMsDYOkqINgwHrBjKMqFoUCSsNyiE6Mcg9h3iZzMbqxKgphBoKFxR7eTKDbJGD+cKnNF2e/by5
1SaS8iJGks83PV3yd0lDLYTxnHpgnvASOzDlKDREfldAnJ1rzDo4Cx5BVCgzIMpSBVPvsbtkomDF
2oYYizl3bEiPlG43+KGzO8Y58es5pc2txm6ER6OTH2h1N8Zkgnt94t9GLgZgUOu6Gy5v6KtRq+m/
mnCl1VzEpuuwBfAiYtO7u31dlEwFJ1MF1pQ4laypB0A2NeEG8cxVQzFUgHVEude2piLBu8wV5Ff7
qZgXRyZIoR5JxVbxoDyOgPBwrfezsYXenpDGcD893Ap6f5fKT7lnkzPqBpxiLumdqzc9jFaf8N9T
LuI/9hSvReqv73uXhFYmCqCLbMdLlm1eR5kcPIPHYUbJB+8tXqy1384+Tz7b/Dv+tNl8fi3fka/W
2738Pa8tgiKDxpOBA+KT0UZnhLxW719rrP9XJNANEtBnfF5W8alJYjtvzP//g3LzdU6e4/rtIF1l
qT6Ejf7lib3+NujgUZV7t4HOZTGOywBElO1TKwfnCYoijE9Rm4WnrcVHU4SxD5MzNEgIXotR/fPh
ni4ieL4Mox+wpzsyFctI/xJbECsiPSeWB4lnUHfh59WS+Yc3J+Zwsc/qTaLIGWr4j+Uj1mtHcVjj
7IQJAi3mOijZMe17D5A/kJYSDjC21rbYCocyhkMWzT6qj2OkjDEiGve84eLrA13/fcPJaeck7apE
liHtKkw7dx2K8vdiycdEzdETdZjQFsPRP3kt41KdKBrhi+ROY2+mYcknN0S6pb9rInzUIRtgAnVl
+QcS/cDI9SGmIb5WaCQa8/Bx4v7sifg1FTu7/pK2/1al/lNl4VeloY/hstPYvyJSt4ZQa1onUCAd
GT8PC5JOAwO/C489OP3J8NnG0Dp92rKEJRp2H4NgFAMD7aTeiXMkNsg+GlvKnjrv9c/eXVzhO8TT
0wU4Lt5evtiDwlblkXlcqO2AtIsH5XHehtYO5j+RPkRvR6TIN4hEfydWD37pPB8MvALKBBDKjTQ4
mIiZVDHJppmxkmFUovI4R1Z5xBScg29ArFPq1wZHfJ8sEckKKyhAk0x49Rnill+NXYuT+y3JDFli
zazq6dLi23CmyeSoQ0b3m6noCgfPlEgGwr0Q9k4Nu/Q8owPGcsKuBfHZ+rAKV5Kd2VwEwr78iqDY
MaPTVvTIqfHxB1iFqwXBWbjDo8aar8JNdqGQlQrSE+0w2wViYcKDsI8tdo3ZtWmlluS1Wg6Mpp8g
W5UEw1Qw6aCjngB6eMrc9LfwDlw0zVLd6ppUWnDmSpeAp5rR1hyTD87+9EDLyQSnXJeACLMtmD4c
8YFwXGVKt3PsJtTd7wr1w8/X8FCdQx/BSKefRuO4sJxOPmtnJLYrwgSpw/XuugEb4KGF7iCAZ7QL
6GdIXKrRkHfU8I7FYArI2PUS/BUFE+pQcoSQtq/Dc06+N+fkNOewXjlmcje9YTU410Awref7F142
o2a6Y+t+SSzzYyWRqUdKYqt4UB5Lni/we4cM/bpN8jCJ7gSk4xc6dGSkH1B8jPb8bJWrsz5VZ6P6
Zx2rfoKQ+wUYIWwfFfTIN+rDtVHjDhZ4563yjsTvOxk0QVfFjbtOn7YM8kDqQQMAHsxBv8UTOZxH
E+86kx9or8C9vGDNeBR2BtlAzbhFigpQ5InHsKLAEzlyKMGeNfvc4+iqfGkAXJDytdyHN1Az8pBd
JTgANcP8C0ds8USOAlrcvmZDTtjSzBs7mi1edVtz4IkcBqqlaLa1JyZXy50RQ1/FDcIZtlDOVTji
Iw/AafwWT+QAbWXAWZzhMkgnwhmIlYkbhHOds6IMvS2+cH6LJ3K4Gj2xq7lwjEbUzBs7mouC0Yia
A0/kyKuIxp4zNhjG+wRPRKuCJ7asCjhHqw5qcftWSVxmkHSV34pL2diOy6yE3rUVlpFlw+D2/Gsy
xiH6lze2/WvrmvGM/g080b8QSuRw0PyfAQACJDu6CmVuZHN0cmVhbQ1lbmRvYmoNMzE3IDAgb2Jq
DTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA0NzkgMCBSIA0vUmVzb3VyY2VzIDMxOCAwIFIgDS9D
b250ZW50cyAzMTkgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAg
MCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0zMTggMCBvYmoNPDwgDS9Qcm9jU2V0
IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDQ4NiAwIFIgL1RUNCA0OTEgMCBSIC9UVDgg
MzQ1IDAgUiAvVFQxMCAzNDYgMCBSIC9UVDEyIDM0NyAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dT
MSA0OTUgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDQ4NyAwIFIgPj4gDT4+IA1lbmRvYmoN
MzE5IDAgb2JqDTw8IC9MZW5ndGggMjU2MCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt
DQpIicxXbW/bOBL+7l/Bj+KiVkmKlKgC/ZA6vr1st2mvVhYHZIuD68iJF4kd2O7mev/o/uXNC0k5
tpVscbjbJoAlcYbD4Tzz+qYZvGwabYQWzXygda6sUPDPb7WCX1WKyrrci+Zu8HK0cWK2IRYlNrPB
yx8nWlxvBkPgVIUTzWyAb74QzcPgMhutlnM59HmRrdZyWOU2u+PHVNa5yZazVjTtRuLKlvnE5L4l
2kwOi9xli7B/MZsGjsVqKaRWeZ1F0XKo8ypbywLEiMmo+aAqEVgOnvFz//sbn9/I/ksbri80XS5n
zRV9/JohzWUn9+EKxr0IxjDModSvUn5qfiKsFGNV53VJKNBLRKrwuTNKI1aIg60QEQJHVwESWWer
+69rSbaUDg68vtnSU4AhTa6zf0tTgz7ir9JmX65vACBGZjUnNmZ+ADlTltKKyVfmYVJ7Bxt54YVE
aOAeSsUL+OBrPtelr+ACzSnpWuikK14AdRX8J7XJ9t+OLv4/32obLxSCB5yw9l6UZV4UVRFvpXSM
CVPzpS4m449CnJ6QsausORFnjPa5hMuXmVg/BNLy6vW+1Ya6zLUH/x6adAybzMZzCsvnNJKYs7Ec
2mwidQGy45o4v3j3Bk8N5I/ilfByWAJ4OeBWZp7OHTcDLRZi4G1u4SKld7kDp8utF0P6XbeD+fNU
7xPVWtDb7NKdqXLTv/0Z8s7ZygeqKTB3Hew+Rn/T9MRR6Uxu7U4g2S6Qgn0/gqGqrJUGQmUuKXD4
Y93KYQ02XGLw22zWvoKo0JiZaAdioAHuD3LoMDbQoa7W0yBiS7xD/ljQB0vdIjyY81RHhxgDHlq/
5sN4+5qYpsvEBhDPmHQf1lSV88I/dzcK+BHToPgVfAFr9IRo6tJQkeiBmalPwNy7nYXrDuVjOPbQ
+3E0Pq9NQFG7lA61CemwOZMGk27zszSWwoHMI15JjdEAgSo1pGZpMFL3TUHZttcUTH3CFL3bo/Bk
qGOm6KH3m0JBbo7+DMEQ05JhQ0wu3rAnoX9aeJ6Bt7r09TMVIkgWJvdgHXGxadfidLqdisVSlrgG
FU47cPsHNCTUdnRv8Gx+vMYa7TK1b0Htes0HpCdsd3wjy7SdWY8ZrofeazjnNWgULWfKaDkVEsEH
Lt8XUOpqyApow7D0fiLhrGwM9mpW4nfKrC3EJjQri/lXafBNUFtTZTdEnW7Fgr/nGIQFVQNI3TUV
A7Q1cl1hN9RSHsFCW4KBxfYmiOdVZhRt2HC/Clu30GIUqdLzXt65Ivxc9oW+bq/EdDZr77fiCkEO
2qy51Yqsd9LgWYK3sDBwi/vpersHtKs12rsH60Dth7t/exDeD/dRYj/WziNvxDoVVSB1WFeEcpWN
h2gVTTGCVh2jdUyGoBdpUYyI9/356dlj7jPkroHA/OAjJ4g0+MZ6urwGi0IjxajiC6FArlETtmD1
MT8jtpaw1QnbIE1A9i8JVIs9NThHmbHQKBx8DnHFlo52LK8EuhrAiZvZY1223IpwjGCFT6i1G73t
tELIlYBbaVeWsQGyrqucjo24po4SatGKKo3L+BPrXInxgAljxQkD0m8ByQXOggkETQcgmvgp4lXv
MIcXQcCGpU2xCDuuiy5rc9Ku+WHwuFkyAVfKZJsbiTkfj0aQv9DXLWUw0OszP9ugGKU9MMbtdH1N
b63YLP7VpshahW2LbVwC86LFFre3+7K2gDjJAKw83KbC2g95gYaHbRs1SGduWvKhEm5HlDupMTvH
VeaK+zf7oVhW5Po9ocjUJ0Kxd3sUngIVpkbgPNh9jN4fkGCzVMCVSROmCr40/juFZMnBp7MRFSOO
MahXp+LdGN3VZvxLQeGzH8eCv8Ouv12Mz8lcRRAAKXvXYYqim03CaAvRVwM7Rp/EdFvT+GN3w88S
aN3f04NF9/pH+Z55ixrS74Gab75FGNmigMmhAATSxKaonVJhrMEOQUOCRNZh5MUxBZqtNOPhhsvO
KH/2EHf07ZSg4wyOY1j4FJdxYXL+Wn96Ei+2F5RIZ01nLxOdN423gX+CZRqAYtOFbUNoS8u6Dpt1
GCRDs3bClXeEqtns7fHUq9PsqcPsKS4hN/rQ1JVwEXEyevtaw3wAieIFF6S/rKfXlIHC8MlirU1i
C90FQ7zJ9B/Yp9icXUxj22dAFtSRT98R2N+8hXG0kIr8Lo4HWeioFEIV0nvENYjZA8lUSVgRhf2p
BqNSOJsuaVjdis8tlyf82vDISm2fowpFLWULvSI2fwX5AaXeCqsdd6EVOgOW5+BPIaWaOt1bfxf3
5rfP2ClB0X1Utw3ejdoc6Adu0STcG8PFqTEuuTGG1oFMU6UiwMLQNu5RY6woMWosK6ffy82feeOs
aEJW9Fn4FDEtekyLRnyK94Ps5Sr/KPGr7wjnP3TbwxrwqAgUlNz+R9kfAq3CBH4aeufUsloaO6EL
h9Qtm9+OdNy+67g9n3XJ+RmKckYtNxz32qgA1k5riHFteltDpj7RGvZuj8Kh8WZqAUrY/Umtj6G3
OcRdoTNUKY2akEYRKIcNHhaiCeJXhTVxOp6MPp59wAnB0lABHGfvz1/tmcNgaPdZg4n9xujdHCXr
aClNVjvYfIzeawnt62iJMoVapnN0kJdNYwUYag7kytXBI5EL8hTTPdP1fqE7yNEx1leU2MTv9Gil
ztaL+VfIfTi+UZq8IQqMli3NnJpKQZ2G1ZqG1RLb0AWnx5BSF8trFk0D7152RfQg5zyfZHdGLkxS
N0HNXU0EFyoXeYJ+WKqw9UlqrdtZu+jueZDx93R65rppOKBg17lX1UFHsAOg+S8BPOwAf2kJKZoX
BY+IaB/s9wCsKelXZ3NqE7dgzXB9mkgD95LbRW4ScZTFry/84I38C6bATLMWm3smTmdQOKF+ruIW
FBB12EgM0G3UYEnEK+ZcPD4yrE5ZPriJ2PANEIwqyL0NXFHBoA03M8iwwbmxAOAqWF5soZjvhb+u
fX/4M7E//Hs3R8kpvG2Zqz2yM10iPNzcSyW9mPq0YsfOTvTj4p8hvxxtnBhNKDEpMRkNtPgJXPI3
YAQHfxBaiXfi8pMSVwPtQZLVpCIcfjcoFDijTwu3gwktKeQpSFnggdrl7Q5P4rAurw0szH+gtRLX
Ks+S8ahSpQWUjEskyNM9kEexoMiTOCpIC5YlRybjIYpZZ9QjLbDOmvaZqsY73yV1Ek/igBNc0Nl4
z5Id4of6lCX1CGGBdIYlQzwQVqQzvFi7w9NxUAllawSTFRXYGyXvHXU7sPCCR9naIJB3A1sHK/MC
no08hBaQLJ4NgyCdnXgSB4gvw9lJchFulSQX6VZpXxFulSQXO/oxR3erKLmoFGMcJYeFXclFZRnj
KDnxJA6yW7AXnEJrVrO9En6m7DwD3SktdO5kCvXYnR5tIg5j0lF7NuwUNNpH8/xnAI5ExnAKZW5k
c3RyZWFtDWVuZG9iag0zMjAgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDQ3OSAwIFIg
DS9SZXNvdXJjZXMgMzIxIDAgUiANL0NvbnRlbnRzIDMyMiAwIFIgDS9NZWRpYUJveCBbIDAgMCA2
MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2Jq
DTMyMSAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgNDg2
IDAgUiAvVFQ0IDQ5MSAwIFIgL1RUOCAzNDUgMCBSIC9UVDEwIDM0NiAwIFIgL1RUMTIgMzQ3IDAg
UiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDQ5NSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUg
NDg3IDAgUiA+PiANPj4gDWVuZG9iag0zMjIgMCBvYmoNPDwgL0xlbmd0aCAyNjYzIC9GaWx0ZXIg
L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ7Fdbbxs3Fn7Xr+DjcBFNhhzOLUAfElnIuk2cNJKL
BVI/qNLIVmNLhjSO6/yj/Zd7bqRGl3GcArubArUBDclzIfmdj4eHr8a95+Oxscqo8bxnTJw4lcA/
t6oEfpNcFS6LSzW+6T0fbDI13ZBKojbT3vPXI6MuN70+aCZppsbTHrbKVI3vex+jwWo51/0yTqPV
WveL2EU3/JnoKrbRclqrcb3RONKwnhrd1iSb6n4aZ9FC7BfTiWgsVkulTRJXkXet+yYuorVOwY0a
Dcbvk0KJysHXd/f73/j9RvVfatm+MrS5mFeeUOfXCGVZ9PJWtmCzZwKGZY0k+VXri/GPFKuEY1XF
VU5RoIaPVFrGmU0Mxgrj4AqMCAXHFBISXUWr24e1Jix1BhNeXjX0VQCkjU30b20rWI/6p3bR3eUV
BIgjs5qTGivfg58Je6nV6IF1WFTfgCEPPNMYGthHkvgNlMK1MjZ5WcAGxie01tSEteIGcK2K/7Sx
0X7r6OD/slVlfkNyeJLY2CRTOYS5cn5TEBI8EgL9u7PXw5HuI7jj03dne4j0ARJbVlb1bZymBflg
OJw/V6ljT2OIVA6RGuq+i0bapHEextTZ+dtXyB8Rf1AvVKn7OQQmhpjkUUXzDsc9oxaqV7rYAd55
lROhYleqPv2u697869KyDFLnYN22Lc9sEdtu86+IW3PDEEttinnpwPqY/NW444zkeQrd1iFx20Mi
+H4AoIqo1hYiNdd0KLizrjF8ebTEg+2iaf0CGG8w65AFxsAA7d/rfoa8R7LM1hNx0ZBunzsL6rDX
BsOD+SzZyuH8gA6NX/JkbL4mpckyqEGIpyy6lbGkiHngj7ahgh81kYXPVB5bzwMPdAEJtzvILH0k
yJ3m3nnyWBQ75N1RdKDrJIYmC4nOWEl041NtMZ2O32jr6DAQOOqFNngWlDrRBpKuthC2l/tQZAnd
hB1QsPQRKDrNybmrtkAdg6JD3g0FbAjSBkDBJPbZQsg8Oqd0UEiGKKJTnbd6b+j6xVQBvIZcMYD7
tACCZ8C7DAgK2ahCmlXIpIUI9+CyOVw7nXCx9BG4Os298wDmMbg65J1wZRXQwh9+SdDQsgLXe07Q
57qPB+2DdN+NhoDNeIUHG8jzGSDMERw87evF/EEbRFjBSYbzVURXJJ80aoM6SMMljczYvl6rDatg
8YKX/x31rkWull5IF65q1nBwqb3BWqGEMqrA67sRRT/JvYb0A/WGuJnw+pqJWsi65nyVg6GsUAw3
arrrYme56gcSFrJKlvlq4SUbePtPLDxYwWbxpd6nTZJ2cgZEjxDmuCH7tFsuHWNLh7ybLXkFK/J0
sZ4tJpAFL9oPsOk0GvahWuODhWANce85XM9w3YRBNSDVd2cnpzvKp3jOcJzVgWsv8VoHckHoL+Eu
qFVzRZ+hWCyhN7tdLfDbwDVStCOClmrDt/4dKEzRFtlZgQDbQM1TYCfcDMwey/7wNuFBNeKtgTMw
4VX/RG0/zT1Ps6C5W67V5Ppa3dbB34JF2MeNqNmkmRATEgUAGefyUAJW2xKwYoAn00+AE/IRf/G0
OCiIYeoMPtcac1Y9k9FL0oErFZYwR1bmsCzSgKG1mq6WorHh4QX9rhB5IxOopj2mhjyKMNM4d1lH
vdqjc1ZU20LkgNEi7SZ1t7k4F1Hq8HbYNz0UdjMalKDrGR0ebVC8EuTDf73HJJMzgQ3FvhSi2mh4
ot5CEQuriviX2FZGr4eK+2L18/nwjJJOKg4gf7ainuXbqKfbqMu7kXBPBfeIO4B6m+EUgtbf41X7
tvlUve5W5+JePWWC0A5fBCWFyj2FUITXkE1DWAr/GPIW5280JfP3ZNr3tphADIIpHqrgYfc59f9/
O7VbJxRLS/yyQBPpqo9+YHT2g7noYE7rcfVdbu7Pv1yZFSYuK5O3WFGEmKZh20+beIQJGUgzE9KI
ayQN1Mx/MdJQ6ynMsX8z57/JnL9cunkKZ9KLw+rk+9yNtAbwGKCaCLeCsaqw8ErhnsS63cCdfA41
mhft3KGW6na8rz+x8GSCtToW7xnURylcsl9qtf3zl1VeQU28JVd4cvqybZ89JrBHbGF5Lq+q75U9
ZytqYamq+PWF6GygkMngDQW3b45vuN/q6eSuJak11IxYo2JxKmrKA7wXn7/TEsW9DHG335iWhFnl
QV7K4qIwBmegmtI4P4VzOAW8bF4OftLj3xH+3Rz2fcPPuSuV3FVE0vW5q8Dc5S6e7JcDAuc8c7YV
kIPnwCPYZwF7cYOnOivK7/VUH2095UrILvbfeo4eWl1vPZY+8tbrNPfOE/8STNP0qPlRhc43H1rJ
gy8JlYCVSgA3muG7zUJmGuH2CxlTJ8PR4MMpvAfhbYpjqHH67uzFHhwWU10XGizsBqPT2HuG8pSl
kEcze2h8TN6JhCkrQiIc9chgLng+HjsFGM0BmSyRDAV3JYtKFhmulZOQW7KQW0oXsLSY7Veakv/n
WvcLOKRrRLCAG7WP4M6596Dp2KoGsM6hcUU2E7ZoWFUddg3GYik3u/chl/rlQnz5iZdKLL3gRgR7
s/rRTe0nmMkMuzvwE93cbfySZGS5EgM/Ll8xlH0saTYoMEwKR+tGA6Rhad5w6ddwrzOsSfxKdqGQ
nvLWc6hxuOu2vnAimMev8UqMNnQrb6cIm1W/QfxSSGwPtE7xUnsrv8X54fVNfMg9HaQMulvShBVW
WTaBGguWQUBZRxVBBl6vsdhKeQ4q3EDlcqen+COuGtafcOaF3SWF3akjtsy2f4rZPjVMQ7rwSQIS
DRC7RJg/06cGlFy0XswftMUWxrwCRqFs0njUofLBQvIKa1ICEzAsqBACD+JoLXVS4bVZPGMbjCoW
WUSHS5IArWxUTxqwbE1as5n6Uq9Xz1Qjg4otd2cW12C/EMeT62su3kq/CN7fTDUrJZuigfbmH1/3
atrUDZAwj7EyxJIQoglF5fHyLwl1tBUCrTDYVXSn0UGzaSYUBSAsDcxYuljy91LzNNxjFTrmBu6z
K+pCUKiaJY3NLX/FYI1kt1GjJuJ3tjNebzZ7Wd9UZXfWZ2F31u809p5DVs+KA7GDw+k6jTultC6W
Pr6wY3MH+XH3XxE/H2wyNRjRfZSo0aBn1I9w9H4HRTi+98ok6q36eJGoWS9NbOwc3PJJBl910zNl
wnUBD1z3RjSUkw4kMVQpoFJxLZWtggGYr3vzfwS/Dt5gsPWtXxlo+3WwC6jNt46DTtBILW6OPHul
FK8+9GwrBlsG0DMOoV1qihiq9JuwnKATNCA5VrJmC7PR9LYSzzKQYsmJVs7lglbJu/IDtqpEI3P4
DGhpVLmAVfp9o47FIUhYtO89t9dbjcSFfQdEC7uHKA/sIFrke4h6naCRlweebbXnWQbanm215zno
BI1y69mjAbO1oMBeGwdXGIzBFgdWCOLcYRB3HKZJjlTe+pSBttsUS702vEEnaMDGy/2l7kTN7YXM
ARN2l7oTL2fLw6WWeChaKy35kLQWWmZYoLcWKipBoSjiYu9g2ayKd2JF/Z1Q5SmTP4RKVIJCBne7
uP3PAHAbw7AKZW5kc3RyZWFtDWVuZG9iag0zMjMgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFy
ZW50IDQ3OSAwIFIgDS9SZXNvdXJjZXMgMzI0IDAgUiANL0NvbnRlbnRzIDMyNSAwIFIgDS9NZWRp
YUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAw
IA0+PiANZW5kb2JqDTMyNCAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250
IDw8IC9UVDIgNDg2IDAgUiAvVFQ0IDQ5MSAwIFIgL1RUOCAzNDUgMCBSIC9UVDEwIDM0NiAwIFIg
L1RUMTIgMzQ3IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDQ5NSAwIFIgPj4gDS9Db2xvclNw
YWNlIDw8IC9DczUgNDg3IDAgUiA+PiANPj4gDWVuZG9iag0zMjUgMCBvYmoNPDwgL0xlbmd0aCAz
MjE2IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ3Fdbc9u4FX7Xr8Aj0DEZAgRv
mcmDL2rqJnFSi2k7k+SBkShZTSxpKTqp/0Z3p/+h/7LnAlAXi449O9lmu5m1CJwLcM75zgUn5eBJ
WWojtCinA63DyIoI/vFXEcHfKBWZTcJclNeDJ6frRIzXxBKJ9Xjw5PlIi9l6EABnFCeiHA/wK49F
+XXwTp4uF1MV5GEsl40KstDKa/6pVBEauRjXoqzXCnda5hOjVU20sQriMJFzJz8fV45jvlwIpaOw
kF61CnSYyUbFoEaMTss3USYcy51fv9xfP/L3kex/rZ35QpNxId88osV7ibREHq+cCSY5cs4wzBFF
75X6UP6ZYhVxrIqwSCkK9OEjFedhYiKNscI42AwjQsHRmQuJKuRyddso8qVK4MDZVUu/AhxpQi3/
o0wB9xF/UlbezK4gQByZ5ZTYmPkr6KlYSy1Gt8zDpPoaBHnjSGFowI4o8gbkDmt5qNM8AwPKM7pr
rLu7ogF4V8H/KW3k/tfBzd/yq0i9QS55AkyZ3IgU4lxYsorSgU25HJYY5UxeHl+MXqnARPIcop3K
0ej89cWebwKdhdpEiQhMGMeZ9S5Kks5FJmG9oBUgZuQQHF3IkdIYOb8pLpQNc/mW/r6C47Q8GV4C
pHIpnqoUOfJQaQsimuMzLAdazMUgt6GFKKRFSjALbS4C+tvUg+m3qXneUa0FG8w2PTFZaPrFv0He
Ohu2mGpirFZ3pA/RT8qezEnTGJZbqWM3qWNdDAHSmayVAX9NFaUKL5paBQXEcoHpbuW4fgp5oLEW
kQSGQ0MyvFFBgtmAEJo0lVPREm/AizktWCvUu5SqXLShQ1YBD+3P+DAWb4ipWnRsAVyDSSu3F2Uh
b/xzW1DAH1G5i09gZTwOvKMzKMP9QWbqPUHuFffKo/ui2EPvj6IFXutiqJOu/Gnjyl95rgwW2fKl
MhbsH7JzIB10iiXwTGmoxMpA1I73PZFE1B57PMHUezzRK07KbbHx0yFP9ND7PQH2FIY84buya8qj
tydcihCXCMhztb16CZi14JcAq5N4Ki7rtgGApAiqnDp4Clxzt1rPof0i8vd8ZVJoRL2+Yuo9vuoV
98o7Tx7yVQ+911dJAZDoEj/dJH7KHnvzFmpnQflfcBYn8jVtjcAZiRxivkOHLJfiC2ZSShkMI8mc
9qe3yuBSUEZn8op5qpalPtZUCdwgY6GaCGyeRlJVsVxVUjlhKqtc8GLGJLHwpwZGU282UOEn7oCK
7iLGrM0dfrP4xB981N7V7r1B3fhB4Zpz6Yb3WcQZ5TicZXzpZoeDf7Bw4RW3z1lfK6qXLOXYd1lu
neHLGyZva97lnDiHzQihkYCr6iRNfUs1uc+OyHCwwW2VGF+Bwhy8RD+f6C8MZdRUnWlfsXFq8Bgk
ioH5lIq8kSwoKojixksaw61wFGxYVz0RU7xfgkFH+QYginm2RnSlIIN9HJIsJcfS3lzhQLzkK4X7
CQfZ3ZdtQLon1Q4Lsk6zycLYYv3ZEz1M78+zJEdeSLR3mEYZxOUSag9U4YCdUZLLCqw+ERg5gsEl
6zbFKfG+vjg73+U+R/xBRl48FccclAYrFrppxt4m1wt6QCQuQghxdG7t4jZjl9eLFmJDGGD6DXHv
Rbfl36oVXpyPm6yWc/5qKVgeAu5aYs434Fsxo48/vIScOWz1hYiFM2IiuruiHW6T5daEg/IPXODj
zQjtiz3mdc4XSCV6MJUvoCBA7jT1uMYLyS9gOUzxSm+9Ab6ywFzxywwMRx4xo5+KWFdkDlyHKGeY
dYk/iG2xcr+HJjAd94+MjtoP1n5xr7yb+Q7gtY/ej1csb3YzE5rugRu58Xv4d8JxioiFwgIORm+j
9Ric4Zl4NcRwWsl/wTsx0J8PBa+d1F/eDi9oZI+dgiHMI/fHdchuR8Ap62LQKruLuNQ/lh7wrtl8
PpTvUQp773vybV3kijgNdQwB6N6LxnTByP1z0Um8fcm1/w1JBl4UX1MafXnmx6HuefZAJ/1vv84o
qLFLrky6pRDv/M7o4pn+cI8PYXBJrNny4R1AH5Id1VhyEig57E6nBeqPTbLc6dKYJp0/R8eKJpFT
vKKFinOw+Wrtj9eFO/4dFTe0B+E7uhDHpy+eaXjOQOE7wmwp5B+bakad4FnE+x/YuNBkmaYgw7h/
OMgP9jcb6jTuTQxF5zP9uwAPw8Y42LheAMR3fgNQYz64gapHy3eCT1oUBwP1Xp7BnFPIf+GtMmqm
MMFiE0y5YWMFoRa4W/BiaNRYUD8B9b1CuMQ7JfC7+pk/+5J0O0fjD3fz4YeH0WNbAENGh3mh0y3I
3Jm3H3sFhlPewcmdsFuN/j+z1H7HLH1gmuqu6+q8mzBzKMLH+NJL5OkLAdn7N5465zAnZ2jE82qF
pTrHpNwg39pHdwLT0wm6DnH4kZd2HrAbMIzapn1mjoZodsrztJVYCcn+iNvInqa7M8OvmpF+47zt
lgentIfm62MPvpuwSQFx2Pes2cy45neRsf7rPT1i4el4rYyRS3xNGXheGny+4edEWDHFxC1kw/P+
kkBdSBIQfnVD3K2fdinrKA7klLTDMDxQ2D3BT1QaUnkDPdFE/OEnXhL/Jnp/APfd81VRl3d9n4eA
Zo69vaYuL2JRMU38jA8rLTVOBL+Ia/BkJvF1Cp13rYIEEpsZ3R7qnflqmWeFe1bg2U29WjatgEJV
/oOqIJG3ytWP7bre8UOIbgBRiLbtKWRT4n9s4x5jXcLWDctBDi8QGAKSOA6h7EShzUVAf5t6MEVq
nndUa+H5YLbpiYEOdq84K4fmlzpqnKRhYvbFexhOykERFlhxI0EfBWSqjVKhU0hiaFfXXH0zn/4m
5gRGgxM5hMwHe0foiMztibPh6PTy/I0KCgB+yRznry+e7nlEZ+k9HnHUfo/0i7PyZGOw1ncc0kfv
90dit/yRdqVM6hBT9UlZWgFTxBTIWeIqZ4Rc0LGYnjNdg758ez7qXBs5156qTF5Bz8pkPcbXBkDs
Ey1Fi/UjdcSqFXMq7LZ7hcAwlMEScYmjkNv9isu5wvliR4Fw0tQWUlm5s2ZExCJm+bVDFSt3DyE4
zNUoLGmxv8vnz+JjDZRxPf/CV1cRNt0jsWqWq7r5fKsMbhxgEZOqrcRHxA5o93w1HzlZLec7h3fv
rYOjlo27Nq6dN5sagYgGmdg1P1h9QdNjuIJBpVPMcEdp3AnXCt55YnnDjK0CYP9b/OSWtf8VFWtf
8Bq7RQZwR/YGqn0Gkds+qNNNdyEGFuC/tLGYsQj6BdRULFkxx+M0cKTw6iF3Zpivoszsj79baDa/
Fs1xh+bMozl1iIs9njPCc0x4LhzJo3kXy/QQiUH+lNvoC4VI3QJ2TF0V49NpIlhjGI2DdEaQjhHS
DtAZARql4i04J2F3mT04x4RVi3D+WJP6Jc7rAJbayTGdtU6YNscr8Q6f76+9cBr5Js4IzoLx1Q1T
2UFrfMgAClvnPq+h98y6OZwX3fvGzbbXAJYMRr4gkevWa51Sns0VZQFstw36D5MfMUaVheXmrfAU
UHCrdIGXXOKCVLakYt1uxCe4zZpJBt5NYDF+AQ+OpmR7pwBFPsH/RxjErWgbKjioakyqr1BN1dSb
rICr5F5ngypqOkWwbXTF5r+NV7tOBDEM7O8rtkQUkDiPderrkKiuRHQICXRUV/D7jJ2Xl3tAdbrx
ZOzYTpxFXbG1811BRE7N6fQhV8GqlVrvzk+Oyas5OeFfJ8eMvxxvjb9qvTH+ri6v4mGOt7SemR1m
J19dfNWqkVXrrcgu+x72y/J/mB/3p7TsDzqY3XLY7/zyhER/goiyfGPZ8ry8vLrlbeeLjGq/xJQk
RV/4rMRbhgdw3B0UIuV48QYOST4NZzLw9cgA3u8VY8E44BerxBW7AYiyL6kKMa4voeCXoqFMgmuq
3TXuA1UlR3pmGyCqAqkKhiQ3xzEayiC4HiuxAmFllcyaXflX9bKuD+zllSOCeBjEThjmNT74vA0z
EAZeNmEKkLdhBjxXswlzUAaBZB+qi7DUM3GWvpFSYDFXILZyAYrKIekIcIJXncEZDDzYqKegk5Kr
yuSKZkGA2CMudZ2875TSoumUQYiYY9tMkHOSnZkJAdw2E+SiycMgdLMvqEtVjSmo54j+CKLaAc9J
En7cxew1/MFIrnUOAKp+haONUYqcz6/fskfD0Gdv9d2VsbPMVrkCG2WSTrHKnTMZrjalUZZOIqvc
AKuM3pNtTOXBmYxWFauMyvNGuQIbZVwuvFHunMlolTHKlEq9HLpyA6wy5VAvma48OIORWnGg/ANV
L+pPCmVuZHN0cmVhbQ1lbmRvYmoNMzI2IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA0
ODEgMCBSIA0vUmVzb3VyY2VzIDMyNyAwIFIgDS9Db250ZW50cyAzMjggMCBSIA0vTWVkaWFCb3gg
WyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4g
DWVuZG9iag0zMjcgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAv
VFQyIDQ4NiAwIFIgL1RUNCA0OTEgMCBSIC9UVDggMzQ1IDAgUiAvVFQxMCAzNDYgMCBSIC9UVDEy
IDM0NyAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA0OTUgMCBSID4+IA0vQ29sb3JTcGFjZSA8
PCAvQ3M1IDQ4NyAwIFIgPj4gDT4+IA1lbmRvYmoNMzI4IDAgb2JqDTw8IC9MZW5ndGggMjQ4OCAv
RmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiewX25LTyPXdX9GP0hYWfVNLooqHYeza
zAYGgsVWUiwPwtYMXnwZNBrY+aT8Zc6lW5Y9loFN1WaTClSN1efW535OPytHj8tSaaFEeTVSKpFW
SPjPX4WEv9KJzKZJLsr16PH5bSrmt0Qixe189PjHmRLXt6MxUEqTinI+wq/ciPLL6G10vt1cxeM8
MdG2icdZYqM1/1RxkehoM69FWd/GCGmZTsxuasLN47FJ0mjp+ZfzylMstxsRK5kUURAdj1WSRU1s
QIyYnZevZCY8yYPfcDw8f+fvd5L/XHvzhSLjEtZc0uGXCHFpdHbjTdDpI+8MzRRS/hLH78qfKFaS
Y1UkhaMo0EeIlMmTVEuFscI42AwjQsFRmQ9JXETbm/smJl/GKVx4/aGlXwGO1ImK/hnrAvQRf4lt
dHf9AQLEkdleERkTfwE5FUupxeyeaRhVr4GRAY9iDA3YIWUwIPe5lifK5RkYUE5IV6M6XdEA1FXw
v1jp6PDrKPCP/CqyYJAvHkzCTCnhIM6FRavYFheKwji26uXryfQ1uBpjPYWIZ9FETKYc8ecX8biI
fu7w/zjw2li5xBSZE2OdGJPZ4Lw07ZynU76mBBESkmcKISiiWawwpgEoLmOb5NEb+vsClFDRM7i0
gJN4EjukyJNYWWBRinSYliMllmKU28RCfFzhKAETm4sx/W3q0dXXsXneYa0FG3Qfn+os0cPsX0H3
7gYQY7XBPvaA+xj+WTlQU84ZOPaKyu6KyrKvX0OyZ1Eda/DXVUxFxIemhngmLtpgI7DRvH4CFaKw
SxEHhkNB2F/F4xTrBJNr0VReREu0Yz4s6cBSoRM66n9yh4d6AxqCX/NlzN4QUbXpyMagBqNuPExm
CQN+6zMKiE4Ck6Hyui9EmriQCsHXGfTo4Tgz9kScB9mDcHkqkAP44UBaoLU+jCrteqPSvjeWF7HG
qiufx9qCC6bsH6gIKDvoj5NYQZuONQTu7NATqaTZOeAJxp7wxCA7CbfFzk/HPDGAH/YE2FPokNDK
hBYVhsTszTNMJUsJCjpEF9Dtw/dzaBMZ+AZbEPhGvGwWkFSU/6C6w5yHpIaEYaiY1KvlZ5jxMCia
+0O3aQcDa9BtjD3htkH2ILxz6jG3DeAH3ZYWkB3Ba9oGr0nf2F/hHM+gqeLMew1dNAugl7PpE1Fu
xfwDlD0MyPlH+hUtn6tWLLH/Y0krLFfQY1570GdmgTKGdiIW5EyCwKFqK9Fug5ha3NHvzQ3gVhX1
FhfdxxpZg4BqPt82i+WGKK+9Gj0RgATubVAkwJta3MYOWgOOiqau1hRIKWDqqdS5MIeCT5TyIxyX
O0dtS0Wf7kBoVGM/gU4oNnfrWGuYOO9hOzpIC2kGcwJQJxLiOCPL1LtcMRYL5oD1OH44G9IcaUM6
ZF06mF46WEgEKJYx91AsIYOlI2kkW3ANg8Q5UL28nFz06S5wsXUAfiLOYBZHTVNtaGxc+3EjcVzT
WuyiDwzjnLjleXJHsDmj9gkh5Wo/fFjm4ma75K+Wt1C/DNLNGHus330O3NBNxCjOm3ohJsTABhw2
yRR2o+G1wGOHgzvMHoSfmvtD+OH4QhLAMcS3e9xIv2BN/04RdhhPqALYrB3EgyzHtWsiXkwxxDbi
v+AXA/gfp4LPnutvb6aXtJQZL2AK4wbdVv7AW6PZrcU+saYb6MCGIgaLNh/aeD9koJbo/Tu90+4+
v5Vu+GtQuWe/SxFyhXGJMhCA7q0gudjYHW9wICkoNyQdB1qcTgqdxxy66MIXHheUqRCpktyWR/4o
xNsAmV0+VY9m9aen5t3v8tc3e25Q4Bvxftk+lTCMdU57+/fdfbxJm57zhDjU4E/69W2EnC4qyQvl
dunysHaPS7ncQmODhy+lhukV85nPLS8Ycwu2xhO59V/g1dkZzByw7a8hSaDru6LojMo7o/RewShf
MEXkj13BFFgwmgpGv4P1UDuHbei7iiUo87/gYQE+5p4SPK0TvdP80ATOXXwROdPL3Qd7Re+iy604
MnDHQchhSB948ZtaoKGIqnf7Fv5xPXDoa1B5/gdKE636fxMcbHjdFzhLH/Q4cJe1ruP+s7jgP+cg
c7jNWnokDG2zjD2xzQ6yB+Gy21ZVjk+TB+xHCQb3WaPS3j4ru76ifV/BOkpxLaVOjsWUeZiYTGfn
ry9g3S34cYIUF/AuOfAI7F0nPOKxwx4ZZg/CO4PhGXLokCH8sD+k6fnDdf0gUklc/jp6XJZWQJ+8
AnSWFr4jIxWMNMbnjFcgL9enWrZ/gtXzj8efYks+X8X0+gO95/Xyc++R14hF3dbz1r+1/J7Pz8CK
KG6Ef70dvgcfyFrwE3H+gV+HG37FecXCOw8JP915rv6jb14/Ev4VuoCHDL1wz2KacDjfOt2+4FDy
ZrX+AepR3sqGX7cVW7GOMbW6u1rQ+2bbtMd7t+oGmfKD7DaG1AGb4YEYVauVeF8LBtX+0g2hWpjA
sJG8ryAQeEbH471rdAL+oLpgfbRYVm29uieihBsjtAuZ6UNVemmj/920cV3a2F1FGlB+S3oJyiLn
swjOLZ8rcpoF4zCQYkn+hY8JPSs1PzwLKtuUX4d49AngOAFsxDIx/hDEqmkodln0mcBLEr255nu3
zNiKLXYHcHK4cdss6kZsw9HrVze1YLmsYVMHjdexxh+PxazLok9eJt9Rb+hnXosujni+C/HC1+V7
PsDN4UJO+r4BLLsRTLBljtViIL1sl16OA9FiZtldNWWcqxL0XMRji06ZeJvAvdo3TpuYcBRz0t9F
LOiOmTb885Fgt7v6wOdsw10WXeyoPjS9//x1/vJV0KWhPn1PB9FJx1O7XGFLgM7n7669Jp64atCq
Md25ZcYmXNLUwbrksNMrc6rTM/ZEpx9kD8K7Tu6KPZzuj70HnMNYVMtjT6v14OKAHJD9FfTj89tU
nM9o+kgxOx8p8ROU/69ACM3ki1BSvBBv30mxGKkCjLAw2SWkoxZr2FAcyOkAq9GMQBpobJElkJxA
o+Fa26MJFKm0ON1Wo6sfOiKbkeXrkZYaszsAUDKCSHIG/DnQBHU6mo7C5WgeSe6IjGPJQWcP2NPZ
gKC+zh1NR2ElWkWSwaeJA5jJcvQUcpnE5R2AJAPIEg3sKiQZljptezQdRa4x4fa9ITNcEnreYMCe
N7Cm97wRaDoKiWqxZGsKH52cIxgAJrUcHYujj5xa8N228P5iAN6NII4ErUPrEYZS2h5NR5Eb9Cjf
DXrQVRZKnSRbx6YzYLUDgHOIC65KJVdcFhQONHkamKBX7Cj4qmAEdO9izwgG7BmhMkzDnhGBpqOA
qZR5I/41ABMF3PoKZW5kc3RyZWFtDWVuZG9iag0zMjkgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0v
UGFyZW50IDQ4MSAwIFIgDS9SZXNvdXJjZXMgMzMwIDAgUiANL0NvbnRlbnRzIDMzMSAwIFIgDS9N
ZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0
ZSAwIA0+PiANZW5kb2JqDTMzMCAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9G
b250IDw8IC9UVDIgNDg2IDAgUiAvVFQ0IDQ5MSAwIFIgL1RUOCAzNDUgMCBSIC9UVDEwIDM0NiAw
IFIgL1RUMTIgMzQ3IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDQ5NSAwIFIgPj4gDS9Db2xv
clNwYWNlIDw8IC9DczUgNDg3IDAgUiA+PiANPj4gDWVuZG9iag0zMzEgMCBvYmoNPDwgL0xlbmd0
aCAyMTYzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ1Fdfc9s2En/Xp8AjeBPR
AAiApGfyEEuannuJ41p0pzepH1SZdtTGkkLJzeUj3bfs/gEoWhaVtHNzubNnRAC7WCx++we7Z9Xg
pKq0EVpUdwOtU2WFgn8elQp+lRe5dWkhqofByWjjxHxDLEps5oOT76Za3G8GQ+BUmRPVfICjIhPV
p8E7OVot75JhkWZy1STDPLXygT+zpEyNXM5rUdWbBFe2zCem65po82SYpU4uwv7FfBY4FqulSLRK
SxlFJ0Od5rJJMhAjpqPqUuUisDz7xun+/E9+/yT7j3W4vtB0uZQ1VzT5WSLNyVfrcAXjXgQwDHMo
9XOS3FTfk60U26pMS09WoEG0VFakziiNtkI72BwtQsbReTBJUsrV+nOTEJaJgwPv32/pKwBIk2r5
78SUoI/4e2Ll4/17MBBbZnVHbMz8CeTMWEotpp+Zh0n1A2zkhRcJmgbuoVS8QBF8rUi1L3K4QDUm
XTPd6ooXQF0F/yXayP3RwcX/5qgs4oVC8AxN6h2YwIOdS0u3iuEQouH6Yvj2ajy5IpgLOUksIDQW
4wnaP5evz9HqVv44ufrnHlhD7VKnCy3gkCzLbcTMuRYz4/iQCqQr8JkJIF/KaaLRlHFRXMCZhbym
3zfgbVqegT4lzMRp4pGjSBNtYYs2pMOkGmixEIPCphbM4ktPfpfaQgzpt6kHd1+mFkVLtRbuYLp0
Z/LU9G//ArlzNiwx1WSYvp7tPkQ/q3pCyfsMpp1YsrtYsoz1Ffh4LuvEAF53CcUOT5o6GZapl0uM
fyvn9SkEhsbkRDvQHBpsf5kMHYYH+tRtMwsitsQ75MmCJiwVEqCntKd2dAgz4KH1ez6MtzfENFu2
bENQg0nrsKbylBf+1d0owDopPAizoPutcKmPrhCxziE199uZqUfs3Ls9ClfHDNlD7zekBV4bzKhd
mxK1CSmxOk8MJt7qdWIsQDBhfCAitMe0OE40ZOfEgOFe7SPhFD2ZPUgw9QgSvdtJuC13OGUWx093
99D7kVCQnqM/ax/TU3Tn6fUZepIm/0QgziEzZO3sNTgEYDOEJHEqrpfwanvwQuR4m+Ar19zWTX0r
xvWHxe9ExEdPY6b5vI+adr2QAekIXoc3skwAwBxxmx56L1iu0KBRRMuYiBb4HqF1iVm7hFyqITSv
IHm6uPR2OjkV1UrM30O0G1nPf6Ov2PJ8thULTA8aIrnE6qCp53VY+Z13AJ6ZbMQtQUkrMJltZ2K7
ilJq8Ujf9RpoH2aUURBpg1ujgNl8vmpuF0vivA9adESs0GZisWUVuodvIBnAo4CH7hnPlXqXSJ/Z
L1D7Tdi/PQjvN+FBYr/9XIG80X55a7+sYz8LlsvlZMi5Dj09QxdX9HRa8GFeEiPgensxPu/ynWPd
6WH5VLyCN1M2zWxJ6f0+PAsKEaSq1cv3vCY24ChoH34A7h/AA6BgWm4hcMjATH8k7nng4r1stRzd
J27n427XqwWPtlw/hjKOlNo7MOzA2hpuJficJU8DCCuexWgmKXzh/eTnoNTpf+4D9Ygn9G6Pwo+9
5330fn+ADAnT6A9tr6JC4TT5iTzCo/01wDcC4Aq+OZZTY/Fmgi5hJf8CLhnQv5sInoddP1xPLqjY
yoKACTwjCJsSSHfet/Xurp5QIQFPluQOaNAEMy5PtzTuWhW9ofN3vGDdDb+W78joqIZnX189X0NB
k+OLgknrMgIEnqKzLAJkytZEsR8gbwRrVKGEDlMQ+C4uTS9e6hfTjy/NDSz4AtJhLv9SnR90gohy
eYE6vduB/q2bj0OjaQADUhX8/iPqD0lMW9di+uwZI0yz0CPgN0wjpjgGTA1i+tPNYVdWbXI1IbmK
a/ELFrfQYm5fah6JcXxMvsbU/8tQ92G985XQ9c2xB8TrsONmwXFzGaaiddwcQc4QZH3zl3T7xqAQ
BJlPfW5zyLwIQTRpdIlp/RHKSyn0C24th5F9PzF2cBPx75ub/D8CP6MEOa/UPqAUgmbeBlK4dr+U
cagK4VWHFzpAGWTuQfn/FVeHoqpTbVh7pOkM1CPVRu/2KHzXVHp7cPtBht56w+QR94eeJImR76ij
onKT3nVeE+PJdHR1folNAVVfyHEOleYeJiYvj9TigdqPSf/2IDyQ4JWG1ml/63NiPxZQi3ex8G2I
S50m1a+Dk6qyAsh3QM5d2ckgUPgwvWC6BomF6QRP28bGKopfLQ2FLBbe3IX50IX5UEZ7yR2TpZoZ
EvHiLqGiTYypejP8DJaEveOyC6cg7ZG2U81sJcvEGhs8eNY0C6z2c2rjvFyQ6OU9n7vijVuxQhPD
qxpP5CZsFadBP4htwXJZw6aOGj8kBj+Bim1GLj8GmXxGvaTPvI5FI88fWWfsOTL5C0/g5Hhg7EN3
F2DZTU/9qnf1a0guW+yAsI3d0GWKIB1XOtINSKelRMM4tBihqzJwapgi1MvfWBzcNKfONdznkZbX
a5D/YfYZ8TBBHPS8gZs7LyPD+WTWUgZmsFUdm96uLul+gHW7jOcBxtQjAda7PQgPpIxy0xNaZlJr
e3f2Ukktph5V6/nBLfGw7C+QT0YbJ0ZTCn0lpqOBFt9DwP4KjLkRn4RW4o14d6PE7UAXIMlCSlUG
D38YZKpMTcELIPrDYEpLCnhsWeARwKOhmbIdnsjhFERBAQt3f2uZrPcsWZeAiOKFIFmXjiVDerbI
ErRpWVoGD87IclueTD3VGBf2NTb+qcYtT8sBoEeNo+QMEuQTybiwJzlz9qnklqflAJVbLGDN41pp
AxZwlFe8ELGAJRKEKBOLYjmRZcegIhYW7M+WgZoe5caFDF5IjUxW44U7d7LWw9v55E7WunCFcCfr
MlY38rQch+5kbPdCZu824Kml717HPLkLtIQ6XOaPAQBFNMwVCmVuZHN0cmVhbQ1lbmRvYmoNMzMy
IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA0ODEgMCBSIA0vUmVzb3VyY2VzIDMzMyAw
IFIgDS9Db250ZW50cyAzMzQgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJv
eCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0zMzMgMCBvYmoNPDwgDS9Q
cm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQyIDQ4NiAwIFIgL1RUNCA0OTEgMCBS
IC9UVDggMzQ1IDAgUiAvVFQxMCAzNDYgMCBSIC9UVDEyIDM0NyAwIFIgPj4gDS9FeHRHU3RhdGUg
PDwgL0dTMSA0OTUgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDQ4NyAwIFIgPj4gDT4+IA1l
bmRvYmoNMzM0IDAgb2JqDTw8IC9MZW5ndGggMjQxOSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN
c3RyZWFtDQpIidRX23IaORq+5yl02doKbZ365Kpc2JjNeuxgT8CzW5XkogMNZozBBXg8eaR9y/0P
UoMxTZJx1U7FrqIl/QdJ33/U6aB1NBhoI7QYjFtax8oJBf88KhT8qlRkLolzMbhvHXVWiRiuiEWJ
1bB19K6vxWTVagOnsokYDFs4yq0YPLU+Rp3FfCzbeWyjxVK2s9hF9/wpZRGbaD6sxKBaSVxZM5/o
P1REG8q2jZNo6uWnw9JzTBdzIbWKiyiolm0dZ9FSWlAj+p3BtcqEZ3nxDdPd+Q9+f5D9t8pfX2i6
XMwnVzT5FCEtiU4e/BVM8saDYZhDqU9Sfh78QrZSbKsiLlKyAg2CpWweJ0ZptBXawWVoETKOzrxJ
ZBEtHr4uJWEpE9hwcrumrwAgTayj/0pTwHnEv6SLHie3YCC2zGJMbMz8BHpK1lKJ/lfmYVJ1D4K8
8EaiaeAeSoUL5N7X8lineQYXGJzRWa2uz4oXwLMK/pPaRLujvYv/z1FRhAv54AF3VRBIKZi5cOFS
sOBDQud8p97Vh/eAcx7n0cmlOOlc9K7+fdk9e9fdwaetk1gnaSraJrY2I40MjgsqrWOVA9CXgt26
su2ivtQ2Tus10bt5f4re5MkfxLEoZDsFM8VgoTTStG930NJiKlq5ix2gnxYpuVfsctGm32XVGn+b
muc11Tk4t9mmJyaLTbP4N8hbe8MSU43FLPVCeh/9dNAQMWlqYboVMnYTMj6LfSCgKmkAtDHan4fL
SrYL8O45BrmNhtWxTDD/EDfir4HpWrYhd0bkNqNlSeIQJVEbBxB+Xhfktgx0K17HjFgAFdYmrBxF
lkAu556h7cCiQ1x+oBWVxTj5c8MuQjjzgWawVD6yZt5TgIFiK0p//pFIYsPDGKLWbjwjQJ9BQm42
O1MPmL1RPChXwW7WIecL6X30ZruaPC6Mt6pOimBVbQofNefSUKRcSuPgul2AEdPcsYTASQG+E4l7
QyHSLrqDPFyApY2Gz+KJKTPmrJBhRAwTZoAEaEygzImy3gWTMnUjmEw9AGajeFCOhbwxSBrozWAq
yOuIJcVFGhKQR7J/gwkliyDPQO7J0PcNpv3zMLjsYqSkiC1EA2DcYwGs3Ab8uk1ed48GyKE1aKOP
zjyrd+ITiTNoCoyK7uYgaDAAnmjVs1YsOPK0SbULuU4a8QbSAbD3C7JOt7HDPqQb6I1IJ7mGE4Vk
ZOqOSiWM9TVeMo1uIEJzSEwp/Pqlq34XcvtgIf6AeMe8omBxOR1/lQZHgtqnPLolarkWfRbrkI4B
mc4EXXDIYTV9pkicEqMoh3e0PKdftGAC5CesOjlYApVUo8mW5PONK0yQ+3ZcSSxXLMK6R9wBVkuI
RNIuyi+LRyKtd5XieR/W0BrSXECnAi4Fhboqh7fkBkpAk6idS+t2I9+0G740j6DFdAiOxCAWIFnA
Fo9z+tzteFNS6E2heeFQntrsU83iXnlzKtxLbHYoR+U0OFTdj4RLX3PUoCslUbdNyYptk2DHgDWs
LzGewqLoEOtV7+z8GfM5xB2wXfWY/RickewGhWtZztEjwDPE+tYPBKBdgtUhEZjokRaHTEPbFqCB
Z+CpFdXSnNwCqujDYsqjNZSxYitD8PFWEgvujgy6EjjQYu53D4fms/awCBJfUAYZHt26lJiYpuuw
PKYbL1jbkkOoCDszLhe7fpKkB6qmpx7wk0bxoFwd6Iaa6M3eAqDVVXNP+un+x8cruYbeyR7dM/G+
i5Cyz7jIB+67ruC5l/r1ptvzSZ8VQObailLsekOUbrox5buxLsajJTeQXF2x33HbfuCofm/+Dnf0
m+H38v2Qwsbznn5bF4FiITFaMEX9Unpplm3Zm0t+dF6TcDtI4zOCniNnDYkAZc+8K4fwONlvFVPU
wuGl9hE35bYXi3i/91Z//oug/U2jM8xH5DzQkiyp+GGn7AEA9ABGBKB+lv79R/5LmPb9HTsSe9iL
lxb+iS6IoxeeJ+oLwiMpjy7e6jf/XJYTsudb9Tlc2MYuyfLg0iojl2ZvxjAwpPF1IWB+shD4nhiw
P5mL7FvcFwJbFdvazevoZcVm6oGK3SjOys2mnusi2SPewNBYsy1IuvrJ4B0ZXdQXTPbjLrZnBdRl
uHnm18RZt9/5cH6N/ZajZxtwnF/1jncQsTbbtBEvEPHUZkSaxVl5GqfNLUwDuRENU5jYoV6PR1rH
daRjOfi9dTQYOAHkMZCzpPBlFbmghWB6znQNGnOzqbvWbJoRw9iiByURPhSgqxxST4NPhcK3sTm1
sQW1sfA0gmaVswM2ngk2nhLHEHGG+seM+kda+oOl4CVC71tU9Mi7iClPV/we40/pt76nBrUiMVF6
lr17Mo0556TZn/ALcDsYwLuRtFReNTNRG4N8z2Tq1otaDui7VWZ2M+aWIcwrDeE2XaG2wRA55N5b
SU0lWqIAL7/jKVoiCzQwBNy+mvOMroOPWZoR6VTgykpiZy/4U7G6IINNbBaxHA0nfh/IKxZOwWe5
oLH44oXHmH0WzL+EB4ht48JSKtr1z/qkCSiG095LrWFf8GV4Z1Se/IB7Lis+VPydYNtXgm3SutK5
gDU8Kel5lrLT4yPxjqbs9JknwtutnM2er1XBWe7Rv5x/qDlyZ+N/S782YQl4hGWeIkrAblkNK6pN
gTYSw8USVtcz3glcF5dj8SnqLcRssa1bLMYe69ecI5aYyKJP8oURnNtnBPdKI+i6Xde+XccWBeO4
j1fGN6jCFHIhhr79uKXa9sg90Jw/d7QmhvDapUEZmJnAq+ijaN8n3mAGGQIiYORXJ8RT4fUzsDbv
wiZ54E3W00XYlDYJ+sbUTGxQRx9+JJbZeuplZ5UY8ajkHaAdGd7yyuO21rvdCoXPlbSxQjH1QIVq
FA/K6/oF5SXUIE82Rh8o+M1UPJmnHj7Zvr0DvUH9N8hHnVUiOn2qnkr0Oy0tfgHH+x0YwY2fhFbi
vfj4WYlRy6g8zp0WLnMxeOF9y1pFR/cLs1afllLiUbFOiSeHIrzFs+HIsFjPWuN/bJjgS5oN+AlC
5hdQMy6RHAAEMNxvjhN4ag4LHV3OmiEGWXOKIhBIIMsz1OlyzSpSh9ggQ8EqiKEmZ/hlhfWuysbP
MKD5NgS2gLLotiHwLDUCKsNdnyFg0yzeBoDn2/e3cBhCNpwksNQMqY2tBxbuAVvAVngvvJ+f21Th
/Tw4NgdNW/DwfBsgi066DVBgqRnAIVN/l/8NAMMlevIKZW5kc3RyZWFtDWVuZG9iag0zMzUgMCBv
YmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDQ4MSAwIFIgDS9SZXNvdXJjZXMgMzM2IDAgUiAN
L0NvbnRlbnRzIDMzNyAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsg
MCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTMzNiAwIG9iag08PCANL1Byb2NT
ZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgNDg2IDAgUiAvVFQ0IDQ5MSAwIFIgL1RU
OCAzNDUgMCBSIC9UVDEwIDM0NiAwIFIgL1RUMTIgMzQ3IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAv
R1MxIDQ5NSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgNDg3IDAgUiA+PiANPj4gDWVuZG9i
ag0zMzcgMCBvYmoNPDwgL0xlbmd0aCAyNTM5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJl
YW0NCkiJzBfJcts49q6vwJHoimhi4eaqHGxZk3EncTwRM0slOTASLSu2JZeWdueT5i/nbaCWmEq6
+jBtV4kA3oKHt7/zqndSVcYqo6qbnjFx4lUC/7wqE/hNMpX7NC5U9dA7GaxSNV4RSqJW497Jq5FR
01WvD5iJS1U17uGqcKp66n2MBov5je4XsYsWS93PYx898KfWZWyj+bhRVbPSeLJmPDV6bAg21n0X
p9FM6GfjWjBmi7nSJonLKLDWfRPn0VI7YKNGg+o6yZWgfPcN28P9H/z+QfR/NvJ8ZehxMUue0OZT
hLA0OnuUJ9j0hSjDMkaSfNL6c/Ur2SphW5VxmZEVaBEsleIXLYVW8Dnag0xjcjGILqPF47elJk3q
FK6b3q7pq0CNNjbRf7UtQRr1d+2jzfQWzMN2WdwQGiM/AZ+auTRq9I1xGNQ8ACEfvNBoGHhFkgTx
C5Y+UWAzk2aZqi5I1oxcB4WMDGBXXxE5uKWPy6JQGSiw9IHAmOBspuS3XQzf6H4WZ9HZf4a8uFBn
g9dX7/4l58OLV8MDOfrCu29j53JiTvpCJTJ355l7BerJQD3A2kcjbRwwDGfq6sPbczSZgN+rU1Xi
nR4sXQCipWuHVc+omeoVPvaJUVmZkQ1jD/fT77Lp3fwYWhQt1HuQ2+7CU5vHtpv8B+Cdu+GIodah
S31H/Rz8vOpwyyxzsAXK4Jlu65mSKt6TohptQWk32lhZLhvdL8GJ5hhJLho3pzrFICds1L8BpGvd
hwSFUWmjybImcnDGqI8L8HLhBQkkB94Jn2PaKQEKZ1NmjiRLANdzQeh7sOgYjx/pJMlj3Py+RVch
aligeziqN8yZ71RgoNipWuSfqDS2vIwhOFxkgmcE1eeQ9brNztAjZu8kD8yTY3btgHfb1QNuyDcm
LYNVjZWYrC61pUh5o62H5w5BjZhNTrXBiFTqTOPdkO2Nj+4g2ZVgaWvgs3hiyD1jNogwIYQpI0Ce
sTZA5gRZHyqT02GXMhl6RJmd5MTcl1tVP6fMDni3MuGhpQ0hkrURIgEyIq/6ADnWRecVR8Ul5qE8
kt0b0AS43JAd71RnmHwviKDR6Mr3dFTT+hsaxAhg0vrxmTY5xhkd383R68ESdHaPURZYTQR/yqF6
oHebxant1DtDj+i9kzwwb63ynN474J16T0uoukHt1oXEn0jJvMbqXIDiDTjbe43OKEfvRkNI9NVC
/caFUCeYsGY3oFpcKcg3ZXRLsHqtRkw0IA6YuRxnLjwECcfNbI+NOidENYbUQQW4Ht/RgrfY9GDO
e+JKdK+BcCJn0x0+an0rVfq4ACtwk1Jo+IYJNmB51CwhRukOVX9ZbLjQb7mi4I9r6MlYSGgS0BW+
K++QVUSt1rJaHzT2PBv0KQjy9exRVo2a8KrGts5E61qNb/lkA5IXIB1t7g59DuKky+EAdMTbnidk
nnbriM5jOB+QPg/vdrW0QNzga7b1tWLH10rysjQa9impsaVS7Cyw1o3CXg0I693VxeUe3qXuY2C+
uxqdsuWgqC3rOToFRCpbDhdDwZ/TfvK4mPFqDemjjHbyAV22wnYGTYAoY+ZBDg44vAMXn60DGbpT
Qe7kwgXoToUAAtoDgEp0AgShE4D5LwCWYBfHN4dnBUFmfKfwGd9umP2dHHxpbkgbC+a55NRU/dKT
TCpN5sdIIg47AHRz0A88mkIEH41FaqAx670+8LMU2tDuvkyg3d7WTR6Yt43VMw7XBe92OEiA3m8b
L9uOaEnKehj+m5wuY/8ylB4K0bqFllm9HY40lhX+JTMU0auh4r1Q/ePD8Irs5oQBZMY9zfu2nCXS
UA+xZntyPKoovF3Tesf7PBaxnT+sN92r7fJn8TpXR+U7/1kuO6sP4FVUpA3o5zrkSXAU41zIk7bN
k4nkSSS/ID0YsgoGp2yV+hhORlcvzWewoy8wRn5GIrke3CPNi3D9boD8pMb//6ufQ6QHO1B9aTBO
gr7zVt+uffYRLmQJjg6wArLsB547FW/Hai0uLMVeDq1lP+MqTbHq/shGBTTlfusiZSuy+etbakS+
aimZWkmm3B14v6Orv4Ko7eqjpgLEsVWAtdT+I166F39b1jR7Gmq2yuhl8vmwTjh3ZPYQ6JE60UnO
zO3ObGEK7EIOyDsQOiuFS/x2lKPmd9w2xDTJYXOJ6Z7SDedlPlMXw9Hg/eU1Fmbyd8S4fHd1eqAR
BzTdGhFot0a6yZm5OzqNdcE79WGL5HAao8QYmVhXX3snVeUVxN8NgHMYfDmjIBYUL4YXDDfAr7Db
lONdWwqN6HYAPpRBG0X1sxnzNHfHW2yy8gCr1xr03cx5R6UJGzjaEehc4cmKRkXFn4bZBRqs13nE
dLScyj0QqdjlsyyvaQ3dFBPf0BzI+MtGVa6PB0ud0K2/t5KmwBikfYAaB/dammMaAT/incuGhYo5
d0LqTHJ7OCzsKNv+SWV/n98hhqlhzUnREMIuuqMtKprNgLswsGHHQ4EPKrFtv5kHmnEtPPgUhzRe
8XzmcT7zOJ3BsplM+V7oiouD6/YHqZwGKUPz2wO1HdQiO2BENNwoT2qajTZEMGeEu+/0Kmn2QK/u
z+rVt3rNgl6zmDXrg2Yz0pKXp5YCBM2qF9SnwwMNN+oZelUNDpuRdngo8TwzZDiCrmGCoSOcQyLU
iYlma8QHMlLEI6ieL1/jjID3yQ2qnn9jOaTnJyy6ZtIqkbmLvNJ9iryEuUsV4EwjD1jDkyAwt/Wt
7QWCYC06OEaOjoFzB7oGxMpETqd7wn2K1GTDJ2q9UJPmvv6mLYlwtq/iTxqDE2J+LRYQXTLOoTYR
drsnDd9yP1HjZVOv0RajM7boa23IsfdZqS+bnTcJZ/DJ7QQo7xNTiFhqsVl/WTxDSnbYGxjK7cBQ
sofB1ImT3WZ+R1/QDjbj+BLczjhaMb2k6HEIgRQkB7xX9Wq1edDWUhT2yTuEQO3yqgU94MzpVCaB
TLaCsxKSe9reyz1joRRRhSFDm3pPpnDJb4TaLEl/aQSGtq2nMUEzXogkWGMNKY141PDOKUGAOiGf
ZZ7y1k86PqjFFsoctAQdtVig3bW4mzwwbyt1kbS9RwAn5THiTihJxtDjkj13dwt/nv0PwCeDVaoG
I+oSEjUa9Iz6FRLjV0CENPukTKLeqo+fEzXpmQIFMMoXBQry0HOJhf69PbjvjeAIEjThQEtTEE4Z
Z34Hp8Uo4VvAwc0vLZLLQFYgMkUeZ0nYI188QSqXQ/7JCIWFCSgtQgbFImO2eGbxKg8q9iKMLdoD
FrjkR/kExQEck7F8AWeLAQVKBPauZM5lib3XQ3vgwKnpem9yfrfPYrzaZ6jzsMeb8YSls9ieIkoh
FzFKi5DiVy4ObAu7z5b2e2zz4oCtoLQIRday/d8ArgdyiwplbmRzdHJlYW0NZW5kb2JqDTMzOCAw
IG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgNDgxIDAgUiANL1Jlc291cmNlcyAzMzkgMCBS
IA0vQ29udGVudHMgMzQwIDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3gg
WyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMzM5IDAgb2JqDTw8IA0vUHJv
Y1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiA0ODYgMCBSIC9UVDQgNDkxIDAgUiAv
VFQ4IDM0NSAwIFIgL1RUMTAgMzQ2IDAgUiAvVFQxMiAzNDcgMCBSID4+IA0vRXh0R1N0YXRlIDw8
IC9HUzEgNDk1IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSA0ODcgMCBSID4+IA0+PiANZW5k
b2JqDTM0MCAwIG9iag08PCAvTGVuZ3RoIDI0MTIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0
cmVhbQ0KSInMV9ty2zgSfddX4JGYsmgC4A2uyoMta2c9STzZiJ7aKjsPjEQ7SmxLQ8vjzSftX25f
AIiWRMWpzW7FrhJJ9AWNPo2+nFSDw6pSWihRXQ+UipNUJPDPbzaB3yQXRZrFpajuBoejh0xMH4gl
EQ/TweGvEyVuHgZD4ExMJqrpAN9KI6qnwWU0Wtxfy2EZm2jRymERp9EdP2ppYx3dTxtRNQ8SV1bM
JybLhmhTOTRxFs2d/HxaO4754l5IlcQ28qrlUMVF1EoDasRkVL1LCuFYtp7+c/P7O5/fyf5H444v
FB0uZssT+riKkJZFx0t3BJ0dOGdo5kiSKyk/VL8RVgljZWObEwr04pHK8IlIIQppgXgQNKpwgEgb
LZZfW0melBlsd/NpRU8BbtSxiv4ttQVrxN9lGj3efAJ4GJfFNbEx8xPoqVlLIyZfmYdJzR0I8sKB
RGDgFEnizS/Z+kQAZirLc1Gdkq05hQ4aGalEyeozMvuwhOjLslTk4EGbogSfSflwS5U73cVbOdSg
OLp4c1yd/QEnMuD+sajQn2U0kQn8novj0esNe4Z+j6GOjSnWm6A3eROT8iagS+WwxVgOU9AIO+Rh
TZxfvD3BvRz5vTgSVg5zcEsMHskjQ/uOq4ESczEo0zhNlMhtTmDGaSmG9Ns2g+tvU8syUNMU7NZd
eqaLWPeLf4Pc2RuWmKoNxtaW9C76SdUTn3kOgOQg6UM0XYeo8+97cFQRNVJDEF5LCkn+aBs5tODD
e7xUaTRtjiDeFN54kkAMFATdOznMMOpANJq1tVOxIt4hf8zpg7WuEB7MJcmaDtELPLR+w5uxeEtM
9X1gA4inTFq6taSIeeFfXUF/t9jSW1qr+TSPzIdbskECkIyNqN0xZyKLdYxhlkbKR4+Hp4AU2R8a
TN0TGr3iXnnisTUpcm5J76L3Y6/L2GqHvMpCclLaJafqTGo8ZvVG6pSuEDlNHEmVU2qXqgCPHUtd
oCej15vuMGWc6V53MHWPO3rFvXIsjr3u6KH3uiOzBuzyF8ElQHjT7h5MLk6wLigKbAyYM8qp/usN
ZGDIMZCZj8T0EWMei6uy8HBft/UKghiCqIj+kjk4rsFCCQJexYTiDdKhhItjwaW03ZZXE7O+49te
Zeoer/aKO+V7sssuYr8/C+J1/tQhb6Nn0Z/v8HhFdEE16T04pPBLv0/GR6JaiOkn8DAUsOkXeooV
f9crMcecjklCYQIAQ6aNW/qLRSAxQIISs2bVTFcPMo/EDcsSYSnm904lS7mNWFFXxUzM6lUNljyy
gLMENTLDn4RdARiTEHNNmwPMFyWlC5dqJscjDAMDeFIRdstPmEkKyG6GkqKzBhHfKskmD7nZ+/Ba
UoqFZgajqr65Q4cYCizMVfcSM9pKphhlbbNctO4dWzwN+yC5vqU1/hUfG0dsyMxnGj7WU6f4Cy0j
DIiX2zVsjoKzOcnULNrcMudXkos3Ijor7J6K6qj9Ed0v7pWHeIe+2ebb0rvo/XENwR/SZqKLENem
E9fQasgiGg+5ZuAFN5gdsPmcgEdytyRGwPX7+elZl+8M00IOy0eYCdKobSmWiujGVWJsmjhyc4pc
WMOIdMBjQEAgWArHVeMimOmPxD11XCzL16rAa+XFebvZcjHntxX3wSfr+xHMYJtq+nDXClSeUpyo
iOyHU2nopjdBN2ZPcXDUPaD3invlIfnvyGR99H7QE+ANmIe5KskY8/E/CfUcMVbUV+TgD4ITrtL4
VLwdI+xpxL/HeOnL6Nex4G8n9Y+L8Tk5zjgFYyi16LXqF04AZp0AXLCN8YIagkryfce2fz08IAB4
Uzt/2If1v61fX8r3IsZeO09erotcYaCtNwBA4rOi1gGMkn0SJC7e4LXK4Uai5NCL4kgBTU5QYIMC
N7aIU3KbJgA14OA+xaVfmJy/Uh++0xE/yJ8vejvFK++sblu6sRZurCsrcJlza/H8l+vI+KH7/6i3
iTvDiErS684BsqJ0B3gJWPpnBmsfWirOFKTDzU6AItZH+0v341vgNcIlUJhQWGOmQmrR/hZcQbYq
oNQr5UY0zPAVJaicSOeUvIQRV9Ij862r9RKwUg/W/w+tq6g6n8BBbhdYJzMqeJA1D24IinrpGslm
trsz02U4pw6o/C8i5Ye8zbE5yCL+xTJuoVurV9ijwcAFPVqJhR0dkbqGQlNHUEYzmG8QrWO8jzCZ
rHFfp5SelPoT+6M3zQDIaZr/5Hnykmvc+v6IcJgh9FLR61f64G9tzZH8Sh1sR/BPfDgxWbUrOMD4
nsyn+FMRpPPNZlIlvZ0kkPa0kbsFSWdi1x2mtna7iexj6O0iUcr1kEmYG7Rr5RDBDFtBTUMCYFi4
NXE6nozen0GLaXlIQI4zmA82vKAxEvr8wMR+T/QKe83KHxUSAhx7S3gXvdcTqrTeE3koZpGKZfV5
cFhVqQBHXQO5yKxr9ZAL2lqml0xXoKzUnV5waxjD+cqNSH7q+eKmnu78BLPP/FrSDMYzDhO7k07r
agAPUptzD/PfPxuomj5VbiSbMtsjSzmzHuQwC4x/Pjqp7lg2bQ6EGwhnMD/QsHksKXlB6tKh9X/C
2WtOk9uzswp30JbHzNqPjER0c+OzDVe7i57J1tOIG4PaZrlooa3HGvFAJeITFZn6ltb4V3xsHLGR
ipxmqeIyrZ5+oW90aQEuuEMr8QE2aycxmxNzzTJYt5Dzq9RIjH2bUyaF3rS5E2v6v421rRrH1eMT
d28cbYpgtS7aUkeEaKPI8I2eguBiyoIT3O1MLDDebj1LyxGzWtBMg9DQvAkOq7lhEUvgWbRcC2ZN
28wof4KWR9LA+XPI9EXLHN0N0Hvg/vkq3kgqypb9SYWJ/UmlV9hrDkkjK7bIKdia9gr3Uskupu43
bNfegb5b/TfIh6OHTIwmlO4SMRkNlPgNouczMEIsPgkoNm/F5YdEzAbKwjlSJaBtgqe4GxgF/VYZ
Fm4HE1rSxJPhFsCjU4jCDk/gKKAvK2Hh+hdaK3HNGNaMW5VJWEDNymasyMDRkaUsWI9nCQzaAoCk
1/MYWziLof7pMiyQxYklMWONs9gZE3g8B2AYLA6ajQXmrmZeeKbZwBzyTLPnCRwp9O4bvtA2R7zW
vnALXV+YBAvg2heBxTNoCw0W603zhH1cOL1+QRvF1kDj+BzftOQzdfDFpaSLb2oddJ4ncHTw9ZoD
Dl5zBwcvF3DwmgNP0NzB4T8DAET+h6IKZW5kc3RyZWFtDWVuZG9iag0zNDEgMCBvYmoNPDwgDS9U
eXBlIC9QYWdlIA0vUGFyZW50IDQ4MSAwIFIgDS9SZXNvdXJjZXMgMzQyIDAgUiANL0NvbnRlbnRz
IDM0MyAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3
OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTM0MiAwIG9iag08PCANL1Byb2NTZXQgWyAvUERG
IC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgNDg2IDAgUiAvVFQ0IDQ5MSAwIFIgL1RUOCAzNDUgMCBS
IC9UVDEwIDM0NiAwIFIgL1RUMTIgMzQ3IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDQ5NSAw
IFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgNDg3IDAgUiA+PiANPj4gDWVuZG9iag0zNDMgMCBv
YmoNPDwgL0xlbmd0aCAyODc5IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ1Fdb
b9s4Fn73r+CjNKgVkroH2IfEMWY8nabdWJndRTsoVFtJPJPYga0k25+0/3LPjZJ8kduis8BsAlgk
z+Hh4XeuPC8GJ0VhrDKquBkYE+hIafjnUa7hVycqjeIgU8XD4GS0idVsQyxabWaDkx+nRt1uBkPg
1GGsitkAR1moipfBe2+0Wt74wywIvdXaH6ZB5D3wp/TzwHrLWaWKauPjSs18avpYEW3mD8Mg9hay
fzErhWOxWirf6CD3nGh/aILUW/shiFHTUfFOp0pY9r5uujv/xu83sv9ayfWVocsFrLmmyQcPabF3
9ihXsPErAcMyh9YffP+34meylWZb5UGekBVo4CwV4xcthVaIUrQHmcakYhA/91aPn9c+IenHcNzt
XU1fBTDawHj/8W0O2qif/Mh7ur0D87BdVjfExswvIKdkKZWafmYeJlUPsJEXXvloGLiF1k79jLXX
Cmxm4iRRxQXpmpDroJKe0dYvfkdm55ZxEANDEgcmt5nbYZyzWb7a1XjqD3O4wBjUCL2rX+E+Jsi8
8YUa/XR9+VoV/3o33lFjCKKzJI3V0AZhlEdOtg4b4QJc4SNvBMLBLUNv6psIPm5VXV6/OWcLC8OV
OgVbD2O4v/YTWAgMnT0uBkYt1CDTQQZXSNKIQi6IMjWk33U1uPkS1QQ2a6gRBKfeoscWDkx6t3+B
3JwN4ZcI1YbIubP7MP282HHNLAkidM0kglCwzjdtkyt0LPYDmDKv8nWQQGRD3FiZrCuyZOwtwali
b1adqilinYA34xY0Qgjc73gRYs5683UpMuohfxcV5Y8Mswa6hSxvQISBSCDSLR1Qr8tlQwUL5t6s
fpQFnQb1v5lLuYBhLe591KF8YoGsubKBdVZ3sEKExrbXpEw9YtKe7a3wxqKHbNZD77eZAZcWk5m4
SSemiYqJbzFlFb/4NqLQI0TUqW8SDIs3vgkp0dB045scZjNcREvT555p8il5celbzBzCsoIkmHpP
9CsyoGwwTea1HDjyrXZChFTtWgCU74MfSEewP7TRyUxasxwCvofeC3ycww0yFyxx2CRyK5V1CkXT
etd+BG52jhEAsr0JXNxzk18QhRRNAr+nPnjjFSCYAB5hwAk6l/H62Yf4AqTmanTHw6flHzxQEDWJ
95nN/FgFu2DqEO/UhydTj0Das70RfgTSQ8R+PFPiFTzDpti856xhAEmLWRtQDd3S2+n4VBUr9ewj
UFCuvPXi5jN6piFYsMLdYR2s4XAM+8SxUUKKPNo4VzNkQkDzZptIeaxg56xatCfM1YI5lshdqnlZ
l7cwRJGwWmImhB7KYgZzrHy0mi94MCvX82q+a6g4ZWAOG0qo/Ybq294Kb8x4wFZ99H5zRQlOXa1o
qrFOO0bLqGQk3hhzs1QBqr+GCnQE8eEW1Yg4315eTLq8E39oYZF5T9UZRkyCSR9T+MbH1L/Ccp56
s0VZQ+PJrRDgngtZ8ZJw1ari5br8dC9cJOuOOyUf43KuPmEpyqGHstgeVFzeUk+kV/ydP64WS2mr
wqY5ExVVubVnrs4Dp/0aqhct3nbOVHSgaEFOpUA4esheIxa2TaNDGzTC1IsaAVKRx9OaxupcbSho
OD3PKPlQXGDnxzw8KWUDOTUNS2G+JTq4ONbM8sGn9OVu/OKbGOszlvauOIq5lG6IwbAm9hRjDjHl
qMOqgXHHqpCIzxw7EHkik4WorqylaMofsK0Vu/Sj0JonRv9o6cpdcsli5Hy3gY8VOPizl2PjOGk7
rf3QZeqR0O3Z3grXLjTDCDn3dh+i94cu+OWxNm/8T+nTKFDNTg8Hzfqb8ZRw4N8zruU/jhXPZdff
r8eXAiwLGEPPgbAVP7AXtxVTS8Uco0FCsZ/HE0C8azsspqrzh51k/6gdfi3fsVGveudfK6EzIihC
yDwhGEC70LZJY4yIMTm09xoaBwMZFkUMnYzdJGFbeOX59QEMga/Y+9VGGnlMw/MP/lei+b8d9WrX
SYJR1N4vap+jk8tJge9RTY9Eg54lTKYFwTg8/wJ3PTSCS2Ba5UCz4OYfyd0jgiXyXndjR0fOTdBh
8Fqjt29fTyDy4jii165yqAEg8Bho/Ctv/OsvjAdf5iNWbAl6SyhYQWGvItqsuZb4+gV1ZZmUHXAr
LseWOzN8gg7pOfSC0vF1GeKDEbu1mIpw9g1Z5k8Y4e0M9yioYg5a8O/TcjFzfQ3odP24lUI7TfJV
Ux2Nt9XpSosrKXREbHdP2LxSu1sQEGmn3/1Tbn1o8aLT/qoaW+5qr3t+6N7vwKPqgze5oBeV+pvS
mh9A2hgeGA0NQYIwaqzreLBpaG6gTZtStoNDpx08L85wO8ZiDC7Y8neyy/9HMPFoetYNoE7nAlZv
nr37nQtTj3QuPdtb4ZCq5FEB8O7t3af2di2hhmQYua5FbNXxDDbVGHu4HDoTg07Na+piPB1dTaCp
gTcOriHH5O3l6Q4WIexpFNrDQqj9WPRtd8LDtsczhNrO7sP0XjxsbnFgHCJJWw9NgNXwpCgiBeQb
IKdxLk0GckFoMD1jOtohs20XYhrHNuLY1ONZr64rySMPkI8S79EfYvasVb2C18qihidYRe00sizB
4SDBlPjeij3+XfEGfqsBXwJChe8G8l2CecByR080yNYUytWWTH544aj2LSfz9ukFzg7anEMphIQZ
cC+qJnIIZB38VvwKjJtXIBzJC0L3NbzYhIWOcJfiWSU05BOV+GL8dIKMhmtyl3ILss6jCXVdkLya
Vbjree/lbReTsz34ZYUKWMrwQd48qHJ5UOXyoIowtVtI7EE3te7nrivKD9Vsxck5I5ga1S0+ZaGi
AExDNmeCRfWW+ai2GllUT/xdYDXFPhlZmBHg2aLdMrG8V07EA3nB031Zr9asMICR6dTu9n8dd7ff
6e77WHCuFBBmotoffIXuW8R6p9A4gFGh3ZAbEdO6bK5DwG11G2B0wVehGRMyo6EKiE3IM5+K1nyi
4ZL7IDlezsFyjcVagBTk5wseYIWt5vv4dZyqg1/4HfiRV8bGAZg5AO/AoKmH0OWoO8YjwJYBXkPs
aVsUMco3m5XgNcNdC+YpcVzzWJaAzWLULJUsbLi5c+KWTo5sU3OZO3ZZf1pzwH0SMinreL8Wtug7
3S5qHyemiUE0JgR1gAELPhVh08efO3wdgKqq/LR6dmMm8QbMCAgY7ZmVeMNcFpmhk3piyjYshBmX
PFPbU37rgkCZi/RzxassXW2xqNW2vnT0WnW1E91EeRFyT7MFpiwLzt7ZDN0xwrJayeqic+mP/yh5
ysJeUc97dAOAEEF/AEl8606venJv1ObeiI00hbhE58F9gBC6HPYaL9xyLIn2cYoJTUNq4HmtSh7M
1dQfJsB3h8UBMt1hUdAUAKAfr9h6s4pgyb1n4sbGPhY37XQv2h7rXph6pHvp2e6Em7Y7yYmzS7Y6
P9IG9lFZM6Ee0+zw2Y7eI/4L5JPRJlajKfVVWk1HA6N+hjj9HRgh6l8UvCXeqPe/aTUfGLgHRitE
L0p6GBBWWbNwP5gOUMkMedIMlUUeKGRRh6fhyFAvWLj5oWWKc1x7gKPSINHNAkrGJdqXhEFoiUfU
cTwNRxzzUSC5YQoh33VVpvmWxqHGvrqjsbC0DFlgox2Fwbdj21WYF7YUBl8GtDsKO56GQ8NzMNtW
OARa6AAkz+UFVjkXnpAvBT1iFv236zK7ARCGYehGVckBZP/FyE3gs9GrVdmWqgykAdFu/XR5BOO6
Mfjosm6WU7eQBk5Y5UQxIOua0eVgOoGIVqrXiWaaAF6SL6atX5y7c4SyVcizi4Ep0x3ZoOh9RzKX
QgqgzSvLRiiuy2BPqZPtHZHbA1eTgmUKZW5kc3RyZWFtDWVuZG9iag0zNDQgMCBvYmoNPDwgDS9U
eXBlIC9Gb250IA0vU3VidHlwZSAvVHlwZTEgDS9FbmNvZGluZyAzNTMgMCBSIA0vQmFzZUZvbnQg
L1N5bWJvbCANL1RvVW5pY29kZSAzNTQgMCBSIA0+PiANZW5kb2JqDTM0NSAwIG9iag08PCANL1R5
cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UcnVlVHlwZSANL0ZpcnN0Q2hhciAzMiANL0xhc3RDaGFyIDE1
MCANL1dpZHRocyBbIDI1MCAwIDQwOCAwIDAgMCA3NzggMCAzMzMgMzMzIDAgMCAyNTAgMzMzIDI1
MCAyNzggNTAwIDUwMCA1MDAgNTAwIA01MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCAyNzggMjc4IDU2
NCA1NjQgNTY0IDQ0NCAwIDcyMiA2NjcgNjY3IDcyMiANNjExIDU1NiA3MjIgNzIyIDMzMyAwIDcy
MiA2MTEgODg5IDcyMiA3MjIgNTU2IDcyMiA2NjcgNTU2IDYxMSA3MjIgDTcyMiA5NDQgNzIyIDcy
MiA2MTEgMzMzIDAgMzMzIDAgNTAwIDAgNDQ0IDUwMCA0NDQgNTAwIDQ0NCAzMzMgNTAwIA01MDAg
Mjc4IDI3OCA1MDAgMjc4IDc3OCA1MDAgNTAwIDUwMCA1MDAgMzMzIDM4OSAyNzggNTAwIDUwMCA3
MjIgDTUwMCA1MDAgNDQ0IDAgMjAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw
IDAgMCAwIDMzMyANNDQ0IDQ0NCAwIDUwMCBdIA0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZyAN
L0Jhc2VGb250IC9UaW1lc05ld1JvbWFuUFNNVCANL0ZvbnREZXNjcmlwdG9yIDM0OSAwIFIgDT4+
IA1lbmRvYmoNMzQ2IDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL1RydWVUeXBlIA0v
Rmlyc3RDaGFyIDMyIA0vTGFzdENoYXIgMTY5IA0vV2lkdGhzIFsgMjUwIDAgMCAwIDAgMCAwIDAg
MCAwIDAgMCAyNTAgMCAyNTAgMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDAgMCAwIDAgDTAgMCAwIDAg
MCAwIDAgMCA2MTEgMCA2NjcgMCAwIDYxMSAwIDcyMiAwIDAgMCAwIDAgMCAwIDYxMSAwIDAgNTAw
IA01NTYgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNTAwIDAgNDQ0IDUwMCA0NDQgMjc4IDUwMCA1
MDAgMjc4IDAgDTAgMjc4IDcyMiA1MDAgNTAwIDUwMCAwIDM4OSAzODkgMjc4IDUwMCA0NDQgNjY3
IDAgNDQ0IDM4OSAwIDAgMCANMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw
IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIA0wIDAgMCAwIDAgMCAwIDAgMCAwIDAgNzYwIF0gDS9F
bmNvZGluZyAvV2luQW5zaUVuY29kaW5nIA0vQmFzZUZvbnQgL1RpbWVzTmV3Um9tYW5QUy1JdGFs
aWNNVCANL0ZvbnREZXNjcmlwdG9yIDM1MCAwIFIgDT4+IA1lbmRvYmoNMzQ3IDAgb2JqDTw8IA0v
VHlwZSAvRm9udCANL1N1YnR5cGUgL1RydWVUeXBlIA0vRmlyc3RDaGFyIDMyIA0vTGFzdENoYXIg
MTE2IA0vV2lkdGhzIFsgMjc4IDAgMCAwIDAgMCAwIDAgMzMzIDMzMyAwIDAgMjc4IDAgMjc4IDAg
NTU2IDU1NiA1NTYgMCAwIDU1NiAwIDU1NiANMCAwIDAgMCAwIDAgMCAwIDAgNjY3IDAgNzIyIDAg
MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDY2NyAwIDAgNjY3IA02MTEgMCA2NjcgMCAwIDAgMCAwIDAg
MCAwIDAgMCA1NTYgMCA1MDAgMCA1NTYgMjc4IDAgMCAyMjIgMCAwIDAgDTgzMyA1NTYgNTU2IDU1
NiAwIDMzMyA1MDAgMjc4IF0gDS9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nIA0vQmFzZUZvbnQg
L0FyaWFsLUl0YWxpY01UIA0vRm9udERlc2NyaXB0b3IgMzUxIDAgUiANPj4gDWVuZG9iag0zNDgg
MCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHJ1ZVR5cGUgDS9GaXJzdENoYXIgMzIg
DS9MYXN0Q2hhciAzMiANL1dpZHRocyBbIDI3OCBdIA0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGlu
ZyANL0Jhc2VGb250IC9BcmlhbC1Cb2xkTVQgDS9Gb250RGVzY3JpcHRvciAzNTIgMCBSIA0+PiAN
ZW5kb2JqDTM0OSAwIG9iag08PCANL1R5cGUgL0ZvbnREZXNjcmlwdG9yIA0vQXNjZW50IDg5MSAN
L0NhcEhlaWdodCAwIA0vRGVzY2VudCAtMjE2IA0vRmxhZ3MgMzQgDS9Gb250QkJveCBbIC0xNjcg
LTMwNyAxMDA5IDEwMDcgXSANL0ZvbnROYW1lIC9UaW1lc05ld1JvbWFuUFNNVCANL0l0YWxpY0Fu
Z2xlIDAgDS9TdGVtViAwIA0+PiANZW5kb2JqDTM1MCAwIG9iag08PCANL1R5cGUgL0ZvbnREZXNj
cmlwdG9yIA0vQXNjZW50IDg5MSANL0NhcEhlaWdodCAwIA0vRGVzY2VudCAtMjE2IA0vRmxhZ3Mg
OTggDS9Gb250QkJveCBbIC0xODkgLTMwNyAxMTIwIDEwMjMgXSANL0ZvbnROYW1lIC9UaW1lc05l
d1JvbWFuUFMtSXRhbGljTVQgDS9JdGFsaWNBbmdsZSAtMTUgDS9TdGVtViAwIA0+PiANZW5kb2Jq
DTM1MSAwIG9iag08PCANL1R5cGUgL0ZvbnREZXNjcmlwdG9yIA0vQXNjZW50IDkwNSANL0NhcEhl
aWdodCAwIA0vRGVzY2VudCAtMjExIA0vRmxhZ3MgOTYgDS9Gb250QkJveCBbIC0yNjIgLTMyNSAx
MDgyIDEwMjUgXSANL0ZvbnROYW1lIC9BcmlhbC1JdGFsaWNNVCANL0l0YWxpY0FuZ2xlIC0xNSAN
L1N0ZW1WIDAgDT4+IA1lbmRvYmoNMzUyIDAgb2JqDTw8IA0vVHlwZSAvRm9udERlc2NyaXB0b3Ig
DS9Bc2NlbnQgOTA1IA0vQ2FwSGVpZ2h0IDAgDS9EZXNjZW50IC0yMTEgDS9GbGFncyAzMiANL0Zv
bnRCQm94IFsgLTE2NyAtMzc2IDEwNzUgMTA0OCBdIA0vRm9udE5hbWUgL0FyaWFsLUJvbGRNVCAN
L0l0YWxpY0FuZ2xlIDAgDS9TdGVtViAxMzMgDT4+IA1lbmRvYmoNMzUzIDAgb2JqDTw8IA0vVHlw
ZSAvRW5jb2RpbmcgDS9EaWZmZXJlbmNlcyBbIDEgL2NvcHlyaWdodHNlcmlmIF0gDT4+IA1lbmRv
YmoNMzU0IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMjEzID4+IA1zdHJl
YW0NCkiJVJAxj8IwDIX3/gqPnBjS3oCEVHUBIXWAO1FgTxO3ikScyE2H/nuSUkAMsWS/fHrPFrt6
X5MJIP7ZqQYDdIY04+BGVggt9oag+AVtVFi6uSorPYgIN9MQ0NbUOSjLTJyjOASeYNVMtnX3df4D
4o81sqEeVpfieouDZvT+jhYpQA5VBRq7TOyO0p+kxSgv6DwvFkOncfBSIUvqEcq8qJ4FSX9rL6Lt
nu3na3nY7LdVFomXluC0ydtbjcwx1rzunChlMITvi3jnk2V62UOAAQBTRmlyCmVuZHN0cmVhbQ1l
bmRvYmoNMzU1IDAgb2JqDTw8IA0vQ291bnQgMTEyIA0vRmlyc3QgMzU2IDAgUiANL0xhc3QgMzU3
IDAgUiANPj4gDWVuZG9iag0zNTYgMCBvYmoNPDwgDS9UaXRsZSAoQ09OVEVOVFMpDS9EZXN0IFsg
NCAwIFIgL0ZpdEIgXSANL1BhcmVudCAzNTUgMCBSIA0vTmV4dCA0NjUgMCBSIA0+PiANZW5kb2Jq
DTM1NyAwIG9iag08PCANL1RpdGxlICg2XHRUZXN0IERlc2NyaXB0aW9uKQ0vRGVzdCBbIDU2IDAg
UiAvRml0QiBdIA0vUGFyZW50IDM1NSAwIFIgDS9QcmV2IDM1OCAwIFIgDS9GaXJzdCAzNTkgMCBS
IA0vTGFzdCAzNTkgMCBSIA0vQ291bnQgOTEgDT4+IA1lbmRvYmoNMzU4IDAgb2JqDTw8IA0vVGl0
bGUgKDVcdFRlc3QgbGlzdCkNL0Rlc3QgWyA0NCAwIFIgL0ZpdEIgXSANL1BhcmVudCAzNTUgMCBS
IA0vUHJldiA0NTAgMCBSIA0vTmV4dCAzNTcgMCBSIA0vRmlyc3QgNDUxIDAgUiANL0xhc3QgNDUx
IDAgUiANL0NvdW50IDYgDT4+IA1lbmRvYmoNMzU5IDAgb2JqDTw8IA0vVGl0bGUgKCkNL0Rlc3Qg
WyA1NiAwIFIgL0ZpdEIgXSANL1BhcmVudCAzNTcgMCBSIA0vRmlyc3QgMzYwIDAgUiANL0xhc3Qg
MzYxIDAgUiANL0NvdW50IDkwIA0+PiANZW5kb2JqDTM2MCAwIG9iag08PCANL1RpdGxlICgpDS9E
ZXN0IFsgNTYgMCBSIC9GaXRCIF0gDS9QYXJlbnQgMzU5IDAgUiANL05leHQgMzc1IDAgUiANL0Zp
cnN0IDM3NiAwIFIgDS9MYXN0IDM3NyAwIFIgDS9Db3VudCA3NCANPj4gDWVuZG9iag0zNjEgMCBv
YmoNPDwgDS9UaXRsZSAoUkVTRVJWRUQgQ0hVTksgVFlQRSkNL0Rlc3QgWyAzNDEgMCBSIC9GaXRC
IF0gDS9QYXJlbnQgMzU5IDAgUiANL1ByZXYgMzYyIDAgUiANPj4gDWVuZG9iag0zNjIgMCBvYmoN
PDwgDS9UaXRsZSAoQ1VNVUxBVElWRSBUU04gQUNLKQ0vRGVzdCBbIDMzOCAwIFIgL0ZpdEIgXSAN
L1BhcmVudCAzNTkgMCBSIA0vUHJldiAzNjMgMCBSIA0vTmV4dCAzNjEgMCBSIA0+PiANZW5kb2Jq
DTM2MyAwIG9iag08PCANL1RpdGxlIChERUxBWUVEIEFDS05PV0xFREdFKQ0vRGVzdCBbIDMzNSAw
IFIgL0ZpdEIgXSANL1BhcmVudCAzNTkgMCBSIA0vUHJldiAzNjQgMCBSIA0vTmV4dCAzNjIgMCBS
IA0+PiANZW5kb2JqDTM2NCAwIG9iag08PCANL1RpdGxlIChOT1JNQUwgQUNLTk9XTEVER0UpDS9E
ZXN0IFsgMzMyIDAgUiAvRml0QiBdIA0vUGFyZW50IDM1OSAwIFIgDS9QcmV2IDM2NSAwIFIgDS9O
ZXh0IDM2MyAwIFIgDT4+IA1lbmRvYmoNMzY1IDAgb2JqDTw8IA0vVGl0bGUgKFVOLU9SREVSRUQg
REVMSVZFUlkpDS9EZXN0IFsgMzI5IDAgUiAvRml0QiBdIA0vUGFyZW50IDM1OSAwIFIgDS9QcmV2
IDM2NiAwIFIgDS9OZXh0IDM2NCAwIFIgDT4+IA1lbmRvYmoNMzY2IDAgb2JqDTw8IA0vVGl0bGUg
KFJFVFJBTlNNSVNTSU9OKQ0vRGVzdCBbIDMyMyAwIFIgL0ZpdEIgXSANL1BhcmVudCAzNTkgMCBS
IA0vUHJldiAzNjcgMCBSIA0vTmV4dCAzNjUgMCBSIA0+PiANZW5kb2JqDTM2NyAwIG9iag08PCAN
L1RpdGxlIChDT05HRVNUSU9OKQ0vRGVzdCBbIDMyMCAwIFIgL0ZpdEIgXSANL1BhcmVudCAzNTkg
MCBSIA0vUHJldiAzNjggMCBSIA0vTmV4dCAzNjYgMCBSIA0+PiANZW5kb2JqDTM2OCAwIG9iag08
PCANL1RpdGxlIChVU0VSICBEQVRBIElOIHJ3bmQ9MCkNL0Rlc3QgWyAzMTcgMCBSIC9GaXRCIF0g
DS9QYXJlbnQgMzU5IDAgUiANL1ByZXYgMzY5IDAgUiANL05leHQgMzY3IDAgUiANPj4gDWVuZG9i
ag0zNjkgMCBvYmoNPDwgDS9UaXRsZSAoQlVGRkVSIFNQQUNFKQ0vRGVzdCBbIDMxNCAwIFIgL0Zp
dEIgXSANL1BhcmVudCAzNTkgMCBSIA0vUHJldiAzNzAgMCBSIA0vTmV4dCAzNjggMCBSIA0+PiAN
ZW5kb2JqDTM3MCAwIG9iag08PCANL1RpdGxlIChUMy1ydHggVElNRVIgRVhQSVJFKQ0vRGVzdCBb
IDMwOCAwIFIgL0ZpdEIgXSANL1BhcmVudCAzNTkgMCBSIA0vUHJldiAzNzEgMCBSIA0vTmV4dCAz
NjkgMCBSIA0vRmlyc3QgMzcyIDAgUiANL0xhc3QgMzcyIDAgUiANL0NvdW50IDEgDT4+IA1lbmRv
YmoNMzcxIDAgb2JqDTw8IA0vVGl0bGUgKENBTkNFTCBUMy1ydHggVElNRVIpDS9EZXN0IFsgMzA1
IDAgUiAvRml0QiBdIA0vUGFyZW50IDM1OSAwIFIgDS9QcmV2IDM3MyAwIFIgDS9OZXh0IDM3MCAw
IFIgDT4+IA1lbmRvYmoNMzcyIDAgb2JqDTw8IA0vVGl0bGUgKERVUExJQ0FURSBEQVRBKQ0vRGVz
dCBbIDMxMSAwIFIgL0ZpdEIgXSANL1BhcmVudCAzNzAgMCBSIA0+PiANZW5kb2JqDTM3MyAwIG9i
ag08PCANL1RpdGxlIChTRUdNRU5URUQgREFUQSBSRUNFUFRJT04pDS9EZXN0IFsgMzAyIDAgUiAv
Rml0QiBdIA0vUGFyZW50IDM1OSAwIFIgDS9QcmV2IDM3NCAwIFIgDS9OZXh0IDM3MSAwIFIgDT4+
IA1lbmRvYmoNMzc0IDAgb2JqDTw8IA0vVGl0bGUgKERBVEEgU0VHTUVOVEFUSU9OKQ0vRGVzdCBb
IDI5OSAwIFIgL0ZpdEIgXSANL1BhcmVudCAzNTkgMCBSIA0vUHJldiAzNzUgMCBSIA0vTmV4dCAz
NzMgMCBSIA0+PiANZW5kb2JqDTM3NSAwIG9iag08PCANL1RpdGxlIChVTi1TRUdNRU5URUQgREFU
QSkNL0Rlc3QgWyAyOTYgMCBSIC9GaXRCIF0gDS9QYXJlbnQgMzU5IDAgUiANL1ByZXYgMzYwIDAg
UiANL05leHQgMzc0IDAgUiANPj4gDWVuZG9iag0zNzYgMCBvYmoNPDwgDS9UaXRsZSAoTm9ybWFs
IEFzc29jaWF0aW9uKQ0vRGVzdCBbIDU2IDAgUiAvRml0QiBdIA0vUGFyZW50IDM2MCAwIFIgDS9O
ZXh0IDQ0OSAwIFIgDT4+IA1lbmRvYmoNMzc3IDAgb2JqDTw8IA0vVGl0bGUgKFNBQ0sgaXMgcmVj
ZWl2ZWQgYnVuZGxlZCB3aXRoIERBVEEgY2h1bmtzKQ0vRGVzdCBbIDI5MyAwIFIgL0ZpdEIgXSAN
L1BhcmVudCAzNjAgMCBSIA0vUHJldiAzNzggMCBSIA0+PiANZW5kb2JqDTM3OCAwIG9iag08PCAN
L1RpdGxlIChTSFVURE9XTiBpcyByZWNlaXZlZCBidW5kbGVkIHdpdGggU0FDSykNL0Rlc3QgWyAy
OTAgMCBSIC9GaXRCIF0gDS9QYXJlbnQgMzYwIDAgUiANL1ByZXYgMzc5IDAgUiANL05leHQgMzc3
IDAgUiANPj4gDWVuZG9iag0zNzkgMCBvYmoNPDwgDS9UaXRsZSAoQ09PS0lFLUFDSyBpcyByZWNl
aXZlZCBidW5kbGVkIHdpdGggZGF0YSBjaHVua3Mgd2l0aCBjb29raWUgYXMgZmlyc3QgY2h1XA1u
aykNL0Rlc3QgWyAyODcgMCBSIC9GaXRCIF0gDS9QYXJlbnQgMzYwIDAgUiANL1ByZXYgMzgwIDAg
UiANL05leHQgMzc4IDAgUiANPj4gDWVuZG9iag0zODAgMCBvYmoNPDwgDS9UaXRsZSAoQ29va2ll
IGlzIHJlY2VpdmVkIGJ1bmRsZWQgd2l0aCBkYXRhIGNodW5rcyB3aXRoIGNvb2tpZSBhcyBmaXJz
dCBjaHVuaykNL0Rlc3QgWyAyODQgMCBSIC9GaXRCIF0gDS9QYXJlbnQgMzYwIDAgUiANL1ByZXYg
MzgxIDAgUiANL05leHQgMzc5IDAgUiANPj4gDWVuZG9iag0zODEgMCBvYmoNPDwgDS9UaXRsZSAo
Q2h1bmsgTXVsdGlwbGV4aW5nIHdpdGggU0hVVERPV04tQUNLIG1lc3NhZ2UpDS9EZXN0IFsgMjgx
IDAgUiAvRml0QiBdIA0vUGFyZW50IDM2MCAwIFIgDS9QcmV2IDM4MiAwIFIgDS9OZXh0IDM4MCAw
IFIgDT4+IA1lbmRvYmoNMzgyIDAgb2JqDTw8IA0vVGl0bGUgKENodW5rIE11bHRpcGxleGluZyB3
aXRoIElOSVQtQUNLIG1lc3NhZ2UpDS9EZXN0IFsgMjc4IDAgUiAvRml0QiBdIA0vUGFyZW50IDM2
MCAwIFIgDS9QcmV2IDM4MyAwIFIgDS9OZXh0IDM4MSAwIFIgDT4+IA1lbmRvYmoNMzgzIDAgb2Jq
DTw8IA0vVGl0bGUgKENodW5rIE11bHRpcGxleGluZyB3aXRoIElOSVQgbWVzc2FnZSkNL0Rlc3Qg
WyAyNzUgMCBSIC9GaXRCIF0gDS9QYXJlbnQgMzYwIDAgUiANL1ByZXYgMzg0IDAgUiANL05leHQg
MzgyIDAgUiANPj4gDWVuZG9iag0zODQgMCBvYmoNPDwgDS9UaXRsZSAoR2VuZXJhdGlvbiBvZiBl
cnJvciBjYXVzZSBNaXNzaW5nIE1hbmRhdG9yeSBwYXJhbWV0ZXIpDS9EZXN0IFsgMjcyIDAgUiAv
Rml0QiBdIA0vUGFyZW50IDM2MCAwIFIgDS9QcmV2IDM4NSAwIFIgDS9OZXh0IDM4MyAwIFIgDT4+
IA1lbmRvYmoNMzg1IDAgb2JqDTw8IA0vVGl0bGUgKEdlbmVyYXRpb24gb2YgZXJyb3IgY2F1c2Ug
SW52YWxpZCBTdHJlYW0gSWRlbnRpZmllcikNL0Rlc3QgWyAyNjkgMCBSIC9GaXRCIF0gDS9QYXJl
bnQgMzYwIDAgUiANL1ByZXYgMzg2IDAgUiANL05leHQgMzg0IDAgUiANPj4gDWVuZG9iag0zODYg
MCBvYmoNPDwgDS9UaXRsZSAoRVJST1IgbWVzc2FnZSB3aXRoIGNhdXNlIFN0YWxlIENvb2tpZSBF
cnJvciByZWNlaXZlZCBpbiBzdGF0ZSBvdGhlciB0aGFuXA0gQ29va2llX1NlbnQgU3RhdGUpDS9E
ZXN0IFsgMjY2IDAgUiAvRml0QiBdIA0vUGFyZW50IDM2MCAwIFIgDS9QcmV2IDM4NyAwIFIgDS9O
ZXh0IDM4NSAwIFIgDT4+IA1lbmRvYmoNMzg3IDAgb2JqDTw8IA0vVGl0bGUgKEVSUk9SIG1lc3Nh
Z2Ugd2l0aCBjYXVzZSBTdGFsZSBDb29raWUgRXJyb3IgcmVjZWl2ZWQgaW4gQ29va2llX1NlbnQg
U3RhdFwNZSkNL0Rlc3QgWyAyNjMgMCBSIC9GaXRCIF0gDS9QYXJlbnQgMzYwIDAgUiANL1ByZXYg
Mzg4IDAgUiANL05leHQgMzg2IDAgUiANPj4gDWVuZG9iag0zODggMCBvYmoNPDwgDS9UaXRsZSAo
SEVBUlRCRUFULUFDSyBtZXNzYWdlIGNvbWVzIGZyb20gYW4gaW5hY3RpdmUgZGVzdGluYXRpb24p
DS9EZXN0IFsgMjU3IDAgUiAvRml0QiBdIA0vUGFyZW50IDM2MCAwIFIgDS9QcmV2IDM4OSAwIFIg
DS9OZXh0IDM4NyAwIFIgDT4+IA1lbmRvYmoNMzg5IDAgb2JqDTw8IA0vVGl0bGUgKEhFQVJUQkVB
VCBtZXNzYWdlIGlzIHJlc3BvbmRlZCB3aXRoIEhFQVJCRUFULUFDSykNL0Rlc3QgWyAyNTQgMCBS
IC9GaXRCIF0gDS9QYXJlbnQgMzYwIDAgUiANL1ByZXYgMzkwIDAgUiANL05leHQgMzg4IDAgUiAN
Pj4gDWVuZG9iag0zOTAgMCBvYmoNPDwgDS9UaXRsZSAoSGVhcnRiZWF0IFJlcXVlc3QgcHJpbWl0
aXZlKQ0vRGVzdCBbIDI1MSAwIFIgL0ZpdEIgXSANL1BhcmVudCAzNjAgMCBSIA0vUHJldiAzOTEg
MCBSIA0vTmV4dCAzODkgMCBSIA0+PiANZW5kb2JqDTM5MSAwIG9iag08PCANL1RpdGxlIChIRUFS
VEJFQVQgbWVzc2FnZSBpcyBzZW50IHBlcmlvZGljYWxseSB0byBhbiBpZGxlIGFjdGl2ZSBzdGF0
aW9uKQ0vRGVzdCBbIDI0OCAwIFIgL0ZpdEIgXSANL1BhcmVudCAzNjAgMCBSIA0vUHJldiAzOTIg
MCBSIA0vTmV4dCAzOTAgMCBSIA0+PiANZW5kb2JqDTM5MiAwIG9iag08PCANL1RpdGxlIChSZXRy
YW5zLkNvdW50IGNvdW50ZXIgZXhjZWVkcyB0aGUgUGF0aC5NYXguUmV0cmFucykNL0Rlc3QgWyAy
MzkgMCBSIC9GaXRCIF0gDS9QYXJlbnQgMzYwIDAgUiANL1ByZXYgMzkzIDAgUiANL05leHQgMzkx
IDAgUiANPj4gDWVuZG9iag0zOTMgMCBvYmoNPDwgDS9UaXRsZSAoU1VCVElUTEU6IFRoZSBjb3Vu
dGVyIGNvdW50aW5nIHRvdGFsIG51bWJlciBvZiByZXRyYW5zbWlzc2lvbiB0byBlbmRwb2luXA10
IGlzIHJlc2V0IG9uIHJlY2VpdmluZyAgU0FDSy4pDS9EZXN0IFsgMjM2IDAgUiAvRml0QiBdIA0v
UGFyZW50IDM2MCAwIFIgDS9QcmV2IDM5NCAwIFIgDS9OZXh0IDM5MiAwIFIgDT4+IA1lbmRvYmoN
Mzk0IDAgb2JqDTw8IA0vVGl0bGUgKFRoZSBjb3VudGVyIGNvdW50aW5nIHRvdGFsIG51bWJlciBv
ZiByZXRyYW5zbWlzc2lvbiB0byBhbiBlbmRwb2ludCBpcyByZVwNc2V0IG9uIHJlY2VpdmluZyBh
IFNBQ0suKQ0vRGVzdCBbIDIzNiAwIFIgL0ZpdEIgXSANL1BhcmVudCAzNjAgMCBSIA0vUHJldiAz
OTUgMCBSIA0vTmV4dCAzOTMgMCBSIA0+PiANZW5kb2JqDTM5NSAwIG9iag08PCANL1RpdGxlIChT
VUJUSVRMRTogVG90YWwgbnVtYmVyIG9mIGNvbnNlY3V0aXZlIHJldHJhbnNtaXNzaW9uIGV4Y2Vl
ZHMgQXNzb2NpYXRpb25cDS5NYXguUmV0cmFucykNL0Rlc3QgWyAyMzMgMCBSIC9GaXRCIF0gDS9Q
YXJlbnQgMzYwIDAgUiANL1ByZXYgMzk2IDAgUiANL05leHQgMzk0IDAgUiANPj4gDWVuZG9iag0z
OTYgMCBvYmoNPDwgDS9UaXRsZSAoVG90YWwgbnVtYmVyIG9mIGNvbnNlY3V0aXZlIHJldHJhbnNt
aXNzaW9uIGV4Y2VlZHMgQXNzb2NpYXRpb24uTWF4LlJldHJhXA1ucykNL0Rlc3QgWyAyMzMgMCBS
IC9GaXRCIF0gDS9QYXJlbnQgMzYwIDAgUiANL1ByZXYgMzk3IDAgUiANL05leHQgMzk1IDAgUiAN
Pj4gDWVuZG9iag0zOTcgMCBvYmoNPDwgDS9UaXRsZSAoRHVwbGljYXRlIHZhbGlkIENvb2tpZSBN
ZXNzYWdlKQ0vRGVzdCBbIDIzMCAwIFIgL0ZpdEIgXSANL1BhcmVudCAzNjAgMCBSIA0vUHJldiAz
OTggMCBSIA0vTmV4dCAzOTYgMCBSIA0+PiANZW5kb2JqDTM5OCAwIG9iag08PCANL1RpdGxlIChE
dXBsaWNhdGUgQ29va2llIE1lc3NhZ2Ugd2l0aCB2YWxpZCBNRDUgc2lnbmF0dXJlIGJ1dCBleHBp
cmVkIGxpZmUgdGltZSkNL0Rlc3QgWyAyMjcgMCBSIC9GaXRCIF0gDS9QYXJlbnQgMzYwIDAgUiAN
L1ByZXYgMzk5IDAgUiANL05leHQgMzk3IDAgUiANPj4gDWVuZG9iag0zOTkgMCBvYmoNPDwgDS9U
aXRsZSAoRHVwbGljYXRlIENvb2tpZSBNZXNzYWdlIHdpdGggaW52YWxpZCBNRDUgc2lnbmF0dXJl
KQ0vRGVzdCBbIDIyNCAwIFIgL0ZpdEIgXSANL1BhcmVudCAzNjAgMCBSIA0vUHJldiA0MDAgMCBS
IA0vTmV4dCAzOTggMCBSIA0+PiANZW5kb2JqDTQwMCAwIG9iag08PCANL1RpdGxlIChTSFVURE9X
Ti1BQ0sgaW4gQ29va2llX1dhaXQgc3RhdGUpDS9EZXN0IFsgMjIxIDAgUiAvRml0QiBdIA0vUGFy
ZW50IDM2MCAwIFIgDS9QcmV2IDQwMSAwIFIgDS9OZXh0IDM5OSAwIFIgDT4+IA1lbmRvYmoNNDAx
IDAgb2JqDTw8IA0vVGl0bGUgKER1cGxpY2F0ZSBTSFVURE9XTiBtZXNzYWdlIGluIFNodXRkb3du
IFJlY2VpdmUgc3RhdGUpDS9EZXN0IFsgMjE4IDAgUiAvRml0QiBdIA0vUGFyZW50IDM2MCAwIFIg
DS9QcmV2IDQwMiAwIFIgDS9OZXh0IDQwMCAwIFIgDT4+IA1lbmRvYmoNNDAyIDAgb2JqDTw8IA0v
VGl0bGUgKER1cGxpY2F0ZSBTSFVURE9XTiBtZXNzYWdlIGluIGNsb3NlZCBzdGF0ZSkNL0Rlc3Qg
WyAyMTUgMCBSIC9GaXRCIF0gDS9QYXJlbnQgMzYwIDAgUiANL1ByZXYgNDAzIDAgUiANL05leHQg
NDAxIDAgUiANPj4gDWVuZG9iag00MDMgMCBvYmoNPDwgDS9UaXRsZSAoRHVwbGljYXRlIFNIVVRE
T1dOIG1lc3NhZ2UgaW4gQ29va2llIFdhaXQgc3RhdGUpDS9EZXN0IFsgMjEyIDAgUiAvRml0QiBd
IA0vUGFyZW50IDM2MCAwIFIgDS9QcmV2IDQwNCAwIFIgDS9OZXh0IDQwMiAwIFIgDT4+IA1lbmRv
YmoNNDA0IDAgb2JqDTw8IA0vVGl0bGUgKFNIVVRET1dOIENvbGxpc2lvbikNL0Rlc3QgWyAyMDkg
MCBSIC9GaXRCIF0gDS9QYXJlbnQgMzYwIDAgUiANL1ByZXYgNDA1IDAgUiANL05leHQgNDAzIDAg
UiANPj4gDWVuZG9iag00MDUgMCBvYmoNPDwgDS9UaXRsZSAoRHVwbGljYXRlIENPT0tJRS1BQ0sg
aW4gZXN0YWJsaXNoZWQgc3RhdGUpDS9EZXN0IFsgMjA2IDAgUiAvRml0QiBdIA0vUGFyZW50IDM2
MCAwIFIgDS9QcmV2IDQwNiAwIFIgDS9OZXh0IDQwNCAwIFIgDT4+IA1lbmRvYmoNNDA2IDAgb2Jq
DTw8IA0vVGl0bGUgKER1cGxpY2F0ZSBJTklULUFDSyBpbiBDb29raWUgU2VudCBzdGF0ZSkNL0Rl
c3QgWyAyMDMgMCBSIC9GaXRCIF0gDS9QYXJlbnQgMzYwIDAgUiANL1ByZXYgNDA3IDAgUiANL05l
eHQgNDA1IDAgUiANPj4gDWVuZG9iag00MDcgMCBvYmoNPDwgDS9UaXRsZSAoRHVwbGljYXRlIElO
SVQgbWVzc2FnZSBpbiBTaHV0ZG93biBzZW50IHN0YXRlKQ0vRGVzdCBbIDIwMCAwIFIgL0ZpdEIg
XSANL1BhcmVudCAzNjAgMCBSIA0vUHJldiA0MDggMCBSIA0vTmV4dCA0MDYgMCBSIA0+PiANZW5k
b2JqDTQwOCAwIG9iag08PCANL1RpdGxlIChEdXBsaWNhdGUgSU5JVCBNZXNzYWdlIGluIEVzdGFi
bGlzaGVkIHN0YXRlKQ0vRGVzdCBbIDE5NyAwIFIgL0ZpdEIgXSANL1BhcmVudCAzNjAgMCBSIA0v
UHJldiA0MDkgMCBSIA0vTmV4dCA0MDcgMCBSIA0+PiANZW5kb2JqDTQwOSAwIG9iag08PCANL1Rp
dGxlIChJTklUIENvbGxpc2lvbikNL0Rlc3QgWyAxOTQgMCBSIC9GaXRCIF0gDS9QYXJlbnQgMzYw
IDAgUiANL1ByZXYgNDEwIDAgUiANL05leHQgNDA4IDAgUiANPj4gDWVuZG9iag00MTAgMCBvYmoN
PDwgDS9UaXRsZSAoSW52YWxpZCBTSFVURE9XTi1BQ0sgbWVzc2FnZSkNL0Rlc3QgWyAxOTEgMCBS
IC9GaXRCIF0gDS9QYXJlbnQgMzYwIDAgUiANL1ByZXYgNDExIDAgUiANL05leHQgNDA5IDAgUiAN
Pj4gDWVuZG9iag00MTEgMCBvYmoNPDwgDS9UaXRsZSAoQ2h1bmsgbGVuZ3RoIGdyZWF0ZXIgdGhh
biBwYWNrZXQgbGVuZ3RoKQ0vRGVzdCBbIDE4OCAwIFIgL0ZpdEIgXSANL1BhcmVudCAzNjAgMCBS
IA0vUHJldiA0MTIgMCBSIA0vTmV4dCA0MTAgMCBSIA0+PiANZW5kb2JqDTQxMiAwIG9iag08PCAN
L1RpdGxlIChJbnZhbGlkIEFCT1JUIG1lc3NhZ2UpDS9EZXN0IFsgMTg1IDAgUiAvRml0QiBdIA0v
UGFyZW50IDM2MCAwIFIgDS9QcmV2IDQxMyAwIFIgDS9OZXh0IDQxMSAwIFIgDT4+IA1lbmRvYmoN
NDEzIDAgb2JqDTw8IA0vVGl0bGUgKEludmFsaWQgQ09PS0lFIG1lc3NhZ2Ugd2l0aCBsaWZlIHRp
bWUgZXhwaXJlZCkNL0Rlc3QgWyAxODIgMCBSIC9GaXRCIF0gDS9QYXJlbnQgMzYwIDAgUiANL1By
ZXYgNDE0IDAgUiANL05leHQgNDEyIDAgUiANPj4gDWVuZG9iag00MTQgMCBvYmoNPDwgDS9UaXRs
ZSAoSW52YWxpZCBDT09LSUUgbWVzc2FnZSB3aXRoIHdyb25nIE1ENSBzaWduYXR1cmUpDS9EZXN0
IFsgMTc5IDAgUiAvRml0QiBdIA0vUGFyZW50IDM2MCAwIFIgDS9QcmV2IDQxNSAwIFIgDS9OZXh0
IDQxMyAwIFIgDT4+IA1lbmRvYmoNNDE1IDAgb2JqDTw8IA0vVGl0bGUgKEludmFsaWQgQWRsZXIt
MzIgQ2hlY2tzdW0gaW4gU0NUUCBkYXRhZ3JhbSkNL0Rlc3QgWyAxNzMgMCBSIC9GaXRCIF0gDS9Q
YXJlbnQgMzYwIDAgUiANL1ByZXYgNDE2IDAgUiANL05leHQgNDE0IDAgUiANPj4gDWVuZG9iag00
MTYgMCBvYmoNPDwgDS9UaXRsZSAoSW52YWxpZCBWZXJpZmljYXRpb24gVGFnIGZpZWxkIGluIGEg
bWVzc2FnZSkNL0Rlc3QgWyAxNjcgMCBSIC9GaXRCIF0gDS9QYXJlbnQgMzYwIDAgUiANL1ByZXYg
NDE3IDAgUiANL05leHQgNDE1IDAgUiANPj4gDWVuZG9iag00MTcgMCBvYmoNPDwgDS9UaXRsZSAo
SU5JVC1BQ0sgTWVzc2FnZSB3aXRoIG1hbmRhdG9yeSBwYXJhbWV0ZXIgbWlzc2luZykNL0Rlc3Qg
WyAxNjQgMCBSIC9GaXRCIF0gDS9QYXJlbnQgMzYwIDAgUiANL1ByZXYgNDE4IDAgUiANL05leHQg
NDE2IDAgUiANPj4gDWVuZG9iag00MTggMCBvYmoNPDwgDS9UaXRsZSAoSW52YWxpZCBJTklULUFD
SyBNZXNzYWdlIHdpdGggSW5pdC1UYWcgTlVMTCkNL0Rlc3QgWyAxNjEgMCBSIC9GaXRCIF0gDS9Q
YXJlbnQgMzYwIDAgUiANL1ByZXYgNDE5IDAgUiANL05leHQgNDE3IDAgUiANPj4gDWVuZG9iag00
MTkgMCBvYmoNPDwgDS9UaXRsZSAoSW52YWxpZCBJTklUIE1lc3NhZ2Ugd2l0aCBtZXNzYWdlIGxl
bmd0aCA8IGxlbmd0aCBvZiBhbGwgbWFuZGF0b3J5IHBhcmFtXA1ldGVycykNL0Rlc3QgWyAxNTgg
MCBSIC9GaXRCIF0gDS9QYXJlbnQgMzYwIDAgUiANL1ByZXYgNDIwIDAgUiANL05leHQgNDE4IDAg
UiANPj4gDWVuZG9iag00MjAgMCBvYmoNPDwgDS9UaXRsZSAoSW52YWxpZCBJTklUIE1lc3NhZ2Ug
d2l0aCBJbml0X3RhZyBOdWxsKQ0vRGVzdCBbIDE1NSAwIFIgL0ZpdEIgXSANL1BhcmVudCAzNjAg
MCBSIA0vUHJldiA0MjEgMCBSIA0vTmV4dCA0MTkgMCBSIA0+PiANZW5kb2JqDTQyMSAwIG9iag08
PCANL1RpdGxlIChEYXRhIENodW5rcyBhcmUgcmVjZWl2ZWQgaW4gU2h1dGRvd24gUmVjZWl2ZSBz
dGF0ZSkNL0Rlc3QgWyAxNTIgMCBSIC9GaXRCIF0gDS9QYXJlbnQgMzYwIDAgUiANL1ByZXYgNDIy
IDAgUiANL05leHQgNDIwIDAgUiANPj4gDWVuZG9iag00MjIgMCBvYmoNPDwgDS9UaXRsZSAoRGF0
YSBmcm9tIFBlZXIgaW4gU2h1dGRvd24gc2VudCBzdGF0ZSkNL0Rlc3QgWyAxNDkgMCBSIC9GaXRC
IF0gDS9QYXJlbnQgMzYwIDAgUiANL1ByZXYgNDIzIDAgUiANL05leHQgNDIxIDAgUiANPj4gDWVu
ZG9iag00MjMgMCBvYmoNPDwgDS9UaXRsZSAoRGF0YSBmcm9tIHVwcGVyIGxheWVyIGluIFNodXRk
b3duIHBlbmRpbmcgc3RhdGUpDS9EZXN0IFsgMTQ2IDAgUiAvRml0QiBdIA0vUGFyZW50IDM2MCAw
IFIgDS9QcmV2IDQyNCAwIFIgDS9OZXh0IDQyMiAwIFIgDT4+IA1lbmRvYmoNNDI0IDAgb2JqDTw8
IA0vVGl0bGUgKERhdGEgZnJvbSB1cHBlciBsYXllciBpbiBTaHV0ZG93biByZWNlaXZlIHN0YXRl
KQ0vRGVzdCBbIDE0MyAwIFIgL0ZpdEIgXSANL1BhcmVudCAzNjAgMCBSIA0vUHJldiA0MjUgMCBS
IA0vTmV4dCA0MjMgMCBSIA0+PiANZW5kb2JqDTQyNSAwIG9iag08PCANL1RpdGxlIChEYXRhIGZy
b20gdXBwZXIgbGF5ZXIgaW4gU2h1dGRvd24gc2VudCBzdGF0ZSkNL0Rlc3QgWyAxNDAgMCBSIC9G
aXRCIF0gDS9QYXJlbnQgMzYwIDAgUiANL1ByZXYgNDI2IDAgUiANL05leHQgNDI0IDAgUiANPj4g
DWVuZG9iag00MjYgMCBvYmoNPDwgDS9UaXRsZSAoQVNTT0NJQVRJT04uTUFYLlJFVFJBTlMgdHJp
ZXMgZXhjZWVkcykNL0Rlc3QgWyAxMzQgMCBSIC9GaXRCIF0gDS9QYXJlbnQgMzYwIDAgUiANL1By
ZXYgNDI3IDAgUiANL05leHQgNDI1IDAgUiANPj4gDWVuZG9iag00MjcgMCBvYmoNPDwgDS9UaXRs
ZSAoVDItU2h1dGRvd24gdGltZXIgZXhwaXJlcykNL0Rlc3QgWyAxMzEgMCBSIC9GaXRCIF0gDS9Q
YXJlbnQgMzYwIDAgUiANL1ByZXYgNDI4IDAgUiANL05leHQgNDI2IDAgUiANPj4gDWVuZG9iag00
MjggMCBvYmoNPDwgDS9UaXRsZSAoVGVybWluYXRpb24gb2YgYW4gYXNzb2NpYXRpb24gYnkgcmVj
ZWl2aW5nIFRlcm1pbmF0ZSBwcmltaXRpdmUgZnJvbSB1cHBlXA1yIGxheWVycykNL0Rlc3QgWyAx
MjggMCBSIC9GaXRCIF0gDS9QYXJlbnQgMzYwIDAgUiANL1ByZXYgNDI5IDAgUiANL05leHQgNDI3
IDAgUiANPj4gDWVuZG9iag00MjkgMCBvYmoNPDwgDS9UaXRsZSAoVGVybWluYXRpb24gb2YgYW4g
YXNzb2NpYXRpb24gYnkgcmVjZWl2aW5nIEFCT1JUIHdpdGggbm8gZXJyb3IgY2F1c2UpDS9EZXN0
IFsgMTI1IDAgUiAvRml0QiBdIA0vUGFyZW50IDM2MCAwIFIgDS9QcmV2IDQzMCAwIFIgDS9OZXh0
IDQyOCAwIFIgDT4+IA1lbmRvYmoNNDMwIDAgb2JqDTw8IA0vVGl0bGUgKEdlbmVyYXRpb24gb2Yg
QUJPUlQpDS9EZXN0IFsgMTIyIDAgUiAvRml0QiBdIA0vUGFyZW50IDM2MCAwIFIgDS9QcmV2IDQz
MSAwIFIgDS9OZXh0IDQyOSAwIFIgDT4+IA1lbmRvYmoNNDMxIDAgb2JqDTw8IA0vVGl0bGUgKElQ
IGFkZHJlc3MgZnJvbSB3aGVyZSB0aGUgSU5JVC1BQ0sgY29tZXMgaXMgbm90IGluY2x1ZGVkIGlu
IHRoZSBJUCBhZGRyZVwNc3MgZmllbGQgb2YgSU5JVC1BQ0spDS9EZXN0IFsgMTE5IDAgUiAvRml0
QiBdIA0vUGFyZW50IDM2MCAwIFIgDS9QcmV2IDQzMiAwIFIgDS9OZXh0IDQzMCAwIFIgDT4+IA1l
bmRvYmoNNDMyIDAgb2JqDTw8IA0vVGl0bGUgKFNVQlRJVExFOiBJUCBhZGRyZXNzIGZyb20gd2hl
cmUgdGhlIElOSVQgY29tZXMgaXMgbm90IGluY2x1ZGVkIGluIHRoZSBJUFwNIGFkZHJlc3MgZmll
bGQgb2YgSU5JVCkNL0Rlc3QgWyAxMTYgMCBSIC9GaXRCIF0gDS9QYXJlbnQgMzYwIDAgUiANL1By
ZXYgNDMzIDAgUiANL05leHQgNDMxIDAgUiANPj4gDWVuZG9iag00MzMgMCBvYmoNPDwgDS9UaXRs
ZSAoSVAgYWRkcmVzcyBmcm9tIHdoZXJlIHRoZSBJTklUIGNvbWVzIGlzIG5vdCBpbmNsdWRlZCBp
biB0aGUgSVAgYWRkcmVzcyBmXA1pZWxkIG9mIElOSVQpDS9EZXN0IFsgMTE2IDAgUiAvRml0QiBd
IA0vUGFyZW50IDM2MCAwIFIgDS9QcmV2IDQzNCAwIFIgDS9OZXh0IDQzMiAwIFIgDT4+IA1lbmRv
YmoNNDM0IDAgb2JqDTw8IA0vVGl0bGUgKE9uZSBvciBtb3JlIFRyYW5zcG9ydCBhZGRyZXNzZXMg
aW4gSU5JVCBtZXNzYWdlKQ0vRGVzdCBbIDExMCAwIFIgL0ZpdEIgXSANL1BhcmVudCAzNjAgMCBS
IA0vUHJldiA0MzUgMCBSIA0vTmV4dCA0MzMgMCBSIA0+PiANZW5kb2JqDTQzNSAwIG9iag08PCAN
L1RpdGxlIChWZW5kb3Igc3BlY2lmaWMgZXh0ZW5zaW9uIHBhcmFtZXRlciB0eXBlIGluIElOSVQt
QUNLKQ0vRGVzdCBbIDEwNyAwIFIgL0ZpdEIgXSANL1BhcmVudCAzNjAgMCBSIA0vUHJldiA0MzYg
MCBSIA0vTmV4dCA0MzQgMCBSIA0+PiANZW5kb2JqDTQzNiAwIG9iag08PCANL1RpdGxlIChWZW5k
b3Igc3BlY2lmaWMgZXh0ZW5zaW9uIHBhcmFtZXRlciB0eXBlIGluIElOSVQpDS9EZXN0IFsgMTA0
IDAgUiAvRml0QiBdIA0vUGFyZW50IDM2MCAwIFIgDS9QcmV2IDQzNyAwIFIgDS9OZXh0IDQzNSAw
IFIgDT4+IA1lbmRvYmoNNDM3IDAgb2JqDTw8IA0vVGl0bGUgKE5vIFRyYW5zcG9ydCBhZGRyZXNz
ZXMgaW4gSU5JVC1BQ0sgbWVzc2FnZXMpDS9EZXN0IFsgMTAxIDAgUiAvRml0QiBdIA0vUGFyZW50
IDM2MCAwIFIgDS9QcmV2IDQzOCAwIFIgDS9OZXh0IDQzNiAwIFIgDT4+IA1lbmRvYmoNNDM4IDAg
b2JqDTw8IA0vVGl0bGUgKElQIGFkZHJlc3MgaW4gbXVsdGlwbGUgYXNzb2NpYXRpb24pDS9EZXN0
IFsgOTUgMCBSIC9GaXRCIF0gDS9QYXJlbnQgMzYwIDAgUiANL1ByZXYgNDM5IDAgUiANL05leHQg
NDM3IDAgUiANPj4gDWVuZG9iag00MzkgMCBvYmoNPDwgDS9UaXRsZSAoVW5yZWNvZ25pemVkIFBh
cmFtZXRlcnMgcGFyYW1ldGVyIGluIElOSVQtQUNLKQ0vRGVzdCBbIDkyIDAgUiAvRml0QiBdIA0v
UGFyZW50IDM2MCAwIFIgDS9QcmV2IDQ0MCAwIFIgDS9OZXh0IDQzOCAwIFIgDT4+IA1lbmRvYmoN
NDQwIDAgb2JqDTw8IA0vVGl0bGUgKE1pc21hdGNoIGluIHRoZSBPdXRib3VuZCBTdHJlYW0gYW5k
IEluYm91bmQgU3RyZWFtIHBhcmFtZXRlcnMgaW4gSU5JVCBhblwNZCBJTklULUFDSykNL0Rlc3Qg
WyA4OSAwIFIgL0ZpdEIgXSANL1BhcmVudCAzNjAgMCBSIA0vUHJldiA0NDEgMCBSIA0vTmV4dCA0
MzkgMCBSIA0+PiANZW5kb2JqDTQ0MSAwIG9iag08PCANL1RpdGxlIChNaXNtYXRjaCBpbiB0aGUg
T3V0Ym91bmQgU3RyZWFtIGFuZCBJbmJvdW5kIFN0cmVhbSBwYXJhbWV0ZXJzIGluIElOSVQgYW5c
DWQgSU5JVC1BQ0spDS9EZXN0IFsgODYgMCBSIC9GaXRCIF0gDS9QYXJlbnQgMzYwIDAgUiANL1By
ZXYgNDQyIDAgUiANL05leHQgNDQwIDAgUiANPj4gDWVuZG9iag00NDIgMCBvYmoNPDwgDS9UaXRs
ZSAoT3B0aW9uYWwgcGFyYW1ldGVycyBpbiB0aGUgSU5JVC1BQ0sgbWVzc2FnZSkNL0Rlc3QgWyA4
MyAwIFIgL0ZpdEIgXSANL1BhcmVudCAzNjAgMCBSIA0vUHJldiA0NDMgMCBSIA0vTmV4dCA0NDEg
MCBSIA0+PiANZW5kb2JqDTQ0MyAwIG9iag08PCANL1RpdGxlIChPcHRpb25hbCBwYXJhbWV0ZXJz
IGluIHRoZSBJTklUIG1lc3NhZ2UpDS9EZXN0IFsgODAgMCBSIC9GaXRCIF0gDS9QYXJlbnQgMzYw
IDAgUiANL1ByZXYgNDQ0IDAgUiANL05leHQgNDQyIDAgUiANPj4gDWVuZG9iag00NDQgMCBvYmoN
PDwgDS9UaXRsZSAoRGlmZmVyZW50IFRhZyBWYWx1ZXMgaW4gZGlmZmVyZW50IGFzc29jaWF0aW9u
IGJlaW5nIGluaXRpYXRlZCBmcm9tIG90aGVyXA0gZW5kcG9pbnQpDS9EZXN0IFsgNzcgMCBSIC9G
aXRCIF0gDS9QYXJlbnQgMzYwIDAgUiANL1ByZXYgNDQ1IDAgUiANL05leHQgNDQzIDAgUiANPj4g
DWVuZG9iag00NDUgMCBvYmoNPDwgDS9UaXRsZSAoRGlmZmVyZW50IFRhZyBWYWx1ZXMgaW4gZGlm
ZmVyZW50IGFzc29jaWF0aW9uIGJlaW5nIGluaXRpYXRlZCBmcm9tIGVuZHBvXA1pbnQgYmVpbmcg
dGVzdGVkKQ0vRGVzdCBbIDc0IDAgUiAvRml0QiBdIA0vUGFyZW50IDM2MCAwIFIgDS9QcmV2IDQ0
NiAwIFIgDS9OZXh0IDQ0NCAwIFIgDT4+IA1lbmRvYmoNNDQ2IDAgb2JqDTw8IA0vVGl0bGUgKE1B
WC5JTklULlJFVFJBTlM6IEZhaWx1cmUgdG8gcmVjZWl2ZSBDT09LSUUtQUNLKQ0vRGVzdCBbIDY4
IDAgUiAvRml0QiBdIA0vUGFyZW50IDM2MCAwIFIgDS9QcmV2IDQ0NyAwIFIgDS9OZXh0IDQ0NSAw
IFIgDT4+IA1lbmRvYmoNNDQ3IDAgb2JqDTw8IA0vVGl0bGUgKE1BWC5JTklULlJFVFJBTlM6IEZh
aWx1cmUgdG8gcmVjZWl2ZSBJTklULUFDSykNL0Rlc3QgWyA2NSAwIFIgL0ZpdEIgXSANL1BhcmVu
dCAzNjAgMCBSIA0vUHJldiA0NDggMCBSIA0vTmV4dCA0NDYgMCBSIA0+PiANZW5kb2JqDTQ0OCAw
IG9iag08PCANL1RpdGxlIChUMS1Jbml0IHRpbWVyIGZvciBDT09LSUUpDS9EZXN0IFsgNjIgMCBS
IC9GaXRCIF0gDS9QYXJlbnQgMzYwIDAgUiANL1ByZXYgNDQ5IDAgUiANL05leHQgNDQ3IDAgUiAN
Pj4gDWVuZG9iag00NDkgMCBvYmoNPDwgDS9UaXRsZSAoVDEtSW5pdCB0aW1lciBmb3IgSU5JVCkN
L0Rlc3QgWyA1OSAwIFIgL0ZpdEIgXSANL1BhcmVudCAzNjAgMCBSIA0vUHJldiAzNzYgMCBSIA0v
TmV4dCA0NDggMCBSIA0+PiANZW5kb2JqDTQ1MCAwIG9iag08PCANL1RpdGxlIChMaW5rIE1vbml0
b3IpDS9EZXN0IFsgNDQgMCBSIC9GaXRCIF0gDS9QYXJlbnQgMzU1IDAgUiANL1ByZXYgNDU3IDAg
UiANL05leHQgMzU4IDAgUiANPj4gDWVuZG9iag00NTEgMCBvYmoNPDwgDS9UaXRsZSAoKQ0vRGVz
dCBbIDQ3IDAgUiAvRml0QiBdIA0vUGFyZW50IDM1OCAwIFIgDS9GaXJzdCA0NTIgMCBSIA0vTGFz
dCA0NTIgMCBSIA0vQ291bnQgNSANPj4gDWVuZG9iag00NTIgMCBvYmoNPDwgDS9UaXRsZSAoKQ0v
RGVzdCBbIDQ3IDAgUiAvRml0QiBdIA0vUGFyZW50IDQ1MSAwIFIgDS9GaXJzdCA0NTMgMCBSIA0v
TGFzdCA0NTQgMCBSIA0vQ291bnQgNCANPj4gDWVuZG9iag00NTMgMCBvYmoNPDwgDS9UaXRsZSAo
MS4xMi4zIElQIGFkZHJlc3MgZnJvbSB3aGVyZSB0aGUgSU5JVCBjb21lcyBpcyBub3QgaW5jbHVk
ZWQgaW4gdGhlIElQIGFkXA1kcmVzcykNL0Rlc3QgWyA0NyAwIFIgL0ZpdEIgXSANL1BhcmVudCA0
NTIgMCBSIA0vTmV4dCA0NTYgMCBSIA0+PiANZW5kb2JqDTQ1NCAwIG9iag08PCANL1RpdGxlIChh
ZGRyZXNzIGZpZWxkIG9mIElOSVQtQUNLKQ0vRGVzdCBbIDQ3IDAgUiAvRml0QiBdIA0vUGFyZW50
IDQ1MiAwIFIgDS9QcmV2IDQ1NSAwIFIgDT4+IA1lbmRvYmoNNDU1IDAgb2JqDTw8IA0vVGl0bGUg
KDEuMTIuNCBJUCBhZGRyZXNzIGZyb20gd2hlcmUgdGhlIElOSVQtQUNLIGNvbWVzIGlzIG5vdCBp
bmNsdWRlZCBpbiB0aGUgSVwNUCkNL0Rlc3QgWyA0NyAwIFIgL0ZpdEIgXSANL1BhcmVudCA0NTIg
MCBSIA0vUHJldiA0NTYgMCBSIA0vTmV4dCA0NTQgMCBSIA0+PiANZW5kb2JqDTQ1NiAwIG9iag08
PCANL1RpdGxlIChmaWVsZCBvZiBJTklUKQ0vRGVzdCBbIDQ3IDAgUiAvRml0QiBdIA0vUGFyZW50
IDQ1MiAwIFIgDS9QcmV2IDQ1MyAwIFIgDS9OZXh0IDQ1NSAwIFIgDT4+IA1lbmRvYmoNNDU3IDAg
b2JqDTw8IA0vVGl0bGUgKFRlc3QgRW52aXJvbm1lbnQpDS9EZXN0IFsgNDEgMCBSIC9GaXRCIF0g
DS9QYXJlbnQgMzU1IDAgUiANL1ByZXYgNDU4IDAgUiANL05leHQgNDUwIDAgUiANL0ZpcnN0IDQ1
OSAwIFIgDS9MYXN0IDQ2MCAwIFIgDS9Db3VudCA0IA0+PiANZW5kb2JqDTQ1OCAwIG9iag08PCAN
L1RpdGxlIChGaWcgMTogVEVTVCBDT05GSUdVUkFUSU9OIE9GIFNDVFApDS9EZXN0IFsgNDEgMCBS
IC9GaXRCIF0gDS9QYXJlbnQgMzU1IDAgUiANL1ByZXYgNDYzIDAgUiANL05leHQgNDU3IDAgUiAN
Pj4gDWVuZG9iag00NTkgMCBvYmoNPDwgDS9UaXRsZSAoRmlnIDIpDS9EZXN0IFsgNDEgMCBSIC9G
aXRCIF0gDS9QYXJlbnQgNDU3IDAgUiANL05leHQgNDYyIDAgUiANPj4gDWVuZG9iag00NjAgMCBv
YmoNPDwgDS9UaXRsZSAoNC4zICAgICAgIFRlc3Qgc2ltdWxhdG9yKQ0vRGVzdCBbIDQ0IDAgUiAv
Rml0QiBdIA0vUGFyZW50IDQ1NyAwIFIgDS9QcmV2IDQ2MSAwIFIgDT4+IA1lbmRvYmoNNDYxIDAg
b2JqDTw8IA0vVGl0bGUgKDQuMiAgICAgICBTQ1RQIHVzZXIgc2ltdWxhdG9yKQ0vRGVzdCBbIDQx
IDAgUiAvRml0QiBdIA0vUGFyZW50IDQ1NyAwIFIgDS9QcmV2IDQ2MiAwIFIgDS9OZXh0IDQ2MCAw
IFIgDT4+IA1lbmRvYmoNNDYyIDAgb2JqDTw8IA0vVGl0bGUgKDQuMVx0U0NUUCB2YWxpZGF0aW9u
IHRlc3RpbmcpDS9EZXN0IFsgNDEgMCBSIC9GaXRCIF0gDS9QYXJlbnQgNDU3IDAgUiANL1ByZXYg
NDU5IDAgUiANL05leHQgNDYxIDAgUiANPj4gDWVuZG9iag00NjMgMCBvYmoNPDwgDS9UaXRsZSAo
M1x0VGVzdCBjb25maWd1cmF0aW9uKQ0vRGVzdCBbIDM4IDAgUiAvRml0QiBdIA0vUGFyZW50IDM1
NSAwIFIgDS9QcmV2IDQ2NCAwIFIgDS9OZXh0IDQ1OCAwIFIgDT4+IA1lbmRvYmoNNDY0IDAgb2Jq
DTw8IA0vVGl0bGUgKEdlbmVyYWwgcHJpbmNpcGxlcyBvZiBTQ1RQIHRlc3RzKQ0vRGVzdCBbIDM4
IDAgUiAvRml0QiBdIA0vUGFyZW50IDM1NSAwIFIgDS9QcmV2IDQ2NSAwIFIgDS9OZXh0IDQ2MyAw
IFIgDS9GaXJzdCA0NjYgMCBSIA0vTGFzdCA0NjcgMCBSIA0vQ291bnQgMiANPj4gDWVuZG9iag00
NjUgMCBvYmoNPDwgDS9UaXRsZSAoMVx0SW50cm9kdWN0aW9uKQ0vRGVzdCBbIDM4IDAgUiAvRml0
QiBdIA0vUGFyZW50IDM1NSAwIFIgDS9QcmV2IDM1NiAwIFIgDS9OZXh0IDQ2NCAwIFIgDT4+IA1l
bmRvYmoNNDY2IDAgb2JqDTw8IA0vVGl0bGUgKDIuMVx0UHJlc2VudGF0aW9uIG9mIHRlc3QgZGVz
Y3JpcHRpb25zKQ0vRGVzdCBbIDM4IDAgUiAvRml0QiBdIA0vUGFyZW50IDQ2NCAwIFIgDS9OZXh0
IDQ2NyAwIFIgDT4+IA1lbmRvYmoNNDY3IDAgb2JqDTw8IA0vVGl0bGUgKDIuMlx0UHJlc2VudGF0
aW9uIG9mIHRoZSB0ZXN0IGxpc3QpDS9EZXN0IFsgMzggMCBSIC9GaXRCIF0gDS9QYXJlbnQgNDY0
IDAgUiANL1ByZXYgNDY2IDAgUiANPj4gDWVuZG9iag00NjggMCBvYmoNPDwgDS9Qcm9kdWNlciAo
QWNyb2JhdCBEaXN0aWxsZXIgNC4wIGZvciBXaW5kb3dzKQ0vQ3JlYXRvciAoTWljcm9zb2Z0IFdv
cmQgOC4wKQ0vTW9kRGF0ZSAoRDoyMDAwMDQyNTE2MzEzNiswNSczMCcpDS9BdXRob3IgKHNqaW5k
YWwpDS9UaXRsZSAoVEVTVCBOVU1CRVIgOiAxKQ0vQ3JlYXRpb25EYXRlIChEOjIwMDAwNDI1MTYy
OTE5KQ0+PiANZW5kb2JqDTQ2OSAwIG9iag08PCANL1R5cGUgL1BhZ2VzIA0vS2lkcyBbIDQ4NCAw
IFIgMSAwIFIgNCAwIFIgMzAgMCBSIDM4IDAgUiA0MSAwIFIgNDQgMCBSIDQ3IDAgUiA1MCAwIFIg
NTMgMCBSIA1dIA0vQ291bnQgMTAgDS9QYXJlbnQgNDcwIDAgUiANPj4gDWVuZG9iag00NzAgMCBv
YmoNPDwgDS9UeXBlIC9QYWdlcyANL0tpZHMgWyA0NjkgMCBSIDQ3MSAwIFIgNDcyIDAgUiA0NzMg
MCBSIDQ3NCAwIFIgNDc1IDAgUiA0NzYgMCBSIDQ3NyAwIFIgNDc4IDAgUiANNDc5IDAgUiBdIA0v
Q291bnQgMTAwIA0vUGFyZW50IDQ4MCAwIFIgDT4+IA1lbmRvYmoNNDcxIDAgb2JqDTw8IA0vVHlw
ZSAvUGFnZXMgDS9LaWRzIFsgNTYgMCBSIDU5IDAgUiA2MiAwIFIgNjUgMCBSIDY4IDAgUiA3MSAw
IFIgNzQgMCBSIDc3IDAgUiA4MCAwIFIgODMgMCBSIA1dIA0vQ291bnQgMTAgDS9QYXJlbnQgNDcw
IDAgUiANPj4gDWVuZG9iag00NzIgMCBvYmoNPDwgDS9UeXBlIC9QYWdlcyANL0tpZHMgWyA4NiAw
IFIgODkgMCBSIDkyIDAgUiA5NSAwIFIgOTggMCBSIDEwMSAwIFIgMTA0IDAgUiAxMDcgMCBSIDEx
MCAwIFIgDTExMyAwIFIgXSANL0NvdW50IDEwIA0vUGFyZW50IDQ3MCAwIFIgDT4+IA1lbmRvYmoN
NDczIDAgb2JqDTw8IA0vVHlwZSAvUGFnZXMgDS9LaWRzIFsgMTE2IDAgUiAxMTkgMCBSIDEyMiAw
IFIgMTI1IDAgUiAxMjggMCBSIDEzMSAwIFIgMTM0IDAgUiAxMzcgMCBSIDE0MCAwIFIgDTE0MyAw
IFIgXSANL0NvdW50IDEwIA0vUGFyZW50IDQ3MCAwIFIgDT4+IA1lbmRvYmoNNDc0IDAgb2JqDTw8
IA0vVHlwZSAvUGFnZXMgDS9LaWRzIFsgMTQ2IDAgUiAxNDkgMCBSIDE1MiAwIFIgMTU1IDAgUiAx
NTggMCBSIDE2MSAwIFIgMTY0IDAgUiAxNjcgMCBSIDE3MCAwIFIgDTE3MyAwIFIgXSANL0NvdW50
IDEwIA0vUGFyZW50IDQ3MCAwIFIgDT4+IA1lbmRvYmoNNDc1IDAgb2JqDTw8IA0vVHlwZSAvUGFn
ZXMgDS9LaWRzIFsgMTc2IDAgUiAxNzkgMCBSIDE4MiAwIFIgMTg1IDAgUiAxODggMCBSIDE5MSAw
IFIgMTk0IDAgUiAxOTcgMCBSIDIwMCAwIFIgDTIwMyAwIFIgXSANL0NvdW50IDEwIA0vUGFyZW50
IDQ3MCAwIFIgDT4+IA1lbmRvYmoNNDc2IDAgb2JqDTw8IA0vVHlwZSAvUGFnZXMgDS9LaWRzIFsg
MjA2IDAgUiAyMDkgMCBSIDIxMiAwIFIgMjE1IDAgUiAyMTggMCBSIDIyMSAwIFIgMjI0IDAgUiAy
MjcgMCBSIDIzMCAwIFIgDTIzMyAwIFIgXSANL0NvdW50IDEwIA0vUGFyZW50IDQ3MCAwIFIgDT4+
IA1lbmRvYmoNNDc3IDAgb2JqDTw8IA0vVHlwZSAvUGFnZXMgDS9LaWRzIFsgMjM2IDAgUiAyMzkg
MCBSIDI0MiAwIFIgMjQ1IDAgUiAyNDggMCBSIDI1MSAwIFIgMjU0IDAgUiAyNTcgMCBSIDI2MCAw
IFIgDTI2MyAwIFIgXSANL0NvdW50IDEwIA0vUGFyZW50IDQ3MCAwIFIgDT4+IA1lbmRvYmoNNDc4
IDAgb2JqDTw8IA0vVHlwZSAvUGFnZXMgDS9LaWRzIFsgMjY2IDAgUiAyNjkgMCBSIDI3MiAwIFIg
Mjc1IDAgUiAyNzggMCBSIDI4MSAwIFIgMjg0IDAgUiAyODcgMCBSIDI5MCAwIFIgDTI5MyAwIFIg
XSANL0NvdW50IDEwIA0vUGFyZW50IDQ3MCAwIFIgDT4+IA1lbmRvYmoNNDc5IDAgb2JqDTw8IA0v
VHlwZSAvUGFnZXMgDS9LaWRzIFsgMjk2IDAgUiAyOTkgMCBSIDMwMiAwIFIgMzA1IDAgUiAzMDgg
MCBSIDMxMSAwIFIgMzE0IDAgUiAzMTcgMCBSIDMyMCAwIFIgDTMyMyAwIFIgXSANL0NvdW50IDEw
IA0vUGFyZW50IDQ3MCAwIFIgDT4+IA1lbmRvYmoNNDgwIDAgb2JqDTw8IA0vVHlwZSAvUGFnZXMg
DS9LaWRzIFsgNDcwIDAgUiA0ODEgMCBSIF0gDS9Db3VudCAxMDYgDT4+IA1lbmRvYmoNNDgxIDAg
b2JqDTw8IA0vVHlwZSAvUGFnZXMgDS9LaWRzIFsgMzI2IDAgUiAzMjkgMCBSIDMzMiAwIFIgMzM1
IDAgUiAzMzggMCBSIDM0MSAwIFIgXSANL0NvdW50IDYgDS9QYXJlbnQgNDgwIDAgUiANPj4gDWVu
ZG9iag14cmVmDTAgNDgyIA0wMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDk1NDIgMDAwMDAgbg0K
MDAwMDAwOTY5NCAwMDAwMCBuDQowMDAwMDA5ODU2IDAwMDAwIG4NCjAwMDAwMTE1NDQgMDAwMDAg
bg0KMDAwMDAxMTg2OSAwMDAwMCBuDQowMDAwMDEyMDEzIDAwMDAwIG4NCjAwMDAwMTIxNTcgMDAw
MDAgbg0KMDAwMDAxMjMwMSAwMDAwMCBuDQowMDAwMDEyNDQ1IDAwMDAwIG4NCjAwMDAwMTI1ODkg
MDAwMDAgbg0KMDAwMDAxMjczNCAwMDAwMCBuDQowMDAwMDEyODc5IDAwMDAwIG4NCjAwMDAwMTMw
MjQgMDAwMDAgbg0KMDAwMDAxMzE2OSAwMDAwMCBuDQowMDAwMDEzMzE0IDAwMDAwIG4NCjAwMDAw
MTM0NTkgMDAwMDAgbg0KMDAwMDAxMzYwNCAwMDAwMCBuDQowMDAwMDEzNzQ5IDAwMDAwIG4NCjAw
MDAwMTM4OTQgMDAwMDAgbg0KMDAwMDAxNDA0MCAwMDAwMCBuDQowMDAwMDE0MTg2IDAwMDAwIG4N
CjAwMDAwMTQzMzIgMDAwMDAgbg0KMDAwMDAxNDQ3OCAwMDAwMCBuDQowMDAwMDE0NjI0IDAwMDAw
IG4NCjAwMDAwMTQ3NzAgMDAwMDAgbg0KMDAwMDAxNDkxNiAwMDAwMCBuDQowMDAwMDE1MDYyIDAw
MDAwIG4NCjAwMDAwMTUyMDcgMDAwMDAgbg0KMDAwMDAxNTM4NSAwMDAwMCBuDQowMDAwMDE3MDQ3
IDAwMDAwIG4NCjAwMDAwMTcyNTAgMDAwMDAgbg0KMDAwMDAxNzM5NiAwMDAwMCBuDQowMDAwMDE3
NTQyIDAwMDAwIG4NCjAwMDAwMTc2ODggMDAwMDAgbg0KMDAwMDAxNzgzNCAwMDAwMCBuDQowMDAw
MDE3OTgwIDAwMDAwIG4NCjAwMDAwMTgxMTggMDAwMDAgbg0KMDAwMDAxODY0NiAwMDAwMCBuDQow
MDAwMDE4ODAxIDAwMDAwIG4NCjAwMDAwMTg5OTQgMDAwMDAgbg0KMDAwMDAyMjg2NCAwMDAwMCBu
DQowMDAwMDIzMDE5IDAwMDAwIG4NCjAwMDAwMjMyMTIgMDAwMDAgbg0KMDAwMDAyNTI0NyAwMDAw
MCBuDQowMDAwMDI1NDAyIDAwMDAwIG4NCjAwMDAwMjU2MDkgMDAwMDAgbg0KMDAwMDAyODk2NCAw
MDAwMCBuDQowMDAwMDI5MTE5IDAwMDAwIG4NCjAwMDAwMjkzMTEgMDAwMDAgbg0KMDAwMDAzMjY1
MiAwMDAwMCBuDQowMDAwMDMyODA3IDAwMDAwIG4NCjAwMDAwMzI5ODYgMDAwMDAgbg0KMDAwMDAz
NTc4OSAwMDAwMCBuDQowMDAwMDM1OTQ0IDAwMDAwIG4NCjAwMDAwMzYxMjMgMDAwMDAgbg0KMDAw
MDAzNzM5MSAwMDAwMCBuDQowMDAwMDM3NTQ2IDAwMDAwIG4NCjAwMDAwMzc3MzggMDAwMDAgbg0K
MDAwMDA0MDg0NyAwMDAwMCBuDQowMDAwMDQxMDAyIDAwMDAwIG4NCjAwMDAwNDExOTQgMDAwMDAg
bg0KMDAwMDA0NDE1NCAwMDAwMCBuDQowMDAwMDQ0MzA5IDAwMDAwIG4NCjAwMDAwNDQ1MDEgMDAw
MDAgbg0KMDAwMDA0NzI2MyAwMDAwMCBuDQowMDAwMDQ3NDE4IDAwMDAwIG4NCjAwMDAwNDc2MTAg
MDAwMDAgbg0KMDAwMDA1MTYwMSAwMDAwMCBuDQowMDAwMDUxNzU2IDAwMDAwIG4NCjAwMDAwNTE5
NDggMDAwMDAgbg0KMDAwMDA1NTkyNiAwMDAwMCBuDQowMDAwMDU2MDgxIDAwMDAwIG4NCjAwMDAw
NTYyNzMgMDAwMDAgbg0KMDAwMDA1OTQ0NCAwMDAwMCBuDQowMDAwMDU5NTk5IDAwMDAwIG4NCjAw
MDAwNTk3OTEgMDAwMDAgbg0KMDAwMDA2MzM5NCAwMDAwMCBuDQowMDAwMDYzNTQ5IDAwMDAwIG4N
CjAwMDAwNjM3NDEgMDAwMDAgbg0KMDAwMDA2NzE3MSAwMDAwMCBuDQowMDAwMDY3MzI2IDAwMDAw
IG4NCjAwMDAwNjc1MTggMDAwMDAgbg0KMDAwMDA3MDQwMyAwMDAwMCBuDQowMDAwMDcwNTU4IDAw
MDAwIG4NCjAwMDAwNzA3NTAgMDAwMDAgbg0KMDAwMDA3Mzc4OCAwMDAwMCBuDQowMDAwMDczOTQz
IDAwMDAwIG4NCjAwMDAwNzQxMzUgMDAwMDAgbg0KMDAwMDA3NzgzNCAwMDAwMCBuDQowMDAwMDc3
OTg5IDAwMDAwIG4NCjAwMDAwNzgxODEgMDAwMDAgbg0KMDAwMDA4MTk2NCAwMDAwMCBuDQowMDAw
MDgyMTE5IDAwMDAwIG4NCjAwMDAwODIzMTEgMDAwMDAgbg0KMDAwMDA4NTUzMiAwMDAwMCBuDQow
MDAwMDg1Njg3IDAwMDAwIG4NCjAwMDAwODU4NzkgMDAwMDAgbg0KMDAwMDA4ODkxMyAwMDAwMCBu
DQowMDAwMDg5MDY5IDAwMDAwIG4NCjAwMDAwODkyNjEgMDAwMDAgbg0KMDAwMDA5MjExNCAwMDAw
MCBuDQowMDAwMDkyMjcyIDAwMDAwIG4NCjAwMDAwOTI0NjUgMDAwMDAgbg0KMDAwMDA5NTQ4MCAw
MDAwMCBuDQowMDAwMDk1NjM4IDAwMDAwIG4NCjAwMDAwOTU4MzEgMDAwMDAgbg0KMDAwMDA5ODgx
NSAwMDAwMCBuDQowMDAwMDk4OTczIDAwMDAwIG4NCjAwMDAwOTkxNjYgMDAwMDAgbg0KMDAwMDEw
MjMxNyAwMDAwMCBuDQowMDAwMTAyNDc1IDAwMDAwIG4NCjAwMDAxMDI2NjggMDAwMDAgbg0KMDAw
MDEwNjIxMyAwMDAwMCBuDQowMDAwMTA2MzcxIDAwMDAwIG4NCjAwMDAxMDY1NjQgMDAwMDAgbg0K
MDAwMDExMDIwNSAwMDAwMCBuDQowMDAwMTEwMzYzIDAwMDAwIG4NCjAwMDAxMTA1NTYgMDAwMDAg
bg0KMDAwMDExNDc0MiAwMDAwMCBuDQowMDAwMTE0OTAwIDAwMDAwIG4NCjAwMDAxMTUwOTMgMDAw
MDAgbg0KMDAwMDExOTQ0MyAwMDAwMCBuDQowMDAwMTE5NjAxIDAwMDAwIG4NCjAwMDAxMTk3OTQg
MDAwMDAgbg0KMDAwMDEyMjU1OSAwMDAwMCBuDQowMDAwMTIyNzE3IDAwMDAwIG4NCjAwMDAxMjI5
MTAgMDAwMDAgbg0KMDAwMDEyNTg1NSAwMDAwMCBuDQowMDAwMTI2MDEzIDAwMDAwIG4NCjAwMDAx
MjYyMDYgMDAwMDAgbg0KMDAwMDEyOTczMCAwMDAwMCBuDQowMDAwMTI5ODg4IDAwMDAwIG4NCjAw
MDAxMzAwODEgMDAwMDAgbg0KMDAwMDEzMjcxOCAwMDAwMCBuDQowMDAwMTMyODc2IDAwMDAwIG4N
CjAwMDAxMzMwNjkgMDAwMDAgbg0KMDAwMDEzNjUyMiAwMDAwMCBuDQowMDAwMTM2NjgwIDAwMDAw
IG4NCjAwMDAxMzY4NzMgMDAwMDAgbg0KMDAwMDEzOTc2MCAwMDAwMCBuDQowMDAwMTM5OTE4IDAw
MDAwIG4NCjAwMDAxNDAxMTEgMDAwMDAgbg0KMDAwMDE0MjkyNyAwMDAwMCBuDQowMDAwMTQzMDg1
IDAwMDAwIG4NCjAwMDAxNDMyNzggMDAwMDAgbg0KMDAwMDE0NjQ1MCAwMDAwMCBuDQowMDAwMTQ2
NjA4IDAwMDAwIG4NCjAwMDAxNDY4MDEgMDAwMDAgbg0KMDAwMDE0OTkzNyAwMDAwMCBuDQowMDAw
MTUwMDk1IDAwMDAwIG4NCjAwMDAxNTAyODggMDAwMDAgbg0KMDAwMDE1MzI4OSAwMDAwMCBuDQow
MDAwMTUzNDQ3IDAwMDAwIG4NCjAwMDAxNTM2NDAgMDAwMDAgbg0KMDAwMDE1NjY5OCAwMDAwMCBu
DQowMDAwMTU2ODU2IDAwMDAwIG4NCjAwMDAxNTcwNDkgMDAwMDAgbg0KMDAwMDE1OTQ4NSAwMDAw
MCBuDQowMDAwMTU5NjQzIDAwMDAwIG4NCjAwMDAxNTk4MzYgMDAwMDAgbg0KMDAwMDE2MzY0NyAw
MDAwMCBuDQowMDAwMTYzODA1IDAwMDAwIG4NCjAwMDAxNjM5OTggMDAwMDAgbg0KMDAwMDE2Njg4
MSAwMDAwMCBuDQowMDAwMTY3MDM5IDAwMDAwIG4NCjAwMDAxNjcyMzIgMDAwMDAgbg0KMDAwMDE3
MTAyNyAwMDAwMCBuDQowMDAwMTcxMTg1IDAwMDAwIG4NCjAwMDAxNzEzNjUgMDAwMDAgbg0KMDAw
MDE3NDczOSAwMDAwMCBuDQowMDAwMTc0ODk3IDAwMDAwIG4NCjAwMDAxNzUwNzcgMDAwMDAgbg0K
MDAwMDE3NzU4NiAwMDAwMCBuDQowMDAwMTc3NzQ0IDAwMDAwIG4NCjAwMDAxNzc5MjQgMDAwMDAg
bg0KMDAwMDE4MTQwMCAwMDAwMCBuDQowMDAwMTgxNTU4IDAwMDAwIG4NCjAwMDAxODE3MzggMDAw
MDAgbg0KMDAwMDE4NDg2OCAwMDAwMCBuDQowMDAwMTg1MDI2IDAwMDAwIG4NCjAwMDAxODUyMTkg
MDAwMDAgbg0KMDAwMDE4ODA0OSAwMDAwMCBuDQowMDAwMTg4MjA3IDAwMDAwIG4NCjAwMDAxODg0
MDAgMDAwMDAgbg0KMDAwMDE5MTU5NiAwMDAwMCBuDQowMDAwMTkxNzU0IDAwMDAwIG4NCjAwMDAx
OTE5NDcgMDAwMDAgbg0KMDAwMDE5NDU0NSAwMDAwMCBuDQowMDAwMTk0NzAzIDAwMDAwIG4NCjAw
MDAxOTQ4OTYgMDAwMDAgbg0KMDAwMDE5NzQyMCAwMDAwMCBuDQowMDAwMTk3NTc4IDAwMDAwIG4N
CjAwMDAxOTc3NzEgMDAwMDAgbg0KMDAwMDIwMDU2NyAwMDAwMCBuDQowMDAwMjAwNzI1IDAwMDAw
IG4NCjAwMDAyMDA5MTggMDAwMDAgbg0KMDAwMDIwNDYzMCAwMDAwMCBuDQowMDAwMjA0Nzg4IDAw
MDAwIG4NCjAwMDAyMDQ5ODEgMDAwMDAgbg0KMDAwMDIwODA1OCAwMDAwMCBuDQowMDAwMjA4MjE2
IDAwMDAwIG4NCjAwMDAyMDg0MDkgMDAwMDAgbg0KMDAwMDIxMTQyOCAwMDAwMCBuDQowMDAwMjEx
NTg2IDAwMDAwIG4NCjAwMDAyMTE3NzkgMDAwMDAgbg0KMDAwMDIxNDg5NiAwMDAwMCBuDQowMDAw
MjE1MDU0IDAwMDAwIG4NCjAwMDAyMTUyNDcgMDAwMDAgbg0KMDAwMDIxODY1NCAwMDAwMCBuDQow
MDAwMjE4ODEyIDAwMDAwIG4NCjAwMDAyMTkwMDUgMDAwMDAgbg0KMDAwMDIyMTYzNiAwMDAwMCBu
DQowMDAwMjIxNzk0IDAwMDAwIG4NCjAwMDAyMjE5ODcgMDAwMDAgbg0KMDAwMDIyNTExOCAwMDAw
MCBuDQowMDAwMjI1Mjc2IDAwMDAwIG4NCjAwMDAyMjU0NjkgMDAwMDAgbg0KMDAwMDIyNzg2NyAw
MDAwMCBuDQowMDAwMjI4MDI1IDAwMDAwIG4NCjAwMDAyMjgyMTggMDAwMDAgbg0KMDAwMDIzMTA2
MyAwMDAwMCBuDQowMDAwMjMxMjIxIDAwMDAwIG4NCjAwMDAyMzE0MTQgMDAwMDAgbg0KMDAwMDIz
NDQxNiAwMDAwMCBuDQowMDAwMjM0NTc0IDAwMDAwIG4NCjAwMDAyMzQ3NjcgMDAwMDAgbg0KMDAw
MDIzNzIzOCAwMDAwMCBuDQowMDAwMjM3Mzk2IDAwMDAwIG4NCjAwMDAyMzc1ODkgMDAwMDAgbg0K
MDAwMDI0MDYwNCAwMDAwMCBuDQowMDAwMjQwNzYyIDAwMDAwIG4NCjAwMDAyNDA5NTUgMDAwMDAg
bg0KMDAwMDI0MzgwMSAwMDAwMCBuDQowMDAwMjQzOTU5IDAwMDAwIG4NCjAwMDAyNDQxNTIgMDAw
MDAgbg0KMDAwMDI0ODI0MyAwMDAwMCBuDQowMDAwMjQ4NDAxIDAwMDAwIG4NCjAwMDAyNDg1OTQg
MDAwMDAgbg0KMDAwMDI1MjgyNSAwMDAwMCBuDQowMDAwMjUyOTgzIDAwMDAwIG4NCjAwMDAyNTMx
NzYgMDAwMDAgbg0KMDAwMDI1NjcyMCAwMDAwMCBuDQowMDAwMjU2ODc4IDAwMDAwIG4NCjAwMDAy
NTcwNzEgMDAwMDAgbg0KMDAwMDI2MTE2MSAwMDAwMCBuDQowMDAwMjYxMzE5IDAwMDAwIG4NCjAw
MDAyNjE1MTIgMDAwMDAgbg0KMDAwMDI2NTY3MyAwMDAwMCBuDQowMDAwMjY1ODMxIDAwMDAwIG4N
CjAwMDAyNjYwMjQgMDAwMDAgbg0KMDAwMDI2OTMzOSAwMDAwMCBuDQowMDAwMjY5NDk3IDAwMDAw
IG4NCjAwMDAyNjk2OTAgMDAwMDAgbg0KMDAwMDI3MjI1OSAwMDAwMCBuDQowMDAwMjcyNDE3IDAw
MDAwIG4NCjAwMDAyNzI2MTAgMDAwMDAgbg0KMDAwMDI3NTM0OSAwMDAwMCBuDQowMDAwMjc1NTA3
IDAwMDAwIG4NCjAwMDAyNzU3MDAgMDAwMDAgbg0KMDAwMDI3OTcxNiAwMDAwMCBuDQowMDAwMjc5
ODc0IDAwMDAwIG4NCjAwMDAyODAwNjcgMDAwMDAgbg0KMDAwMDI4MzE3MyAwMDAwMCBuDQowMDAw
MjgzMzMxIDAwMDAwIG4NCjAwMDAyODM1MjQgMDAwMDAgbg0KMDAwMDI4NjkyMyAwMDAwMCBuDQow
MDAwMjg3MDgxIDAwMDAwIG4NCjAwMDAyODcyNzQgMDAwMDAgbg0KMDAwMDI5MDU5OCAwMDAwMCBu
DQowMDAwMjkwNzU2IDAwMDAwIG4NCjAwMDAyOTA5NDkgMDAwMDAgbg0KMDAwMDI5MzY3NSAwMDAw
MCBuDQowMDAwMjkzODMzIDAwMDAwIG4NCjAwMDAyOTQwMjYgMDAwMDAgbg0KMDAwMDI5Njg0NiAw
MDAwMCBuDQowMDAwMjk3MDA0IDAwMDAwIG4NCjAwMDAyOTcxOTcgMDAwMDAgbg0KMDAwMDMwMDEx
OSAwMDAwMCBuDQowMDAwMzAwMjc3IDAwMDAwIG4NCjAwMDAzMDA0NzAgMDAwMDAgbg0KMDAwMDMw
MzU1MyAwMDAwMCBuDQowMDAwMzAzNzExIDAwMDAwIG4NCjAwMDAzMDM5MDQgMDAwMDAgbg0KMDAw
MDMwNzUyMiAwMDAwMCBuDQowMDAwMzA3NjgwIDAwMDAwIG4NCjAwMDAzMDc4NzMgMDAwMDAgbg0K
MDAwMDMxMDYwNiAwMDAwMCBuDQowMDAwMzEwNzY0IDAwMDAwIG4NCjAwMDAzMTA5NTcgMDAwMDAg
bg0KMDAwMDMxMzk2OCAwMDAwMCBuDQowMDAwMzE0MTI2IDAwMDAwIG4NCjAwMDAzMTQzMTkgMDAw
MDAgbg0KMDAwMDMxNjgyOCAwMDAwMCBuDQowMDAwMzE2OTg2IDAwMDAwIG4NCjAwMDAzMTcxNzkg
MDAwMDAgbg0KMDAwMDMxOTkwNSAwMDAwMCBuDQowMDAwMzIwMDYzIDAwMDAwIG4NCjAwMDAzMjAy
NTYgMDAwMDAgbg0KMDAwMDMyMjM4OCAwMDAwMCBuDQowMDAwMzIyNTQ2IDAwMDAwIG4NCjAwMDAz
MjI3MzkgMDAwMDAgbg0KMDAwMDMyNTM0NiAwMDAwMCBuDQowMDAwMzI1NTA0IDAwMDAwIG4NCjAw
MDAzMjU2OTcgMDAwMDAgbg0KMDAwMDMyODE0OSAwMDAwMCBuDQowMDAwMzI4MzA3IDAwMDAwIG4N
CjAwMDAzMjg1MDAgMDAwMDAgbg0KMDAwMDMzMTAxMSAwMDAwMCBuDQowMDAwMzMxMTY5IDAwMDAw
IG4NCjAwMDAzMzEzNjIgMDAwMDAgbg0KMDAwMDMzMzk4NiAwMDAwMCBuDQowMDAwMzM0MTQ0IDAw
MDAwIG4NCjAwMDAzMzQzMzcgMDAwMDAgbg0KMDAwMDMzNjU3MyAwMDAwMCBuDQowMDAwMzM2NzMx
IDAwMDAwIG4NCjAwMDAzMzY5MjQgMDAwMDAgbg0KMDAwMDMzOTY1NCAwMDAwMCBuDQowMDAwMzM5
ODEyIDAwMDAwIG4NCjAwMDAzNDAwMDUgMDAwMDAgbg0KMDAwMDM0MjY0MSAwMDAwMCBuDQowMDAw
MzQyNzk5IDAwMDAwIG4NCjAwMDAzNDI5OTIgMDAwMDAgbg0KMDAwMDM0NTczMSAwMDAwMCBuDQow
MDAwMzQ1ODg5IDAwMDAwIG4NCjAwMDAzNDYwODIgMDAwMDAgbg0KMDAwMDM0OTM3NCAwMDAwMCBu
DQowMDAwMzQ5NTMyIDAwMDAwIG4NCjAwMDAzNDk3MjUgMDAwMDAgbg0KMDAwMDM1MjI4OSAwMDAw
MCBuDQowMDAwMzUyNDQ3IDAwMDAwIG4NCjAwMDAzNTI2NDAgMDAwMDAgbg0KMDAwMDM1NDg3OSAw
MDAwMCBuDQowMDAwMzU1MDM3IDAwMDAwIG4NCjAwMDAzNTUyMzAgMDAwMDAgbg0KMDAwMDM1Nzcy
NSAwMDAwMCBuDQowMDAwMzU3ODgzIDAwMDAwIG4NCjAwMDAzNTgwNzYgMDAwMDAgbg0KMDAwMDM2
MDY5MSAwMDAwMCBuDQowMDAwMzYwODQ5IDAwMDAwIG4NCjAwMDAzNjEwNDIgMDAwMDAgbg0KMDAw
MDM2MzUzMCAwMDAwMCBuDQowMDAwMzYzNjg4IDAwMDAwIG4NCjAwMDAzNjM4ODEgMDAwMDAgbg0K
MDAwMDM2NjgzNiAwMDAwMCBuDQowMDAwMzY2OTQ5IDAwMDAwIG4NCjAwMDAzNjc1NDUgMDAwMDAg
bg0KMDAwMDM2ODA5MSAwMDAwMCBuDQowMDAwMzY4NTAxIDAwMDAwIG4NCjAwMDAzNjg2ODMgMDAw
MDAgbg0KMDAwMDM2ODg3NSAwMDAwMCBuDQowMDAwMzY5MDc2IDAwMDAwIG4NCjAwMDAzNjkyNjcg
MDAwMDAgbg0KMDAwMDM2OTQ1NiAwMDAwMCBuDQowMDAwMzY5NTM0IDAwMDAwIG4NCjAwMDAzNjk4
MjIgMDAwMDAgbg0KMDAwMDM2OTg5MCAwMDAwMCBuDQowMDAwMzY5OTg4IDAwMDAwIG4NCjAwMDAz
NzAxNDAgMDAwMDAgbg0KMDAwMDM3MDI5OSAwMDAwMCBuDQowMDAwMzcwNDE3IDAwMDAwIG4NCjAw
MDAzNzA1NTAgMDAwMDAgbg0KMDAwMDM3MDY2MSAwMDAwMCBuDQowMDAwMzcwNzg2IDAwMDAwIG4N
CjAwMDAzNzA5MTIgMDAwMDAgbg0KMDAwMDM3MTAzNyAwMDAwMCBuDQowMDAwMzcxMTYzIDAwMDAw
IG4NCjAwMDAzNzEyODQgMDAwMDAgbg0KMDAwMDM3MTQwMSAwMDAwMCBuDQowMDAwMzcxNTI4IDAw
MDAwIG4NCjAwMDAzNzE2NDcgMDAwMDAgbg0KMDAwMDM3MTgxNCAwMDAwMCBuDQowMDAwMzcxOTQw
IDAwMDAwIG4NCjAwMDAzNzIwMzEgMDAwMDAgbg0KMDAwMDM3MjE2MiAwMDAwMCBuDQowMDAwMzcy
Mjg2IDAwMDAwIG4NCjAwMDAzNzI0MTAgMDAwMDAgbg0KMDAwMDM3MjUxOSAwMDAwMCBuDQowMDAw
MzcyNjUyIDAwMDAwIG4NCjAwMDAzNzI3OTcgMDAwMDAgbg0KMDAwMDM3Mjk4MCAwMDAwMCBuDQow
MDAwMzczMTU3IDAwMDAwIG4NCjAwMDAzNzMzMDggMDAwMDAgbg0KMDAwMDM3MzQ1NSAwMDAwMCBu
DQowMDAwMzczNTk4IDAwMDAwIG4NCjAwMDAzNzM3NTggMDAwMDAgbg0KMDAwMDM3MzkxNiAwMDAw
MCBuDQowMDAwMzc0MTE1IDAwMDAwIG4NCjAwMDAzNzQyOTcgMDAwMDAgbg0KMDAwMDM3NDQ2MCAw
MDAwMCBuDQowMDAwMzc0NjE1IDAwMDAwIG4NCjAwMDAzNzQ3NDkgMDAwMDAgbg0KMDAwMDM3NDky
MCAwMDAwMCBuDQowMDAwMzc1MDc3IDAwMDAwIG4NCjAwMDAzNzUyODggMDAwMDAgbg0KMDAwMDM3
NTQ5MyAwMDAwMCBuDQowMDAwMzc1Njg2IDAwMDAwIG4NCjAwMDAzNzU4NjkgMDAwMDAgbg0KMDAw
MDM3NjAwNiAwMDAwMCBuDQowMDAwMzc2MTg0IDAwMDAwIG4NCjAwMDAzNzYzNDIgMDAwMDAgbg0K
MDAwMDM3NjQ4MiAwMDAwMCBuDQowMDAwMzc2NjQxIDAwMDAwIG4NCjAwMDAzNzY3OTAgMDAwMDAg
bg0KMDAwMDM3Njk0NCAwMDAwMCBuDQowMDAwMzc3MDY5IDAwMDAwIG4NCjAwMDAzNzcyMTcgMDAw
MDAgbg0KMDAwMDM3NzM2MyAwMDAwMCBuDQowMDAwMzc3NTE1IDAwMDAwIG4NCjAwMDAzNzc2NjUg
MDAwMDAgbg0KMDAwMDM3Nzc4NiAwMDAwMCBuDQowMDAwMzc3OTIxIDAwMDAwIG4NCjAwMDAzNzgw
NjcgMDAwMDAgbg0KMDAwMDM3ODE5NSAwMDAwMCBuDQowMDAwMzc4MzQ3IDAwMDAwIG4NCjAwMDAz
Nzg1MDEgMDAwMDAgbg0KMDAwMDM3ODY1MCAwMDAwMCBuDQowMDAwMzc4ODAwIDAwMDAwIG4NCjAw
MDAzNzg5NTYgMDAwMDAgbg0KMDAwMDM3OTEwNiAwMDAwMCBuDQowMDAwMzc5MjkyIDAwMDAwIG4N
CjAwMDAzNzk0MzggMDAwMDAgbg0KMDAwMDM3OTU5NSAwMDAwMCBuDQowMDAwMzc5NzM5IDAwMDAw
IG4NCjAwMDAzNzk4OTMgMDAwMDAgbg0KMDAwMDM4MDA0NyAwMDAwMCBuDQowMDAwMzgwMTk4IDAw
MDAwIG4NCjAwMDAzODAzNDIgMDAwMDAgbg0KMDAwMDM4MDQ3NCAwMDAwMCBuDQowMDAwMzgwNjYz
IDAwMDAwIG4NCjAwMDAzODA4MzggMDAwMDAgbg0KMDAwMDM4MDk2NCAwMDAwMCBuDQowMDAwMzgx
MTY1IDAwMDAwIG4NCjAwMDAzODEzNjggMDAwMDAgbg0KMDAwMDM4MTU2MSAwMDAwMCBuDQowMDAw
MzgxNzE1IDAwMDAwIG4NCjAwMDAzODE4NzQgMDAwMDAgbg0KMDAwMDM4MjAyOSAwMDAwMCBuDQow
MDAwMzgyMTc5IDAwMDAwIG4NCjAwMDAzODIzMTkgMDAwMDAgbg0KMDAwMDM4MjQ3MCAwMDAwMCBu
DQowMDAwMzgyNjYwIDAwMDAwIG4NCjAwMDAzODI4NTAgMDAwMDAgbg0KMDAwMDM4Mjk5OSAwMDAw
MCBuDQowMDAwMzgzMTQ0IDAwMDAwIG4NCjAwMDAzODMzMzMgMDAwMDAgbg0KMDAwMDM4MzUyOSAw
MDAwMCBuDQowMDAwMzgzNjgyIDAwMDAwIG4NCjAwMDAzODM4MzMgMDAwMDAgbg0KMDAwMDM4Mzk2
MyAwMDAwMCBuDQowMDAwMzg0MDkxIDAwMDAwIG4NCjAwMDAzODQyMDkgMDAwMDAgbg0KMDAwMDM4
NDMyNiAwMDAwMCBuDQowMDAwMzg0NDQzIDAwMDAwIG4NCjAwMDAzODQ2MTMgMDAwMDAgbg0KMDAw
MDM4NDcyOSAwMDAwMCBuDQowMDAwMzg0OTEwIDAwMDAwIG4NCjAwMDAzODUwMjkgMDAwMDAgbg0K
MDAwMDM4NTE5MiAwMDAwMCBuDQowMDAwMzg1MzMxIDAwMDAwIG4NCjAwMDAzODU0MjcgMDAwMDAg
bg0KMDAwMDM4NTU0MiAwMDAwMCBuDQowMDAwMzg1Njc3IDAwMDAwIG4NCjAwMDAzODU4MTEgMDAw
MDAgbg0KMDAwMDM4NTkzOCAwMDAwMCBuDQowMDAwMzg2MTE3IDAwMDAwIG4NCjAwMDAzODYyMzgg
MDAwMDAgbg0KMDAwMDM4NjM2NyAwMDAwMCBuDQowMDAwMzg2NDkyIDAwMDAwIG4NCjAwMDAzODY3
MDQgMDAwMDAgbg0KMDAwMDM4Njg1MiAwMDAwMCBuDQowMDAwMzg3MDEyIDAwMDAwIG4NCjAwMDAz
ODcxNjEgMDAwMDAgbg0KMDAwMDM4NzMxNSAwMDAwMCBuDQowMDAwMzg3NDc0IDAwMDAwIG4NCjAw
MDAzODc2MzMgMDAwMDAgbg0KMDAwMDM4Nzc5MiAwMDAwMCBuDQowMDAwMzg3OTUxIDAwMDAwIG4N
CjAwMDAzODgxMTAgMDAwMDAgbg0KMDAwMDM4ODI2OSAwMDAwMCBuDQowMDAwMzg4NDI4IDAwMDAw
IG4NCjAwMDAzODg1MDYgMDAwMDAgbg0KdHJhaWxlcg08PA0vU2l6ZSA0ODINL0lEWzwxOWE2MmIy
MjQ0YzNlMWQ1N2EyOWEzNTNjOGNjZWQyZD48MTlhNjJiMjI0NGMzZTFkNTdhMjlhMzUzYzhjY2Vk
MmQ+XQ0+Pg1zdGFydHhyZWYNMTczDSUlRU9GDQ==

--0__=5DnV1j7mrOy37Gam7COeoyGPPJynCEMhmXOFfzF2oo1OG521V0WiyrWs--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr 25 09:03:00 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11521
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 25 Apr 2000 09:03:00 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.39EB9830@standards.nortelnetworks.com>; Tue, 25 Apr 2000 8:49:54 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 13507 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Apr 2000 08:49:02 -0400
Received: from smtprtp.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.1AD07D80@standards.nortelnetworks.com>; Tue, 25 Apr 2000 8:49:02
          -0400
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          smtprtp.ntcom.nortel.net; Tue, 25 Apr 2000 08:54:41 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <27B9PDA0>; Tue, 25 Apr 2000 08:54:42 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B6FF@zcard00g.ca.nortel.com>
Date:         Tue, 25 Apr 2000 08:54:37 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Responses to Commands
X-To:         Bharat Kaul <bharat@TRILLIUM.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Section 9 is talking specifically about response to the ServiceChange
command.  The problematic case is D.1.5.

The problem is to ensure that a transaction response gets to wherever it is
needed to close things off, during and after handoff or failover.  Perhaps
we could try these principles:

(1) Clearly, until registration is completed with the new MGC, transaction
responses can only go back to the initiator of the transaction.

(2) For some intermediate period, responses should go both to the old MGC
and to the new one.

(3) At the end of that period responses go to the new MGC only.

If this sounds like a possibility, the next step is to determine what
event(s) mark the end of the intermediate period.

> -----Original Message-----
> From: Bharat Kaul [SMTP:bharat@TRILLIUM.COM]
> Sent: Tuesday, April 18, 2000 8:48 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Responses to Commands
>
> Hi Folks,
>
>   There seems to be some conflicticting statements in the document.
>
>  In section 9.0, last line of the section says that the "responses to the
> command should be sent to the source address". Similar statement occurs in
> section D.1.5 , paragraph 4.
>
> However in section 11.5 of the document, following statement appears
> The MGC and MG may take the following steps when Handoff occurs. When the
> MGC initiates a HandOff, the handover should be tran- sparent to
> Operations
> on the Media Gateway. Transactions can be exe- cuted in any order, and
> could
> be in progress when the ServiceChange is executed. Accordingly, commands
> in
> progress continue, transaction replies are sent to the new MGC (after a
> new
> control association is established), and the MG should expect outstanding
> transaction replies from the new MGC.
>
> So, is there a conflict or is it me ? Clarification is appreciated.
>
> Thanks
> Bharat
>
> --------------------------------------------------------------------------
> --
> -----------
> Bharat Kaul;                                      Trillium Digital Systems
> Inc.
> mailto:bharat@trillium.com          12100 Wilshire Blvd,
> Phone: +1-310-442-9222                Los Angeles, CA - 90025.
> Fax:     +1-310-442-1162                  http://www.trillium.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr 25 09:50:44 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12501
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 25 Apr 2000 09:50:44 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A587A4B0@standards.nortelnetworks.com>; Tue, 25 Apr 2000 9:43:01 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 13550 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Apr 2000 09:41:13 -0400
Received: from ns01.newbridge.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.FF95C290@standards.nortelnetworks.com>; Tue, 25 Apr 2000 9:31:13
          -0400
Received: (from smtpd@localhost) by ns01.newbridge.com (8.9.2/8.9.2) id
          JAA06648 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 25 Apr 2000
          09:31:30 -0400 (EDT)
Received: from portal1.newbridge.com(192.75.23.76),
          claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by
          ns01.newbridge.com, id smtpdCAASSUML_; Tue Apr 25 09:31:23 2000
Received: from kanmail01.ca.newbridge.com by kanata-mh1.ca.newbridge.com with
          ESMTP for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Apr 2000
          09:37:19 -0400
Received: from ntrgillan ([138.120.42.106]) by kanmail01.ca.newbridge.com
          (Netscape Messaging Server 3.6)  with SMTP id AAA7253 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 25 Apr 2000 09:37:17 -0400
MIME-Version: 1.0
Content-Type: multipart/mixed;
              boundary="----=_NextPart_000_0073_01BFAE99.D3841020"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0
Importance: Normal
Message-ID:  <007201bfaebb$5a95b020$6a2a788a@ntrgillan.ca.newbridge.com>
Date:         Tue, 25 Apr 2000 09:37:09 -0400
Reply-To: ROB GILLAN <rgillan@NEWBRIDGE.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: ROB GILLAN <rgillan@NEWBRIDGE.COM>
Subject:      Unsubscribe
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_0073_01BFAE99.D3841020
Content-Type: multipart/alternative;
        boundary="----=_NextPart_001_0074_01BFAE99.D3841020"


------=_NextPart_001_0074_01BFAE99.D3841020
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Unsubscribe




------=_NextPart_001_0074_01BFAE99.D3841020
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D671383613-25042000>Unsubscribe</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_001_0074_01BFAE99.D3841020--

------=_NextPart_000_0073_01BFAE99.D3841020
Content-Type: application/octet-stream;
        name="Rob Gillan.vcf"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
        filename="Rob Gillan.vcf"
Content-Transfer-Encoding: quoted-printable

BEGIN:VCARD
VERSION:2.1
N:Gillan;Rob
FN:Rob Gillan
ORG:Newbridge Networks
TITLE:VP Broadband Wireless Access
TEL;WORK;VOICE:(613) 599 3600 x5985
TEL;VOICE:(613) 220 0311
TEL;WORK;FAX:(613) 599 3674
ADR;WORK:;;600 March Rd.;Kanata;Ontario;K2K 2E6;Canada
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:600 March Rd.=3D0D=3D0AKanata, =
Ontario K2K 2E6=3D0D=3D0ACanada
EMAIL;PREF;INTERNET:rgillan@newbridge.com
REV:20000403T182149Z
END:VCARD

------=_NextPart_000_0073_01BFAE99.D3841020--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr 25 10:07:09 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12847
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 25 Apr 2000 10:07:08 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.092A9F70@standards.nortelnetworks.com>; Tue, 25 Apr 2000 10:00:07 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 13666 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Apr 2000 09:59:01 -0400
Received: from smtprtp1.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.E1D64370@standards.nortelnetworks.com>; Tue, 25 Apr 2000 9:59:01
          -0400
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          smtprtp1.ntcom.nortel.net; Tue, 25 Apr 2000 10:04:40 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <27B9PGDC>; Tue, 25 Apr 2000 10:04:39 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B701@zcard00g.ca.nortel.com>
Date:         Tue, 25 Apr 2000 10:04:33 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Errata Document
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Attached is a new and expanded version of the errata document, covering just
about every issue I've found.  There are, I think, only a couple of issues
left.  Please look it over and confirm whether my optimism is justified.

 <<errata.zip>>

Tom Taylor
Phone and FAX: +1 613 736 0961
E-mail: taylor@nortelnetworks.com


begin 600 errata.zip
M4$L#!!0````(`-Q-F2AHU6=*UR<``$2!```*````97)R871A+G1X=+5]:V_;
M2+;@]\;F/Q2(!=:>E17+3IR.!P%6\2/MVWZ-[<Q@MM$8E,B2Q1N)Y+`HV[H7
M\]_WO.I!BE;:LXX"=%LB>:KJO%]5?//3A<ERK;[HQCSJE3HJBZ8NY^J/?:Z'
M=T-UIU?SLG[STUG1F+HPC3JN];3Y_L/N<UG6C9FK2],\EO4W^^:GXS)=+DS1
M'*H,(>WDIIGN+,R]3LL=4]>ZT3N[N\/FJ7>,<57G<[6WN[O[YJ<C6-1]6:\.
MU6VCBTS7F55WM4Z_O?D)__$#1V5=F[3)RP(NEJJ9&75L8"6+O#"9NJ!AW_XR
MW'OWL[JNRZ9,`3MNA@P'@#=+J\HI/)Q;>&11"O@[_)[)S0K^UH5R:-IA-,&\
M\$)>J.ER/E=I64S+>J&+U*C'O)D1&`T7JKI\R"W-$@:ZY1FKT2Y^NSD]VMO=
M.U"_C7X?RLCM46#@&N`!>O/BWD](IFS\S>JDN(=5FQKNXOEK^TV=EC5,9NOL
MY.YT>Z!R!J;M@*<.7QW<^[I<5G8(!&T,P-4-P2AAA%JNJ06PF)[;4F6Y;>I\
MLFSZIJ5MF#_!X$4,>U=%/!(]_*#G>:8`B4K#<$_Y8KF`=1(8FS^I!3#XS-+<
M<3(3HY95!GR2#51MJKE.\2]XN)S8<@Y\D*G)BM=`(*))(NU6JLD7!B;6,!%U
M!70"#M2(@5(M;4#NCJR"*6IAM*FI#=)Y`7?#(W,<%AY*<T*?60CJ`),%/I`@
MHF`,`@##W-?&VF$BC&;4'%"*%$V7P-#`;EUDI0`&EJO3%)Z#=0E]9DU3';Y]
M^_CX.$1!&Y;U_5O\X^THSW;T!,BD4\`]B-O:2!U6OIWIK'Q4QSG*4UGGYD5C
M6GIZ.&L6\R'+U6BHQC)^KSS!,"6*-+(PZ(6RMD#V)3)E0;\Q9\02[%#'4NP!
M_;;W.W#SO`0F1)FCAU/`^CVL`.E9XM0%:&,$$20[.G`>D@XH4LX?F'HP^2F@
M1_UGF2,Q0'K>GMU]W;D#7;3,5NH+"@0!&ATH8IL'Y``22.":-&BE`?ZT@IF!
M%@!<Y@5<J\H:>1:^-*2R"-`4^`]69=(\@TL/ID9U@2!9>R'+T\H0M*W*(D.I
M8_1XI!`@T"="@KTA6H0'6!YIGJ5'1$0'3QNCON$\B2;)Q=?;NV3`_U>75_3W
MS<E?OI[=G!SCW[>_C,_/_1]\!\&!'ZZ^GLL]^%=X^NCJXN+D\I@``.3QWQ-6
M0LG5]=W9U>7X/''BT9H@J0G`$R$/2%+5)-<@4IFQ*6@A7A2L>F=O-/KHU6C?
M/S9V*GPZED7M[*B3IPI$P*JKM"%#I+J?T9N?_L?:C_QIV9O8-,6?R,;QK/9!
M`UF[A#%!]X+"1B$`6W9C_KF$F:@CYN58B*P8$!1ET&5J:AZ=-<@94JUSI';)
M;"]L@K<3D,=9GL[4(V@PD;FB%`G@(;4($"(6Q&M(_($V"/^C"42Q7$Q`/F!4
MUG-V"1!E<`8O"IKE'.9"$+0EQ=XTHI'A>;Y!5899.BT7%:AN8?ZSD]LOZER#
MQCH".SKLK!^EBL#`.)EAA3^MRP4M6@3*L9%=3A9Y$XN=BB2:H)!4HT2C%)+X
M@6"A[H-QQR"_;EA>.QLP&@YQY+T29]WA`R['9`ZFX+G/#6J<)=Y-3WX8CH8?
M^<IQ;E/@2T0(8&&RG**YR91Y(.N%;I>0:(A0M"T+#2,YK\A]'F>F4"?XS&>"
MX/S#7#@RU=:0L5UH,N*Z"X#'R)`WKDY/_7/^D^4T,4"O1QDBI`L&M5YA@?OP
M3E+2WB&BZTB,LD!;FA'/?3&%>="#+AB<*7!J/LU3[1ADL9PW.3`,7@>'A#@9
M3,X2N`6<E:(+0A`(FK]$XPUCS8D9_76T1,/N4Q9\1..<,Z32:$2_$V-.P/,#
M[XO,*FB3[K.@K\`K0>Q:&)I<!IL#BZ_DNEY,\OMEWJP&,'><.BQL;0(`0U=Y
MLYRC:Y(98.U<$/!&O>B#&@:L.BU3E75WG%^-J<8P!;""T[F^#TO>&[X?T!TW
M9DZXM[.\`K%K'@VP&)I5TN7@D,]U[0F$2VH\A`,>`QPUT*^`"T]#$.,,N=T@
M@(`0]*CZZ:&76=Z0MC*6?#>D>CHWN@YB^'.X_:A<+'!VYLFD)&W*SLKE/$.U
M@9]+]S0(#'!&HIMRD:?)&A=4P./3G(T/WS.,KR^,1GM?Z;K)4R!5/5]U07SO
M\TA*TC$I3-GF]Z#%[$OAH&9*D</!P<L<%4^`<??X^I=:%SA#PO)41HF>'S]J
M0+!YJL"U)9:=&!"^-?T2Z6J:,Y*B*4M_O29.!=9'`5\8U":Y7:R1,RUU;9UM
M<'>ASI%/<HE"OSKRHX&GL(:2#+0_F&Q>RAP'G>I\O@168R+-\V\&A(X]"7#9
MYCGIM1=C%@"!'8%GK6E<:/*"CQ!TH"",6A:%0?.BZQ<S"ON`%HRML#)*P&2-
M0-_[(+$F2Y"\PI8+X_VF=]XC.<O0>R2F_PS:%27E[[#N&W:5LQZG9(!TQ,"R
MR1M0RZCJ()88(#LV.@=?J.4DS/0#,I=A19V'T4`S0Y29+BV[P>S'D(Y%+8^6
M@`%HMO/T>.W-*<"U@A)03SJ=Y<"?F9AQ[Z;+3!9+ZW$G,4"&NF=1/K#IPZ%!
M9SWDY3+X'BP1P3>1:.D5'<V]UW8T%4I)"F(/RQ+11?_A%Y+PINM8Q4Z5+!;O
M83!15B0X5LZM0I\-*<0>F`N/G!JZ&W\^/U'')^<G=R?'ZA_`*V9A`[(+M"4R
M#V'(]T-UPA'B*4#]&]$]7O08IH9IG#8_YE;\"I!ZORYV?'%UM5D`.Z[%0TI/
MG6_JUX+,Q*LP+@@#&U5X^P7N7SL^XWD1$'(=$(%S"(\5IAI<V-(*??%Q9_CR
MEG00%&)C'Q[W1KP1/BCB%%_>85V\TD/D*OBZXS_TE:3]4%T:F&I(;0`USH;[
M!_O#]VIK/#Y_ORVP@MMZJ,89II'^/T>!X`W<[H.1VKJ^OMX>OLXP?QE^V'OG
MG`.,??O@'A.#LQ?O$B-^:G9MO'<;QOM\<_;OC*8G$U0M[%2M+W"@CC:,>6Y0
M?]Z8%(P<3;MF(0(F&8-Q>5)'8&0D049.)]I%="(E$"0-V#O3DO(C:_,Y`#]N
M(VW;KI3S[&`6*"O!:LW+\AN9Y.>(31%<.0>I(?\!E,(AW:>2''36%_!0T>W$
M/"^+X9WV@04X+21#U>B3!G=L[]-DX!WSUB.3]4?V/J7PR/XGD$;U]?+LZI*>
M<O-6C\YMO/M3#%Z>P73>*^G^_=?6_7V$W,3-MWIE.44FZ%EA;A;-)?H]P%^7
MDO!FW[_&0']A,"XVC&G4:+4!@\\*D$+1&/NU:98U*JN20`T55R]TEJ?@/$0\
M2@/`@!A"[#_++G@3@)KF-8@5N.`:U7J=^:#K4"47I6TB8A,<\C\@H-(01LH"
M!\ZS0$_\";R7%!R9%4==40+-"E4)#-`;T3)9A<`6V':8*"_R85Z@QFO@.C<Q
M&4[X3&<P44S&M>9$>B(0@K_-5A;"K+FZBY":2L0[,3YTGZ#U:QJ4HIQ0I*.H
MG:$S;6#0")2H!Y<X+9#:1TQM9O.7,--Q?I\W%[I2,&:](IB8KL"T`S"40W+;
M)AS?79PR_<LB:.*8[IP8@\=!DSHEP1[$(V43M!4-8@&GQT0^)GI%(3_PGKY'
MC[01@EN,)U'M,X)#N,>>O@_+*!_IT+S033K#>THVNY(SAR`7"V,<*G+]1-6Z
M\14!"Q.>K_HQ^7X#)F]*5+"Z8,9%V<+%IU1U>31`(VUC?491+TV[#X$:!"<)
M,!+GP'4XU*46B8<%@;6^KW4U&Y`90^23NL_C`@Y.%3UN/XB,\.AJ2V.,XO]*
M'(@K8H40'NVBYL-P-%#CC=8'!0>3C36R&!.5O:VJ*25?)QD]U$B@^^$VC=[<
MPMD'3DV"#L`HHY58`,4++C"X@#66T?#:-']R^L"H\>WE<(1/$9@'"*V)P]W5
MSY>G&U47(8@"9=ULF#.#$Y736B<QG]S\@"4$5*@L(#PU[Q(`"AW_:I0.FN#%
MER.D#?/\BH%31A#]^_M[T,6L2OZCG!5`DGO`$4'8`L%RDW7SI*0E`D@&ZF_P
MV.C]V]W]M[N[VST4'8XVDA,U."G-+1<,`NQE$403+RZPX&NW#P.Q"`CC)=Q`
MV$%":YCKJH\:-UQ"#,RNFL?2BX%56P8B29#N^[R@K(9SOGDX3&(GT=R2[>"=
M]WDRR1EJ&7'3LXCH<>60F(>R7=%U"<)B/&SE0W"+,'JN,<NA)SCK;?8T/8=3
M+<I'LJ_FJ[S[`7%JV]?H2`7I"/HM<BA`*J=8TQT@G0D&*!2-)AN5D%KDS#P]
MR%1(`AA0RH"8'EU4S2KHJ.AV+H4`#X#^!2363C=>?&%BHZ>(:2@1L'Y6#:HG
MF@>J#&/;/!5=]MD\SJ\4&:9862/899H:EV)F_*X;%I2U]P/U>;/^)%^.3*8Z
M^N7JZO:$4-WU`*5,%WD+%'VC)F#%B>H.(FI#^G.#Z<;[Q*V7CQOJ6M<+]4E5
MW^ZS2\":VE+)_TS46T3B@DQ&KS(Y^$,+=,BCBB@2,&GJI4FX&#G5<PM_RTI!
MA\QYFDQ.#%T2S#_2O>5TFO0L#I4Z2ASE1PJ<$3.K#)-+OCQ4<JUC%P*-BAH&
M'+3FT[Z9A^ZSD,.?-ZR>RCV<8L8,?/U@N.(%));O;(TQ<P)3!>.NQ>!SC0/9
MK3&+H`$/28D1_Y>9:3FH^.-Y"?ZIU)RZ_`QC0-CZ<(79&?AZ:XH,OP^&PV&"
MR4*,LZC7A!R=X]MK`I`7#YB><ZBEQ(=F(D)$64U092U@*L_9VL3=U8^\CQN0
M1V6TXPN<.&;X*6V^*AK]Y,M."RZTBU!&&:R>B9`9$!.0H7<,EJGJS:=+L<05
M:SB?ZMT.FI4--G@0SY,*_MB3HFOPNDTN9H5U2X%B17K4A"`#OVAKRS0GY>)G
M-@0\&9]%([O]KE_';$)AG!PP-!EQJ9LZ!Q\#8BAP7)2!X`1#P"TSO!]*OIR@
M1,I^&RMXV+R#D^;,/YF`Z-?(&=ERPPD.D5BH?KG0Q2A4`8?;B)8(4EQRI!2R
M+;DTB=AJO(]"#K%#HD,5UB!(8H4Y\*(UM%`"X1:+LDZ%!8NFA*N`%,O$8_?P
M$L@=^FO?G\F`(Q1TTEFD,=:TXHG<10&GC.WMVH##0^U8<DOX"*(LBHH1]\9'
MP:Y2O<VLZ_Q6%VB1P&(4*?UKND.%KI9`M'#:D^LV3AC6?8)7\V;>_P!O9BO!
M)H?[(O\O=`L'7"9#QQ+33%S<<CZ:B\$NO@P57Q+J$R#IJ<A<JB]G*GEE`7Y?
M67-'C,!Q_619+E*$G7O<51"0'S30EEV3\VWD^2)NHQ,6P1`(G3$,%E%XL8^B
M%2;QM&3I]`C./]6@EPB.S`W]59Z'%,<(.4U942N??Z2UG(A=`&EOT8+(LQ'W
M,,^$QL!6SY!F;D0:2!4OKH`,@V'GF"#Q6B9A'RV)UI4X=2R1<Q!"WPTA8\5B
MV!+!2^P;G<]7@Q:^F$J,1SOC*A.B`GL7UW`FY"U!6ZN_H<Q&U7Q<F?=$9;($
M=N#<5P;OZO74:E4O*VZ3=&/(D.5:MDB541S*@!F,]1K"8_2L".IJ!SV,.)T@
MQ**FV696&XR@,=/&61E&E8/8(03*EE.1G!?'83@L"X]H&V6UN$#EAW^Q3W"$
MOL<(:-J82NUMZ6V&+;48X&OL!J:F#0Q"3ERB:E[>YZF79]!&J'=STK%Y0;T=
MAMP99VQ8C^,8YBF=+S,,C(*EC$32<AL6!NU<T8],Y@;K$:9//6`Z"P%JI%T8
M9?]<&O808R:RE`8*G`6V@2"L>R?";-B4ZMB(P7.Z&*N`6#WV75P!#'<P2?Q%
MIAGX8E$Y0R5:E+EXPK2GNQP0'N91V]`>Y%F3@<*\&A0;['VPTH/\W$I(Q#`V
MP)NIV<#=WK-H$*$PA2`1+L]<5>@2.7>VI>!XT<>1E0,PKCC+:JWE"7HDD?Q'
M\XFR-)(]P+8D$.;,J>G(7P(A-!I1@$0@YACU.WNC_0W"<2$1=P*NKBDLJ4ET
M<,%##NPTOCY[SD5V$;M_IE<\1YORSEX4N0S+K=\U6''NK,,)D*)K^SR9Z$"[
M6DS*.2L9YQT!2Q&&EO/^G#3ILV[B-)B#D#LBGPM\?>P]2YX2IRW)9:><L2N=
M#12&1%''T@*%EIM78F$=6TKT%"Z+[09GMS":-S@)(&4#7OD.$Y\O,W<16U-:
MFQ*`3H=@*V7C<$*!,&FE65FSIPR^WXH=GE=QPPY^2/,#$1'+,F=.43VUS$]`
M6*<\PY1SQEJ-9<G.IM91AD\3HCB.#5233HJAG\P?Y^);E,#W$E26V*V[Y#H;
MUY"QPFMJ8G"+#)#EC(VIJ(O>\))\>BI"4/(]R[%(K+@GHI>Q74U6&L1Y]PAU
M1G!OPA(5JA1#7"&!E9ZS>@ZC8M5$VSL!@8L0I%%!"V=1?Q-4`Q[5UL1$'J"?
M+28'`;24(:FW:,%=*AH=$AY>S['4H\EO$3]*!&2;A2XHN8.7*YA61%L`)5PY
M**H5!?>$FT0XUF4-\UR\VXIU^\@1!W[LQ3RO=#QK$A32\]FRQD=HU4Z/Q/4R
MQCW[I(*VD/*4B8*C64DDX?S#90%JD14#<1V!64MJ(-/@+9UF4W"/L60"H2.2
M,R\P_X;IV*J2/DHTL92!)R>'83E;.D#7R%3HTTMU:1B[)V)M*M`^^MXX?G$V
M('C&7E8(1,_<.ZGY]81-8\U\2G1WKK2BA.-#GK'3P1$]A2-2<QH&'U]\:&81
M5.@)=9,"$8BQDGA`KD[)$%TFPR0?M6QQ(UR;TY:`7A0S'Y\+D*A*,?-\V[*,
MSV:JGO$/-LD.`FR[_Z'-#*NZ&D?`58(C`")&%IOC7>;C?EIN3J:%RG<K,'L&
M%CN*#+)7*?X3+CLI%-W\O!BNB=<-.2(D,7"SRU'%^<!<0BYIX)FV)HO941$P
MT7YA_<+V\,,"^/'!T#8DCM<7OI3-*HAY7QKJT6KU:\%->66NTTD?O&X:32J0
M;(!+21TJBPTE/DGK6C()S`0M1Y%7&"DA[J/`$O/*S@0#&V//&^"(-0@$T9C$
M[&U?XJX+$M$YF8[DSWYP5LLIZ#PI:DI_A&>'SO@)V^Q7<FP^_`#')B+5YD8,
M,)[2GT8+E1J/[]*BNEI8_%G&G1`7I;0A2H[JN5X"8C&6"<=0DH7J"$?<\Q*J
M,=V*WIG?Y!DV"/0PY^:&B?6<<]1V`*N[FE#A(^M&;02#NSBL$Z=45\VRYI`K
MSJO%.;5.0NU[_4IN];SX?-HK_L:;BNXLVWD=UMK2JL:5S&BQ$`Q1[H``;:PZ
M2#O,#,N`)$(]:W6=#J[*1[>':(&@+0#AY<M)=NIRYAXYU%P2+07Y-(IWUZA&
MG64;G-A..5XE$3#E&]-F1D4]_LZCPYQMJ)#XHJZK&(:<IK@S*NK9Z)USG^FD
M[3;CX=[WZIG'#OL>542%0G;(8''$D=GZA2T+5)O,4.'RAC*MU+D`FFODBC@0
M^8S:2*1_1]`E@\3C5X"ET#_B^DJ04;:2WTX?LT._Z:!0#Z,#`D-[DW_O-I+T
MLM3!O\E21[K2DWS.?=<N:.JEU*MR%F!']!\=&4!X`+/&$M[/$]\M;Y^%?7;I
M*DIT5"B4UN:TS%5,2%<2NV:G@OK(4H>0E;`1=>@_I\E<I1N0BY7NA!XY@R<2
M##6RI=0*&._!R@+V_1Q0IL($V'5FI@KIK352$9S8(+V*=?[Y]?MN58>*FSPI
MX/R*=IR/MEVIPCFC7V`-!L)L`%8_Y*D1V60=._`JQJ9EY9U/=.&1.IFPEU3A
M,"L(C%*X!6#>J0C;YU3'LL>%$F9RZHT*QEP+\U>S&A/B21DT7F0.MNRVTA2!
ML->%3[37(M3L\T`WHXT#AFJN"^KM<C8JTM.4Q&N-QKMF73:TK'`D,&_";JSR
M!KZV+S]3^^LSWD_B8"0NCDG6YY3$YL!=SD.$U3/%)!B9%R/FNB_S..Z@W6V/
ME.8_83A>(S9B8OHQ!S;*$)54U(C#1%=ODT6T0+,*CQH$0PL4[GLI3+FTN#NG
MB?R_C@_C9M++*9Z])!L)&@]/)F&,AKW;LAV(Y:/D'4'YM#U4\&.D!1*-J.2.
MJ#WR>YX<0BN!O8O67M]GZWWC]%M1/H)_<,_=+'WT]Y1QF[6L1T??2GT.Q/=S
M8U?G3#O+3[D!>CI.BK5&O+A/S];/5D!0[4QIGWW:5`N@OBO*W]#&XQ2[A=[M
M[D?YT>X&<<*9L\;O=M^1D7BW^WZ#F^(HD=RRO\)CP?Q!_1>6<_PWO&?XI=.G
MGJDP68A$&7CM-[3`N*UA*NIK(B#1[]?,'@,U-]P-L9(X-#`B1JF]QE9B6L2=
M18P,$!WPGX/1SKN##^NVYN?O;-4Y]<5/XI''NA2O98U0[_8V83T@_,0A7/CV
M=0/GCS\R<![M?M_9!B[@HDF^4.-?U`RD&9RZE-LH.+DWH5T'7!2!/_;>J1+,
MG30J;*$#?'-ZA+_O[@_PO^^BO2;H(DG9V&^$R+9YSR!&@B[=(Z;:Q[/<C$Y&
MJUSB84^`Z0P=:[$L7X^O%8:Q,I3HP0J+?$46!#S5\W0Y?[94+-1&/+EH'EEG
M(%]VVH6OT$I.@,1.^"GA=`8414?N*HG]V?7MR=&0ZC/<K0XDX68K.9$$G4+D
MRV71N-Y4YV..E\WL6#<:1P?,4V)_?V_-9HY&WQ&+NI63;"\,5I`]F+KA$,^7
MX@1$ML2=+&2._+%0L$H8L7?C$OS=H)]0UN`)QSG\J*_R"WMGM)E`6CS@*?B:
MVQD7_.A$CSH^EH$PB7T;H/]ILP)7Q6E//Q_Q`1HIP\[P!>$1;0^6RKMZ7U"F
M/@+-):M<H+&N76(?I#Z5G478[94O=+V2D\6FRN]MYV/'F$_@*\Y*MMZLFQ%`
MU<926."\0]%8C*'6V0QDB@LC_3]+E^"FG;W4D8?M21N8O+O_A0HD&,"AKHO7
MD<B>'F%RT`2)8`$OKG/>WG`S[XT[G=VTKVJ`Q\BX#3UEFBY)Q7(A(C0[L51/
M#";Z;:OSENC1[=7N=6()/Z1(W,JE:[&3E"4(Y/8S7@LY`LAQ+_V:C.<0F2SO
MJ24(6Y8DL;_`77CHOY4%]>Y:MYV&NGVK$L/4.:=XM&@JZ2IF<KI]>'C#&A)Z
M&`IQ_IT2GN'DM'04<J$?*V3$_,'J!Q[#L3_?$!0I?3DODQ;!ITNP3W#E[WC&
M?PQW*.[W7-^R#6N(C%-_*SM-/MH/YO>($3V7DQVJ%4,@R$AM5I7IZ=6'.RNR
M%?'FWV<K'LL)`458&-`!/[B@`)<A;+`5@174A6EN)Z\6NH]V?VSH[C=/;>`E
M.R^K:B4;KF#.>1';IR@5Y$03<<6)0T86MO5SW_^\3+]A?=9W?A1TFH6B<X"`
M!O\E%41U-GY_>W=S=@EJL'#RXD:\)%DE3/J#/.J(H_%9"DN!?3^7<EYEY*Z>
M';/RB'[)2)"?V^`^S9]P38LU%OY#V&,O$CGD.MX&LL:<CITM;WOB58?04FY#
M7O2G0[G]1#G^HB7P[#O/`"-YMW<XG94YJW^0M5ICI@Y)VIJ<9LJU*GO^0X^=
MX6,*:RUG1R?A^G^W;\6/,^+NNSMK:>T@+#+@]R;Z_OGJZOQD?-ESIY/2SIWA
MQG\I=P"?:/.,D5"H^#S,HFQ</!X=:27)/U9N+Z=X;*:B-$&GJ:/FO2GQ_ED"
M4L=[5KA_,&QJZ?>WN+G4`20_R1IDG<:L@8O'X'TRG\MRCF<\K7/WQE7VYY([
MG:+(L;5>N>ZOVY._?#VY%'ZY.FV7J?K6YAIG>[8<!H6`_$E/]D_I\/"3'Q@'
MI;MNP>K%3^'WUIUT*>)FOV>K\[F6WR,>M0T$OPO0,IW/K?O=<6;TC'D`N3N/
M.5J>Z4[\VFD$>O9?3J>_DK5Y]5,@U0ME9VS1;0!^*2?_"<^%LY-JUSGYG,>Q
M_L`</"KF'-F<$?18DC?+G::;29XI7!NE!'?N-1T^O2.AR-;N]IH3YD.Y#>NY
M#=K?;_(CJ?[K^/SK":B>>PYW\<P`O,-*Q;7VB48^/P<T.UBS4]Z4@/U@@\A>
M4)K3R-Z3*`D6V>#@-"$/NSQPCFL#*2)Y<CZJ/ZEN@ZZ)K'$T(*].DN!>4AW6
MD[4[/ZDMQD.0`Z7>JO/;SS>_W@F&_K2%)ZR.^=NVNN%K^/FSQT#G\0U/^X?Q
M\6@^=L,,CJ[.KR[E;QE^VX$@,OU;C-&OJX11D=<;X`@ZY&E6/A:L/EV/'\$!
M6I=_5'VR>?,DHTQ8[_C^>._OZMK^YS_%Z[HK805"CM_X`5:[C+T_;2DFCK\"
M>/V=:10/0E>B3;._"<APM:T3G_FL#^<?4XXS?N^.&VY!7N6?28L#D]"W*Y+>
MM6V[?X@#7%XQ\A"YL-PJ11_*/D8\A['A:)'I+W69#1%_(!O+X#IP6):K5S*U
MP-R,S_V-EZZ<V_HX`KB[6)C;&'P1)O[*QT+S#-`EEFCX.55/&ZQE,JUG/^&F
M-/D%]U4G?TVV7]E"[OUX"_F=Y@@^0S<@ZSO'<@4F>"9\.=I8:SLWQ7U#VRZ_
MG-VA>T?YJ;[Q^-SAJ!&WXG."!\KM6+-\""$8B-LO:G3`(0[$'1/*`SI(LH^0
MVR_V/DJNV6WH"-D7#"S,@Y:./^H!E&,G+!?#IG22`3W][-(W[8,ZNW-UIN@`
M'[=_@R*'O>?1[A_ZMX8._5V4`?G+\./^2'V&[Z!LCD(CP]E)Z_B=\Y*W]9R#
MQUUCN:("XQ9NS;&K'>?^',?<2I&0QI38DA-<I371&3@\$7J\-9G^E1YO/`T%
M[45(UO.F]QGF<:=33/F[O"9O8I"4,@7!%U_X"+G"F(QV"$QSUW`BE4GK"ZJ/
M1$7>&=3+NCQ^[S:7:3MS/I`]#WB-X'!UDL)&ZLD,M=%6SI&KI-@>ZVIK\0&=
MM/U7XE`(4VOLGL6)4V*`4OYA'V+[K'Q9(CLP=)(YPEK/&'I:;*1&E(GN8$,.
MX+%\8I<3\5@T",[/=)P9C,O9&)]@_GI\O>.:<CV`_LU&J.';9V9AKO,9,3KV
M>=#^0L>@LXQ&S[%3=E(N74%9=BP[<D99(25U35_%=#O08#%OQ^>GLE^0:.X>
M=QQ:UMQDVD3@>%LD;D+#W+#;_2'[35S3NV-3RE1TJNF>JV*H+=[&/<T$)DYR
MU''S9*CFM*%(%4VR%*0G"%#8[<YJ6?KA>M#T>CG/'W!,H.IO;(M*4W=8MI:W
M.PA'Y#;@+G>[J>D04D(WG7-4F29L:FZAM)&SP[H8Y?.ZHZW#?2S]A_HD6W6C
M>.B("Y'IT$N@`-#Q29?3NXR.34W1[J05*Y9Y:1O.S@)0APW9D(%#(+/RJD4_
M&3Z'Z`G/#J)ZFFNW81;M[Q7I]AOTUG0XD^?;FR#<GV>]S0HZ:NH1^7)3B_LF
MZ9"E,#\U/OI5$?7Y&*L-RF=3R^]Y>Q](+F<R87K0JR#`5E\#ESMIR<HYAIBI
M>.##R_B<U9+W5TBU\L^H1LB@Z/DC5GW$KB3H+7)/7+2/O"=4(*W2.A:LW0_E
MFN#^P750.3^'=@^2I97YK9R^2%A7M/=?\?90ORN?MOP+7N/^H/6NM@MJ!Z2^
MY8;>T^37Y(RM8T?J`L0&(;>=6#^R!R.:$P9'-J9"*DJ'._X]DIZ><ML)6+5-
M9A,A9U$2-#HVP/H#A*)"9U#WOOK61QN`0SO#T"\:!&;UB_$U1-P#Y`_R]*CH
MUC:C*3[#T"?#@XT*)SG'VK0O(K)'+NT"=4+*SF4K$GKQ32A@$!B*-;DV@X8@
ME&R2_]O+G#=Q^C>Z9VW:'S?K23ZL=8:G\U)7GN(M$#B-L`&07'T<+76[30D&
MGRQ%:3-B$M;VJ9NY/Q*S><S3_@)T1UFM[78(W?94I>!A_>WMK1S1S5C`0>X0
MO5D6.[1`31VM4T8`_<(]_D,5[Q^R_?NZ_+96>H9`Q)V06^(F=#:WS.*S6EC_
M>+0$NQGCG\X>GZ-^6*G68?;;K^=%O/H!?K00U&`;*)BW#F.)]\8QXP+OPWSO
M/"/1K_SQN::SXT/JJX4;MW:?8/S1=G3;W:H"EI:B3?RXR]]RX-:IV='19V^3
MJ\N$7^C!E*,PV7=ZQ01J^F9(<$K/:5O(9OC7MOB&DWA;L*PX?.C,-YC"Z6EK
M#BWN60?2`B&'-$F7:^]TF0)R%$7I[NW`B9[,`R.NKRMTV?8`:9]E#.,D3+2$
M>YO6-#MRSK/"_!V^.<,=JT`ATF3/\0P>L2(<L_>C."90B^,.D?+(6>Q`X2*,
MWH3ET-G+FFH-SZWTN-_)FMMH)GY#Z<O9SK^YQP91Z,!88[)>*?`Z8LT\87_A
M!OOTM]*_$\O;'DJTW)O"U)SN2!>56RX90SH>$_PLUM&NEX"<L/A$1#QOG-MW
M?&Y,GL1-%W18@9Z[W4UX)O6&](@-X88_BXW6]EYM94;3VVFX4.L/XB>V12#;
M83]%=-:"=@=P>4\[(,#Z$T\M]M70V;,N4=2Q7G0&5B7'%S:SR(*K9>7->,Y[
M[''M[-LS[W);)OF_G:/F6HMB!"$V79"T/5@C=T6O>\,:Y^:..#K[8F\WG*,G
MVPQ]1WO7=8OW`JZ1IV>7EIRV1J_1C>V4;W%P@DKBF4A-XY,:_2-QA^=UG<?_
M=B[Y+>]K^`1HDU\&?4U`GP@.OE_M7P-IF3[``Q?!`<9LX1'VR&:&/<E7.[5W
M].KGW(GJ1OU,K^[,J1"WK*JY<1O$Z,4ES%^^NP/1[WB:F=@MW)J0C'_STX<A
MD-*]F$-&^VWTN[I-RZ91GVN=%9C\1-OAWX@;\'+-P19BYL;(F^?VN:L`7^Y)
M;R#!M_`.$&$EOMEP]/&CY-WQ]2XW)8B0PNWM\T'/BXTK>0'GSNX'?-?J0%#H
MWSG,(\DK8#$:H=>_#M2IF=1+;!=%/,IH^VMK^M6L2//Q^V^^6EPA-Y+?E?"G
M!#OROLB%<T?/00GBBZ;"^D:CCS`S7:>S`2[O`V'VYZ$*>U$6;%6ZI*RC=[52
MF1_?_4L<0;F<\"[(RI38;56&/4[1JR>!\B!M:`E(A]#A7!+ZL@Q&7,?C>G62
M8FA*>K#!JF].!W'>0<3[S55`1*$MA%L^#JD=O*S_ET6I1VR'5VB6"__::]7S
M!FN%K\:^&H(?\*3VWX]&`W(FD&,XCW[5-!`K`Z<`!]=Y.5!'NM"95K^._J[>
M77]@`#.P$(?J?X_4P6A??=@_4+L?#S@P/EF`+H-(F&;P?PH:O9#!AVFY<-+T
MQ_^]BCYX]0.7WOQTRB^-J%9U?C]KV"6+WCF;A$M;1]L=R2U3D*\56!9X!KQ+
M?&_7#=Z*QP:S9SB,N-2_O`FSD>A\2#<\<@5M/U[Q'J.*.L3AIBE8C]SR,14$
MAXRKO!8;S[Y_X,80H@K[06ZC*V4-^?['W,K&0Y!J2?7`-6UQ4X.BWRR=V(L/
M,@O)5'#[!?!T-I!)#51%?7JSZ.TIX2W;V8`S)>6<<C&<+0`M@_*!R3$@+#G4
MN617Y;RY;SD>."GUB"QX<W0`&`XLV,<C:5(C+?ZY#8:=IU+[LP/HA;(H;'0"
M#\W<]F)LJ'XI'XU4H];>&<9GY+A\:WRD65Z0IP.!\<`?93A9L?>51R=TK,V]
M1,?(60=GU=>XR=&-];Z[6M;W&F(HYAB_B0XK#<9DTK*,X*IEC2^3=CY@AOJU
MI".0/"CK!<]GMLC%;&8FJN7X?6U^&7%6JC-U#U'RA:UJ&#LR\M)S'=*PA`&1
M`RJ<T'FP[$#.=7&_Q*W6SH$=J6!J;H<#E?SJ7P2-2Z?2B]B;9H.]4<[D)`/U
M^>A:C=X-NF:'K,[+]5O?OU?1>7@6R_\#4$L!`A0`%`````@`W$V9*&C59TK7
M)P``1($```H``````````0`@`+:!`````&5R<F%T82YT>'102P4&``````$`
,`0`X````_R<`````
`
end


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr 25 10:37:54 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13632
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 25 Apr 2000 10:37:52 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8B50C530@standards.nortelnetworks.com>; Tue, 25 Apr 2000 10:25:14 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 13715 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Apr 2000 10:23:40 -0400
Received: from fw7.usa.alcatel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.ED258C70@standards.nortelnetworks.com>; Tue, 25 Apr 2000 10:13:39
          -0400
Received: (from uucp@localhost) by fw7.usa.alcatel.com (8.8.8+Sun/8.8.8) id
          JAA12873 for <megaco@standards.nortelnetworks.com>; Tue, 25 Apr 2000
          09:18:47 -0500 (CDT)
Received: from <Chuong.Nguyen@usa.alcatel.com> (relay1.usa.alcatel.com
          [143.209.238.6]) by fw7 via smap (V2.1) id xma012633; Tue, 25 Apr 00
          09:17:47 -0500
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1]) by
          relay1.usa.alcatel.com (8.9.3/8.9.3) with ESMTP id JAA22285 for
          <megaco@standards.nortelnetworks.com>; Tue, 25 Apr 2000 09:18:49
          -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 JAA25408 for <megaco@standards.nortelnetworks.com>; Tue, 25
          Apr 2000 09:17:57 -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 JAA00598
          for <megaco@standards.nortelnetworks.com>; Tue, 25 Apr 2000 09:17:56
          -0500 (CDT)
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <C51ED84B6F47D211917A0000F8BCBD1193B6E9@zcard00g.ca.nortel.com>
Content-Type: multipart/alternative;
              boundary="------------D72D4D6B9460997AE07949DE"
Message-ID:  <3905A913.216D6C09@usa.alcatel.com>
Date:         Tue, 25 Apr 2000 09:17:56 -0500
Reply-To: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Subject:      Re: LocalControl Descriptor
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--------------D72D4D6B9460997AE07949DE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Can signal be applied to ephermeral termination (RTP)?
Appendix A: Example Call Flows, step 20,
"An RTP termination has no events nor signals, ..."

Thanks
Chuong

Tom-PT Taylor wrote:

>
>
> The general response to your follow-up queries is that, except where a
> package specifies otherwise, signals are sent from the termination
> outwards, never inwards to the context.  See the third-last paragraph
> of sec. 7.1.11.
>
> The only reason continuity test tones would be propagated inwards
> would be because the audio stream of the termination is in receive or
> sendReceive mode.
>
>      -----Original Message-----
>      From:  Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]
>      Sent:  Monday, April 24, 2000 5:45 PM
>      To:    MEGACO@STANDARDS.NORTELNETWORKS.COM
>      Subject:       Re: LocalControl Descriptor
>
>      Thanks for the response Tom.
>
>      See comments below.
>
>      Tom-PT Taylor wrote:
>
>
>           My views below.
>
>                   -----Original Message-----
>           From:  Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]
>           Sent:  Friday, April 07, 2000 12:43 PM
>           To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
>           Subject:      LocalControl Descriptor
>
>                   Hi
>
>                   I asked this question before maybe in a different
>           but I don't think that I got a response or
>           clarification in the latest version.
>
>                   Maybe I will try again w/an example.
>
>
>                   Section 7.1.7 LocalControl Descriptor
>           "The allowed values for the mode property are send-only,
>           receive-only, send/receive,
>           inactive and loop-back.  "Send" and "receive" are with
>           respect to the exterior of the context,
>           so that, for example, a stream set to mode=sendonly does not
>           pass received media
>           into the context.  Signals and Events are not affected by
>           mode."
>
>                   If I have the following sceanrio
>
>
>
>           MG1
>           MG2                                            CO
>               ______________         ________________
>           _______________
>               |                       |
>           |                           |
>           |                             |
>               |   TDM--*--RTP  |--------|  RTP--*--TDM
>           ------|           |                 |
>               |                       |
>           |                           |
>           |                             |
>                        |------------|
>           |-------------|            |-----------|
>
>
>                   MG1 TDM termination is set to sendrecv.
>           MG1 RTP termination is set to receive only.
>
>                   MG2 TDM termination is set to inactive.
>           MG2 RTP termination is set to inactive.
>
>                   MGC sends the following transaction to MG2 to do a
>           Continuity Test:
>
>                   Transaction=1{Context=1{Modify=TDM{Signals={ct/ct},
>           Events=123{ct/cmp} }}}
>
>                   The questions that I have are (keep in mind of the
>           definition of mode and the relationship
>           of signal and mode as described in Section 7.1.7 above):
>
>                   1) Since the MG2 TDM termination mode is inactive,
>           does a ct signal get send to CO?
>                The answer should be yes since "Signals and Events are
>           not affected by mode.".
>           [PTT]  Agreed.
>
>                   2) Since the MG2 RTP termination mode is inactive,
>           does a ct signal gets propagated to
>                MG1 RTP terminaiton?
>                The answer should be no since the termination mode is
>           inactive.
>           [PTT]  Agreed.
>
>      <cnn>  This is the behavior that I would like to see but doesn't
>      this conflict w/#1 above?
>                   That is a signal is applied to TDM termination.  Is
>      this signal seen by the RTP termination?
>                   If this signal is seen by the RTP termination
>      (default topology behavior of bothway),
>                   shouldn't this signal be propagated out of the
>      context via RTP termination too
>                  since signal is not dependent on termination mode?
>
>                   Does topology, signal, event, termination/stream
>      mode have any relationships?
>
>
>
>           3) Even though MG2 TDM termination is inactive, with the
>           above transaction would I
>                still have performed a valid COT between the TDM
>           termination and CO?
>           [PTT]  Yes.  It's important to note that you have tested the
>           TDM portion of the connection only, but that is AFAIK the
>           intent of a continuity test.
>
>                   4) Does signal get propagated out of the context
>           regardless of mode via whatever terminations
>                are in the context?
>                If there is a link between 2 MGs contexts, does a
>           signal applied to MG2 termination get
>                propagate out of MG2 context and into MG1 context?
>           [PTT]  Since you're putting MG2 in the role of initiator,
>           the response from the other end gets propagated through the
>           context if the modes of the two terminations are set to
>           allow it.
>
>      <cnn>  I understand the response gets propagated through the
>      context.  But the question is, does
>                   signal applied to a TDM gets propagated
>
>           5) What does loopback really mean?  Can someone provide an
>           example?
>                 " "Send" and "receive" are with respect to the
>           exterior of the context, ...."
>                 Does loopback on a RTP termination mean that media
>           flows into the context via
>                 the RTP termination and flows back out of the
>           context.? That media does not flow
>                 into the TDM termination.  Thus that same media does
>           not flow out of context via
>                 the TDM termination.
>                 Was loopback intended for COT initiated by CO?  But
>           with the definition that signal
>                  is not affected by mode, how is loopback used with
>           COT signal?
>           [PTT]  "Loopback" mode means that the media content received
>           on a termination is reflected back along the return
>           direction.  We have not pinned down whether loopback happens
>           on the outside of the MG or whether it passes through signal
>           processors in the interior.  The difference does matter for
>           some maintenance operations, so this is an open issue.
>
>                   When it comes to continuity tests, some variants
>           require loopback at the responding end, while others require
>           generation of a different tone in the return direction from
>           the tone sent by the initiator.  In our design of the
>           package, we assumed that the MG would be aware through
>           provisioning which test variant applied to a given
>           termination.  Where loopback is required, it is implicit in
>           the invocation of ct/rsp that it should be applied to the
>           termination while the ct/rsp "signal" is active.
>
>                   Am I even approaching this COT correctly?
>
>
>
>                   Thanks
>           Chuong
>
>
>                   --
>             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 ****
>
>      --
>        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
>      ****
>
--
  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 ****



--------------D72D4D6B9460997AE07949DE
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Can signal be applied to ephermeral termination (RTP)?
<br>Appendix A: Example Call Flows, step 20,
<br>"An RTP termination has no events nor signals, ..."
<p>Thanks
<br>Chuong
<p>Tom-PT Taylor wrote:
<blockquote TYPE=CITE>&nbsp;
<p><font face="Arial"><font color="#0000FF"><font size=-1>The general response
to your follow-up queries is that, except where a package specifies otherwise,
signals are sent from the termination outwards, never inwards to the context.&nbsp;
See the third-last paragraph of sec. 7.1.11.</font></font></font>
<p><font face="Arial"><font color="#0000FF"><font size=-1>The only reason
continuity test tones would be propagated inwards would be because the
audio stream of the termination is in receive or sendReceive mode.</font></font></font>
<ul><font face="Arial"><font size=-2>-----Original Message-----</font></font>
<br><font face="Arial"><font size=-2><b>From:&nbsp; </b>Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]</font></font>
<br><font face="Arial"><font size=-2><b>Sent:&nbsp; </b>Monday, April 24,
2000 5:45 PM</font></font>
<br><font face="Arial"><font size=-2><b>To:&nbsp;&nbsp;&nbsp; </b>MEGACO@STANDARDS.NORTELNETWORKS.COM</font></font>
<br><font face="Arial"><font size=-2><b>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</b>Re: LocalControl Descriptor</font></font>
<p><font face="Arial">Thanks for the response Tom.</font>
<p><font face="Arial">See comments below.</font>
<p><font face="Arial">Tom-PT Taylor wrote:</font>
<ul>&nbsp;
<p><font face="Arial"><font color="#0000FF"><font size=-1>My views below.</font></font></font>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face="Arial"><font size=-2>-----Original
Message-----</font></font>
<br><b><font face="Arial"><font size=-2>From:&nbsp;</font></font></b> <font face="Arial"><font size=-2>Chuong
Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]</font></font>
<br><b><font face="Arial"><font size=-2>Sent:&nbsp;</font></font></b> <font face="Arial"><font size=-2>Friday,
April 07, 2000 12:43 PM</font></font>
<br><font face="Arial"><font size=-2><b>To:&nbsp;&nbsp; </b>MEGACO@STANDARDS.NORTELNETWORKS.COM</font></font>
<br><font face="Arial"><font size=-2><b>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</b>LocalControl Descriptor</font></font>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face="Arial"><font size=-1>Hi</font></font>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face="Arial"><font size=-1>I
asked this question before maybe in a different but I don't think that
I got a response or</font></font>
<br><font face="Arial"><font size=-1>clarification in the latest version.</font></font>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face="Arial"><font size=-1>Maybe
I will try again w/an example.</font></font>
<br>&nbsp;
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face="Arial"><font size=-1>Section
7.1.7 LocalControl Descriptor</font></font>
<br><font face="Arial"><font size=-1>"The allowed values for the mode property
are send-only, receive-only, send/receive,</font></font>
<br><font face="Arial"><font size=-1>inactive and loop-back.&nbsp; "Send"
and "receive" are with respect to the exterior of the context,</font></font>
<br><font face="Arial"><font size=-1>so that, for example, a stream set
to mode=sendonly does not pass received media</font></font>
<br><font face="Arial"><font size=-1>into the context.&nbsp; Signals and
Events are not affected by mode."</font></font>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face="Arial"><font size=-1>If
I have the following sceanrio</font></font>
<br>&nbsp;
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
MG1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
MG2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
CO</font></font>
<br><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp; ______________&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
________________&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
_______________</font></font>
<br><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</font></font>
<br><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; TDM--*--RTP&nbsp;
|--------|&nbsp; RTP--*--TDM ------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</font></font>
<br><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</font></font>
<br><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|-------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|-----------|</font></font>
<br>&nbsp;
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face="Arial"><font size=-1>MG1
TDM termination is set to sendrecv.</font></font>
<br><font face="Arial"><font size=-1>MG1 RTP termination is set to receive
only.</font></font>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face="Arial"><font size=-1>MG2
TDM termination is set to inactive.</font></font>
<br><font face="Arial"><font size=-1>MG2 RTP termination is set to inactive.</font></font>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face="Arial"><font size=-1>MGC
sends the following transaction to MG2 to do a Continuity Test:</font></font>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face="Arial"><font size=-1>Transaction=1{Context=1{Modify=TDM{Signals={ct/ct},
Events=123{ct/cmp} }}}</font></font>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face="Arial"><font size=-1>The
questions that I have are (keep in mind of the definition of mode and the
relationship</font></font>
<br><font face="Arial"><font size=-1>of signal and mode as described in
Section 7.1.7 above):</font></font>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face="Arial"><font size=-1>1)
Since the MG2 TDM termination mode is inactive, does a ct signal get send
to CO?</font></font>
<br><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp; The answer
should be yes since "Signals and Events are not affected by mode.".</font></font>
<br><font face="Arial"><b><i><font color="#0000FF"><font size=-1>[PTT]</font></font></i></b>&nbsp;<font color="#0000FF"><font size=-1>
Agreed.</font></font></font>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face="Arial"><font size=-1>2)
Since the MG2 RTP termination mode is inactive, does a ct signal gets propagated
to</font></font>
<br><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp; MG1 RTP terminaiton?</font></font>
<br><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp; The answer
should be no since the termination mode is inactive.</font></font>
<br><font face="Arial"><b><i><font color="#0000FF"><font size=-1>[PTT]</font></font></i></b>&nbsp;<font color="#0000FF"><font size=-1>
Agreed.</font></font></font>
<br>&nbsp;</ul>
<font face="Arial">&lt;cnn>&nbsp; This is the behavior that I would like
to see but doesn't this conflict w/#1 above?</font>
<br><font face="Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
That is a signal is applied to TDM termination.&nbsp; Is this signal seen
by the RTP termination?</font>
<br><font face="Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
If this signal is seen by the RTP termination (default topology behavior
of bothway),</font>
<br><font face="Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
shouldn't this signal be propagated out of the context via RTP termination
too</font>
<br><font face="Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
since signal is not dependent on termination mode?</font>
<p><font face="Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Does topology, signal, event, termination/stream mode have any relationships?</font>
<br>&nbsp;
<br>&nbsp;
<ul>&nbsp;
<br><font face="Arial"><font size=-1>3) Even though MG2 TDM termination
is inactive, with the above transaction would I</font></font>
<br><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp; still have
performed a valid COT between the TDM termination and CO?</font></font>
<br><font face="Arial"><b><i><font color="#0000FF"><font size=-1>[PTT]</font></font></i></b>&nbsp;<font color="#0000FF"><font size=-1>
Yes.&nbsp; It's important to note that you have tested the TDM portion
of the connection only, but that is AFAIK the intent of a continuity test.</font></font></font>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face="Arial"><font size=-1>4)
Does signal get propagated out of the context regardless of mode via whatever
terminations</font></font>
<br><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp; are in the
context?</font></font>
<br><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp; If there
is a link between 2 MGs contexts, does a signal applied to MG2 termination
get</font></font>
<br><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp; propagate
out of MG2 context and into MG1 context?</font></font>
<br><font face="Arial"><b><i><font color="#0000FF"><font size=-1>[PTT]</font></font></i></b>&nbsp;<font color="#0000FF"><font size=-1>
Since you're putting MG2 in the role of initiator, the response from the
other end gets propagated through the context if the modes of the two terminations
are set to allow it.</font></font></font>
<br>&nbsp;</ul>
<font face="Arial">&lt;cnn>&nbsp; I understand the response gets propagated
through the context.&nbsp; But the question is, does</font>
<br><font face="Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
signal applied to a TDM gets propagated</font>
<ul>&nbsp;
<br><font face="Arial"><font size=-1>5) What does loopback really mean?&nbsp;
Can someone provide an example?</font></font>
<br><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; " "Send"
and "receive" are with respect to the exterior of the context, ...."</font></font>
<br><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Does
loopback on a RTP termination mean that media flows into the context via</font></font>
<br><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the
RTP termination and flows back out of the context.? That media does not
flow</font></font>
<br><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; into
the TDM termination.&nbsp; Thus that same media does not flow out of context
via</font></font>
<br><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the
TDM termination.</font></font>
<br><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Was
loopback intended for COT initiated by CO?&nbsp; But with the definition
that signal</font></font>
<br><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
is not affected by mode, how is loopback used with COT signal?</font></font>
<br><font face="Arial"><b><i><font color="#0000FF"><font size=-1>[PTT]</font></font></i></b>&nbsp;<font color="#0000FF"><font size=-1>
"Loopback" mode means that the media content received on a termination
is reflected back along the return direction.&nbsp; We have not pinned
down whether loopback happens on the outside of the MG or whether it passes
through signal processors in the interior.&nbsp; The difference does matter
for some maintenance operations, so this is an open issue.</font></font></font>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face="Arial"><font color="#0000FF"><font size=-1>When
it comes to continuity tests, some variants require loopback at the responding
end, while others require generation of a different tone in the return
direction from the tone sent by the initiator.&nbsp; In our design of the
package, we assumed that the MG would be aware through provisioning which
test variant applied to a given termination.&nbsp; Where loopback is required,
it is implicit in the invocation of ct/rsp that it should be applied to
the termination while the ct/rsp "signal" is active.</font></font></font>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face="Arial"><font size=-1>Am
I even approaching this COT correctly?</font></font>
<br>&nbsp;
<br>&nbsp;
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face="Arial"><font size=-1>Thanks</font></font>
<br><font face="Arial"><font size=-1>Chuong</font></font>
<br>&nbsp;
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font face="Courier New"><font size=-1>--</font></font>
<br><font face="Courier New"><font size=-1>&nbsp; Alcatel USA, Inc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Internet: Chuong.Nguyen@usa.alcatel.com</font></font>
<br><font face="Courier New"><font size=-1>&nbsp; 1000 Coit Road Plano,
Texas 75075&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Phone:&nbsp;&nbsp;&nbsp; (972) 519-4613</font></font>
<br><font face="Courier New"><font size=-1>&nbsp; **** The opinions expressed
are not those of Alcatel USA, Inc ****</font></font>
<br>&nbsp;</ul>
<font face="Courier New"><font size=-1>--</font></font>
<br><font face="Courier New"><font size=-1>&nbsp; Alcatel USA, Inc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Internet: Chuong.Nguyen@usa.alcatel.com</font></font>
<br><font face="Courier New"><font size=-1>&nbsp; 1000 Coit Road Plano,
Texas 75075&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Phone:&nbsp;&nbsp;&nbsp; (972) 519-4613</font></font>
<br><font face="Courier New"><font size=-1>&nbsp; **** The opinions expressed
are not those of Alcatel USA, Inc ****</font></font></ul>
</blockquote>

<pre>--&nbsp;
&nbsp; Alcatel USA, Inc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Internet: Chuong.Nguyen@usa.alcatel.com
&nbsp; 1000 Coit Road Plano, Texas 75075&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Phone:&nbsp;&nbsp;&nbsp; (972) 519-4613
&nbsp; **** The opinions expressed are not those of Alcatel USA, Inc ****</pre>
&nbsp;</html>

--------------D72D4D6B9460997AE07949DE--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr 25 11:20:36 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16812
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 25 Apr 2000 11:20:36 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.43E58530@standards.nortelnetworks.com>; Tue, 25 Apr 2000 11:13:21 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 13805 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Apr 2000 11:11:38 -0400
Received: from chmls06.mediaone.net by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.A146C5B0@standards.nortelnetworks.com>; Tue, 25 Apr 2000 11:01:38
          -0400
Received: from mournblade (h00a0cc3c8d4b.ne.mediaone.net [24.218.118.164]) by
          chmls06.mediaone.net (8.8.7/8.8.7) with SMTP id LAA22292 for
          <MEGACO@standards.nortelnetworks.com>; Tue, 25 Apr 2000 11:07:52
          -0400 (EDT)
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_002B_01BFAEA6.8727CD40"
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:  <002e01bfaec8$0e61dcd0$a476da18@ne.mediaone.net>
Date:         Tue, 25 Apr 2000 11:08:04 -0400
Reply-To: John Meade <stormbringer@MEDIAONE.NET>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: John Meade <stormbringer@MEDIAONE.NET>
Subject:      Unsubscribe
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_002B_01BFAEA6.8727CD40
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Unsubscribe


------=_NextPart_000_002B_01BFAEA6.8727CD40
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3D"Comic Sans MS" size=3D2>Unsubscribe</FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_002B_01BFAEA6.8727CD40--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr 25 11:37:42 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17411
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 25 Apr 2000 11:37:41 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A5BA0180@standards.nortelnetworks.com>; Tue, 25 Apr 2000 11:30:24 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 13846 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Apr 2000 11:28:50 -0400
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.0816BD70@standards.nortelnetworks.com>; Tue, 25 Apr 2000 11:18:50
          -0400
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id LAA25620; Tue, 25 Apr
          2000 11:25:02 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id LAA03071; Tue, 25 Apr
          2000 11:25:04 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <2MSF6N08>; Tue, 25 Apr 2000 11:19:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFAEC9.AD2CD31E"
Message-ID:  <4FBEA8857476D311A03300204840E1CF678204@whq-msgusr-02.fore.com>
Date:         Tue, 25 Apr 2000 11:24:54 -0400
Reply-To: "Rosen, Brian" <brosen@FORE.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <brosen@FORE.COM>
Subject:      Re: LocalControl Descriptor
X-To:         Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
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_01BFAEC9.AD2CD31E
Content-Type: text/plain;
        charset="iso-8859-1"

Hmm, better fix the example.

For example (!) a terminating gateway returning ring indication to the
originating gateway
would do so on the RTP termination.  The prompt from an IVR would also do
this.

Brian

-----Original Message-----
From: Chuong Nguyen [mailto:Chuong.Nguyen@USA.ALCATEL.COM]
Sent: Tuesday, April 25, 2000 10:18 AM
To: MEGACO@standards.nortelnetworks.com
Subject: Re: LocalControl Descriptor


Can signal be applied to ephermeral termination (RTP)?
Appendix A: Example Call Flows, step 20,
"An RTP termination has no events nor signals, ..."

Thanks
Chuong


Tom-PT Taylor wrote:




The general response to your follow-up queries is that, except where a
package specifies otherwise, signals are sent from the termination outwards,
never inwards to the context.  See the third-last paragraph of sec. 7.1.11.


The only reason continuity test tones would be propagated inwards would be
because the audio stream of the termination is in receive or sendReceive
mode.


        -----Original Message-----
From:  Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]
Sent:  Monday, April 24, 2000 5:45 PM
To:    MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject:       Re: LocalControl Descriptor

        Thanks for the response Tom.


        See comments below.


        Tom-PT Taylor wrote:




        My views below.


                -----Original Message-----
From:  Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]
Sent:  Friday, April 07, 2000 12:43 PM
To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject:      LocalControl Descriptor


                Hi


                I asked this question before maybe in a different but I
don't think that I got a response or
clarification in the latest version.


                Maybe I will try again w/an example.



                Section 7.1.7 LocalControl Descriptor
"The allowed values for the mode property are send-only, receive-only,
send/receive,
inactive and loop-back.  "Send" and "receive" are with respect to the
exterior of the context,
so that, for example, a stream set to mode=sendonly does not pass received
media
into the context.  Signals and Events are not affected by mode."


                If I have the following sceanrio



                         MG1                                          MG2
CO
    ______________         ________________           _______________
    |                       |        |                           |
|                             |
    |   TDM--*--RTP  |--------|  RTP--*--TDM ------|           |
|
    |                       |        |                           |
|                             |
             |------------|                     |-------------|
|-----------|



                MG1 TDM termination is set to sendrecv.
MG1 RTP termination is set to receive only.


                MG2 TDM termination is set to inactive.
MG2 RTP termination is set to inactive.


                MGC sends the following transaction to MG2 to do a
Continuity Test:


                Transaction=1{Context=1{Modify=TDM{Signals={ct/ct},
Events=123{ct/cmp} }}}


                The questions that I have are (keep in mind of the
definition of mode and the relationship
of signal and mode as described in Section 7.1.7 above):


                1) Since the MG2 TDM termination mode is inactive, does a ct
signal get send to CO?
     The answer should be yes since "Signals and Events are not affected by
mode.".
[PTT]  Agreed.


                2) Since the MG2 RTP termination mode is inactive, does a ct
signal gets propagated to
     MG1 RTP terminaiton?
     The answer should be no since the termination mode is inactive.
[PTT]  Agreed.


        <cnn>  This is the behavior that I would like to see but doesn't
this conflict w/#1 above?
             That is a signal is applied to TDM termination.  Is this signal
seen by the RTP termination?
             If this signal is seen by the RTP termination (default topology
behavior of bothway),
             shouldn't this signal be propagated out of the context via RTP
termination too
            since signal is not dependent on termination mode?

                     Does topology, signal, event, termination/stream mode
have any relationships?





        3) Even though MG2 TDM termination is inactive, with the above
transaction would I
     still have performed a valid COT between the TDM termination and CO?
[PTT]  Yes.  It's important to note that you have tested the TDM portion of
the connection only, but that is AFAIK the intent of a continuity test.

                4) Does signal get propagated out of the context regardless
of mode via whatever terminations
     are in the context?
     If there is a link between 2 MGs contexts, does a signal applied to MG2
termination get
     propagate out of MG2 context and into MG1 context?
[PTT]  Since you're putting MG2 in the role of initiator, the response from
the other end gets propagated through the context if the modes of the two
terminations are set to allow it.


        <cnn>  I understand the response gets propagated through the
context.  But the question is, does
             signal applied to a TDM gets propagated


        5) What does loopback really mean?  Can someone provide an example?
      " "Send" and "receive" are with respect to the exterior of the
context, ...."
      Does loopback on a RTP termination mean that media flows into the
context via
      the RTP termination and flows back out of the context.? That media
does not flow
      into the TDM termination.  Thus that same media does not flow out of
context via
      the TDM termination.
      Was loopback intended for COT initiated by CO?  But with the
definition that signal
       is not affected by mode, how is loopback used with COT signal?
[PTT]  "Loopback" mode means that the media content received on a
termination is reflected back along the return direction.  We have not
pinned down whether loopback happens on the outside of the MG or whether it
passes through signal processors in the interior.  The difference does
matter for some maintenance operations, so this is an open issue.

                When it comes to continuity tests, some variants require
loopback at the responding end, while others require generation of a
different tone in the return direction from the tone sent by the initiator.
In our design of the package, we assumed that the MG would be aware through
provisioning which test variant applied to a given termination.  Where
loopback is required, it is implicit in the invocation of ct/rsp that it
should be applied to the termination while the ct/rsp "signal" is active.


                Am I even approaching this COT correctly?




                Thanks
Chuong



                --
  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 ****


        --
  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 ****

--

  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 ****



------_=_NextPart_001_01BFAEC9.AD2CD31E
Content-Type: text/html;
        charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.2919.6307" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=620072215-25042000>Hmm,
better fix the example.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=620072215-25042000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=620072215-25042000>For
example (!) a terminating gateway returning ring indication to the originating
gateway</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=620072215-25042000>would
do so on the RTP termination.&nbsp; The prompt from an IVR would also do
this.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=620072215-25042000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=620072215-25042000>Brian</SPAN></FONT></DIV>
<BLOCKQUOTE
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma
  size=2>-----Original Message-----<BR><B>From:</B> Chuong Nguyen
  [mailto:Chuong.Nguyen@USA.ALCATEL.COM]<BR><B>Sent:</B> Tuesday, April 25, 2000
  10:18 AM<BR><B>To:</B> MEGACO@standards.nortelnetworks.com<BR><B>Subject:</B>
  Re: LocalControl Descriptor<BR><BR></DIV></FONT>Can signal be applied to
  ephermeral termination (RTP)? <BR>Appendix A: Example Call Flows, step 20,
  <BR>"An RTP termination has no events nor signals, ..."
  <P>Thanks <BR>Chuong
  <P>Tom-PT Taylor wrote:
  <BLOCKQUOTE TYPE="CITE">&nbsp;
    <P><FONT face=Arial><FONT color=#0000ff><FONT size=-1>The general response
    to your follow-up queries is that, except where a package specifies
    otherwise, signals are sent from the termination outwards, never inwards to
    the context.&nbsp; See the third-last paragraph of sec.
    7.1.11.</FONT></FONT></FONT>
    <P><FONT face=Arial><FONT color=#0000ff><FONT size=-1>The only reason
    continuity test tones would be propagated inwards would be because the audio
    stream of the termination is in receive or sendReceive
    mode.</FONT></FONT></FONT>
    <UL><FONT face=Arial><FONT size=-2>-----Original
      Message-----</FONT></FONT> <BR><FONT face=Arial><FONT
      size=-2><B>From:&nbsp; </B>Chuong Nguyen
      [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]</FONT></FONT> <BR><FONT
      face=Arial><FONT size=-2><B>Sent:&nbsp; </B>Monday, April 24, 2000 5:45
      PM</FONT></FONT> <BR><FONT face=Arial><FONT
      size=-2><B>To:&nbsp;&nbsp;&nbsp;
      </B>MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT></FONT> <BR><FONT
      face=Arial><FONT size=-2><B>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      </B>Re: LocalControl Descriptor</FONT></FONT>
      <P><FONT face=Arial>Thanks for the response Tom.</FONT>
      <P><FONT face=Arial>See comments below.</FONT>
      <P><FONT face=Arial>Tom-PT Taylor wrote:</FONT>
      <UL>&nbsp;
        <P><FONT face=Arial><FONT color=#0000ff><FONT size=-1>My views
        below.</FONT></FONT></FONT>
        <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial><FONT
        size=-2>-----Original Message-----</FONT></FONT> <BR><B><FONT
        face=Arial><FONT size=-2>From:&nbsp;</FONT></FONT></B> <FONT
        face=Arial><FONT size=-2>Chuong Nguyen
        [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]</FONT></FONT> <BR><B><FONT
        face=Arial><FONT size=-2>Sent:&nbsp;</FONT></FONT></B> <FONT
        face=Arial><FONT size=-2>Friday, April 07, 2000 12:43 PM</FONT></FONT>
        <BR><FONT face=Arial><FONT size=-2><B>To:&nbsp;&nbsp;
        </B>MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT></FONT> <BR><FONT
        face=Arial><FONT size=-2><B>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        </B>LocalControl Descriptor</FONT></FONT>
        <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial><FONT
        size=-1>Hi</FONT></FONT>
        <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial><FONT
        size=-1>I asked this question before maybe in a different but I don't
        think that I got a response or</FONT></FONT> <BR><FONT face=Arial><FONT
        size=-1>clarification in the latest version.</FONT></FONT>
        <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial><FONT
        size=-1>Maybe I will try again w/an example.</FONT></FONT> <BR>&nbsp;
        <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial><FONT
        size=-1>Section 7.1.7 LocalControl Descriptor</FONT></FONT> <BR><FONT
        face=Arial><FONT size=-1>"The allowed values for the mode property are
        send-only, receive-only, send/receive,</FONT></FONT> <BR><FONT
        face=Arial><FONT size=-1>inactive and loop-back.&nbsp; "Send" and
        "receive" are with respect to the exterior of the context,</FONT></FONT>
        <BR><FONT face=Arial><FONT size=-1>so that, for example, a stream set to
        mode=sendonly does not pass received media</FONT></FONT> <BR><FONT
        face=Arial><FONT size=-1>into the context.&nbsp; Signals and Events are
        not affected by mode."</FONT></FONT>
        <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial><FONT
        size=-1>If I have the following sceanrio</FONT></FONT> <BR>&nbsp;
        <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<FONT
        face=Arial><FONT
        size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        MG1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        MG2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        CO</FONT></FONT> <BR><FONT face=Arial><FONT size=-1>&nbsp;&nbsp;&nbsp;
        ______________&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        ________________&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        _______________</FONT></FONT> <BR><FONT face=Arial><FONT
        size=-1>&nbsp;&nbsp;&nbsp;
        |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        |</FONT></FONT> <BR><FONT face=Arial><FONT size=-1>&nbsp;&nbsp;&nbsp;
        |&nbsp;&nbsp; TDM--*--RTP&nbsp; |--------|&nbsp; RTP--*--TDM
        ------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        |</FONT></FONT> <BR><FONT face=Arial><FONT size=-1>&nbsp;&nbsp;&nbsp;
        |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        |</FONT></FONT> <BR><FONT face=Arial><FONT
        size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        |------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        |-------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        |-----------|</FONT></FONT> <BR>&nbsp;
        <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial><FONT
        size=-1>MG1 TDM termination is set to sendrecv.</FONT></FONT> <BR><FONT
        face=Arial><FONT size=-1>MG1 RTP termination is set to receive
        only.</FONT></FONT>
        <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial><FONT
        size=-1>MG2 TDM termination is set to inactive.</FONT></FONT> <BR><FONT
        face=Arial><FONT size=-1>MG2 RTP termination is set to
        inactive.</FONT></FONT>
        <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial><FONT
        size=-1>MGC sends the following transaction to MG2 to do a Continuity
        Test:</FONT></FONT>
        <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial><FONT
        size=-1>Transaction=1{Context=1{Modify=TDM{Signals={ct/ct},
        Events=123{ct/cmp} }}}</FONT></FONT>
        <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial><FONT
        size=-1>The questions that I have are (keep in mind of the definition of
        mode and the relationship</FONT></FONT> <BR><FONT face=Arial><FONT
        size=-1>of signal and mode as described in Section 7.1.7
        above):</FONT></FONT>
        <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial><FONT
        size=-1>1) Since the MG2 TDM termination mode is inactive, does a ct
        signal get send to CO?</FONT></FONT> <BR><FONT face=Arial><FONT
        size=-1>&nbsp;&nbsp;&nbsp;&nbsp; The answer should be yes since "Signals
        and Events are not affected by mode.".</FONT></FONT> <BR><FONT
        face=Arial><B><I><FONT color=#0000ff><FONT
        size=-1>[PTT]</FONT></FONT></I></B>&nbsp;<FONT color=#0000ff><FONT
        size=-1> Agreed.</FONT></FONT></FONT>
        <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial><FONT
        size=-1>2) Since the MG2 RTP termination mode is inactive, does a ct
        signal gets propagated to</FONT></FONT> <BR><FONT face=Arial><FONT
        size=-1>&nbsp;&nbsp;&nbsp;&nbsp; MG1 RTP terminaiton?</FONT></FONT>
        <BR><FONT face=Arial><FONT size=-1>&nbsp;&nbsp;&nbsp;&nbsp; The answer
        should be no since the termination mode is inactive.</FONT></FONT>
        <BR><FONT face=Arial><B><I><FONT color=#0000ff><FONT
        size=-1>[PTT]</FONT></FONT></I></B>&nbsp;<FONT color=#0000ff><FONT
        size=-1> Agreed.</FONT></FONT></FONT> <BR>&nbsp;</P></UL><FONT
      face=Arial>&lt;cnn&gt;&nbsp; This is the behavior that I would like to see
      but doesn't this conflict w/#1 above?</FONT> <BR><FONT
      face=Arial>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      That is a signal is applied to TDM termination.&nbsp; Is this signal seen
      by the RTP termination?</FONT> <BR><FONT
      face=Arial>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      If this signal is seen by the RTP termination (default topology behavior
      of bothway),</FONT> <BR><FONT
      face=Arial>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      shouldn't this signal be propagated out of the context via RTP termination
      too</FONT> <BR><FONT
      face=Arial>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      since signal is not dependent on termination mode?</FONT>
      <P><FONT
      face=Arial>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      Does topology, signal, event, termination/stream mode have any
      relationships?</FONT> <BR>&nbsp; <BR>&nbsp;
      <UL> <BR><FONT face=Arial><FONT size=-1>3) Even though MG2 TDM
        termination is inactive, with the above transaction would
        I</FONT></FONT> <BR><FONT face=Arial><FONT
        size=-1>&nbsp;&nbsp;&nbsp;&nbsp; still have performed a valid COT
        between the TDM termination and CO?</FONT></FONT> <BR><FONT
        face=Arial><B><I><FONT color=#0000ff><FONT
        size=-1>[PTT]</FONT></FONT></I></B>&nbsp;<FONT color=#0000ff><FONT
        size=-1> Yes.&nbsp; It's important to note that you have tested the TDM
        portion of the connection only, but that is AFAIK the intent of a
        continuity test.</FONT></FONT></FONT>
        <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial><FONT
        size=-1>4) Does signal get propagated out of the context regardless of
        mode via whatever terminations</FONT></FONT> <BR><FONT face=Arial><FONT
        size=-1>&nbsp;&nbsp;&nbsp;&nbsp; are in the context?</FONT></FONT>
        <BR><FONT face=Arial><FONT size=-1>&nbsp;&nbsp;&nbsp;&nbsp; If there is
        a link between 2 MGs contexts, does a signal applied to MG2 termination
        get</FONT></FONT> <BR><FONT face=Arial><FONT
        size=-1>&nbsp;&nbsp;&nbsp;&nbsp; propagate out of MG2 context and into
        MG1 context?</FONT></FONT> <BR><FONT face=Arial><B><I><FONT
        color=#0000ff><FONT size=-1>[PTT]</FONT></FONT></I></B>&nbsp;<FONT
        color=#0000ff><FONT size=-1> Since you're putting MG2 in the role of
        initiator, the response from the other end gets propagated through the
        context if the modes of the two terminations are set to allow
        it.</FONT></FONT></FONT> <BR>&nbsp;</P></UL><FONT
      face=Arial>&lt;cnn&gt;&nbsp; I understand the response gets propagated
      through the context.&nbsp; But the question is, does</FONT> <BR><FONT
      face=Arial>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      signal applied to a TDM gets propagated</FONT>
      <UL> <BR><FONT face=Arial><FONT size=-1>5) What does loopback really
        mean?&nbsp; Can someone provide an example?</FONT></FONT> <BR><FONT
        face=Arial><FONT size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; " "Send" and
        "receive" are with respect to the exterior of the context,
        ...."</FONT></FONT> <BR><FONT face=Arial><FONT
        size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Does loopback on a RTP
        termination mean that media flows into the context via</FONT></FONT>
        <BR><FONT face=Arial><FONT size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the
        RTP termination and flows back out of the context.? That media does not
        flow</FONT></FONT> <BR><FONT face=Arial><FONT
        size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; into the TDM termination.&nbsp;
        Thus that same media does not flow out of context via</FONT></FONT>
        <BR><FONT face=Arial><FONT size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the
        TDM termination.</FONT></FONT> <BR><FONT face=Arial><FONT
        size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Was loopback intended for COT
        initiated by CO?&nbsp; But with the definition that signal</FONT></FONT>
        <BR><FONT face=Arial><FONT size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        is not affected by mode, how is loopback used with COT
        signal?</FONT></FONT> <BR><FONT face=Arial><B><I><FONT
        color=#0000ff><FONT size=-1>[PTT]</FONT></FONT></I></B>&nbsp;<FONT
        color=#0000ff><FONT size=-1> "Loopback" mode means that the media
        content received on a termination is reflected back along the return
        direction.&nbsp; We have not pinned down whether loopback happens on the
        outside of the MG or whether it passes through signal processors in the
        interior.&nbsp; The difference does matter for some maintenance
        operations, so this is an open issue.</FONT></FONT></FONT>
        <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial><FONT
        color=#0000ff><FONT size=-1>When it comes to continuity tests, some
        variants require loopback at the responding end, while others require
        generation of a different tone in the return direction from the tone
        sent by the initiator.&nbsp; In our design of the package, we assumed
        that the MG would be aware through provisioning which test variant
        applied to a given termination.&nbsp; Where loopback is required, it is
        implicit in the invocation of ct/rsp that it should be applied to the
        termination while the ct/rsp "signal" is active.</FONT></FONT></FONT>
        <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial><FONT
        size=-1>Am I even approaching this COT correctly?</FONT></FONT>
        <BR>&nbsp; <BR>&nbsp;
        <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=Arial><FONT
        size=-1>Thanks</FONT></FONT> <BR><FONT face=Arial><FONT
        size=-1>Chuong</FONT></FONT> <BR>&nbsp;
        <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT
        face="Courier New"><FONT size=-1>--</FONT></FONT> <BR><FONT
        face="Courier New"><FONT size=-1>&nbsp; Alcatel USA,
        Inc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        Internet: Chuong.Nguyen@usa.alcatel.com</FONT></FONT> <BR><FONT
        face="Courier New"><FONT size=-1>&nbsp; 1000 Coit Road Plano, Texas
        75075&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        Phone:&nbsp;&nbsp;&nbsp; (972) 519-4613</FONT></FONT> <BR><FONT
        face="Courier New"><FONT size=-1>&nbsp; **** The opinions expressed are
        not those of Alcatel USA, Inc ****</FONT></FONT> <BR>&nbsp;</P></UL><FONT
      face="Courier New"><FONT size=-1>--</FONT></FONT> <BR><FONT
      face="Courier New"><FONT size=-1>&nbsp; Alcatel USA,
      Inc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      Internet: Chuong.Nguyen@usa.alcatel.com</FONT></FONT> <BR><FONT
      face="Courier New"><FONT size=-1>&nbsp; 1000 Coit Road Plano, Texas
      75075&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
      Phone:&nbsp;&nbsp;&nbsp; (972) 519-4613</FONT></FONT> <BR><FONT
      face="Courier New"><FONT size=-1>&nbsp; **** The opinions expressed are
      not those of Alcatel USA, Inc ****</FONT></FONT></UL></BLOCKQUOTE><PRE>--&nbsp;
&nbsp; Alcatel USA, Inc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Internet: Chuong.Nguyen@usa.alcatel.com
&nbsp; 1000 Coit Road Plano, Texas 75075&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Phone:&nbsp;&nbsp;&nbsp; (972) 519-4613
&nbsp; **** The opinions expressed are not those of Alcatel USA, Inc ****</PRE>&nbsp;
</BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01BFAEC9.AD2CD31E--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Apr 25 12:12:32 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18520
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 25 Apr 2000 12:12:32 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8DB560C0@standards.nortelnetworks.com>; Tue, 25 Apr 2000 12:05:31 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 13944 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Apr 2000 12:03:34 -0400
Received: from smtprich.nortel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.47FD5330@standards.nortelnetworks.com>; Tue, 25 Apr 2000 12:03:34
          -0400
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprich.nortel.com; Tue, 25 Apr 2000 10:01:38 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <JSPA3A0C>; Tue, 25 Apr 2000 10:00:24 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B703@zcard00g.ca.nortel.com>
Date:         Tue, 25 Apr 2000 10:00:23 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: LocalControl Descriptor
X-To:         Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Certainly.  Consider especially the possibility of AVT-Tones to ship in-band
signalling.  Looks like the quoted step should be fixed up.

> -----Original Message-----
> From: Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]
> Sent: Tuesday, April 25, 2000 10:18 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: LocalControl Descriptor
>
> Can signal be applied to ephermeral termination (RTP)?
> Appendix A: Example Call Flows, step 20,
> "An RTP termination has no events nor signals, ..."
>
> Thanks
> Chuong
>
> Tom-PT Taylor wrote:
>
>
>
>       The general response to your follow-up queries is that, except where
> a package specifies otherwise, signals are sent from the termination
> outwards, never inwards to the context.  See the third-last paragraph of
> sec. 7.1.11.
>
>       The only reason continuity test tones would be propagated inwards
> would be because the audio stream of the termination is in receive or
> sendReceive mode.
>
>               -----Original Message-----
>       From:  Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]
>       Sent:  Monday, April 24, 2000 5:45 PM
>       To:    MEGACO@STANDARDS.NORTELNETWORKS.COM
>       Subject:       Re: LocalControl Descriptor
>
>               Thanks for the response Tom.
>
>               See comments below.
>
>               Tom-PT Taylor wrote:
>
>
>
>                       My views below.
>
>                               -----Original Message-----
>               From:  Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]
>               Sent:  Friday, April 07, 2000 12:43 PM
>               To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
>               Subject:      LocalControl Descriptor
>
>                               Hi
>
>                               I asked this question before maybe in a
> different but I don't think that I got a response or
>               clarification in the latest version.
>
>                               Maybe I will try again w/an example.
>
>
>                               Section 7.1.7 LocalControl Descriptor
>               "The allowed values for the mode property are send-only,
> receive-only, send/receive,
>               inactive and loop-back.  "Send" and "receive" are with
> respect to the exterior of the context,
>               so that, for example, a stream set to mode=sendonly does not
> pass received media
>               into the context.  Signals and Events are not affected by
> mode."
>
>                               If I have the following sceanrio
>
>
>                                        MG1
> MG2                                            CO
>                   ______________         ________________
> _______________
>                   |                       |        |
> |            |                             |
>                   |   TDM--*--RTP  |--------|  RTP--*--TDM ------|
> |                 |
>                   |                       |        |
> |            |                             |
>                            |------------|
> |-------------|            |-----------|
>
>
>                               MG1 TDM termination is set to sendrecv.
>               MG1 RTP termination is set to receive only.
>
>                               MG2 TDM termination is set to inactive.
>               MG2 RTP termination is set to inactive.
>
>                               MGC sends the following transaction to MG2
> to do a Continuity Test:
>
>
> Transaction=1{Context=1{Modify=TDM{Signals={ct/ct}, Events=123{ct/cmp} }}}
>
>
>                               The questions that I have are (keep in mind
> of the definition of mode and the relationship
>               of signal and mode as described in Section 7.1.7 above):
>
>                               1) Since the MG2 TDM termination mode is
> inactive, does a ct signal get send to CO?
>                    The answer should be yes since "Signals and Events are
> not affected by mode.".
>               [PTT]  Agreed.
>
>                               2) Since the MG2 RTP termination mode is
> inactive, does a ct signal gets propagated to
>                    MG1 RTP terminaiton?
>                    The answer should be no since the termination mode is
> inactive.
>               [PTT]  Agreed.
>
>
>               <cnn>  This is the behavior that I would like to see but
> doesn't this conflict w/#1 above?
>                    That is a signal is applied to TDM termination.  Is
> this signal seen by the RTP termination?
>                    If this signal is seen by the RTP termination (default
> topology behavior of bothway),
>                    shouldn't this signal be propagated out of the context
> via RTP termination too
>                   since signal is not dependent on termination mode?
>
>                            Does topology, signal, event,
> termination/stream mode have any relationships?
>
>
>
>
>               3) Even though MG2 TDM termination is inactive, with the
> above transaction would I
>                    still have performed a valid COT between the TDM
> termination and CO?
>               [PTT]  Yes.  It's important to note that you have tested the
> TDM portion of the connection only, but that is AFAIK the intent of a
> continuity test.
>
>                               4) Does signal get propagated out of the
> context regardless of mode via whatever terminations
>                    are in the context?
>                    If there is a link between 2 MGs contexts, does a
> signal applied to MG2 termination get
>                    propagate out of MG2 context and into MG1 context?
>               [PTT]  Since you're putting MG2 in the role of initiator,
> the response from the other end gets propagated through the context if the
> modes of the two terminations are set to allow it.
>
>
>               <cnn>  I understand the response gets propagated through the
> context.  But the question is, does
>                    signal applied to a TDM gets propagated
>
>
>               5) What does loopback really mean?  Can someone provide an
> example?
>                     " "Send" and "receive" are with respect to the
> exterior of the context, ...."
>                     Does loopback on a RTP termination mean that media
> flows into the context via
>                     the RTP termination and flows back out of the
> context.? That media does not flow
>                     into the TDM termination.  Thus that same media does
> not flow out of context via
>                     the TDM termination.
>                     Was loopback intended for COT initiated by CO?  But
> with the definition that signal
>                      is not affected by mode, how is loopback used with
> COT signal?
>               [PTT]  "Loopback" mode means that the media content received
> on a termination is reflected back along the return direction.  We have
> not pinned down whether loopback happens on the outside of the MG or
> whether it passes through signal processors in the interior.  The
> difference does matter for some maintenance operations, so this is an open
> issue.
>
>                               When it comes to continuity tests, some
> variants require loopback at the responding end, while others require
> generation of a different tone in the return direction from the tone sent
> by the initiator.  In our design of the package, we assumed that the MG
> would be aware through provisioning which test variant applied to a given
> termination.  Where loopback is required, it is implicit in the invocation
> of ct/rsp that it should be applied to the termination while the ct/rsp
> "signal" is active.
>
>                               Am I even approaching this COT correctly?
>
>
>
>                               Thanks
>               Chuong
>
>
>                               --
>                 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 ****
>
>
>               --
>         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 ****
>
> --
>   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  Tue Apr 25 17:26:11 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26420
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 25 Apr 2000 17:26:10 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6497B270@standards.nortelnetworks.com>; Tue, 25 Apr 2000 17:19:20 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 14538 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Apr 2000 17:18:09 -0400
Received: from auemlsrv.firewall.lucent.com (192.11.223.161) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.3A5425C0@standards.nortelnetworks.com>; Tue, 25 Apr 2000
          17:18:09 -0400
Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by
          auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id RAA04734
          for <MEGACO@standards.nortelnetworks.com>; Tue, 25 Apr 2000 17:24:24
          -0400 (EDT)
Received: from ihgp2.ih.lucent.com (h135-1-53-26.lucent.com [135.1.53.26]) by
          auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id RAA04719
          for <MEGACO@standards.nortelnetworks.com>; Tue, 25 Apr 2000 17:24:23
          -0400 (EDT)
Received: by ihgp2.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA18112; Tue, 25
          Apr 2000 16:24:22 -0500 (CDT)
Received: from il0015varney2 by ihgp2.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id
          QAA18102; Tue, 25 Apr 2000 16:24:18 -0500 (CDT)
X-Sender: varney@ihgp2.ih.lucent.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Message-ID:  <4.2.2.20000425104737.00b0d5c0@ihgp2.ih.lucent.com>
Date:         Tue, 25 Apr 2000 16:24:13 -0500
Reply-To: Al Varney <varney@LUCENT.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Al Varney <varney@LUCENT.COM>
Subject:      Re: E.10.3 Signals (Basic Continuity Package)
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <C51ED84B6F47D211917A0000F8BCBD1193B6F1@zcard00g.ca.nortel. com>

<html>
At 02:14 04/25/2000 -0400, Tom-PT Taylor wrote:<br>
<blockquote type=cite cite>&gt; From: Chuong Nguyen
[SMTP:Chuong.Nguyen@USA.ALCATEL.COM]<br>
&gt; Sent: Monday, April 03, 2000 5:45 PM</blockquote><br>
<blockquote type=cite cite>&gt; The Respond SignalID: rsp (0x004)&nbsp;
has a Signal Type of Timeout.<br>
&gt;<br>
&gt; Looking at Section 10.5,<br>
&gt; &quot;Upon reception of a command with the rsp signal, the MG<br>
&gt; awaits reception of the continuity test tone.&nbsp; When the tone is
received<br>
&gt; before the rsp signal times out, the MG returns the applicable
return<br>
&gt; tone.&quot;<br>
&gt;<br>
&gt; What is the duration of this Respond Signal?&nbsp; The text seems to
imply that<br>
&gt; the Signal Type is<br>
&gt; Timeout but it is used to timeout the reception of the continuity
test<br>
&gt; tone.<br>
&gt; Is the intend that the Respond Signal has the same duration as the
Timeout<br>
&gt; for the detection of<br>
&gt; the continuity test tone?<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [PTT]<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I'd like someone to confirm
the correctness of the procedure as<br>
quoted.&nbsp; My understanding of continuity testing varies on two
points:<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - sometimes the
responder just does a loopback rather than<br>
detecting a tone and playing out another<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - the responder
continues to respond until told by the MGC to stop.<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Am I wrong?</blockquote><br>
&nbsp;&nbsp; For ISUP/TUP continuity testing, there are two
procedures:<br>
Case 1:&nbsp; A 4-wire test described in Q.764, Section 7<br>
Case 2:&nbsp; A 2-wire test described in Q.764, Section 8<br>
<br>
&nbsp;&nbsp; You are correct on both &quot;-&quot; items above, but so is
the quoted procedure, with some interpretation.&nbsp; In Case 1, the
tested switch (doing ct/rsp) only needs a loop-back (called a
&quot;check-loop&quot; in Q.724).&nbsp; In Case 2, the tested switch must
recognize the incoming test tone and return one of a different
frequency.&nbsp; Specifically, the outgoing tone is ON whenever the
incoming tone is ON, and OFF otherwise.&nbsp; This can occur multiple
times during one test.&nbsp; In effect, the return tone
&quot;emulates&quot; a loop-back, only shifting the test frequency.<br>
<br>
&nbsp;&nbsp; Note that in either Case, the testing switch (the one doing
ct/ct in Megaco) is the one that determines test timing, duration and
success/failure.&nbsp; The tested switch should not attempt to do
anything other than reflect back what is received.&nbsp; Because of glare
considerations, the national option of detecting both the presence of a
returned tone and the removal of a returned tone is often used.&nbsp;
That is why the return tone in Case 2 must be removed whenever the
incoming test tone is not being detected.<br>
<br>
<blockquote type=cite cite>&gt; If the Respond Signal duration is
TimeOut, MGC gets indication from<br>
&gt; Central Office that<br>
&gt; COT test successful, should MGC sends a Modify to stop the Respond
Signal<br>
&gt; or<br>
&gt; just let it play until Timeout?<br>
&gt; If let it plays until Timeout, will or should MG sends Notify w/COT
failed<br>
&gt; due to Timeout of<br>
&gt; Respond Signal?<br>
&gt;<br>
&gt; Or should the Respond Signal be Brief or ON/OFF?<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [PTT]<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If it is correct that the
responder continues running the test until<br>
call signalling indicates that it can stop, then no timeout is needed
and<br>
the rsp signal should be ON/OFF.<br>
</blockquote><br>
&nbsp;&nbsp; That's how it works in ISUP PSTN switches today.&nbsp;
Whether initiated by an IAM (indicating &quot;continuity check required
on this circuit&quot;) or by a CCR, the receiving MGC will be running
ISUP timer T8 or T36, waiting for the sending switch to send a COT or
other message to end the test.&nbsp; So there is no need to actually have
a timer on the &quot;ct/rsp signal&quot; -- in fact, there are may be
good reasons to leave a loop-back in place for a long period of
time.&nbsp; On the other hand, there are no OnOff Signal Types anywhere
else in Annex E, so a (long) timer could just insure the MGC didn't
forget about the termination....<br>
<br>
&nbsp;&nbsp; I suggest a clarified version of the referenced paragraph in
E.10.5, with the ct/rsp Signal Type changed to OnOff :<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp; &quot;When a MGC wants the MG to respond to a
continuity test, it sends<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a command to the MG containing a signals
descriptor with the rsp<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; signal. Upon reception of a command with
the rsp signal, the MG<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; either applies a loop-back or (for 2-wire
circuits) awaits reception<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of a continuity test tone.&nbsp; In the
loop-back case, any incoming<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; information shall be reflected back as
outgoing information.&nbsp; In the<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2-wire case, any time the appropriate test
tone is received, the<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; appropriate response tone should be
sent.&nbsp; The MGC will determine<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; when to remove the rsp signal.<br>
<br>
&nbsp;&nbsp; The current version of E.10 is much improved, but it did
result in dropping all references to Q.724.&nbsp; Rather than add in a
lot more text to explain &quot;2-wire&quot;, etc., why not add back in a
(&quot;See Q.724 Sections 7 and 8 for further information.&quot;) at the
end?<br>
<br>
&nbsp;&nbsp; One last note -- Telcordia's GR-317 has a better (IMHO)
description of the continuity test procedure.&nbsp; It also indicates the
desirability of performing the &quot;2-wire&quot; test even on 4-wire
circuits, since it will detect instances where digital transmission
facilities have been inadvertently left in a loop-back mode.&nbsp; So
don't ignore Case 2 above just because an MG may only be connecting to
4-wire circuits.<br>
<br>
Al Varney - Lucent Technologies&nbsp; +1 630 224-7493&nbsp;&nbsp;&nbsp;
varney@lucent.com
</html>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Apr 26 00:27:23 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07485
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 26 Apr 2000 00:27:22 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.39B7BCE0@standards.nortelnetworks.com>; Wed, 26 Apr 2000 0:20:28 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 15387 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Apr 2000 00:18:46 -0400
Received: from ish7.ericsson.com.au (203.61.155.111) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.95A28A00@standards.nortelnetworks.com>; Wed, 26 Apr 2000
          0:08:43 -0400
Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id OAA24194; Wed,
          26 Apr 2000 14:13:51 +1000 (EST)
Received: from mcsi00.epa.ericsson.se (mcsi00 [146.11.8.201]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id OAA20555; Wed, 26
          Apr 2000 14:14:14 +1000 (EST)
Received: from ericsson.com (mcdh183.epa.ericsson.se [146.11.81.183]) by
          mcsi00.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id OAA11147; Wed,
          26 Apr 2000 14:14:01 +1000 (EST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <C51ED84B6F47D211917A0000F8BCBD1193B6F7@zcard00g.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39066CF3.68BF6AFA@ericsson.com>
Date:         Wed, 26 Apr 2000 14:13:39 +1000
Reply-To: Christian Groves <Christian.Groves@ERICSSON.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Christian Groves <Christian.Groves@ERICSSON.COM>
Subject:      Re: clarification
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Tom,

I agree the modem descriptor seems out of place and probably isn't
needed. However can we really deprecate this in H248v2 and be backwards
compatible?

Cheers, Christian

Tom-PT Taylor wrote:
>
> This is a leftover from Santiago, when we firmed up the set of
> descriptors needed to describe a termination.  Mike Buckley had an
> insight: let the descriptors form a hierarchy, describing the
> termination from the physical layer upwards.  We didn't really follow
> through on that thought, but the modem descriptor got left in the
> schema more or less through oversight.  It's a bit late to delete it,
> but maybe in H.248v2 it could be deprecated and replaced by a property
> in another descriptor.
>
>      -----Original Message-----
>      From:   Marc Mathew [SMTP:marc_mathew@MAILCITY.COM]
>      Sent:   Thursday, April 06, 2000 8:06 AM
>      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
>      Subject:        clarification
>
>      Hi,
>
>         Can anyone please tell me what modem descriptor is used for.
>      Should modem not be specified as a seperate package (NAS ?).
>      Isn't modem a different kind of termination. Why is there a
>      seperate descriptor for it.
>
>      Always,
>      Marc
>
>      Send FREE April Fool's Greetings to your friends!
>      http://www.whowhere.lycos.com/redirects/American_Greetings.rdct


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Apr 26 00:30:28 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07612
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 26 Apr 2000 00:30:27 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A64A89A0@standards.nortelnetworks.com>; Wed, 26 Apr 2000 0:23:30 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 15393 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Apr 2000 00:21:33 -0400
Received: from ish7.ericsson.com.au (203.61.155.111) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.F995B280@standards.nortelnetworks.com>; Wed, 26 Apr 2000
          0:11:31 -0400
Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id OAA24426; Wed,
          26 Apr 2000 14:16:29 +1000 (EST)
Received: from mcsi00.epa.ericsson.se (mcsi00 [146.11.8.201]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id OAA20865; Wed, 26
          Apr 2000 14:16:51 +1000 (EST)
Received: from ericsson.com (mcdh183.epa.ericsson.se [146.11.81.183]) by
          mcsi00.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id OAA11191; Wed,
          26 Apr 2000 14:16:37 +1000 (EST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <C51ED84B6F47D211917A0000F8BCBD1193B6E9@zcard00g.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39066D8E.80EC421D@ericsson.com>
Date:         Wed, 26 Apr 2000 14:16:14 +1000
Reply-To: Christian Groves <Christian.Groves@ERICSSON.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Christian Groves <Christian.Groves@ERICSSON.COM>
Subject:      Re: LocalControl Descriptor
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Tom,

The only other way would be if the direction was specified in a package.
The protocol spec says direction is outward unless specified in a
package.

Cheers, Christian

Tom-PT Taylor wrote:
>
> The general response to your follow-up queries is that, except where a
> package specifies otherwise, signals are sent from the termination outwards,
> never inwards to the context.  See the third-last paragraph of sec. 7.1.11.
>
> The only reason continuity test tones would be propagated inwards would be
> because the audio stream of the termination is in receive or sendReceive
> mode.
>
> > -----Original Message-----
> > From: Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]
> > Sent: Monday, April 24, 2000 5:45 PM
> > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject:      Re: LocalControl Descriptor
> >
> > Thanks for the response Tom.
> >
> > See comments below.
> >
> > Tom-PT Taylor wrote:
> >
> >
> >
> >       My views below.
> >
> >               -----Original Message-----
> >       From:  Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]
> >       Sent:  Friday, April 07, 2000 12:43 PM
> >       To:    MEGACO@STANDARDS.NORTELNETWORKS.COM
> >       Subject:       LocalControl Descriptor
> >
> >               Hi
> >
> >               I asked this question before maybe in a different but I
> > don't think that I got a response or
> >       clarification in the latest version.
> >
> >               Maybe I will try again w/an example.
> >
> >
> >               Section 7.1.7 LocalControl Descriptor
> >       "The allowed values for the mode property are send-only,
> > receive-only, send/receive,
> >       inactive and loop-back.  "Send" and "receive" are with respect to
> > the exterior of the context,
> >       so that, for example, a stream set to mode=sendonly does not pass
> > received media
> >       into the context.  Signals and Events are not affected by mode."
> >
> >               If I have the following sceanrio
> >
> >
> >                        MG1                                          MG2
> > CO
> >           ______________         ________________
> > _______________
> >           |                       |        |                           |
> > |                             |
> >           |   TDM--*--RTP  |--------|  RTP--*--TDM ------|           |
> > |
> >           |                       |        |                           |
> > |                             |
> >                    |------------|                     |-------------|
> > |-----------|
> >
> >
> >               MG1 TDM termination is set to sendrecv.
> >       MG1 RTP termination is set to receive only.
> >
> >               MG2 TDM termination is set to inactive.
> >       MG2 RTP termination is set to inactive.
> >
> >               MGC sends the following transaction to MG2 to do a
> > Continuity Test:
> >
> >               Transaction=1{Context=1{Modify=TDM{Signals={ct/ct},
> > Events=123{ct/cmp} }}}
> >
> >               The questions that I have are (keep in mind of the
> > definition of mode and the relationship
> >       of signal and mode as described in Section 7.1.7 above):
> >
> >               1) Since the MG2 TDM termination mode is inactive, does a ct
> > signal get send to CO?
> >            The answer should be yes since "Signals and Events are not
> > affected by mode.".
> >       [PTT]  Agreed.
> >
> >               2) Since the MG2 RTP termination mode is inactive, does a ct
> > signal gets propagated to
> >            MG1 RTP terminaiton?
> >            The answer should be no since the termination mode is inactive.
> >
> >       [PTT]  Agreed.
> >
> >
> > <cnn>  This is the behavior that I would like to see but doesn't this
> > conflict w/#1 above?
> >              That is a signal is applied to TDM termination.  Is this
> > signal seen by the RTP termination?
> >              If this signal is seen by the RTP termination (default
> > topology behavior of bothway),
> >              shouldn't this signal be propagated out of the context via
> > RTP termination too
> >             since signal is not dependent on termination mode?
> >
> >              Does topology, signal, event, termination/stream mode have
> > any relationships?
> >
> >
> >
> >
> >       3) Even though MG2 TDM termination is inactive, with the above
> > transaction would I
> >            still have performed a valid COT between the TDM termination
> > and CO?
> >       [PTT]  Yes.  It's important to note that you have tested the TDM
> > portion of the connection only, but that is AFAIK the intent of a
> > continuity test.
> >
> >               4) Does signal get propagated out of the context regardless
> > of mode via whatever terminations
> >            are in the context?
> >            If there is a link between 2 MGs contexts, does a signal
> > applied to MG2 termination get
> >            propagate out of MG2 context and into MG1 context?
> >       [PTT]  Since you're putting MG2 in the role of initiator, the
> > response from the other end gets propagated through the context if the
> > modes of the two terminations are set to allow it.
> >
> >
> > <cnn>  I understand the response gets propagated through the context.  But
> > the question is, does
> >              signal applied to a TDM gets propagated
> >
> >
> >       5) What does loopback really mean?  Can someone provide an example?
> >             " "Send" and "receive" are with respect to the exterior of the
> > context, ...."
> >             Does loopback on a RTP termination mean that media flows into
> > the context via
> >             the RTP termination and flows back out of the context.? That
> > media does not flow
> >             into the TDM termination.  Thus that same media does not flow
> > out of context via
> >             the TDM termination.
> >             Was loopback intended for COT initiated by CO?  But with the
> > definition that signal
> >              is not affected by mode, how is loopback used with COT
> > signal?
> >       [PTT]  "Loopback" mode means that the media content received on a
> > termination is reflected back along the return direction.  We have not
> > pinned down whether loopback happens on the outside of the MG or whether
> > it passes through signal processors in the interior.  The difference does
> > matter for some maintenance operations, so this is an open issue.
> >
> >               When it comes to continuity tests, some variants require
> > loopback at the responding end, while others require generation of a
> > different tone in the return direction from the tone sent by the
> > initiator.  In our design of the package, we assumed that the MG would be
> > aware through provisioning which test variant applied to a given
> > termination.  Where loopback is required, it is implicit in the invocation
> > of ct/rsp that it should be applied to the termination while the ct/rsp
> > "signal" is active.
> >
> >               Am I even approaching this COT correctly?
> >
> >
> >
> >               Thanks
> >       Chuong
> >
> >
> >               --
> >         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 ****
> >
> >
> >
> > --
> >   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 Apr 26 00:48:42 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07920
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 26 Apr 2000 00:48:42 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.312557B0@standards.nortelnetworks.com>; Wed, 26 Apr 2000 0:41:42 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 15511 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Apr 2000 00:40:03 -0400
Received: from ish7.ericsson.com.au (203.61.155.111) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.87F365C0@standards.nortelnetworks.com>; Wed, 26 Apr 2000
          0:29:49 -0400
Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id OAA25690; Wed,
          26 Apr 2000 14:34:07 +1000 (EST)
Received: from mcsi00.epa.ericsson.se (mcsi00 [146.11.8.201]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id OAA22900; Wed, 26
          Apr 2000 14:34:30 +1000 (EST)
Received: from ericsson.com (mcdh183.epa.ericsson.se [146.11.81.183]) by
          mcsi00.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id OAA11386; Wed,
          26 Apr 2000 14:34:18 +1000 (EST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF6781E2@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <390671B2.E81DF994@ericsson.com>
Date:         Wed, 26 Apr 2000 14:33:54 +1000
Reply-To: Christian Groves <Christian.Groves@ERICSSON.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Christian Groves <Christian.Groves@ERICSSON.COM>
Subject:      Re: Multiple streams per call,
X-To:         "Rosen, Brian" <brosen@FORE.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

I like the 'elegant method'. I thought that context properties could be
used in the situations where the elegant didn't work. This I thought
would be the most generic.

I agree that using the 'internal' termination model is a valid modelling
technique but I wonder if it is more uniform. ie. Conferences today are
handled by context but we could equally have a context with a mixing
termination and then hang off individual context and terminations for
the subscriber legs.

I think this is something for discussion for v2, either approach is
interesting.

Cheers, Christian

"Rosen, Brian" wrote:
>
> This is beyond the current discussion.  The question is, in general,
> how do we model devices that are "different".  In the case cited,
> media translation, we could model it as a two termination context,
> with the RTP flows, specified by media descriptors, describing the
> two sides, and an implicit translation in between.  This certainly
> works, and is pretty elegant.
>
> The problem is that it doesn't work for all kinds of devices,
> and I wondered if we should model them in a more uniform way.  I
> suggested a set of two termination contexts with an "internal"
> termination that can have characteristics ascribed to it by a
> set of packages implemented on it, and an RTP termination that
> had the external flow on it.  This would also work for the translator,
> but requires more terminations and more contexts, and thus is
> somewhat less elegant.  It too would work, and has the advantage of
> being able to be used for a much wider range of applications.
>
> Brian
>
> Brian
>
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> > Sent: Friday, April 21, 2000 9:36 AM
> > To: MEGACO@standards.nortelnetworks.com
> > Subject: Re: Multiple streams per call,
> >
> >
> > My view of something like tiling is that we need a per-stream
> > property to
> > express mixing method.  I didn't push this last summer
> > because it was clear
> > that it would have to be designed by specialists in the area,
> > and I figured
> > they should be the ones to step up to the plate when they are
> > serious about
> > building product using Megaco/H.248.
> >
> > > -----Original Message-----
> > > From: Rosen, Brian [SMTP:brosen@FORE.COM]
> > > Sent: Friday, April 21, 2000 8:58 AM
> > > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject:      Re: Multiple streams per call,
> > >
> > > Yes, the translation MG, you could construct a context with
> > > two RTP ports and use the SDP to imply translation.  The
> > protocol would
> > > allow that.
> > >
> > > The problem is that it would work for things that are
> > expressible in SDP,
> > > but not for more general mechanisms.  For example, suppose
> > you wanted
> > > an MCU that did tiling.  I'd prefer that we use one
> > mechanism for all of
> > > these
> > > kinds of problems.
> > >
> > > And, yes Christian, SDP is shorthand for "SDP or Annex C"
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: John Segers [mailto:jsegers@lucent.com]
> > > > Sent: Friday, April 21, 2000 5:52 AM
> > > > To: Rosen, Brian
> > > > Cc: MEGACO@standards.nortelnetworks.com
> > > > Subject: Re: Multiple streams per call,
> > > >
> > > >
> > > > Hi,
> > > >
> > > > Having been away from the list for a while, I've got some
> > > > catching up to
> > > > do!  Although this thread is probably less urgent than some of the
> > > > others, this one being related to more advanced (future)
> > > > functionality,
> > > > I'll jump in on this first.
> > > >
> > > > Comparing Brian's proposal for the video translator to
> > less exotic MG
> > > > devices that translate audio, I wonder why the extra ports
> > > > are needed.
> > > > In the audio case, the required transcoding, e.g. from
> > G.711 A-law to
> > > > G.723.1 is inferred from the Termination type/name and/or
> > RTP payload
> > > > type.  No extra ports are introduced to model the translator
> > > > resource.
> > > > Why can't it work the same for video?
> > > >
> > > > Cheers,
> > > >
> > > > John
> > > >
> > > > "Rosen, Brian" wrote:
> > > > >
> > > > > You seem to have everything correct!
> > > > >
> > > > > You are worried about the video translator.  The
> > problem statement
> > > > > was MG-A and MG-B did not have a common video encoding,
> > so the MGC
> > > > > wanted to insert a translator to fix the problem.
> > > > >
> > > > > I think this is very reasonable to do, and I would model the
> > > > > translator as a set of pairs of terminations - The "A" side and
> > > > > the "B" side.  Trying to push these into a single context, to
> > > > > my way of thinking, is very weird.  Much cleaner to have two
> > > > > separate contexts.  I waffled over whether to represent
> > the "ports"
> > > > > of the translator as physical terminations.  In
> > reality, they could
> > > > > be, if the translator was some hard wired fixed function.  It is
> > > > > possible that it could just be a fancy DSP, and the number
> > > > of translations
> > > > > it could do was a variable, determined by what
> > > > > translations were in use.  For example, it might be able to do
> > > > > 10 MPEG 1 to MPEG 2 translations, but only 3 MPEG2 to H.261
> > > > translations.
> > > > > In this case, it might be better to model the ports as ephemeral
> > > > > terminations.  I would still represent them as pairs of
> > > > terminations,
> > > > > which would go in pairs of two termination contexts, the other
> > > > > termination being (for example) the RTP termination.
> > > > >
> > > > > To help your thinking, instead of calling those
> > > > terminations Y and Z,
> > > > > call them XLate/A and XLate/B.  If the box could do
> > more than one,
> > > > > maybe we would call them XL/1/A and XL/1/B, so you
> > could talk about
> > > > > XL/4/A for example.  Then XL/1/A is in a context with RTP-A, and
> > > > > XL/1/B is in context with RTP-B.
> > > > >
> > > > > It is possible to have one termination that had two
> > streams (the A
> > > > > stream and the B stream) and then the context would have 3
> > > > terminations, the
> > > > > translator, the "A" RTP and the "B" RTP.  Then you would
> > > > use streamIDs to
> > > > > keep the streams straight (no need to use topology).
> > > > > This is one of the things I don't like about what we did,
> > > > two ways to
> > > > > do the same thing, nothing but "taste" to decide which to use,
> > > > > guaranteed interoperability problems unless some package is
> > > > standardized.
> > > > > Oh well.  Anyway, I think modeling the translator as having two
> > > > > terminations, an A termination and a B termination,
> > each with one
> > > > > stream, is the best way to do it.
> > > > >
> > > > > In fact, you may have noticed that I used the same model for the
> > > > > weird function bridge a few emails back -- I think
> > whenever we have
> > > > > odd-function devices, we should model the "ports" of the device
> > > > > as a termination implementing a specific package.  In
> > this specific
> > > > > case the ports are symmetric (because the flows are
> > send-receive),
> > > > > but in the general case, they may not be.
> > > > >
> > > > > Brian
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Chip Sharp [mailto:chsharp@cisco.com]
> > > > > > Sent: Friday, April 14, 2000 3:58 PM
> > > > > > To: Rosen, Brian; MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > Subject: Re: Multiple streams per call,
> > > > > >
> > > > > >
> > > > > > At 02:33 PM 4/14/00 -0400, Rosen, Brian wrote:
> > > > > >
> > > > > > ...snip...
> > > > > >
> > > > > > >Sure.  Look at it from the point of view of the MGs.
> > > > You have MG-A,
> > > > > > >MG-B and MG1.  MG-A has a termination with two
> > streams, video and
> > > > > > >audio.  It is commanded by the MGC to set up a single
> > > > context with
> > > > > > >the termination and two RTP connections, call them
> > > > RTP-A-Audio and
> > > > > > >RTP-A-Video.  The address it assigns to RTP-A-Audio is MG-B.
> > > > > > >The address it assigns RTP-A-Video is MG1.
> > > > > > >Again, this is a single context, with the physical
> > termination
> > > > > > >having two streams, and each of the RTP terminations
> > having one
> > > > > > >stream each.
> > > > > >
> > > > > > I assume when you say "RTP connections" above, you mean "RTP
> > > > > > terminations"
> > > > > > since the word "connection" isn't allowed in megaco. (your
> > > > > > MGCP is showing
> > > > > > ;-) ).
> > > > > > I'm not sure what kind of termination you are talking about,
> > > > > > but I'll call
> > > > > > it X.
> > > > > >
> > > > > > In MG-A, Terminations X, RTP-A-Audio and RTP-A-Video all
> > > > > > belong to the same
> > > > > > context, say Context A.  Termination X has 2 streams assigned
> > > > > > to it.  One
> > > > > > stream contains the video, the other stream contains the
> > > > > > audio (both in
> > > > > > send-receive).  Termination RTP-A-Audio would be configured
> > > > > > with only the
> > > > > > Audio stream.  Termination RTP-A-Video would be configured
> > > > > > with only the
> > > > > > Video stream.
> > > > > >
> > > > > > Therefore the video stream goes to MG1 and the audio stream
> > > > > > goes to MGB, as
> > > > > > described.
> > > > > >
> > > > > >
> > > > > > >Look at MG1.  It has two terminations, with one
> > stream each.  It
> > > > > > >is asked to set up two contexts, one with an RTP
> > connecting to
> > > > > > >MG-A and the other with its RTP connection to MG-B.  That's
> > > > > > >two contexts, each with two terminations, with one stream in
> > > > > > >each of the contexts.
> > > > > >
> > > > > > I'm not sure what the two mystery terminations are again, but
> > > > > > I'll call
> > > > > > them Y and Z.
> > > > > >
> > > > > > Terminations Y and RTP-A belong to a context A and
> > > > contain one stream.
> > > > > > Terminations Z and RTP-B belong to a context B and
> > > > contain one stream.
> > > > > >
> > > > > > The video stream from MGA comes into context A via
> > > > > > Termination RTP-A and
> > > > > > ends up on Termination Y (and vice versa).
> > > > > >
> > > > > > Whatever is on termination Z is transmitted out RTP-B via
> > > > > > context B (and
> > > > > > vice versa).
> > > > > >  From the below, it seems video is connected to MG-B; however
> > > > > > there is no
> > > > > > context containing Terminations Z & Y to allow them to
> > > > > > communicate under
> > > > > > the control of megaco.  Therefore, I assume that some internal
> > > > > > implementation-specific mechanism connects terminations Y & Z
> > > > > > in order to
> > > > > > get the video from Context A into context B.
> > > > > > MG1 could just have 2 RTP terminations with one stream in one
> > > > > > context.  Of
> > > > > > course, H.248 forbids a termination from belonging to
> > > > more than one
> > > > > > context, so you can't just create a context containing X & Y.
> > > > > >
> > > > > >
> > > > > >
> > > > > > >Of course, MG-B has a similar setup to MG-A -- it's
> > > > audio connects
> > > > > > >to MG-A, the video connects to MG1.
> > > > > > >
> > > > > > >Now look at it from the MGC.  The "call" has 3
> > Megaco contexts.
> > > > > > >The MG-A to MG-B audio, the MG-A to MG1 video and
> > the MG1 to MG-B
> > > > > > >video.
> > > > > >
> > > > > > Yes, but the MGC has no idea how the video gets from
> > > > Termination X to
> > > > > > Termination Y in MG1.
> > > > > >
> > > > > > Thanks for the illustration.  I haven't really thought about
> > > > > > it in a while.
> > > > > >
> > > > > >
> > > > > > >I'm still not thrilled with the whole stream idea, but
> > > > it does work.
> > > > > > >
> > > > > > >Brian
> > > > > >
> > > > > > http://www.netaid.org
> > > > > > --------------------------------------------------------------
> > > > > > -----------
> > > > > > Chip Sharp                 CTO Consulting Engineering
> > > > > > Cisco Systems
> > > > > > Reality - Love it or Leave it.
> > > > > > --------------------------------------------------------------
> > > > > > ----------
> > > > > >
> > > >
> > > > --
> > > > John Segers                                  email:
> > jsegers@lucent.com
> > > > Lucent Technologies
> >  Room HE 306
> > > > 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 Apr 26 04:09:01 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21395
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 26 Apr 2000 04:09:01 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.32110680@standards.nortelnetworks.com>; Wed, 26 Apr 2000 4:02:10 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 15926 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Apr 2000 04:02:08 -0400
Received: from wiprom2mx2.wipro.com (203.197.164.42) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.C8469E00@standards.nortelnetworks.com>; Wed, 26 Apr 2000
          3:52:03 -0400
Received: from m2vwall1.wipro.com (m2vwall1.wipro.com [164.164.27.50]) by
          wiprom2mx2.wipro.com (8.9.3/8.9.3) with ESMTP id QAA25261 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 26 Apr 2000 16:01:47 +0530
Received: from sarovar.mail.wipro.com ([164.164.27.50]) by m2vwall1.wipro.com
          (Netscape Messaging Server 3.6)  with ESMTP id AAA3D5B for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 26 Apr 2000 13:27:30 +0530
Received: from hiren ([192.168.243.67]) by sarovar.mail.wipro.com (Netscape
          Messaging Server 3.6)  with SMTP id AAAD1F for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 26 Apr 2000 13:29:40 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_01A4_01BFAF83.344CFAE0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3612.1700
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700
Message-ID:  <01a701bfaf55$1aaa42b0$43f3a8c0@hiren.wipinfo.soft.net>
Date:         Wed, 26 Apr 2000 13:27:44 +0530
Reply-To: Hiren Shah <hiren.shah@WIPRO.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Hiren Shah <hiren.shah@WIPRO.COM>
Subject:      Call agent issue
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_01A4_01BFAF83.344CFAE0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi all
I have a small doubt in concept.
Is there a one to one relationship between a call agent and a media =
gateway.
If not, then what are the considerations involved for having more than =
one call agent.
One of the consideration is that the media gateways may be of different =
vendors and therefore there the call agents also will be different .
Lets assume that the media gateways are from the same vendor and provide =
a standard and identical interface.
Now if this is the case ,will the geographical locations of the media =
gateways  have an impact on the decision whether there has to be a call =
agent per gateway.
Please clarify my doubt and please give me the attributes that matter in =
making a desicion to deploy more than one call agents.

regards
Hiren

A Candle never  loses any of its light by lighting other Candles

------=_NextPart_000_01A4_01BFAF83.344CFAE0
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type><BASE=20
href=3D"file://C:\Program Files\Common Files\Microsoft =
Shared\Stationery\">
<STYLE></STYLE>

<META content=3D'"MSHTML 4.72.3612.1706"' name=3DGENERATOR>
</HEAD>
<BODY background=3D"">
<DIV>Hi all</DIV>
<DIV>I have a small doubt in concept.</DIV>
<DIV>Is there a one to one relationship between a call agent and a media =

gateway.</DIV>
<DIV>If not, then what are the considerations involved for having more =
than one=20
call agent.</DIV>
<DIV>One of the consideration is that the media gateways may be of =
different=20
vendors and therefore there the call agents also will be different =
.</DIV>
<DIV>Lets assume that the media gateways are from the same vendor and =
provide a=20
standard and identical interface.</DIV>
<DIV>Now if this is the case ,will the geographical locations of the =
media=20
gateways&nbsp; have an impact on the decision whether there has to be a =
call=20
agent per gateway.</DIV>
<DIV>Please clarify my doubt and please give me the attributes that =
matter in=20
making a desicion to deploy more than one call agents.</DIV>
<DIV>&nbsp;</DIV>
<DIV>regards</DIV>
<DIV>Hiren</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>A Candle never&nbsp; loses any of its light by =
lighting other=20
Candles</FONT></DIV></BODY></HTML>

------=_NextPart_000_01A4_01BFAF83.344CFAE0--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Apr 26 07:48:21 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23969
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 26 Apr 2000 07:48:21 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D81D4840@standards.nortelnetworks.com>; Wed, 26 Apr 2000 7:41:33 -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; Wed, 26 Apr 2000 07:39:36 -0400
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.2CA7F600@standards.nortelnetworks.com>; Wed, 26 Apr 2000 7:29:36
          -0400
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id HAA13710; Wed, 26 Apr
          2000 07:35:52 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id HAA07372; Wed, 26 Apr
          2000 07:35:53 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <2MSF7AS1>; Wed, 26 Apr 2000 07:30:28 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF678216@whq-msgusr-02.fore.com>
Date:         Wed, 26 Apr 2000 07:35:51 -0400
Reply-To: "Rosen, Brian" <brosen@FORE.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <brosen@FORE.COM>
Subject:      Re: clarification
X-To:         Christian Groves <Christian.Groves@ERICSSON.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Wasn't modem needed to accommodate H.324, where the multimedia
streams are encoded into a single data stream and then modulated
by a modem, so that you needed to have the modem specified before
you got to the streams?

Brian

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM]
> Sent: Wednesday, April 26, 2000 12:14 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: clarification
>
>
> G'Day Tom,
>
> I agree the modem descriptor seems out of place and probably isn't
> needed. However can we really deprecate this in H248v2 and be
> backwards
> compatible?
>
> Cheers, Christian
>
> Tom-PT Taylor wrote:
> >
> > This is a leftover from Santiago, when we firmed up the set of
> > descriptors needed to describe a termination.  Mike Buckley had an
> > insight: let the descriptors form a hierarchy, describing the
> > termination from the physical layer upwards.  We didn't
> really follow
> > through on that thought, but the modem descriptor got left in the
> > schema more or less through oversight.  It's a bit late to
> delete it,
> > but maybe in H.248v2 it could be deprecated and replaced by
> a property
> > in another descriptor.
> >
> >      -----Original Message-----
> >      From:   Marc Mathew [SMTP:marc_mathew@MAILCITY.COM]
> >      Sent:   Thursday, April 06, 2000 8:06 AM
> >      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
> >      Subject:        clarification
> >
> >      Hi,
> >
> >         Can anyone please tell me what modem descriptor is used for.
> >      Should modem not be specified as a seperate package (NAS ?).
> >      Isn't modem a different kind of termination. Why is there a
> >      seperate descriptor for it.
> >
> >      Always,
> >      Marc
> >
> >      Send FREE April Fool's Greetings to your friends!
> >      http://www.whowhere.lycos.com/redirects/American_Greetings.rdct
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Apr 26 08:17:38 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24650
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 26 Apr 2000 08:17:36 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E75BE1F0@standards.nortelnetworks.com>; Wed, 26 Apr 2000 8:10:37 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 16259 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Apr 2000 08:09:45 -0400
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.5A09B5D0@standards.nortelnetworks.com>; Wed, 26 Apr 2000 7:59:30
          -0400
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id IAA15838; Wed, 26 Apr
          2000 08:05:41 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id IAA11318; Wed, 26 Apr
          2000 08:05:43 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <2MSF7BHH>; Wed, 26 Apr 2000 08:00:17 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFAF76.FCF442B2"
Message-ID:  <4FBEA8857476D311A03300204840E1CF678218@whq-msgusr-02.fore.com>
Date:         Wed, 26 Apr 2000 08:05:41 -0400
Reply-To: "Rosen, Brian" <brosen@FORE.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <brosen@FORE.COM>
Subject:      Re: Call agent issue
X-To:         Hiren Shah <hiren.shah@wipro.com>
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_01BFAF76.FCF442B2
Content-Type: text/plain;
        charset="iso-8859-1"


Hi all
I have a small doubt in concept.
Only one?  Keep thinking, you are sure to find more!!!

Is there a one to one relationship between a call agent and a media gateway.

Could be, but usually thought of as one to many in the current version, with
the possibility
of many to many.

If not, then what are the considerations involved for having more than one
call agent.
Lots, I'll go through yours and then add some more

One of the consideration is that the media gateways may be of different
vendors and therefore there the call agents also will be different .
Sure, we would say that Media Gateways implement packages on terminations.
In order
to assure that a Call Agent (we call them Media Gateway Controllers) can
properly control
a Media Gateway, the MGC has to support the packages of the MG.  So if you
had more than
one MGC that was different, one way to decide which MGC controlled which MGs
would
be which MGC implemented support for the packages implemented on the MGs.
For simplicity
we also have the "profile" concept, where if the MG and MGC implement the
same profile,
then they are compatible.

Lets assume that the media gateways are from the same vendor and provide a
standard and identical interface.
Or all the MGs implement the same profiles, or the MGCs all implement the
union of the profiles
implemented on the MGs to be controlled

Now if this is the case ,will the geographical locations of the media
gateways  have an impact on the decision whether there has to be a call
agent per gateway.
While it's possible that geography determines this, it would be a side
effect of network connectivity.   You need addressibility and some amount of
bandwidth between the MG and
MGC, and latency is also an issue.  Sometimes, network elements physically
nearer to one another have better connectivity.  This is not the case in
many networks however.

Please clarify my doubt and please give me the attributes that matter in
making a desicion to deploy more than one call agents.
Here is my list, others may have more:
    1. Administrative domain - a network may have more than one
administrative domain.
            Assignment of MGs to MGCs may be made on administrative domain
boundaries
    2. Bandwidth/latency as discussed above
    3. Call capacity.  A set of MGs may be able to generate a very large
number of calls.
            A MGC  has some limit to the number of calls it can handle.  You
add MGCs to
            your net to allow more calls
    4. Services.  Different MGCs may offer different services.  An MG may be
attached to
            a specific MGC based on what services it requires
    5. Reliability, there are mechanisms to support handoff of an MG from
one MGC to
            another.

Please also note that an MG may be controlled by more than one MGC.  See the
discussion
of "Virtual MGs" in the text.  This is how you get many to many connections.

regards
Hiren

A Candle never  loses any of its light by lighting other Candles


------_=_NextPart_001_01BFAF76.FCF442B2
Content-Type: text/html;
        charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">

<BASE
href="file://C:\Program Files\Common Files\Microsoft Shared\Stationery\">
<STYLE></STYLE>

<META content='"MSHTML 4.72.3612.1706"' name=GENERATOR>
<META content="MSHTML 5.00.2919.6307" name=GENERATOR></HEAD>
<BODY background="">
<BLOCKQUOTE
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma
  size=2></DIV></FONT>
  <DIV>Hi all</DIV>
  <DIV>I have a small doubt in concept.<FONT color=#0000ff face=Arial
  size=2><SPAN class=470433911-26042000>&nbsp;</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=470433911-26042000>Only
  one?&nbsp; Keep&nbsp;thinking, you are sure to find
more!!!</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=470433911-26042000>&nbsp;</SPAN></FONT></DIV>
  <DIV>Is there a one to one relationship between a call agent and a media
  gateway.<FONT color=#0000ff face=Arial size=2><SPAN
  class=470433911-26042000>&nbsp;</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=470433911-26042000>Could be, but usually thought of as&nbsp;one to many
  in the current version, with the possibility</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=470433911-26042000>of
  many to&nbsp;many.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=470433911-26042000>&nbsp;</SPAN></FONT></DIV>
  <DIV>If not, then what are the considerations involved for having more than
  one call agent.<FONT color=#0000ff face=Arial size=2><SPAN
  class=470433911-26042000>&nbsp;</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=470433911-26042000>Lots, I'll go&nbsp;through yours and then add some
  more</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=470433911-26042000>&nbsp;</SPAN></FONT></DIV>
  <DIV>One of the consideration is that the media gateways may be of different
  vendors and therefore there the call agents also will be different .<FONT
  color=#0000ff face=Arial size=2><SPAN
  class=470433911-26042000>&nbsp;</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=470433911-26042000>Sure, we would say that Media Gateways implement
  packages on terminations.&nbsp; In order</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=470433911-26042000>to
  assure that a Call Agent (we call them Media Gateway Controllers) can properly
  control</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=470433911-26042000>a
  Media Gateway, the MGC has to support the packages of the MG.&nbsp; So if you
  had more than</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=470433911-26042000>one
  MGC that was different, one way to decide which MGC controlled which MGs
  would</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=470433911-26042000>be
  which MGC implemented support for the packages implemented on the MGs.&nbsp;
  For simplicity</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=470433911-26042000>we
  also have the "profile" concept, where if the MG and MGC implement the same
  profile,</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=470433911-26042000>then
  they are compatible.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=470433911-26042000></SPAN></FONT>&nbsp;</DIV>
  <DIV>Lets assume that the media gateways are from the same vendor and provide
  a standard and identical interface.<FONT color=#0000ff face=Arial size=2><SPAN
  class=470433911-26042000>&nbsp;</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=470433911-26042000>Or&nbsp;all the MGs implement the&nbsp;same profiles,
  or the MGCs all implement the union of the profiles</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=470433911-26042000>implemented on the MGs to be
  controlled</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=470433911-26042000></SPAN></FONT>&nbsp;</DIV>
  <DIV>Now if this is the case ,will the geographical locations of the media
  gateways&nbsp; have an impact on the decision whether there has to be a call
  agent per gateway.<FONT color=#0000ff face=Arial size=2><SPAN
  class=470433911-26042000>&nbsp;</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=470433911-26042000>While it's possible that geography determines this,
  it would be a side effect of network connectivity.&nbsp;&nbsp; You need
  addressibility and some amount of bandwidth between the MG
  and</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=470433911-26042000>MGC,
  and latency is also an issue.&nbsp; Sometimes, network elements physically
  nearer to one another </SPAN></FONT><FONT color=#0000ff face=Arial
  size=2><SPAN class=470433911-26042000>have better connectivity.&nbsp; This is
  not the case in many networks however.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=470433911-26042000></SPAN></FONT>&nbsp;</DIV>
  <DIV>Please clarify my doubt and please give me the attributes that matter in
  making a desicion to deploy more than one call agents.<FONT color=#0000ff
  face=Arial size=2><SPAN class=470433911-26042000>&nbsp;</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=470433911-26042000>Here
  is my list, others may have more:</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=470433911-26042000>&nbsp;&nbsp;&nbsp;&nbsp;1. Administrative domain - a
  network may have more than one administrative domain.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=470433911-26042000>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Assignment
  of&nbsp;MGs to MGCs may be made on administrative domain
  boundaries</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=470433911-26042000>&nbsp;&nbsp;&nbsp;&nbsp;2. Bandwidth/latency as
  discussed above&nbsp;</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=470433911-26042000>&nbsp;&nbsp;&nbsp; 3. Call capacity.&nbsp; A set of
  MGs may be able to generate a very large number of calls.&nbsp;
  </SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=470433911-26042000>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  A MGC</SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN
  class=470433911-26042000>&nbsp; has some limit to the number of calls it can
  handle.&nbsp; You add MGCs to </SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=470433911-26042000>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  your net </SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN
  class=470433911-26042000>to allow more calls</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=470433911-26042000>&nbsp;&nbsp;&nbsp; 4. Services.&nbsp; Different MGCs
  may offer different services.&nbsp; An MG may be attached
  to</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=470433911-26042000>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  a specific MGC based on what services it requires</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=470433911-26042000>&nbsp;&nbsp;&nbsp; 5. Reliability, there are
  mechanisms to support handoff of an MG from one MGC to</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=470433911-26042000>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  another.</SPAN></FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN
  class=470433911-26042000>Please also note that an MG may be controlled by more
  than one MGC.&nbsp; See the discussion</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=470433911-26042000>of
  "Virtual MGs" in the text.&nbsp; This is how you get many to many
  connections.</SPAN></FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV>regards</DIV>
  <DIV>Hiren</DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT size=2>A Candle never&nbsp; loses any of its light by lighting
  other Candles</FONT></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01BFAF76.FCF442B2--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Apr 26 08:49:48 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25361
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 26 Apr 2000 08:49:47 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6336BE40@standards.nortelnetworks.com>; Wed, 26 Apr 2000 8:42:43 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 16317 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Apr 2000 08:41:31 -0400
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.CD238330@standards.nortelnetworks.com>; Wed, 26 Apr 2000 8:31:21
          -0400
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id IAA18190; Wed, 26 Apr
          2000 08:37:25 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id IAA15584; Wed, 26 Apr
          2000 08:37:27 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <2MSF7B55>; Wed, 26 Apr 2000 08:32: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:  <4FBEA8857476D311A03300204840E1CF67821A@whq-msgusr-02.fore.com>
Date:         Wed, 26 Apr 2000 08:37:25 -0400
Reply-To: "Rosen, Brian" <brosen@FORE.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <brosen@FORE.COM>
Subject:      Re: Multiple streams per call,
X-To:         Christian Groves <Christian.Groves@ericsson.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

The reason it's not a v2 issue is that it affects how you design
a package for a cs1 implementation of some kind of capability not
specifically catered for.

In the discussions of "topology" we had a similar disagreement, with
the same actors :(.  The topology mechanism works for most common
implementations of an audio mixing bridge.  The protocol does not
have a mechanism to extend topology, nor to add context properties.
We do have the package mechanism.  If I wanted to build a very flexible
MCU which allowed a wide range of video and audio effects, I can't do
it with "bare" cs1 capabilities (my "what does T1/T2 bothways mean
for a tiling video MCU?" question).

On the other hand, I can do it with the mechanism I propose.  In fact,
it's pretty hard to think of any kind of media device I cannot control
pretty nicely with such a mechanism.  That is a very good feature of
the protocol.

Now, what I'm advocating is that we use that mechanism uniformly.

What we are discussing is a kind of corner case - the "two RTPs with
different media specifications, implied translation" clearly is
within the capabilities of the protocol.  It does work.  But all
you need to do is add one twist - say that the translator is also a
multimedia MCU, and now you can't use the same model.  That is a bad
idea.

Brian

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> Sent: Wednesday, April 26, 2000 12:34 AM
> To: Rosen, Brian
> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Multiple streams per call,
>
>
> I like the 'elegant method'. I thought that context
> properties could be
> used in the situations where the elegant didn't work. This I thought
> would be the most generic.
>
> I agree that using the 'internal' termination model is a
> valid modelling
> technique but I wonder if it is more uniform. ie. Conferences
> today are
> handled by context but we could equally have a context with a mixing
> termination and then hang off individual context and terminations for
> the subscriber legs.
>
> I think this is something for discussion for v2, either approach is
> interesting.
>
> Cheers, Christian
>
> "Rosen, Brian" wrote:
> >
> > This is beyond the current discussion.  The question is, in general,
> > how do we model devices that are "different".  In the case cited,
> > media translation, we could model it as a two termination context,
> > with the RTP flows, specified by media descriptors, describing the
> > two sides, and an implicit translation in between.  This certainly
> > works, and is pretty elegant.
> >
> > The problem is that it doesn't work for all kinds of devices,
> > and I wondered if we should model them in a more uniform way.  I
> > suggested a set of two termination contexts with an "internal"
> > termination that can have characteristics ascribed to it by a
> > set of packages implemented on it, and an RTP termination that
> > had the external flow on it.  This would also work for the
> translator,
> > but requires more terminations and more contexts, and thus is
> > somewhat less elegant.  It too would work, and has the advantage of
> > being able to be used for a much wider range of applications.
> >
> > Brian
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> > > Sent: Friday, April 21, 2000 9:36 AM
> > > To: MEGACO@standards.nortelnetworks.com
> > > Subject: Re: Multiple streams per call,
> > >
> > >
> > > My view of something like tiling is that we need a per-stream
> > > property to
> > > express mixing method.  I didn't push this last summer
> > > because it was clear
> > > that it would have to be designed by specialists in the area,
> > > and I figured
> > > they should be the ones to step up to the plate when they are
> > > serious about
> > > building product using Megaco/H.248.
> > >
> > > > -----Original Message-----
> > > > From: Rosen, Brian [SMTP:brosen@FORE.COM]
> > > > Sent: Friday, April 21, 2000 8:58 AM
> > > > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject:      Re: Multiple streams per call,
> > > >
> > > > Yes, the translation MG, you could construct a context with
> > > > two RTP ports and use the SDP to imply translation.  The
> > > protocol would
> > > > allow that.
> > > >
> > > > The problem is that it would work for things that are
> > > expressible in SDP,
> > > > but not for more general mechanisms.  For example, suppose
> > > you wanted
> > > > an MCU that did tiling.  I'd prefer that we use one
> > > mechanism for all of
> > > > these
> > > > kinds of problems.
> > > >
> > > > And, yes Christian, SDP is shorthand for "SDP or Annex C"
> > > >
> > > > Brian
> > > >
> > > > > -----Original Message-----
> > > > > From: John Segers [mailto:jsegers@lucent.com]
> > > > > Sent: Friday, April 21, 2000 5:52 AM
> > > > > To: Rosen, Brian
> > > > > Cc: MEGACO@standards.nortelnetworks.com
> > > > > Subject: Re: Multiple streams per call,
> > > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > Having been away from the list for a while, I've got some
> > > > > catching up to
> > > > > do!  Although this thread is probably less urgent
> than some of the
> > > > > others, this one being related to more advanced (future)
> > > > > functionality,
> > > > > I'll jump in on this first.
> > > > >
> > > > > Comparing Brian's proposal for the video translator to
> > > less exotic MG
> > > > > devices that translate audio, I wonder why the extra ports
> > > > > are needed.
> > > > > In the audio case, the required transcoding, e.g. from
> > > G.711 A-law to
> > > > > G.723.1 is inferred from the Termination type/name and/or
> > > RTP payload
> > > > > type.  No extra ports are introduced to model the translator
> > > > > resource.
> > > > > Why can't it work the same for video?
> > > > >
> > > > > Cheers,
> > > > >
> > > > > John
> > > > >
> > > > > "Rosen, Brian" wrote:
> > > > > >
> > > > > > You seem to have everything correct!
> > > > > >
> > > > > > You are worried about the video translator.  The
> > > problem statement
> > > > > > was MG-A and MG-B did not have a common video encoding,
> > > so the MGC
> > > > > > wanted to insert a translator to fix the problem.
> > > > > >
> > > > > > I think this is very reasonable to do, and I would model the
> > > > > > translator as a set of pairs of terminations - The
> "A" side and
> > > > > > the "B" side.  Trying to push these into a single
> context, to
> > > > > > my way of thinking, is very weird.  Much cleaner to have two
> > > > > > separate contexts.  I waffled over whether to represent
> > > the "ports"
> > > > > > of the translator as physical terminations.  In
> > > reality, they could
> > > > > > be, if the translator was some hard wired fixed
> function.  It is
> > > > > > possible that it could just be a fancy DSP, and the number
> > > > > of translations
> > > > > > it could do was a variable, determined by what
> > > > > > translations were in use.  For example, it might be
> able to do
> > > > > > 10 MPEG 1 to MPEG 2 translations, but only 3 MPEG2 to H.261
> > > > > translations.
> > > > > > In this case, it might be better to model the ports
> as ephemeral
> > > > > > terminations.  I would still represent them as pairs of
> > > > > terminations,
> > > > > > which would go in pairs of two termination
> contexts, the other
> > > > > > termination being (for example) the RTP termination.
> > > > > >
> > > > > > To help your thinking, instead of calling those
> > > > > terminations Y and Z,
> > > > > > call them XLate/A and XLate/B.  If the box could do
> > > more than one,
> > > > > > maybe we would call them XL/1/A and XL/1/B, so you
> > > could talk about
> > > > > > XL/4/A for example.  Then XL/1/A is in a context
> with RTP-A, and
> > > > > > XL/1/B is in context with RTP-B.
> > > > > >
> > > > > > It is possible to have one termination that had two
> > > streams (the A
> > > > > > stream and the B stream) and then the context would have 3
> > > > > terminations, the
> > > > > > translator, the "A" RTP and the "B" RTP.  Then you would
> > > > > use streamIDs to
> > > > > > keep the streams straight (no need to use topology).
> > > > > > This is one of the things I don't like about what we did,
> > > > > two ways to
> > > > > > do the same thing, nothing but "taste" to decide
> which to use,
> > > > > > guaranteed interoperability problems unless some package is
> > > > > standardized.
> > > > > > Oh well.  Anyway, I think modeling the translator
> as having two
> > > > > > terminations, an A termination and a B termination,
> > > each with one
> > > > > > stream, is the best way to do it.
> > > > > >
> > > > > > In fact, you may have noticed that I used the same
> model for the
> > > > > > weird function bridge a few emails back -- I think
> > > whenever we have
> > > > > > odd-function devices, we should model the "ports"
> of the device
> > > > > > as a termination implementing a specific package.  In
> > > this specific
> > > > > > case the ports are symmetric (because the flows are
> > > send-receive),
> > > > > > but in the general case, they may not be.
> > > > > >
> > > > > > Brian
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Chip Sharp [mailto:chsharp@cisco.com]
> > > > > > > Sent: Friday, April 14, 2000 3:58 PM
> > > > > > > To: Rosen, Brian; MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > > Subject: Re: Multiple streams per call,
> > > > > > >
> > > > > > >
> > > > > > > At 02:33 PM 4/14/00 -0400, Rosen, Brian wrote:
> > > > > > >
> > > > > > > ...snip...
> > > > > > >
> > > > > > > >Sure.  Look at it from the point of view of the MGs.
> > > > > You have MG-A,
> > > > > > > >MG-B and MG1.  MG-A has a termination with two
> > > streams, video and
> > > > > > > >audio.  It is commanded by the MGC to set up a single
> > > > > context with
> > > > > > > >the termination and two RTP connections, call them
> > > > > RTP-A-Audio and
> > > > > > > >RTP-A-Video.  The address it assigns to
> RTP-A-Audio is MG-B.
> > > > > > > >The address it assigns RTP-A-Video is MG1.
> > > > > > > >Again, this is a single context, with the physical
> > > termination
> > > > > > > >having two streams, and each of the RTP terminations
> > > having one
> > > > > > > >stream each.
> > > > > > >
> > > > > > > I assume when you say "RTP connections" above,
> you mean "RTP
> > > > > > > terminations"
> > > > > > > since the word "connection" isn't allowed in megaco. (your
> > > > > > > MGCP is showing
> > > > > > > ;-) ).
> > > > > > > I'm not sure what kind of termination you are
> talking about,
> > > > > > > but I'll call
> > > > > > > it X.
> > > > > > >
> > > > > > > In MG-A, Terminations X, RTP-A-Audio and RTP-A-Video all
> > > > > > > belong to the same
> > > > > > > context, say Context A.  Termination X has 2
> streams assigned
> > > > > > > to it.  One
> > > > > > > stream contains the video, the other stream contains the
> > > > > > > audio (both in
> > > > > > > send-receive).  Termination RTP-A-Audio would be
> configured
> > > > > > > with only the
> > > > > > > Audio stream.  Termination RTP-A-Video would be configured
> > > > > > > with only the
> > > > > > > Video stream.
> > > > > > >
> > > > > > > Therefore the video stream goes to MG1 and the
> audio stream
> > > > > > > goes to MGB, as
> > > > > > > described.
> > > > > > >
> > > > > > >
> > > > > > > >Look at MG1.  It has two terminations, with one
> > > stream each.  It
> > > > > > > >is asked to set up two contexts, one with an RTP
> > > connecting to
> > > > > > > >MG-A and the other with its RTP connection to
> MG-B.  That's
> > > > > > > >two contexts, each with two terminations, with
> one stream in
> > > > > > > >each of the contexts.
> > > > > > >
> > > > > > > I'm not sure what the two mystery terminations
> are again, but
> > > > > > > I'll call
> > > > > > > them Y and Z.
> > > > > > >
> > > > > > > Terminations Y and RTP-A belong to a context A and
> > > > > contain one stream.
> > > > > > > Terminations Z and RTP-B belong to a context B and
> > > > > contain one stream.
> > > > > > >
> > > > > > > The video stream from MGA comes into context A via
> > > > > > > Termination RTP-A and
> > > > > > > ends up on Termination Y (and vice versa).
> > > > > > >
> > > > > > > Whatever is on termination Z is transmitted out RTP-B via
> > > > > > > context B (and
> > > > > > > vice versa).
> > > > > > >  From the below, it seems video is connected to
> MG-B; however
> > > > > > > there is no
> > > > > > > context containing Terminations Z & Y to allow them to
> > > > > > > communicate under
> > > > > > > the control of megaco.  Therefore, I assume that
> some internal
> > > > > > > implementation-specific mechanism connects
> terminations Y & Z
> > > > > > > in order to
> > > > > > > get the video from Context A into context B.
> > > > > > > MG1 could just have 2 RTP terminations with one
> stream in one
> > > > > > > context.  Of
> > > > > > > course, H.248 forbids a termination from belonging to
> > > > > more than one
> > > > > > > context, so you can't just create a context
> containing X & Y.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > >Of course, MG-B has a similar setup to MG-A -- it's
> > > > > audio connects
> > > > > > > >to MG-A, the video connects to MG1.
> > > > > > > >
> > > > > > > >Now look at it from the MGC.  The "call" has 3
> > > Megaco contexts.
> > > > > > > >The MG-A to MG-B audio, the MG-A to MG1 video and
> > > the MG1 to MG-B
> > > > > > > >video.
> > > > > > >
> > > > > > > Yes, but the MGC has no idea how the video gets from
> > > > > Termination X to
> > > > > > > Termination Y in MG1.
> > > > > > >
> > > > > > > Thanks for the illustration.  I haven't really
> thought about
> > > > > > > it in a while.
> > > > > > >
> > > > > > >
> > > > > > > >I'm still not thrilled with the whole stream idea, but
> > > > > it does work.
> > > > > > > >
> > > > > > > >Brian
> > > > > > >
> > > > > > > http://www.netaid.org
> > > > > > >
> --------------------------------------------------------------
> > > > > > > -----------
> > > > > > > Chip Sharp                 CTO Consulting Engineering
> > > > > > > Cisco Systems
> > > > > > > Reality - Love it or Leave it.
> > > > > > >
> --------------------------------------------------------------
> > > > > > > ----------
> > > > > > >
> > > > >
> > > > > --
> > > > > John Segers                                  email:
> > > jsegers@lucent.com
> > > > > Lucent Technologies
> > >  Room HE 306
> > > > > 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 Apr 26 08:55:41 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25413
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 26 Apr 2000 08:55:41 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3AEFA860@standards.nortelnetworks.com>; Wed, 26 Apr 2000 8:48:45 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 16363 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Apr 2000 08:47:32 -0400
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.0F73E9D0@standards.nortelnetworks.com>; Wed, 26 Apr 2000 8:47:32
          -0400
Received: from chsharp-tecra.cisco.com (chsharp-isdn.cisco.com
          [171.68.116.221]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2)
          with ESMTP id FAA29098; Wed, 26 Apr 2000 05:53:38 -0700 (PDT)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.3.1.2.20000426084752.00ba36e0@dogwood.cisco.com>
Date:         Wed, 26 Apr 2000 08:49:56 -0400
Reply-To: Chip Sharp <chsharp@CISCO.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chip Sharp <chsharp@CISCO.COM>
Subject:      Re: clarification
X-To:         "Rosen, Brian" <brosen@FORE.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <4FBEA8857476D311A03300204840E1CF678216@whq-msgusr-02.fore. com>

I believe this is correct.  I believe the idea for the modem descriptor was
introduced in Santiago (5/99) when all the multiplexing termination and
multimedia stuff was added.  Don't know if anyone has actually implemented
it. I haven't seen much discussion of H.324 since then.

Chip

At 07:35 AM 4/26/00 -0400, Rosen, Brian wrote:
>Wasn't modem needed to accommodate H.324, where the multimedia
>streams are encoded into a single data stream and then modulated
>by a modem, so that you needed to have the modem specified before
>you got to the streams?
>
>Brian
>
> > -----Original Message-----
> > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM]
> > Sent: Wednesday, April 26, 2000 12:14 AM
> > To: MEGACO@standards.nortelnetworks.com
> > Subject: Re: clarification
> >
> >
> > G'Day Tom,
> >
> > I agree the modem descriptor seems out of place and probably isn't
> > needed. However can we really deprecate this in H248v2 and be
> > backwards
> > compatible?
> >
> > Cheers, Christian
> >
> > Tom-PT Taylor wrote:
> > >
> > > This is a leftover from Santiago, when we firmed up the set of
> > > descriptors needed to describe a termination.  Mike Buckley had an
> > > insight: let the descriptors form a hierarchy, describing the
> > > termination from the physical layer upwards.  We didn't
> > really follow
> > > through on that thought, but the modem descriptor got left in the
> > > schema more or less through oversight.  It's a bit late to
> > delete it,
> > > but maybe in H.248v2 it could be deprecated and replaced by
> > a property
> > > in another descriptor.
> > >
> > >      -----Original Message-----
> > >      From:   Marc Mathew [SMTP:marc_mathew@MAILCITY.COM]
> > >      Sent:   Thursday, April 06, 2000 8:06 AM
> > >      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
> > >      Subject:        clarification
> > >
> > >      Hi,
> > >
> > >         Can anyone please tell me what modem descriptor is used for.
> > >      Should modem not be specified as a seperate package (NAS ?).
> > >      Isn't modem a different kind of termination. Why is there a
> > >      seperate descriptor for it.
> > >
> > >      Always,
> > >      Marc
> > >
> > >      Send FREE April Fool's Greetings to your friends!
> > >      http://www.whowhere.lycos.com/redirects/American_Greetings.rdct
> >


-------------------------------------------------------------------
Chip Sharp                 CTO Consulting Engineering
Cisco Systems
Reality - Love it or Leave it.
http://www.netaid.org
-------------------------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Apr 26 09:11:41 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25762
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 26 Apr 2000 09:11:41 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7A510560@standards.nortelnetworks.com>; Wed, 26 Apr 2000 9:04:50 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 16423 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Apr 2000 09:03:20 -0400
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.44FAD8A0@standards.nortelnetworks.com>; Wed, 26 Apr 2000
          9:03:20 -0400
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Wed, 26 Apr 2000 08:09:24 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <JSPA3WWF>; Wed, 26 Apr 2000 08:09:13 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B70B@zcard00g.ca.nortel.com>
Date:         Wed, 26 Apr 2000 08:09:15 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Call agent issue
X-To:         "hiren.shah@WIPRO.COM" <hiren.shah@WIPRO.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I assume that by "Call Agent" you mean what in Megaco we call the MGC (Media
Gateway Controller).  This isn't an automatic assumption -- the architecture
above the MG could be more complicated -- but it's reasonable.

First point: the whole reason to define a standard is so different vendors'
products can interwork.  Just because you have media gateways from multiple
vendors doesn't mean they can't be controlled by the same call agent.

Second point: in my engineering judgement, it is hard to see that having a
call agent per media gateway would be economic.  You might as well combine
the two units, eliminating the cost of supporting the Megaco/H.248
interface.  The whole point of the decomposition into call agent/MGC and
media gateway components is to achieve economies through geographic
dispersion of the complete gateway function.

> -----Original Message-----
> From: hiren.shah@WIPRO.COM [SMTP:hiren.shah@WIPRO.COM]
> Sent: Wednesday, April 26, 2000 3:58 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Call agent issue
>
> Hi all
> I have a small doubt in concept.
> Is there a one to one relationship between a call agent and a media
> gateway.
> If not, then what are the considerations involved for having more than one
> call agent.
> One of the consideration is that the media gateways may be of different
> vendors and therefore there the call agents also will be different .
> Lets assume that the media gateways are from the same vendor and provide a
> standard and identical interface.
> Now if this is the case ,will the geographical locations of the media
> gateways  have an impact on the decision whether there has to be a call
> agent per gateway.
> Please clarify my doubt and please give me the attributes that matter in
> making a desicion to deploy more than one call agents.
>
> regards
> Hiren
>
> A Candle never  loses any of its light by lighting other Candles


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Apr 26 09:19:54 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25892
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 26 Apr 2000 09:19:53 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9A3769E0@standards.nortelnetworks.com>; Wed, 26 Apr 2000 9:12:53 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 16461 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Apr 2000 09:11:46 -0400
Received: from smtprich.nortel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.72480660@standards.nortelnetworks.com>; Wed, 26 Apr 2000 9:11:46
          -0400
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprich.nortel.com; Wed, 26 Apr 2000 08:16:33 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <JSPA3W9N>; Wed, 26 Apr 2000 08:15:13 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B70C@zcard00g.ca.nortel.com>
Date:         Wed, 26 Apr 2000 08:15:15 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Multiple streams per call,
X-To:         "Rosen, Brian" <brosen@FORE.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

It seems to me that this is only marginally a standardization issue.  You
may want to build your GW one way, another vendor differently.  We will have
to think about whether we have to define properties to allow the MGC to
discover the difference in internal organization.

:-) My suspicion is that, having stoutly resisted the multimedia context
model, you'd like to bury it on the rebound.

> -----Original Message-----
> From: Rosen, Brian [SMTP:brosen@FORE.COM]
> Sent: Wednesday, April 26, 2000 8:37 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: Multiple streams per call,
>
> The reason it's not a v2 issue is that it affects how you design
> a package for a cs1 implementation of some kind of capability not
> specifically catered for.
>
> In the discussions of "topology" we had a similar disagreement, with
> the same actors :(.  The topology mechanism works for most common
> implementations of an audio mixing bridge.  The protocol does not
> have a mechanism to extend topology, nor to add context properties.
> We do have the package mechanism.  If I wanted to build a very flexible
> MCU which allowed a wide range of video and audio effects, I can't do
> it with "bare" cs1 capabilities (my "what does T1/T2 bothways mean
> for a tiling video MCU?" question).
>
> On the other hand, I can do it with the mechanism I propose.  In fact,
> it's pretty hard to think of any kind of media device I cannot control
> pretty nicely with such a mechanism.  That is a very good feature of
> the protocol.
>
> Now, what I'm advocating is that we use that mechanism uniformly.
>
> What we are discussing is a kind of corner case - the "two RTPs with
> different media specifications, implied translation" clearly is
> within the capabilities of the protocol.  It does work.  But all
> you need to do is add one twist - say that the translator is also a
> multimedia MCU, and now you can't use the same model.  That is a bad
> idea.
>
> Brian
>
> > -----Original Message-----
> > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > Sent: Wednesday, April 26, 2000 12:34 AM
> > To: Rosen, Brian
> > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Multiple streams per call,
> >
> >
> > I like the 'elegant method'. I thought that context
> > properties could be
> > used in the situations where the elegant didn't work. This I thought
> > would be the most generic.
> >
> > I agree that using the 'internal' termination model is a
> > valid modelling
> > technique but I wonder if it is more uniform. ie. Conferences
> > today are
> > handled by context but we could equally have a context with a mixing
> > termination and then hang off individual context and terminations for
> > the subscriber legs.
> >
> > I think this is something for discussion for v2, either approach is
> > interesting.
> >
> > Cheers, Christian
> >
> > "Rosen, Brian" wrote:
> > >
> > > This is beyond the current discussion.  The question is, in general,
> > > how do we model devices that are "different".  In the case cited,
> > > media translation, we could model it as a two termination context,
> > > with the RTP flows, specified by media descriptors, describing the
> > > two sides, and an implicit translation in between.  This certainly
> > > works, and is pretty elegant.
> > >
> > > The problem is that it doesn't work for all kinds of devices,
> > > and I wondered if we should model them in a more uniform way.  I
> > > suggested a set of two termination contexts with an "internal"
> > > termination that can have characteristics ascribed to it by a
> > > set of packages implemented on it, and an RTP termination that
> > > had the external flow on it.  This would also work for the
> > translator,
> > > but requires more terminations and more contexts, and thus is
> > > somewhat less elegant.  It too would work, and has the advantage of
> > > being able to be used for a much wider range of applications.
> > >
> > > Brian
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> > > > Sent: Friday, April 21, 2000 9:36 AM
> > > > To: MEGACO@standards.nortelnetworks.com
> > > > Subject: Re: Multiple streams per call,
> > > >
> > > >
> > > > My view of something like tiling is that we need a per-stream
> > > > property to
> > > > express mixing method.  I didn't push this last summer
> > > > because it was clear
> > > > that it would have to be designed by specialists in the area,
> > > > and I figured
> > > > they should be the ones to step up to the plate when they are
> > > > serious about
> > > > building product using Megaco/H.248.
> > > >
> > > > > -----Original Message-----
> > > > > From: Rosen, Brian [SMTP:brosen@FORE.COM]
> > > > > Sent: Friday, April 21, 2000 8:58 AM
> > > > > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject:      Re: Multiple streams per call,
> > > > >
> > > > > Yes, the translation MG, you could construct a context with
> > > > > two RTP ports and use the SDP to imply translation.  The
> > > > protocol would
> > > > > allow that.
> > > > >
> > > > > The problem is that it would work for things that are
> > > > expressible in SDP,
> > > > > but not for more general mechanisms.  For example, suppose
> > > > you wanted
> > > > > an MCU that did tiling.  I'd prefer that we use one
> > > > mechanism for all of
> > > > > these
> > > > > kinds of problems.
> > > > >
> > > > > And, yes Christian, SDP is shorthand for "SDP or Annex C"
> > > > >
> > > > > Brian
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: John Segers [mailto:jsegers@lucent.com]
> > > > > > Sent: Friday, April 21, 2000 5:52 AM
> > > > > > To: Rosen, Brian
> > > > > > Cc: MEGACO@standards.nortelnetworks.com
> > > > > > Subject: Re: Multiple streams per call,
> > > > > >
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Having been away from the list for a while, I've got some
> > > > > > catching up to
> > > > > > do!  Although this thread is probably less urgent
> > than some of the
> > > > > > others, this one being related to more advanced (future)
> > > > > > functionality,
> > > > > > I'll jump in on this first.
> > > > > >
> > > > > > Comparing Brian's proposal for the video translator to
> > > > less exotic MG
> > > > > > devices that translate audio, I wonder why the extra ports
> > > > > > are needed.
> > > > > > In the audio case, the required transcoding, e.g. from
> > > > G.711 A-law to
> > > > > > G.723.1 is inferred from the Termination type/name and/or
> > > > RTP payload
> > > > > > type.  No extra ports are introduced to model the translator
> > > > > > resource.
> > > > > > Why can't it work the same for video?
> > > > > >
> > > > > > Cheers,
> > > > > >
> > > > > > John
> > > > > >
> > > > > > "Rosen, Brian" wrote:
> > > > > > >
> > > > > > > You seem to have everything correct!
> > > > > > >
> > > > > > > You are worried about the video translator.  The
> > > > problem statement
> > > > > > > was MG-A and MG-B did not have a common video encoding,
> > > > so the MGC
> > > > > > > wanted to insert a translator to fix the problem.
> > > > > > >
> > > > > > > I think this is very reasonable to do, and I would model the
> > > > > > > translator as a set of pairs of terminations - The
> > "A" side and
> > > > > > > the "B" side.  Trying to push these into a single
> > context, to
> > > > > > > my way of thinking, is very weird.  Much cleaner to have two
> > > > > > > separate contexts.  I waffled over whether to represent
> > > > the "ports"
> > > > > > > of the translator as physical terminations.  In
> > > > reality, they could
> > > > > > > be, if the translator was some hard wired fixed
> > function.  It is
> > > > > > > possible that it could just be a fancy DSP, and the number
> > > > > > of translations
> > > > > > > it could do was a variable, determined by what
> > > > > > > translations were in use.  For example, it might be
> > able to do
> > > > > > > 10 MPEG 1 to MPEG 2 translations, but only 3 MPEG2 to H.261
> > > > > > translations.
> > > > > > > In this case, it might be better to model the ports
> > as ephemeral
> > > > > > > terminations.  I would still represent them as pairs of
> > > > > > terminations,
> > > > > > > which would go in pairs of two termination
> > contexts, the other
> > > > > > > termination being (for example) the RTP termination.
> > > > > > >
> > > > > > > To help your thinking, instead of calling those
> > > > > > terminations Y and Z,
> > > > > > > call them XLate/A and XLate/B.  If the box could do
> > > > more than one,
> > > > > > > maybe we would call them XL/1/A and XL/1/B, so you
> > > > could talk about
> > > > > > > XL/4/A for example.  Then XL/1/A is in a context
> > with RTP-A, and
> > > > > > > XL/1/B is in context with RTP-B.
> > > > > > >
> > > > > > > It is possible to have one termination that had two
> > > > streams (the A
> > > > > > > stream and the B stream) and then the context would have 3
> > > > > > terminations, the
> > > > > > > translator, the "A" RTP and the "B" RTP.  Then you would
> > > > > > use streamIDs to
> > > > > > > keep the streams straight (no need to use topology).
> > > > > > > This is one of the things I don't like about what we did,
> > > > > > two ways to
> > > > > > > do the same thing, nothing but "taste" to decide
> > which to use,
> > > > > > > guaranteed interoperability problems unless some package is
> > > > > > standardized.
> > > > > > > Oh well.  Anyway, I think modeling the translator
> > as having two
> > > > > > > terminations, an A termination and a B termination,
> > > > each with one
> > > > > > > stream, is the best way to do it.
> > > > > > >
> > > > > > > In fact, you may have noticed that I used the same
> > model for the
> > > > > > > weird function bridge a few emails back -- I think
> > > > whenever we have
> > > > > > > odd-function devices, we should model the "ports"
> > of the device
> > > > > > > as a termination implementing a specific package.  In
> > > > this specific
> > > > > > > case the ports are symmetric (because the flows are
> > > > send-receive),
> > > > > > > but in the general case, they may not be.
> > > > > > >
> > > > > > > Brian
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Chip Sharp [mailto:chsharp@cisco.com]
> > > > > > > > Sent: Friday, April 14, 2000 3:58 PM
> > > > > > > > To: Rosen, Brian; MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > > > Subject: Re: Multiple streams per call,
> > > > > > > >
> > > > > > > >
> > > > > > > > At 02:33 PM 4/14/00 -0400, Rosen, Brian wrote:
> > > > > > > >
> > > > > > > > ...snip...
> > > > > > > >
> > > > > > > > >Sure.  Look at it from the point of view of the MGs.
> > > > > > You have MG-A,
> > > > > > > > >MG-B and MG1.  MG-A has a termination with two
> > > > streams, video and
> > > > > > > > >audio.  It is commanded by the MGC to set up a single
> > > > > > context with
> > > > > > > > >the termination and two RTP connections, call them
> > > > > > RTP-A-Audio and
> > > > > > > > >RTP-A-Video.  The address it assigns to
> > RTP-A-Audio is MG-B.
> > > > > > > > >The address it assigns RTP-A-Video is MG1.
> > > > > > > > >Again, this is a single context, with the physical
> > > > termination
> > > > > > > > >having two streams, and each of the RTP terminations
> > > > having one
> > > > > > > > >stream each.
> > > > > > > >
> > > > > > > > I assume when you say "RTP connections" above,
> > you mean "RTP
> > > > > > > > terminations"
> > > > > > > > since the word "connection" isn't allowed in megaco. (your
> > > > > > > > MGCP is showing
> > > > > > > > ;-) ).
> > > > > > > > I'm not sure what kind of termination you are
> > talking about,
> > > > > > > > but I'll call
> > > > > > > > it X.
> > > > > > > >
> > > > > > > > In MG-A, Terminations X, RTP-A-Audio and RTP-A-Video all
> > > > > > > > belong to the same
> > > > > > > > context, say Context A.  Termination X has 2
> > streams assigned
> > > > > > > > to it.  One
> > > > > > > > stream contains the video, the other stream contains the
> > > > > > > > audio (both in
> > > > > > > > send-receive).  Termination RTP-A-Audio would be
> > configured
> > > > > > > > with only the
> > > > > > > > Audio stream.  Termination RTP-A-Video would be configured
> > > > > > > > with only the
> > > > > > > > Video stream.
> > > > > > > >
> > > > > > > > Therefore the video stream goes to MG1 and the
> > audio stream
> > > > > > > > goes to MGB, as
> > > > > > > > described.
> > > > > > > >
> > > > > > > >
> > > > > > > > >Look at MG1.  It has two terminations, with one
> > > > stream each.  It
> > > > > > > > >is asked to set up two contexts, one with an RTP
> > > > connecting to
> > > > > > > > >MG-A and the other with its RTP connection to
> > MG-B.  That's
> > > > > > > > >two contexts, each with two terminations, with
> > one stream in
> > > > > > > > >each of the contexts.
> > > > > > > >
> > > > > > > > I'm not sure what the two mystery terminations
> > are again, but
> > > > > > > > I'll call
> > > > > > > > them Y and Z.
> > > > > > > >
> > > > > > > > Terminations Y and RTP-A belong to a context A and
> > > > > > contain one stream.
> > > > > > > > Terminations Z and RTP-B belong to a context B and
> > > > > > contain one stream.
> > > > > > > >
> > > > > > > > The video stream from MGA comes into context A via
> > > > > > > > Termination RTP-A and
> > > > > > > > ends up on Termination Y (and vice versa).
> > > > > > > >
> > > > > > > > Whatever is on termination Z is transmitted out RTP-B via
> > > > > > > > context B (and
> > > > > > > > vice versa).
> > > > > > > >  From the below, it seems video is connected to
> > MG-B; however
> > > > > > > > there is no
> > > > > > > > context containing Terminations Z & Y to allow them to
> > > > > > > > communicate under
> > > > > > > > the control of megaco.  Therefore, I assume that
> > some internal
> > > > > > > > implementation-specific mechanism connects
> > terminations Y & Z
> > > > > > > > in order to
> > > > > > > > get the video from Context A into context B.
> > > > > > > > MG1 could just have 2 RTP terminations with one
> > stream in one
> > > > > > > > context.  Of
> > > > > > > > course, H.248 forbids a termination from belonging to
> > > > > > more than one
> > > > > > > > context, so you can't just create a context
> > containing X & Y.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > >Of course, MG-B has a similar setup to MG-A -- it's
> > > > > > audio connects
> > > > > > > > >to MG-A, the video connects to MG1.
> > > > > > > > >
> > > > > > > > >Now look at it from the MGC.  The "call" has 3
> > > > Megaco contexts.
> > > > > > > > >The MG-A to MG-B audio, the MG-A to MG1 video and
> > > > the MG1 to MG-B
> > > > > > > > >video.
> > > > > > > >
> > > > > > > > Yes, but the MGC has no idea how the video gets from
> > > > > > Termination X to
> > > > > > > > Termination Y in MG1.
> > > > > > > >
> > > > > > > > Thanks for the illustration.  I haven't really
> > thought about
> > > > > > > > it in a while.
> > > > > > > >
> > > > > > > >
> > > > > > > > >I'm still not thrilled with the whole stream idea, but
> > > > > > it does work.
> > > > > > > > >
> > > > > > > > >Brian
> > > > > > > >
> > > > > > > > http://www.netaid.org
> > > > > > > >
> > --------------------------------------------------------------
> > > > > > > > -----------
> > > > > > > > Chip Sharp                 CTO Consulting Engineering
> > > > > > > > Cisco Systems
> > > > > > > > Reality - Love it or Leave it.
> > > > > > > >
> > --------------------------------------------------------------
> > > > > > > > ----------
> > > > > > > >
> > > > > >
> > > > > > --
> > > > > > John Segers                                  email:
> > > > jsegers@lucent.com
> > > > > > Lucent Technologies
> > > >  Room HE 306
> > > > > > 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 Apr 26 09:49:12 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26579
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 26 Apr 2000 09:49:11 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AD1A2C60@standards.nortelnetworks.com>; Wed, 26 Apr 2000 9:42:03 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 16532 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Apr 2000 09:41:48 -0400
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.2B1FE6B0@standards.nortelnetworks.com>; Wed, 26 Apr 2000 9:31:15
          -0400
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id JAA25743; Wed, 26 Apr
          2000 09:37:20 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id JAA28519; Wed, 26 Apr
          2000 09:37:22 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <2MSF7D6Z>; Wed, 26 Apr 2000 09:31: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:  <4FBEA8857476D311A03300204840E1CF67821E@whq-msgusr-02.fore.com>
Date:         Wed, 26 Apr 2000 09:37:18 -0400
Reply-To: "Rosen, Brian" <brosen@FORE.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <brosen@FORE.COM>
Subject:      Re: Multiple streams per call,
X-To:         Tom-PT Taylor <taylor@nortelnetworks.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I see it as a style issue - the more uniform packages (and gateways)
are built, the more likely there will be wide interoperability.
What I would really hate to see is one vendor building MCUs one way,
and other building them another way, so that it was a tremendous
amount of code for one MGC to control both kinds.

Multimedia contexts aren't the issue.  The issue is what is the
general way to model a device that does not have an explicit
protocol mechanism to support it.  The really amusing part of this
discussion is that I was one of the folks in the design team meeting
in Minneapolis that seized on the idea of having each termination be
able to have a different media specification with implicit translation
between them!  It's still a very elegant mechanism, and I've said
so in the context of the translator.  I'm more worried about influencing
the design of packages to ease the burden on the MGC of supporting
lots of MGs.  We can't control it -- we aren't any more effective as
the package police than we are as the protocol police!

Brian

> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> Sent: Wednesday, April 26, 2000 9:15 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: Multiple streams per call,
>
>
> It seems to me that this is only marginally a standardization
> issue.  You
> may want to build your GW one way, another vendor
> differently.  We will have
> to think about whether we have to define properties to allow
> the MGC to
> discover the difference in internal organization.
>
> :-) My suspicion is that, having stoutly resisted the
> multimedia context
> model, you'd like to bury it on the rebound.
>
> > -----Original Message-----
> > From: Rosen, Brian [SMTP:brosen@FORE.COM]
> > Sent: Wednesday, April 26, 2000 8:37 AM
> > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject:      Re: Multiple streams per call,
> >
> > The reason it's not a v2 issue is that it affects how you design
> > a package for a cs1 implementation of some kind of capability not
> > specifically catered for.
> >
> > In the discussions of "topology" we had a similar disagreement, with
> > the same actors :(.  The topology mechanism works for most common
> > implementations of an audio mixing bridge.  The protocol does not
> > have a mechanism to extend topology, nor to add context properties.
> > We do have the package mechanism.  If I wanted to build a
> very flexible
> > MCU which allowed a wide range of video and audio effects,
> I can't do
> > it with "bare" cs1 capabilities (my "what does T1/T2 bothways mean
> > for a tiling video MCU?" question).
> >
> > On the other hand, I can do it with the mechanism I
> propose.  In fact,
> > it's pretty hard to think of any kind of media device I
> cannot control
> > pretty nicely with such a mechanism.  That is a very good feature of
> > the protocol.
> >
> > Now, what I'm advocating is that we use that mechanism uniformly.
> >
> > What we are discussing is a kind of corner case - the "two RTPs with
> > different media specifications, implied translation" clearly is
> > within the capabilities of the protocol.  It does work.  But all
> > you need to do is add one twist - say that the translator is also a
> > multimedia MCU, and now you can't use the same model.  That is a bad
> > idea.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > > Sent: Wednesday, April 26, 2000 12:34 AM
> > > To: Rosen, Brian
> > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Multiple streams per call,
> > >
> > >
> > > I like the 'elegant method'. I thought that context
> > > properties could be
> > > used in the situations where the elegant didn't work.
> This I thought
> > > would be the most generic.
> > >
> > > I agree that using the 'internal' termination model is a
> > > valid modelling
> > > technique but I wonder if it is more uniform. ie. Conferences
> > > today are
> > > handled by context but we could equally have a context
> with a mixing
> > > termination and then hang off individual context and
> terminations for
> > > the subscriber legs.
> > >
> > > I think this is something for discussion for v2, either
> approach is
> > > interesting.
> > >
> > > Cheers, Christian
> > >
> > > "Rosen, Brian" wrote:
> > > >
> > > > This is beyond the current discussion.  The question
> is, in general,
> > > > how do we model devices that are "different".  In the
> case cited,
> > > > media translation, we could model it as a two
> termination context,
> > > > with the RTP flows, specified by media descriptors,
> describing the
> > > > two sides, and an implicit translation in between.
> This certainly
> > > > works, and is pretty elegant.
> > > >
> > > > The problem is that it doesn't work for all kinds of devices,
> > > > and I wondered if we should model them in a more uniform way.  I
> > > > suggested a set of two termination contexts with an "internal"
> > > > termination that can have characteristics ascribed to it by a
> > > > set of packages implemented on it, and an RTP termination that
> > > > had the external flow on it.  This would also work for the
> > > translator,
> > > > but requires more terminations and more contexts, and thus is
> > > > somewhat less elegant.  It too would work, and has the
> advantage of
> > > > being able to be used for a much wider range of applications.
> > > >
> > > > Brian
> > > >
> > > > Brian
> > > >
> > > > > -----Original Message-----
> > > > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> > > > > Sent: Friday, April 21, 2000 9:36 AM
> > > > > To: MEGACO@standards.nortelnetworks.com
> > > > > Subject: Re: Multiple streams per call,
> > > > >
> > > > >
> > > > > My view of something like tiling is that we need a per-stream
> > > > > property to
> > > > > express mixing method.  I didn't push this last summer
> > > > > because it was clear
> > > > > that it would have to be designed by specialists in the area,
> > > > > and I figured
> > > > > they should be the ones to step up to the plate when they are
> > > > > serious about
> > > > > building product using Megaco/H.248.
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Rosen, Brian [SMTP:brosen@FORE.COM]
> > > > > > Sent: Friday, April 21, 2000 8:58 AM
> > > > > > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > Subject:      Re: Multiple streams per call,
> > > > > >
> > > > > > Yes, the translation MG, you could construct a context with
> > > > > > two RTP ports and use the SDP to imply translation.  The
> > > > > protocol would
> > > > > > allow that.
> > > > > >
> > > > > > The problem is that it would work for things that are
> > > > > expressible in SDP,
> > > > > > but not for more general mechanisms.  For example, suppose
> > > > > you wanted
> > > > > > an MCU that did tiling.  I'd prefer that we use one
> > > > > mechanism for all of
> > > > > > these
> > > > > > kinds of problems.
> > > > > >
> > > > > > And, yes Christian, SDP is shorthand for "SDP or Annex C"
> > > > > >
> > > > > > Brian
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: John Segers [mailto:jsegers@lucent.com]
> > > > > > > Sent: Friday, April 21, 2000 5:52 AM
> > > > > > > To: Rosen, Brian
> > > > > > > Cc: MEGACO@standards.nortelnetworks.com
> > > > > > > Subject: Re: Multiple streams per call,
> > > > > > >
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > Having been away from the list for a while, I've got some
> > > > > > > catching up to
> > > > > > > do!  Although this thread is probably less urgent
> > > than some of the
> > > > > > > others, this one being related to more advanced (future)
> > > > > > > functionality,
> > > > > > > I'll jump in on this first.
> > > > > > >
> > > > > > > Comparing Brian's proposal for the video translator to
> > > > > less exotic MG
> > > > > > > devices that translate audio, I wonder why the extra ports
> > > > > > > are needed.
> > > > > > > In the audio case, the required transcoding, e.g. from
> > > > > G.711 A-law to
> > > > > > > G.723.1 is inferred from the Termination type/name and/or
> > > > > RTP payload
> > > > > > > type.  No extra ports are introduced to model the
> translator
> > > > > > > resource.
> > > > > > > Why can't it work the same for video?
> > > > > > >
> > > > > > > Cheers,
> > > > > > >
> > > > > > > John
> > > > > > >
> > > > > > > "Rosen, Brian" wrote:
> > > > > > > >
> > > > > > > > You seem to have everything correct!
> > > > > > > >
> > > > > > > > You are worried about the video translator.  The
> > > > > problem statement
> > > > > > > > was MG-A and MG-B did not have a common video encoding,
> > > > > so the MGC
> > > > > > > > wanted to insert a translator to fix the problem.
> > > > > > > >
> > > > > > > > I think this is very reasonable to do, and I
> would model the
> > > > > > > > translator as a set of pairs of terminations - The
> > > "A" side and
> > > > > > > > the "B" side.  Trying to push these into a single
> > > context, to
> > > > > > > > my way of thinking, is very weird.  Much
> cleaner to have two
> > > > > > > > separate contexts.  I waffled over whether to represent
> > > > > the "ports"
> > > > > > > > of the translator as physical terminations.  In
> > > > > reality, they could
> > > > > > > > be, if the translator was some hard wired fixed
> > > function.  It is
> > > > > > > > possible that it could just be a fancy DSP, and
> the number
> > > > > > > of translations
> > > > > > > > it could do was a variable, determined by what
> > > > > > > > translations were in use.  For example, it might be
> > > able to do
> > > > > > > > 10 MPEG 1 to MPEG 2 translations, but only 3
> MPEG2 to H.261
> > > > > > > translations.
> > > > > > > > In this case, it might be better to model the ports
> > > as ephemeral
> > > > > > > > terminations.  I would still represent them as pairs of
> > > > > > > terminations,
> > > > > > > > which would go in pairs of two termination
> > > contexts, the other
> > > > > > > > termination being (for example) the RTP termination.
> > > > > > > >
> > > > > > > > To help your thinking, instead of calling those
> > > > > > > terminations Y and Z,
> > > > > > > > call them XLate/A and XLate/B.  If the box could do
> > > > > more than one,
> > > > > > > > maybe we would call them XL/1/A and XL/1/B, so you
> > > > > could talk about
> > > > > > > > XL/4/A for example.  Then XL/1/A is in a context
> > > with RTP-A, and
> > > > > > > > XL/1/B is in context with RTP-B.
> > > > > > > >
> > > > > > > > It is possible to have one termination that had two
> > > > > streams (the A
> > > > > > > > stream and the B stream) and then the context
> would have 3
> > > > > > > terminations, the
> > > > > > > > translator, the "A" RTP and the "B" RTP.  Then you would
> > > > > > > use streamIDs to
> > > > > > > > keep the streams straight (no need to use topology).
> > > > > > > > This is one of the things I don't like about
> what we did,
> > > > > > > two ways to
> > > > > > > > do the same thing, nothing but "taste" to decide
> > > which to use,
> > > > > > > > guaranteed interoperability problems unless
> some package is
> > > > > > > standardized.
> > > > > > > > Oh well.  Anyway, I think modeling the translator
> > > as having two
> > > > > > > > terminations, an A termination and a B termination,
> > > > > each with one
> > > > > > > > stream, is the best way to do it.
> > > > > > > >
> > > > > > > > In fact, you may have noticed that I used the same
> > > model for the
> > > > > > > > weird function bridge a few emails back -- I think
> > > > > whenever we have
> > > > > > > > odd-function devices, we should model the "ports"
> > > of the device
> > > > > > > > as a termination implementing a specific package.  In
> > > > > this specific
> > > > > > > > case the ports are symmetric (because the flows are
> > > > > send-receive),
> > > > > > > > but in the general case, they may not be.
> > > > > > > >
> > > > > > > > Brian
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Chip Sharp [mailto:chsharp@cisco.com]
> > > > > > > > > Sent: Friday, April 14, 2000 3:58 PM
> > > > > > > > > To: Rosen, Brian; MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > > > > Subject: Re: Multiple streams per call,
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > At 02:33 PM 4/14/00 -0400, Rosen, Brian wrote:
> > > > > > > > >
> > > > > > > > > ...snip...
> > > > > > > > >
> > > > > > > > > >Sure.  Look at it from the point of view of the MGs.
> > > > > > > You have MG-A,
> > > > > > > > > >MG-B and MG1.  MG-A has a termination with two
> > > > > streams, video and
> > > > > > > > > >audio.  It is commanded by the MGC to set up a single
> > > > > > > context with
> > > > > > > > > >the termination and two RTP connections, call them
> > > > > > > RTP-A-Audio and
> > > > > > > > > >RTP-A-Video.  The address it assigns to
> > > RTP-A-Audio is MG-B.
> > > > > > > > > >The address it assigns RTP-A-Video is MG1.
> > > > > > > > > >Again, this is a single context, with the physical
> > > > > termination
> > > > > > > > > >having two streams, and each of the RTP terminations
> > > > > having one
> > > > > > > > > >stream each.
> > > > > > > > >
> > > > > > > > > I assume when you say "RTP connections" above,
> > > you mean "RTP
> > > > > > > > > terminations"
> > > > > > > > > since the word "connection" isn't allowed in
> megaco. (your
> > > > > > > > > MGCP is showing
> > > > > > > > > ;-) ).
> > > > > > > > > I'm not sure what kind of termination you are
> > > talking about,
> > > > > > > > > but I'll call
> > > > > > > > > it X.
> > > > > > > > >
> > > > > > > > > In MG-A, Terminations X, RTP-A-Audio and
> RTP-A-Video all
> > > > > > > > > belong to the same
> > > > > > > > > context, say Context A.  Termination X has 2
> > > streams assigned
> > > > > > > > > to it.  One
> > > > > > > > > stream contains the video, the other stream
> contains the
> > > > > > > > > audio (both in
> > > > > > > > > send-receive).  Termination RTP-A-Audio would be
> > > configured
> > > > > > > > > with only the
> > > > > > > > > Audio stream.  Termination RTP-A-Video would
> be configured
> > > > > > > > > with only the
> > > > > > > > > Video stream.
> > > > > > > > >
> > > > > > > > > Therefore the video stream goes to MG1 and the
> > > audio stream
> > > > > > > > > goes to MGB, as
> > > > > > > > > described.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > >Look at MG1.  It has two terminations, with one
> > > > > stream each.  It
> > > > > > > > > >is asked to set up two contexts, one with an RTP
> > > > > connecting to
> > > > > > > > > >MG-A and the other with its RTP connection to
> > > MG-B.  That's
> > > > > > > > > >two contexts, each with two terminations, with
> > > one stream in
> > > > > > > > > >each of the contexts.
> > > > > > > > >
> > > > > > > > > I'm not sure what the two mystery terminations
> > > are again, but
> > > > > > > > > I'll call
> > > > > > > > > them Y and Z.
> > > > > > > > >
> > > > > > > > > Terminations Y and RTP-A belong to a context A and
> > > > > > > contain one stream.
> > > > > > > > > Terminations Z and RTP-B belong to a context B and
> > > > > > > contain one stream.
> > > > > > > > >
> > > > > > > > > The video stream from MGA comes into context A via
> > > > > > > > > Termination RTP-A and
> > > > > > > > > ends up on Termination Y (and vice versa).
> > > > > > > > >
> > > > > > > > > Whatever is on termination Z is transmitted
> out RTP-B via
> > > > > > > > > context B (and
> > > > > > > > > vice versa).
> > > > > > > > >  From the below, it seems video is connected to
> > > MG-B; however
> > > > > > > > > there is no
> > > > > > > > > context containing Terminations Z & Y to allow them to
> > > > > > > > > communicate under
> > > > > > > > > the control of megaco.  Therefore, I assume that
> > > some internal
> > > > > > > > > implementation-specific mechanism connects
> > > terminations Y & Z
> > > > > > > > > in order to
> > > > > > > > > get the video from Context A into context B.
> > > > > > > > > MG1 could just have 2 RTP terminations with one
> > > stream in one
> > > > > > > > > context.  Of
> > > > > > > > > course, H.248 forbids a termination from belonging to
> > > > > > > more than one
> > > > > > > > > context, so you can't just create a context
> > > containing X & Y.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > >Of course, MG-B has a similar setup to MG-A -- it's
> > > > > > > audio connects
> > > > > > > > > >to MG-A, the video connects to MG1.
> > > > > > > > > >
> > > > > > > > > >Now look at it from the MGC.  The "call" has 3
> > > > > Megaco contexts.
> > > > > > > > > >The MG-A to MG-B audio, the MG-A to MG1 video and
> > > > > the MG1 to MG-B
> > > > > > > > > >video.
> > > > > > > > >
> > > > > > > > > Yes, but the MGC has no idea how the video gets from
> > > > > > > Termination X to
> > > > > > > > > Termination Y in MG1.
> > > > > > > > >
> > > > > > > > > Thanks for the illustration.  I haven't really
> > > thought about
> > > > > > > > > it in a while.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > >I'm still not thrilled with the whole stream
> idea, but
> > > > > > > it does work.
> > > > > > > > > >
> > > > > > > > > >Brian
> > > > > > > > >
> > > > > > > > > http://www.netaid.org
> > > > > > > > >
> > > --------------------------------------------------------------
> > > > > > > > > -----------
> > > > > > > > > Chip Sharp                 CTO Consulting Engineering
> > > > > > > > > Cisco Systems
> > > > > > > > > Reality - Love it or Leave it.
> > > > > > > > >
> > > --------------------------------------------------------------
> > > > > > > > > ----------
> > > > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > John Segers                                  email:
> > > > > jsegers@lucent.com
> > > > > > > Lucent Technologies
> > > > >  Room HE 306
> > > > > > > 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 Apr 26 11:15:11 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28152
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 26 Apr 2000 11:15:11 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B7AFB6C0@standards.nortelnetworks.com>; Wed, 26 Apr 2000 11:08:14 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 16708 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Apr 2000 11:06:55 -0400
Received: from smtprtp1.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.885DC2E0@standards.nortelnetworks.com>; Wed, 26 Apr 2000 11:06:55
          -0400
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          smtprtp1.ntcom.nortel.net; Wed, 26 Apr 2000 11:11:45 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <27B9Q1SA>; Wed, 26 Apr 2000 11:10:55 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B70E@zcard00g.ca.nortel.com>
Date:         Wed, 26 Apr 2000 11:10:49 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: E.10.3 Signals (Basic Continuity Package)
X-To:         Al Varney <varney@LUCENT.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Thank you for your words.  I'll put them into the errata document.

> -----Original Message-----
> From: Al Varney [SMTP:varney@LUCENT.COM]
> Sent: Tuesday, April 25, 2000 5:24 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: E.10.3 Signals (Basic Continuity Package)
>
> At 02:14 04/25/2000 -0400, Tom-PT Taylor wrote:
>
>
>       > From: Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]
>       > Sent: Monday, April 03, 2000 5:45 PM
>
>
>       > The Respond SignalID: rsp (0x004)  has a Signal Type of Timeout.
>       >
>       > Looking at Section 10.5,
>       > "Upon reception of a command with the rsp signal, the MG
>       > awaits reception of the continuity test tone.  When the tone is
> received
>       > before the rsp signal times out, the MG returns the applicable
> return
>       > tone."
>       >
>       > What is the duration of this Respond Signal?  The text seems to
> imply that
>       > the Signal Type is
>       > Timeout but it is used to timeout the reception of the continuity
> test
>       > tone.
>       > Is the intend that the Respond Signal has the same duration as the
> Timeout
>       > for the detection of
>       > the continuity test tone?
>               [PTT]
>               I'd like someone to confirm the correctness of the procedure
> as
>       quoted.  My understanding of continuity testing varies on two
> points:
>                - sometimes the responder just does a loopback rather than
>       detecting a tone and playing out another
>                - the responder continues to respond until told by the MGC
> to stop.
>               Am I wrong?
>
>
>    For ISUP/TUP continuity testing, there are two procedures:
> Case 1:  A 4-wire test described in Q.764, Section 7
> Case 2:  A 2-wire test described in Q.764, Section 8
>
>    You are correct on both "-" items above, but so is the quoted
> procedure, with some interpretation.  In Case 1, the tested switch (doing
> ct/rsp) only needs a loop-back (called a "check-loop" in Q.724).  In Case
> 2, the tested switch must recognize the incoming test tone and return one
> of a different frequency.  Specifically, the outgoing tone is ON whenever
> the incoming tone is ON, and OFF otherwise.  This can occur multiple times
> during one test.  In effect, the return tone "emulates" a loop-back, only
> shifting the test frequency.
>
>    Note that in either Case, the testing switch (the one doing ct/ct in
> Megaco) is the one that determines test timing, duration and
> success/failure.  The tested switch should not attempt to do anything
> other than reflect back what is received.  Because of glare
> considerations, the national option of detecting both the presence of a
> returned tone and the removal of a returned tone is often used.  That is
> why the return tone in Case 2 must be removed whenever the incoming test
> tone is not being detected.
>
>
>
>       > If the Respond Signal duration is TimeOut, MGC gets indication
> from
>       > Central Office that
>       > COT test successful, should MGC sends a Modify to stop the Respond
> Signal
>       > or
>       > just let it play until Timeout?
>       > If let it plays until Timeout, will or should MG sends Notify
> w/COT failed
>       > due to Timeout of
>       > Respond Signal?
>       >
>       > Or should the Respond Signal be Brief or ON/OFF?
>               [PTT]
>               If it is correct that the responder continues running the
> test until
>       call signalling indicates that it can stop, then no timeout is
> needed and
>       the rsp signal should be ON/OFF.
>
>
>
>    That's how it works in ISUP PSTN switches today.  Whether initiated by
> an IAM (indicating "continuity check required on this circuit") or by a
> CCR, the receiving MGC will be running ISUP timer T8 or T36, waiting for
> the sending switch to send a COT or other message to end the test.  So
> there is no need to actually have a timer on the "ct/rsp signal" -- in
> fact, there are may be good reasons to leave a loop-back in place for a
> long period of time.  On the other hand, there are no OnOff Signal Types
> anywhere else in Annex E, so a (long) timer could just insure the MGC
> didn't forget about the termination....
>
>    I suggest a clarified version of the referenced paragraph in E.10.5,
> with the ct/rsp Signal Type changed to OnOff :
>
>      "When a MGC wants the MG to respond to a continuity test, it sends
>       a command to the MG containing a signals descriptor with the rsp
>       signal. Upon reception of a command with the rsp signal, the MG
>       either applies a loop-back or (for 2-wire circuits) awaits reception
>       of a continuity test tone.  In the loop-back case, any incoming
>       information shall be reflected back as outgoing information.  In the
>       2-wire case, any time the appropriate test tone is received, the
>       appropriate response tone should be sent.  The MGC will determine
>       when to remove the rsp signal.
>
>    The current version of E.10 is much improved, but it did result in
> dropping all references to Q.724.  Rather than add in a lot more text to
> explain "2-wire", etc., why not add back in a ("See Q.724 Sections 7 and 8
> for further information.") at the end?
>
>    One last note -- Telcordia's GR-317 has a better (IMHO) description of
> the continuity test procedure.  It also indicates the desirability of
> performing the "2-wire" test even on 4-wire circuits, since it will detect
> instances where digital transmission facilities have been inadvertently
> left in a loop-back mode.  So don't ignore Case 2 above just because an MG
> may only be connecting to 4-wire circuits.
>
> Al Varney - Lucent Technologies  +1 630 224-7493    varney@lucent.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Apr 26 13:30:49 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00848
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 26 Apr 2000 13:30:49 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A75C3330@standards.nortelnetworks.com>; Wed, 26 Apr 2000 13:23:47 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 17116 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Apr 2000 13:22:35 -0400
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.7BF84260@standards.nortelnetworks.com>; Wed, 26 Apr 2000
          13:22:35 -0400
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Wed, 26 Apr 2000 12:28:14 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <JSPAPA9V>; Wed, 26 Apr 2000 12:28:02 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD1193B712@zcard00g.ca.nortel.com>
Date:         Wed, 26 Apr 2000 12:27:54 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Multiple Profiles; Representation of Empty Descriptors
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Here are a couple of miscellaneous issues that have popped up.

(1) It seems reasonable that the MGC, at least, may be capable of supporting
multiple profiles.  The syntax should be altered to allow this.

(2) Suppose a given descriptor is empty on a given termination.  In
particular, suppose there is nothing in the Events descriptor, or no active
digit map.  What is the syntax for representing this in a response to the
MGC?

Proposal: represent an empty descriptor by giving its name alone.  The
simplest way to represent this is to change the syntax of
auditReturnParameter to add auditItem as an additional possibility.

e.g. In step 20 of the Annex A example, where the audit has requested Media,
DigitMap, Events, Signals, Packages, and Statistics descriptors, the
response would be

MEGACO/1 [125.125.125.111]:55555
Reply = 50007 {
   Context = - {
AuditValue = A5556 {
          Media {
             TerminationState { ServiceStates = InService,
EventBufferControl = OFF },
             Stream = 1 {
                 LocalControl { Mode = SendReceive,
                    nt/jit=40 },
                 Local {
v=0
c=IN IP4 125.125.125.111
m=audio 1111 RTP/AVP  4
a=ptime:30
                },
                 Remote {
v=0
c=IN IP4 124.124.124.222
m=audio 2222 RTP/AVP  4
a=ptime:30
                 } } },
          Events,
          Signals,
          DigitMap,
          Packages {nt-1, rtp-1},
          Statistics { rtp/ps=1200,  ; packets sent
                       nt/os=62300, ; octets sent
                       rtp/pr=700, ; packets received
                       nt/or=45100, ; octets received
                       rtp/pl=0.2,  ; % packet loss
                       rtp/jit=20,
                       rtp/delay=40 } ; avg latency
       }
    }
}


Tom Taylor
Phone and FAX: +1 613 736 0961
E-mail: taylor@nortelnetworks.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Apr 26 14:43:51 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02191
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 26 Apr 2000 14:43:51 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E2825DE0@standards.nortelnetworks.com>; Wed, 26 Apr 2000 14:37:02 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 17245 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Apr 2000 14:35:15 -0400
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.3D245750@standards.nortelnetworks.com>; Wed, 26 Apr 2000 14:25:15
          -0400
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id OAA00332; Wed, 26 Apr
          2000 14:31:16 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id OAA03994; Wed, 26 Apr
          2000 14:31:18 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <2MSF7MWV>; Wed, 26 Apr 2000 14:25:52 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF678226@whq-msgusr-02.fore.com>
Date:         Wed, 26 Apr 2000 14:31:14 -0400
Reply-To: "Rosen, Brian" <brosen@FORE.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <brosen@FORE.COM>
Subject:      Re: Multiple Profiles; Representation of Empty Descriptors
X-To:         Tom-PT Taylor <taylor@nortelnetworks.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

> (1) It seems reasonable that the MGC, at least, may be
> capable of supporting
> multiple profiles.  The syntax should be altered to allow this.
I'm not sure a syntax change is needed for the case of MGC support
of multiple profiles.  The registration process always starts with
the MG sending serviceChange.  If it specifies a profile, the MGC
responds with the same profile if it can support it, or it's best
suggestion if it can't.  Words to that effect should be added.
Could consider an error code of "Can't support that profile"

>
> (2) Suppose a given descriptor is empty on a given termination.  In
> particular, suppose there is nothing in the Events
> descriptor, or no active
> digit map.  What is the syntax for representing this in a
> response to the
> MGC?
>
> Proposal: represent an empty descriptor by giving its name alone.  The
> simplest way to represent this is to change the syntax of
> auditReturnParameter to add auditItem as an additional possibility.
This is okay with me, although Events{} would be okay with me also.


Brian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Apr 26 15:10:13 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02888
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 26 Apr 2000 15:10:12 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.89D17420@standards.nortelnetworks.com>; Wed, 26 Apr 2000 15:03:11 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 17398 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Apr 2000 15:02:21 -0400
Received: from smtprtp.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.6C636D30@standards.nortelnetworks.com>; Wed, 26 Apr 2000 15:02:21
          -0400
Received: from zrtpd00y.us.nortel.com (actually zrtpd00y) by
          smtprtp.ntcom.nortel.net; Wed, 26 Apr 2000 15:08:35 -0400
Received: by zrtpd00y.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <24DY3XKK>; Wed, 26 Apr 2000 15:08:36 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BFAFB2.D2C44BA4"
Message-ID:  <5F68FAE98163D21193750000F81AC9BE010FE05C@zrtpd00x.us.nortel.com>
Date:         Wed, 26 Apr 2000 15:08:29 -0400
Reply-To: David Cromwell <cromwell@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: David Cromwell <cromwell@NORTELNETWORKS.COM>
Subject:      Re: Open Issue: Sublist vs. Alternatives
X-To:         Tom-PT Taylor <taylor@nortelnetworks.com>
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_01BFAFB2.D2C44BA4
Content-Type: text/plain

Agreed.  The Advanced Audio Package already makes extensive use of square
bracket sublists.

David
--
cromwell@nortelnetworks.com                   Nortel Networks
ESN:            351-8870                              35 Davis Dr
Public:    919-991-8870                              RTP, NC 27709

> -----Original Message-----
> From: Taylor, Tom-PT [NORSE:B901:EXCH]
> Sent: Monday, April 24, 2000 10:27 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Open Issue: Sublist vs. Alternatives
>
> In production alternativeValue in Annex B.2, we still have the open issue
> that the syntax for over-specification and that for sub-lists is
> apparently
> the same: LSBRKT VALUE *(COMMA VALUE) RSBRKT.  How about enclosing
> sub-lists
> in square brackets and sets of alternative values in curly brackets?
> Combined with an accepted fix for ranges this gives:
>
>  alternativeValue = (VALUE                                       ; single
> value
>        /  LSBRKT VALUE *(COMMA VALUE) RSBRKT  ; sub-list
>        /  LBRKT VALUE *(COMMA VALUE) RBRKT      ; alternatives
>        /   LSBRKT VALUE COLON VALUE RSBRKT )   ; range
>
> ASN.1 encoding also lacks sub-list support.  I suggest that it be added as
> a
> BOOLEAN choice in extrainfo within the PropertyParm production.
>
>
> Tom Taylor
> Phone and FAX: +1 613 736 0961
> E-mail: taylor@nortelnetworks.com

------_=_NextPart_001_01BFAFB2.D2C44BA4
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2651.65">
<TITLE>RE: Open Issue: Sublist vs. Alternatives</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">Agreed.&nbsp; The =
Advanced Audio Package already makes extensive use of square bracket =
sublists.</FONT>
</P>

<P><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">David</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">--</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">cromwell@nortelnetworks.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; Nortel Networks&nbsp; </FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">ESN:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; =
351-8870&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 35 Davis Dr</FONT>
<BR><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">Public:&nbsp;&nbsp;&nbsp; =
919-991-8870&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RTP, NC 27709</FONT>
</P>
<UL>
<P><FONT SIZE=3D1 FACE=3D"Arial">-----Original Message-----</FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Taylor, Tom-PT [NORSE:B901:EXCH] </FONT>
<BR><B><FONT SIZE=3D1 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Arial">Monday, April 24, 2000 10:27 PM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Arial">MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
<BR><B><FONT SIZE=3D1 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Arial">Open Issue: Sublist vs. =
Alternatives</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In production alternativeValue in =
Annex B.2, we still have the open issue</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">that the syntax for =
over-specification and that for sub-lists is apparently</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the same: LSBRKT VALUE *(COMMA VALUE) =
RSBRKT.&nbsp; How about enclosing sub-lists</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">in square brackets and sets of =
alternative values in curly brackets?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Combined with an accepted fix for =
ranges this gives:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;alternativeValue =3D =
(VALUE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp; ; single</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">value</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
/&nbsp; LSBRKT VALUE *(COMMA VALUE) RSBRKT&nbsp; ; sub-list</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
/&nbsp; LBRKT VALUE *(COMMA VALUE) RBRKT&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
; alternatives</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
/&nbsp;&nbsp; LSBRKT VALUE COLON VALUE RSBRKT )&nbsp;&nbsp; ; =
range</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">ASN.1 encoding also lacks sub-list =
support.&nbsp; I suggest that it be added as a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">BOOLEAN choice in extrainfo within =
the PropertyParm production.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Tom Taylor</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Phone and FAX: +1 613 736 0961</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">E-mail: =
taylor@nortelnetworks.com</FONT>
</P>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01BFAFB2.D2C44BA4--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Apr 26 15:15:28 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03031
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 26 Apr 2000 15:15:27 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D1FA0C80@standards.nortelnetworks.com>; Wed, 26 Apr 2000 15:05:12 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 17361 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Apr 2000 15:03:35 -0400
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.3296A1E0@standards.nortelnetworks.com>; Wed, 26 Apr 2000 14:53:35
          -0400
Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com
          (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id LAA11920; Wed, 26 Apr 2000
          11:59:49 -0700 (PDT)
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <C51ED84B6F47D211917A0000F8BCBD1193B6EE@zcard00g.ca.nortel.com>
Content-Type: multipart/alternative;
              boundary="------------9EFC953AE0A7A535105B2528"
Message-ID:  <39076785.57C29DF8@cisco.com>
Date:         Wed, 26 Apr 2000 15:02:46 -0700
Reply-To: Flemming Andreasen <fandreas@CISCO.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Flemming Andreasen <fandreas@CISCO.COM>
Organization: Cisco Systems
Subject:      Re: Signalling Failure
X-To:         Tom-PT Taylor <taylor@nortelnetworks.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--------------9EFC953AE0A7A535105B2528
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Tom-PT Taylor wrote:

>
>
> In my opinion the proper solution would be to add the mask to the
> individual signals rather than the completion event, because "failure"
> may be different for different signals.  For instance, interruption by
> an event is normal for dial tone, but abnormal for outpulsing of
> digits.

Good point.

> I hesitate to add yet another parameter, of sub-list type at that, to
> the basic signal mechanism.  Maybe the real problem is that the
> original mechanism is mis-specified: the interesting event is that of
> the signal not completing in the way expected, rather than
> completing.  The way forward may be to replace "notifyCompletion" with
> an optional parameter "expect", with possible values "timeout" or
> "event", representing the expected way the signal terminates.  If
> "expect" is present and the signal does not complete in the expected
> way, a signal failure event is reported (new name for the signal
> completion event, nothing else changes).  If "expect" is absent, a
> signal failure event is reported if and only if the event terminates
> due to other causes (not TO, not event, not replacement of the
> signalling descriptor).

Not sure I see much of a difference between "expect these, tell me about
others" and "tell me about these" but it seems like we agree on the
basic issue. Also, I like your idea about having a set of default
failures you report unless modified by a list - the default you provided
seems good to me.


-- Flemming

>
>
>      -----Original Message-----
>      From:   Flemming Andreasen [SMTP:fandreas@CISCO.COM]
>      Sent:   Tuesday, March 07, 2000 8:28 PM
>
>      5) 7.1.11, second paragraph:    The granularity of the signal
>      completion
>      event defined in E.1.2 is too coarse. There is for example no way
>      to be
>      informed of just failures (which would seem generally desirable)
>      without
>      being more or less flooded by the other completion reasons as
>      well (some
>      of which are more questionable). One simple way out of this is to
>      extend
>      the definition of the signal completion event to include
>      EventsDescriptorParameters where the TerminationMethod(s) of
>      interest
>      could be specified. Also, the term "notifyCompletion" is somewhat
>      of a
>      misnomer.
>
>
--
Flemming Andreasen                Phone: +1 732 452 1667
Cisco Systems                     Fax:   +1 240 359 5839


--------------9EFC953AE0A7A535105B2528
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<p>Tom-PT Taylor wrote:
<blockquote TYPE=CITE>&nbsp;
<p><font face="Arial"><font color="#0000FF"><font size=-1>In my opinion
the proper solution would be to add the mask to the individual signals
rather than the completion event, because "failure" may be different for
different signals.&nbsp; For instance, interruption by an event is normal
for dial tone, but abnormal for outpulsing of digits.</font></font></font></blockquote>
Good point.
<blockquote TYPE=CITE><font face="Arial"><font color="#0000FF"><font size=-1>I
hesitate to add yet another parameter, of sub-list type at that, to the
basic signal mechanism.&nbsp; Maybe the real problem is that the original
mechanism is mis-specified: the interesting event is that of&nbsp; the
signal not completing in the way expected, rather than completing.&nbsp;
The way forward may be to replace "notifyCompletion" with an optional parameter
"expect", with possible values "timeout" or "event", representing the expected
way the signal terminates.&nbsp; If "expect" is present and the signal
does not complete in the expected way, a signal failure event is reported
(new name for the signal completion event, nothing else changes).&nbsp;
If "expect" is absent, a signal failure event is reported if and only if
the event terminates due to other causes (not TO, not event, not replacement
of the signalling descriptor).</font></font></font></blockquote>
Not sure I see much of a difference between "expect these, tell me about
others" and "tell me about these" but it seems like we agree on the basic
issue. Also, I like your idea about having a set of default failures you
report unless modified by a list - the default you provided seems good
to me.
<br>&nbsp;
<p>-- Flemming
<blockquote TYPE=CITE><font face="Arial"><font color="#0000FF"><font size=-1></font></font></font>&nbsp;
<ul><font face="Arial"><font size=-2>-----Original Message-----</font></font>
<br><b><font face="Arial"><font size=-2>From:&nbsp;&nbsp;</font></font></b>
<font face="Arial"><font size=-2>Flemming Andreasen [SMTP:fandreas@CISCO.COM]</font></font>
<br><b><font face="Arial"><font size=-2>Sent:&nbsp;&nbsp;</font></font></b>
<font face="Arial"><font size=-2>Tuesday, March 07, 2000 8:28 PM</font></font>
<p><font face="Arial"><font size=-1>5) 7.1.11, second paragraph:&nbsp;&nbsp;&nbsp;
The granularity of the signal completion</font></font>
<br><font face="Arial"><font size=-1>event defined in E.1.2 is too coarse.
There is for example no way to be</font></font>
<br><font face="Arial"><font size=-1>informed of just failures (which would
seem generally desirable) without</font></font>
<br><font face="Arial"><font size=-1>being more or less flooded by the
other completion reasons as well (some</font></font>
<br><font face="Arial"><font size=-1>of which are more questionable). One
simple way out of this is to extend</font></font>
<br><font face="Arial"><font size=-1>the definition of the signal completion
event to include</font></font>
<br><font face="Arial"><font size=-1>EventsDescriptorParameters where the
TerminationMethod(s) of interest</font></font>
<br><font face="Arial"><font size=-1>could be specified. Also, the term
"notifyCompletion" is somewhat of a</font></font>
<br><font face="Arial"><font size=-1>misnomer.</font></font>
<br>&nbsp;</ul>
</blockquote>

<p>--
<br>Flemming Andreasen&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Phone: +1 732 452 1667
<br>Cisco Systems&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Fax:&nbsp;&nbsp; +1 240 359 5839
<br>&nbsp;</html>

--------------9EFC953AE0A7A535105B2528--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Apr 26 15:15:28 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03033
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 26 Apr 2000 15:15:28 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1B72F2A0@standards.nortelnetworks.com>; Wed, 26 Apr 2000 15:07:15 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 17444 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Apr 2000 15:06:34 -0400
Received: from smtprtp.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.031AA5E0@standards.nortelnetworks.com>; Wed, 26 Apr 2000 15:06:34
          -0400
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          smtprtp.ntcom.nortel.net; Wed, 26 Apr 2000 15:12:48 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <27B9QNSY>; Wed, 26 Apr 2000 15:12:50 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD11038583DD@zcard00g.ca.nortel.com>
Date:         Wed, 26 Apr 2000 15:12:44 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Multiple Profiles; Representation of Empty Descriptors
X-To:         "Rosen, Brian" <brosen@fore.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Is there not a possibility that an MG supports multiple profiles?  I
shouldn't have been so cautious in my initial proposal.

The problem with Events{} in particular is that you're supposed to have a
requestId in there.

> -----Original Message-----
> From: Rosen, Brian [SMTP:brosen@fore.com]
> Sent: Wednesday, April 26, 2000 2:31 PM
> To:   Taylor, Tom-PT [NORSE:B901:EXCH];
> MEGACO@standards.nortelnetworks.com
> Subject:      RE: Multiple Profiles; Representation of Empty Descriptors
>
> > (1) It seems reasonable that the MGC, at least, may be
> > capable of supporting
> > multiple profiles.  The syntax should be altered to allow this.
> I'm not sure a syntax change is needed for the case of MGC support
> of multiple profiles.  The registration process always starts with
> the MG sending serviceChange.  If it specifies a profile, the MGC
> responds with the same profile if it can support it, or it's best
> suggestion if it can't.  Words to that effect should be added.
> Could consider an error code of "Can't support that profile"
>
> >
> > (2) Suppose a given descriptor is empty on a given termination.  In
> > particular, suppose there is nothing in the Events
> > descriptor, or no active
> > digit map.  What is the syntax for representing this in a
> > response to the
> > MGC?
> >
> > Proposal: represent an empty descriptor by giving its name alone.  The
> > simplest way to represent this is to change the syntax of
> > auditReturnParameter to add auditItem as an additional possibility.
> This is okay with me, although Events{} would be okay with me also.
>
>
> Brian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Apr 26 15:38:13 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03420
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 26 Apr 2000 15:38:13 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.792EE400@standards.nortelnetworks.com>; Wed, 26 Apr 2000 15:31:21 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 17522 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Apr 2000 15:29:36 -0400
Received: from smtprtp1.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.394447E0@standards.nortelnetworks.com>; Wed, 26 Apr 2000 15:29:34
          -0400
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          smtprtp1.ntcom.nortel.net; Wed, 26 Apr 2000 15:30:28 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <27B9Q3H0>; Wed, 26 Apr 2000 15:30:28 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD11038583DE@zcard00g.ca.nortel.com>
Date:         Wed, 26 Apr 2000 15:30:23 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Documentation Of Ability to Audit Contexts
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

The ability to audit context properties is not mentioned in the body of the
protocol document.  The most natural place to put it might be as a note in
section 7.2.5 AuditValue pointing out that context property audits have
their own syntax and do not use the AuditValue command.

Tom Taylor
Phone and FAX: +1 613 736 0961
E-mail: taylor@nortelnetworks.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Apr 26 15:42:14 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03519
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 26 Apr 2000 15:42:14 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.09803BD0@standards.nortelnetworks.com>; Wed, 26 Apr 2000 15:35:23 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 17515 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Apr 2000 15:33:36 -0400
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.640A4070@standards.nortelnetworks.com>; Wed, 26 Apr 2000 15:23:36
          -0400
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id PAA06858; Wed, 26 Apr
          2000 15:29:51 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id PAA16620; Wed, 26 Apr
          2000 15:29:49 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <2MSF73SA>; Wed, 26 Apr 2000 15:24: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:  <4FBEA8857476D311A03300204840E1CF678229@whq-msgusr-02.fore.com>
Date:         Wed, 26 Apr 2000 15:29:45 -0400
Reply-To: "Rosen, Brian" <brosen@FORE.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <brosen@FORE.COM>
Subject:      Re: Multiple Profiles; Representation of Empty Descriptors
X-To:         Tom-PT Taylor <taylor@nortelnetworks.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I think MGs supporting multiple profiles is a cs2 issue,
but I wouldn't rule out the following:

Profile p3 is really an expansion of profile p2, which is actually
an expansion of p1.  MG1 registers at MGC1 claiming to implement
p3.  MGC only implements p2, so it declines.  MG1, persistent bugger
that he is, tries again, claiming to implement p2.  MGC1 accepts.
MG2 implements p1, registers with MGC1, which accepts, since it
can also do p1 if it does p2.

Takes no syntax change to handle that.  Beyond that, I think
multiple profiles in MGs get you into complications I don't want to
think about yet.

Is your problem with Events the issue that the ABNF requires requestId?
We'd have to fix that.

Brian

> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> Sent: Wednesday, April 26, 2000 3:13 PM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: Multiple Profiles; Representation of Empty Descriptors
>
>
> Is there not a possibility that an MG supports multiple profiles?  I
> shouldn't have been so cautious in my initial proposal.
>
> The problem with Events{} in particular is that you're
> supposed to have a
> requestId in there.
>
> > -----Original Message-----
> > From: Rosen, Brian [SMTP:brosen@fore.com]
> > Sent: Wednesday, April 26, 2000 2:31 PM
> > To:   Taylor, Tom-PT [NORSE:B901:EXCH];
> > MEGACO@standards.nortelnetworks.com
> > Subject:      RE: Multiple Profiles; Representation of
> Empty Descriptors
> >
> > > (1) It seems reasonable that the MGC, at least, may be
> > > capable of supporting
> > > multiple profiles.  The syntax should be altered to allow this.
> > I'm not sure a syntax change is needed for the case of MGC support
> > of multiple profiles.  The registration process always starts with
> > the MG sending serviceChange.  If it specifies a profile, the MGC
> > responds with the same profile if it can support it, or it's best
> > suggestion if it can't.  Words to that effect should be added.
> > Could consider an error code of "Can't support that profile"
> >
> > >
> > > (2) Suppose a given descriptor is empty on a given
> termination.  In
> > > particular, suppose there is nothing in the Events
> > > descriptor, or no active
> > > digit map.  What is the syntax for representing this in a
> > > response to the
> > > MGC?
> > >
> > > Proposal: represent an empty descriptor by giving its
> name alone.  The
> > > simplest way to represent this is to change the syntax of
> > > auditReturnParameter to add auditItem as an additional
> possibility.
> > This is okay with me, although Events{} would be okay with me also.
> >
> >
> > Brian
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Apr 26 18:45:48 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06292
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 26 Apr 2000 18:45:47 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AF3B69A0@standards.nortelnetworks.com>; Wed, 26 Apr 2000 18:38:58 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 17995 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Apr 2000 18:37:01 -0400
Received: from smtprch2.nortel.com (192.135.215.15) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.692B29F0@standards.nortelnetworks.com>; Wed, 26 Apr 2000
          18:37:01 -0400
Received: from smtprich.nortel.com (actually zrchs148) by smtprch2.nortel.com;
          Wed, 26 Apr 2000 14:35:02 -0500
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprich.nortel.com; Wed, 26 Apr 2000 14:38:29 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <JSPAPF41>; Wed, 26 Apr 2000 14:37:16 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
X-Orig: <taylor@americasm01.nt.com>
X-Orig: <taylor@nortelnetworks.com>
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD11038583DF@zcard00g.ca.nortel.com>
Date:         Wed, 26 Apr 2000 14:37:10 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Multiple Profiles; Representation of Empty Descriptors
X-To:         "Rosen, Brian" <brosen@fore.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I'll accept your position on profiles, though with some uneasiness.

On the Events { } issue, yes, the ABNF requires requestID.  Similarly just
about all the other descriptors require content -- you can't have an empty
modem or digitMap descriptor, for instance.

We have another problem with digit maps: you can't set or report more than
one in the same command.

> -----Original Message-----
> From: Rosen, Brian [SMTP:brosen@fore.com]
> Sent: Wednesday, April 26, 2000 3:30 PM
> To:   Taylor, Tom-PT [NORSE:B901:EXCH];
> MEGACO@standards.nortelnetworks.com
> Subject:      RE: Multiple Profiles; Representation of Empty Descriptors
>
> I think MGs supporting multiple profiles is a cs2 issue,
> but I wouldn't rule out the following:
>
> Profile p3 is really an expansion of profile p2, which is actually
> an expansion of p1.  MG1 registers at MGC1 claiming to implement
> p3.  MGC only implements p2, so it declines.  MG1, persistent bugger
> that he is, tries again, claiming to implement p2.  MGC1 accepts.
> MG2 implements p1, registers with MGC1, which accepts, since it
> can also do p1 if it does p2.
>
> Takes no syntax change to handle that.  Beyond that, I think
> multiple profiles in MGs get you into complications I don't want to
> think about yet.
>
> Is your problem with Events the issue that the ABNF requires requestId?
> We'd have to fix that.
>
> Brian
>
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> > Sent: Wednesday, April 26, 2000 3:13 PM
> > To: MEGACO@standards.nortelnetworks.com
> > Subject: Re: Multiple Profiles; Representation of Empty Descriptors
> >
> >
> > Is there not a possibility that an MG supports multiple profiles?  I
> > shouldn't have been so cautious in my initial proposal.
> >
> > The problem with Events{} in particular is that you're
> > supposed to have a
> > requestId in there.
> >
> > > -----Original Message-----
> > > From: Rosen, Brian [SMTP:brosen@fore.com]
> > > Sent: Wednesday, April 26, 2000 2:31 PM
> > > To:   Taylor, Tom-PT [NORSE:B901:EXCH];
> > > MEGACO@standards.nortelnetworks.com
> > > Subject:      RE: Multiple Profiles; Representation of
> > Empty Descriptors
> > >
> > > > (1) It seems reasonable that the MGC, at least, may be
> > > > capable of supporting
> > > > multiple profiles.  The syntax should be altered to allow this.
> > > I'm not sure a syntax change is needed for the case of MGC support
> > > of multiple profiles.  The registration process always starts with
> > > the MG sending serviceChange.  If it specifies a profile, the MGC
> > > responds with the same profile if it can support it, or it's best
> > > suggestion if it can't.  Words to that effect should be added.
> > > Could consider an error code of "Can't support that profile"
> > >
> > > >
> > > > (2) Suppose a given descriptor is empty on a given
> > termination.  In
> > > > particular, suppose there is nothing in the Events
> > > > descriptor, or no active
> > > > digit map.  What is the syntax for representing this in a
> > > > response to the
> > > > MGC?
> > > >
> > > > Proposal: represent an empty descriptor by giving its
> > name alone.  The
> > > > simplest way to represent this is to change the syntax of
> > > > auditReturnParameter to add auditItem as an additional
> > possibility.
> > > This is okay with me, although Events{} would be okay with me also.
> > >
> > >
> > > Brian
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr 27 01:20:23 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14220
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 27 Apr 2000 01:20:23 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B18E5550@standards.nortelnetworks.com>; Thu, 27 Apr 2000 1:12:45 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 18559 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Apr 2000 01:11:57 -0400
Received: from ish7.ericsson.com.au (203.61.155.111) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.2C40ED00@standards.nortelnetworks.com>; Thu, 27 Apr 2000
          1:01:51 -0400
Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id PAA24189; Thu,
          27 Apr 2000 15:06:47 +1000 (EST)
Received: from mcsi00.epa.ericsson.se (mcsi00 [146.11.8.201]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id PAA16576; Thu, 27
          Apr 2000 15:07:09 +1000 (EST)
Received: from ericsson.com (mcdh183.epa.ericsson.se [146.11.81.183]) by
          mcsi00.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id PAA00443; Thu,
          27 Apr 2000 15:06:57 +1000 (EST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <C51ED84B6F47D211917A0000F8BCBD1193B6C4@zcard00g.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39079EEB.673E305F@ericsson.com>
Date:         Thu, 27 Apr 2000 11:59:07 +1000
Reply-To: Christian Groves <Christian.Groves@ERICSSON.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Christian Groves <Christian.Groves@ERICSSON.COM>
Subject:      Re: Unspecified Properties, Defaults and Value Replacement
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Tom,

Why do we want the exception for Local Control and Termination State in
(1) below?

Cheers, Christian
Tom-PT Taylor wrote:
>
> I have done some further thinking and research on the "unspecified value"
> issue.  Here are my new thoughts.  I would very much welcome comments.
>
> Section 6.2.4 presents a data model which is not an accurate representation
> of subsequent parts of the protocol document.  There are several statements:
>  -- most properties have default values
>  -- when a termination is created, unspecified properties are given their
> default values
>  -- when a termination is modified, unspecified properties retain their
> previous values.
>
> As noted in a previous thread, a lot of our data behaviour is actually
> specified at the descriptor level.  In addition, the sensible initial state
> for most descriptors is either "no value" or "empty", although this could be
> modified by provisioning for specific terminations.  Here's a complete list
> of descriptors and the initial values I think we intend:
>
> Descriptor              Initial Value When Termination Created
> ----------------
> --------------------------------------------------------
> Modem                  No value
> Multiplex                No value
>
> Media                    See components
> TerminationState    ServiceStates=InService; EventBufferControl=Off
> Stream                  See components
> Local                     Empty
> Remote                 Empty
> LocalControl          Mode=inactive[?]; Reservexx=Off
>
> Events                  Empty, RequestID=0[?]
> EventBuffer            Empty
> Signals                 Empty
> Audit                    Empty
> DigitMap               Empty
>
> I propose that the above table be added to section 6.2.4 and and the text on
> initial values for properties be modified to refer to the table instead
> (with suitable reference to packages where applicable).  The question marks
> for Mode and RequestID are because we do not actually specify those defaults
> in our text.
>
> The other point to be straightened out is the fact that descriptor-level
> semantics are important.  I think the following are true statements of our
> intent.  If so, sections 6.2.4 and 7.1.1 should be modified to reflect them:
>
>  (1) When a specific descriptor is specified in a command, the contents of
> that descriptor completely replace any previous settings of properties
> within that descriptor.  THERE ARE THREE EXCEPTIONS: DigitMap does its
> replacement at the level of the individual named digit map, and we probably
> want unspecified properties in TerminationState and LocalControl to retain
> their previous values.
>
>  (2) If a specific descriptor is omitted from a command, its previous
> contents are retained.
>
> Tom Taylor
> Phone and FAX: +1 613 736 0961
> E-mail: taylor@nortelnetworks.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr 27 01:20:23 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14225
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 27 Apr 2000 01:20:23 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B213D900@standards.nortelnetworks.com>; Thu, 27 Apr 2000 1:12:45 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 18562 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Apr 2000 01:12:27 -0400
Received: from ish7.ericsson.com.au (203.61.155.111) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.3E4B26A0@standards.nortelnetworks.com>; Thu, 27 Apr 2000
          1:02:22 -0400
Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id PAA24152; Thu,
          27 Apr 2000 15:06:30 +1000 (EST)
Received: from mcsi00.epa.ericsson.se (mcsi00 [146.11.8.201]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id PAA16523; Thu, 27
          Apr 2000 15:06:52 +1000 (EST)
Received: from ericsson.com (mcdh183.epa.ericsson.se [146.11.81.183]) by
          mcsi00.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id PAA00405; Thu,
          27 Apr 2000 15:06:41 +1000 (EST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF678229@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <390785B1.8DFBD4A2@ericsson.com>
Date:         Thu, 27 Apr 2000 10:11:29 +1000
Reply-To: Christian Groves <Christian.Groves@ERICSSON.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Christian Groves <Christian.Groves@ERICSSON.COM>
Subject:      Re: Multiple Profiles; Representation of Empty Descriptors
X-To:         "Rosen, Brian" <brosen@FORE.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Tom,

I tend to agreee with Brian. Profiles have largely been undefined in
H248. We have a field to carry profile but it pretty much undefined.
Brian brings up versioning below, we haven't considered that. We don't
even have a proforma on what the profile names should be. Rather than
adding support for multliple profiles now when we don't know the format
lets do it properly in v2 or fix it all in v1 (I suspect we don't want
to do that).

Cheers, Christian

"Rosen, Brian" wrote:
>
> I think MGs supporting multiple profiles is a cs2 issue,
> but I wouldn't rule out the following:
>
> Profile p3 is really an expansion of profile p2, which is actually
> an expansion of p1.  MG1 registers at MGC1 claiming to implement
> p3.  MGC only implements p2, so it declines.  MG1, persistent bugger
> that he is, tries again, claiming to implement p2.  MGC1 accepts.
> MG2 implements p1, registers with MGC1, which accepts, since it
> can also do p1 if it does p2.
>
> Takes no syntax change to handle that.  Beyond that, I think
> multiple profiles in MGs get you into complications I don't want to
> think about yet.
>
> Is your problem with Events the issue that the ABNF requires requestId?
> We'd have to fix that.
>
> Brian
>
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> > Sent: Wednesday, April 26, 2000 3:13 PM
> > To: MEGACO@standards.nortelnetworks.com
> > Subject: Re: Multiple Profiles; Representation of Empty Descriptors
> >
> >
> > Is there not a possibility that an MG supports multiple profiles?  I
> > shouldn't have been so cautious in my initial proposal.
> >
> > The problem with Events{} in particular is that you're
> > supposed to have a
> > requestId in there.
> >
> > > -----Original Message-----
> > > From: Rosen, Brian [SMTP:brosen@fore.com]
> > > Sent: Wednesday, April 26, 2000 2:31 PM
> > > To:   Taylor, Tom-PT [NORSE:B901:EXCH];
> > > MEGACO@standards.nortelnetworks.com
> > > Subject:      RE: Multiple Profiles; Representation of
> > Empty Descriptors
> > >
> > > > (1) It seems reasonable that the MGC, at least, may be
> > > > capable of supporting
> > > > multiple profiles.  The syntax should be altered to allow this.
> > > I'm not sure a syntax change is needed for the case of MGC support
> > > of multiple profiles.  The registration process always starts with
> > > the MG sending serviceChange.  If it specifies a profile, the MGC
> > > responds with the same profile if it can support it, or it's best
> > > suggestion if it can't.  Words to that effect should be added.
> > > Could consider an error code of "Can't support that profile"
> > >
> > > >
> > > > (2) Suppose a given descriptor is empty on a given
> > termination.  In
> > > > particular, suppose there is nothing in the Events
> > > > descriptor, or no active
> > > > digit map.  What is the syntax for representing this in a
> > > > response to the
> > > > MGC?
> > > >
> > > > Proposal: represent an empty descriptor by giving its
> > name alone.  The
> > > > simplest way to represent this is to change the syntax of
> > > > auditReturnParameter to add auditItem as an additional
> > possibility.
> > > This is okay with me, although Events{} would be okay with me also.
> > >
> > >
> > > Brian
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr 27 01:23:48 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14708
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 27 Apr 2000 01:23:48 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FAA2FB60@standards.nortelnetworks.com>; Thu, 27 Apr 2000 1:14:47 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 18563 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Apr 2000 01:12:55 -0400
Received: from ish7.ericsson.com.au (203.61.155.111) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.46712E10@standards.nortelnetworks.com>; Thu, 27 Apr 2000
          1:02:35 -0400
Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id PAA24155; Thu,
          27 Apr 2000 15:06:31 +1000 (EST)
Received: from mcsi00.epa.ericsson.se (mcsi00 [146.11.8.201]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id PAA16531; Thu, 27
          Apr 2000 15:06:54 +1000 (EST)
Received: from ericsson.com (mcdh183.epa.ericsson.se [146.11.81.183]) by
          mcsi00.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id PAA00409; Thu,
          27 Apr 2000 15:06:43 +1000 (EST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF67821E@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39078AF0.BE4EFC83@ericsson.com>
Date:         Thu, 27 Apr 2000 10:33:52 +1000
Reply-To: Christian Groves <Christian.Groves@ERICSSON.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Christian Groves <Christian.Groves@ERICSSON.COM>
Subject:      Re: Multiple streams per call,
X-To:         "Rosen, Brian" <brosen@FORE.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Brian,

Let's not drag in the topology discussion, I haven't disagreed with you
(yet :-). I mentioned that we needed to consider the issue.

Stylistically we already have a direction set in the protocol that the
context implies a certain functionality ie. mixing. We tried to hide the
internal operation of the MG from the MGC. With topology it is a means
of setting the relationships between terminations for things like
operator break in and another topic which we can't talk about in the
IETF. Topology wasn't designed for mixing and we previously had
earmarked the context properties for mixing properties.

If we define an MCU package then there will be only one way of
implementing an MCU. I agree with you that in v1 you can't do a wide
range of effects on an MCU because we haven't defined any. However these
could be properties on a termination.

I'm not sure that shifting the burden of developing packages to the
protocol know is a good idea. It has been said before on the list that
Full Multimedia would be considered in v2. Is this still the plan?

Cheers, Christian

"Rosen, Brian" wrote:
>
> I see it as a style issue - the more uniform packages (and gateways)
> are built, the more likely there will be wide interoperability.
> What I would really hate to see is one vendor building MCUs one way,
> and other building them another way, so that it was a tremendous
> amount of code for one MGC to control both kinds.
>
> Multimedia contexts aren't the issue.  The issue is what is the
> general way to model a device that does not have an explicit
> protocol mechanism to support it.  The really amusing part of this
> discussion is that I was one of the folks in the design team meeting
> in Minneapolis that seized on the idea of having each termination be
> able to have a different media specification with implicit translation
> between them!  It's still a very elegant mechanism, and I've said
> so in the context of the translator.  I'm more worried about influencing
> the design of packages to ease the burden on the MGC of supporting
> lots of MGs.  We can't control it -- we aren't any more effective as
> the package police than we are as the protocol police!
>
> Brian
>
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> > Sent: Wednesday, April 26, 2000 9:15 AM
> > To: MEGACO@standards.nortelnetworks.com
> > Subject: Re: Multiple streams per call,
> >
> >
> > It seems to me that this is only marginally a standardization
> > issue.  You
> > may want to build your GW one way, another vendor
> > differently.  We will have
> > to think about whether we have to define properties to allow
> > the MGC to
> > discover the difference in internal organization.
> >
> > :-) My suspicion is that, having stoutly resisted the
> > multimedia context
> > model, you'd like to bury it on the rebound.
> >
> > > -----Original Message-----
> > > From: Rosen, Brian [SMTP:brosen@FORE.COM]
> > > Sent: Wednesday, April 26, 2000 8:37 AM
> > > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject:      Re: Multiple streams per call,
> > >
> > > The reason it's not a v2 issue is that it affects how you design
> > > a package for a cs1 implementation of some kind of capability not
> > > specifically catered for.
> > >
> > > In the discussions of "topology" we had a similar disagreement, with
> > > the same actors :(.  The topology mechanism works for most common
> > > implementations of an audio mixing bridge.  The protocol does not
> > > have a mechanism to extend topology, nor to add context properties.
> > > We do have the package mechanism.  If I wanted to build a
> > very flexible
> > > MCU which allowed a wide range of video and audio effects,
> > I can't do
> > > it with "bare" cs1 capabilities (my "what does T1/T2 bothways mean
> > > for a tiling video MCU?" question).
> > >
> > > On the other hand, I can do it with the mechanism I
> > propose.  In fact,
> > > it's pretty hard to think of any kind of media device I
> > cannot control
> > > pretty nicely with such a mechanism.  That is a very good feature of
> > > the protocol.
> > >
> > > Now, what I'm advocating is that we use that mechanism uniformly.
> > >
> > > What we are discussing is a kind of corner case - the "two RTPs with
> > > different media specifications, implied translation" clearly is
> > > within the capabilities of the protocol.  It does work.  But all
> > > you need to do is add one twist - say that the translator is also a
> > > multimedia MCU, and now you can't use the same model.  That is a bad
> > > idea.
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
> > > > Sent: Wednesday, April 26, 2000 12:34 AM
> > > > To: Rosen, Brian
> > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: Re: Multiple streams per call,
> > > >
> > > >
> > > > I like the 'elegant method'. I thought that context
> > > > properties could be
> > > > used in the situations where the elegant didn't work.
> > This I thought
> > > > would be the most generic.
> > > >
> > > > I agree that using the 'internal' termination model is a
> > > > valid modelling
> > > > technique but I wonder if it is more uniform. ie. Conferences
> > > > today are
> > > > handled by context but we could equally have a context
> > with a mixing
> > > > termination and then hang off individual context and
> > terminations for
> > > > the subscriber legs.
> > > >
> > > > I think this is something for discussion for v2, either
> > approach is
> > > > interesting.
> > > >
> > > > Cheers, Christian
> > > >
> > > > "Rosen, Brian" wrote:
> > > > >
> > > > > This is beyond the current discussion.  The question
> > is, in general,
> > > > > how do we model devices that are "different".  In the
> > case cited,
> > > > > media translation, we could model it as a two
> > termination context,
> > > > > with the RTP flows, specified by media descriptors,
> > describing the
> > > > > two sides, and an implicit translation in between.
> > This certainly
> > > > > works, and is pretty elegant.
> > > > >
> > > > > The problem is that it doesn't work for all kinds of devices,
> > > > > and I wondered if we should model them in a more uniform way.  I
> > > > > suggested a set of two termination contexts with an "internal"
> > > > > termination that can have characteristics ascribed to it by a
> > > > > set of packages implemented on it, and an RTP termination that
> > > > > had the external flow on it.  This would also work for the
> > > > translator,
> > > > > but requires more terminations and more contexts, and thus is
> > > > > somewhat less elegant.  It too would work, and has the
> > advantage of
> > > > > being able to be used for a much wider range of applications.
> > > > >
> > > > > Brian
> > > > >
> > > > > Brian
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> > > > > > Sent: Friday, April 21, 2000 9:36 AM
> > > > > > To: MEGACO@standards.nortelnetworks.com
> > > > > > Subject: Re: Multiple streams per call,
> > > > > >
> > > > > >
> > > > > > My view of something like tiling is that we need a per-stream
> > > > > > property to
> > > > > > express mixing method.  I didn't push this last summer
> > > > > > because it was clear
> > > > > > that it would have to be designed by specialists in the area,
> > > > > > and I figured
> > > > > > they should be the ones to step up to the plate when they are
> > > > > > serious about
> > > > > > building product using Megaco/H.248.
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Rosen, Brian [SMTP:brosen@FORE.COM]
> > > > > > > Sent: Friday, April 21, 2000 8:58 AM
> > > > > > > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > > Subject:      Re: Multiple streams per call,
> > > > > > >
> > > > > > > Yes, the translation MG, you could construct a context with
> > > > > > > two RTP ports and use the SDP to imply translation.  The
> > > > > > protocol would
> > > > > > > allow that.
> > > > > > >
> > > > > > > The problem is that it would work for things that are
> > > > > > expressible in SDP,
> > > > > > > but not for more general mechanisms.  For example, suppose
> > > > > > you wanted
> > > > > > > an MCU that did tiling.  I'd prefer that we use one
> > > > > > mechanism for all of
> > > > > > > these
> > > > > > > kinds of problems.
> > > > > > >
> > > > > > > And, yes Christian, SDP is shorthand for "SDP or Annex C"
> > > > > > >
> > > > > > > Brian
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: John Segers [mailto:jsegers@lucent.com]
> > > > > > > > Sent: Friday, April 21, 2000 5:52 AM
> > > > > > > > To: Rosen, Brian
> > > > > > > > Cc: MEGACO@standards.nortelnetworks.com
> > > > > > > > Subject: Re: Multiple streams per call,
> > > > > > > >
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > Having been away from the list for a while, I've got some
> > > > > > > > catching up to
> > > > > > > > do!  Although this thread is probably less urgent
> > > > than some of the
> > > > > > > > others, this one being related to more advanced (future)
> > > > > > > > functionality,
> > > > > > > > I'll jump in on this first.
> > > > > > > >
> > > > > > > > Comparing Brian's proposal for the video translator to
> > > > > > less exotic MG
> > > > > > > > devices that translate audio, I wonder why the extra ports
> > > > > > > > are needed.
> > > > > > > > In the audio case, the required transcoding, e.g. from
> > > > > > G.711 A-law to
> > > > > > > > G.723.1 is inferred from the Termination type/name and/or
> > > > > > RTP payload
> > > > > > > > type.  No extra ports are introduced to model the
> > translator
> > > > > > > > resource.
> > > > > > > > Why can't it work the same for video?
> > > > > > > >
> > > > > > > > Cheers,
> > > > > > > >
> > > > > > > > John
> > > > > > > >
> > > > > > > > "Rosen, Brian" wrote:
> > > > > > > > >
> > > > > > > > > You seem to have everything correct!
> > > > > > > > >
> > > > > > > > > You are worried about the video translator.  The
> > > > > > problem statement
> > > > > > > > > was MG-A and MG-B did not have a common video encoding,
> > > > > > so the MGC
> > > > > > > > > wanted to insert a translator to fix the problem.
> > > > > > > > >
> > > > > > > > > I think this is very reasonable to do, and I
> > would model the
> > > > > > > > > translator as a set of pairs of terminations - The
> > > > "A" side and
> > > > > > > > > the "B" side.  Trying to push these into a single
> > > > context, to
> > > > > > > > > my way of thinking, is very weird.  Much
> > cleaner to have two
> > > > > > > > > separate contexts.  I waffled over whether to represent
> > > > > > the "ports"
> > > > > > > > > of the translator as physical terminations.  In
> > > > > > reality, they could
> > > > > > > > > be, if the translator was some hard wired fixed
> > > > function.  It is
> > > > > > > > > possible that it could just be a fancy DSP, and
> > the number
> > > > > > > > of translations
> > > > > > > > > it could do was a variable, determined by what
> > > > > > > > > translations were in use.  For example, it might be
> > > > able to do
> > > > > > > > > 10 MPEG 1 to MPEG 2 translations, but only 3
> > MPEG2 to H.261
> > > > > > > > translations.
> > > > > > > > > In this case, it might be better to model the ports
> > > > as ephemeral
> > > > > > > > > terminations.  I would still represent them as pairs of
> > > > > > > > terminations,
> > > > > > > > > which would go in pairs of two termination
> > > > contexts, the other
> > > > > > > > > termination being (for example) the RTP termination.
> > > > > > > > >
> > > > > > > > > To help your thinking, instead of calling those
> > > > > > > > terminations Y and Z,
> > > > > > > > > call them XLate/A and XLate/B.  If the box could do
> > > > > > more than one,
> > > > > > > > > maybe we would call them XL/1/A and XL/1/B, so you
> > > > > > could talk about
> > > > > > > > > XL/4/A for example.  Then XL/1/A is in a context
> > > > with RTP-A, and
> > > > > > > > > XL/1/B is in context with RTP-B.
> > > > > > > > >
> > > > > > > > > It is possible to have one termination that had two
> > > > > > streams (the A
> > > > > > > > > stream and the B stream) and then the context
> > would have 3
> > > > > > > > terminations, the
> > > > > > > > > translator, the "A" RTP and the "B" RTP.  Then you would
> > > > > > > > use streamIDs to
> > > > > > > > > keep the streams straight (no need to use topology).
> > > > > > > > > This is one of the things I don't like about
> > what we did,
> > > > > > > > two ways to
> > > > > > > > > do the same thing, nothing but "taste" to decide
> > > > which to use,
> > > > > > > > > guaranteed interoperability problems unless
> > some package is
> > > > > > > > standardized.
> > > > > > > > > Oh well.  Anyway, I think modeling the translator
> > > > as having two
> > > > > > > > > terminations, an A termination and a B termination,
> > > > > > each with one
> > > > > > > > > stream, is the best way to do it.
> > > > > > > > >
> > > > > > > > > In fact, you may have noticed that I used the same
> > > > model for the
> > > > > > > > > weird function bridge a few emails back -- I think
> > > > > > whenever we have
> > > > > > > > > odd-function devices, we should model the "ports"
> > > > of the device
> > > > > > > > > as a termination implementing a specific package.  In
> > > > > > this specific
> > > > > > > > > case the ports are symmetric (because the flows are
> > > > > > send-receive),
> > > > > > > > > but in the general case, they may not be.
> > > > > > > > >
> > > > > > > > > Brian
> > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Chip Sharp [mailto:chsharp@cisco.com]
> > > > > > > > > > Sent: Friday, April 14, 2000 3:58 PM
> > > > > > > > > > To: Rosen, Brian; MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > > > > > > Subject: Re: Multiple streams per call,
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > At 02:33 PM 4/14/00 -0400, Rosen, Brian wrote:
> > > > > > > > > >
> > > > > > > > > > ...snip...
> > > > > > > > > >
> > > > > > > > > > >Sure.  Look at it from the point of view of the MGs.
> > > > > > > > You have MG-A,
> > > > > > > > > > >MG-B and MG1.  MG-A has a termination with two
> > > > > > streams, video and
> > > > > > > > > > >audio.  It is commanded by the MGC to set up a single
> > > > > > > > context with
> > > > > > > > > > >the termination and two RTP connections, call them
> > > > > > > > RTP-A-Audio and
> > > > > > > > > > >RTP-A-Video.  The address it assigns to
> > > > RTP-A-Audio is MG-B.
> > > > > > > > > > >The address it assigns RTP-A-Video is MG1.
> > > > > > > > > > >Again, this is a single context, with the physical
> > > > > > termination
> > > > > > > > > > >having two streams, and each of the RTP terminations
> > > > > > having one
> > > > > > > > > > >stream each.
> > > > > > > > > >
> > > > > > > > > > I assume when you say "RTP connections" above,
> > > > you mean "RTP
> > > > > > > > > > terminations"
> > > > > > > > > > since the word "connection" isn't allowed in
> > megaco. (your
> > > > > > > > > > MGCP is showing
> > > > > > > > > > ;-) ).
> > > > > > > > > > I'm not sure what kind of termination you are
> > > > talking about,
> > > > > > > > > > but I'll call
> > > > > > > > > > it X.
> > > > > > > > > >
> > > > > > > > > > In MG-A, Terminations X, RTP-A-Audio and
> > RTP-A-Video all
> > > > > > > > > > belong to the same
> > > > > > > > > > context, say Context A.  Termination X has 2
> > > > streams assigned
> > > > > > > > > > to it.  One
> > > > > > > > > > stream contains the video, the other stream
> > contains the
> > > > > > > > > > audio (both in
> > > > > > > > > > send-receive).  Termination RTP-A-Audio would be
> > > > configured
> > > > > > > > > > with only the
> > > > > > > > > > Audio stream.  Termination RTP-A-Video would
> > be configured
> > > > > > > > > > with only the
> > > > > > > > > > Video stream.
> > > > > > > > > >
> > > > > > > > > > Therefore the video stream goes to MG1 and the
> > > > audio stream
> > > > > > > > > > goes to MGB, as
> > > > > > > > > > described.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >Look at MG1.  It has two terminations, with one
> > > > > > stream each.  It
> > > > > > > > > > >is asked to set up two contexts, one with an RTP
> > > > > > connecting to
> > > > > > > > > > >MG-A and the other with its RTP connection to
> > > > MG-B.  That's
> > > > > > > > > > >two contexts, each with two terminations, with
> > > > one stream in
> > > > > > > > > > >each of the contexts.
> > > > > > > > > >
> > > > > > > > > > I'm not sure what the two mystery terminations
> > > > are again, but
> > > > > > > > > > I'll call
> > > > > > > > > > them Y and Z.
> > > > > > > > > >
> > > > > > > > > > Terminations Y and RTP-A belong to a context A and
> > > > > > > > contain one stream.
> > > > > > > > > > Terminations Z and RTP-B belong to a context B and
> > > > > > > > contain one stream.
> > > > > > > > > >
> > > > > > > > > > The video stream from MGA comes into context A via
> > > > > > > > > > Termination RTP-A and
> > > > > > > > > > ends up on Termination Y (and vice versa).
> > > > > > > > > >
> > > > > > > > > > Whatever is on termination Z is transmitted
> > out RTP-B via
> > > > > > > > > > context B (and
> > > > > > > > > > vice versa).
> > > > > > > > > >  From the below, it seems video is connected to
> > > > MG-B; however
> > > > > > > > > > there is no
> > > > > > > > > > context containing Terminations Z & Y to allow them to
> > > > > > > > > > communicate under
> > > > > > > > > > the control of megaco.  Therefore, I assume that
> > > > some internal
> > > > > > > > > > implementation-specific mechanism connects
> > > > terminations Y & Z
> > > > > > > > > > in order to
> > > > > > > > > > get the video from Context A into context B.
> > > > > > > > > > MG1 could just have 2 RTP terminations with one
> > > > stream in one
> > > > > > > > > > context.  Of
> > > > > > > > > > course, H.248 forbids a termination from belonging to
> > > > > > > > more than one
> > > > > > > > > > context, so you can't just create a context
> > > > containing X & Y.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >Of course, MG-B has a similar setup to MG-A -- it's
> > > > > > > > audio connects
> > > > > > > > > > >to MG-A, the video connects to MG1.
> > > > > > > > > > >
> > > > > > > > > > >Now look at it from the MGC.  The "call" has 3
> > > > > > Megaco contexts.
> > > > > > > > > > >The MG-A to MG-B audio, the MG-A to MG1 video and
> > > > > > the MG1 to MG-B
> > > > > > > > > > >video.
> > > > > > > > > >
> > > > > > > > > > Yes, but the MGC has no idea how the video gets from
> > > > > > > > Termination X to
> > > > > > > > > > Termination Y in MG1.
> > > > > > > > > >
> > > > > > > > > > Thanks for the illustration.  I haven't really
> > > > thought about
> > > > > > > > > > it in a while.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >I'm still not thrilled with the whole stream
> > idea, but
> > > > > > > > it does work.
> > > > > > > > > > >
> > > > > > > > > > >Brian
> > > > > > > > > >
> > > > > > > > > > http://www.netaid.org
> > > > > > > > > >
> > > > --------------------------------------------------------------
> > > > > > > > > > -----------
> > > > > > > > > > Chip Sharp                 CTO Consulting Engineering
> > > > > > > > > > Cisco Systems
> > > > > > > > > > Reality - Love it or Leave it.
> > > > > > > > > >
> > > > --------------------------------------------------------------
> > > > > > > > > > ----------
> > > > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > John Segers                                  email:
> > > > > > jsegers@lucent.com
> > > > > > > > Lucent Technologies
> > > > > >  Room HE 306
> > > > > > > > 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 Apr 27 01:24:04 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14218
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 27 Apr 2000 01:20:22 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B108D1A0@standards.nortelnetworks.com>; Thu, 27 Apr 2000 1:12:44 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 18558 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Apr 2000 01:11:03 -0400
Received: from ish7.ericsson.com.au (203.61.155.111) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.0EF1DFC0@standards.nortelnetworks.com>; Thu, 27 Apr 2000
          1:01:02 -0400
Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id PAA24182 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 27 Apr 2000 15:06:45
          +1000 (EST)
Received: from mcsi00.epa.ericsson.se (mcsi00 [146.11.8.201]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id PAA16571 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 27 Apr 2000 15:07:07
          +1000 (EST)
Received: from ericsson.com (mcdh183.epa.ericsson.se [146.11.81.183]) by
          mcsi00.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id PAA00439 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 27 Apr 2000 15:06:56
          +1000 (EST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <38FBFA5F.8EB6205E@ericsson.com.au>
            <38FBE3C1.9EFD052C@ficon-tech.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <390795E0.AC103E7E@ericsson.com>
Date:         Thu, 27 Apr 2000 11:20:32 +1000
Reply-To: Christian Groves <Christian.Groves@ERICSSON.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Christian Groves <Christian.Groves@ERICSSON.COM>
Subject:      Re: Wildcarded context ID?
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day,

Is this a common understanding of the list? If so then perhaps we should
document it in the spec. I've asked different people and had different
thoughts on whether or not it should include the NULL context.

Cheers, Christian

Harpreet Singh Anand wrote:
>
> Hi Paul,
>
> Paul Hollis wrote:
>
> > Hi,
> >
> > just a quick question:
> >
> > Does the wildcard "ALL" for a context ID include the NULL context,
>
> Yes it includes the NULL context also.
>
> > or does it
> > only cover non-Null contexts?
> >
> > Regards Paul.
>
> --
>
> Regards,
> Harpreet
>
> _________________________________
> Harpreet Singh Anand
> Ficon Technology
> E-mail :  mailto:hsanand@ficon-tech.com
> Web    :  http://www.ficon-tech.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr 27 09:37:04 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28662
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 27 Apr 2000 09:37:04 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1B9E6170@standards.nortelnetworks.com>; Thu, 27 Apr 2000 9:29:38 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 19225 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Apr 2000 09:28:19 -0400
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.EC79BF20@standards.nortelnetworks.com>; Thu, 27 Apr 2000 9:28:19
          -0400
Received: from chsharp-tecra.cisco.com (chsharp-isdn.cisco.com
          [171.68.116.221]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2)
          with ESMTP id GAA26582 for <megaco@standards.nortelnetworks.com>;
          Thu, 27 Apr 2000 06:34:38 -0700 (PDT)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.3.1.2.20000427091010.00c1e100@dogwood.cisco.com>
Date:         Thu, 27 Apr 2000 09:11:39 -0400
Reply-To: Chip Sharp <chsharp@CISCO.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chip Sharp <chsharp@CISCO.COM>
Subject:      One termination & multiple contexts
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

My apologies that my memory ist nicht so gut, but can someone remind me why
H.248 doesn't allow a termination to belong to more than one context?

Thanks,
Chip

-------------------------------------------------------------------
Chip Sharp                 CTO Consulting Engineering
Cisco Systems
Reality - Love it or Leave it.
http://www.netaid.org
-------------------------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr 27 13:57:17 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04530
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 27 Apr 2000 13:57:16 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.81747060@standards.nortelnetworks.com>; Thu, 27 Apr 2000 13:50:11 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 19610 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Apr 2000 13:49:01 -0400
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.57DEFE00@standards.nortelnetworks.com>; Thu, 27 Apr 2000
          13:49:01 -0400
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Thu, 27 Apr 2000 12:54:48 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <JYJQQQQ7>; Thu, 27 Apr 2000 12:54:46 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD11038583E3@zcard00g.ca.nortel.com>
Date:         Thu, 27 Apr 2000 12:54:42 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Wildcarded context ID?
X-To:         Christian Groves <Christian.Groves@ERICSSON.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

It came as a surprise to me.  I'm not really comfortable with it because
wildcard audits suddenly get a lot larger.

> -----Original Message-----
> From: Christian Groves [SMTP:Christian.Groves@ERICSSON.COM]
> Sent: Wednesday, April 26, 2000 9:21 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: Wildcarded context ID?
>
> G'Day,
>
> Is this a common understanding of the list? If so then perhaps we should
> document it in the spec. I've asked different people and had different
> thoughts on whether or not it should include the NULL context.
>
> Cheers, Christian
>
> Harpreet Singh Anand wrote:
> >
> > Hi Paul,
> >
> > Paul Hollis wrote:
> >
> > > Hi,
> > >
> > > just a quick question:
> > >
> > > Does the wildcard "ALL" for a context ID include the NULL context,
> >
> > Yes it includes the NULL context also.
> >
> > > or does it
> > > only cover non-Null contexts?
> > >
> > > Regards Paul.
> >
> > --
> >
> > Regards,
> > Harpreet
> >
> > _________________________________
> > Harpreet Singh Anand
> > Ficon Technology
> > E-mail :  mailto:hsanand@ficon-tech.com
> > Web    :  http://www.ficon-tech.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr 27 14:10:06 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04734
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 27 Apr 2000 14:10:05 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.535BADE0@standards.nortelnetworks.com>; Thu, 27 Apr 2000 14:03:12 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 19633 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Apr 2000 14:01:54 -0400
Received: from smtprtp.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.24D917F0@standards.nortelnetworks.com>; Thu, 27 Apr 2000 14:01:54
          -0400
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          smtprtp.ntcom.nortel.net; Thu, 27 Apr 2000 14:06:00 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <JX3CVVA6>; Thu, 27 Apr 2000 14:05:59 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD11038583E5@zcard00g.ca.nortel.com>
Date:         Thu, 27 Apr 2000 14:05:56 -0400
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: One termination & multiple contexts
X-To:         Chip Sharp <chsharp@CISCO.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

It isn't necessary, for one thing -- you can get whatever effects you need
through manipulation of terminations and switching them between contexts as
necessary.  The main reason, though, was that it would really mess up the
whole model -- you'd have a bunch of extra rules to figure out the source
and destination of the media flows through a multi-context termination.  The
decision was made before we introduced streams, so it is possible we would
make a different decision now that we have them.

> -----Original Message-----
> From: Chip Sharp [SMTP:chsharp@CISCO.COM]
> Sent: Thursday, April 27, 2000 9:12 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      One termination & multiple contexts
>
> My apologies that my memory ist nicht so gut, but can someone remind me
> why
> H.248 doesn't allow a termination to belong to more than one context?
>
> Thanks,
> Chip
>
> -------------------------------------------------------------------
> Chip Sharp                 CTO Consulting Engineering
> Cisco Systems
> Reality - Love it or Leave it.
> http://www.netaid.org
> -------------------------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr 27 14:15:19 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04796
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 27 Apr 2000 14:15:19 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.077506A0@standards.nortelnetworks.com>; Thu, 27 Apr 2000 14:08:14 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 19632 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Apr 2000 14:06:38 -0400
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.6843A880@standards.nortelnetworks.com>; Thu, 27 Apr 2000 13:56:38
          -0400
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id OAA09718; Thu, 27 Apr
          2000 14:02:46 -0400 (EDT)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id OAA00734; Thu, 27 Apr
          2000 14:02:48 -0400 (EDT)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          <2MSF8D0C>; Thu, 27 Apr 2000 13:57:21 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF67823A@whq-msgusr-02.fore.com>
Date:         Thu, 27 Apr 2000 14:02:46 -0400
Reply-To: "Rosen, Brian" <brosen@FORE.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <brosen@FORE.COM>
Subject:      Re: Wildcarded context ID?
X-To:         Tom-PT Taylor <taylor@nortelnetworks.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I've already sent a message to the list objecting to this interpretation.
I agree that wildcard does not include Null context.

Brian

> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> Sent: Thursday, April 27, 2000 1:55 PM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: Wildcarded context ID?
>
>
> It came as a surprise to me.  I'm not really comfortable with
> it because
> wildcard audits suddenly get a lot larger.
>
> > -----Original Message-----
> > From: Christian Groves [SMTP:Christian.Groves@ERICSSON.COM]
> > Sent: Wednesday, April 26, 2000 9:21 PM
> > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject:      Re: Wildcarded context ID?
> >
> > G'Day,
> >
> > Is this a common understanding of the list? If so then
> perhaps we should
> > document it in the spec. I've asked different people and
> had different
> > thoughts on whether or not it should include the NULL context.
> >
> > Cheers, Christian
> >
> > Harpreet Singh Anand wrote:
> > >
> > > Hi Paul,
> > >
> > > Paul Hollis wrote:
> > >
> > > > Hi,
> > > >
> > > > just a quick question:
> > > >
> > > > Does the wildcard "ALL" for a context ID include the
> NULL context,
> > >
> > > Yes it includes the NULL context also.
> > >
> > > > or does it
> > > > only cover non-Null contexts?
> > > >
> > > > Regards Paul.
> > >
> > > --
> > >
> > > Regards,
> > > Harpreet
> > >
> > > _________________________________
> > > Harpreet Singh Anand
> > > Ficon Technology
> > > E-mail :  mailto:hsanand@ficon-tech.com
> > > Web    :  http://www.ficon-tech.com
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr 27 16:37:37 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06380
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 27 Apr 2000 16:37:36 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E9F20100@standards.nortelnetworks.com>; Thu, 27 Apr 2000 16:30:35 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 19889 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Apr 2000 16:29:26 -0400
Received: from smtprch2.nortel.com (192.135.215.15) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.C0FEC210@standards.nortelnetworks.com>; Thu, 27 Apr 2000
          16:29:26 -0400
Received: from smtprich.nortel.com (actually zrchs148) by smtprch2.nortel.com;
          Thu, 27 Apr 2000 12:57:37 -0500
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprich.nortel.com; Thu, 27 Apr 2000 13:00:52 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <JYJQQQW7>; Thu, 27 Apr 2000 12:59:40 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
X-Orig: <taylor@americasm01.nt.com>
X-Orig: <taylor@nortelnetworks.com>
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD11038583E4@zcard00g.ca.nortel.com>
Date:         Thu, 27 Apr 2000 12:59:36 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Unspecified Properties, Defaults and Value Replacement
X-To:         Christian Groves <Christian.Groves@ERICSSON.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Because they contain properties for which the documentation gives defaults
that make sense as a starting point.  That isn't true of the other
descriptors -- they are too situation-dependent.

In my errata document I've taken a more timid stand at this point, waiting
for comments.

> -----Original Message-----
> From: Christian Groves [SMTP:Christian.Groves@ERICSSON.COM]
> Sent: Wednesday, April 26, 2000 9:59 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: Unspecified Properties, Defaults and Value Replacement
>
> G'Day Tom,
>
> Why do we want the exception for Local Control and Termination State in
> (1) below?
>
> Cheers, Christian
> Tom-PT Taylor wrote:
> >
> > I have done some further thinking and research on the "unspecified
> value"
> > issue.  Here are my new thoughts.  I would very much welcome comments.
> >
> > Section 6.2.4 presents a data model which is not an accurate
> representation
> > of subsequent parts of the protocol document.  There are several
> statements:
> >  -- most properties have default values
> >  -- when a termination is created, unspecified properties are given
> their
> > default values
> >  -- when a termination is modified, unspecified properties retain their
> > previous values.
> >
> > As noted in a previous thread, a lot of our data behaviour is actually
> > specified at the descriptor level.  In addition, the sensible initial
> state
> > for most descriptors is either "no value" or "empty", although this
> could be
> > modified by provisioning for specific terminations.  Here's a complete
> list
> > of descriptors and the initial values I think we intend:
> >
> > Descriptor              Initial Value When Termination Created
> > ----------------
> > --------------------------------------------------------
> > Modem                  No value
> > Multiplex                No value
> >
> > Media                    See components
> > TerminationState    ServiceStates=InService; EventBufferControl=Off
> > Stream                  See components
> > Local                     Empty
> > Remote                 Empty
> > LocalControl          Mode=inactive[?]; Reservexx=Off
> >
> > Events                  Empty, RequestID=0[?]
> > EventBuffer            Empty
> > Signals                 Empty
> > Audit                    Empty
> > DigitMap               Empty
> >
> > I propose that the above table be added to section 6.2.4 and and the
> text on
> > initial values for properties be modified to refer to the table instead
> > (with suitable reference to packages where applicable).  The question
> marks
> > for Mode and RequestID are because we do not actually specify those
> defaults
> > in our text.
> >
> > The other point to be straightened out is the fact that descriptor-level
> > semantics are important.  I think the following are true statements of
> our
> > intent.  If so, sections 6.2.4 and 7.1.1 should be modified to reflect
> them:
> >
> >  (1) When a specific descriptor is specified in a command, the contents
> of
> > that descriptor completely replace any previous settings of properties
> > within that descriptor.  THERE ARE THREE EXCEPTIONS: DigitMap does its
> > replacement at the level of the individual named digit map, and we
> probably
> > want unspecified properties in TerminationState and LocalControl to
> retain
> > their previous values.
> >
> >  (2) If a specific descriptor is omitted from a command, its previous
> > contents are retained.
> >
> > Tom Taylor
> > Phone and FAX: +1 613 736 0961
> > E-mail: taylor@nortelnetworks.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr 27 17:38:41 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07266
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 27 Apr 2000 17:38:41 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.76B640D0@standards.nortelnetworks.com>; Thu, 27 Apr 2000 17:31:47 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 20035 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Apr 2000 17:30:01 -0400
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.D21B8A40@standards.nortelnetworks.com>; Thu, 27 Apr 2000
          17:20:01 -0400
Received: from zcard015.ca.nortel.com (actually zcard015) by
          smtprch1.nortel.com; Thu, 27 Apr 2000 16:26:14 -0500
Received: from zrtpd00z.us.nortel.com ([47.140.224.110]) by
          zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id JXPSQ8S9; Thu, 27 Apr 2000 17:26:13
          -0400
Received: from americasm10.nt.com (pnc1m006.us.nortel.com [47.142.208.218]) by
          zrtpd00z.us.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2650.21) id JH0J8WQP; Thu, 27 Apr 2000 17:26:12
          -0400
X-Sybari-Space: 00000000 00000000 00000000
X-Sender: "Brown, Michael [NC1:3T19:EXCH]" <mahubard@zrtpd00z>
X-Mailer: Mozilla 4.7 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF67823A@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3908B15B.8BB8D1E6@americasm10.nt.com>
Date:         Thu, 27 Apr 2000 17:30:03 -0400
Reply-To: Michael Brown <C.Michael.Brown@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Michael Brown <C.Michael.Brown@NORTELNETWORKS.COM>
Organization: Nortel Networks
Subject:      Re: Wildcarded context ID?
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Somehow I missed the initial post of this issue.

I would also agree with the understanding that wildcard (ALL for contextid)
does not include the Null contextid, and I thought that the spec was clear
about it NOT being included, so I went to take a look..

In 8.1.2, I found the following sentence,

"The MGC may use the ALL wildcard to address all Contexts on the MG."

The clarification that implies that NULL would not be included above that
sentence is:

"The protocol makes reference to a distinguished value that may be used by
the Media Gateway Controller when referring to a Termination that is
currently not associated with a Context, namely the null ContextID."

While this does pretty clearly imply that a NULL is not really a context but
actually a special contextid, perhaps it's not clear enough.

Also, in the section 7.2.5 on Auditvalue, there is a table which again sort
of implies that Null is not included in the use of the ALL keyword, because
the table differentiates the behavior of NULL and ALL as the specified
context ID. However, the statement in the table for use of the ALL for
contextid could be interpreted to include NULL.

Based on that I would agree with Christian's suggestion that both of these
references should specifically exclude the NULL context.

Michael

"Rosen, Brian" wrote:

> I've already sent a message to the list objecting to this interpretation.
> I agree that wildcard does not include Null context.
>
> Brian
>
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> > Sent: Thursday, April 27, 2000 1:55 PM
> > To: MEGACO@standards.nortelnetworks.com
> > Subject: Re: Wildcarded context ID?
> >
> >
> > It came as a surprise to me.  I'm not really comfortable with
> > it because
> > wildcard audits suddenly get a lot larger.
> >
> > > -----Original Message-----
> > > From: Christian Groves [SMTP:Christian.Groves@ERICSSON.COM]
> > > Sent: Wednesday, April 26, 2000 9:21 PM
> > > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject:      Re: Wildcarded context ID?
> > >
> > > G'Day,
> > >
> > > Is this a common understanding of the list? If so then
> > perhaps we should
> > > document it in the spec. I've asked different people and
> > had different
> > > thoughts on whether or not it should include the NULL context.
> > >
> > > Cheers, Christian
> > >
> > > Harpreet Singh Anand wrote:
> > > >
> > > > Hi Paul,
> > > >
> > > > Paul Hollis wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > just a quick question:
> > > > >
> > > > > Does the wildcard "ALL" for a context ID include the
> > NULL context,
> > > >
> > > > Yes it includes the NULL context also.
> > > >
> > > > > or does it
> > > > > only cover non-Null contexts?
> > > > >
> > > > > Regards Paul.
> > > >
> > > > --
> > > >
> > > > Regards,
> > > > Harpreet
> > > >
> > > > _________________________________
> > > > Harpreet Singh Anand
> > > > Ficon Technology
> > > > E-mail :  mailto:hsanand@ficon-tech.com
> > > > Web    :  http://www.ficon-tech.com
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Apr 27 23:53:45 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12893
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 27 Apr 2000 23:53:44 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D7394B30@standards.nortelnetworks.com>; Thu, 27 Apr 2000 23:46:43 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 20753 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Apr 2000 23:46:41 -0400
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.D6140510@standards.nortelnetworks.com>; Thu, 27 Apr 2000
          23:46:41 -0400
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Thu, 27 Apr 2000 22:52:35 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <JZHNF4LJ>; Thu, 27 Apr 2000 22:52:33 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD11038583EB@zcard00g.ca.nortel.com>
Date:         Thu, 27 Apr 2000 22:52:33 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: [Fwd: On 7.1.14]
X-To:         Flemming Andreasen <fandreas@cisco.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

The issue in this dialogue is handling the extra digit in the case of a
partial digit map match.

If the initial digit map is supposed to provide the complete story, the MGC
can embed a new Events descriptor in the digit map completion event,
containing no event related to digit collection.  This is guaranteed to
clear out the extra digit, since under the current rules that extra digit is
the first event to be processed after the digit map completion is reported.

If, on the success path, more digits will be collected after the first digit
map completion event is reported, the MGC has to examine the reason for the
completion and then send down a Modify with an Events descriptor devoid of
any event related to digit collection followed by a Modify with a repeat of
the first digit map (along, presumably, with the necessary prompting
signals).

There's also a question of when the extra digit event exerts its side
effects.  According to the text I already have in the errata document I sent
out last week, that won't be until the event is recognized according to the
Events descriptor which is active once the digit map completion event is
reported.  Corner case: the mismatch occurs on the first digit.  Issue: does
this mean dial tone doesn't get broken by the dialled digit?  Answer: no
problem -- the digit map completion event does the job.

> -----Original Message-----
> From: Flemming Andreasen [SMTP:fandreas@cisco.com]
> Sent: Wednesday, April 26, 2000 7:06 PM
> To:   Taylor, Tom-PT [NORSE:B901:EXCH]
> Cc:   'Brian Rosen'; 'John Segers'; Flemming Andreasen
> Subject:      Re: [Fwd: On 7.1.14]
>
> Hi Tom
>
> I snipped the ones we are in sync on.
>
> Should this one have gone to the Megaco list as well ?
>
>
> Tom-PT Taylor wrote:
>
>
>
>       Responses below.
>
>               -----Original Message-----
>       From:   Flemming Andreasen [SMTP:fandreas@cisco.com]
>       Sent:   Wednesday, April 05, 2000 11:14 PM
>       To:     Taylor, Tom-PT [CAR:B904:EXCH];
> MEGACO@STANDARDS.NORTELNETWORKS.COM
>       Subject:        [Fwd: On 7.1.14]
>       <snip>
>                       >
>                       > > 11) 7.1.14, numbered list, item 5:    It is
> entirely unclear why an
>                       > > event triggering a partial match is not reported
> as part of the
>                       > matched
>                       > > string. In the absence of a compelling argument,
> the triggering
>                       > event
>                       > > should be included in the string as it otherwise
> may be processed
>                       > twice,
>                       > > which is hardly what the user had in mind.
>                       >         [[TomT]]  I had it that way in the first
> place (with the
>                       > triggering
>                       > event distinguished by being placed in an "extra
> event" parameter) and
>                       >
>                       > consensus was to change it to what it is now.
> Have to overrule you on
>                       > this
>                       > one unless you get more support.
>
>                                       Well, I think it would be more
> appropriate that those who argue against
>                       explain why. There's got to be a reasonable
> explanation here, or
>                       reviewing this stuff is a waste of everybody's time.
>
>                       [[TomT]]
>                       The reasoning was that when you activate a digit map
> it's what the digit map matches that is of interest -- anything left over
> needs to be handled in a separate processing step.  The typical situation
> in our experience is that digit collection happens in multiple stages.
> The MGC doesn't want to receive that extra digit because it wants the
> digit to be processed against the next map to be activated.
>
>               Agreed, but only in the case where the first stage did not
> contain an error, i.e. mismatch. You want to consume the "error" input.
>
>               [PTT]
>       The MGC can do that in advance by embedding the appropriate Events
> descriptor in the digit map completion event, or after the fact by sending
> down the appropriate descriptor.
>
>
> I don't think you can do it in advance as you only want to consume the
> extra event on mismatch. Sending down two EventsDescriptors (two commands)
> introduces a race as you cannot be guaranteed that the first command will
> execute and consume the extra event prior to the second command being
> processed. I still cannot think of a single reason as to why you would not
> want to consume the event that causes a mismatch and it furthermore seems
> far simpler to me so my comment still stands.
>
>
>
>
>
>
>                                       I'll have to think about the "double
> processing" question.  Events have side effects, such as stopping signals,
> and clearly we only want those side effects to happen once.  It may be
> that we need language to make sure this is what happens.
>
> [PTT]
> ... and I now have the necessary language, I think.
>
>
> Did I miss it somewhere ?
>
>
>
>                                       > I'm also not clear how you get
> duplicate
>                       > processing -- the situation is logically
> equivalent to the triggering
>                       > event
>                       > (a non-matching digit) happening just after the
> digit completion event
>                       > has
>                       > been notified.
>
>                                       Consider an IVR menu where input
> consists of two or more digits. For
>                       sake of argument, let's say the only valid choice is
> "12", and I
>                       erroneously enter "13". Upon entering "3" we get a
> mismatch and I
>                       probably hear a recording telling me that "13" is an
> invalid choice and
>                       I should try again.
>                       [[TomT]]
>                       More likely you'll get a recording telling you what
> the valid choices are.  Under our current rules, of course, the MGC
> doesn't know about the 3 when the digit map completion event is reported.
>
>                                       When digit map processing resumes
> for renewed input,
>                       "3" will now be processed and I get another
> mismatch.
>                       [[TomT]]
>                       Seems clear in this case that the MGC should ensure
> that the event buffer is cleared before resuming the operation.
>
>               Agreed, however LockStep doesn't do that, so you have a
> problem.
>       [PTT]
>       It does if you precede your real command with one that has an empty
> Events descriptor.
>
> Ahh, very clever :-)
>
> -- Flemming
>
> --
> Flemming Andreasen                Phone: +1 732 452 1667
> Cisco Systems                     Fax:   +1 240 359 5839
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Apr 28 00:23:42 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13086
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 28 Apr 2000 00:23:41 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0A685560@standards.nortelnetworks.com>; Fri, 28 Apr 2000 0:16:47 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 20787 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Apr 2000 00:15:06 -0400
Received: from smtprch2.nortel.com (192.135.215.15) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.CE5B1A80@standards.nortelnetworks.com>; Fri, 28 Apr 2000
          0:15:06 -0400
Received: from smtprich.nortel.com (actually zrchs148) by smtprch2.nortel.com;
          Thu, 27 Apr 2000 23:18:09 -0500
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprich.nortel.com; Thu, 27 Apr 2000 23:21:43 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id
          <JZHNF4TV>; Thu, 27 Apr 2000 23:20:33 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
X-Orig: <taylor@americasm01.nt.com>
X-Orig: <taylor@nortelnetworks.com>
Message-ID:  <C51ED84B6F47D211917A0000F8BCBD11038583ED@zcard00g.ca.nortel.com>
Date:         Thu, 27 Apr 2000 23:20:32 -0500
Reply-To: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Final Roundup Of Issues
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I have seen no comments on the errata document update I sent out earlier
this week.  What follows is a set of issues and proposed resolutions which
have been under discussion or have been noted in the intervening days.  I
propose to update the errata document with the contents of this E-mail, then
submit it as a formal I-D.  If there are no further comments tomorrow I will
forward it to the IESG for final approval.

Section: 7.2.5, Annex B.2
-----------------
Issue: the text of 7.2.5 allows retrieval of multiple digit maps with one
AuditValue command if the terminationId is ALL.  There is no ABNF syntax to
support this return result.  Note that Annex A has no restriction on the
number of instances of any descriptor in either a command or a response.

Proposed Resolution: add digitMapDescriptor to the exceptions to the
"at-most-once" comment preceding ABNF production auditReturnParameter.

Section: 7.2.5, Annex A.2, Annex B.2
-----------------
Issue: the text in section 7.2.5 mentions that using an empty Audit
descriptor with a wildcarded terminationId is a way to get a list of the
terminations in the context.  Annex A provides the possibility that the
auditReply may be a contextAuditResult of type terminationIdList, and Annex
B allows for an auditReply containing a contextTerminationAudit which in
turn presents a terminationIdList.  The connection between the text in 7.2.5
and these special forms of audit result is not clear.  Moreover, a note at
the beginning of Annex A section A.2 limits terminationIdList to one
terminationId.

Proposed Resolution: add the following text in section 7.2.5 after the
sentence "This may be useful to get a list of TerminationIDs when used with
wildcard.":
"Annexes A and B provide a special syntax for presenting such a list in
condensed form, such that the AuditValue command tag does not have to be
repeated for each terminationId."
Also, in the Note at the beginning of section A.2 of Annex A, provide an
exception on the length of type TerminationIdList when used in
contextAuditResult.

Section: 7.1, Annex A.2, Annex B.2
-----------------
Issue: it is unclear how to express empty descriptors in responses to the
MGC.

Proposed resolution: In section 7.1, add the following text after the
sentence: "Descriptors may be returned as output from a command.":
"In any such return of descriptor contents, an empty descriptor is
represented by its name unaccompanied by any list."

In the ASN.1, add the following choice to the AuditReturnParameter
production:

  "emptyDescriptors               AuditDescriptor,"

Note that this introduces a dependency which may force reordering of the
AuditDescriptor and AuditReturnParameter productions.

In the ABNF, add the choice auditItem to the production
auditReturnParameter.  Redraft the preceding "At-most-once" comment to say:
"; at-most-once for any descriptor or its token, except possibly for
errorDescriptor"

Section: 7.1.11, Annex A.2, Annex B.2
-----------------
Issue: There is a need for the MGC to be aware of signalling failures.  It
is not possible to use the signal completion event to monitor for signalling
failures only, without also having to process successes.

Proposed Resolution: In section 7.1.11, replace the current text on
completion notification, beginning: "Finally, the optional parameter
"notifyCompletion" ..." and continuing to the end of the paragraph with the
following text:

"Finally, the optional parameter "notifyCompletion" allows a MGC to indicate
the circumstances under which it wishes to be notified when the signal
finishes playout.  The possible cases are that the signal timed out, that it
was interrupted by an event, that it was halted when a Signals descriptor
was replaced, or that it stopped or never started for other reasons.  If
"notifyCompletion" is absent, notification is generated in the "other
reasons" case only.  For reporting to occur the signal completion event (see
section E.1.2) must be enabled in the currently active Events descriptor."

In Annex A.2, make notifyCompletion a BIT STRING with the four cases.  In
B.2, make it a parameter consisting of a name and a list of values
representing the possible completion methods.

Section: 8
-----------------
Issue: unclear what state the MG is in if a command fails.

Proposed Resolution: add the statement:
"If a command fails, the MG shall as much as possible restore the state
which existed before execution of the command began."

Section: E.9.2
-----------------
Issue: where hook state differs from the expected one, it is sometimes
desirable that the command fail rather than proceed anyway.

Proposed Resolution: change the possible values for the proposed Strict
Transition EventsDescriptor parameter from On/Off to "State" /
"TransitionOnly" / "Fail", meaning respectively that the event is reported
as soon as the desired state is reached, or is reported only when the
indicated transition is next observed, or the command fails if the hook
state is not as expected.

Also add a new package-specific error code with explanation "Unexpected Hook
State".

Section: Appendix A.1.2
-----------------
Issue: incorrect statement that an RTP termination has no events or signals.
Missing descriptors in the reply as compared with the request in the
previous step.

Resolution: delete the offending sentence.  Add the line "Events, Signals,
DigitMap," after the end of the Media descriptor to show that these other
descriptors are empty.

Tom Taylor
Phone and FAX: +1 613 736 0961
E-mail: taylor@nortelnetworks.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Apr 28 01:31:47 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16897
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 28 Apr 2000 01:31:47 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8C80B0C0@standards.nortelnetworks.com>; Fri, 28 Apr 2000 1:24:50 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 20832 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Apr 2000 01:22:58 -0400
Received: from ish7.ericsson.com.au (203.61.155.111) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.E32FC520@standards.nortelnetworks.com>; Fri, 28 Apr 2000
          1:12:57 -0400
Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by
          ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id PAA17649; Fri,
          28 Apr 2000 15:17:45 +1000 (EST)
Received: from mcsi00.epa.ericsson.se (mcsi00 [146.11.8.201]) by
          brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id PAA29744; Fri, 28
          Apr 2000 15:18:07 +1000 (EST)
Received: from ericsson.com (mcdh183.epa.ericsson.se [146.11.81.183]) by
          mcsi00.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id PAA15566; Fri,
          28 Apr 2000 15:17:58 +1000 (EST)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <C51ED84B6F47D211917A0000F8BCBD11038583ED@zcard00g.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <39091EEA.65234854@ericsson.com>
Date:         Fri, 28 Apr 2000 15:17:30 +1000
Reply-To: Christian Groves <Christian.Groves@ERICSSON.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Christian Groves <Christian.Groves@ERICSSON.COM>
Subject:      Re: Final Roundup Of Issues
X-To:         Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Tom,

An additional one which has just been discussed:
Section: 7.2.5 & 8.1.2
-----------
Issue: Unclear whether wilcarded ALL on contextID includes the NULL
context.
Proposed Resolution:
8.1.2,
"The MGC may use the ALL wildcard to address all Contexts (except the
NULL context) on the MG."

7.2.5
All     wildcard        Audit of all matching Terminations not in the
                        NULL context and the
                        Context to which they are associated

Could you also wait for until Monday to send the draft as different
timezones need time to look at it?

Regards, Christian

Tom-PT Taylor wrote:
>
..snip..
>
> Section: 7.2.5, Annex A.2, Annex B.2
> -----------------
> Issue: the text in section 7.2.5 mentions that using an empty Audit
> descriptor with a wildcarded terminationId is a way to get a list of the
> terminations in the context.  Annex A provides the possibility that the
> auditReply may be a contextAuditResult of type terminationIdList, and Annex
> B allows for an auditReply containing a contextTerminationAudit which in
> turn presents a terminationIdList.  The connection between the text in 7.2.5
> and these special forms of audit result is not clear.  Moreover, a note at
> the beginning of Annex A section A.2 limits terminationIdList to one
> terminationId.
>
> Proposed Resolution: add the following text in section 7.2.5 after the
> sentence "This may be useful to get a list of TerminationIDs when used with
> wildcard.":
> "Annexes A and B provide a special syntax for presenting such a list in
> condensed form, such that the AuditValue command tag does not have to be
> repeated for each terminationId."
> Also, in the Note at the beginning of section A.2 of Annex A, provide an
> exception on the length of type TerminationIdList when used in
> contextAuditResult.

[CHG] I thought that the "special syntax" for terminationID list was not
meant to be used. It was a hook added to the ASN1 for future
upgradability. Do we need have this possibility in v1? Its not an error
and its a bit of a dubious clarification.


>
> Section: 7.1, Annex A.2, Annex B.2
> -----------------
> Issue: it is unclear how to express empty descriptors in responses to the
> MGC.
>
> Proposed resolution: In section 7.1, add the following text after the
> sentence: "Descriptors may be returned as output from a command.":
> "In any such return of descriptor contents, an empty descriptor is
> represented by its name unaccompanied by any list."

[CHG] This is a bit confusing. We don't return lists in descriptors, we
return properties, signal, events events. Does this really need to be
clarified in the main text?

>
> In the ASN.1, add the following choice to the AuditReturnParameter
> production:
>
>   "emptyDescriptors               AuditDescriptor,"
>
> Note that this introduces a dependency which may force reordering of the
> AuditDescriptor and AuditReturnParameter productions.

[CHG] Why do we need to add an "emptyDescriptor" element? We have the
choice not to send anything. We can also send the TAG for the descriptor
without any contents.

>
> In the ABNF, add the choice auditItem to the production
> auditReturnParameter.  Redraft the preceding "At-most-once" comment to say:
> "; at-most-once for any descriptor or its token, except possibly for
> errorDescriptor"
>
> Section: 8
> -----------------
> Issue: unclear what state the MG is in if a command fails.
>
> Proposed Resolution: add the statement:
> "If a command fails, the MG shall as much as possible restore the state
> which existed before execution of the command began."

[CHG] I don't see the point of putting "as much as possible" because
this still leaves the MG in an unknown state which defeats the purpose
of this clarification. We know we can't say "all" because it depends on
how the MG actually parses the command. That's internal MG operation
which we don't dictate here.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Apr 28 11:17:06 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03352
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 28 Apr 2000 11:17:05 -0400 (EDT)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.488BB6B0@standards.nortelnetworks.com>; Fri, 28 Apr 2000 11:09:55 -0400
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 21643 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Apr 2000 11:08:28 -0400
Received: from alemail1.firewall.lucent.com (192.11.221.161) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.14B54C20@standards.nortelnetworks.com>; Fri, 28 Apr 2000
          11:08:28 -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 LAA02923
          for <MEGACO@standards.nortelnetworks.com>; Fri, 28 Apr 2000 11:14:51
          -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
          LAA02891 for <MEGACO@standards.nortelnetworks.com>; Fri, 28 Apr 2000
          11:14:50 -0400 (EDT)
Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id RAA19495; Fri,
          28 Apr 2000 17:14:50 +0200 (MET DST)
Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id
          RAA19380; Fri, 28 Apr 2000 17:14:32 +0200 (MET DST)
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
Original-CC: MEGACO@standards.nortelnetworks.com,
             olivier.legrand@rd.francetelecom.fr, dianda@lucent.com,
             schicker@scicon.ch
References: <C51ED84B6F47D211917A0000F8BCBD11038583ED@zcard00g.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3909AAAF.D16AF6A2@lucent.com>
Date:         Fri, 28 Apr 2000 17:13:51 +0200
Reply-To: John Segers <jsegers@LUCENT.COM>
Sender: "Media Gateway Control (megaco)"
              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: John Segers <jsegers@LUCENT.COM>
Organization: Lucent Technologies
Subject:      Re: Final Roundup Of Issues
X-To:         Tom-PT Taylor <taylor@nortelnetworks.com>
X-cc:         olivier.legrand@rd.francetelecom.fr, dianda@lucent.com,
              schicker@scicon.ch
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Tom,

I received some more comments off-line, mostly of editorial nature.  But
I suppose it's best to have all comments out on the list to be looked
over by anyone who wants to.

At the end of the message, I have some comment about your document.

ATM properties in Annex C
--------------------------
I received some comments from Olivier LeGrand of France Telecom and Bob
Dianda of Lucent about the properties related to ATM.
1. Table C.4, General ATM properties
- The SC (Service Category) field (for CBR, UBR, etc.) does not exist in
Q.2931 or any DSS2 standard.  The parameter was proposed by MSF, but
apparently we got the reference wrong.  Does anybody know the correct
reference from the top of their heads?
- The Broadband Transfer Capability is defined in Q.2961.2, but Q.2961
is referenced.  I propose that we leave this as is, because some BBTC
codepoints are in Q.2961.3, 4, and others.
- ATC field: the value SBR(3) should be replaced by SBR3(3).
- PCR0 and PCR1 fields: should reference Q.2931 because I.371 does not
specify coding details.
- SCR and MBS fields: one of the contributors suggested referencing
Q.2961.1 for similar reasons.
- SCR2 field: should be called SCR1 as it pertains to sustainable cell
rate for CLP=0+1.
- MBS3 field: should be callsed MBS1 as is pertains to sustainable cell
rate for CLP=0+1.
- Are forward/backward indications needed for the cell rate and burst
size fields?
- Some parameters are missing for ABR and ABT (allowed values in ATC
field): MCR is one.  Any others?
- GFRs needed?
- Tagging indicator (TI): one of the contributors suggested including a
reference to Q.2961.1; also, may need backward and forward indicators.
- Frame Discard (FD): add reference to I.371, need forward/backward
separated?
- BCLR0 and BCLR1 fields: should not have P-P in value column.
- Qos properties (FCCDV to EETD): it's unclear for some whether they
apply to CLP=0 or CLP=0+1.  Brian noted a long time ago in the liaison
from MSF that there were omissions in this area, but it never got
fixed.  I'm not comfortable enough with ATM to make the change.
- FACDV field: replace P-P-P by P-P.
- End-to-end Transit Delay (EETD): need two parameters, acceptable and
cumulative.
- Cell delay variation: ATM forum and ITU use a different CDV (peak to
peak as opposed to 2 point).  It was suggested to add a reference to
Q.2965.2.
- QosClass: the table in the value column is unclear, and the reference
to Q.2931 should be replaced by a reference to Q.2965.1.

2. Table C.7, ATM AAL2
- SCLP field: isn't cell loss priority set at ATM level?
- EETR: broadband bearer capability has been amended and EETR does not
exist any longer.  What is the intended use of the field?  Indicating
that an ATM path providing  end-to-end timing requirements is to be
used?

3. Table C.8, ATM AAL1
- Same question for EETR as under 2.

4. Table C.10, ATM AAL5
- SC: same comment as under 1.  Or are different values intended here?
- EETR: why is there no EETR field for AAL5?

Additional comments to the draft
--------------------------------
Some of this came from Pietro Schicker.
1. Annex A.1, explanation of PropertyParm
The explanation is unclear and can be improved by adding the text
"without extraInfo present" in two places:

-- In PropertyParm , value is a SEQUENCE OF octet string. When sent
[...]
-- one element sequence _without extraInfo present_ specifies value
-- longer sequence _without extraInfo present_ means "choose one of the
values"
[...]

2. Section 7.1.14, DigitMap Descriptor
It was suggested to add subsection headings to add more structure to
this section (it has grown quite a bit over time).  My proposal is to
add the following subsections.

7.1.14.1 DigitMap definition, creation, modification and termination
(before first paragraph)
7.1.14.2 DigitMap Timers
(after the first bullet list)
7.1.14.3 DigitMap syntax
(before the long paragraph starting "The formal syntax of the digit map
[...]")
7.1.14.4 DigitMap completion event
(before the paragraph starting "A digit map is active while the events
descriptor [...]")
7.1.14.5 DigitMap procedures
(before the sentence "Pending completion, successive events shall be
processed [...]", preceding the numbered list)
7.1.14.6 DigitMap activation
(after the numbered list)
7.1.14.7 Interaction of DigitMap and event processing
(before the next paragraph, starting "While the digit map is activated,
[...]")
7.1.14.8 Wildcards
(before the the next paragraph, staring "Note that if a package contains
[...]")
7.1.14.9 Example
(before the example)

3. My notes from Geneva _seem_ to record a decision to add a new
subsection explaining the errorDescriptor.  This new subsection has not
been added.  Does anyone recall the decision (I couldn't find it in the
Geneva meeting report).

4. Section 8.1.1.  Suggest adding text indicating that TransactionId 0
is reserved for responses to erroneous trnasactions with a x-ref to
8.2.2.

5. Error codes in packages.  My notes from Geneva reminded me that we
discussed adding a section about error codes defined in packages, but no
resolution.  Is this desirable?

6. Appendix A
The example profile is called ResGW, while the document refers to
gateways as MGs (minor nit).

Comments on Tom's internet-draft
--------------------------------
1. Section 7.1.4.  There was some discussion about properties of root.
The resolution (as far as I remember) was to add text stating that they
are in TerminationState.  Should this be added to the document?

2. Section 7.2.3.  Needs a similar remark as suggested for 7.2.4, that
CHOOSE cannot be used for TerminationId in Subtract command.

3. ASN.1 and ABNF.  I remember some discussion on the minimum length of
the authdata (e.g. message from Tom, Apr 13, in thread "Interim AH in
Megaco").  Do we need to change the minimum length to 24 hex digits (12
octets)?

Cheers,

John

Tom-PT Taylor wrote:
>
> I have seen no comments on the errata document update I sent out earlier
> this week.  What follows is a set of issues and proposed resolutions which
> have been under discussion or have been noted in the intervening days.  I
> propose to update the errata document with the contents of this E-mail, then
> submit it as a formal I-D.  If there are no further comments tomorrow I will
> forward it to the IESG for final approval.
>
> Section: 7.2.5, Annex B.2
> -----------------
> Issue: the text of 7.2.5 allows retrieval of multiple digit maps with one
> AuditValue command if the terminationId is ALL.  There is no ABNF syntax to
> support this return result.  Note that Annex A has no restriction on the
> number of instances of any descriptor in either a command or a response.
>
> Proposed Resolution: add digitMapDescriptor to the exceptions to the
> "at-most-once" comment preceding ABNF production auditReturnParameter.
>
> Section: 7.2.5, Annex A.2, Annex B.2
> -----------------
> Issue: the text in section 7.2.5 mentions that using an empty Audit
> descriptor with a wildcarded terminationId is a way to get a list of the
> terminations in the context.  Annex A provides the possibility that the
> auditReply may be a contextAuditResult of type terminationIdList, and Annex
> B allows for an auditReply containing a contextTerminationAudit which in
> turn presents a terminationIdList.  The connection between the text in 7.2.5
> and these special forms of audit result is not clear.  Moreover, a note at
> the beginning of Annex A section A.2 limits terminationIdList to one
> terminationId.
>
> Proposed Resolution: add the following text in section 7.2.5 after the
> sentence "This may be useful to get a list of TerminationIDs when used with
> wildcard.":
> "Annexes A and B provide a special syntax for presenting such a list in
> condensed form, such that the AuditValue command tag does not have to be
> repeated for each terminationId."
> Also, in the Note at the beginning of section A.2 of Annex A, provide an
> exception on the length of type TerminationIdList when used in
> contextAuditResult.
>
> Section: 7.1, Annex A.2, Annex B.2
> -----------------
> Issue: it is unclear how to express empty descriptors in responses to the
> MGC.
>
> Proposed resolution: In section 7.1, add the following text after the
> sentence: "Descriptors may be returned as output from a command.":
> "In any such return of descriptor contents, an empty descriptor is
> represented by its name unaccompanied by any list."
>
> In the ASN.1, add the following choice to the AuditReturnParameter
> production:
>
>   "emptyDescriptors               AuditDescriptor,"
>
> Note that this introduces a dependency which may force reordering of the
> AuditDescriptor and AuditReturnParameter productions.
>
> In the ABNF, add the choice auditItem to the production
> auditReturnParameter.  Redraft the preceding "At-most-once" comment to say:
> "; at-most-once for any descriptor or its token, except possibly for
> errorDescriptor"
>
> Section: 7.1.11, Annex A.2, Annex B.2
> -----------------
> Issue: There is a need for the MGC to be aware of signalling failures.  It
> is not possible to use the signal completion event to monitor for signalling
> failures only, without also having to process successes.
>
> Proposed Resolution: In section 7.1.11, replace the current text on
> completion notification, beginning: "Finally, the optional parameter
> "notifyCompletion" ..." and continuing to the end of the paragraph with the
> following text:
>
> "Finally, the optional parameter "notifyCompletion" allows a MGC to indicate
> the circumstances under which it wishes to be notified when the signal
> finishes playout.  The possible cases are that the signal timed out, that it
> was interrupted by an event, that it was halted when a Signals descriptor
> was replaced, or that it stopped or never started for other reasons.  If
> "notifyCompletion" is absent, notification is generated in the "other
> reasons" case only.  For reporting to occur the signal completion event (see
> section E.1.2) must be enabled in the currently active Events descriptor."
>
> In Annex A.2, make notifyCompletion a BIT STRING with the four cases.  In
> B.2, make it a parameter consisting of a name and a list of values
> representing the possible completion methods.
>
> Section: 8
> -----------------
> Issue: unclear what state the MG is in if a command fails.
>
> Proposed Resolution: add the statement:
> "If a command fails, the MG shall as much as possible restore the state
> which existed before execution of the command began."
>
> Section: E.9.2
> -----------------
> Issue: where hook state differs from the expected one, it is sometimes
> desirable that the command fail rather than proceed anyway.
>
> Proposed Resolution: change the possible values for the proposed Strict
> Transition EventsDescriptor parameter from On/Off to "State" /
> "TransitionOnly" / "Fail", meaning respectively that the event is reported
> as soon as the desired state is reached, or is reported only when the
> indicated transition is next observed, or the command fails if the hook
> state is not as expected.
>
> Also add a new package-specific error code with explanation "Unexpected Hook
> State".
>
> Section: Appendix A.1.2
> -----------------
> Issue: incorrect statement that an RTP termination has no events or signals.
> Missing descriptors in the reply as compared with the request in the
> previous step.
>
> Resolution: delete the offending sentence.  Add the line "Events, Signals,
> DigitMap," after the end of the Media descriptor to show that these other
> descriptors are empty.
>
> Tom Taylor
> Phone and FAX: +1 613 736 0961
> E-mail: taylor@nortelnetworks.com

--
John Segers                                  email: jsegers@lucent.com
Lucent Technologies                                        Room HE 306
Dept. Forward Looking Work                      phone: +31 35 687 4724
P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954