From megaco-admin@ietf.org Thu Apr 1 04:50:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03667 for ; Thu, 1 Apr 2004 04:50:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8ypl-00028d-WB; Thu, 01 Apr 2004 04:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8yoo-00022O-1x for megaco@optimus.ietf.org; Thu, 01 Apr 2004 04:49:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03602 for ; Thu, 1 Apr 2004 04:48:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8yok-0005uN-00 for megaco@ietf.org; Thu, 01 Apr 2004 04:48:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8ynk-0005qL-00 for megaco@ietf.org; Thu, 01 Apr 2004 04:47:57 -0500 Received: from [202.41.97.50] (helo=u1.doe.ernet.in) by ietf-mx with esmtp (Exim 4.12) id 1B8ymp-0005li-00 for Megaco@ietf.org; Thu, 01 Apr 2004 04:47:01 -0500 Received: from uucp-relay-delhi.ernet.in (uucp-relay-delhi.ernet.in [202.41.97.134]) by u1.doe.ernet.in (8.12.8/8.12.8) with ESMTP id i319YONp025114; Thu, 1 Apr 2004 15:04:29 +0530 Received: by uucp-relay-delhi.ernet.in (8.9.3+Sun/SMI-4.1-MHS-7.0) id PAA25641; Thu, 1 Apr 2004 15:28:05 -0500 (GMT) >Received: from cdotd.ernet.in by cdotd.cdotd.ernet.in (SMI-8.6/SMI-SVR4) id OAA05551; Thu, 1 Apr 2004 14:58:17 -0500 X-Authentication-Warning: relay.cdotd.ernet.in: iscan owned process doing -bs Message-ID: <406BDD21.7D3889A0@cdotd.ernet.in> Date: Thu, 01 Apr 2004 14:43:05 +0530 From: Prateek Raj Singh Organization: CDOT X-Mailer: Mozilla 4.73 [en] (X11; I; HP-UX B.11.00 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: Kevin Boyle CC: Megaco@ietf.org Subject: Re: [Megaco] subscription :Megaco query References: Received: from cdotd by vikram.eis.ernet.in; Thu, 1 Apr 2004 15:28 GMT Content-Type: multipart/alternative; boundary="------------0210785DD2F162D148A32506" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, LINES_OF_YELLING,MSGID_FROM_MTA_HEADER autolearn=no version=2.60 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --------------0210785DD2F162D148A32506 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hi Kevin , What will be the state of the terminations which are present at the time of MGW get fail ? What mechanism provided by the megaco to maintain the same state at the both end MGC and MGW ? regards, prateek Kevin Boyle wrote: > > > Procedures for MGC control of MGs are described in the spec. > Essentially, the MGC would have to wait for the MG to return to > service. > > Kevin > > -----Original Message----- > From: Prateek Raj Singh Pawar [mailto:prateek@cdotd.ernet.in] > Sent: Wednesday, March 24, 2004 11:38 PM > To: Megaco@ietf.org > Cc: Prateek Raj Singh > Subject: [Megaco] subscription :Megaco query > > Hi , > > This is parteek , working in C-DOT Indian goverment telecom research > center . we are currently working on the 3G MSC Server . > > Pls add me in the mailing list of megaco . > > I h've some queries related with the megaco . > > What are the control procedure if MGC control only one MGW > configuration and MGW will fail . > > with regards, > PRATEEK RAJ SINGH PAWAR > Research Engineer > 3G Mobile Solutions > C-DOT Ph(O):24677525 ext. 324 > Room No 824,9th Floor Cell : +919810652039 Akber Bhavan ,Chankya > mail :pprateekraj@yahoo > Puri , New Delhi-21 pratraj@rediff > > --------------------------------------------------------------------------- > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco -- PRATEEK RAJ SINGH PAWAR Research Engineer Mobile Solutions C-DOT Ph(O):24677525 ext. 324 Room No 824,9th Floor Cell : +919810652039 Akber Bhavan ,Chankya mail :pprateekraj@yahoo Puri , New Delhi-21 pratraj@rediff ---------------------------------------------------------------------------- --------------0210785DD2F162D148A32506 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit hi Kevin ,

What will be the state of the terminations which are  present at the time of MGW get fail ?
What mechanism provided by the megaco to maintain the same state at the both end MGC and MGW ?
 

regards,
prateek
Kevin Boyle wrote:

 

Procedures for MGC control of MGs are described in the spec.  Essentially, the MGC would have to wait for the MG to return to service.

Kevin

-----Original Message-----
From: Prateek Raj Singh Pawar [mailto:prateek@cdotd.ernet.in]
Sent: Wednesday, March 24, 2004 11:38 PM
To: Megaco@ietf.org
Cc: Prateek Raj Singh
Subject: [Megaco] subscription :Megaco query

Hi ,

This is parteek , working in C-DOT Indian goverment telecom research center . we are currently working on the 3G MSC Server .

Pls add me in the mailing list of megaco .

I h've some queries related with the megaco .

What are the control procedure if  MGC control only one MGW configuration and MGW will fail .

with regards,
PRATEEK RAJ SINGH PAWAR
  Research Engineer
  3G  Mobile Solutions
      C-DOT            Ph(O):24677525 ext. 324
Room No 824,9th Floor  Cell : +919810652039 Akber Bhavan ,Chankya  mail :pprateekraj@yahoo
Puri ,  New Delhi-21         pratraj@rediff
----------------------------------------------------------------------------
 

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

-- 

PRATEEK RAJ SINGH PAWAR 
  Research Engineer 
   Mobile Solutions   
      C-DOT            Ph(O):24677525 ext. 324
Room No 824,9th Floor  Cell : +919810652039
Akber Bhavan ,Chankya  mail :pprateekraj@yahoo
Puri ,  New Delhi-21         pratraj@rediff 
----------------------------------------------------------------------------
  --------------0210785DD2F162D148A32506-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Apr 1 04:52:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03791 for ; Thu, 1 Apr 2004 04:52:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8yri-0002Lk-3U for megaco-archive@odin.ietf.org; Thu, 01 Apr 2004 04:52:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i319q2GT009021 for megaco-archive@odin.ietf.org; Thu, 1 Apr 2004 04:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8yrh-0002LE-Gj for megaco-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 04:52:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03748 for ; Thu, 1 Apr 2004 04:51:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8yre-0006CB-00 for megaco-web-archive@ietf.org; Thu, 01 Apr 2004 04:51:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8yqh-00067k-00 for megaco-web-archive@ietf.org; Thu, 01 Apr 2004 04:51:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8ypp-00061W-00 for megaco-web-archive@ietf.org; Thu, 01 Apr 2004 04:50:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8ypl-00028d-WB; Thu, 01 Apr 2004 04:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8yoo-00022O-1x for megaco@optimus.ietf.org; Thu, 01 Apr 2004 04:49:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03602 for ; Thu, 1 Apr 2004 04:48:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8yok-0005uN-00 for megaco@ietf.org; Thu, 01 Apr 2004 04:48:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8ynk-0005qL-00 for megaco@ietf.org; Thu, 01 Apr 2004 04:47:57 -0500 Received: from [202.41.97.50] (helo=u1.doe.ernet.in) by ietf-mx with esmtp (Exim 4.12) id 1B8ymp-0005li-00 for Megaco@ietf.org; Thu, 01 Apr 2004 04:47:01 -0500 Received: from uucp-relay-delhi.ernet.in (uucp-relay-delhi.ernet.in [202.41.97.134]) by u1.doe.ernet.in (8.12.8/8.12.8) with ESMTP id i319YONp025114; Thu, 1 Apr 2004 15:04:29 +0530 Received: by uucp-relay-delhi.ernet.in (8.9.3+Sun/SMI-4.1-MHS-7.0) id PAA25641; Thu, 1 Apr 2004 15:28:05 -0500 (GMT) >Received: from cdotd.ernet.in by cdotd.cdotd.ernet.in (SMI-8.6/SMI-SVR4) id OAA05551; Thu, 1 Apr 2004 14:58:17 -0500 X-Authentication-Warning: relay.cdotd.ernet.in: iscan owned process doing -bs Message-ID: <406BDD21.7D3889A0@cdotd.ernet.in> Date: Thu, 01 Apr 2004 14:43:05 +0530 From: Prateek Raj Singh Organization: CDOT X-Mailer: Mozilla 4.73 [en] (X11; I; HP-UX B.11.00 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: Kevin Boyle CC: Megaco@ietf.org Subject: Re: [Megaco] subscription :Megaco query References: Received: from cdotd by vikram.eis.ernet.in; Thu, 1 Apr 2004 15:28 GMT Content-Type: multipart/alternative; boundary="------------0210785DD2F162D148A32506" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, LINES_OF_YELLING,MSGID_FROM_MTA_HEADER autolearn=no version=2.60 --------------0210785DD2F162D148A32506 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hi Kevin , What will be the state of the terminations which are present at the time of MGW get fail ? What mechanism provided by the megaco to maintain the same state at the both end MGC and MGW ? regards, prateek Kevin Boyle wrote: > > > Procedures for MGC control of MGs are described in the spec. > Essentially, the MGC would have to wait for the MG to return to > service. > > Kevin > > -----Original Message----- > From: Prateek Raj Singh Pawar [mailto:prateek@cdotd.ernet.in] > Sent: Wednesday, March 24, 2004 11:38 PM > To: Megaco@ietf.org > Cc: Prateek Raj Singh > Subject: [Megaco] subscription :Megaco query > > Hi , > > This is parteek , working in C-DOT Indian goverment telecom research > center . we are currently working on the 3G MSC Server . > > Pls add me in the mailing list of megaco . > > I h've some queries related with the megaco . > > What are the control procedure if MGC control only one MGW > configuration and MGW will fail . > > with regards, > PRATEEK RAJ SINGH PAWAR > Research Engineer > 3G Mobile Solutions > C-DOT Ph(O):24677525 ext. 324 > Room No 824,9th Floor Cell : +919810652039 Akber Bhavan ,Chankya > mail :pprateekraj@yahoo > Puri , New Delhi-21 pratraj@rediff > > --------------------------------------------------------------------------- > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco -- PRATEEK RAJ SINGH PAWAR Research Engineer Mobile Solutions C-DOT Ph(O):24677525 ext. 324 Room No 824,9th Floor Cell : +919810652039 Akber Bhavan ,Chankya mail :pprateekraj@yahoo Puri , New Delhi-21 pratraj@rediff ---------------------------------------------------------------------------- --------------0210785DD2F162D148A32506 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit hi Kevin ,

What will be the state of the terminations which are  present at the time of MGW get fail ?
What mechanism provided by the megaco to maintain the same state at the both end MGC and MGW ?
 

regards,
prateek
Kevin Boyle wrote:

 

Procedures for MGC control of MGs are described in the spec.  Essentially, the MGC would have to wait for the MG to return to service.

Kevin

-----Original Message-----
From: Prateek Raj Singh Pawar [mailto:prateek@cdotd.ernet.in]
Sent: Wednesday, March 24, 2004 11:38 PM
To: Megaco@ietf.org
Cc: Prateek Raj Singh
Subject: [Megaco] subscription :Megaco query

Hi ,

This is parteek , working in C-DOT Indian goverment telecom research center . we are currently working on the 3G MSC Server .

Pls add me in the mailing list of megaco .

I h've some queries related with the megaco .

What are the control procedure if  MGC control only one MGW configuration and MGW will fail .

with regards,
PRATEEK RAJ SINGH PAWAR
  Research Engineer
  3G  Mobile Solutions
      C-DOT            Ph(O):24677525 ext. 324
Room No 824,9th Floor  Cell : +919810652039 Akber Bhavan ,Chankya  mail :pprateekraj@yahoo
Puri ,  New Delhi-21         pratraj@rediff
----------------------------------------------------------------------------
 

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

-- 

PRATEEK RAJ SINGH PAWAR 
  Research Engineer 
   Mobile Solutions   
      C-DOT            Ph(O):24677525 ext. 324
Room No 824,9th Floor  Cell : +919810652039
Akber Bhavan ,Chankya  mail :pprateekraj@yahoo
Puri ,  New Delhi-21         pratraj@rediff 
----------------------------------------------------------------------------
  --------------0210785DD2F162D148A32506-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Apr 1 05:40:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05302 for ; Thu, 1 Apr 2004 05:40:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8zc9-0006Fw-G4; Thu, 01 Apr 2004 05:40:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8zbD-0006By-8D for megaco@optimus.ietf.org; Thu, 01 Apr 2004 05:39:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05272 for ; Thu, 1 Apr 2004 05:38:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8zb9-0002If-00 for megaco@ietf.org; Thu, 01 Apr 2004 05:38:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8zaB-0002F3-00 for megaco@ietf.org; Thu, 01 Apr 2004 05:38:00 -0500 Received: from [202.41.97.50] (helo=u1.doe.ernet.in) by ietf-mx with esmtp (Exim 4.12) id 1B8zZR-0002BW-00 for Megaco@ietf.org; Thu, 01 Apr 2004 05:37:13 -0500 Received: from uucp-relay-delhi.ernet.in (uucp-relay-delhi.ernet.in [202.41.97.134]) by u1.doe.ernet.in (8.12.8/8.12.8) with ESMTP id i31AOtNp026774 for ; Thu, 1 Apr 2004 15:54:56 +0530 Received: by uucp-relay-delhi.ernet.in (8.9.3+Sun/SMI-4.1-MHS-7.0) id QAA29336; Thu, 1 Apr 2004 16:18:36 -0500 (GMT) >Received: from cdotd.ernet.in by cdotd.cdotd.ernet.in (SMI-8.6/SMI-SVR4) id QAA07977; Thu, 1 Apr 2004 16:05:48 -0500 X-Authentication-Warning: relay.cdotd.ernet.in: iscan owned process doing -bs Message-ID: <406BECF4.27305AAB@cdotd.ernet.in> Date: Thu, 01 Apr 2004 15:50:36 +0530 From: Prateek Raj Singh Organization: CDOT X-Mailer: Mozilla 4.73 [en] (X11; I; HP-UX B.11.00 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: Megaco@ietf.org Received: from cdotd by vikram.eis.ernet.in; Thu, 1 Apr 2004 16:18 GMT Content-Type: multipart/alternative; boundary="------------4927A19ECC5FEDD3B0F0442B" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, MSGID_FROM_MTA_HEADER autolearn=no version=2.60 Subject: [Megaco] Megaco mib Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --------------4927A19ECC5FEDD3B0F0442B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi , Pls tell me the mib for ASN.1 encoding of Megaco regards, Prateek -- PRATEEK RAJ SINGH PAWAR Research Engineer Mobile Solutions C-DOT Ph(O):24677525 ext. 324 Room No 824,9th Floor Cell : +919810652039 Akber Bhavan ,Chankya mail :pprateekraj@yahoo Puri , New Delhi-21 pratraj@rediff ---------------------------------------------------------------------------- --------------4927A19ECC5FEDD3B0F0442B Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit     Hi ,
 
Pls tell me the mib for ASN.1 encoding of Megaco
regards,
Prateek 
-- 

PRATEEK RAJ SINGH PAWAR 
  Research Engineer 
   Mobile Solutions   
      C-DOT            Ph(O):24677525 ext. 324
Room No 824,9th Floor  Cell : +919810652039
Akber Bhavan ,Chankya  mail :pprateekraj@yahoo
Puri ,  New Delhi-21         pratraj@rediff 
----------------------------------------------------------------------------
  --------------4927A19ECC5FEDD3B0F0442B-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Apr 1 05:42:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05355 for ; Thu, 1 Apr 2004 05:42:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8ze3-0006Qq-N7 for megaco-archive@odin.ietf.org; Thu, 01 Apr 2004 05:41:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i31AfxPr024720 for megaco-archive@odin.ietf.org; Thu, 1 Apr 2004 05:41:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8ze3-0006Qd-EJ for megaco-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 05:41:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05334 for ; Thu, 1 Apr 2004 05:41:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8ze0-0002Wz-00 for megaco-web-archive@ietf.org; Thu, 01 Apr 2004 05:41:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8zd3-0002Sg-00 for megaco-web-archive@ietf.org; Thu, 01 Apr 2004 05:40:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8zc7-0002Mu-00 for megaco-web-archive@ietf.org; Thu, 01 Apr 2004 05:39:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8zc9-0006Fw-G4; Thu, 01 Apr 2004 05:40:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8zbD-0006By-8D for megaco@optimus.ietf.org; Thu, 01 Apr 2004 05:39:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05272 for ; Thu, 1 Apr 2004 05:38:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8zb9-0002If-00 for megaco@ietf.org; Thu, 01 Apr 2004 05:38:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8zaB-0002F3-00 for megaco@ietf.org; Thu, 01 Apr 2004 05:38:00 -0500 Received: from [202.41.97.50] (helo=u1.doe.ernet.in) by ietf-mx with esmtp (Exim 4.12) id 1B8zZR-0002BW-00 for Megaco@ietf.org; Thu, 01 Apr 2004 05:37:13 -0500 Received: from uucp-relay-delhi.ernet.in (uucp-relay-delhi.ernet.in [202.41.97.134]) by u1.doe.ernet.in (8.12.8/8.12.8) with ESMTP id i31AOtNp026774 for ; Thu, 1 Apr 2004 15:54:56 +0530 Received: by uucp-relay-delhi.ernet.in (8.9.3+Sun/SMI-4.1-MHS-7.0) id QAA29336; Thu, 1 Apr 2004 16:18:36 -0500 (GMT) >Received: from cdotd.ernet.in by cdotd.cdotd.ernet.in (SMI-8.6/SMI-SVR4) id QAA07977; Thu, 1 Apr 2004 16:05:48 -0500 X-Authentication-Warning: relay.cdotd.ernet.in: iscan owned process doing -bs Message-ID: <406BECF4.27305AAB@cdotd.ernet.in> Date: Thu, 01 Apr 2004 15:50:36 +0530 From: Prateek Raj Singh Organization: CDOT X-Mailer: Mozilla 4.73 [en] (X11; I; HP-UX B.11.00 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: Megaco@ietf.org Received: from cdotd by vikram.eis.ernet.in; Thu, 1 Apr 2004 16:18 GMT Content-Type: multipart/alternative; boundary="------------4927A19ECC5FEDD3B0F0442B" Subject: [Megaco] Megaco mib Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, MSGID_FROM_MTA_HEADER autolearn=no version=2.60 --------------4927A19ECC5FEDD3B0F0442B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi , Pls tell me the mib for ASN.1 encoding of Megaco regards, Prateek -- PRATEEK RAJ SINGH PAWAR Research Engineer Mobile Solutions C-DOT Ph(O):24677525 ext. 324 Room No 824,9th Floor Cell : +919810652039 Akber Bhavan ,Chankya mail :pprateekraj@yahoo Puri , New Delhi-21 pratraj@rediff ---------------------------------------------------------------------------- --------------4927A19ECC5FEDD3B0F0442B Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit     Hi ,
 
Pls tell me the mib for ASN.1 encoding of Megaco
regards,
Prateek 
-- 

PRATEEK RAJ SINGH PAWAR 
  Research Engineer 
   Mobile Solutions   
      C-DOT            Ph(O):24677525 ext. 324
Room No 824,9th Floor  Cell : +919810652039
Akber Bhavan ,Chankya  mail :pprateekraj@yahoo
Puri ,  New Delhi-21         pratraj@rediff 
----------------------------------------------------------------------------
  --------------4927A19ECC5FEDD3B0F0442B-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Apr 1 15:32:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00290 for ; Thu, 1 Apr 2004 15:32:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B98q6-0005YA-Ux; Thu, 01 Apr 2004 15:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8yEx-0008En-QF for megaco@optimus.ietf.org; Thu, 01 Apr 2004 04:12:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02828 for ; Thu, 1 Apr 2004 04:11:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8yEv-0003He-00 for megaco@ietf.org; Thu, 01 Apr 2004 04:11:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8yE4-0003ET-00 for megaco@ietf.org; Thu, 01 Apr 2004 04:11:06 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1B8yDP-00039B-00 for megaco@ietf.org; Thu, 01 Apr 2004 04:10:23 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i319AKqY012668 for ; Thu, 1 Apr 2004 11:10:23 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 1 Apr 2004 11:10:20 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 1 Apr 2004 11:10:29 +0200 Message-ID: <2EFFD98DEBD6FD42AA1B21153E735975383B91@esealnt803.al.sw.ericsson.se> From: =?iso-8859-1?Q?T=F6nu_Trump_=28AS/EAB=29?= To: "'peter.goldstein@ties.itu.int'" , albrecht.schwarz@alcatel.de Cc: adrian.soncodi@tekelec.com, megaco@ietf.org, tsg15q7@itu.int Subject: RE: Re: H.248.xx Enhanced Acoustic Control Package; RE: Basic Mod el & Near End Definition; RE: [Megaco] Question on echo control direction Date: Thu, 1 Apr 2004 11:09:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 01 Apr 2004 09:10:20.0548 (UTC) FILETIME=[28510440:01C417C9] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Dear all, The Draft ITU-T Rec. G.799.1 is clearly stating which direction the = network echo cancellers need to be connected: 8.1.1 Echo Control In compliance with ITU-T Rec. G.177, Transmission Planning for = voiceband services over hybrid internet/PSTN connections, a = voice-over-IP connection traversing a hybrid is required to include a = G.168 compliant echo canceller. Since the echo canceller needs to have = a constant delay for its echo path, it shall be placed so that the echo = path is on the TDM side of the interface that includes the hybrid. = Issues that need to be addressed are: =B7 Issues related to modem and other voice-band data signals =B7 Tail Capacity Network Operators and Service Providers should ensure that echo = cancellation is applied in the most appropriate location for the = specific configuration. The echo canceller shall be associated with the = TIGIN gateway in one of three possible configurations, as outlined in = the following sections. =20 It should be reinforced that all voice connections involving GSTN to IP = interworking involving a hybrid require echo cancellation and the = Network Operator or Service Provider choosing to utilize either = configuration B or C below should ensure that an echo canceller is = provisioned on the TDM bearer side of the hybrid Internet/GSTN = connection.=20 Best regards, T=F5nu Trump Rapporteur Q.7/15 -----Original Message----- From: owner-tsg15q7@itu.int [mailto:owner-tsg15q7@itu.int]On Behalf Of peter.goldstein@ties.itu.int Sent: den 31 mars 2004 10:12 To: albrecht.schwarz@alcatel.de Cc: adrian.soncodi@tekelec.com; megaco@ietf.org; tsg15q7@itu.int Subject: Fwd: Re: H.248.xx Enhanced Acoustic Control Package; RE: Basic Model & Near End Definition; RE: [Megaco] Question on echo control direction ----- Forwarded message from pgoldste@ties.itu.ch ----- From: pgoldste@ties.itu.ch Reply-To: pgoldste@ties.itu.ch Subject: Re: H.248.xx Enhanced Acoustic Control Package; RE: Basic = Model &=20 Near End Definition; RE: [Megaco] Question on echo control direction To: Albrecht.Schwarz@alcatel.de Dear All, ITU-T Rec.Q.115.1 describes where and when Echo Control Devices are = needed and=20 provided in a voice call. This nezwork logic is independent of the = signalling=20 systems used and the network technology (TDM, Mobile, Packet). ITU-T Rec.Q.115.0 describes protocols to control Echo Control Devices = (on a per=20 call basis). In a TDM network this may be something like c-bit of time = slot 16=20 (PCM 30); in a VoIP GW a H.248 SPNE (Signal Processing Network = Equipment)=20 Package has been defined, this allows a MGC to control a ECD associated = with a=20 MG. This package complements the TDM Package which does not provide the = required flexibility (an ECD may have to be controlled at any point in = time of=20 a call). ITU-T Rec. Q.115.1 refers to Network Echo Control Devices (e.g. Echo=20 Cancellers, Echosuppressors). There exist a final draft new REC.Q.115.2 Logic for the Control of VEDs = (Voice=20 Enhancement Devices/Functions). Acoustic Echo Control is part of such a = device/function. >From the control point of view Echo Control Devices are considered to=20 be "half", i.e. an ECD is controlling the echo from only one echo = source. If a=20 specific implementation provides "full" echo control then this is = considered as=20 two "halfs" and the two "halfs" are controlled independently. regards; Peter Goldstein Siemens Switzerland (Rapporteur Q.10/11) =20 =20 Quoting Albrecht.Schwarz@alcatel.de: >=20 > Adrian, >=20 > when reading the Half Echo-Control Device (HECD) section, I was = reminded to > Q.115.1 and G.799.1: >=20 > ITU-T Recommendation Q.115.1 > Logic for the control of echo control devices and functions >=20 > ITU-T Recommendation G.799.1 >=20 > Functionality and Interface Specifications for GSTN Transport Network > Equipment for Interconnecting GSTN and IP Networks >=20 >=20 >=20 > For instance, Q.115.1 is, inter alia, providing definitions for = incoming > echo control device (IECD) and outgoing echo control device (OECD), = G.799.1 > is extensively dealing with EC in TDM-to-Packet media gateways. >=20 >=20 >=20 > Did you already consider these ITU-T recs. in your package proposal? = I > guess that we need alignment. >=20 >=20 >=20 > May anyone of the Q7/15 experts comment on the HECD block in the = proposed > H.248 package. >=20 >=20 >=20 > Regards, >=20 > Albrecht >=20 >=20 >=20 >=20 >=20 > = =20 > = =20 > "Soncodi, Adrian" = =20 > = =20 > SCHWARZ/DE/ALCATEL@ALCATEL = =20 > =20 > ekelec.com> cc: = =20 > = =20 > Subject: H.248.xx = Enhanced > Acoustic Control Package; RE: Basic Model & Near End Definition; RE: = =20 > 29.03.2004 21:17 [Megaco] Question on = echo > control direction = =20 > = =20 > = =20 > = =20 > = =20 >=20 >=20 >=20 >=20 > Albrecht, >=20 > Still on the EC issue... I may be jumping ahead here while you are = trying > to propose a resolution, but this is what I think: >=20 > First, it doesn't look like we can "fix" the EC omission in the TDM = package > without affecting either some existing MG implementations or some = MGC-MG > procedures on deployed systems. >=20 > Then there are also other capabilities similar to EC, and for which = there > is currently no H.248 package. For example: > - ANR automatic noise reduction > - ALC automatic level control > - ALE adaptive listener enhancement > These are used mostly (but not only) for wireless calls. >=20 > So I was thinking we might as well define a new package, to fix the = EC and > also provide the above capabilities. >=20 > Attached is an outline of what this "Enhanced Acoustic Control = Package" > might contain. I did not include the "audio gain", which is defined = in the > TDM package. (Maybe I should have, because this is also directional, = so > apparently it has the same problem as EC.) >=20 > Please let me know what you think. If anyone is interested in = pursuing this > work in the ITU-T group, please let me know. >=20 > Regards, >=20 > Adrian >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Albrecht.Schwarz@alcatel.de = [mailto:Albrecht.Schwarz@alcatel.de] > Sent: Wednesday, March 24, 2004 11:09 AM > To: Soncodi, Adrian > Cc: megaco@ietf.org > Subject: Basic Model & Near End Definition; RE: [Megaco] Question on > echo control direction >=20 >=20 >=20 > Adrian, >=20 > you are addressing a bunch of valid questions. > Before responding on your details, I'd like to synchronize our > understanding. >=20 > Please find enclosed some powerpoint slides > (NGN_EchoCanceller_Principle_r02.PPT), these pictures reflecting my = "world > view" on H.248 MG-embedded ECs:-) > Do you agree with "near end", "half way" definitions? > Is my view inline with yours? >=20 > Perhaps one issue is the use of term "near end" in NGN environments, > whereas G.168 precisely talks about "cancelled end" since the 2002 = version. >=20 > Any G.168 experts view? Please correct me if I'm wrong. >=20 > Best regards, > Albrecht >=20 >=20 >=20 >=20 > (See attached file: NGN_EchoCanceller_Principle_r02.PPT)(See attached = file: > NGN_EchoCanceller_Principle_r02.pdf) >=20 >=20 >=20 >=20 > "Soncodi, Adrian" >=20 > SCHWARZ/DE/ALCATEL@ALCATEL >=20 > ekelec.com> cc: = >=20 > Subject: RE: [Megaco] > Question on echo control direction >=20 > 19.03.2004 18:46 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Albrecht, >=20 > Let's say both switches perform near-end, half way EC as you suggest. = Then > the question is: what do you mean by "near-end half way EC"? Is it: > a) Cancelling echo towards the near-end user, so that he does not = hear > echo? or > b) Cancelling echo generated by the near end, so that the far end = user does > not hear echo? >=20 > In other words, which one happens when the MGC instructs the MG to = turn EC > on? I'm not saying it should be one or another, I'm saying that the = H.248 > standard should specify it, because it matters. >=20 > Kevin says it should be a). I just point out that most of the MGs = today do > b). And I found one MG that does a). So if MGCs follow the ISUP = procedures > to turn EC on at both ends using b), they may have the surprise that = some > EC devices are "flipped over", and thus they become ineffective as = they > work over the long path. Or, instead of being complementary, both EC > devices cancel in the same direction ... you see the problem. >=20 > I don't quite understand the rest of you e-mail. What do you mean by = "Any > EC requirement in addition ... must be signalled correspondingly." = Signaled > where? in H.248 you only have one ec property. >=20 > Are you suggesting that the MGC just signals "ec=3Don", and then the = exact > behavior of the MG (i.e. the direction of the half-way EC device = etc.) > depends on the local MG provisioning? This could be a solution, but = even > so, the H.248 standard should make it clear. And the MGC would still = have > to know what is the case in order to properly implement two-way echo > control procedures. >=20 > To conclude, I'm still trying to find out what the MG's expected = behavior > is. See my long e-mail for pros and cons of a) and b). But I believe = if we > don't clarify it, there will be interop problems. >=20 > Adrian >=20 >=20 >=20 >=20 > -----Original Message----- > From: Albrecht.Schwarz@alcatel.de = [mailto:Albrecht.Schwarz@alcatel.de] > Sent: Friday, March 19, 2004 3:06 AM > To: Soncodi, Adrian > Cc: Kevin Boyle; megaco@ietf.org; megaco-admin@ietf.org > Subject: RE: [Megaco] Question on echo control direction >=20 >=20 >=20 > Adrian, > I couldn't find any contradiction between Kevin's and your = statements. >=20 > My understanding is that the "basic" EC settings for = circuit-to-packet MGs, > where the POTS/ISDN terminal is accessed via a circuit-switched = network, > are: > - near-end EC, and > - half way only ("I don't know the exact G.168 terminology"). >=20 > I think that this common understanding may be derived from legacy = PSTN/ISDN > networks. > Any EC requirement in addition, e.g., like > - far-end EC, > - 2 near-end "H.248 TDM Terminations" (in a TDM-to-TDM call), and/or > - full way > must be signalled correspondingly. >=20 > My impression is that the "basic settings" are sufficient for almost = all > cases. The additional EC capabilities are valid network scenarios = (e.g., > inter-operater interworking, replacement of an international = exchange, > tandem echo cancellation, two satellite links in the TDM-to-TDM call > scenario, missing near-end EC capability in peer MG, etc), but rather > exeptional cases (like in pre-NGN TDM networks). >=20 > Regards, > Albrecht >=20 >=20 >=20 >=20 >=20 >=20 > "Soncodi, Adrian" >=20 > , >=20 > ekelec.com> cc: >=20 > Sent by: Subject: RE: [Megaco] > Question on echo control direction >=20 > megaco-admin@ietf >=20 > .org >=20 >=20 >=20 > 18.03.2004 18:13 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Kevin, >=20 > In your message you say: >=20 >=20 > "I cannot find anything that specifies this, but I don't know why = someone > would use an echo canceller to cancel echo inside the context... Why = not > just fix the DSP to not introduce the echo in the first place? You = don't > generally find echo on the transition from TDM<->packet." >=20 >=20 > Actually, it's not the DSP that introduces echo. It's the 4-wire to = 2-wire > conversion beyond the TDM termination. So for a TDM-packet-TDM call, = we > have the following: >=20 > - Typically, echo is cancelled at both ends of the call. Originating = and > terminating switch each cancel in different directions. >=20 > - For an echo device to cancel in one direction, it has to take the = other > path as reference, wait for the signal to turn around from the user, = and > then compare the two and clean the echo. This involves a delay buffer = (echo > tail), typically up to 64 ms, sometimes up to 128 ms (I don't know of = MGs > that can do more). >=20 > - As a consequence, each switch typically cancels echo over the short = path. > For a TDM-packet-TDM call, the short path is usually the TDM, while = the > long path is the packet network plus the other TDM. If you wait for = the > signal to turn around on the packet side, many times the delay is = bigger > than the buffer size and the EC device becomes ineffective. >=20 > - Consider two MG-s interconnected by a packet network. If these were > traditional TDM switches, each one would clean the stream going = towards the > other (for example, the echo indications in ISUP IAM/ACM are designed = to > achieve this result). This corresponds to the direction into the = packet > network. >=20 > - Another reason to clean the stream into the packet network is that = if the > stream has echo, then the encoding/decoding performed by some = compression > algorithms results in lower quality voice (i.e. some algorithms are > optimized for "clean" voice). >=20 > - A solution for this would be to turn echo control on the = packet-side > terminations. Then if these terminations work like you say they = should, the > desired result would be achieved. Unfortunately, all the MGs I know = cannot > do this. They can only apply a half EC device on the TDM termination > (probably because the package name is TDM) >=20 > - Another aspect: For a conference call with N TDM terminations in a > context, in order cancel the echo generated by one TDM circuit it is > simpler to clean its stream going into the context than the other N-1 = going > out of the context. >=20 > - Until now, I thought I knew the answer to this one. Although this = does > not seem to be clearly specified either in MGCP or in MEGACO, for all = the > MGs I've seen, if you turn on echo on a TDM termination they clear = the > stream going into the packet network. They reference the backwards = stream > to TDM, which is turned around over the short path. So it looks like = most > of the existing MGs do not work like you recommended -- people, = correct me > if I'm wrong here. >=20 > - However, recently I stumbled upon an MG that behaves exactly the > opposite. So now I really have a problem, because there is no way for = an > MGC to know whether the ec property results in the insertion of a = full EC > device or a half device, and which direction. >=20 > - By analogy with signals (although ec is a propery not a signal), = this > should work as you said, i.e. towards the outside of the context. But = if > you would like to standardize this behavior, already a lot of MGs = would be > non-compliant (again, people?). >=20 > - There is also no way for an MGC to audit for this behavior. But if = MGs > were allowed to behave both ways, then you could have different MGs = at the > two ends and then of a TDM-packet-TDM call, and it becomes impossible = to > provide two-way echo cancellation. >=20 > So how do you propose we clarify all this? >=20 > Thanks, >=20 > Adrian >=20 >=20 > -----Original Message----- > From: Kevin Boyle [mailto:kboyle@nortelnetworks.com] > Sent: Wednesday, March 17, 2004 6:12 PM > To: Soncodi, Adrian; megaco@ietf.org > Subject: RE: [Megaco] Question on echo control direction >=20 >=20 >=20 > Ecan generally applies to the network transition point to avoid > reflections off the transition. Therefore, it would make sense = that > the echo canceller on the TDM termination would cancel echo = outwards > toward the TDM facility. >=20 >=20 > I cannot find anything that specifies this, but I don't know = why > someone would use an echo canceller to cancel echo inside the > context... Why not just fix the DSP to not introduce the echo = in the > first place? You don't generally find echo on the transition = from > TDM<->packet. >=20 >=20 > Kevin >=20 >=20 > -----Original Message----- > From: Soncodi, Adrian [mailto:Adrian.Soncodi@tekelec.com] > Sent: Wednesday, March 17, 2004 6:51 PM > To: megaco@ietf.org > Subject: [Megaco] Question on echo control direction >=20 >=20 > Hi, >=20 >=20 > When an MCG turns on echo control for a TDM termination on the = MG, > which one of the following audio streams becomes "clean" of = echo: >=20 >=20 > a) The stream from the termination outwards to the TDM = facility, or > b) The stream from the termination inwards into the context > (presumably going out on another facility associated with = another > termination in the context) (I am assuming that only a = half-echo > canceller is inserted, because most of the MGs can only do = that. The > other half would be on the other termination.) >=20 >=20 > Where is this specified? the TDM package in H.248 annex E does = not > say. >=20 >=20 > Thanks, >=20 >=20 > Adrian >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco >=20 >=20 >=20 >=20 >=20 >=20 >=20 ----- End forwarded message ----- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Apr 1 18:29:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09147 for ; Thu, 1 Apr 2004 18:29:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B99ZI-0008VI-J0; Thu, 01 Apr 2004 16:17:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B933M-00046P-Mo for megaco@optimus.ietf.org; Thu, 01 Apr 2004 09:20:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14279 for ; Thu, 1 Apr 2004 09:18:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B931F-0007hc-00 for megaco@ietf.org; Thu, 01 Apr 2004 09:18:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B930P-0007dU-00 for megaco@ietf.org; Thu, 01 Apr 2004 09:17:18 -0500 Received: from mailrelay1.alcatel.de ([194.113.59.75] helo=mailrelay2.alcatel.de) by ietf-mx with esmtp (Exim 4.12) id 1B92zt-0007XQ-00 for megaco@ietf.org; Thu, 01 Apr 2004 09:16:45 -0500 Received: from ks.sel.alcatel.de (slsv0d.stgl.sel.alcatel.de [149.204.14.10]) by mailrelay2.alcatel.de (8.12.10/8.12.10) with ESMTP id i31EG3jx014074; Thu, 1 Apr 2004 14:16:03 GMT Received: from slssiv ([149.204.245.89] helo=slsdtk.stgl.sel.alcatel.de) by ks.sel.alcatel.de with esmtp (Exim 3.31) id 1B92zD-0005nP-00; Thu, 01 Apr 2004 16:16:03 +0200 Received: from slsufnt ([149.204.245.33] helo=alcatel.de) by slsdtk.stgl.sel.alcatel.de with esmtp (Exim 3.31) id 1B92zC-0005PC-00; Thu, 01 Apr 2004 16:16:02 +0200 Message-ID: <406C2424.7050708@alcatel.de> Date: Thu, 01 Apr 2004 15:16:04 +0100 From: Carsten Waitzmann User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Groves CC: Tom Taylor , Albrecht.Schwarz@alcatel.de, Zhao Bo , megaco@ietf.org Subject: Re: Signaling of UDI rsp Clearmode Bearer Service; Re: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversion References: <403E1760.2010903@nortelnetworks.com> <40427B92.3000707@ericsson.com> In-Reply-To: <40427B92.3000707@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed X-Alcanet-virus-scanned: i31EG3jx014074 at mailrelay2.alcatel.de X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA14280 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello Christian, I took your suggestion as a basis for the following example: MGC -> MG: MEGACO / 1 [1.2.3.4] Transaction =3D 100 { Context =3D $ { Add =3D TDM1 { Media { LocalControl {Mode =3D=20 SendReceive}, Local {a=3Dh248item:TMR =3D= =20 0000 0010}} }}} MG -> MGC MEGACO / 1 [1.2.3.5] Reply =3D 100 { Context =3D 1 { Add =3D TDM1 { Media { Local {a=3Dh248item:TMR =3D= =20 00000010} }}}} Is this usage in line to what you have in mind? H.248.15 specifies: a=3Dh248item:/ =3D .=20 For H.248.1 C.9 I do not know which package applies to property TMR. But=20 H.248.15 states "To enable the carriage of package defined properties in=20 the local and remote descriptors of the text encoded H.248.1 protocol=20 the Package attribute shall be used" thus I am wondering whether a=20 package name isn't mandatory? Thanks a lot! Carsten Alcatel Christian Groves wrote: > Hello Tom and Albrecht, > > What peice of information do you want to signal explicitely? Doesn't=20 > TMR allow you to specify 64Kbit UDI? If so then its supported by=20 > H.248.1 Annex C.9. For H.248 text users this (or any element in Annex=20 > C) can be tranferred via H.248.15. Alternatively Q.1950 sect 5.7.1.2=20 > specifies an equivalent encoding. > > Regards, Christian > > Tom Taylor wrote: > >> I intended a reference to draft-ietf-avt-rtp-clearmode-04.txt in my=20 >> intervention. My old draft has been allowed to expire because it did=20 >> not seem to be of much interest to the community. >> >> You are right: the draft just referred to doesn't apply to TDM, only=20 >> to the packet side. I wasn't thinking. I agree that in the absence=20 >> of the attributes provided in my old draft, TDM bearer=20 >> characteristics are assumed rather than signalled explicitly. >> >> Albrecht.Schwarz@alcatel.de wrote: >> >>> I think that the question is, whether this specific TDM bearer=20 >>> capability >>> should be (1) explicitly signalled, or whether (2) implicit=20 >>> assumption is >>> already sufficient. >>> >>> With regard to (1), Tom, I guess that your refer to >>> >>> * RTP/CLEARMODE >>> RTP payload format for a 64 kbit/s transparent call >>> =20 >>> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-clearmode-04.t= xt >>> >>> But, this coming RFC may not be directly applied, e.g.,=20 >>> packetization time >>> parameter isn't applicable IMHO. Pls correct me if wrong. >>> >>> Or do you refer to your proposals in your expired draft wrt >>> * TDM/CLEARMODE >>> Conventions for the use of the Session Description Protocol (SDP) >>> for Digital Circuit Connections >>> http://www.watersprings.org/pub/id/draft-taylor-mmusic-sdp-tdm-01.t= xt >>> >>> My conclusion is, that an explicit signalling method doesn't exist=20 >>> today >>> ("exception might be Q.1950"). >>> Even though, an explicit TDM Media Descriptor for I.231.1 might be=20 >>> helpful >>> for unambigously specification in certain MG implementations. >>> >>> >>> With regard to (2): >>> Implicit signaling is in my understanding the situation of today. In=20 >>> case >>> of, (a) missing TDM Media Descriptors, or (b) "identical TDM Media >>> Descriptors with transparent channel indications", when a transparent >>> 64-kbit/s bearer connection may be established. >>> Sometimes this is also called "native TDM switching", or "native TDM >>> hairpinning", but technically it is exactly representing an ISDN B=20 >>> channel >>> with I.231.1 bearer service. [=3D> the channel may bypass the DSP, bu= t in >>> case that a DSP is looped-in, then must be the DSP channel operation=20 >>> mode >>> configured for 'Clearmode'] >>> >>> Last comment: >>> Such kind of implicit signalling mechanism is often assumed in telco >>> industry, because this is the legacy signaling mechanism within a TDM >>> switch ("if there aren't any signaled bearer capabilities then=20 >>> transparent >>> channel; any needed bearer capability in addition must be explicitly >>> signalled, like signal processing network equipment functions, e.g.,=20 >>> EC"). >>> >>> TDM hairpinning means, an "H.248-controlled TDM switching function"=20 >>> from >>> H.248 Media Gateway perspective. Hence, this implicit signalling=20 >>> assumption >>> may be still valid, or do you see any needs for explicit signaling >>> codepoints in case of TDM-to-TDM ISDN I.231.1 calls? >>> >>> Regards >>> >>> Albrecht >>> >>> >>> >>> >>> >>> >>> = = =20 >>> Tom=20 >>> Taylor = =20 >>> >> = =20 >>> tworks.com> cc: Albrecht=20 >>> SCHWARZ/DE/ALCATEL@ALCATEL,=20 >>> megaco@ietf.org =20 >>> Subject: Re: TDM=20 >>> Hairpinning; Re: [Megaco] Hairpin case A/u Law=20 >>> conversion =20 >>> 26.02.2004=20 >>> 14:05 = =20 >>> = = =20 >>> = = =20 >>> >>> >>> >>> >>> I think you would do it by specifying the CLEARMODE codec in the=20 >>> Local and >>> Remote >>> descriptors. Unfortunately, CLEARMODE is still under consideration=20 >>> by the >>> IESG >>> and hasn't reached RFC status. >>> >>> Zhao Bo wrote: >>> >>>> Dear Albrecht: >>>> Is there any H.248 package defined to signal the UDI transparency >>> >>> >>> >>> properties in TDM hairping case? >>> >>>> Best regards >>>> >>>> ----- Original Message ----- >>>> From: >>>> To: "Zhao Bo" >>>> Cc: ; >>>> Sent: Wednesday, February 25, 2004 10:24 PM >>>> Subject: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversi= on >>>> >>>> >>>> >>>> Dear Zhao Bo, >>>> >>>> because there isn't any "hairpinning" definition in MEGACOP/H.248 >>> >>> >>> >>> standards >>> >>>> ("please correct if I'm wrong"), I'd like to use the following one f= or >>>> responding your questions: >>>> >>>> >>> >>> *********************************************************************= **************=20 >>> >>> >>> >>>> Definition: >>>> TDM Hairpinning >>>> ? is a scenario whereby a call is being made between two TDM=20 >>>> endpoints on >>> >>> >>> >>> a >>> >>>> single media gateway. The media comes in on one TDM channel and=20 >>>> goes >>>> out on another TDM channel through the use of an internal loop=20 >>>> in the >>>> media gateway. >>>> >>>> Note 1: due to the fact that there are local call types at local >>> >>> >>> >>> exchanges >>> >>>> (CLASS5), and transit exchanges (CLASS4) in legacy TDM networks (PST= N, >>>> NISDN, etc), there is a variety of TDM-to-TDM connection types=20 >>>> behind the >>>> general "TDM hairpinning" capability (dependent on required type of=20 >>>> IWF, >>>> etc.) in corresponding H.248 MG types >>>> >>>> Note 2: H.248/MEGCOP perspective >>>> TDM Hairpinning =3D Single H.248 Context with 2 H.248 TDM Terminatio= ns >>>> >>> >>> *********************************************************************= ***************=20 >>> >>> >>> >>>> Based on this hairpinning understanding, my answers are: >>>> >>>> (1) Speech telephony service: G.711 companding formats are a=20 >>>> property of >>>> the corresponding H.248 TDM termination >>>> >>>> [Note: dependent on MG architecture and implementation, property=20 >>>> might be >>>> signalled or preprovisioned. Of course, G.711 companding law is an >>> >>> >>> >>> inherent >>> >>>> property of your DS0 channel at your PDH/SDH/SONET framer; the way,=20 >>>> how >>>> this DS0 property is associated with the corresponding H.248 TDM >>>> Termination property may only realized MG-internally for very=20 >>>> specific MG >>>> architectures. Generally it is up to the MGC, particularly if some (= or >>> >>> >>> >>> all) >>> >>>> DS0's are ISDN B channels.] >>>> >>>> (2) Voiceband Data services: same as in (1) >>>> >>>> [Note: VBD according new ITU-T V.152 -> "... For purposes of >>>> interoperability, a V.152 compliant implementation shall support at=20 >>>> least >>>> both G.711 A-law and G.711 =C3=AC-law codecs as VBD codecs. "] >>>> >>>> (3) ISDN UDI =3D all ISDN Teleservices with ISDN I.231. bearer servi= ce >>>> requirement >>>> =3D> H.248 TDM Termination property must be signalled by MGC, if not= , MG >>> >>> >>> >>> may >>> >>>> not guarantee UDI capability (i.e., fully transparent 64-kbit/s bear= er >>>> channel) in TDM hairpinning scenarios ... >>>> >>>> >>>> Conclusion: >>>> IF your MG is supporting >>>> PSTN lines (=3D H.248 ALN Termination), >>>> PSTN trunks (=3D H.248 TDM Termination), and >>>> ISDN B channels (=3D H.248 TDM Termination) >>>> >>>> AND IF you've such services and interworking requirements >>>> >>>> THEN you should generally signal the corresponding properties ... >>>> >>>> ... in case of >>>> TDM hairpinning, >>>> ALN hairpinning, or >>>> ALN-to-TDM connection types. >>>> >>>> Regards, >>>> Albrecht >>>> >>>> ALCATEL >>>> >>>> >>>> >>>> >>>> >>> >>> >>>> Zhao Bo >>> >>> >>> >>> >>>> To: megaco@ietf.o= rg >>> >>> >>> >>> >>>> Sent by: cc: >>> >>> >>> >>> >>>> megaco-admin@iet Subject: [Megaco]=20 >>>> Hairpin >>> >>> >>> >>> case A/u Law conversion >>> >>>> f.org >>> >>> >>> >>> >>> >>> >>>> 25.02.2004 08:11 >>> >>> >>> >>> >>> >>> >>>> >>>> >>>> >>>> In this case, the A/u law format of a TDM ciruit can be=20 >>>> provisioned, but >>>> the MG doesn't know the service type of a call, thus >>>> has no way to know if a conversion is needed. For speech service >>> >>> >>> >>> conversion >>> >>>> may be needed; for data service like isdn UDI, conversion is not >>> >>> >>> >>> permitted. >>> >>>> Is there any method to solve this problem? >>>> >>>> Zhao Bo >>>> >>>> ***************************************************************** >>>> This e-mail and its attachments contain confidential information fro= m >>>> HUAWEI, which is intended only for the person or entity whose=20 >>>> address is >>>> listed above. Any use of the information contained herein in any way >>>> (including, but not limited to, total or partial disclosure, >>> >>> >>> >>> reproduction, >>> >>>> or dissemination) by persons other than the intended recipient(s) is >>>> prohibited. If you receive this e-mail in error, please notify the=20 >>>> sender >>>> by phone or email immediately and delete it! >>>> ***************************************************************** >>>> >>>> _______________________________________________ >>>> Megaco mailing list >>>> Megaco@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/megaco >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Megaco mailing list >>>> Megaco@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/megaco >>>> 1=C3=A8=1Ar=E2=80=B0=C5=A1=C5=A0X=C2=A7=E2=80=9AX=C2=AC=C2=B4=C3=87 = i=C3=8A"z=C3=97=C3=A8=C2=AE=08m=C2=B6=E2=80=BA?=C3=BF=0C0=C3=96'=C2=AD~=C5= =A0=C3=A0=C3=BEf=C2=A2=E2=80=93f=C2=A7=C3=BEX=C2=AC=C2=B6)=C3=9F=C2=A3=C3= =B9=C5=BE=EF=A2=9D=C2=A7( >>> >>> >>> >>> >>> >>> >> >> _______________________________________________ >> Megaco mailing list >> Megaco@ietf.org >> https://www1.ietf.org/mailman/listinfo/megaco >> > > > This communication is confidential and intended solely for the=20 > addressee(s). Any unauthorized review, use, disclosure or distribution=20 > is prohibited. If you believe this message has been sent to you in=20 > error, please notify the sender by replying to this transmission and=20 > delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption,=20 > interruption, unauthorized amendment, tampering and viruses, and we=20 > only send and receive e-mails on the basis that we are not liable for=20 > any such corruption, interception, amendment, tampering or viruses or=20 > any consequences thereof. > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mailman-admin@ietf.org Thu Apr 1 18:36:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09574 for ; Thu, 1 Apr 2004 18:36:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B99b3-0000PE-LG for megaco-archive@lists.ietf.org; Thu, 01 Apr 2004 16:19:33 -0500 Date: Thu, 01 Apr 2004 11:22:09 -0500 Message-ID: <20040401162209.11029.6790.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: megaco-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, megaco-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for megaco-archive@lists.ietf.org: List Password // URL ---- -------- megaco@ietf.org rFKd https://www1.ietf.org/mailman/options/megaco/megaco-archive%40lists.ietf.org From megaco-admin@ietf.org Thu Apr 1 19:03:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11427 for ; Thu, 1 Apr 2004 19:03:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9ACO-0007kY-22; Thu, 01 Apr 2004 16:58:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B95Ll-00011G-0n for megaco@optimus.ietf.org; Thu, 01 Apr 2004 11:47:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13592 for ; Thu, 1 Apr 2004 08:59:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B92iv-0005vo-00 for megaco@ietf.org; Thu, 01 Apr 2004 08:59:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B92i8-0005qu-00 for megaco@ietf.org; Thu, 01 Apr 2004 08:58:24 -0500 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1B92hJ-0005gG-00 for Megaco@ietf.org; Thu, 01 Apr 2004 08:57:33 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i31Dv1U09588 for ; Thu, 1 Apr 2004 08:57:01 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Apr 2004 08:57:02 -0500 Message-ID: From: "Kevin Boyle" To: Prateek Raj Singh Cc: Megaco@ietf.org Subject: RE: [Megaco] subscription :Megaco query Date: Thu, 1 Apr 2004 08:56:59 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,LINES_OF_YELLING autolearn=no version=2.60 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , That would depend upon how the MG came back into service. As stated in the spec, the default value of the ServiceStates property is "Inservice". This means that upon a cold start registration of the MG, all terminations are inservice, unless and until the MG reports otherwise via a separate ServiceChange command on the OOS terms. The MGC is always free to audit to determine the ServiceState of terminations in the MG. Kevin _____ From: Prateek Raj Singh [mailto:prateek@cdotd.ernet.in] Sent: Thursday, April 01, 2004 4:13 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH] Cc: Megaco@ietf.org Subject: Re: [Megaco] subscription :Megaco query hi Kevin , What will be the state of the terminations which are present at the time of MGW get fail ? What mechanism provided by the megaco to maintain the same state at the both end MGC and MGW ? regards, prateek Kevin Boyle wrote: Procedures for MGC control of MGs are described in the spec. Essentially, the MGC would have to wait for the MG to return to service. Kevin -----Original Message----- From: Prateek Raj Singh Pawar [mailto:prateek@cdotd.ernet.in ] Sent: Wednesday, March 24, 2004 11:38 PM To: Megaco@ietf.org Cc: Prateek Raj Singh Subject: [Megaco] subscription :Megaco query Hi , This is parteek , working in C-DOT Indian goverment telecom research center . we are currently working on the 3G MSC Server . Pls add me in the mailing list of megaco . I h've some queries related with the megaco . What are the control procedure if MGC control only one MGW configuration and MGW will fail . with regards, PRATEEK RAJ SINGH PAWAR Research Engineer 3G Mobile Solutions C-DOT Ph(O):24677525 ext. 324 Room No 824,9th Floor Cell : +919810652039 Akber Bhavan ,Chankya mail :pprateekraj@yahoo Puri , New Delhi-21 pratraj@rediff ---------------------------------------------------------------------------- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco -- PRATEEK RAJ SINGH PAWAR Research Engineer Mobile Solutions C-DOT Ph(O):24677525 ext. 324 Room No 824,9th Floor Cell : +919810652039 Akber Bhavan ,Chankya mail :pprateekraj@yahoo Puri , New Delhi-21 pratraj@rediff ---------------------------------------------------------------------------- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri Apr 2 00:48:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11122 for ; Fri, 2 Apr 2004 00:48:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9E7z-0005ZS-O3 for megaco-archive@odin.ietf.org; Thu, 01 Apr 2004 21:09:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3229pYv021415 for megaco-archive@odin.ietf.org; Thu, 1 Apr 2004 21:09:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Bdv-0007Zx-R1 for megaco-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 18:30:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09207 for ; Thu, 1 Apr 2004 18:30:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Bds-00026b-00 for megaco-web-archive@ietf.org; Thu, 01 Apr 2004 18:30:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Bd0-00020w-00 for megaco-web-archive@ietf.org; Thu, 01 Apr 2004 18:29:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9BcU-0001ug-00 for megaco-web-archive@ietf.org; Thu, 01 Apr 2004 18:29:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B99ZI-0008VI-J0; Thu, 01 Apr 2004 16:17:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B933M-00046P-Mo for megaco@optimus.ietf.org; Thu, 01 Apr 2004 09:20:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14279 for ; Thu, 1 Apr 2004 09:18:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B931F-0007hc-00 for megaco@ietf.org; Thu, 01 Apr 2004 09:18:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B930P-0007dU-00 for megaco@ietf.org; Thu, 01 Apr 2004 09:17:18 -0500 Received: from mailrelay1.alcatel.de ([194.113.59.75] helo=mailrelay2.alcatel.de) by ietf-mx with esmtp (Exim 4.12) id 1B92zt-0007XQ-00 for megaco@ietf.org; Thu, 01 Apr 2004 09:16:45 -0500 Received: from ks.sel.alcatel.de (slsv0d.stgl.sel.alcatel.de [149.204.14.10]) by mailrelay2.alcatel.de (8.12.10/8.12.10) with ESMTP id i31EG3jx014074; Thu, 1 Apr 2004 14:16:03 GMT Received: from slssiv ([149.204.245.89] helo=slsdtk.stgl.sel.alcatel.de) by ks.sel.alcatel.de with esmtp (Exim 3.31) id 1B92zD-0005nP-00; Thu, 01 Apr 2004 16:16:03 +0200 Received: from slsufnt ([149.204.245.33] helo=alcatel.de) by slsdtk.stgl.sel.alcatel.de with esmtp (Exim 3.31) id 1B92zC-0005PC-00; Thu, 01 Apr 2004 16:16:02 +0200 Message-ID: <406C2424.7050708@alcatel.de> Date: Thu, 01 Apr 2004 15:16:04 +0100 From: Carsten Waitzmann User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Groves CC: Tom Taylor , Albrecht.Schwarz@alcatel.de, Zhao Bo , megaco@ietf.org Subject: Re: Signaling of UDI rsp Clearmode Bearer Service; Re: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversion References: <403E1760.2010903@nortelnetworks.com> <40427B92.3000707@ericsson.com> In-Reply-To: <40427B92.3000707@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed X-Alcanet-virus-scanned: i31EG3jx014074 at mailrelay2.alcatel.de Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA14280 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello Christian, I took your suggestion as a basis for the following example: MGC -> MG: MEGACO / 1 [1.2.3.4] Transaction =3D 100 { Context =3D $ { Add =3D TDM1 { Media { LocalControl {Mode =3D=20 SendReceive}, Local {a=3Dh248item:TMR =3D= =20 0000 0010}} }}} MG -> MGC MEGACO / 1 [1.2.3.5] Reply =3D 100 { Context =3D 1 { Add =3D TDM1 { Media { Local {a=3Dh248item:TMR =3D= =20 00000010} }}}} Is this usage in line to what you have in mind? H.248.15 specifies: a=3Dh248item:/ =3D .=20 For H.248.1 C.9 I do not know which package applies to property TMR. But=20 H.248.15 states "To enable the carriage of package defined properties in=20 the local and remote descriptors of the text encoded H.248.1 protocol=20 the Package attribute shall be used" thus I am wondering whether a=20 package name isn't mandatory? Thanks a lot! Carsten Alcatel Christian Groves wrote: > Hello Tom and Albrecht, > > What peice of information do you want to signal explicitely? Doesn't=20 > TMR allow you to specify 64Kbit UDI? If so then its supported by=20 > H.248.1 Annex C.9. For H.248 text users this (or any element in Annex=20 > C) can be tranferred via H.248.15. Alternatively Q.1950 sect 5.7.1.2=20 > specifies an equivalent encoding. > > Regards, Christian > > Tom Taylor wrote: > >> I intended a reference to draft-ietf-avt-rtp-clearmode-04.txt in my=20 >> intervention. My old draft has been allowed to expire because it did=20 >> not seem to be of much interest to the community. >> >> You are right: the draft just referred to doesn't apply to TDM, only=20 >> to the packet side. I wasn't thinking. I agree that in the absence=20 >> of the attributes provided in my old draft, TDM bearer=20 >> characteristics are assumed rather than signalled explicitly. >> >> Albrecht.Schwarz@alcatel.de wrote: >> >>> I think that the question is, whether this specific TDM bearer=20 >>> capability >>> should be (1) explicitly signalled, or whether (2) implicit=20 >>> assumption is >>> already sufficient. >>> >>> With regard to (1), Tom, I guess that your refer to >>> >>> * RTP/CLEARMODE >>> RTP payload format for a 64 kbit/s transparent call >>> =20 >>> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-clearmode-04.t= xt >>> >>> But, this coming RFC may not be directly applied, e.g.,=20 >>> packetization time >>> parameter isn't applicable IMHO. Pls correct me if wrong. >>> >>> Or do you refer to your proposals in your expired draft wrt >>> * TDM/CLEARMODE >>> Conventions for the use of the Session Description Protocol (SDP) >>> for Digital Circuit Connections >>> http://www.watersprings.org/pub/id/draft-taylor-mmusic-sdp-tdm-01.t= xt >>> >>> My conclusion is, that an explicit signalling method doesn't exist=20 >>> today >>> ("exception might be Q.1950"). >>> Even though, an explicit TDM Media Descriptor for I.231.1 might be=20 >>> helpful >>> for unambigously specification in certain MG implementations. >>> >>> >>> With regard to (2): >>> Implicit signaling is in my understanding the situation of today. In=20 >>> case >>> of, (a) missing TDM Media Descriptors, or (b) "identical TDM Media >>> Descriptors with transparent channel indications", when a transparent >>> 64-kbit/s bearer connection may be established. >>> Sometimes this is also called "native TDM switching", or "native TDM >>> hairpinning", but technically it is exactly representing an ISDN B=20 >>> channel >>> with I.231.1 bearer service. [=3D> the channel may bypass the DSP, bu= t in >>> case that a DSP is looped-in, then must be the DSP channel operation=20 >>> mode >>> configured for 'Clearmode'] >>> >>> Last comment: >>> Such kind of implicit signalling mechanism is often assumed in telco >>> industry, because this is the legacy signaling mechanism within a TDM >>> switch ("if there aren't any signaled bearer capabilities then=20 >>> transparent >>> channel; any needed bearer capability in addition must be explicitly >>> signalled, like signal processing network equipment functions, e.g.,=20 >>> EC"). >>> >>> TDM hairpinning means, an "H.248-controlled TDM switching function"=20 >>> from >>> H.248 Media Gateway perspective. Hence, this implicit signalling=20 >>> assumption >>> may be still valid, or do you see any needs for explicit signaling >>> codepoints in case of TDM-to-TDM ISDN I.231.1 calls? >>> >>> Regards >>> >>> Albrecht >>> >>> >>> >>> >>> >>> >>> = = =20 >>> Tom=20 >>> Taylor = =20 >>> >> = =20 >>> tworks.com> cc: Albrecht=20 >>> SCHWARZ/DE/ALCATEL@ALCATEL,=20 >>> megaco@ietf.org =20 >>> Subject: Re: TDM=20 >>> Hairpinning; Re: [Megaco] Hairpin case A/u Law=20 >>> conversion =20 >>> 26.02.2004=20 >>> 14:05 = =20 >>> = = =20 >>> = = =20 >>> >>> >>> >>> >>> I think you would do it by specifying the CLEARMODE codec in the=20 >>> Local and >>> Remote >>> descriptors. Unfortunately, CLEARMODE is still under consideration=20 >>> by the >>> IESG >>> and hasn't reached RFC status. >>> >>> Zhao Bo wrote: >>> >>>> Dear Albrecht: >>>> Is there any H.248 package defined to signal the UDI transparency >>> >>> >>> >>> properties in TDM hairping case? >>> >>>> Best regards >>>> >>>> ----- Original Message ----- >>>> From: >>>> To: "Zhao Bo" >>>> Cc: ; >>>> Sent: Wednesday, February 25, 2004 10:24 PM >>>> Subject: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversi= on >>>> >>>> >>>> >>>> Dear Zhao Bo, >>>> >>>> because there isn't any "hairpinning" definition in MEGACOP/H.248 >>> >>> >>> >>> standards >>> >>>> ("please correct if I'm wrong"), I'd like to use the following one f= or >>>> responding your questions: >>>> >>>> >>> >>> *********************************************************************= **************=20 >>> >>> >>> >>>> Definition: >>>> TDM Hairpinning >>>> ? is a scenario whereby a call is being made between two TDM=20 >>>> endpoints on >>> >>> >>> >>> a >>> >>>> single media gateway. The media comes in on one TDM channel and=20 >>>> goes >>>> out on another TDM channel through the use of an internal loop=20 >>>> in the >>>> media gateway. >>>> >>>> Note 1: due to the fact that there are local call types at local >>> >>> >>> >>> exchanges >>> >>>> (CLASS5), and transit exchanges (CLASS4) in legacy TDM networks (PST= N, >>>> NISDN, etc), there is a variety of TDM-to-TDM connection types=20 >>>> behind the >>>> general "TDM hairpinning" capability (dependent on required type of=20 >>>> IWF, >>>> etc.) in corresponding H.248 MG types >>>> >>>> Note 2: H.248/MEGCOP perspective >>>> TDM Hairpinning =3D Single H.248 Context with 2 H.248 TDM Terminatio= ns >>>> >>> >>> *********************************************************************= ***************=20 >>> >>> >>> >>>> Based on this hairpinning understanding, my answers are: >>>> >>>> (1) Speech telephony service: G.711 companding formats are a=20 >>>> property of >>>> the corresponding H.248 TDM termination >>>> >>>> [Note: dependent on MG architecture and implementation, property=20 >>>> might be >>>> signalled or preprovisioned. Of course, G.711 companding law is an >>> >>> >>> >>> inherent >>> >>>> property of your DS0 channel at your PDH/SDH/SONET framer; the way,=20 >>>> how >>>> this DS0 property is associated with the corresponding H.248 TDM >>>> Termination property may only realized MG-internally for very=20 >>>> specific MG >>>> architectures. Generally it is up to the MGC, particularly if some (= or >>> >>> >>> >>> all) >>> >>>> DS0's are ISDN B channels.] >>>> >>>> (2) Voiceband Data services: same as in (1) >>>> >>>> [Note: VBD according new ITU-T V.152 -> "... For purposes of >>>> interoperability, a V.152 compliant implementation shall support at=20 >>>> least >>>> both G.711 A-law and G.711 =C3=AC-law codecs as VBD codecs. "] >>>> >>>> (3) ISDN UDI =3D all ISDN Teleservices with ISDN I.231. bearer servi= ce >>>> requirement >>>> =3D> H.248 TDM Termination property must be signalled by MGC, if not= , MG >>> >>> >>> >>> may >>> >>>> not guarantee UDI capability (i.e., fully transparent 64-kbit/s bear= er >>>> channel) in TDM hairpinning scenarios ... >>>> >>>> >>>> Conclusion: >>>> IF your MG is supporting >>>> PSTN lines (=3D H.248 ALN Termination), >>>> PSTN trunks (=3D H.248 TDM Termination), and >>>> ISDN B channels (=3D H.248 TDM Termination) >>>> >>>> AND IF you've such services and interworking requirements >>>> >>>> THEN you should generally signal the corresponding properties ... >>>> >>>> ... in case of >>>> TDM hairpinning, >>>> ALN hairpinning, or >>>> ALN-to-TDM connection types. >>>> >>>> Regards, >>>> Albrecht >>>> >>>> ALCATEL >>>> >>>> >>>> >>>> >>>> >>> >>> >>>> Zhao Bo >>> >>> >>> >>> >>>> To: megaco@ietf.o= rg >>> >>> >>> >>> >>>> Sent by: cc: >>> >>> >>> >>> >>>> megaco-admin@iet Subject: [Megaco]=20 >>>> Hairpin >>> >>> >>> >>> case A/u Law conversion >>> >>>> f.org >>> >>> >>> >>> >>> >>> >>>> 25.02.2004 08:11 >>> >>> >>> >>> >>> >>> >>>> >>>> >>>> >>>> In this case, the A/u law format of a TDM ciruit can be=20 >>>> provisioned, but >>>> the MG doesn't know the service type of a call, thus >>>> has no way to know if a conversion is needed. For speech service >>> >>> >>> >>> conversion >>> >>>> may be needed; for data service like isdn UDI, conversion is not >>> >>> >>> >>> permitted. >>> >>>> Is there any method to solve this problem? >>>> >>>> Zhao Bo >>>> >>>> ***************************************************************** >>>> This e-mail and its attachments contain confidential information fro= m >>>> HUAWEI, which is intended only for the person or entity whose=20 >>>> address is >>>> listed above. Any use of the information contained herein in any way >>>> (including, but not limited to, total or partial disclosure, >>> >>> >>> >>> reproduction, >>> >>>> or dissemination) by persons other than the intended recipient(s) is >>>> prohibited. If you receive this e-mail in error, please notify the=20 >>>> sender >>>> by phone or email immediately and delete it! >>>> ***************************************************************** >>>> >>>> _______________________________________________ >>>> Megaco mailing list >>>> Megaco@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/megaco >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Megaco mailing list >>>> Megaco@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/megaco >>>> 1=C3=A8=1Ar=E2=80=B0=C5=A1=C5=A0X=C2=A7=E2=80=9AX=C2=AC=C2=B4=C3=87 = i=C3=8A"z=C3=97=C3=A8=C2=AE=08m=C2=B6=E2=80=BA?=C3=BF=0C0=C3=96'=C2=AD~=C5= =A0=C3=A0=C3=BEf=C2=A2=E2=80=93f=C2=A7=C3=BEX=C2=AC=C2=B6)=C3=9F=C2=A3=C3= =B9=C5=BE=EF=A2=9D=C2=A7( >>> >>> >>> >>> >>> >>> >> >> _______________________________________________ >> Megaco mailing list >> Megaco@ietf.org >> https://www1.ietf.org/mailman/listinfo/megaco >> > > > This communication is confidential and intended solely for the=20 > addressee(s). Any unauthorized review, use, disclosure or distribution=20 > is prohibited. If you believe this message has been sent to you in=20 > error, please notify the sender by replying to this transmission and=20 > delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption,=20 > interruption, unauthorized amendment, tampering and viruses, and we=20 > only send and receive e-mails on the basis that we are not liable for=20 > any such corruption, interception, amendment, tampering or viruses or=20 > any consequences thereof. > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri Apr 2 03:14:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28031 for ; Fri, 2 Apr 2004 03:14:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9EAP-0006f5-Qu for megaco-archive@odin.ietf.org; Thu, 01 Apr 2004 21:12:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i322CLRa025605 for megaco-archive@odin.ietf.org; Thu, 1 Apr 2004 21:12:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9CAu-0004n3-22 for megaco-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 19:04:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11550 for ; Thu, 1 Apr 2004 19:04:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9CAq-0006F9-00 for megaco-web-archive@ietf.org; Thu, 01 Apr 2004 19:04:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9C9v-00067W-00 for megaco-web-archive@ietf.org; Thu, 01 Apr 2004 19:03:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9C9G-00060Z-00 for megaco-web-archive@ietf.org; Thu, 01 Apr 2004 19:03:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9ACO-0007kY-22; Thu, 01 Apr 2004 16:58:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B95Ll-00011G-0n for megaco@optimus.ietf.org; Thu, 01 Apr 2004 11:47:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13592 for ; Thu, 1 Apr 2004 08:59:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B92iv-0005vo-00 for megaco@ietf.org; Thu, 01 Apr 2004 08:59:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B92i8-0005qu-00 for megaco@ietf.org; Thu, 01 Apr 2004 08:58:24 -0500 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1B92hJ-0005gG-00 for Megaco@ietf.org; Thu, 01 Apr 2004 08:57:33 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i31Dv1U09588 for ; Thu, 1 Apr 2004 08:57:01 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Apr 2004 08:57:02 -0500 Message-ID: From: "Kevin Boyle" To: Prateek Raj Singh Cc: Megaco@ietf.org Subject: RE: [Megaco] subscription :Megaco query Date: Thu, 1 Apr 2004 08:56:59 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,LINES_OF_YELLING autolearn=no version=2.60 That would depend upon how the MG came back into service. As stated in the spec, the default value of the ServiceStates property is "Inservice". This means that upon a cold start registration of the MG, all terminations are inservice, unless and until the MG reports otherwise via a separate ServiceChange command on the OOS terms. The MGC is always free to audit to determine the ServiceState of terminations in the MG. Kevin _____ From: Prateek Raj Singh [mailto:prateek@cdotd.ernet.in] Sent: Thursday, April 01, 2004 4:13 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH] Cc: Megaco@ietf.org Subject: Re: [Megaco] subscription :Megaco query hi Kevin , What will be the state of the terminations which are present at the time of MGW get fail ? What mechanism provided by the megaco to maintain the same state at the both end MGC and MGW ? regards, prateek Kevin Boyle wrote: Procedures for MGC control of MGs are described in the spec. Essentially, the MGC would have to wait for the MG to return to service. Kevin -----Original Message----- From: Prateek Raj Singh Pawar [mailto:prateek@cdotd.ernet.in ] Sent: Wednesday, March 24, 2004 11:38 PM To: Megaco@ietf.org Cc: Prateek Raj Singh Subject: [Megaco] subscription :Megaco query Hi , This is parteek , working in C-DOT Indian goverment telecom research center . we are currently working on the 3G MSC Server . Pls add me in the mailing list of megaco . I h've some queries related with the megaco . What are the control procedure if MGC control only one MGW configuration and MGW will fail . with regards, PRATEEK RAJ SINGH PAWAR Research Engineer 3G Mobile Solutions C-DOT Ph(O):24677525 ext. 324 Room No 824,9th Floor Cell : +919810652039 Akber Bhavan ,Chankya mail :pprateekraj@yahoo Puri , New Delhi-21 pratraj@rediff ---------------------------------------------------------------------------- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco -- PRATEEK RAJ SINGH PAWAR Research Engineer Mobile Solutions C-DOT Ph(O):24677525 ext. 324 Room No 824,9th Floor Cell : +919810652039 Akber Bhavan ,Chankya mail :pprateekraj@yahoo Puri , New Delhi-21 pratraj@rediff ---------------------------------------------------------------------------- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Apr 2 12:06:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18794 for ; Fri, 2 Apr 2004 12:06:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Q7T-0004og-3U; Fri, 02 Apr 2004 09:58:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Ln6-00005O-Mo for megaco@optimus.ietf.org; Fri, 02 Apr 2004 05:20:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02503 for ; Fri, 2 Apr 2004 05:20:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Ln3-0007Cn-00 for megaco@ietf.org; Fri, 02 Apr 2004 05:20:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Lm6-00076f-00 for megaco@ietf.org; Fri, 02 Apr 2004 05:19:46 -0500 Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1B9Llj-00070q-00 for megaco@ietf.org; Fri, 02 Apr 2004 05:19:24 -0500 Received: from z14593 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HVJ00C7JFOKOO@mta0.huawei.com> for megaco@ietf.org; Fri, 02 Apr 2004 17:57:57 +0800 (CST) Date: Fri, 02 Apr 2004 17:59:36 +0800 From: Zhao Bo To: Kevin Boyle Cc: megaco@ietf.org Message-id: <000701c41899$359f1ee0$e4496e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 X-Mailer: Microsoft Outlook Express 5.50.4922.1500 Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Subject: [Megaco] question about H.248.26 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hi Kevin: As per H.248.26, for "pri" parameter of "em" signal: There is no default value for this parameter, and the MGC should always provide a positive non-zero value. Why? Why MG cannot use a provsioned value. Best regards Zhao Bo ***************************************************************** This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ***************************************************************** _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Apr 2 16:11:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29605 for ; Fri, 2 Apr 2004 16:11:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9SKo-0007nm-E7; Fri, 02 Apr 2004 12:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9QYb-0005nJ-K2 for megaco@optimus.ietf.org; Fri, 02 Apr 2004 10:26:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13750 for ; Fri, 2 Apr 2004 10:26:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9QYY-0006ZU-00 for megaco@ietf.org; Fri, 02 Apr 2004 10:26:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9QXe-0006RH-00 for megaco@ietf.org; Fri, 02 Apr 2004 10:25:10 -0500 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1B9QX7-0006IL-00 for megaco@ietf.org; Fri, 02 Apr 2004 10:24:37 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i32FO5s04807 for ; Fri, 2 Apr 2004 10:24:06 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Apr 2004 10:24:05 -0500 Message-ID: From: "Kevin Boyle" To: Zhao Bo Cc: megaco@ietf.org Date: Fri, 2 Apr 2004 10:24:04 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Megaco] RE: question about H.248.26 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , If the MG was in charge of running metering, then there would be no point to having this package. Because this package is intended to allow MGC control of metering pulse application, the MGC should indeed perform that control. Kevin -----Original Message----- From: Zhao Bo [mailto:zbo@huawei.com] Sent: Friday, April 02, 2004 5:00 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH] Cc: megaco@ietf.org Subject: question about H.248.26 Hi Kevin: As per H.248.26, for "pri" parameter of "em" signal: There is no default value for this parameter, and the MGC should always provide a positive non-zero value. Why? Why MG cannot use a provsioned value. Best regards Zhao Bo ***************************************************************** This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ***************************************************************** _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri Apr 2 16:48:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03851 for ; Fri, 2 Apr 2004 16:48:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9VLU-000680-Eq for megaco-archive@odin.ietf.org; Fri, 02 Apr 2004 15:32:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32KWukJ023556 for megaco-archive@odin.ietf.org; Fri, 2 Apr 2004 15:32:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9S8Q-0006qu-8l for megaco-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 12:07:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18852 for ; Fri, 2 Apr 2004 12:07:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9S8O-0006EV-00 for megaco-web-archive@ietf.org; Fri, 02 Apr 2004 12:07:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9S7Y-00065R-00 for megaco-web-archive@ietf.org; Fri, 02 Apr 2004 12:06:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9S6t-0005wv-00 for megaco-web-archive@ietf.org; Fri, 02 Apr 2004 12:05:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Q7T-0004og-3U; Fri, 02 Apr 2004 09:58:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Ln6-00005O-Mo for megaco@optimus.ietf.org; Fri, 02 Apr 2004 05:20:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02503 for ; Fri, 2 Apr 2004 05:20:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9Ln3-0007Cn-00 for megaco@ietf.org; Fri, 02 Apr 2004 05:20:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9Lm6-00076f-00 for megaco@ietf.org; Fri, 02 Apr 2004 05:19:46 -0500 Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1B9Llj-00070q-00 for megaco@ietf.org; Fri, 02 Apr 2004 05:19:24 -0500 Received: from z14593 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HVJ00C7JFOKOO@mta0.huawei.com> for megaco@ietf.org; Fri, 02 Apr 2004 17:57:57 +0800 (CST) Date: Fri, 02 Apr 2004 17:59:36 +0800 From: Zhao Bo To: Kevin Boyle Cc: megaco@ietf.org Message-id: <000701c41899$359f1ee0$e4496e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 X-Mailer: Microsoft Outlook Express 5.50.4922.1500 Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [Megaco] question about H.248.26 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi Kevin: As per H.248.26, for "pri" parameter of "em" signal: There is no default value for this parameter, and the MGC should always provide a positive non-zero value. Why? Why MG cannot use a provsioned value. Best regards Zhao Bo ***************************************************************** This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ***************************************************************** _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri Apr 2 17:10:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06828 for ; Fri, 2 Apr 2004 17:10:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9Wr2-0005tx-SN for megaco-archive@odin.ietf.org; Fri, 02 Apr 2004 17:09:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32M9avs022686 for megaco-archive@odin.ietf.org; Fri, 2 Apr 2004 17:09:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9VzX-0005Go-Jo for megaco-web-archive@optimus.ietf.org; Fri, 02 Apr 2004 16:14:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29923 for ; Fri, 2 Apr 2004 16:14:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9VzV-0001tY-00 for megaco-web-archive@ietf.org; Fri, 02 Apr 2004 16:14:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9VxZ-0001KZ-00 for megaco-web-archive@ietf.org; Fri, 02 Apr 2004 16:12:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9VwJ-0000w4-00 for megaco-web-archive@ietf.org; Fri, 02 Apr 2004 16:10:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9SKo-0007nm-E7; Fri, 02 Apr 2004 12:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9QYb-0005nJ-K2 for megaco@optimus.ietf.org; Fri, 02 Apr 2004 10:26:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13750 for ; Fri, 2 Apr 2004 10:26:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9QYY-0006ZU-00 for megaco@ietf.org; Fri, 02 Apr 2004 10:26:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9QXe-0006RH-00 for megaco@ietf.org; Fri, 02 Apr 2004 10:25:10 -0500 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1B9QX7-0006IL-00 for megaco@ietf.org; Fri, 02 Apr 2004 10:24:37 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i32FO5s04807 for ; Fri, 2 Apr 2004 10:24:06 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Apr 2004 10:24:05 -0500 Message-ID: From: "Kevin Boyle" To: Zhao Bo Cc: megaco@ietf.org Date: Fri, 2 Apr 2004 10:24:04 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [Megaco] RE: question about H.248.26 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 If the MG was in charge of running metering, then there would be no point to having this package. Because this package is intended to allow MGC control of metering pulse application, the MGC should indeed perform that control. Kevin -----Original Message----- From: Zhao Bo [mailto:zbo@huawei.com] Sent: Friday, April 02, 2004 5:00 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH] Cc: megaco@ietf.org Subject: question about H.248.26 Hi Kevin: As per H.248.26, for "pri" parameter of "em" signal: There is no default value for this parameter, and the MGC should always provide a positive non-zero value. Why? Why MG cannot use a provsioned value. Best regards Zhao Bo ***************************************************************** This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ***************************************************************** _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Sat Apr 3 11:58:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26782 for ; Sat, 3 Apr 2004 11:58:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9oT3-0008BE-Qv; Sat, 03 Apr 2004 11:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9oSy-0007zC-1b for megaco@optimus.ietf.org; Sat, 03 Apr 2004 11:57:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26779 for ; Sat, 3 Apr 2004 11:57:52 -0500 (EST) From: mankin@isi.edu Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9oSw-0006oI-00 for megaco@ietf.org; Sat, 03 Apr 2004 11:57:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9oRz-0006hf-00 for megaco@ietf.org; Sat, 03 Apr 2004 11:56:56 -0500 Received: from p3e9bb408.dip.t-dialin.net ([62.155.180.8] helo=somdjeu) by ietf-mx with smtp (Exim 4.12) id 1B9oRb-0006bb-00 for megaco@ietf.org; Sat, 03 Apr 2004 11:56:32 -0500 Date: Sat, 03 Apr 2004 18:51:24 +0100 To: megaco@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------hlapafllyxvrjasghxaj" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Subject: [Megaco] :-) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , ----------hlapafllyxvrjasghxaj Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) Found virus WORM_BAGLE.GEN-1 in file MoreInfo.zip The uncleanable file is deleted. --------------------------------------------------------- ----------hlapafllyxvrjasghxaj Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I don't bite, weah! password: 14871 ----------hlapafllyxvrjasghxaj Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) MoreInfo.zip is removed from here because it contains a virus. --------------------------------------------------------- ----------hlapafllyxvrjasghxaj-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Apr 5 22:47:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08559 for ; Mon, 5 Apr 2004 22:47:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAgcB-0000XU-O1; Mon, 05 Apr 2004 22:47:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAgby-0000Vp-V0 for megaco@optimus.ietf.org; Mon, 05 Apr 2004 22:46:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08470 for ; Mon, 5 Apr 2004 22:46:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAgbv-0004V5-00 for megaco@ietf.org; Mon, 05 Apr 2004 22:46:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAgB3-0001UJ-00 for megaco@ietf.org; Mon, 05 Apr 2004 22:19:04 -0400 Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1BAfoE-0006DU-00 for megaco@ietf.org; Mon, 05 Apr 2004 21:55:27 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i361tNWR029742 for ; Tue, 6 Apr 2004 03:55:26 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 6 Apr 2004 03:55:23 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id H8FWAYZ5; Tue, 6 Apr 2004 03:55:22 +0200 Received: from ericsson.com (sealwa04-208.sw.ericsson.se [130.100.249.208]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 2A5WM4ZF; Tue, 6 Apr 2004 11:54:50 +1000 Message-ID: <40720E2A.6070903@ericsson.com> Date: Tue, 06 Apr 2004 11:55:54 +1000 X-Sybari-Trust: 600ae803 2c4885b5 06e2c4e1 00000138 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Carsten Waitzmann CC: Tom Taylor , Albrecht.Schwarz@alcatel.de, Zhao Bo , megaco@ietf.org Subject: Re: Signaling of UDI rsp Clearmode Bearer Service; Re: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversion References: <403E1760.2010903@nortelnetworks.com> <40427B92.3000707@ericsson.com> <406C2424.7050708@alcatel.de> In-Reply-To: <406C2424.7050708@alcatel.de> Content-Type: text/plain; charset=UTF-8; format=flowed X-OriginalArrivalTime: 06 Apr 2004 01:55:23.0126 (UTC) FILETIME=[391B3160:01C41B7A] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by albatross.ericsson.se id i361tNWR029742 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello Carsten, Yes this is what I had in mind. The package ID for Annex C is 0. ie. H.248.1 Annex A PkgdName ::=3D OCTET STRING(SIZE(4)) -- represents Package Name (2 octets) plus Property, Event, -- Signal Names or Statistics ID. (2 octets) -- To wildcard a package use 0xFFFF for first two octets, choose -- is not allowed. To reference native property tag specified in -- Annex C, use 0x0000 as first two octets. Regards, Christian Carsten Waitzmann wrote: > Hello Christian, >=20 > I took your suggestion as a basis for the following example: >=20 > MGC -> MG: > MEGACO / 1 [1.2.3.4] > Transaction =3D 100 { > Context =3D $ { Add =3D TDM1 { > Media { > LocalControl {Mode =3D=20 > SendReceive}, > Local {a=3Dh248item:TMR =3D= =20 > 0000 0010}} > }}} >=20 > MG -> MGC > MEGACO / 1 [1.2.3.5] > Reply =3D 100 { > Context =3D 1 { > Add =3D TDM1 { > Media { > Local {a=3Dh248item:TMR = =3D=20 > 00000010} > }}}} >=20 > Is this usage in line to what you have in mind? > H.248.15 specifies: a=3Dh248item:/ =3D .=20 > For H.248.1 C.9 I do not know which package applies to property TMR. Bu= t=20 > H.248.15 states "To enable the carriage of package defined properties i= n=20 > the local and remote descriptors of the text encoded H.248.1 protocol=20 > the Package attribute shall be used" thus I am wondering whether a=20 > package name isn't mandatory? >=20 > Thanks a lot! >=20 > Carsten >=20 > Alcatel >=20 > Christian Groves wrote: >=20 >> Hello Tom and Albrecht, >> >> What peice of information do you want to signal explicitely? Doesn't=20 >> TMR allow you to specify 64Kbit UDI? If so then its supported by=20 >> H.248.1 Annex C.9. For H.248 text users this (or any element in Annex=20 >> C) can be tranferred via H.248.15. Alternatively Q.1950 sect 5.7.1.2=20 >> specifies an equivalent encoding. >> >> Regards, Christian >> >> Tom Taylor wrote: >> >>> I intended a reference to draft-ietf-avt-rtp-clearmode-04.txt in my=20 >>> intervention. My old draft has been allowed to expire because it did= =20 >>> not seem to be of much interest to the community. >>> >>> You are right: the draft just referred to doesn't apply to TDM, only=20 >>> to the packet side. I wasn't thinking. I agree that in the absence=20 >>> of the attributes provided in my old draft, TDM bearer=20 >>> characteristics are assumed rather than signalled explicitly. >>> >>> Albrecht.Schwarz@alcatel.de wrote: >>> >>>> I think that the question is, whether this specific TDM bearer=20 >>>> capability >>>> should be (1) explicitly signalled, or whether (2) implicit=20 >>>> assumption is >>>> already sufficient. >>>> >>>> With regard to (1), Tom, I guess that your refer to >>>> >>>> * RTP/CLEARMODE >>>> RTP payload format for a 64 kbit/s transparent call >>>> =20 >>>> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-clearmode-04.= txt >>>> >>>> But, this coming RFC may not be directly applied, e.g.,=20 >>>> packetization time >>>> parameter isn't applicable IMHO. Pls correct me if wrong. >>>> >>>> Or do you refer to your proposals in your expired draft wrt >>>> * TDM/CLEARMODE >>>> Conventions for the use of the Session Description Protocol (SDP) >>>> for Digital Circuit Connections >>>> http://www.watersprings.org/pub/id/draft-taylor-mmusic-sdp-tdm-01.= txt >>>> >>>> My conclusion is, that an explicit signalling method doesn't exist=20 >>>> today >>>> ("exception might be Q.1950"). >>>> Even though, an explicit TDM Media Descriptor for I.231.1 might be=20 >>>> helpful >>>> for unambigously specification in certain MG implementations. >>>> >>>> >>>> With regard to (2): >>>> Implicit signaling is in my understanding the situation of today. In= =20 >>>> case >>>> of, (a) missing TDM Media Descriptors, or (b) "identical TDM Media >>>> Descriptors with transparent channel indications", when a transparen= t >>>> 64-kbit/s bearer connection may be established. >>>> Sometimes this is also called "native TDM switching", or "native TDM >>>> hairpinning", but technically it is exactly representing an ISDN B=20 >>>> channel >>>> with I.231.1 bearer service. [=3D> the channel may bypass the DSP, b= ut in >>>> case that a DSP is looped-in, then must be the DSP channel operation= =20 >>>> mode >>>> configured for 'Clearmode'] >>>> >>>> Last comment: >>>> Such kind of implicit signalling mechanism is often assumed in telco >>>> industry, because this is the legacy signaling mechanism within a TD= M >>>> switch ("if there aren't any signaled bearer capabilities then=20 >>>> transparent >>>> channel; any needed bearer capability in addition must be explicitly >>>> signalled, like signal processing network equipment functions, e.g.,= =20 >>>> EC"). >>>> >>>> TDM hairpinning means, an "H.248-controlled TDM switching function"=20 >>>> from >>>> H.248 Media Gateway perspective. Hence, this implicit signalling=20 >>>> assumption >>>> may be still valid, or do you see any needs for explicit signaling >>>> codepoints in case of TDM-to-TDM ISDN I.231.1 calls? >>>> >>>> Regards >>>> >>>> Albrecht >>>> >>>> >>>> >>>> >>>> >>>> >>>> = = =20 >>>> Tom=20 >>>> Taylor = =20 >>>> >>> = =20 >>>> tworks.com> cc: Albrecht=20 >>>> SCHWARZ/DE/ALCATEL@ALCATEL,=20 >>>> megaco@ietf.org =20 >>>> Subject: Re: TDM=20 >>>> Hairpinning; Re: [Megaco] Hairpin case A/u Law=20 >>>> conversion =20 >>>> 26.02.2004=20 >>>> 14:05 = =20 >>>> = = =20 >>>> = = =20 >>>> >>>> >>>> >>>> >>>> I think you would do it by specifying the CLEARMODE codec in the=20 >>>> Local and >>>> Remote >>>> descriptors. Unfortunately, CLEARMODE is still under consideration=20 >>>> by the >>>> IESG >>>> and hasn't reached RFC status. >>>> >>>> Zhao Bo wrote: >>>> >>>>> Dear Albrecht: >>>>> Is there any H.248 package defined to signal the UDI transparenc= y >>>> >>>> >>>> >>>> >>>> properties in TDM hairping case? >>>> >>>>> Best regards >>>>> >>>>> ----- Original Message ----- >>>>> From: >>>>> To: "Zhao Bo" >>>>> Cc: ; >>>>> Sent: Wednesday, February 25, 2004 10:24 PM >>>>> Subject: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law convers= ion >>>>> >>>>> >>>>> >>>>> Dear Zhao Bo, >>>>> >>>>> because there isn't any "hairpinning" definition in MEGACOP/H.248 >>>> >>>> >>>> >>>> >>>> standards >>>> >>>>> ("please correct if I'm wrong"), I'd like to use the following one = for >>>>> responding your questions: >>>>> >>>>> >>>> >>>> ********************************************************************= ***************=20 >>>> >>>> >>>> >>>>> Definition: >>>>> TDM Hairpinning >>>>> ? is a scenario whereby a call is being made between two TDM=20 >>>>> endpoints on >>>> >>>> >>>> >>>> >>>> a >>>> >>>>> single media gateway. The media comes in on one TDM channel and=20 >>>>> goes >>>>> out on another TDM channel through the use of an internal loop=20 >>>>> in the >>>>> media gateway. >>>>> >>>>> Note 1: due to the fact that there are local call types at local >>>> >>>> >>>> >>>> >>>> exchanges >>>> >>>>> (CLASS5), and transit exchanges (CLASS4) in legacy TDM networks (PS= TN, >>>>> NISDN, etc), there is a variety of TDM-to-TDM connection types=20 >>>>> behind the >>>>> general "TDM hairpinning" capability (dependent on required type of= =20 >>>>> IWF, >>>>> etc.) in corresponding H.248 MG types >>>>> >>>>> Note 2: H.248/MEGCOP perspective >>>>> TDM Hairpinning =3D Single H.248 Context with 2 H.248 TDM Terminati= ons >>>>> >>>> >>>> ********************************************************************= ****************=20 >>>> >>>> >>>> >>>>> Based on this hairpinning understanding, my answers are: >>>>> >>>>> (1) Speech telephony service: G.711 companding formats are a=20 >>>>> property of >>>>> the corresponding H.248 TDM termination >>>>> >>>>> [Note: dependent on MG architecture and implementation, property=20 >>>>> might be >>>>> signalled or preprovisioned. Of course, G.711 companding law is an >>>> >>>> >>>> >>>> >>>> inherent >>>> >>>>> property of your DS0 channel at your PDH/SDH/SONET framer; the way,= =20 >>>>> how >>>>> this DS0 property is associated with the corresponding H.248 TDM >>>>> Termination property may only realized MG-internally for very=20 >>>>> specific MG >>>>> architectures. Generally it is up to the MGC, particularly if some = (or >>>> >>>> >>>> >>>> >>>> all) >>>> >>>>> DS0's are ISDN B channels.] >>>>> >>>>> (2) Voiceband Data services: same as in (1) >>>>> >>>>> [Note: VBD according new ITU-T V.152 -> "... For purposes of >>>>> interoperability, a V.152 compliant implementation shall support at= =20 >>>>> least >>>>> both G.711 A-law and G.711 =C3=AC-law codecs as VBD codecs. "] >>>>> >>>>> (3) ISDN UDI =3D all ISDN Teleservices with ISDN I.231. bearer serv= ice >>>>> requirement >>>>> =3D> H.248 TDM Termination property must be signalled by MGC, if no= t, MG >>>> >>>> >>>> >>>> >>>> may >>>> >>>>> not guarantee UDI capability (i.e., fully transparent 64-kbit/s bea= rer >>>>> channel) in TDM hairpinning scenarios ... >>>>> >>>>> >>>>> Conclusion: >>>>> IF your MG is supporting >>>>> PSTN lines (=3D H.248 ALN Termination), >>>>> PSTN trunks (=3D H.248 TDM Termination), and >>>>> ISDN B channels (=3D H.248 TDM Termination) >>>>> >>>>> AND IF you've such services and interworking requirements >>>>> >>>>> THEN you should generally signal the corresponding properties ... >>>>> >>>>> ... in case of >>>>> TDM hairpinning, >>>>> ALN hairpinning, or >>>>> ALN-to-TDM connection types. >>>>> >>>>> Regards, >>>>> Albrecht >>>>> >>>>> ALCATEL >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>>> Zhao Bo >>>> >>>> >>>> >>>> >>>> >>>>> To: megaco@ietf.= org >>>> >>>> >>>> >>>> >>>> >>>>> Sent by: cc: >>>> >>>> >>>> >>>> >>>> >>>>> megaco-admin@iet Subject: [Megaco]=20 >>>>> Hairpin >>>> >>>> >>>> >>>> >>>> case A/u Law conversion >>>> >>>>> f.org >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> 25.02.2004 08:11 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> In this case, the A/u law format of a TDM ciruit can be=20 >>>>> provisioned, but >>>>> the MG doesn't know the service type of a call, thus >>>>> has no way to know if a conversion is needed. For speech service >>>> >>>> >>>> >>>> >>>> conversion >>>> >>>>> may be needed; for data service like isdn UDI, conversion is not >>>> >>>> >>>> >>>> >>>> permitted. >>>> >>>>> Is there any method to solve this problem? >>>>> >>>>> Zhao Bo >>>>> >>>>> ***************************************************************** >>>>> This e-mail and its attachments contain confidential information fr= om >>>>> HUAWEI, which is intended only for the person or entity whose=20 >>>>> address is >>>>> listed above. Any use of the information contained herein in any wa= y >>>>> (including, but not limited to, total or partial disclosure, >>>> >>>> >>>> >>>> >>>> reproduction, >>>> >>>>> or dissemination) by persons other than the intended recipient(s) i= s >>>>> prohibited. If you receive this e-mail in error, please notify the=20 >>>>> sender >>>>> by phone or email immediately and delete it! >>>>> ***************************************************************** >>>>> >>>>> _______________________________________________ >>>>> Megaco mailing list >>>>> Megaco@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/megaco >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Megaco mailing list >>>>> Megaco@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/megaco >>>>> 1=C3=A8=1Ar=E2=80=B0=C5=A1=C5=A0X=C2=A7=E2=80=9AX=C2=AC=C2=B4=C3=87= i=C3=8A"z=C3=97=C3=A8=C2=AE=08m=C2=B6=E2=80=BA?=C3=BF=0C0=C3=96'=C2=AD~=C5= =A0=C3=A0=C3=BEf=C2=A2=E2=80=93f=C2=A7=C3=BEX=C2=AC=C2=B6)=C3=9F=C2=A3=C3= =B9=C5=BE=EF=A2=9D=C2=A7( >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Megaco mailing list >>> Megaco@ietf.org >>> https://www1.ietf.org/mailman/listinfo/megaco >>> >> >> >> This communication is confidential and intended solely for the=20 >> addressee(s). Any unauthorized review, use, disclosure or distribution= =20 >> is prohibited. If you believe this message has been sent to you in=20 >> error, please notify the sender by replying to this transmission and=20 >> delete the message without disclosing it. Thank you. >> >> E-mail including attachments is susceptible to data corruption,=20 >> interruption, unauthorized amendment, tampering and viruses, and we=20 >> only send and receive e-mails on the basis that we are not liable for=20 >> any such corruption, interception, amendment, tampering or viruses or=20 >> any consequences thereof. >> >> >> _______________________________________________ >> Megaco mailing list >> Megaco@ietf.org >> https://www1.ietf.org/mailman/listinfo/megaco >> >=20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Mon Apr 5 23:38:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12755 for ; Mon, 5 Apr 2004 23:38:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAhPh-00033K-Vr for megaco-archive@odin.ietf.org; Mon, 05 Apr 2004 23:38:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i363cDdx011734 for megaco-archive@odin.ietf.org; Mon, 5 Apr 2004 23:38:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAhPg-00032y-Rr for megaco-web-archive@optimus.ietf.org; Mon, 05 Apr 2004 23:38:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12518 for ; Mon, 5 Apr 2004 23:38:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAhPe-000253-00 for megaco-web-archive@ietf.org; Mon, 05 Apr 2004 23:38:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAh3G-0007Lr-00 for megaco-web-archive@ietf.org; Mon, 05 Apr 2004 23:15:06 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BAgcF-0004XZ-00 for megaco-web-archive@ietf.org; Mon, 05 Apr 2004 22:47:07 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BAgcH-0004uG-7i for megaco-web-archive@ietf.org; Mon, 05 Apr 2004 22:47:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAgcB-0000XU-O1; Mon, 05 Apr 2004 22:47:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAgby-0000Vp-V0 for megaco@optimus.ietf.org; Mon, 05 Apr 2004 22:46:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08470 for ; Mon, 5 Apr 2004 22:46:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAgbv-0004V5-00 for megaco@ietf.org; Mon, 05 Apr 2004 22:46:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAgB3-0001UJ-00 for megaco@ietf.org; Mon, 05 Apr 2004 22:19:04 -0400 Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1BAfoE-0006DU-00 for megaco@ietf.org; Mon, 05 Apr 2004 21:55:27 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i361tNWR029742 for ; Tue, 6 Apr 2004 03:55:26 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 6 Apr 2004 03:55:23 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id H8FWAYZ5; Tue, 6 Apr 2004 03:55:22 +0200 Received: from ericsson.com (sealwa04-208.sw.ericsson.se [130.100.249.208]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 2A5WM4ZF; Tue, 6 Apr 2004 11:54:50 +1000 Message-ID: <40720E2A.6070903@ericsson.com> Date: Tue, 06 Apr 2004 11:55:54 +1000 X-Sybari-Trust: 600ae803 2c4885b5 06e2c4e1 00000138 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Carsten Waitzmann CC: Tom Taylor , Albrecht.Schwarz@alcatel.de, Zhao Bo , megaco@ietf.org Subject: Re: Signaling of UDI rsp Clearmode Bearer Service; Re: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversion References: <403E1760.2010903@nortelnetworks.com> <40427B92.3000707@ericsson.com> <406C2424.7050708@alcatel.de> In-Reply-To: <406C2424.7050708@alcatel.de> Content-Type: text/plain; charset=UTF-8; format=flowed X-OriginalArrivalTime: 06 Apr 2004 01:55:23.0126 (UTC) FILETIME=[391B3160:01C41B7A] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by albatross.ericsson.se id i361tNWR029742 Content-Transfer-Encoding: quoted-printable Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello Carsten, Yes this is what I had in mind. The package ID for Annex C is 0. ie. H.248.1 Annex A PkgdName ::=3D OCTET STRING(SIZE(4)) -- represents Package Name (2 octets) plus Property, Event, -- Signal Names or Statistics ID. (2 octets) -- To wildcard a package use 0xFFFF for first two octets, choose -- is not allowed. To reference native property tag specified in -- Annex C, use 0x0000 as first two octets. Regards, Christian Carsten Waitzmann wrote: > Hello Christian, >=20 > I took your suggestion as a basis for the following example: >=20 > MGC -> MG: > MEGACO / 1 [1.2.3.4] > Transaction =3D 100 { > Context =3D $ { Add =3D TDM1 { > Media { > LocalControl {Mode =3D=20 > SendReceive}, > Local {a=3Dh248item:TMR =3D= =20 > 0000 0010}} > }}} >=20 > MG -> MGC > MEGACO / 1 [1.2.3.5] > Reply =3D 100 { > Context =3D 1 { > Add =3D TDM1 { > Media { > Local {a=3Dh248item:TMR = =3D=20 > 00000010} > }}}} >=20 > Is this usage in line to what you have in mind? > H.248.15 specifies: a=3Dh248item:/ =3D .=20 > For H.248.1 C.9 I do not know which package applies to property TMR. Bu= t=20 > H.248.15 states "To enable the carriage of package defined properties i= n=20 > the local and remote descriptors of the text encoded H.248.1 protocol=20 > the Package attribute shall be used" thus I am wondering whether a=20 > package name isn't mandatory? >=20 > Thanks a lot! >=20 > Carsten >=20 > Alcatel >=20 > Christian Groves wrote: >=20 >> Hello Tom and Albrecht, >> >> What peice of information do you want to signal explicitely? Doesn't=20 >> TMR allow you to specify 64Kbit UDI? If so then its supported by=20 >> H.248.1 Annex C.9. For H.248 text users this (or any element in Annex=20 >> C) can be tranferred via H.248.15. Alternatively Q.1950 sect 5.7.1.2=20 >> specifies an equivalent encoding. >> >> Regards, Christian >> >> Tom Taylor wrote: >> >>> I intended a reference to draft-ietf-avt-rtp-clearmode-04.txt in my=20 >>> intervention. My old draft has been allowed to expire because it did= =20 >>> not seem to be of much interest to the community. >>> >>> You are right: the draft just referred to doesn't apply to TDM, only=20 >>> to the packet side. I wasn't thinking. I agree that in the absence=20 >>> of the attributes provided in my old draft, TDM bearer=20 >>> characteristics are assumed rather than signalled explicitly. >>> >>> Albrecht.Schwarz@alcatel.de wrote: >>> >>>> I think that the question is, whether this specific TDM bearer=20 >>>> capability >>>> should be (1) explicitly signalled, or whether (2) implicit=20 >>>> assumption is >>>> already sufficient. >>>> >>>> With regard to (1), Tom, I guess that your refer to >>>> >>>> * RTP/CLEARMODE >>>> RTP payload format for a 64 kbit/s transparent call >>>> =20 >>>> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-clearmode-04.= txt >>>> >>>> But, this coming RFC may not be directly applied, e.g.,=20 >>>> packetization time >>>> parameter isn't applicable IMHO. Pls correct me if wrong. >>>> >>>> Or do you refer to your proposals in your expired draft wrt >>>> * TDM/CLEARMODE >>>> Conventions for the use of the Session Description Protocol (SDP) >>>> for Digital Circuit Connections >>>> http://www.watersprings.org/pub/id/draft-taylor-mmusic-sdp-tdm-01.= txt >>>> >>>> My conclusion is, that an explicit signalling method doesn't exist=20 >>>> today >>>> ("exception might be Q.1950"). >>>> Even though, an explicit TDM Media Descriptor for I.231.1 might be=20 >>>> helpful >>>> for unambigously specification in certain MG implementations. >>>> >>>> >>>> With regard to (2): >>>> Implicit signaling is in my understanding the situation of today. In= =20 >>>> case >>>> of, (a) missing TDM Media Descriptors, or (b) "identical TDM Media >>>> Descriptors with transparent channel indications", when a transparen= t >>>> 64-kbit/s bearer connection may be established. >>>> Sometimes this is also called "native TDM switching", or "native TDM >>>> hairpinning", but technically it is exactly representing an ISDN B=20 >>>> channel >>>> with I.231.1 bearer service. [=3D> the channel may bypass the DSP, b= ut in >>>> case that a DSP is looped-in, then must be the DSP channel operation= =20 >>>> mode >>>> configured for 'Clearmode'] >>>> >>>> Last comment: >>>> Such kind of implicit signalling mechanism is often assumed in telco >>>> industry, because this is the legacy signaling mechanism within a TD= M >>>> switch ("if there aren't any signaled bearer capabilities then=20 >>>> transparent >>>> channel; any needed bearer capability in addition must be explicitly >>>> signalled, like signal processing network equipment functions, e.g.,= =20 >>>> EC"). >>>> >>>> TDM hairpinning means, an "H.248-controlled TDM switching function"=20 >>>> from >>>> H.248 Media Gateway perspective. Hence, this implicit signalling=20 >>>> assumption >>>> may be still valid, or do you see any needs for explicit signaling >>>> codepoints in case of TDM-to-TDM ISDN I.231.1 calls? >>>> >>>> Regards >>>> >>>> Albrecht >>>> >>>> >>>> >>>> >>>> >>>> >>>> = = =20 >>>> Tom=20 >>>> Taylor = =20 >>>> >>> = =20 >>>> tworks.com> cc: Albrecht=20 >>>> SCHWARZ/DE/ALCATEL@ALCATEL,=20 >>>> megaco@ietf.org =20 >>>> Subject: Re: TDM=20 >>>> Hairpinning; Re: [Megaco] Hairpin case A/u Law=20 >>>> conversion =20 >>>> 26.02.2004=20 >>>> 14:05 = =20 >>>> = = =20 >>>> = = =20 >>>> >>>> >>>> >>>> >>>> I think you would do it by specifying the CLEARMODE codec in the=20 >>>> Local and >>>> Remote >>>> descriptors. Unfortunately, CLEARMODE is still under consideration=20 >>>> by the >>>> IESG >>>> and hasn't reached RFC status. >>>> >>>> Zhao Bo wrote: >>>> >>>>> Dear Albrecht: >>>>> Is there any H.248 package defined to signal the UDI transparenc= y >>>> >>>> >>>> >>>> >>>> properties in TDM hairping case? >>>> >>>>> Best regards >>>>> >>>>> ----- Original Message ----- >>>>> From: >>>>> To: "Zhao Bo" >>>>> Cc: ; >>>>> Sent: Wednesday, February 25, 2004 10:24 PM >>>>> Subject: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law convers= ion >>>>> >>>>> >>>>> >>>>> Dear Zhao Bo, >>>>> >>>>> because there isn't any "hairpinning" definition in MEGACOP/H.248 >>>> >>>> >>>> >>>> >>>> standards >>>> >>>>> ("please correct if I'm wrong"), I'd like to use the following one = for >>>>> responding your questions: >>>>> >>>>> >>>> >>>> ********************************************************************= ***************=20 >>>> >>>> >>>> >>>>> Definition: >>>>> TDM Hairpinning >>>>> ? is a scenario whereby a call is being made between two TDM=20 >>>>> endpoints on >>>> >>>> >>>> >>>> >>>> a >>>> >>>>> single media gateway. The media comes in on one TDM channel and=20 >>>>> goes >>>>> out on another TDM channel through the use of an internal loop=20 >>>>> in the >>>>> media gateway. >>>>> >>>>> Note 1: due to the fact that there are local call types at local >>>> >>>> >>>> >>>> >>>> exchanges >>>> >>>>> (CLASS5), and transit exchanges (CLASS4) in legacy TDM networks (PS= TN, >>>>> NISDN, etc), there is a variety of TDM-to-TDM connection types=20 >>>>> behind the >>>>> general "TDM hairpinning" capability (dependent on required type of= =20 >>>>> IWF, >>>>> etc.) in corresponding H.248 MG types >>>>> >>>>> Note 2: H.248/MEGCOP perspective >>>>> TDM Hairpinning =3D Single H.248 Context with 2 H.248 TDM Terminati= ons >>>>> >>>> >>>> ********************************************************************= ****************=20 >>>> >>>> >>>> >>>>> Based on this hairpinning understanding, my answers are: >>>>> >>>>> (1) Speech telephony service: G.711 companding formats are a=20 >>>>> property of >>>>> the corresponding H.248 TDM termination >>>>> >>>>> [Note: dependent on MG architecture and implementation, property=20 >>>>> might be >>>>> signalled or preprovisioned. Of course, G.711 companding law is an >>>> >>>> >>>> >>>> >>>> inherent >>>> >>>>> property of your DS0 channel at your PDH/SDH/SONET framer; the way,= =20 >>>>> how >>>>> this DS0 property is associated with the corresponding H.248 TDM >>>>> Termination property may only realized MG-internally for very=20 >>>>> specific MG >>>>> architectures. Generally it is up to the MGC, particularly if some = (or >>>> >>>> >>>> >>>> >>>> all) >>>> >>>>> DS0's are ISDN B channels.] >>>>> >>>>> (2) Voiceband Data services: same as in (1) >>>>> >>>>> [Note: VBD according new ITU-T V.152 -> "... For purposes of >>>>> interoperability, a V.152 compliant implementation shall support at= =20 >>>>> least >>>>> both G.711 A-law and G.711 =C3=AC-law codecs as VBD codecs. "] >>>>> >>>>> (3) ISDN UDI =3D all ISDN Teleservices with ISDN I.231. bearer serv= ice >>>>> requirement >>>>> =3D> H.248 TDM Termination property must be signalled by MGC, if no= t, MG >>>> >>>> >>>> >>>> >>>> may >>>> >>>>> not guarantee UDI capability (i.e., fully transparent 64-kbit/s bea= rer >>>>> channel) in TDM hairpinning scenarios ... >>>>> >>>>> >>>>> Conclusion: >>>>> IF your MG is supporting >>>>> PSTN lines (=3D H.248 ALN Termination), >>>>> PSTN trunks (=3D H.248 TDM Termination), and >>>>> ISDN B channels (=3D H.248 TDM Termination) >>>>> >>>>> AND IF you've such services and interworking requirements >>>>> >>>>> THEN you should generally signal the corresponding properties ... >>>>> >>>>> ... in case of >>>>> TDM hairpinning, >>>>> ALN hairpinning, or >>>>> ALN-to-TDM connection types. >>>>> >>>>> Regards, >>>>> Albrecht >>>>> >>>>> ALCATEL >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>>> Zhao Bo >>>> >>>> >>>> >>>> >>>> >>>>> To: megaco@ietf.= org >>>> >>>> >>>> >>>> >>>> >>>>> Sent by: cc: >>>> >>>> >>>> >>>> >>>> >>>>> megaco-admin@iet Subject: [Megaco]=20 >>>>> Hairpin >>>> >>>> >>>> >>>> >>>> case A/u Law conversion >>>> >>>>> f.org >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> 25.02.2004 08:11 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> In this case, the A/u law format of a TDM ciruit can be=20 >>>>> provisioned, but >>>>> the MG doesn't know the service type of a call, thus >>>>> has no way to know if a conversion is needed. For speech service >>>> >>>> >>>> >>>> >>>> conversion >>>> >>>>> may be needed; for data service like isdn UDI, conversion is not >>>> >>>> >>>> >>>> >>>> permitted. >>>> >>>>> Is there any method to solve this problem? >>>>> >>>>> Zhao Bo >>>>> >>>>> ***************************************************************** >>>>> This e-mail and its attachments contain confidential information fr= om >>>>> HUAWEI, which is intended only for the person or entity whose=20 >>>>> address is >>>>> listed above. Any use of the information contained herein in any wa= y >>>>> (including, but not limited to, total or partial disclosure, >>>> >>>> >>>> >>>> >>>> reproduction, >>>> >>>>> or dissemination) by persons other than the intended recipient(s) i= s >>>>> prohibited. If you receive this e-mail in error, please notify the=20 >>>>> sender >>>>> by phone or email immediately and delete it! >>>>> ***************************************************************** >>>>> >>>>> _______________________________________________ >>>>> Megaco mailing list >>>>> Megaco@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/megaco >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Megaco mailing list >>>>> Megaco@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/megaco >>>>> 1=C3=A8=1Ar=E2=80=B0=C5=A1=C5=A0X=C2=A7=E2=80=9AX=C2=AC=C2=B4=C3=87= i=C3=8A"z=C3=97=C3=A8=C2=AE=08m=C2=B6=E2=80=BA?=C3=BF=0C0=C3=96'=C2=AD~=C5= =A0=C3=A0=C3=BEf=C2=A2=E2=80=93f=C2=A7=C3=BEX=C2=AC=C2=B6)=C3=9F=C2=A3=C3= =B9=C5=BE=EF=A2=9D=C2=A7( >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Megaco mailing list >>> Megaco@ietf.org >>> https://www1.ietf.org/mailman/listinfo/megaco >>> >> >> >> This communication is confidential and intended solely for the=20 >> addressee(s). Any unauthorized review, use, disclosure or distribution= =20 >> is prohibited. If you believe this message has been sent to you in=20 >> error, please notify the sender by replying to this transmission and=20 >> delete the message without disclosing it. Thank you. >> >> E-mail including attachments is susceptible to data corruption,=20 >> interruption, unauthorized amendment, tampering and viruses, and we=20 >> only send and receive e-mails on the basis that we are not liable for=20 >> any such corruption, interception, amendment, tampering or viruses or=20 >> any consequences thereof. >> >> >> _______________________________________________ >> Megaco mailing list >> Megaco@ietf.org >> https://www1.ietf.org/mailman/listinfo/megaco >> >=20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Apr 6 03:28:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16408 for ; Tue, 6 Apr 2004 03:28:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAl09-00023A-Az; Tue, 06 Apr 2004 03:28:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAkzd-0001ld-0b for megaco@optimus.ietf.org; Tue, 06 Apr 2004 03:27:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16277 for ; Tue, 6 Apr 2004 03:27:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAkza-0006IR-00 for megaco@ietf.org; Tue, 06 Apr 2004 03:27:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAksW-00050g-00 for megaco@ietf.org; Tue, 06 Apr 2004 03:20:12 -0400 Received: from mta1.huawei.com ([61.144.161.40] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1BAkcW-0002Ax-00 for megaco@ietf.org; Tue, 06 Apr 2004 03:03:41 -0400 Received: from l12381 (huawei.com [172.17.1.60]) by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0HVQ003HGLSVEC@mta1.huawei.com> for megaco@ietf.org; Tue, 06 Apr 2004 14:53:22 +0800 (CST) Date: Tue, 06 Apr 2004 15:02:10 +0800 From: ll Subject: [megaco] About DCME(digital Circuit Multiplication Equipment) To: "megaco@ietf.org" Message-id: <0HVQ003HILSYEC@mta1.huawei.com> MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: TEXT/PLAIN Content-transfer-encoding: QUOTED-PRINTABLE X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.3 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, MAILTO_TO_SPAM_ADDR,TO_ADDRESS_EQ_REAL autolearn=no version=2.60 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: QUOTED-PRINTABLE hi,everyone, =09Is there a package for DCME(digital Circuit Multiplication Equipm= ent)? Best Regards =09=09=09=09 =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1lihu =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1l12381@huawei.com =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A12004-04-0= 6 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Tue Apr 6 04:20:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20401 for ; Tue, 6 Apr 2004 04:20:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAloi-0006vj-Sc for megaco-archive@odin.ietf.org; Tue, 06 Apr 2004 04:20:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i368KKGb026634 for megaco-archive@odin.ietf.org; Tue, 6 Apr 2004 04:20:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAloh-0006vK-Vf for megaco-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 04:20:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20288 for ; Tue, 6 Apr 2004 04:20:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAlof-0004KZ-00 for megaco-web-archive@ietf.org; Tue, 06 Apr 2004 04:20:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAlZf-0001Ym-00 for megaco-web-archive@ietf.org; Tue, 06 Apr 2004 04:04:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BAl08-0006Ni-00 for megaco-web-archive@ietf.org; Tue, 06 Apr 2004 03:28:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAl09-00023A-Az; Tue, 06 Apr 2004 03:28:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAkzd-0001ld-0b for megaco@optimus.ietf.org; Tue, 06 Apr 2004 03:27:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16277 for ; Tue, 6 Apr 2004 03:27:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAkza-0006IR-00 for megaco@ietf.org; Tue, 06 Apr 2004 03:27:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAksW-00050g-00 for megaco@ietf.org; Tue, 06 Apr 2004 03:20:12 -0400 Received: from mta1.huawei.com ([61.144.161.40] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1BAkcW-0002Ax-00 for megaco@ietf.org; Tue, 06 Apr 2004 03:03:41 -0400 Received: from l12381 (huawei.com [172.17.1.60]) by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0HVQ003HGLSVEC@mta1.huawei.com> for megaco@ietf.org; Tue, 06 Apr 2004 14:53:22 +0800 (CST) Date: Tue, 06 Apr 2004 15:02:10 +0800 From: ll Subject: [megaco] About DCME(digital Circuit Multiplication Equipment) To: "megaco@ietf.org" Message-id: <0HVQ003HILSYEC@mta1.huawei.com> MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: TEXT/PLAIN Content-transfer-encoding: QUOTED-PRINTABLE Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.3 required=5.0 tests=AWL,FROM_ENDS_IN_NUMS, MAILTO_TO_SPAM_ADDR,TO_ADDRESS_EQ_REAL autolearn=no version=2.60 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Transfer-Encoding: QUOTED-PRINTABLE hi,everyone, =09Is there a package for DCME(digital Circuit Multiplication Equipm= ent)? Best Regards =09=09=09=09 =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1lihu =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1l12381@huawei.com =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A12004-04-0= 6 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Apr 6 10:24:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22215 for ; Tue, 6 Apr 2004 10:24:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BArUf-0005Ao-9f; Tue, 06 Apr 2004 10:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAgOY-0005gB-V4 for megaco@optimus.ietf.org; Mon, 05 Apr 2004 22:32:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07176 for ; Mon, 5 Apr 2004 22:32:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAgOV-0002iu-00 for megaco@ietf.org; Mon, 05 Apr 2004 22:32:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAfve-0007OA-00 for megaco@ietf.org; Mon, 05 Apr 2004 22:03:08 -0400 Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1BAfa4-0004In-00 for megaco@ietf.org; Mon, 05 Apr 2004 21:40:48 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i361emWR027828 for ; Tue, 6 Apr 2004 03:40:48 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 6 Apr 2004 03:40:47 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 2CQBX2F0; Tue, 6 Apr 2004 03:41:10 +0200 Received: from ericsson.com (sealwa04-208.sw.ericsson.se [130.100.249.208]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 2A5WM43M; Tue, 6 Apr 2004 11:39:42 +1000 Message-ID: <40720AA2.9000101@ericsson.com> Date: Tue, 06 Apr 2004 11:40:50 +1000 X-Sybari-Trust: 227f4e00 272a6e05 0d802f51 00000139 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: megaco ietf Content-Type: multipart/mixed; boundary="------------020305050802080009070500" X-OriginalArrivalTime: 06 Apr 2004 01:40:47.0790 (UTC) FILETIME=[2F5D84E0:01C41B78] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Megaco] ITU-SG16 Q.3 [Fwd: Notice of the Beijing meeting (11-14 May 2004)] Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------020305050802080009070500 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello all, For your information, please find attached the invitation to the next SG16 meeting Q.3 meeting where H.248 will be discussed. If you are interested in attending it is important to sort out the visa issues as soon as possible. Regards, Christian -------- Original Message -------- Subject: Notice of the Beijing meeting (11-14 May 2004) Date: Thu, 1 Apr 2004 03:37:37 -0500 (EST) From: OKUBO Sakae To: itu-sg16@external.cisco.com CC: Pierre-Andre PROBST *** This notice and the host's information as attached will be *** *** placed at . *** To Experts of ITU-T SG16 Questions F, G, K, 2, 3, 4 and 5/16 Cc Mr. P-A. Probst, Chairman of SG16 Mr. M. Matsumoto, Vice-Chairman of SG16 Mr. S. Campos-Neto, ITU TSB Mr. L. Jiang, MII Ms. Y. Shen, MII Mr. C. Hansen, Rapporteur for Q.B/16 , Mr. P. Luthi, Rapporteur for Q.1/16 De S-H. Jeong Rapporteur for Q.F/16 M. Euchner Rapporteur for Q.G/16 L. Lehmann Rapporteur for Q.K/16 P. Jones Rapporteur for Q.2/16 C. Groves Rapporteur for Q.3/16 S. Okubo Rapporteur for Q.4/16 R. Gilman Rapporteur for Q.5/16 ------------------------------------------------------------------- Subject: Notice of Joint Rapporteur Meeting in Beijing, China Date: 31 March 2004 ------------------------------------------------------------------- Dear experts of Questions F, G, K, 2-5/16, The subject meeting of ITU-T SG16 experts will be held in Beijing, China at the kind invitation of China Academy of Telecommunications Research of MII and China Communications Standards Association. Details of the meeting are contained herein. Please note that Q.B/16 and Q.1/16 may meet concurrently and we will have joint sessions with these Questions in that case. 1. Date ^^^^^^^ 11 (Tuesday) - 14 (Friday) May 2004 Meeting will start at 9:00 AM on the first day Closing around 18:00 on the final day 2. Venue ^^^^^^^^ GUANGZHOU HOTEL No.A3, Xi Dan Heng Er Tiao, Xicheng District, Beijing, China Tel: +86 10 66078866 Fax: +86 10 66085998 Post Code: 100031 3. Topics (tentative) ^^^^^^^^^^^^^^^^^^^^^ 1) Review of the relevant group activities 2) Q.F/16 Quality of Service and End-to-end Performance in Multimedia Systems - Progress work for: * Annex N H.323 * H.priority * H.trans.cont 3) Q.G/16 Security of Multimedia Systems and Services - Progress work for: * H.235 Annex G * other study items in the living list (TD-71/WP2, January 2004) 4) Q.K/16 Mobility for Multimedia Systems and Services - Further elaboration TD-53/WP2 (January 2004) - Mobility aspects of presence service; co-ordination with Q.2/16 - Study of new service features - Follow up workplan 5) Q.2/16 Multimedia over packet networks using H.323 systems - Progress work for: * H.460.tppr * H.460.trans * H.460.relreq * H.gaam * H.323 Annexes I & N * H.323 Annexes Dv3, Gv2, Ov2 * H.sms * H.presence 6) Q.3/16 Infrastructure and interoperability for Multimedia over packet networks - Progress work for: * H.248-subseries * H.245 v11 * H.341 7) Q.4/16 Video and data conferencing using Internet-supported services - H.350-series maintenance - Addition to H.350-series - Presence use scenarios - Study of new service features 8) Q.5/16 Control of NAT and Firewall Traversal for Multimedia Systems - Progress NAT/firewall traversal methods 9) Interaction with other groups - NGN - Others 10) Future work plan 4. Documents ^^^^^^^^^^^^ /// Registration of the document: by 23:59 UTC, 30 April 2004 /// /// Distribution of the document: by 23:59 UTC, 4 May 2004 /// /// Use the ftp site (or e-mail reflector) for distribution /// 1) When you are going to submit a document, please notify Paul Jones , document manager of this meeting, as soon as possible, by 23:59 UTC, Friday 30 April 2004 at the latest. Document number AVD-nnnn will be allocated. Early indication of your submission plan is welcome and encouraged. Note: Prefix "AVD" comes from Audio, Video and Data. 2) You are advised to include a header as follows: ------------------------------------------------------------------ | | | ITU Telecommunication Standardization Sector Document AVD-{nnnn}| | Study Group 16 {Version m if relevant}| | Q.F, G, K, 2-5/16 Rapporteur Meeting {Date}| | Beijing, 11-14 May 2004 | | | | SOURCE*: { } | | TITLE : { } | | PURPOSE: {Proposal, Discussion, Information, Report, etc.} | | | | _________________________ | | | | | | | | *Contact: Name, e-mail | ------------------------------------------------------------------ Note: A template for the AVD document can be found at: This may be modified and used for the purpose of document submission at this meeting. 3) File format: Use of Word, PDF, ASCII or HTML is recommended. 4) All the contributors are requested to distribute their documents as early as possible, at least 7 calendar days in advance of the meeting (23:59 UTC, Tuesday 4 May 2004 or before) by posting them at either of the following: - Uploading via FTP Site: ftp3.itu.int/ User ID: avguest Password: Avguest (Note the uppercase 'A') Directory: avc-site/Incoming - E-mail reflector E-mail address: itu-sg16@external.cisco.com To subscribe: Send e-mail to majordomo@cisco.com In the body of the message, put: subscribe itu-sg16 Please avoid the use of reflector when your document is voluminous. 5) Input documents can be retrieved from /0405_Bei directory of the ftp site once Mr. Jones has an opportunity to put them into place. The documents will also be available through the following URLs: http://ftp3.itu.int/av-arch/avc-site/0405_Bei/ ftp://avguest:Avguest@ftp3.itu.int/avc-site/0405_Bei/ 6) The document distribution / presentation at the meeting will be all electronic. Participants must bring along a laptop and 802.11b wireless card in order to access the documents. 5. Logistic information ^^^^^^^^^^^^^^^^^^^^^^^ The meeting will be hosted by China Academy of Telecommunications Research of MII and China Communications Standards Association. Please refer to the participants' information document kindly prepared by the host, which is available at: 6. Registration ^^^^^^^^^^^^^^^ To register your meeting attendance, please send the Meeting Registration / Hotel Room Reservation Form provided by the host in the participants' information document to Ms. Jiang Hong with copy to Ms.Yaqin Shen and CCSA by 28 April 2004. 7. Hotel Room Reservation ^^^^^^^^^^^^^^^^^^^^^^^^^ You are recommended to stay at GUANGZHOU HOTEL, the meeting place. For room reservation, please indicate the dates of your stay in the Meeting Registration / Hotel Room Reservation Form. We are looking forward to meeting with you in Beijing. Sincerely yours, Seong-ho JEONG Martin EUCHNER Robert GILMAN Paul JONES (document manager of this meeting) Christian GROVES Sakae OKUBO (meeting organizer of this meeting) Leo LEHMANN ---------- --------------020305050802080009070500 Content-Type: application/msword; x-mac-type="5738424E"; x-mac-creator="4D535744"; name="Participants-info_Beijing.doc" Content-Disposition: inline; filename="Participants-info_Beijing.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAdAAAAAAA AAAAEAAAdgAAAAEAAAD+////AAAAAHMAAAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////spcEAiUAJBAAA+FK/AAAAAAABEQABAAEABgAA 8BMAAA4AamJqYp12nXYAAAAAAAAAAAAAAAAAAAAAAAARBBYAIioAAPcUAQD3FAEA1g0AAAAA AAAZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8A AAAAAAAAAAAAAAAAAAAAAGwAAAAAAOYCAAAAAAAA5gIAAOYCAAAAAAAA5gIAAAAAAADmAgAA AAAAAOYCAAAAAAAA5gIAABQAAAAAAAAAAAAAAD4DAAAAAAAAPgMAAAAAAAA+AwAAAAAAAD4D AAA4AAAAdgMAABwAAACSAwAALAAAAD4DAAAAAAAAMxMAAKgBAADSAwAAXgAAADAEAAAiAAAA UgQAAAAAAABSBAAAAAAAAFIEAAAAAAAApwgAAAAAAACnCAAAAAAAAKcIAAAAAAAA8BIAAAIA AADyEgAAAAAAAPISAAAAAAAA8hIAAAAAAADyEgAAAAAAAPISAAAAAAAA8hIAACwAAADbFAAA IAIAAPsWAABQAAAAHhMAABUAAAAAAAAAAAAAAAAAAAAAAAAA5gIAAAAAAACnCAAAAAAAAAAA AAAAAAAAAAAAAAAAAACFCAAAIgAAAKcIAAAAAAAApwgAAAAAAACnCAAAAAAAAB4TAAAAAAAA WQoAAAAAAADmAgAAAAAAAOYCAAAAAAAAUgQAAAAAAAAAAAAAAAAAAFIEAAAzBAAA0gMAAAAA AABZCgAAAAAAAFkKAAAAAAAAWQoAAAAAAACnCAAADAEAAOYCAAAAAAAAUgQAAAAAAADmAgAA AAAAAFIEAAAAAAAA8BIAAAAAAAAAAAAAAAAAAFkKAAAAAAAA+gIAACIAAAAcAwAAIgAAAOYC AAAAAAAA5gIAAAAAAADmAgAAAAAAAOYCAAAAAAAApwgAAAAAAADwEgAAAAAAAFkKAAA0BgAA WQoAAAAAAACNEAAAjgAAAEwSAABoAAAA5gIAAAAAAADmAgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1BIAAAAAAAAAAAAA AAAAAL4DAAAUAAAAbYCRvAAAAAA+AwAAAAAAAD4DAAAAAAAAswkAAKYAAAC0EgAAEAAAAAAA AAAAAAAA1BIAABwAAAAzEwAAAAAAADMTAAAAAAAAxBIAABAAAABLFwAAAAAAAFkKAAAAAAAA SxcAAAAAAADUEgAAAAAAAFkKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAABADDAA8A5QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQYXJ0 aWNpcGFudHOSIEluZm9ybWF0aW9uDQ1JVFUtVCBTRzE2IFJhcHBvcnRldXIgTWVldGluZw0x MSAtIDE0IE1heSwgIDIwMDQgDUd1YW5nemhvdSBIb3RlbCwgQmVpamluZywgIENoaW5hDQ0N VmVudWUgYW5kIER1cmF0aW9uDUNoaW5hIEFjYWRlbXkgb2YgVGVsZWNvbW11bmljYXRpb24g UmVzZWFyY2ggb2YgTUlJIGFuZCBDaGluYSBDb21tdW5pY2F0aW9ucyBTdGFuZGFyZHMgQXNz b2NpYXRpb24gaGF2ZSB0aGUgaG9ub3IgdG8gaW52aXRlIHRoZSBwYXJ0aWNpcGFudHMgdG8g dGhlIElUVS1UIFNHMTYgUmFwcG9ydGV1ciBNZWV0aW5nLCB3aGljaCB3aWxsIGJlIGhlbGQg aW4gR3Vhbmd6aG91IEhvdGVsLCBCZWlqaW5nIGZyb20gMTEgdG8gMTQgTWF5IDIwMDQuIA0N R1VBTkdaSE9VIEhPVEVMDU5vLkEzLCBYaSBEYW4gSGVuZyBFciBUaWFvLCANWGljaGVuZyBE aXN0cmljdCwgQmVpamluZywgDUNoaW5hDVRlbDoJKzg2IDEwIDY2MDc4ODY2DUZheDoJKzg2 IDEwIDY2MDg1OTk4DVBvc3QgQ29kZTogMTAwMDMxIA0BICAgICAgICABDSAgICAgDQ1SZWdp c3RyYXRpb24NVGhlIFJlZ2lzdHJhdGlvbiBDb3VudGVyIGZvciB0aGUgbWVldGluZyB3aWxs IGJlIHNldCB1cCBpbiBmcm9udCBvZiB0aGUgbWVldGluZyByb29tIGF0IDA4OjMwIGhvdXJz IG9uIFR1ZXNkYXkgMTEgTWF5IGFuZCB3aWxsIHJlbWFpbiBvcGVuIHRocm91Z2hvdXQgdGhl IG1lZXRpbmcuDQ1UcmFuc2ZlcnMgZnJvbSBBaXJwb3J0DUd1YW5nemhvdSBIb3RlbCBpcyBs b2NhdGVkIGluIHRoZSBkb3dudG93biBhcmVhIGFuZCB0aGUgY2VudGVyIG9mIEJlaWppbmcs IGFwcHJveGltYXRlbHkgMzAga2lsb21ldGVycyBmcm9tIHRoZSBhaXJwb3J0LiBBIHRheGkg ZmFyZSBmcm9tIHRoZSBhaXJwb3J0IHRvIHRoZSBjaXR5IGNlbnRlciAodGhlIG1lZXRpbmcg dmVudWUpIGlzIGFyb3VuZCBSTUIxMzAuMDAgliAxNTAuMDAgeXVhbi4gQSBzaHV0dGxlLWJ1 cyBmYXJlIGlzIGN1cnJlbnRseSBSTUIxNi4wMCB5dWFuLiANDUhvdGVsIEFjY29tbW9kYXRp b24NVGhlIHBhcnRpY2lwYW50cyBhcmUgcmVjb21tZW5kZWQgdG8gbGl2ZSBpbiBHdWFuZ3po b3UgSG90ZWwuDVJvb20gUmF0ZTogIFJNQjY1MC4wMCB5dWFuIHBlciByb29tIHBlciBuaWdo dCAoaW5jbHVkaW5nIGJyZWFrZmFzdCkNVGhlIGxvY2FsIHNlY3JldGFyaWF0IHdpbGwgY29v cmRpbmF0ZSBib29raW5nIG9mIGFsbCBob3RlbCByb29tcyBmb3IgcGFydGljaXBhbnRzLiAN DSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDUVsZWN0cmljYWwgU29ja2V0IERlc2ln bg1UaGUgc3RhbmRhcmQgcG93ZXIgc3VwcGx5IGluIENoaW5hIGlzIDIyMCBWb2x0cyA1MCBI ei4gIFBsZWFzZSBicmluZyB0aGUgYXBwcm9wcmlhdGUgYWRhcHRlcnMgYW5kIGNvbnZlcnRl cnMuDSAgICAgICAgICAIDTMgcGluIHNvY2tldA0NDQ0NDQ0NDQ0NQWlycG9ydCBUYXgNQWly cG9ydCBUYXggaXMgUk1COTAuMDAgeXVhbi4NDUZvcmVpZ24gRXhjaGFuZ2UgUmF0ZQ1QYXJ0 aWNpcGFudHMgYXJlIHJlcXVlc3RlZCB0byBjaGVjayB3aXRoIGxvY2FsIGJhbmtzIG9yIGZp bmFuY2lhbCBzZXJ2aWNlcyBmb3IgbGF0ZXN0IHJhdGVzLiBVU0QgMS4wMCBlcXVhbHMgYXBw cm94aW1hdGVseSBSTUI4LjMwLg0NV2VhdGhlcg1EdXJpbmcgTWF5IHRoZSBhdmVyYWdlIHRl bXBlcmF0dXJlIHZhcmllcyBmcm9tIGFwcHJveCAxNSB0byAyNSBkZWdyZWVzIENlbHNpdXMu IA0NSW5zdXJhbmNlDVRoZSBwYXJ0aWNpcGFudHMgYXJlIHJlcXVlc3RlZCB0byBraW5kbHkg bWFrZSBuZWNlc3NhcnkgYXJyYW5nZW1lbnRzIGZvciBpbnN1cmFuY2UgYW5kIG1lZGljYWwg Y292ZXJhZ2UgYmVmb3JlIHRyYXZlbC4gDQ1XaXJlbGVzcyBBY2Nlc3MNQXMgdGhlIG1lZXRp bmcgd2lsbCBiZSBhbiBhbGwtZWxlY3Ryb25pYyBtZWV0aW5nLCBubyBwYXBlciBjb3BpZXMg b2YgdGhlIGlucHV0IGNvbnRyaWJ1dGlvbnMgd2lsbCBiZSBhdmFpbGFibGUuIFBhcnRpY2lw YW50cyBhcmUgcmVtaW5kZWQgdG8gYnJpbmcgdGhlaXIgUEOScyBhbmQgd2lyZWxlc3MgbmV0 d29yayBjYXJkcyB3aXRoIHRoZW0uIFdpcmVsZXNzIDgwMi4xMWIgYWNjZXNzIHdpbGwgYmUg YXZhaWxhYmxlIGluIHRoZSBtZWV0aW5nIHJvb20uDQ1Mb2NhbCBTZWNyZXRhcmlhdA1Ncy4g SmlhbmcgSG9uZw1Ncy4gU2hlbiBZYXFpbg1DaGluYSBBY2FkZW15IG9mIFRlbGVjb21tdW5p Y2F0aW9uIFJlc2VhcmNoDVRlbDogICs4NiAxMCA2MjMwNDM3Ng1GYXg6ICs4NiAxMCA2MjMw NDM2NA1FbWFpbDogIBMgSFlQRVJMSU5LICJtYWlsdG86amlhbmdob25nQGNhdHIuY29tLmNu IiABFGppYW5naG9uZ0BjYXRyLmNvbS5jbhU7IBMgSFlQRVJMSU5LICJtYWlsdG86c2hlbnlh cWluQGNhdHIuY29tLmNuIiABFHNoZW55YXFpbkBjYXRyLmNvbS5jbhUNDA1NZWV0aW5nIFJl Z2lzdHJhdGlvbiAvIEhvdGVsIFJvb20gUmVzZXJ2YXRpb24gRm9ybSANV1AyIC8xNiBNZWV0 aW5nDTExLTE0ICBNYXkgMjAwNA0NUGxlYXNlIGNvbXBsZXRlIGEgc2VwYXJhdGUgZm9ybSBm b3IgZWFjaCBkZWxlZ2F0ZSBhbmQgcmV0dXJuIGJ5IDI4dGggQXByaWwgMjAwNCB0bzoNTXMu IEhvbmcgSmlhbmcgICAgICAgICBUZWwvRmF4OiArODYxMC02MjMwNDczNQ1FbWFpbDogIBMg SFlQRVJMSU5LICJtYWlsdG86amlhbmdob25nQGNhdHIuY29tLmNuIiABFGppYW5naG9uZ0Bj YXRyLmNvbS5jbhUNV2l0aCBhIGNvcHkgdG8gTXMuWWFxaW4gU2hlbiBhbmQgQ0NTQToNICAg ICAgICAgICAgICAgICAgICAgICAgICATIEhZUEVSTElOSyAibWFpbHRvOnNoZW55YXFpbkBj YXRyLmNvbS5jbiIgARRzaGVueWFxaW5AY2F0ci5jb20uY24VDSAgICAgICAgICAgICAgICAg ICAgICAgICAgEyBIWVBFUkxJTksgIm1haWx0bzpjY3NhY29udGFjdEBjY3NhLm9yZy5jbiIg ARRjY3NhY29udGFjdEBjY3NhLm9yZy5jbhUNDUZpcnN0IE5hbWU6IAlfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQ1GYW1pbHkgTmFtZTogCV9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NDUNvdW50cnk6ICAgICAgICAgCV9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NDUNvbXBhbnk6IAkJX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0NQWRkcmVzczogIAkJX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0NVGVsOiAJCQlfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQ1GYXg6 CQkJIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0NRW1haWw6IAkJX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0NSG90ZWwgUm9vbSBSZXNlcnZhdGlvbg1D aGVjay1pbiBkYXRlOiAgICAgICBfX18gTWF5DUNoZWNrLW91dCBkYXRlOiAgICAgX19fIE1h eQ0JTnVtYmVyIG9mIG5pZ2h0czogX19fDQ1GbGlnaHQgaW5mb3JtYXRpb24NQXJyaXZhbDog ICAgICBfX19fX19fX19fX19fX19fX18NRGVwYXJ0dXJlOiBfX19fX19fX19fX19fX19fX18N DVNwZWNpYWwgcmVxdWVzdHMgaWYgYW55OiANDRNQQUdFICAVDQ0NE1BBR0UgIBQzFQ0NDQ0N AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAABoGAAAbBgAA OQYAADsGAAA+BgAAQAYAAEEGAABEBgAASgYAAEsGAABeBgAAZQYAAGgGAABpBgAAbQYAAG4G AABvBgAAcAYAAIMGAABpBwAAawcAAG8HAABxBwAAcgcAAHUHAAB5BwAAegcAAH0HAAB+BwAA jQcAAI4HAADMBwAAzQcAAOEHAADiBwAA9gcAAPcHAAAICAAACggAAAsIAAATCAAAFAgAABoI AAAbCAAAHAgAACkIAADMCAAAzQgAAOQIAAD0CQAA9QkAAAkKAABVCgAAWAoAAIkKAACKCgAA 3goAAN8KAAD8CgAA/QoAABYLAAA7CwAAPgsAAIMLAACOCwAA/fr38/Hz8fPx8/Hz8fPx8wD6 AO3n7eft5+3n7eEA39zYAN8A3wDUy/rC1Ly4AO24AO24AO3n7eftuN+yAO3n7ecAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAKPioBQ0oWAG8oAQAHNQiBQ0oYAAo1CIFDShgAbygBABAD ajczAABDShgAVQgBbygBABADagAAAABDShgAVQgBbygBAAdDShgAbygBB21IFARvKAEEbUgU BAADbygBCgwqB0NKGABvKAEACjUIgUNKFgBvKAEABzUIgUNKFgADPioBBj4qAW8oAQAEQ0oc AAAEQ0oYAAAEQ0ooAEEABgAAGgYAABsGAAA5BgAATQYAAG4GAABvBgAAcAYAAIMGAAB9BwAA fgcAAI4HAACrBwAAxwcAAM0HAADiBwAA9wcAAAoIAAAVCAAAGwgAABwIAAApCAAAzAgAAM0I AADkCAAA9AkAAPUJAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7 AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA7gAA AAAAAAAAAAAAAO4AAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAA AAAAAAAAAADpAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADpAAAAAAAA AAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA4AAAAAAAAAAA AAAAAO4AAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAA AAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAAAAAAgQAAMkABGE8ABghPAAYSQAAAQQAAMk A2EkAwAHEAADJAASZGgBAQBhJAAABBAAAyQAYSQAAAEQAAABDwAAGgAGAAAaBgAAGwYAADkG AABNBgAAbgYAAG8GAABwBgAAgwYAAH0HAAB+BwAAjgcAAKsHAADHBwAAzQcAAOIHAAD3BwAA CggAABUIAAAbCAAAHAgAACkIAADMCAAAzQgAAOQIAAD0CQAA9QkAAAkKAABGCgAAigoAAN4K AADfCgAA/QoAABYLAACECwAAkAsAAJ0LAACeCwAAnwsAAKALAAChCwAAogsAAKMLAACkCwAA pQsAAKYLAACnCwAAswsAANELAADSCwAA6AsAAGwMAABtDAAAdQwAAMYMAADHDAAA0QwAAEkN AABKDQAAWg0AAF0OAABeDgAAcA4AAH8OAACODgAAug4AANAOAADlDgAAdg8AAHgPAACsDwAA vA8AAMwPAADNDwAAIRAAAFAQAACcEAAAwxAAACERAACDEQAAhBEAALQRAAC1EQAA5hEAAOcR AAAcEgAAHRIAAEsSAABMEgAAexIAAHwSAACnEgAAqBIAANISAADTEgAA/xIAAP39/fv7+/v7 +/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/sAAPkA9/kA9/sA9fn7+/v7 +/v7+/v7+/39+/Ly8vLy8vLy8vLy8vDy+/Ly8vLy8vLyAAIBAQAFAhAADQEDAhkAAwIXAAMC GAADAhAAAwIPAABf9QkAAAkKAABGCgAAigoAAN4KAADfCgAA/QoAABYLAACECwAAkAsAAJ0L AACeCwAAnwsAAKALAAChCwAAogsAAKMLAACkCwAApQsAAKYLAACnCwAAswsAANELAADSCwAA 6AsAAGwMAABtDAAAdQwAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA7gAAAAAAAAAA AAAAAOwAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB FwAABAAAAyQDYSQDAAQYAAMkA2EkAwABAAAABBAAAyQAYSQAABuOCwAAjwsAAJALAACcCwAA nQsAAKcLAACoCwAAswsAANELAADSCwAA0wsAAOgLAABsDAAAbQwAAG4MAAB0DAAAdQwAAMYM AADHDAAAyAwAANAMAADRDAAASQ0AAEoNAABaDQAA+A0AABMOAABcDgAAXg4AAHAOAADtDgAA 7g4AABgPAAAZDwAAGg8AAC8PAAAwDwAAMg8AADMPAABdDwAAXg8AAF8PAAB0DwAAdQ8AAHYP AAB3DwAAqg8AAKsPAACsDwAAsA8AALIPAACzDwAAvA8AAL4PAAC/DwAAwQ8AAPPt6e3l4d3a z+Hdys/h3QDaxuHdAL/PAOnt6cYA6bbprLantum26Z22p7bpm5iUkZSRlJGNmI0AAAAHQ0og AG8oAQRDShwAAAdDShwAbygBBENKIAAAAzUIgRMCCIEDakl+AAAGCAFDShYAVQgBCDBKEQBD ShYAABMCCIEDam59AAAGCAFDShYAVQgBEANqAAAAADUIgUNKFgBVCAEADUIqAENKFgBwaAAA AP8HNQiBQ0oYAAhDShYAbUgJBAAVQioAQ0oWAE9KAwBRSgMAcGgAAAD/BENKFgAABzUIgUNK HAAHNQiBQ0ooAAdDShgAbygBBzUIgUNKFgAKNQiBQ0oWAG8oAQAYA2oAAAAANQiBQ0oWAFUI AW1IAARuSAAEN3UMAADGDAAAxwwAANEMAABJDQAASg0AAFoNAABdDgAAXg4AAHAOAAB/DgAA jg4AALoOAADQDgAA5Q4AAHYPAAB4DwAArA8AALwPAADMDwAA/QAAAAAAAAAAAAAAAPgAAAAA AAAAAAAAAADzAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAAD4AAAAAAAA AAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAA AAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAA AAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAMgAAAAAAAAAAAAAAADIAAAAAAAAAAAAAAAA pAAAAAAAAAAAAAAAAAAAIxAAJGQEAQAAJWQEAQAEJmQEAQABJ2QEAQAETsYIAAAA/wQBAABP xggAAAD/BAEEAFDGCAAAAP8EAQEAUcYIAAAA/wQBBAAAIw8AJGQEAQAAJWQEAQAEJmQEAQAB J2QEAQAETsYIAAAA/wQBAABPxggAAAD/BAEEAFDGCAAAAP8EAQEAUcYIAAAA/wQBBAAABBgA AyQDYSQDAAEZAAAEAAADJANhJAMABBAAAyQAYSQAAAEXAAATwQ8AAMMPAADGDwAAyg8AAMsP AADMDwAAzQ8AAA8QAAAREAAAWBAAAFkQAACDEAAAhBAAAIUQAACaEAAAmxAAAN0QAADeEAAA CBEAAAkRAAAKEQAAHxEAACARAAA7EQAAPBEAAGgRAABpEQAAahEAAIERAACCEQAA5REAAOgR AADvEQAA+BEAABsSAAAcEgAAHxMAACATAADVEwAA1hMAANcTAADdEwAA3hMAAN8TAADhEwAA 4hMAAOgTAADpEwAA6hMAAOsTAADsEwAA7xMAAPATAAD9+f359f0A8wDuAObu4+4A7gDb7uPu AO4A0+7j7gDRANEA0QDRANHKx8rHAMrHysDKxwDRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADDBKGwBtSAAEbkgA BAAEMEobAAANA2oAAAAAMEobAFUIAQNvKAEPAgiBA2ragAAABggBVQgBDwIIgQNq/38AAAYI AVUIAQQwShEAAA8CCIEDaiR/AAAGCAFVCAEJA2oAAAAAVQgBA0gqAQcMKgdDSiAAB0NKIABv KAEEQ0ogADTMDwAAzQ8AACEQAABQEAAAnBAAAMMQAAAhEQAAgxEAAIQRAAC0EQAAtREAAOYR AADnEQAAHBIAAB0SAABLEgAATBIAAHsSAAB8EgAApxIAAKgSAADSEgAA0xIAAP8SAAAAEwAA FxMAAP0AAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAO8AAAAAAAAAAAAA AADkAAAAAAAAAAAAAAAA2QAAAAAAAAAAAAAAANkAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA +AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgA AAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAA AAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAA AAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAA AAAAAAAAAAAAAAAKEAADJAARhAgHV0RYAmCECAdhJAAAChAAAyQAEYSwBFdEkAFghLAEYSQA AAgQAAMkABGEiwtghIsLYSQAAAQQAAMkAGEkAAABEAAAGf8SAAAAEwAAFxMAADQTAABQEwAA ZxMAAGgTAAB7EwAAnBMAALoTAAC7EwAA1RMAANYTAADhEwAA6RMAAOoTAADsEwAA7RMAAO8T AADwEwAA/Pz8/Pz6+vz8/Pr6+Pj4+PX4+gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAhoADQECAQEAAwIQAAUC EAANAQATFxMAADQTAABQEwAAZxMAAGgTAAB7EwAAnBMAALoTAAC7EwAA1RMAANYTAADfEwAA 4BMAAOETAADsEwAA7RMAAO4TAADvEwAA8BMAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA 8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYA AAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADoAAAA AAAAAAAAAAAA4gAAAAAAAAAAAAAAAOAAAAAAAAAAAAAAAADoAAAAAAAAAAAAAAAA4gAAAAAA AAAAAAAAAOAAAAAAAAAAAAAAAADgAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAABRoADoRoAV2EaAEACBoAGIT4/xmEAQAbJmAj JAIABBAAAyQAYSQAAAgQAAMkABGE0AJghNACYSQAABIgABaQAYAfsNAvILDgPSGwigUisIoF I5DfBCSQ8QMlsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAADczAABEAGQAAAAAAAAAAAAAAAAAAAAAAAAAAAAtD5sK6APoAwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAADwAE8FAAAACyBArwCAAAAAEEAAAACgAAQwAL8CwAAAAEQQEA AAAFwRQAAAAGAQIAAAD/AQAACAAnWaZTuWVNTwdoTHIwADAAMQAAAAAAEPAEAAAAAAAAgGIA B/CTMgAABgbGv0ZaNuw6+Hel+9YN5MWp/wBvMgAAAQAAAEQAAAAAAAAAAG4e8GcyAADGv0Za Nuw6+Hel+9YN5MWp/4lQTkcNChoKAAAADUlIRFIAAAEDAAAAtQgDAAAAbOtqJQAAAwBQTFRF AAAA/////6ir/7u+/Zih/nyO/46c8nSL/6y76V1932F96WiG+X2Z6Iec015743mW4FyD22yM /+Dp3WGI5mmQ7JWw44Wk4qS7+7LS4ou5+87o/+D1//v+/uz/6t79+Pb/8fH/s7f4y876fpT/ jaD7gJj3dpX/eZT0fZv/dpr+f6X/k7T5tc//nMf9r+n8y/H+nOvy1/3/5/7/9P//etDKfuPU Z7yjkenOq/bc0PvocM+dqN2/Vrd8IiwmZ7x1RrBWdYJ2T61JVbVOXrZXf9B2YMBUktSIbspa XrtHXKxHpN6Vw/C4YWxdcr1JitRa5/7Y3/nI1e7A+P/yhcZIpNFy1/2s8v/j+v/0mtFPyPWE 9v/osudXXmVOw+dqS1E6v9pRcHVdlpmL3uTD/P/u/f/y/f/t4+tiNjcn+PyA//6a/v6v//69 ///E///I///N///QsbGR///T///V///W///Z///b///c///f///h///i///k///n///o///r 5ubU///s///u///x///z///0///2///4///6///8///+5uSq/fza8O27//3Y//3a7OixqaaB mZZ1wb+h8e7M//3n/PbC9fDC//rN//rR//zf//zh//3r1MyP//e7XFlF/vjJ2tfDLSsez8mn //jW//nb//C0W1Q5/+yq//bW//jh/fHO//jnd2Y+jn1Y//La/9GJ/OK4/ujE/teiz7eZOigU Szsp/7dualI6/6BScGhi/6Nl/+/lHxYR/9S7/8Wn//38/4ZL/4lZ/6yL/3lF/5x4/+DV/2o7 /4pn/1Qq/3tZ/1o5/2tJ/0Yn/zcc/417/5eJ/46C/y0b/y0d/ygZ/ykd/ywh/y4i/y0i/zMk /zgp/0g9/1NK/2pf/3t0/8/M/yEX/yMc/ycd/ych/ykh/y4k/zgz/yom8/Pz7u7u7e3t4+Pj 3d3dzMzMu7u7qqqqoKCgnJycmZmZiIiId3d3ZmZmZWVlY2NjXFxcRERENTU1Li4uIiIiHBwc ERERDAwMAQEB////9TZdnQAAAQB0Uk5T//////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////AFP3ByUAAAABYktHRACIBR1IAAAADGNtUFBKQ21wMDcxMgAAAANIAHO8AAAt 4ElEQVR4Xu2dCZycZZ3n6w2nxJmAyOpAi0O4D1FgZQRdd7kEUZiDOdBBdGZdDEmA7e6qeqve t955jzp1UVFnUUd0ZBZRFAPZFV2UhCSQcERQSCfhCkd0jZJG04nQIUY++/0971vd1Z2q6qrq gDCfftLdqa5+36fe5//87+tJWTMjNQMCawYG1gwMoIMZPJiBgdjhDB7MwGAGD2LFYIYWZmAw gwcztFA3E2b4wQw/qPODmlUpl4vFEv9VLata42WtWK1UqkXet2rVmlVkVEoW3xUrLBWLfqlc Kxd1f9Wq8LNWrtZqvC6FxWJolcOK3jR/1SjrR61SK9eqZe4OA7/g+oWC73iF0HcKBX66oR8W Q88PSlzKJH4Qhr7ve0HB8wtBoF/5wQs/5FXglYIgLJTCICyWy6VSpVQuVyq1XkxgPWhMC9Vq mafjP1bCT/PspVK8ArOAainibVZaLPF5ZT/0g4q5jHXr7/wQDCpRqRRY1ZBr9Xu1VCnXSjVm 4hmLlbAUea7Pl5tnuG42n8662Wwm4zj92XTattPpnMNsnu/xBUS8AqAKvCD0wmLJL7JPoV9i lsCvsvzAisJKiQcCBuYjOoZBAi1WYF6N84NiAxzHVz8OhhpLFBiqtXIpYjPqe20+Or4BULKx oeeEYbVWqhZL7BIwqBUr1ZJVqobFasjK2EnwwM15ju3YjKydyacBQX86faVjM03e81yXb8/3 XQdI+KEb8e2HpVKxEDJXKeRlKbIqjCp4UALHLIOQU45qRWipzauWK9VqkVUJBvxXqlZKodYR VYtcUq4w4UTc4i1za9niSpanh0hWPgYDM3PJLXh5cMqAJHkkpoSegEiF9UfFKAQZXMcHGXIF J5ezbQckACDZgUy/lUq5fgAEimADkHCgCQilAC6YUeRfFFYhyNCKSiJh6IGHKbFBU41kl9mQ WsUSyguFG/HA7KcWDo4nSDI2Z6XG1hdB7ahYC4s8VCUIIl+faiaKiSceVb/gecBHL+uYlVzE 5CXQiOdnJ32/5DrZTCGXtbPZXDqXGcgNDGbSPFHKsp2840SeV8g7eRtQRBAEmMAQ1xBrKEEt QY3fvRCsZFcYYl3toFB/yppVFt8bH8ID89sY9TdlLbVKpSyar9RqkHyRb/YlpkCuZ1bAajai Bgxsh8kgmxgyYJR5ZeBaKYmkICgQrwpbA+cLLrTgurbrpNMZ2AEwyOXTdt5zCwXHzTm+4zqF ogcrgTYCFs3wqiU2oswLQFAqG6agBbSAQbwHEFGlBqsvAYOKNshwPb4TfsAqIAK9Cd8Tr58E CR7a7CpX8LdqBQ4KRxjnQg2Xi+S1IRM2xTBQ3tSOVaKoyHNHJT9wMrmcFuzY+Yydy8MaYjzI Zu20uKbhoIUwdAPRA3wwlEAoVSOL2yMYDG9ADRUgara2I9EwdpHQfVwuCE4xq2gxAGIdBoJE xB7C8gzGT/5c2IThNPXJzEuRQS0C+qy+XIyE0ECx6GYdO1ew7fwArDEjxmhgMGBn0gPZQRvW 6RUQCyU/RETAC7SXReipKCQrWVGENGBG3u5EMkrgiaWzjVVuAhvY75gnJmNsU5vx12posCRZ W7UEjypH5bAZxLgsQNdosicJIlli5TD3GoIN7AbjHb/g2K7t5OyCgUE63Z9lpDM2xAAlQDEO zLMAKYD9yIegIhSwIMpiGUYFP+8EBmbD9BCssIqyYnaP1+MwaI9HMfvT3ppv5DQAAQboV5MA AZC9oFjnqjHV1VlnDEURJRsBX0BOIOx9H/6XLyBQHD+mBTuTs53BtJ1zPDcAGZCQYn8whCKv yrBjsAjhEEZI6VhasCbJ7q7HBDxIJFmLaUqTQCQyACWbDAQw+9VCWDM7D8sApcvIOIR/EDo+ fM+2kRCZrIFBJj2YTmcHB/mZzhaQM26ALpk3coGbQoAPGMWUJGbQVybLsRaQ4JPLoB+UUBTX A3lKxQl40B6CuqU505kItJrFQ6LXtFLaDG80qCS+CzZAz1EVUesEKESOF+NBLp1FazQqg3ij 7wIFvhAGBQjBjbyiJKVUtaKwKWbOHelIFkLEyAW01zLMFOW/Gz9SR0wX1o8Uhdh3AWkMKxgB AhIooDGhRYfScjBLgAF6QM7OJbQAArjpbD6Tz/XnAEIOxuhLNwoDWECxhGqAcg8tlCuI5Lrq 0wkd1KRLIa75EUrKB93BoJOPEKqgREZNYGBuNwIzwYNYEos5wehLqIaBl4/1g3QGvdkGFzLZ TD9C0047qI6FGMNCL6hgNYAC4AFGHdab5oy53VTIjBCFgWJgyJaBiyBTu8KDqT4h+XulEvot YcCKY22dbZCyFEk95zlE1LA5N6YFp5ApuBkPWpDCaOezGSfrGpPRj3y4TTWoonIj3YRQLUaz P6CuF+GiRSwCQBHBipilcxjIahw3ANqCo+ph17S9QjtmGIyoMZtK+cxcjDAPvTChBSRDNgNL ABVyfA1msCkLLrZibHN51QB+io6E/pp8Esg0FSbwidInkWjQguEHsJIJcqHDbZ7yskoJXt9o hE66Q+xI2jUKKZyhbC3ASJJnAgIK0UKMrmyjOef5RnFEQOaEDDk7iz3pBS6KQeRLTYz3ZBza U9GCQFDmbrcM+zEatxALAdeFfjDl6uMLZCHCrtsNpJN8FfyLIuuKVMpjX4TXCEwDAwxrHwvC YemgAoRg5wYkJSANz0VJLxqjYbIc6EA5kFhEW0UkIhTLFWRSl3KhQxiEtSL8oMOLwQVg4CcG ivBZMAgL+bwTuHk346JIp3N4Wzw4Ql4iAmUJ8SC7o2Hfk+VPJR2hllLJRxJjbsMSKljx3egH jbpvO4DjMEGLFKdpNeqSDAvEYHJ/KoXKYxDIDMEgYMs9N4+W7OTzIgPoAWU6l0Z39gogcjUx Ss0d4iyG1U5FDahG4AGqaSAPCHQBb5lAC+13rnF6nrLpiN8XDBrccO0NWnhgOpUS5Yg5oTsY GFgVdpuBS4pRKOTtvO0UMJ5dN59FYYIdYgXHM09QDqYEgmgO55Y8BTynrC1uif1I3Y32MBh/ rilnRV2yrKtSKSPgq/JRAA1mr8hhiR0lZ1vaRYe2szgRPBviwKB2+OMUUyOB2QjUjyiILLxw SMFCWMyhFwRw3mKEllCNMOLhw7FsxNtnNJc280qYoKSj0STY2uxaNjR5uyOgxo4Ny8qkUhOu ZxaYqjxG6Mi+PI7OILIBAZHOD9r5tJtJ42CLdn3eZJbrL/mnmy75/Kc++NWP/WvhY1+95JJ/ /Oyll156zecu/do/X3o9/osyjvEyGqJxBYWB7H8em3uncsnq73JTxLjWHA9qn+8OBmYq0HIg lUo4qKwZM7ssa54RZ7o87J4PU8ix/7bvYF7DKvCtRLvCOTFRP/b7D/7D9/71km8s/s7oP33i q9d8/fr5N//omhs/+6P/8rEf/W/UgRqECjdEYUQ5w9E/piNNtXFotGImsdOkBQys/9GKRtog GE8ADNAWxdGIXkh7T1lYlAABvy1AkKMdXQHPIi4GFw8jtraDo3UX0Rg7qizvG5/Y/p8uuf7r /1D94Deu/8RXL700qF7z9VuXfuzrN3/v67fKhxNCCZUIHVuuWDxiiX4wlUyJGQ/uuxhfWqz1 f8bvy3E6JSdouMDIhYQU9TmGH8AZIkMSYt0QNLwgn4Mz2m464DVeF88NJ/lNgCL393/vmq/8 n5sHv/PV//v9G77yvX/77Pe+YN38/bD2nZvdm7//BcztMPJkexV9lHOMrjFduRN+AEvwUPHb wABaiGllKu48EULggaubjFyIdSRMWuSrZfxtAQo+7kTCMo4NFsAREROokLmch6NGboD6iHcy XPy1f1l8U7V/8eJ+68obll55Q6m68GtWdKNTve5aGc5oBrIW4IiYzsYbPa4nyuM+xfYZJtoa D26KGXxb5tr4CcnT26kUHrTYw6sf4omyqcBTXMBIMrhxkfAa+kJIdM4LMKJxqeFiAy/xEes2 s/yETfZZffWdiF+MjyqMVkECOaEEDQUF6zAoozso1tbGKAI+RAtjptiOFhLG1Aaa4Q9/6CfL N7MhTrxxX5uZXQE83Ao8qrAVxoD3AO9qzrcLOO4lJfEtOYQYEG51//4U+xeDhTgqgrVc9WG4 zB+VjOczFmeaSAYsAbLJWm5j/CT5nBYw+EwHPPGm5auWrbqLrzuwkuORk67cMBIYKNJbgeRx L8QhlFLRDbV0+Zpt1o/aLA3KxxNTv9v4s7sfMQxiKqhWQKcp+WNLPPjMS1MlM9gP3LlooVPp CwduvGvVLcknwROBgXkC8474gR6maoUV3JK4z4tFhS5LVV9hvjAiFI27hWBTseRFkdegIk+E wK9+88KLv2e8+MJvftUWMOOPDQJiu1VEY1OMifut/VKQbuktk5SdXWb51v234SuLR/WW+xfF rwwt1Ic015QJXaE7y92DjV8qeqIGxGQZfcELXYKU2BGYlvAIeVYUEjdAM/pFMmq/2f6753+9 OfWLzb9+/nfbt7TjdY1bp1ixJusOBnKu6KY+9IO2XPXWe29snPnL98ZAwIeigPvYmExRSmxQ aARzR0oUdKFYPPwBTzvDJikBOy1R9cYe4JdbX/rtZt7V+pZu3vbS1l+2XlVz/0F7CTH5KcVc wYUp+IF/7+V9tdq3zZ4H3+W/MAZCoREP9NQJizKuT+QjLjMyD1DQcKKyPYYzoDuSmiH1SZiA lIB7EoxWiD8eta07R6ylsT0EEGojO7e2XlMTGMjl12SUTzz++Le9XX9owfu+1p4nPrCoz/rS 48sWLylatyxa/tjiqpVZcQWzQQv5+pNPnL1uUcCj5PMiyggM5AZRAkrB8XJh4BaIxHqokzAH KRh1HN7y0oiZM1V/ppGXtrREhGZ4YLJR6qM+a+n4I+ceOveIE1vDAKRujW/Wd+8kfrL8p/Ot 5YsKq/LV+1fwGctv40cDDBotMi1XtIl7Sb5MpQmNMyrIA30alyJeUUViC4QekKNEv+Mn+NX2 38YvxmBgbdvekjE2eeymaAAIDu3rWzr3KIDQYq2fbguDB0D8viU/vrG6ZNmSO8vWY3fyhOEy tKMW/MBwJnznmDZl+DQCsiHMrbih3MJyCooGAvkXuaKupf/md+IFjTBYuvl3v2m1Q01gYPKS jFurYcw98rhqba71p4cfdUorGHyhHQzCFVcxW+WuZf6SO29fac9apl+tu+bXrHxzflAnBPC/ HJoHibEzCVNJsQYGDq6mPPk/uFvy2UJJfmmNF54XL5iAB0uff6ELGDS7tHLY0ceIF8w9+ui3 t4IBzK3Vp1jWTXeG1k0PPrCkYC1ZeeeKoLrhwZ/sYVlLbrMsdGXZC2Nj0iysBZW5qbSCOlCc KuSpEZHGzZgngy2e5sVfx/9DCmPT/frF7mCwCzmUjj/uCMt6u/XWI4+d2woGbjsY3HF7ddbP Vy66a1mwZOWyFdasexff9cjj4R0/qFrcNllPbHhYGbeG2wsW8fsmC1CjopQOk5mhSDyiAtdb fMnvx0lh7KE2/74NDKYylXRr9bCjjreswyzrmKNOagUDpz0Mrnp09XzLenyRYHDLo/Ot2hNP 3n7HD4xsDFvjgVmtfiAbDCgasqUUr4QOUBbITyBLg7SeBJq//8WuePCLdjBoBZ4J7x969HEn 8cbco4/oawUDkLr1VLfcft3PVy+wrAdW3gYM7lpN8tXjT96+5HZ0hfa0YGAQcwLhATDQLwY0 Bg8KRlMiXSnnKIstwYMYBoYU6k/VAQwa5eGuS6mW5x5+3NtOfNuxRx7am1z45orc8kfuu7Hv gXtuv3/VymXA4IlH7swsQTj6bWCgxAKJffNAdS49xqxBibDkxnalSEGBhwQGMS1MgEFbWmic v/VG9s098uijjj3iT83UTS9riwfW/VfUbl18tQUMVq5aee/qAeuLNxSsVZcjIBP/QX3Oltgk K0IXYdDEYCBZkExeJ4+DJecRmJLxEM8S88QEBMmE3fLEpmvsO3QuSNAaBm35gfXgItlBtRgP Vq3u10S5ZfBxbwp7ofW2KEMOPwPcQGmcJrc5kTAvPJ/AIIaEmaKtbEzYzpTmIjpO7JhpsVMg devnZb2GX9XxwKgHyxdhbnUOg8nMWwF73MTQQYCfEL2RLKX4CdCRlo4tPgZCJzoSqedtVjDh Ty3WirLTZoba8uX6gJ8ktLCQ13evuJaf0MKYRd0MwpMeq+FX0gNJ4sXLJr8KDIGfiVz41XYQ Yexx9KL2fEe68iQwt7GzeuEHtb5li3mUB9fft/rR1Y/eAwzC2JYGD+xG2LW3vBqvlIWgDBZ5 nxENeBvrtGDJZpoAg5GXWqrKsW3ZiYbQ8OEtnrK9zWRZX773DmDw5EM/W7v+4dULrcLjsf8A PGjrP2iNW6Fyh2GNcQqrWIKyCcyQ7Ty+UymrQ9u5U0poyQ/a80Sm91c9WPtf9963evV9K26z Z92LTEhg0JYWWj0XJSaSEWSnVfEyk68kejAeag18KCl4QjxSv+3QhzL5s1qzhxZ4MCUMsA+e 2HPDrbfeessdy++97drE8w0rHfel6YGT/ZsaOc0ThgoC4n0m5kIYYpyqaluML+0X8qWlOvWl KSOjcXQNg/Y80UxdrdyyfNWqVctuX3TlmO8fWuiRHyBUlAdIzjAMQe53RsMKevCpvvy0kHzC F9JfChs+DJ6Yafzsznmi7iIeDhbIYhA/qNsLna/FkEp3l8fk1fymtrZz64+BFnrEAzMnSiO0 4Bcj0vaicIwfdLOs3QiDtrZz82cicqUYCwbU+OgKD1TBgQPJuJRI6Fb+LuFETVuDUUyOD/EX ZXaTjkUA2tTDKbttHA/GlOtOXjRfUSd3Nr1mwnQ9z9LdjcIgk524W2GAEdzjmIDBPc7R7W0U KJqKsN2cr7zgxhtu4Ou6665bsGCBfixcuGDhFXxfeVV/ur+fHGS+stl+ChP4lyYD1Sb/lNSK boi34VpFGzATSpR7RUTdCKYq+AJ6k2ZCNnKJ7DNld4yPJFvaxNNMaVO5y9y8Th4Ud29j7vTU Ir6TSdtfQ0mOkmRIt8SZQGTSZGXDHCQwGYTUuZ8HUZmAAEMiKAtXOhYyldD2bsaD6S+o+xlI dqUkCP8KayG8oGQeJVaQXxKpLBanu5xQqmglvaek7ExidophqrBKWPSahIFh9mOZ2qRUBBAC G67kFdIJihasHm88sQYqbBuSWROkTFQ/BexVaqmJxmTjWEFm93vxB7ijrl2TFqv8LSWjk7VC JrgpWYvJQFFI0ruRnfyNEnXVbEscolaZOl8TxZkAgz/AQqbxkeNaFRX4qhllcRXy9eRvw71U QQewSJtWKguAgEsBF7KQKHsgEUnV0tRYkosj1jCGB2OOy2k81yt0qyGDujEDvqvkU1nvJhne UhheqVoEJEnGNFH7JEnDJAOjEYAEZFrUcD1QakqUsjdd+RVabLuPqUsc+GG8vxIM/EDiARbQ nW03ldHGopI2DVEgIsjwYlryqiRKRBANtDCe0/MqWGBXj6AcfJWKKWMlXpLQRMW/oL1cK/jb qFAtFwMVLaBJqKIQ8ZCEp0yWeBcfyMwwnoZeC8NJSMvavCn57DGfFEDl6r/7q3Ll48F/+69/ 9eEP/+2H/5bx5/XxFxp/+YG/ZPzFBPdBZ89TT92PqZtUfvoKKBe9biHwvwo08CuEgQr5YBEY EkhFrUFVthXYAcqBqQSpw6A7VTN50PGbRnjnv3cyx0vNLpqw7k5mmf41RLNVz2Q2NIFBtbtZ xx96dGRkNPntmu7maLj6DwADyohM4wtlLCQwGPchLbjhxhuvk9ovvf86VH60/SuuuvKqK/nq Tw8M9PffOJaDt2VkZMfo6I6REZPncg3vd+yfH1/2JycZy93Yzii+VOfA9xCCMDnIAb0xyeGC W8bBaDECFZVSC8lF6jtAAYMpwpTuPEYLrcsEm5AnfsNkqaM7Rnfu2LGT/wwMunn63QMDsT9x QnQeKulwsooNKX+nBljkY6X0hUJyyuXJ1yFhhUJkJEYZWaq8fbiF4W674MHUPGncdzo6Yo1u gRZicniFYNBgiJE9XDE9APgfJRHnovo0SD2Q2mSK4kldM9gQqdCsSlkLehNNKALZVahJfoOO 1EGgbQw44/6i0ZFNqc0jo8PbpwODySl9XWAT/UfKNcoDi6iFyt0yWpJRgVUoKHczlR85VUQB CKhCqY0aZHKR7ila8Rv4QTdWLn7DOi288OKotWXn9lQMgylzdZvi2HT4gelLpUA0P6ibUNsg 040JY0hORmqHVRxK0YMNTuBvrPpBGUSQ1lSjeD6Ku7yIFpTb0QUQGmjht9s2WZtGRrYaGHy2 2Q6edMLbTjy5LX1NAwZGP2YnTWZ3nJ4xxpRNwkpEgyklqWR9iAWFkWxnuAG6E3nO6kNFf4ku avsaljEeXx5FMmqMCgZ9zWBwwnFHHHnE8Sazs9XomRYQ8aj91CSg+0vSowari5dpcqK/qZZR XcncXPpq3Ewk6+uPcXGnLCmyl8pErLvTE5NVjPvQJ8CgGR6c8FYB562HtQPCNPBANhKkD19D 2Ekkmp4zJq+T0ih4INSQcSkNzNm0KSNED1OIHKWrRFjSCkuYZhXQgmkUN7U4GLuCwFDyestw /GLY6Aef3YUfvP24OJp0wrGnvAx4kEw5gYzV7aP+USJv2jgF6jdDlTRsQvlr1IuLPaq9CqpD wVNFZReLTy4ttcjR35UWTjiGFGdS+o47tg0iTC6H61AusP/0BioGZHVLMhYDDAHWWSsVoAcV cKoLXlQs5Gmok/UKYD/ckII+FedhZmJW4kOgb1lvvjR86E0BtwsM+o4/6qjDSWA6/KhjTtjt eCCrKfYZICHh61J2DDYLq9UwCQWBzfdz+Uyaann1E1MTIbmWEAxKdDY5XKpO7wEPWsFgVx3p sCOV1XjCUYcf9TLgQexThBVE6otDWW8kOGAh4hxQnInuNHgLQm9gYDDvypugYJQyNsQVKKLF H094rkdaGOcHEzd3V1o49JhjkYtHHHPMEUkmUzNs6IkW5MFHG6yiIquvhZwhKrpDHNRYuCr2 5C0wwdjBwS9m6V5G9xOUJOIqmMsoT+iIxsuippU94EHn/MA6DAQ4+ZhjD4/z2ZqPHmCQhAwa 8ndFAzSHUV4GBaLUP6nBn5oHFWg1dS1xHLlP6Efp00PEJPbqh1Eae4MBdnZTMdJEP+g77Jhj jj36iLltQFDtAQbKP5GRBM7LVSPal4fQtPPU7wq4ikBkSZauSl+d9vCpqeUeDQ/Vdo0KEHUl Vc8+04Gle7nQOS0w91vmJkmNLT/nnzu3nWPQG8RXFT/N8yhP5Ftd5OQg1AujN2JBqeoDrKgW M98coFsrbdVU2AkJoEGoAQC1L8KJHvGg1kIu4EdqstA+Rls4Ty4B6kA2qseWUIBlSgmoKzjq eFuBH+BSE1DEAGnsls9l2Pli4KqhRME0J3MDfvNdIUPQm37QIgej2tRemBrNklLxsQvbwUBx Q5UBq5UsHcZU5wXCmwZLsZSIDQaQQV3xwIrQq7hUyqvaXVqRmvNGrum5pkZ1fqlXudAqD6VH GPTAD0zXOVVwmM5jcVo3bT1kMhuSCNWrS173wLbpWIo8MDqBeIGHbKATE0JCQhLy6A0Pis13 qtacFqZEhC74QeNc6l+ahJV429RqgxTYz2h+0ATuMxgFZeFqHCCxyEsnR2dnNQ3Iq+ghyKnP lN8bDJALTRfWIx50wQ9M00HiR4qV0fSrIqaGSWB6ptFp2NTK41wEIAq9EXDj2mKgsDxRWKrC 4rhLIhSBjgqGe5ON3fHEKfGgG36QTGY6whqVCAvJNNwSFiALlFZBohH8UA14y3STUg6rp1iT 2msZHdkYzaIGNezmzZ5kI/ygmcdlaY+0cEPnspE9g/UpUkI4DWkgIzFp7Ji09zH+RDWVpPBH QTjiS2iFanpA9xcJQ6xFGYwmDCdY9EgLLXjiK8MPtPsRtgCOEGQgrW1wJspkotGRmCMqgmJv 5DEb9qhOqyYaqdZaysxQEb36smEywhBxJPUIg0oqNSmlNUbRHvGgG34Qm4Ym3cdUNSUVuUZ3 ksSk640EhBAlUgorC5c8lMkYMwO5j1TsoGp5IyV6hEErXblHGFzbOS2oibDREIwawA9RhmEO MWwkJOkjLY1Z8ROZxvQFo+BLWTdxF06MRpPLSM0L3dzp6oss6UFXhhaa2gu9waDWBR7E+IZP 2JR+G34QZ+bEkRX5RtTSRGkZlP7idqdxr1RpWloanJDSIMmAO4VXhByEIK8CGFid4oH8JZIG pjGxACAwAI240Fs8waIXiImyqNU5LM8oh9p0kN4EE9QywJQ6gAaoCxFY0LtcaCrwesODjmFg 1CC0YWXgKpwgmcCIuQNmEmAQw0QnMAHHEO3AdAwV+1Nvc/ZeHkQCb2pcLkqgvQq97HvFg6Zh qc91YO00AR494ya822oWtY41DS94oX+knGAVqNs4PJAkZFJvwHTcSrSHpLGLuCHMAASgW5zA wdEB5QBXiiEFozFACMRceoXBmO+28el7hAE9JDuAgek4ok7KprG3wX9pSKZjU8Kd0IwIIxNT VcNt4qqQPkbiu09/79nv+wCeMzK6DQroS4AwPXpNRWRvPLEpLfQIg854ojEOpAiK66EYK/cQ GOiUgHpDIAwoJSMpM09HJJCUyavT//MFl83/0Fnn2xhIxQAHolGWFWkCGESko93ME3uLN3ZI C3X/WYyCcf6U/AQ66EXtEjENdEaIDn2hAxRtY0lD8oJ3n/PReTXrtDPP+yTJiuoPJSSQhqzj bejSOA2eKLLcZfSIBx3SQozwJg9JPTSlBooaGnpVABE8aHFKhrKUChxx8d6LVS922jlnXni1 2pVLKaAXKXJBPhSUZ5zuvdJCsz6WS3uEwXjryRiqzXiiiSTKGBIZqKGcSToxXc3VetxoDViG iq8BHLwrohIQ/s/POvfPcOufdsY5FyygHaMMaqmKqgyVnkht6O7VkWovIwyMaiyprz6WJrIi 5zmVjSZNF0UYGaFScAEKEleLFHlOP/6PZ5155oXQwllnXnQ5lCDHkVk8TdjoTMlpJyBDr3jw SstG6cbSB9T1TZtuKt9jFdnwCVW4GQFBiz36suuQEKjfCxeedd6ZF4IHZ5510XzyMWwtXP32 CLp7TlotnHuMsYCtCJQm/KA3njjYkWzET6JoEsgMnht+gJWo8LKxG9Rj0ARbBSpVdaAryT/g /fV55wkGZ5x52afwKRBYKrhK0QzoPAhTyNGPsGc8aNrXtkda6O8IBoqhKbTOP8WWIHfSq1SR oPNoipxFYJyLcdECnI+0VJ1tFS648Mxz3vWO/3jmxZerQ4KaNsfHPOmUNJ0D5jm7lSda1/em J145NQyUhCyfMaox1TlgAT+kJooCZBKRgU4CHmknBgfY5rTxoGIYuPM/esEZZ13w0XmfolWI znuhLy2HetB4Ts0HgzyGRK/8oE4Lm0bI1n2OhByNHmGAXJhghjaDpDmRTFU5GIIKpKg3tNKT QQwlo1V9ox7JjpKnhDw8lfmhFdEqcuHl8+ZdPp8O1Tolz3PjTs30qnZyLg1aTZV4b3rimK6s LJzRbTFv+Nzu5geFL9dhHdtF3t0bvkWsPPaeqEhBvlISUGo6w8H429V8k+MfqP/WGQV3/OQn P3mArwf4+cATy79EcpJEgc5A47gfveRouZ5hUH+250a2Dj/3QpKOMo4HJ77zne9qn4jVwFHR kSaYHwkeVAsHHXDgAbNM21GTKONtmLPffgcc9EPloCEdjQMBgRCaPr44C/ChyXGGnoiTDM95 4ZbHHnro6TVrNq5Z8/BPn3r6qZ/exdEmThoE4HQ4WpI6A3lfbfw7xoMJTtTxJi6pbSOk6v4W ZBAeJE9/0unnXnjRued8oJnsaPIe/GCCqE1muXvOG/fbe9br59xtZCG+wVlzZjH2nvNDyUNF 2+U5lMNAyVcABAWIZHQlXnCAEcrwHY8+uX79uvVr1/I1NPSzoTVr7uI4BxpUe3SphgxIXaS9 Vq5Tnrhhzuw5/2HD2PNPhsG2BAYJLZz+95fncvM/0ikQkAtN8MCfc8CB+1p9b9hvjgpTANKG /e82ocvZf0RpjuKupFzJYYLfpFr21QPU9FDHolJEOQhptHDfI+uGhtauX//I0NNrh9auvP/+ xV+mcbnOtqA9syPCgD12CIM9Z+81a8+9Zr+pDoTxxhXCg9GRbdsbeeK7L7Stk8jBOvvczgqw gUETPNiwPyCwqocceMAGVoa82/uApdYhB7953wNmgxmQA9xQBQvKTVbaidqTy3MiRZGURD83 eO21Nz22cePQ2p/9bN3Q+p+t/fGidP8X7fQXadlOnzky1XIFmlUXOuSJe+xzd40NmDW7jgnj TRtS20d37BjdbhhrLeEHZ5/7jnecP98qnX7O33REDU1hsHTW/vv2HfIG6w0H7j/LeJHDff6I fph91h77HbiHORFT5oEsBoxg1a3KVUS9SqBY4h1PJOPna4aGhtatXbfxkfVrhu5/PB53cbCL WvkjHTjtJtsRHpT3Yu1vPvgtb34jT2HGeJO34eHhbdv40YAHp5x9znnnsfq/u/CcD3UEA/ps N+mDseeeVWsDQftZB+5pYuz+XnMOPuTgQ6y+Pf94X5GOcSbKnwgeqL000IjEGOQpfeLJZzZu 3Pj0k0+tWTsENazbuHHt+jVrnjLj6afuuYEz8nRyKkeocrpFR/pBdrbJH/jh3gfO+XgdBrZ5 MTxehiEo1PHg7+d95Ox3Wdb551zeJitxHDy016qLmQTC+m/WQfEVb9l/D0pUIfK9997jzXvN sqx9999AUFUudPWYJaYYh1cIsSlZXRXM3330YZjA+vVD6x4aWrdm7dMPP71x7dqNTz899Ay8 ceiZ1Yv7zQGqOvaJc386woO7Z+tRrL7yPnMS3pVKZc3zbQIDnh0RHgxLS0pg8KH3WdZ8OuSd fgEt4joYwGBCZXYsF765z0F/8id86utnfzueY8lBfRKTb3nj6wsm9Y4DbU3JLvnHNFFUKEGe 8qDkBg8+8xDC4P9tXLdu7ca1Qw+tvHf9xrWPrB1a89RDa4Y2blz309sGadg+OJBxOTjSdoD/ 1DpSOPsQy3r9wXy/PtHnxpvA8lBxvjajzg8GL/wzdIOT3nnOvA4AwCWNslEiOJGN+77uj//4 oEPeBBqYI8mqlb3nvPmQg98ES4z7sJNiYBzMkTkFEI+CKeFifOuxh9dsXPfw6hXrnlm9YuiZ Hy/KP/7kUytXPvXUj2977MlnnnnmqTuv/DSL1wEvwCIddAIDa88YLd/wuj0SLaGOB+btrVsn wcCaf/F7Tz/9Pede1mFJPzyRvRgfggHAjvbYa/aBr9tnDw+dB/0vsuxZ++y33xv3urvCqmnH jlw0VfYqV5PNjOWk8GNUXLLajNuuWLX6B3yvuNJfcs89ixbfd88PFi65Z+V9K++5c6E5EC+j DgR2uiM8iA11jbpa38I2Go/Jn2Kd0kV1UAubqSZhNCGVScn55uDNDgbuV6NO9MUPb/TrGrNJ uZw8w9S0sOsHtrIPe7MbJzvPepylA7i0umQGBh3xg13A9+8VD3quz3yN3jiBCye/vEaX0vNj N4PBNFjKa/7WXnjia37RkxYwA4Pe5MIMHvx7g8AMHmhHZ/hB1zDYNCpvyaa6rThtuthmqkN3 y3huk7XluZ5m6hYPUoLBtu1xZGl6Q76XkZ3PJR6Y6c3F3TuHLfoxbBkd7RqsPcDgly/sFhBY OGTjYeA63UEfCimNwyMjXc/WNQyeG9nx4i+n+8Dmfi2dnYtfTHds2Tny3PD2bcObh8caFnU8 ZdcwGN6qx94dY+RZ69mdzzITL6Y9NkMEozu3j+5MxQ0puhldwaDBkTx9QIxACvSTYWyf/mRE v9WVZMfIs8NdrUigqnV1B47k1Ii+8Cd3A+im1z4rjjg8vDX13G6YzNq8M7VJsY5N3cOga/0A 2k3Ci9MGgmVt32pt4ly13TGGR3caLB3e3NWuxoypywcABpt2JgkHXd66y+XDo6kdO+JY5fTH MGxgZMR6tusV9QKD50Y279yxZXcoCNamLakdqdHpk5UgOLzj2S2jO1IjLz8MNqdScLBN2/is aY9toAEbN5rqWqlp9tHDqS3btyFhRnd2/WDd0sKWeNd2BxoMK5mJsXtw6tlkV+o9WrqARLcw 6GLq18ql1RkYdM8TXyub28VzTtKRenZVv0ZvjCE1uY7mNbqYHh+7GQwC5agQmabVnNoKmaPw OEzZz5vsX1UHqIEv6YHxUIllF0jXxaVxpNs0zCXTQDXsqmgPVc9J1R6JeNQ0099JxXvqeaUS 70iZ/PojvW+UuOJH5ONmv/3uU99z6ruvGHSzV/Qr1p6h+X/GVooiGTkFuv53ln/QxaPvpkvJ vdNxtqalGYmXpnZP9Tmq16USqUyaWskrlTizkYxc0nCDInvlRY7rck6VOa+KhFwn8JyBz5/6 /osuuui8sz6TyaXTA3ZuID1oD2SyaY4/yHJgOrvsWZVO5UKzSvfdtOIJ02inSTpV+xYqVWhm o7aoavZCoy+V7wMIatmr5tgR8hBV4k/FblBQm0iyTv3QzqkHEAukSVrOPvWieVdEV8+74Nyv DaQZ2cF0f16HPgw4DliRz5Kg16Xd+HIsetKcbLppC6q6FPLM1PSIPmfqa0A7Gx14TUqKOu1z igDn2Kp4nyMLXdPXIsw7tLnQkZ6c/l3w8nnb+8D759VOOcnq+8AZX7mqf3AgPdAPKAYG+9OD /QPZdMZN56jte9XpB2RgK/2WUh319jGdbqjfVE8D8COMavHpbPQAVbGuydAH811oATpwgQgl CeBFSC4qCUf/cv55p5106sUfr512xl9fxe+OktHsXEaJyzk7k4Ng3FcjDMi2AvNpmw066EgN Mu7U+tMiDVe5qJAGvdNrLgySwpSiMpPJPjeneAYqTIgKjm87RRKTs577rfed8Z73fmSh9fZT z7h4IUm6PhBIp3NXK1vZd/L5tJPNU47SKT94BcjAVHGy2ArrZtmgg07UMH1uSNdVA0TyrkhK hxro78P61e+G5GyS1ItqeGVKFgJ1ufC8HKd6Bnnn/DMumleyTjz7vDM+ei1c0bEzmXRmALaI fHDMATF2FzzxFYEBH6I6XWp1EG6mik0bb+p2TatMZF5UUd9DWkGSlesELB2W4HkliECNvzjZ 1HRUdul8QzLqpz95wTyaYvQv/Jv3XwazyOUQA7l83iFdmUom0vOcrP1qwwMqVxH8pKWaimwf /idUYOdpfkUlt2pUSiVPwiIflVi9ClXpeqXafrogeRmVKykz3/YGbZKRnfzVl5128sknn3Ly Oy6ej1TIeKg//YPOQDqfVfp6wfHyLnnCrypaMIUKVK2pD7p6oaliyxy0AzeQpFACO8oPza3g fpHq81yOYvGpYi+4bgGMoIAFhKCclbT0XCGXsxec/973vAeeMI90TNv2cqTuc6mdzpClm83D Iznh7dUkF+KmHuAuGZhqgqWfOotMPcTV/IAXOocMMolghWgGSElVa8IIQArpsmgJTt4F4X3p ujklYc6fd9lHL7tsPoSRsbMeZ0Jl7UxWqcr2QDqT5crgVacfkHVK8a7Zb9oDggpQvinUpzJB beACtUVUtXacl6ua7YC6ZR3a50QuTZNBDhXuZWguXci6duZL//bFhdfagZ/LIgwpXYEDSCIa FSmT8zrMV36luOEf7nNeZfzgDwKIGRhY1v8H5WlhJXQul2QAAAAASUVORK5CYII3SgAARABk AAAAAAAAAAAAAAAAAAAAAAAAAAAAPg0DDOgD6AMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAA8ABPBQAAAAsgQK8AgAAAACBAAAAAoAAEMAC/AsAAAABEECAAAABcEUAAAABgEC AAAA/wEAAAgAJ1mmU01Pbn8HaExyMAAwADIAAAAAABDwBAAAAAEAAIBiAAfwk0kAAAYGDBY2 Qww8Mmg1SqzKGJEIvf8Ab0kAAAEAAAB7MwAAAAAAAABuHvBnSQAADBY2Qww8Mmg1SqzKGJEI vf+JUE5HDQoaCgAAAA1JSERSAAAA4gAAAM0IAwAAAJI0XAYAAAMAUExURQAAAP////eIi/ma nvurrv7i5PBrg9lcf9xnh+J4mOiVtvvH3/zh/P7t/v74/tnY2fHQ9NHH97Wx9JKm9niR8qHX +eP8/r35/fr+/pCRkZ2fnoKEg6HuxHvVn97+6WTDd9f72PL+8mNmYz9BP09QT7y9vF++Ucbj wXZ5dSgqJ4WWe6a6mfL+6oPMUJjcZURPPOv93pOkg1BaRjg5N7/yhhEUDWt1XdvvvOj3zfb+ 5iMkIW1ua6awi/P+1TU3L9j5Zur+ql1iTejzwfP9zvP9w/j+3iAhG/r+4vr+2vr+zvr+1vj+ eN7guP39n/7+yv7+zv7+0v7+1rq6nf7+2v7+3v7+4v7+5v7+6v7+7v7+8v7+9v7++q2trP78 xI6NcFBPO/76yv76zufkwTEwJ6qolf72vENBMvPst/750v751v762qCZbLmyin15YZmUePPs xMrFpaSghv764mlkSebbpomDZf70w9XPr/753v765ltVOq+leWtnVf70zP7utOjizZGDW/76 7mVXNYd3T5uNav7svYeBcoh5WXlsT/3jq8q3jdjFm6eZePHdr8q7mf7swvHhvP7z2kA4KPbh t/7sxvjmwf7w00lIRv7mvGBXR+PPrHhuW/7szPPiw+PAhLSacZaEZv7itLilhkxFOenXuPDR ov7mwvnmyRoYFVlHLnRcPcSmfmtbRv7ZqK6bgsKuk/jgwP7mxrWmkfTkzsSVW5p6U6qLZr+d dXZiSldOQ+3aw/706Kh/U4ZoSPbHlM2rhf7gv/XYuTQnGoRtVejEnty6mKaOdYx4YywmIJiF cv7lzFA9LJFxVLWQbZp6XV1KOP3Oo9qyjP3hxvTdxz0tIOKqfGtRPNOid6KAY/3n1G9LL4Vb O7ODXSYcFMiVbe64jvzs4FIzHpdpSn1cRLmHZxkSDvzczRUNC/3MyvACAvIODtsNDfIdHfA1 NfFPT/Zubvi+vfzb2/7t7f709P76+v7+/vr6+vT09Ovr6+Hh4czMzFpaWhISEgwMDAICAv// /4dQojoAAAEAdFJOU/////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////wBT 9wclAAAAAWJLR0QAiAUdSAAAAAxjbVBQSkNtcDA3MTIAAAADSABzvAAAROBJREFUeF7tvQlc U3e6N+4BrLYzt85Y22EZb+cFsdj+W1+1deaFjr303svcO1VIyJ6AggiDVSwUDR0hlKsgmxCE gAECsoY1ClIBGdlBMMiOLFagilq0CrgcQNR+/s/zO0HR6nQD2/f99NSG5GThfM+zfZ/v7zlh HvX//DZvFhHS3/isWzfGYBueP4u/5Pt/1BxCvGkwev3aVdyuj+j9hCjnDOJN/etXr4/qjw0P DxuMjly7Nnrj+5//2XnHXEEcu351dOyWRELRNC2hqBt616/p35qdQ/6+nzJHEPWujIzdfhib tERyY/TqyM1vRuv3Pd4f8Po5gXh79MroN01mcO36TxKRcwJx9Ir+k8728LXrN3+AFX7sW+YC ov4VPfDI22P6BroUM6yvPwYBSQ1ffYJxfyyCb33/HEC8cW0U8NwavXplZEQP/PWm3sj1K1f0 blM0ZfBk837rUf6oF8wBxJFr6I76V64a3By7NkrdGrk2fEvvypUxPM6Ra88+HGcf4vBVEogj V0bAbqNXhonlbl+/Mop7b1zV+1EW+SFvnnWI9Oi1m+CnAA5zi94VvdErBgDtOolPihq9/swr x6xDnH8Nog4gjl27MjIM7jo6emWMHr5+5dowIqTHrgLgZ7vNNkTAQIKOevGy3sjobYMreiNX hm+OPiCpN68Th32W22xDpPSuQaW4oT86qj//1k2dFW/fvH1DD/dgjF5/lvDwd802RHr0+q3b elevXLl69ZoBrYNI0XrXrsG+a/q34RSgHz/LbbYh3h4ZoaFCXNUbvoF5BljACJQLvSujN4ah UF7Ro/SvPuuyMdsQqZGRGwAF6gQ9fPXaTQNMN8Pzr5JyCNCv39J/5pVxtiHSI6PDABFTzvC1 KwZMutG7Qgi4PrjqfH2M1We6zTrE0ZEb165cGQHiBj/1GCtijaSp+SNgRYjFZ03FZxuiBCo/ WOvKiP6t+QQiWnH0yshNUAEgRA2g9j/rpnG2IVIGV6HgX792nUAcZUr/CFjxJvT9IwbUrf8H 6uKNa8BCb94AR0WIQOBGrhgAX8WO4wZ46/A1/f/rrSgZuX4LBRuABNSb4agIEXbgTr1n3/nP uqNSD1joIxB1OebmdT3sjZ/pNusQ6VvXrzP8Zf4jViS76J/AiLNO4ADHGNMT0mhF/Sv6UDSY WMRSef2ZR+Lsc1QEMso0GwBxZBRjUQ/uEEe9OYLazf/16QaQ3BohGMFRcQOuw1ABQIi5BpPO M91mPRaZKESMN4HlTG+QZakbIOL8BAjnIhaJva7o3QT55sE2StGgFGPj/6xtODexiL4KzNtg vsEILk1duz4CWtzI1ZFn3UXpwmFOHBWNNTxy9bqewdgwLE2NjenBA4NnXhDnGCIWD1hevHYd tmvXgJ3+RMtScBxzZUVyBm8O64Nko6c/9qz7p0cy9pxCZH4TWWR8pmXi0V82mxB/Qhj/7Ff/ AvFnapjvdVi/WPF7na6f6Yt/seJ3Mcydp7xowsjhkWcmDb/Lp83+a2bBig4Hp554XON378/E aG65ZuoJ5XHSwXx89mHN/MRZgDi5YsWTMRrPs5rxqxaZzjv4GJiJO+YmlvPmGf3sId6x+nrZ xMSDwzScBBI+iaaxmDcDOk0ZzzN7+Cry8kmTefPm3Tto/vOC+E0qNml0b172MjOTaQvddjAa pxzuGVGGd9dMzPRMi68tHsMybrXu4DLTqTmmdz/KUSeNpxxM1ty/fy/73n2zB3AWWRpT5l8f pCZXzPRTanzZPQuruxYzk5ODzdSk1T2zp+WrWTLuj4JIW4CjfW1qvmhi3JARFsFq4+aWVpT5 PYsJB5tHgmzS8p7Z/XnzTGccuOk9kxVff20yS1Ce9jE/CiIE0wrwvhmOZrho0mGZ5dQikzUr lh00M575W6cA3zwb0xnhOZnt4nJ/3n0rCN653H4cREgplo8eoPGaFXct75pZmFnOO7hiBkTa 2AUQ3n0k9RrZ3Jk0m7duhencVo0fAHFmCqHX3H201k3dzwaA2RYrzM3uHnwA0dzE7Gtw6Qcp iTGamQU49H0HK7OfH8QZoKbuP17UjJYtWzPpYLJiatL87gOIWBwgDB87GzaLxg/Ou2+y7BF/ nn2X/SFWnHGkVvcer/r0orsrJimj7EXUxAMr0uNW9+bNW/FYVbQwAyMuW2G67LH9sw3yB0Cc cQgTK9Y87mTj5nfNJsaXrbhDj5s9yJU05WA5z2LR1KKZ73WB2mJhZWNj+TMr/Y+eYodvZvyJ NfdNadrU5g41bmb6cMRm6t79KfM1lsscHpjMHGmf8f15lpY2c5tSf5QVJw7e/0bZnlhzz5ym zNeAo5ote2BiyJzLJsYXLZv39QrgPmSzWGa07G42JFmz7J8xRId5TyjbU+B39PjUJDV+0EVn MsQ2D91xArmCEYnlyTVGU0b37gP1m2fx84U4afk4ryYEx1CXjiYO3mOO/c5dyDVMwaCB0DI1 wnjF5KSRpYP5inn3vl5n6jCHdeNHOOrkXcgp/yT9QVQybjzpYGT+INE4rLmL5wDT7aTpvYNm 982mHMzmzbOYO4w/HOK4kenkP1WAb1tl615Az1yPmiR8/Y7pi4DT3GqZyR2anjC2/HrunPVH QJz8tibozsP0+Q1j09OQmLN0x3juiuMPhzirFZpMsczR9sMggq8Zjo+PU+MTOsmJRiNMTGBA kZvJyUl4fnyCxv/xGcg0E+QN8CzcGI6TF4+jLccnxycn4G3wFgo/dLa3HwCRdjAxNjKnjU0m 6SkjOMY7UAfh0Ti1yGgRPWlkZGx8x9zY3NxqatzE+PYdCwdq0nxqynwc30CZGwHYcSOTiUkT Ywk1Zb7IfHLSxMHEwWjK3MLcwWjS3GImAZodsN8fIm10d9GksRFlbDVOL4JkTxshiZu6B32j 8cQkpI9FFlMOk7TxskkJ8nCzqdsmxuPjJka0sRVN3XFAhzSyomgrE9rcYoI2t1rkMHl3EZyE u+PU1B3zu7Ofdr4/xDvrkHlPUsaQ5++AcSYc7kJVX2S8BignbYQiG3rjFNAb2tSYppZNTZnB 3SmzOw4g3aDFAaIF9aKFEYU0nV7mQI1jGzl1986dRbS56c8BovkKijJ0MAGILyJEynzK6K4h NbXI3NJ8atzC6jZIAQ705DLkMKZW5sDkHNbAYS+C8vcAovEyc/NlRtQ60FVpUxN6gkA8aO4A J+lnAfHOuklwyYMA0RCNApq38ZopamqKMloDzgjuNg7+aQQ/AaLR5J2DYEVgCOYHdVYkFMdq 8o4VWBGU5PFlDrTOipMTEKsIcXx2s+v3d9QXTSwmJ4zvomdNAGkxNx9/0cKUNjeH8FpG37nr MDlh5WC+bgpkYPquMU0fNL9tYTwxYWREwxsm4UwQiDTEIuVgNTExZQquvgz2QhROQFbCD53l 5ur7Q6TGHYwdjPGgjECrHzeGAzI2hfyDUTkBNdzYwWHSxMLc3MSYtjKiJ02NgcRMwYmAnhHe gAYaN7EYn7AAT54yh8REQRMNn+Fw18HcAiA6OFg9WVv/wen1B0B8dDyI1GymcE/7l24X84M8 AReIPep8UOp1e2A/RCTzMt1rZpkG/CCIP/iE/iRv/AXiT3LaZ/mX/mLFH3FCb+gND+s/XBjW 0/uJFolndUDskfNB3/xqbIy5kO8mfpeI3lcG+I0iP+Kc/dC3zp2jGgLEEWK5sa+++ur6yAjc fjXyQ4/zR7xvjiDevEGhFUcM9eCKYpq+oaf3vJ6enr6h4U/grXMEEQ0HEMF6+tgSj301Att1 xqjPepsjiDdvSm5jLILdAKHh2FeG/8vwlbGfwk1/yDwqWWR66vbARDRNHJXYjX7Uiv/8E2b9 pM/6Bz50w4cQ4etuFo5+tWD0+Z9kdnrOIN7UZzLqjRsA2nB0ZPKrsZHrwz9FMM4NREP9619d I3XRcESPMjS4fv2m5KuxidGvnvglMXOcf+YI4rD+jbGvxm5gXp1veOurkYkbel8NGxrqPTfH cJ708XMDkYICeHPspuHE2Ngt8E14ZAgEjoYfs6tZfKcTNkcQMf5IuZg+iJ+k6DO/fO4gfqcz /Cxe9AvEZ3GW5/p3/GLFuT7Dz+Lzf7HiszjLc/07frHiXJ/hZ/H5v1jxWZzluf4dv1hxrs/w s/j8Z21FCV53K6FpsUgsFtMisUQiFlMSMdyKJTTuElMisUgoFghh4wv4fL6ABz94PAH8FAr4 Qh7sEwkFPHyWI2Dz+PgfHx4IuVwuvoHLE8DT8JPL4XA5XO4z6jQedomARoQXF0tEQhFCAlAU 4AXggFEHUQL4BSKRUEj+FwrgkOHV8AgOG0ES5IBXyONxeTwOD6DxuXwel8/BMyKAfXw+T8Dj iQTwQt4zgvjQH0USSiRCCwopCdxBDGJ8DLdoWLgLuwlEMUAjr+AzAOE/sBwg5uN9AeAEFACP A5DAgAiLC+bjcTg8NhoULA83HM4zhYj6G/oluibcgGOSRxLYYKVYQovgafh6akCKdsTTIIJ/ IoAFjgiowJoCEdwI4Sef2FcIToqmA5/li3joxAKwNJfFBnCAGOzK5j9TiGLBx2IavREwUGIR +bptxIlwATWcAfgfrKezGIQkuqoIYAAWEbodD70WHgr4HIhMEVgO4g28lYu2A4OiOcGEEIMQ u1wMS+7jEP/1X79jigNvmn4lHtojy/8Pnnnssy6/sHDh82MCwEijA6LxwHpoRIhKEXzix3wx P46xFvFd4qcCYYcCDQbBi3sAI4/nrqxKLeiIKASsgJfLBmQk/iDzAHQe5Bgu2JaN8DmPxKL4 96++9dbS308fmOd6avOWh0fpuUOse0Bv20k7envY6x4e2cHdx9XdX2/x+vsc6z9BwH1jExs8 p6evr/e8vhCMFWdkYmRi8a6A5FERWJQCS8bFewpTS9kiCfgnbAgPQ47TfQjcEhwT7AZZBOMr xSbabV1jYzNPBKgwa3LAXYVgOg5kHR6EIgKGuASIfOFDR6UFry5/cwP/7eVLGSvQAV7UxkDd kUauXrupxttvLY88s3ebx8p3bFx8yJOepqfWR6//MweTpsQ3x3LFppqc1R89QPggl3YsmP8i bDcWGEAqres6NzBwrIkDBgTzQcCBKXmlNpZ+HtGJaTy0oEAE1kZbiwWtaWIwIIYmZhxMp701 NdnZl7oqmIKBxuOyECugQ7zothiH6Lm8mUVj6ZsfbDCk/3X5cmJHjl/jirvrlhkZEdvtyvHd tmqVb5MtPhBbv77W5Z2V1nb4QOJ9f6XZO5Y28XhiJHneTeff/bedexK+YUSR3kKa+pdf//qF Bc9/LJbUrTM2NrZq4mB2xaQJkUjzyqMvfX7is8/O8MQisBkmFrGIs8XIxOagiYUnuq5IRANK WiTsDW56p//LEC6eARGUSUw5mF4BLpQPMCmHw7KD6OSwWRz2QysKXn0L11j+sHz5W+BKlDA5 t3yvS4BLsQCPtu7QausQt23J/4UPIrNX2KyzMYvm4wNh/u7+6E3RraXkdWH9iZnea1enkace 2XjP6b9I3aLn6y9ccFlE1XWdboq+MMCGCgEVEvBBXhV55PTXeVkd+QdTPeA/iVDMOfF57qWa 8s/P8AUkEiG/CgWc3lNNLtHZpZA30ZG5Qh4b6iKGJZYJBMgFc/K4AkDJn5Fu3l++fOnLEoS4 nNiK7bfWr3F9LjlYWuIavWOL9TZDEmOsoW2b1tmsZiDaNaelH4339g5Ga9N5TbvfCAwM3v7N jMN77nmK+jUk0ecXDIvFdU1H49OPHlEBFIhF8EEIxbbGdTX13U1DkG2EQiwWaF4RjxvUH8/i YG0EC8JzYrGA33s43cWtP5eF5QLClYSdEKoFBiIA5EDRgLew2XYcyD0PrEj/G2B7i1jxTUc8 2sSuxtJci726HPNfpa05OWGMXSQBnn7r+jdFk8AUvL8229o7JDgY0RvmpXj3W1p2ncVPeHQT 6D1vYPCcAU3rL+ijqMz+811fNp2vxzkpGkgbbk45K9PTTp8sR/4GEIHDgXNCrUjo76oCI0HB gKDFZ3jClrQ92S7Z5ZBiBFhJIKlCeQB4YESIPwEYFoGy7diYXR866n+/CRANiaOS/OgdGRi2 89I23YHa+1lbW6/l6CC+bu3hZr2CpBtRSNemVq/gwF0EfNhKt7Td+QHM6x7d9F948UWcCnv+ Ob6Izsx1r26qk7GFEIxA6IDEScTc0qb+/bX7S8FB0U3hjzfATwAaf/G0BzBSjEWIUGQBdrX7 u79s7O+B/IoUhsMFzobpBWgAhwUOyueCm7I5bDYYnz+D3Ujenob4HnHHEFPrSLtL23XHGbI3 OTk5OoHJj3tzchpzm2p6iTuy00LCPdK8UshTeU15m/N9t61/Akau3gv/QlG/eX5BByWmM9P3 1RUnyhLA7dBNIY+IRLLPNfkh5ZXph9mEvxBMIqHK6rx7aJeVChwSiR8yPoG2tdtvk83BJB4E JhZOnpAwVrhFqsqH3RCVHMDJsYPq+NCKEtc3l7/68u+WLn+L8bKQ7m5T69z0N8gDeu/qVate XzENMc8ud/3avbqA2+6xqnvHukryukOB69PzMt3WhX/TivRlvYXPL1z43BjSmfAvz6aqz67r 5oH5ADFEg1hSfaG6Jruk4lITm1R5hCMSOjed14j4gzW9EIcYimAWIV9z7nTr0IkLue2E92As YtqBn8AEECdh30gH4MfMjErRG94DX33zPVfm8JJZmvMl/OQTBIj4xN7PPvvsPFMJJSfCKTvN 2TodjOTiCseKM5iFKUlysuaMyO6zz6apAPN6/ABIWdxhA4OxOAlWQc1nbLHQ/8QZPukvoPSD YyraVGdOqA4MtsEu3A1vE4t5g3IwsUCjILmHsFKhiMvRpLL+bhsqI/QUeieACOYjdR/hAQvg An9j20I+erSZEm744IMPNnCnmQnt6iqh+MzB8jfwJRRnA5N7xBugQLBdp7Mml2eIhiEbjy+C 1zyJ3ABIKH7wHqgPIkrAR1gsHhIbKP1iIVPn+WyhEDIs2pDxSbwLBAU7QOwwYMP8AmYiT+Ie 9E3MOlhJmSfgGQkwISgeEItg55k0XCLhAi9/uEmgXE1vP35ZEEk3hh2YRwSIMKnAP2wVkbvo OinMPpBn8EkKDhXqCTyDjBUZEBiQtFeAAyoHgMMoRAZHij5yO0g0hOOggzJZ9TErPho/SDke bjN62kdfpnsk3PwRvJz/1DOBvQU2F2gtDDw4ftJfEHCk9YXjR39FforPojW4n6BtiLWgR4Kn RTyBmIfUDtoR+In/kWYEX4AOCh0HEnGeANIqlEQuHwn6U5spn/jg4ocm3ZkGULgYfQJf2Cva T8gbxhlzHoQex45to/h1Yo6vABukJ5wGaJzgtaQtEVMHtiEZgj5DVYfOS4n5UhG/Ho4WG2Zs PdCqaa1DKbbQS8HBt6fye1Mh4Ryu4/aw0DshaUKxFwGjwYIIDoppCFKMAM4Cph/SLEIReYTd PHZUYQGOtmJq87adlDjcl7szB+5wwyWC7bty2ZLIgE22hhHbtgspn23bMFjphECJqE4sDhPt jJZxwoRh7Ec+jSQOCFJwDNIvSsSVXW0UT8NXuqvOCHj1eYXiutYqXjtflHAyQsyvPwxgwVlT iqtyKoQRdqkaYXuoYEgjCE9pTeb1uNoeSilhceqDAzWkYcSUg1UCDA3EDWUNMCP2kJBS4d+M ovEYxIRN28IpTsDfAqTCEDjyPaF72axAwc6UUG+W017XEFeB9478nXRguC+pD3nbMfsLUgS2 Q3xRsedeQlhnbvi3piDbYDkHiJzS/SlCdq3ytFLRy1UE1rYI2s5KP2zhqC8MnlazckrKq9Ar T3b3NmmELZq0i4LiekG5Rt5dN1TPa1H657SXa7bmVpzOQ1xMjWBkDghA0Kug24DSj3oHBuZT HZUO74XUI90l2bZTFMyhdgYI99raBorCff8SwnJN4Qe72rbuDw6lD9uGRyKSiAABJ5gtCObY lfKounQd05uJEf+KCLgweCWEUkJXSJNCnBfcLAw6xgvaFVIrCDrG4bSwM3uFvRV2Q07n6pCr FTc7n24WFrcdbhb3tvNr26qG2CmVvNOphUOKlrbCXPmpEuxIEB2mIGR72C4TIQebKJJU4c7T YlGyEw+Tv803kCcs5tGh3r6+FDsPzLotmC/03VbOElWijyazInYiEHFeQECYiFcp4Jzwp9j5 05GK4Ya9PcqIJLkAH8VK39zOPZdHaXOqKdUJQV35ySG+c3kh7yLb+dj+XjvWsb8OVEPDKCjJ 9S1vo9v35uaJeyr+3qIRNAd01/Gbg1jnFANtnIsBOZUkTgEXJhxEC2bDos/EIdLWx/rFRz1L SHINxxW4NuYXW0eo7WACjiPucPwvEeyCe+CeTEWkOVhPSdBRCSUzm35If1B9mLLAUBaJIEhA c4PEIn8BxXOVsCs0qVxBqpNQKhQ5VcjEIieBOx+lHE5o6FaRmK9R8oSf8ERsvpDj78oTsFGK YnGEA4FDbVAwsYXCeok2IxGI2ikHaj7eIsH5VgXuG7mR2fHPyqRE9ii3IbxgumliajqUQhSE 4ZRgZwjSKlEaseBhvUDhjUhv2IIAt0FuAKcUwhM+BjkpEQDUg22QV/EhlhVUIuGtwGp0yQYl YwhEHps11woc+CXYA6o+8Da0MPmHrotdMOzGXpho4VAsCAUALNhfMJUS5TcofVgdxXBHl1kw gYLChsQNhFMiRSFFRawMDYfcCowO78BTc66GExGfkUSxqjM0BUQ4tJGu7OuaXzAIoThgI9SQ qWmNCt+DtfLhGzDu0FpELWZYKhRIfIwyDlHGicOCFZHezIUVH7Ci6euDsOIL4cBJI4hqFPot Lm0wAgb282ARcg6IBqXriZm2n1FT4W1wDoDLoVHRoISrEmYD8FC2EvDhrYSuomyAhgbYKD7O BcSH7AZw4DIMcBYhkdow1ER8BAVWISWS2JIRvacVcECDpBQPnjzHcDR8hQBBkOUcoHNITUk6 BU9FPwW+ijEJn4+FkizyoDLHfTzd/PiR2Md0YxJo2C6BfiEUfHEAUiWJOTE/CtpCEfYQxNVQ 98TGYmsH4dUQe4hES1RFZkEj7kMR7wDuBkPzM4B8YoFHr0T+RhY7yCqNrlJihcS6//jK1O+X Ln2oFD+BZj5p1zdPCq5P6LIuSvmkGcStT/85UMOHkchhOcpXYLGE546AuGXtvToPfVJyJITr sWl3fBXK3qLDp1P3eXiUIHa+qDKfl5YCd3CVKm1I7eFnvR91Y5TgsC/WWR7pKfaU4LigUJFm Y4aj/i9o+N96c/nS//NkcO8TgZFs2ObBsT/YfP57+q74UyH/3//6nxxdL4nhB0YEFxSJLi98 Th8EqgUG6H8J9l4u+476YIoRtcSXenuH5Bwj5yG/Jr/Rb1dNNZ6WI+fr5D09A3XAXoR8zslL fo3xhbimIYxsancaHISigR6ALSRGIkYp5lRCWHGdjpGQH9Fulr61wZbl+MHypYxh3n/jjXdX rfojc/D//tprK1e/9tp/Mo/CPLbvjnfTyToi9n/Hr2WzGVa6NZ99snuTzaEZtiUiG5wWPfjb BXAd4wsLhiW0oLupuz/nbBMLjklcfOpYdM6JvS3gnJK8xoZT0cfzu6qgdnAulPgluMtUcg56 8FjN0IULXcUYicKLJX5HNkdE+ChJ0JEumNRLsmLF8BrEjEs5IBs/tOJryzdQr7xiSL21/H3i aGF7crL35BIGCkJO/5703XtqPMgDSUSe4wb/gEDGHyNd3Lq6cnJ8ySNFq8JWmV8+rTGisIbu CCV+bAF8q7bBr//lhQX6YjG3u8K5O1Xe6g4lhW4+mWCWWF18DDNPW86KhnTTfV2ZkJ74zvvL 90Z3NUZXoErc1lTVpxoqBsUYnPVkeXNXTXbNAK7FIULSQpIlLVwFwV6LhCVg5c/oNCRL33zl d0tBSP398rd1bue6m4XCEYIqTrb1thXmHSIPfLYhV9vOrHfQvvlBQU4qxV/xAT8kO/59090f schCMO4h3RPq2gbPk0WPX+kteJ4n4rYeiUr39GmVoW/2njxXcym/FwQokejDXS6r1jS6pLdh jg27VK8MPdfU5o6BmdqV7uZW04yBxo/MLnH0T27SOBMVFTAyVQLdlfA4QgNQPwZHFTwsGuK3 lr/66nsc6nevomAMre8b5q+7rHpjFVHG6ff/9IbLa3/+I+O2kTvwdjsjsdJ5e5krZEm3pMnR lN63sXRzf4TiITh9EMOpX8ElYgueF4g4TZY1X7rUdMnQCL2HP0k08w5sQVuoz/Z3R59yacJY 5F7oqpdQ9d1cGvgdrzrv8J7iwUowkUhwoitPINF0w6opE4dEwwHPhJVIIDVwF5f6QTFmIwua 4ahvLX/zA5r+w1vLl7+Hh845vdftfnTw3iBindwcm5w9jXuOkTTiQ8ClMcoplRagSzyIkZfP ykyPj2+SIy+D5gkcETMqeJHBghfhb6LA9VML9ECfODFY0dTedo5Ysdktv6umKx3TDXhqk1f6 ka5DpApKe+sFwvpWAALLN6Uppb0tytZwpGnOxSUCYWruVsIWiOBKkOooBN5H5orLrWDGGRA3 oM5v+Ff3tyEmySbZdskP9TQCODzb5909LEbp8CQuGrafgegbwLyEbNx1q1cF7DqVY4fjCSA+ YZtBKKeAo/cCTb9IU7+CJQ2h6GMBJ1/zP/+DBU3U7BKf71fqEgBFg5bUfZnjtqZ1kw/SOHFv vUh4tJWH3EbVndea2e7RMgAGE4uam/mc7d12wAfIGABpiElGZcgNaZIh5xB5YwaBM/zgFbL9 /j0drL/szst5TXfoEtdStxXEP2ELxzuGjLtSdEogrtwzmyCkKbfLKz88B5c7yE6i2mP9Ew4/ 9/xvfv0byDbIcmgRu1tDqqJQ3FyT29091HUMmZt48PPUs5+nnjgHLSCUk0pa0zUEa3FC8dYz qbmtOWeVf8GFG2FzszD1fDlqNEydADaO3krYHFnbwbDEpIpLrDPqIvftV3F77z/IVL7kDyuL DZPXrcKDhazxn2/Y7Nm0iujBlM9G3OPBpBt+fBjJIwzEM46uPfHBFk18iE5mlobINuhQwmG9 5xYseM5AgHKqWPzJRS02kUBU29pw5aFtkDAEDlvYxhZzOQBXIqzQiLgVoaRfgvVgV01bEOrC QNc0Gh67wh/nT6A0EJw4moNEl5lhQRZHyj/8e4SjCja89957GxgY1N+aiqFDH8whTT21za00 WeCfw6x978TEujU3gjyIAKecudHSEv/PKwjfZMABLcVfjf3A5bHLB8gaIXAwOCikKshAESrs RY8mCqMEZFZ0QGw6mJkcMrtByBBsRMjAAQ6GxGCfCOiYnoPR/uG3oUhMZEcQpWdMT0FTd5vI SLjRTNzpHrIcRWBbWDfHTUye0rmznb8QxQvkoZhFcZFJDHIqxg8uq0HVwV4RFAPCh8jqBUam O5fkCqTXyMCxayftLjKUuIQOzJsyGajaCLTzSDWgPYDv4KviyMI59o/TcgbpPKbZKcN2MDJR 1yCgn9pp/OW11177w4yVUOH/1mEX/JGi//Tnh4b7845V012+jsgw5wEbDKzHKNhMz18wK2h8 UX3+sb2FsJcUNagIIG7n1aGlMHCrS8+VbwcItZnMyo1P+cXP63iilDDgogLwXb5gKwsHbhS2 uo4Kh1hIvSfUB6u/rpcm9VHwVIgRgZu2H/mIQsJKgPquhB8Akw5vFNBu+w3/zKPEfwJs/JDw ymb6T5u52KnzPT+iuZt5nuuxh8L1exKP6HMo3ZP2kAyG9SSq8/PEoqreQFiUqU8JVotEF9PC UknnzD/dzk/NVVBt59tIR8WrbRNqgAq05NSGi0XtdSJeb3ltKp+f19sQStYxiGuSISPiq0wb BVYk1fGfWZFiBVDrPe0DVv3VIxhz567g9Ty/EC+aCu/3/I8uX8/EXX/cWFvLpTgXvNa7Juwt 9zgsS4isDwiRewd67S3NQE2fmSwhLS2u6TPLGdg0UpVNLU3hIlFdoHce5M1DA4fEopI1LWxE KOSUy0UgmlKK0zBuA+/mlavIEF9vSU+LUFRSKeKcbmvu4QtKelvbSXUgoU5IKcpxRHXE4kFI DoJ+ekvMDqS2v2v/rrVniG0Ij/qP1RZr/yPANlhEhXtvXBW8yvr1jTuCHfMSKJHrmWOv7830 D06JCUvz2bg7Ya9r7sbEPLKAj8HFrBXiBkM25CdAbW+QlbQIBL4pudAp9bbVNVPiQ+cbGGlD cs6ezuqW0ewTzsh9BNyWOl5kpVDUWzfYKxAOVIpZp4MqK/mc0ubSPKK7YavP6FOEBZAERGqH bqnu6RAFKZS9h4entf0OQSKHfndb8p433hUGCAzDtgXuDt8f4mUfuYsTlkCxdvDW5xbb2ycG eu7YleiZGB5sd2z/DpB6GbFMgCOJTNFghp9I91jf6pV7BojYqVJgpiWatgGJ+Ez7QB0zqZFa vm9oUETxLm5F0U0kaisPLldK6IG2th6xuL2C4g84DVYIeOfKywcYfREEAFL9MYESE0KvAWWI pFPomZ8OUZhHRVQWHz4dVinu4VPwL7myTpwspkIzU5MdM0MvHnJM5oVKYXjlHCyhDpTvDb14 UTPYM1AxyJNfHJBi44uGg3OLGZSRqAhUtBS7YlAD+6QVbalCkZTHdRaLYEAG6ByO/onsKlKh bghYZMENFvtlbY6QeOGQOeDGHJGABZ2ugMeSsmxx1pGZ0CEZZloFwiSDAh3OqXzrsCbNg6RP wVV6WN5xchRle0MUuGHxjJFT6b8IoBaoiyV8OD5MLFCzofMjShvqDdCw4+8HB0KtgshtUE9Q uCH9MmhtMCGGQ4xEZsZwxQ9FzkBoEK4RgHggpHFuDhUgHGzEHoqQUsCBVBQ7DBzIJa0jNtAM AUByDlrYLE0Vi9jTZQTAoaJLlEKi6yIqooeTUMT5DJzzQ9WQyHF46IxGRcoi3DIrWIzXIs8m a6xEm2NI6fRCKhEtka8xgzrk7DH8hsw64j9opn78sCZamfwNImaMVJdaSJ2Ceg6Vj0FJCgYe MS6IY2tAKA3uJmSdUXgw3yKpw5diI03eQBRvaKeQ0SANZdZMiYvgI4xvHQMnAc8skDPNBt7j P70uPsLKvtMDHe2GA8baB1EA2ZA0cnCWyWAFBCakAnKUzNgJ+hp6HbO2j8FKBGJyFhgFEmUD ok8K0WMRMvFCbCnIGINOlEKQKNgwRmXYHOHnmItmy1GxLSbDtISNkd4cfiWXrDkQhkkOnXQW TH0kFkdmh/bVDRJDKCNmxj8J/yRep7MViWLEgFOA+LlMKOiSmC6bMVGvIwE43fmt6ebbzTet m2JiQBfC7I1TkrCaiSu3IIHBLc4kEnkDR74ZewEs6JfJPAPcMJP+xFVxqhpewsw+YHBhvwio yLIM6mykzycT8cw6BtmYBMTckCyLP0hlFM2aFYm0IZEgHpwOJRP3sLoHK7ckLLEwCz65c+dD tAnJDEjsEKpupYOUFuKeuDH48KxgymVSDelDiCJOBoxwFQcR4OgqphskAExPQ9oXEgJEh5sJ 0fD3S19d+vtXvt1yM19B6gazfIa9Kcy6wBAoy5aF02jQcoMczYdfj8H/j8VLYFvMOJdYmOAE b2PG4HGFHHYJ5Al8cofYm+RjPDFY4HS2gb3g+h1pVfWwWIExwRAKcjaI/SAHTMcikwZAzJkB 8f9buvzNt0Ck+ldGsMDzBueAFKy//ZFe/+86YE7T820frbe1h4pG2i/BxgQY52GzHNOqwnd4 +R5xZLFxehkleRD6SGx8sfi3uC1eDHkIzCHIhzFGMBC2XZCfwMsF/P3esJpElg8ZFxVpvP1A KPfeXYwdCZoFCwE3+Fh9vlctG62KdYaJSBKYzBthNz09MYdO8LAuglQMRGjDm68S1dc1Z/fK lSt378ZJN9rX7Y+bAA5sEkmwB04uwM7gQxU5th/BAow41n6Ly8GjXjt5LFl8eF7upi/LHe1s cZIQTMphE4rB5S/+HU4yUtSS30IpqT5yNDrxSCRYglyogAPi7qXHGxvz84/noWkhQlHZCjqT fKg/LzNZwzAG4rB8X5v6Xdm5ybAQTNaGmdaJJCeGz5E6gxYkMSp4WPrpPyz/N8NXXqYM32Z0 VIErK2SbdwQLe3ovtybLnBxQvw19V691sbFevQ3gsqKVmfkR0VWQDVP6z37++dnuEnac5zoL pU96r8xJFodD6Dg3gctG4Gt9S5a8/DJ8/G+XvARmSuw62990tiYVSx+GGOQhVsWZmoCKwcFU 0u1j4YF/vP2r7/mtTSCBgP0xlJDMrq7SrvTN+w5Nj1WBuzPJVVcWxSRcmXEjVKgeWBGgvbp0 KYhvsLJBzLV+ldtKl7Wr0C0DrXc0vusN00WSzEMhlSVdzZlgxqP9rpmbrFug2vFSQmxt7VyV UkdpQ2P6rhUrdm3MZLmz7MCKXHf4n1w9sQgD8V9efAVub4kEQ3mflA7Gna1CUQDtRfKsqmal Xwig1mUYPGrXphMDA+d7daWTmIjVlqtJzYluqgBfnK6nqIYwdiZ0gUz5kNKDsfbQUUFHffMt EPzfxsFb2AK8N4VsCuhC7SZwU6BLSiv0ikBI8zmOpUKIP25OdlDopRxb4C+cFA+23VZnmUqm unzcPuXLe9nZvk6OUltHO5adrZ0jZB42l30DsP2Wpl5asuSlf4j4tac2p+/wAUUYZBqScXBY 5fD9eN+aVFRMmGUQqPxOOfbrfXYXk5SC6RRh2HXnJ7Z2lRDezTA+Mh6gKyDYJOICK6Oroi73 EOLbb25wffstQ3BYYkU64F2P9QHrdyPEbatXubwev58Yt2WVVwBKM/wzTRlelwZ5XDt3rkei SqEqLOwrVCQ1WRyJPrgpOk0Wt5X1yYdk7NUZp+34XwA4QwqN+BJ4UW1/U3ZXdL+G+B8eJBwj e1N568YhDozeMQvleOiy803d3TWwWEMikVlnVjf1nh0ob0Hai6bDzhSRk+KIAjGjW5FVAExQ M9gN583fSeiPKcOljFQsCXQJ4e6NbvwboN2eGJ/tnWhPqrxjl42ScClWulu/m9TW1tFVetxP KlWqg9SqWC+bd8zij/utO6LoiHOUSaXudk4yd2d3SKyfQBBS9MsA8TdwLD2DiqE8ZY8CLIUz /sBxxeKUXG7+fYwGKPt4uR+6m2xPQqGitlhXR5GOC0SK0x3HI/cXowkZbIThAKdhIMFDoIHT oQl7ZkwVb3j197/7HUwVv8cM9Qfu2SBwDYuOoOiw9OPp2em703GVSuhZU/MGaltcWVNtgFvS EXu5qsxtxwGFok+dpdKWdhc3+a3b2LhdrlI4xck+ZNvKHFkf2oGvcm4uXvLyS2DKxUDrUBYt bcdQIUeHUxpizflIz001x1d9hEIrGdaB+HJqcutu7S9mDMXUA16G1+oLp2tOodRKKiwDkBQZ Ynmdqkfm5zEDzSga4g9gqBgWNthMAQx0gYF3a5udNEwQ+2c2Vfj7O8PE38qu5IrzNrvs7OwK o+3rL5maxR9Qb2mM1Aap1VVyuTpTXZDWlbiu0adD21eo2ur8odSd5W7HdsYu9u+/eWnJS4t/ A2OWREMaar9NOBYcEfFLjsa7ZkAKuQXNp6M4Ivezg6maz5t1h45JU6zOabrobHfmfAX6Juma SS9DGg9dM0UCFIsJMqhH+0XHDR9s2KATFultx5IrMpPPMlIxO5cFNY0Wt59LFbA1vZUctlNf t2dU+fk9RxSxvd0xSrVSDajUKnVBRknCobyCAqUqKEghl7tKXaVyO2fIrizWP/4xf/7Nj8nC PmSEMxpsGzAnkPwHNxUaASWUuZPqi5QJL+NMhX5bHkQuI8OjRjwwRA1opP9FLIcVghgX4eK5 IuYmq8+oNzxmRYTCXGtCNjs+zgTZotfCjKI/H4cPoM6xODI7WZBMJi0MVWcpq6sURVnV1drO goK+wg6tsrAMwGpj5eqCrCx1oUyhksbJ5HFSKcfOmQUXh8AMLNzAMCxfxMXQwSMjzkrGbhki ziwU6DRw1GNBLSeyHR4AyUzQMqPsRfphkQDhM9o50WR113PqUhhC/S40nFxHg4MvcP0DC1xU tlWulWV9EVdUFHNAFdVZoP20IzVVqVIqC6oKtOpOdZn2cmdh5+WOPpVSqy5UBMnlTrYssCTO FpILfvj8rZ5RXBkZpCEpn5xvEkmC9dsVKOUwdQ1JqJxLBAJ4FHfUS8YEpfBDUFF0PRfuIBAZ QyMdnvZrZib5qRC5f6U5cSyK+lAndYOU9reNq2K5zh8mbZmKKiiL6kz6W5Z080YfpadHvFdS oeKyOrZQ2aeVa6OykqIKqtSxSnW1MkZZVaBQyRVxW523SrHBwmFtLq8v8cTQ0VN92HrxPzkg EHyIAhOszYsodW1Pb2UKmDgOlozdeZwiXp1ia5GQvXkrn98y0HOCHSFjlSXIazOl4SxpBpnS 1NVFVBZ0G1kRYdR41Jiept04lr6/KzlTwN4RzrcDuYvF5juVDpzw+Mh/s9du61XryxJ83vBx eMP8eOR8K+/DTeb2xp6eGT7rt6xa77nKftWWsqwYbWFnX2yntgOqpcJf7uRo62gLDYgdUFcO t7Ll76GD3cdPHs2sPxwfH34kP3GfLOxoYq1cUpfvk1rflO/pNZR2NL/WPn7o6OH93bmeKeW1 PHULly+tD2k40j0U2O3rUe6VeIFFkimWfYxqYk4iiWFzBZdW4SzOP7GiuD26xNZ3+97WI77B adtD9sYIwlpYQXWJkRvXxrtZr53yMFnnsTbeZFNaXKCb1eEd1nusrSOtdvgd32edfnf1yi3a 1L6CKm1qQZayo0rZoVT2OcY5yT50ZgE+mKM4dJLP7SgfrM1PzgsYGmxo0LQEbz+5N3kwT8A5 cyElrTg5vkFaXlqRmV/sHxyQcqQ9vlh6jFPVK+R3JIYMBRS3pTSntQYeK1djkKJuR3In02lj UzZtTZ3a9VQFLqjf07G0VNqcdjixtCGs8gi/cgeX7eOd1hDvl7gxxNNvrYdnSLr1JvsM+x0h Kzd52cen2/v5+aV7e6eV5jedDArqUKurY/sKozqzOjuUWoVc5i+TObk72bFYLG576YG0ll5V Q+mRwNMtVbUNRQ3trSdLwnx66Ex7Xm1KXmZu8OaQEHv7vbt8egNP1WeWB64P4fCPRXqe7t2V 8lmzpjjg0JBXyYkq5kJqZGvEYBCHpNlgxslIeOI5eBpEfkNxwM6QYNv9Hok7ShsSwvMEmpDN aX75q+K9Ez1W3TVZk2ix4671suNpRaYWDm7eFhbx6RZu8ene1n72HlZ+R/uUN7KiLquzyqKy CpRVSqXaXy51+hC4kCPwVrbzxdpjbT3ynjPlF86ckQ/W16anDrXbXTwnE8vOtfRo2pSDFS0V za0XK1p7UysqlEEVYQ25XEp5sVnuNNCeqnFsq6ioaA7VcGCqdVqTw6TM1EdMNphrp4sjNQ/4 7swLMqZrhv85fk9lT3JKbWVvSkBJqKZCyK4sza1rDynd75u2o6E15LDvkXy4qC8yafue+JTw xE3xXrm1h0JqUwJ9wkpDEjrU1TGpHTEZGTGdUUl9hQVaZZ+qMM4dSADHzg6IQKoMJn+hALH/ Ai1X/anTEceCxFxUaQQgeWMd4VGVg6LQHnA68D9u3qkeuAxHAsQHDh1XucBaIPvg6is6J7le lwgipBoSYYS5BgTpHFhRN/v8oCKSOwJgejyhmMUWclkw6CH8i4hvF+TPck+VqoIUVaHV6pio jISyzIyoKG1CWVlGbFhDVkRWTAzk0Cj4H0pIp7KqKKosK6osqawoJikqolApLwxSyIDuyDhw YSG5HA86ZaxxykGopiTp4yguGeOEFT+4XJ3HxmViOE7bUHJ1FeHijPKjWx3RKT+4h6kaBCKB yTA7UG7RUR8bg0ZqgZ03Y18yBkzEPS4PiqK73VZH7QH5F1na+VF9RQWfZiR9Wl0WFdNZnRAb W1ZQUIR5tE/bMb9KWxZRFKNOiomKioiKiY1KjVAEfSGVuUtZdlL4GB5c6ovaDiywEAGYzKGS +MHjw6U7UOgAJ64zwx6cQSfSJHPcjH5FBC3yXrKTGcoFpYg0IGRBgTyDEJ/gp4+BZngxjCHb sdi2n0jlKmVhlHKzMioqqCwmJioiqSi2KErdV5DUWdAZlVqgropJhfCLia2uiu2M6uyMutxZ VpSR1QlnBkba3GW2tlCD8EpKvPgXl/wf0GlkN4wBCEiESNRHbCsZSVInPQIlIKosKj/MVVjE hMz3OSClIKsljBZAzcOx2Ed9VGdFNCNe20Nu8O2gHoIeY2cHXVKQurC6UF3YV9BXFNW3uejT JFWsQlsQq1QmpcoLIooUSpW0MyumKCurqKyoMwZ8tSwmqSCmQ64CLz/gekAmxUt+GU+FA9KJ jgANcei+sAGvsEJhiDEGgUK+34DMNhDWB5HI8CJ8npnFJjHIXLnEVA48W0/IqNOIsYvDeQRy InFdBGcD2bZsp61b5Yo+6IDVnSp1UmxSVEZSbFRVrLYwVlugrUrSxhR1xmYVqAvksUGxSRFg 5KiYqKKCpKzqPlXWAYV7nCPL0ZYNegDUSIQowFVEpq0i7kXGrSBWmNgk6HDqA56H9gqtixMd 5PCZgQJyl6EAKMUTXPg84/i6dDNtRLGw7+NHLTrNypmrDVAp5dhxbe2cHB2lUqlcKo8tjI2K jYrrjAHm1hej6gCaKlUoU6tSlcpqrbJAHVWUUVZU/WlRRh/46mtTL71k/qmTTKYAeCy45B6v VINVM1zmYKgqc3A4/g0woGMkii+ZeoBn8fs3REDyGP0YFSlmZpeQd9jLDNoz6z26VSISpDOt yNNfCGO/lx82G8RR8YQSK8KpxLUKVGI4jqo41YFOnyJtVpFaq4IIzNisVMtj1MqkTzfDf5/G QInoK9AmxXYWRGVEVYMZY2LMUaBassS8L6hP7VOWkVEdUw2KR+phzuFMlJH4Mk+4Qh/4VmQE fSScgoEpH095YCowF0lqmtMhHkki4rQSxldF4dXkKwF00hvJr4zHYmziI3iSGH4mRN7ChQv0 DPQXjOm+01S83nY9h6ytQb+4j4OrD8I4+y1btqwyNnd1ljmpIs0ythhvVquzYmIT1uwo7FN1 9HmaLoPN9GCkKjYWv+pDmVQUVRhVVBT1RdnUksWTEjG0xVPyuMjGSzY2No01mRyeZ6O92xG4 fjvxoFm/2cFEtiAhvjJj2V1Pviilq8nbZaPPJ+IYi5TI4zC2CDbkb9yHS91gxoHdfHRlyCNo VWbsCKsKfP8K8x1I01UEIE4bTfjCwgUGkGIWLoTr7nET5/vuzsQ78tdf9/hy7ev74Esg6vpb LV1azx93BU8Nsnfx2fiOUayqQFWUUHNKnhWlzIr88lL2Ozb3+8OVUBrlHdqoos6MvrKysohP Ny9ejMvNL/56yZIMbUZeWk1Ta/ugglfnFm3ZtSacLzsL05tfdp1li0LueZVEN/XwxS3eiS7R 3V1HxIfur1mZbbYmXGhrfdDF8uBxRzjXXM3nymktg8krugtb8SpWZuUL0yomyoeOennBAn0s hQsXTH9lcumRPRE8iHDNsdO1wXv3HhuEMZLW6mgX04Z8aADT3Na9s2Zd1/6gqrIt9m80ethv WR9VGNmYnn0/O/tUjEqbpY1VFMoh1ZRFRWTEZny65GWKWgwLJkuWTHV2bDHNtnRZG8lh17ud atwXXcnjtXXdt7wfXSXgHreJ3nfw+JYYcWDjmi+Pa3qPCFOi+7uiXaLbxdKzbRdb2nL8KYGP V4A0NUFH0qZTJ3bV6JzIFsgXzpBQnAHRAKHBTOzCBc+THnj9u2si97zrFwlBz9pnujbRNAGS WmZrYn96Tl4+MM22gZaaQ5sC5UqFT02jy32bFTZGqr5IN4t33sm+5KVWKJRyMKS6ENy0LAuq 4p0lL6E6Sk8CRKXcr9Emuia6gcupq2ntb6ppZ/Mio+81vuOWwI+7UL6v5UJTU5uw12VNa9OR wEruheJNh+N3t9aJpN2sI4fZe1LFnD2JvcK2XJyynx5B0xEDvOSFpB2SVPFaEAKRSaI42Tz/ JvxcqEcugm3+vCZyt+UJGXisMqdncHCoGNSUzPSU49m7jsbLWBx3lo/ZeutdB+TajsrKk/eP t+dlBmkjN3lkW9pk74Bko9b2yfu02r7qssJOKI2LlvzGkHr5lRcNIRg7+hqs0k/57Wg4wK7v 2ueyKzqPIwu2tEm/lB3A5Wm8bTZu3+TtLypudEs8bh0fyQ/dYbMsvrQ7U+gUbW22xjraVawo 3R/A4w3tB1aHSoeuAJKgxLpIhiFwgRnZ4IzvKq7CyWbYXtQ5qpjrvX1PCY5LUAo3E6NV6aBc ijXwVR/WXf3HWRxVvNm6+ysu3fOSBoEhve6vKSvsU2oj4/e9s87yvpdcrZUpFY6FcnlSUHVh bKey84uXXqFe/C18P8NLS8o6shJX5Ff2Z9c6OWZ2t2ant9ZxVKXv9Ef3f9ldyOm+VHyivKlV Iyq2iU9fZ5ldL0zJPh4f0DIUIXY8eyJ3z2dnpVR4aVgwX9JTDlfiQ1aB2Qhy+ZyO1pGL0Mhl k+TSSfHDWPwf/RdeeGE+JXlh4fSf9QjZvocZyOT0ltfk9mrAFzKbKj2ii5vz4ZtIzvQ0N16s 7Nph5xwnVR106/LCqnj04BaIxcZKhb8SfVVbqOgo0HbKL0doLy9CjDT18pLFWqXCo6s+prm1 4WO16TKzbLfV1qlbzwwl5gd2n5Hy2lrq29MOtQsEmi634guf99fxNQP5lbvaS1MlgtSP29Ng TkcyeKa+QeSjdMLlAmR1zGwosncyW4FWxGvqkOUCQXjIbrQwEfvCr8Z0RpQI15uF5UYIZGBH TmLm3spgH4jczOPzExuPZuRDB8TldBxXrXdJc5fGqSxq6gNstnwUqti4YvW6dTbeWkVQnFrR 569VQV5VxsYUBFV3aBe/9BJqxYt/rS3s27fGdK2VWeKBwosXT3S1DAykctwbLHO64kFFFh4O 01TuqxQL03LPBdiq0+tEwsyGHTkeOe44xZ13ErMID9LUquhQ6KrIF5GBS2JHBes/xEuZxUGs CcwC7UOIdB+O/S4YY0KT3ZpTY5+76vVNMMkXf44dn3nmfIREnJkdf/xS45p0thgWuKvSE7rP tzm61pn15ykL8u8bqfvy3Va4ddWkW0Uo5OC/clwEUCZlFRQlJRWp+34LIBcvBmqnDKptOn3h Qk4t29GO7dqt+QSky8qcc6EVF9pgpe5ij2jwfJ1A0NPGbeM2n5VKBJpzZzSfwdQxmKX9Iq49 wjfHXDjbA4WRUBryZQHMmD1hqMxMLWQOIsXOhAioL48Nf6xjc/wKx/Lwga6ui0KK1cMNOx8k GpSKJZrPLw6ADva5La7ka1pT2ypYTnZ1Z/MK5X3VF9Kk6va8oRPt9edOpKbK1QoVCHLavoKO y1na6o5OdcEXN391o+9GRKdW3Vdff0D2YdvgJ+5sbtwZJRBWjn8qXIPvzAb6plQK1G2wKonr gzylP+QTthS+vgjyOdSBre7MJZ1CDpeQG7zeDL2TmbbCb7eAOzojElvNTDc6aDN+2HH5tnYY 0ZQkSA5ZFk4a/+9QeQQCFpmC5KbabmU5OznJ5cBX5UFKubxQBtf/qOJkKq2rTCZXQB4KUkqh sUpVRhRUAwEoSiooi+i7XNihhpoCi3UKJ5mTVObs5O681RnaKzL4wGiiMKUDDBVTCDJHXAIA gg0gmLDTpVCcvcJnyIaNFUYl+fYHhIYTzATsdxkQwzqJA9CEi0OLA9f1ghwKcxm4fuhk6yx1 lamVl+XyDnlSVWGVUq0CwFLXIH+lQhFUqCzUauO0hUWdSZ0gAnREpEYplUGxamWqLMgpztF2 qyObZSsLgqVIkJLRdrqLgdzJ1Qo4u4ICBqEv8PuFn8LVgZhQmKsrSNiR4R0sEtAWwT0yjI9X iZBW/p/JUyJ7L09c3nCOiioAtRhOErxXvTElgQw3Qa2MIYyck5rot09l5y4L89ovk23ZuF2q kirkUltXmUIKUn+fuqOqoxBuqrRJ1R3VwNe11UmXOzz3+ZgcrdYeVsGiFdudXecXUs1mZ4bF 4CXCnHoFXPYdGBwZSa68JIMloan4JQXA1QNbelk498JJcCUX2iI4TDgQd8QKBDihGCS3kuuZ ni4V70kO3iny4frXhddJoyJ5/PDNPFHl6bZSWUakkHO0sL5SfTnysIzXHpKZfzQ8KDLtlF+k h5uHl5fflvX79nnaSZ2h3woCB5YqwYcLo6D/1yZ1oAjQmRSbmb/y5MnD1sfTPDxPArrehsr6 U6eOHE9MS6naf6q2NVKgqc0cLA3ZHJniExiYsXFbZJrHNllKIMf/GDc0c5evfYhv+f5t2yIb 4CsyyNcc4lc5YtUnFsUxkOmWkHxrztMc1c7b3s/HK3ij/Y4d727PP71j/4nunXRYyLv5kReO 2W88l7LfIyWv9FgFu333xuM7ajM89u1LjG9pjb8bHXzco3SowV0qVblLZYq4Ax2yy32FRYVJ ZRmdHYWqmKzY6oIYlVe/z67VDd2gyZa27GdXdO/yaukJbi3dnX+8uGeouJfNOhfi09uc2Hsm vrfdr7kk3rulOLHynDy0RCjY753oXXLId5uHR2kxubhAl2SwW9bpFcjbEDlZAno6RFZ3eMDa 3b7euxo8duw/7FoaYncogQ5raQvZVGnb5M09udcmUHk6OIJXV9sW4leb4LErcdNx6cZ07+MZ 3psiw3ZJ5TIpZBwVpBU1tMexMdXopWWwglXW2Xk5w6rLwSrdp9T7eP6p8Ganuure6LSCgNpT +SnpadKWiGaONDSz9GRCd2BUjm9GblhkTmleZXf4Ibn0GCutO/hkbabv/uDakw15JJsQAqbL MIwQRUbPiLtiCXm6FXPf990bYr//cOCuUycPyWtT7P3qqPaG9bXHAo4eOx3Z29x8+vDh2jRB RfzR3JZ8j5BTpYkh++Lja3f7lDf4WSeCKAAri66Qc4KUQUp1QXVWWVInrPVUQ4ucUXWk+3B3 bYtfa75ffm993oGexMRzpbXFvb0tDc21p4s1lVsVLacG2jUDJaeL80/lxRefKcmsqG9olYt6 TpdoevOSQyvqSoqbkzVYNMjF5VjxCT3F1Io9BpZ8jEX03qc5qvCzEwN2oS0V/uENFamh7IrQ Y02ZYv9zn1WwBz9jKwY0rnJ1Rc9AEFc28NmgNBkGtwfbKi72VLS3q+vqa5sa5AoFFBBVXJxK Cys3VWWxSZ0xUUkRKFNFFBTU1avrEjQ9bW31FRp/f6egisGgtgp/JQjSjqGhH8Kih1ChgYEd 9lap5pxj28BfYXqYm7rxNEssZMN3+sCXP4lx5ox4o47HzFARiSIJhsSMQ4jO04sGNP8wwWWY eU6IUlFdwAk2jgYTmY/oI/jdHeQLWOzYW0FetXWSOcscAZdzeGlInSooDmQ4hRZuqlILq7Qd BZ0dnZsvg5d2ajM6q2HFCoY8wJttpQp3mdTJ2dnWyRZWAlgsSJTwvTxkYRAulRexgii2E044 iPk4dMRU85l/SHQ6seA3BiFisr5MZiLIN7Og435rXZTo/hyN5Dv//SRdDn+USzB/7xRvMaF/ 58/SFQHyWY+Lu98kK0/e8/8DzaIQ5XrpD2kAAAAASUVORK5CYILbAAAARAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQ yep5+brOEYyCAKoAS6kLAgAAABcAAAAWAAAAagBpAGEAbgBnAGgAbwBuAGcAQABjAGEAdABy AC4AYwBvAG0ALgBjAG4AAADgyep5+brOEYyCAKoAS6kLOgAAAG0AYQBpAGwAdABvADoAagBp AGEAbgBnAGgAbwBuAGcAQABjAGEAdAByAC4AYwBvAG0ALgBjAG4AAADbAAAARAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AADQyep5+brOEYyCAKoAS6kLAgAAABcAAAAWAAAAcwBoAGUAbgB5AGEAcQBpAG4AQABjAGEA dAByAC4AYwBvAG0ALgBjAG4AAADgyep5+brOEYyCAKoAS6kLOgAAAG0AYQBpAGwAdABvADoA cwBoAGUAbgB5AGEAcQBpAG4AQABjAGEAdAByAC4AYwBvAG0ALgBjAG4AAADbAAAARAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAADQyep5+brOEYyCAKoAS6kLAgAAABcAAAAWAAAAagBpAGEAbgBnAGgAbwBuAGcAQABj AGEAdAByAC4AYwBvAG0ALgBjAG4AAADgyep5+brOEYyCAKoAS6kLOgAAAG0AYQBpAGwAdABv ADoAagBpAGEAbgBnAGgAbwBuAGcAQABjAGEAdAByAC4AYwBvAG0ALgBjAG4AAADbAAAARAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAADQyep5+brOEYyCAKoAS6kLAgAAABcAAAAWAAAAcwBoAGUAbgB5AGEAcQBpAG4A QABjAGEAdAByAC4AYwBvAG0ALgBjAG4AAADgyep5+brOEYyCAKoAS6kLOgAAAG0AYQBpAGwA dABvADoAcwBoAGUAbgB5AGEAcQBpAG4AQABjAGEAdAByAC4AYwBvAG0ALgBjAG4AAADjAAAA RAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAADQyep5+brOEYyCAKoAS6kLAgAAABcAAAAYAAAAYwBjAHMAYQBjAG8AbgB0 AGEAYwB0AEAAYwBjAHMAYQAuAG8AcgBnAC4AYwBuAAAA4Mnqefm6zhGMggCqAEupCz4AAABt AGEAaQBsAHQAbwA6AGMAYwBzAGEAYwBvAG4AdABhAGMAdABAAGMAYwBzAGEALgBvAHIAZwAu AGMAbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAASABwACgABAGkADwACAAAABAAAACAAAEDx/wIAIAAMAAIA GWqWbgAAAgAAAAgAbUgJBG5IBAgyAAEAAQACADIADAAFAIuJ+lFXMCAAMQAAAA4AAQADJAMG JAFAJgBhJAMHADUIgUNKHAAAAAAAAAAAAAAAAAAAAAAAABwAQUDy/6EAHAAMAQYAtWs9hNUw qTDzMMgwAAAAAAAAAAAAAAAAIgA+QAEA8gAiAAwAAgBoiEyYAAAIAA8AAyQBYSQBAwA1CIEA JgBKQAEAAgEmAAwAAgBvUkyYAAAIABAAAyQBYSQBBwA1CIFDShwAACQAVUCiABEBJAAMAAcA zzCkMNEw/DDqMPMwrzAAAAYAPioBQioCLABWQKIAIQEsAAwACwBoiDp5VzBfMM8wpDDRMPww 6jDzMK8wAAAGAD4qAUIqDDYA/g/x/zIBNgAMAAkASABUAE0ATAAgAEIAbwBkAHkAAAACABMA DwBPSgIAUUoCAGgIAG1ICQQAPAD+D/H/QgE8AAwADABIAFQATQBMACAAUAByAGUALQB0AGEA ZwAAAAIAFAAPAE9KBQBRSgUAaAgAbUgJBAAiAP4PAQBSASIADAEFAHli6GxGaIdlLGcAAAIA FQAEAENKEgAwAB8AAQBiATAADAAEANgwwzDAMPwwAAANABYADcYIAAI5EHIgAQIACABQSgYA bUgJDCYAQkABAHIBJgAMAAIALGeHZQAACAAXAAMkA2EkAwgAQ0oYAG1ICQwuAFFAAQCCAS4A DAAEACxnh2UgADMAAAACABgAEQBCKgZDShgAbUgJDHBo/wAAAAA0AFBAAQCSATQADAAEACxn h2UgADIAAAAIABkAAyQDYSQDEQBCKgZDShgAbUgJDHBo/wAAAAAuACBAAQCiAS4ADAAEANUw wzC/MPwwAAAQABoADcYIAAI5EHIgAQJHJAAEAENKEgAaAClAogCxARoADAAFANow/DC4MGp1 91MAAAAAAAAAAPANAAAGAAAqAAAAAP////8DAAAABCH//wEAoHqZAAAh//8CAKB6mQAEIP// AwCgepkAAAAAAIoEAAB3CQAA8A0AAAAAVAAAAAEAAQAAAAIAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsAAAAYAAAAGAAAABgAAAAbAAAAAAYAAI4LAADBDwAA 8BMAAAsAAAAPAAAAEQAAAAAGAAD1CQAAdQwAAMwPAAAXEwAA8BMAAAwAAAAOAAAAEAAAABIA AAAUAAAAAAYAAP8SAADwEwAADQAAABMAAADtCAAAGQkAAC8JAAAyCQAAXgkAAHQJAABYCgAA hAoAAJoKAADdCgAACQsAAB8LAAA7CwAAaQsAAIELAADwDQAAE1gU/xWEE1gU/xWEE1gU/xWE E1gU/xWEE1gU/xWEAAAAAAcAAAALAAAAEgAAABQAAAAbAAAAEyGVABMhlP+VgA8AAPA4AAAA AAAG8BgAAAACCAAAAgAAABAAAAABAAAAAQAAABEAAABAAB7xEAAAAP//AAAAAP8AgICAAPcA ABAADwAC8OoDAAAQAAjwCAAAAAcAAAAQBAAADwAD8IgDAAAPAATwKAAAAAEACfAQAAAAAAAA AAAAAAAAAAAAAAAAAAIACvAIAAAAAAQAAAUAAAAPAAPwUAMAAA8ABPBcAQAAAQAJ8BAAAAAI BwAAVRYAAMgoAAAFKgAAAgAK8AgAAAAIBAAAAQIAADMAC/AAAQAAfwCAAIAAg8PuAAAAvwMg ACAAHQAgAAgA1iEAAIYFAADvHwAAxwUAANUbAACKCAAA1RsAAIsJAADuGQAAjw0AAMIYAACU EQAAURgAAJkVAABRGAAAnRkAAMIYAACiHQAAyBkAAKYhAACKGwAAqyUAALAbAABsJgAApB8A AK8pAACFIAAArykAAOQjAACvKQAAxCQAAK8pAAC5KAAAbCYAAN4oAACrJQAAxioAAKYhAACn KwAAoh0AABgsAACdGQAAGCwAAJkVAACCKwAAlBEAAHsqAACPDQAAbigAAIsJAACUKAAAiggA AHokAADHBQAAkiIAAIYFAADWIQAAhgUAACMAIvEMAAAAkQMAAAAAAAUAAAAAAAAQ8AQAAAAA AAAAAAAR8AQAAAABAAAADwAE8HQAAACyBArwCAAAAAcEAAACCgAAcwAL8CoAAAB/AAQABABY AQAAAAB/ATkAOQC/AQEAEQD/AQAACAA/AwAAEAC/AyAAIAATACLxBgAAAL8BAABgAAAAD/AQ AAAACAcAAFUWAADIKAAABSoAAAAAEfAEAAAABQAAAA8ABPBCAAAAMgAK8AgAAAAOBAAAAgoA ABMAC/AGAAAAvwMgACAAAAAP8BAAAADgEAAAtRcAAJwYAAAlIAAAAAAR8AQAAAACAAAADwAE 8FoAAABCAQrwCAAAAAkEAAACCgAAUwAL8B4AAABEAQQAAAB/AQAAAQC/AQAAEAD/ARAAEAC/ AyAAIAAAAA/wEAAAALQUAAByGAAAtRQAAI0aAAAAABHwBAAAAAUAAAAPAATwWgAAAEIBCvAI AAAACgQAAEIKAABTAAvwHgAAAEQBBAAAAH8BAAABAL8BAAAQAP8BEAAQAL8DIAAgAAAAD/AQ AAAA5REAABwcAAABFAAAOB4AAAAAEfAEAAAABQAAAA8ABPBaAAAAQgEK8AgAAAALBAAAAgoA AFMAC/AeAAAARAEEAAAAfwEAAAEAvwEAABAA/wEQABAAvwMgACAAAAAP8BAAAABpFQAAQxwA ADQXAAA4HgAAAAAR8AQAAAAFAAAADwAE8EIAAAASAArwCAAAAAEEAAAADgAAUwAL8B4AAAC/ AQAAEADLAQAAAAD/AQAACAAEAwkAAAA/AwEAAQAAABHwBAAAAAEAAACOBQAA8A0AAAgEAAAA AAAAHAEAAMAhAADMFAAAlEAAAAAAAAAAACYAAAAwAAAAjgEAAJQBAACVAQAAlwEAAJgBAACq AQAAqwEAALwBAAC9AQAAxQEAAMcBAADMAQAAvgMAAMIDAADtAwAA8QMAAFwEAABgBAAAywUA AM8FAAB0CAAAeQgAAIMIAACHCAAAiAgAAI0IAAAqCgAALwoAAKsKAACzCgAAtAoAALgKAADn CwAA5wsAAGgNAABuDQAA1g0AAN4NAADhDQAA6w0AAO4NAADxDQAABwAcAAcABQAHAAUABwAF AAcABQAHAAUABwAFAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH AAQABwAEAAcABwAHAAcABwAHAAAAAAA5AAAARAAAAEsAAABlAAAAbQAAAG4AAACOAQAAqgEA AKsBAADGAQAAxwEAAMwBAAC8CQAAvwkAAMYJAADMCQAA5wsAAOcLAABoDQAAeg0AANYNAADe DQAA4Q0AAOsNAADsDQAA7g0AAPENAAAHAAcAOgAHADoABwAHAAUABwAFAAcABQAHAAcAOgAH AAcABAAHAAQABwAHAAcABwAFAAcABwD//xQAAAABACAAdwBDADoAXABEAG8AYwB1AG0AZQBu AHQAcwAgAGEAbgBkACAAUwBlAHQAdABpAG4AZwBzAFwAdQBzAGUAcgBfAGMAbwBtAG0AbwBu AFwAQQBwAHAAbABpAGMAYQB0AGkAbwBuACAARABhAHQAYQBcAE0AaQBjAHIAbwBzAG8AZgB0 AFwAVwBvAHIAZABcABwg6oGoUmJgDVkdIN1PWFtXAFAAMgAgAFMARwAxADYAIABiAGUAaQBq AGkAbgBnACgAUABhAHIAdABpAGMAaQBwAGEAbgB0AHMAJwAgAEkAbgBmAG8AKQAxAC4AYQBz AGQABQAnWUVO3U8gAK5pMABMAEgARAAtADAAOgBVAHMAZQByAHMAOgBvAGsAdQBiAG8AOgBH ADQALQBUAG8AZABhAHkAOgBQAGEAcgB0AGkAYwBpAHAAYQBuAHQAcwAtAGkAbgBmAG8ALgBk AG8AYwAFACdZRU7dTyAArmlLAE0AYQBjAGkAbgB0AG8AcwBoACAASABEADoAcAByAGkAdgBh AHQAZQA6AHQAbQBwADoANQAwADEAOgBUAGUAbQBwAG8AcgBhAHIAeQBJAHQAZQBtAHMAOgBB AHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABQAGEAcgB0AGkAYwBp AHAAYQBuAAUAJ1lFTt1PIACuaUsATQBhAGMAaQBuAHQAbwBzAGgAIABIAEQAOgBwAHIAaQB2 AGEAdABlADoAdABtAHAAOgA1ADAAMQA6AFQAZQBtAHAAbwByAGEAcgB5AEkAdABlAG0AcwA6 AEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAFAAYQByAHQAaQBj AGkAcABhAG4ABQAnWUVO3U8gAK5pOgBNAGEAYwBpAG4AdABvAHMAaAAgAEgARAA6AFUAcwBl AHIAcwA6AG8AawB1AGIAbwA6AFQAbwBkAGEAeQAgAC0AIABHADQARAA6AFAAYQByAHQAaQBj AGkAcABhAG4AdABzAC0AaQBuAGYAbwAuAGQAbwBjAAUAJ1lFTt1PIACuaToATQBhAGMAaQBu AHQAbwBzAGgAIABIAEQAOgBVAHMAZQByAHMAOgBvAGsAdQBiAG8AOgBUAG8AZABhAHkAIAAt ACAARwA0AEQAOgBQAGEAcgB0AGkAYwBpAHAAYQBuAHQAcwAtAGkAbgBmAG8ALgBkAG8AYwAF ACdZRU7dTyAArmlLAE0AYQBjAGkAbgB0AG8AcwBoACAASABEADoAcAByAGkAdgBhAHQAZQA6 AHQAbQBwADoANQAwADEAOgBUAGUAbQBwAG8AcgBhAHIAeQBJAHQAZQBtAHMAOgBBAHUAdABv AFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABQAGEAcgB0AGkAYwBpAHAAYQBu AAUAJ1lFTt1PIACuaUsATQBhAGMAaQBuAHQAbwBzAGgAIABIAEQAOgBwAHIAaQB2AGEAdABl ADoAdABtAHAAOgA1ADAAMQA6AFQAZQBtAHAAbwByAGEAcgB5AEkAdABlAG0AcwA6AEEAdQB0 AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAFAAYQByAHQAaQBjAGkAcABh AG4ABQAnWUVO3U8gAK5pQwBNAGEAYwBpAG4AdABvAHMAaAAgAEgARAA6AFUAcwBlAHIAcwA6 AG8AawB1AGIAbwA6AFQAbwBkAGEAeQAgAC0AIABHADQARAA6ADAANAAwADUAXwBCAGUAaQA6 AFAAYQByAHQAaQBjAGkAcABhAG4AdABzAC0AaQBuAGYAbwAuAGQAbwBjAAUAJ1lFTt1PIACu aUsATQBhAGMAaQBuAHQAbwBzAGgAIABIAEQAOgBVAHMAZQByAHMAOgBvAGsAdQBiAG8AOgBU AG8AZABhAHkAIAAtACAARwA0AEQAOgAwADQAMAA1AF8AQgBlAGkAOgBQAGEAcgB0AGkAYwBp AHAAYQBuAHQAcwAtAGkAbgBmAG8AXwBCAGUAaQBqAGkAbgBnAC4AZABvAGMABQA2VDAeIAY6 yP8P/w//D/8P/w//D/8P/w//DwEAAEwQRBcACQT/D/8P/w//D/8P/w//D/8P/w8BALRNPlYc q1R1/w//D/8P/w//D/8P/w//D/8PAQA+ZNFh1oaOsv8P/w//D/8P/w//D/8P/w//DwEAOxOp bhYinsb/D/8P/w//D/8P/w//D/8P/w8BAAMAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAMYAAAP hLMBEYSJ/hXGBQABswEGXoSzAWCEif5vKAECAAAADv8BAAAABAABAAAAAAAAAAAAAAAAAAAA AAADGAAAD4RoARGEmP4VxgUAAWgBBl6EaAFghJj+bygAAgAAACkAAgAAAAAAAQAAAAAAAAAA AAAAAAAAAAAAAxgAAA+EdwERhIn+FcYFAAF3AQZehHcBYISJ/m8oAQIAAAAO/wEAAAAAAAEA AAAAAAAAAAAAAAAAAAAAAAMYAAAPhGgBEYSY/hXGBQABaAEGXoRoAWCEmP5vKAECAAAAATAB AAAAAAABAAAAAAAAAAAAAAAAAAAAAAADGAAAD4TQAhGEMP0VxgUAAdACBl6E0AJghDD9bygA AgAAAC4ABQAAADsTqW4AAAAAAAAAAAAAAAAATBBEAAAAAAAAAAAAAAAAtE0+VgAAAAAAAAAA AAAAAD5k0WEAAAAAAAAAAAAAAAA2VDAeAAAAAAAAAAAAAAAA//////////////////////// /////wUAAAAAAAAAAAAAAAAA//8FAAAAAAAAAAAAAAAAAAAAAAB9AQAAKQIAAPENAAAAAAAA AQAAAAEAAAD/QACAAQDnCwAA5wsAADwkpQsBAAAA5wsAAAAAAAAAAAAAAAAAAAMAAwB8BEkD AhAAAAAAAAAA8A0AAGAAAAwAQAAABwAAAEcGkAEAAAACAgYDBQQFAgMAAAADAAAAAAAAAAAA AAAAAQAAAAAAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAADUGkAECAAACAAUA AAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAAADMGkAEAAAACCwYE AgICAgIAAAADAAAAAAAAAAAAAAAAAQAAAAAAAABBAHIAaQBhAGwAAAA7BpABAAAAAgAFAAAA AAAAAAAAAwAAAAAAAAAAAAAAAAEAAAAAAAAASABlAGwAdgBlAHQAaQBjAGEAAAA5BpABhgMC AQYAAwEBAQEBAwAAAAAADggQAAAAAAAAAAEABAAAAAAAi1tTTwAALf8z/yAADmYdZwAAPwaQ AQAAAAIHAwkCAgUCBAAAAAMAAAAAAAAAAAAAAAABAAAAAAAAAEMAbwB1AHIAaQBlAHIAIABO AGUAdwAAADs1kAGBAAIDBgkAAQEBAQGvAgCw+3zXaTAAAAAAAAAAnwAIAAAAAABCAGEAdABh AG4AZwBDAGgAZQAAACIABAAxCIgYAPDQAgAAaAEAAAAAQPiDZlAMhIYu1IOmBgBgAAAAAAIA AGkLAAADAAUAAAAEAAMQGAAAAFUBAACdBwAAAwADAAAAEAAAAAAAAABhJQDwEAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAClBsAHtAC0AIAAHjAAAAAAAAAA AAAAAAAAAAMOAADyCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAE0CAAAAAAkzg3EA8BAA398AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAASAD//xIAAAAAAAAABQBOAGUAdwAgAFEAAAAAAAAACQBUAG8AbQAg AFcAYQBsAHMAaAAFACdZRU7dTyAArmkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAD+/wAAAwoBAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAA AACIAQAAEgAAAAEAAACYAAAAAgAAAKAAAAADAAAAsAAAAAQAAAC8AAAABQAAANAAAAAGAAAA 3AAAAAcAAADoAAAACAAAAPgAAAAJAAAAEAEAABIAAAAcAQAACgAAADgBAAALAAAARAEAAAwA AABQAQAADQAAAFwBAAAOAAAAaAEAAA8AAABwAQAAEAAAAHgBAAATAAAAgAEAAAIAAADp/QAA HgAAAAYAAABOZXcgUQAAZh4AAAABAAAAAGV3IB4AAAAKAAAAVG9tIFdhbHNoAAAgHgAAAAEA AAAAb20gHgAAAAEAAAAAb20gHgAAAAcAAABOb3JtYWwAcx4AAAAOAAAA5aSn5LmF5L+dIOam rgAAbx4AAAACAAAANgCn5B4AAAAUAAAATWljcm9zb2Z0IFdvcmQgMTAuMQBAAAAAAEA6aQ0A AABAAAAAACyEYQYTxAFAAAAAAED8DXAWxAFAAAAAAODgkMEXxAEDAAAAAwAAAAMAAAAAAgAA AwAAAGkLAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA /v8AAAMKAQAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQk5cIACss+a5EAAAABdXN1Zwu GxCTlwgAKyz5rmQBAAAgAQAADAAAAAEAAABoAAAADwAAAHAAAAAFAAAAjAAAAAYAAACUAAAA EQAAAJwAAAAXAAAApAAAAAsAAACsAAAAEAAAALQAAAATAAAAvAAAABYAAADEAAAADQAAAMwA AAAMAAAA6AAAAAIAAADp/QAAHgAAABQAAABMdWNlbnQgVGVjaG5vbG9naWVzAAMAAAAYAAAA AwAAAAUAAAADAAAAAw4AAAMAAAAEAQoACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAA AAAeEAAAAgAAAAYAAABOZXcgUQAGAAAATmV3IFEADBAAAAQAAAAeAAAABgAAAFRpdGxlAAMA AAABAAAAHgAAAAcAAADpopjnm64AAwAAAAEAAAAAAAAQAwAAAwAAAAAAAAAgAAAAAQAAADgA AAACAAAAQAAAAAEAAAACAAAADAAAAF9QSURfSExJTktTAAIAAADp/QAAQQAAAMgCAAAqAAAA AwAAAGYAGQADAAAADAAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAHwAAAG0AYQBpAGwAdABvADoA YwBjAHMAYQBjAG8AbgB0AGEAYwB0AEAAYwBjAHMAYQAuAG8AcgBnAC4AYwBuAAAAAAAfAAAA AQAAAAAAAAADAAAABAB6AAMAAAAJAAAAAwAAAAAAAAADAAAABQAAAB8AAAAdAAAAbQBhAGkA bAB0AG8AOgBzAGgAZQBuAHkAYQBxAGkAbgBAAGMAYQB0AHIALgBjAG8AbQAuAGMAbgAAAAAA HwAAAAEAAAAAAAAAAwAAABAAdQADAAAABgAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAHQAAAG0A YQBpAGwAdABvADoAagBpAGEAbgBnAGgAbwBuAGcAQABjAGEAdAByAC4AYwBvAG0ALgBjAG4A AAAAAB8AAAABAAAAAAAAAAMAAAAEAHoAAwAAAAMAAAADAAAAAAAAAAMAAAAFAAAAHwAAAB0A AABtAGEAaQBsAHQAbwA6AHMAaABlAG4AeQBhAHEAaQBuAEAAYwBhAHQAcgAuAGMAbwBtAC4A YwBuAAAAAAAfAAAAAQAAAAAAAAADAAAAEAB1AAMAAAAAAAAAAwAAAAAAAAADAAAABQAAAB8A AAAdAAAAbQBhAGkAbAB0AG8AOgBqAGkAYQBuAGcAaABvAG4AZwBAAGMAYQB0AHIALgBjAG8A bQAuAGMAbgAAAAAAHwAAAAEAAAAAAAAAAwAAAJdumFQDAAAACggAAAMAAAABBAAAAwAAAAEA AAAfAAAACgAAACdZplO5ZU1PB2hMcjAAMAAxAAAAHwAAAAEAAAAAAAAAAwAAALReb34DAAAA EwgAAAMAAAACBAAAAwAAAAEAAAAfAAAACgAAACdZplNNT25/B2hMcjAAMAAyAAAAHwAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAA AwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAA AAARAAAAEgAAABMAAAAUAAAAFQAAAP7///8XAAAAGAAAABkAAAAaAAAAGwAAABwAAAAdAAAA HgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsA AAAsAAAALQAAAC4AAAAvAAAAMAAAADEAAAAyAAAAMwAAADQAAAA1AAAANgAAADcAAAA4AAAA OQAAADoAAAA7AAAAPAAAAD0AAAA+AAAAPwAAAEAAAABBAAAAQgAAAEMAAABEAAAARQAAAEYA AABHAAAASAAAAEkAAABKAAAASwAAAEwAAABNAAAATgAAAE8AAABQAAAAUQAAAFIAAABTAAAA VAAAAFUAAABWAAAA/v///1gAAABZAAAAWgAAAFsAAABcAAAAXQAAAF4AAABfAAAAYAAAAGEA AABiAAAA/v///2QAAABlAAAAZgAAAGcAAABoAAAAaQAAAGoAAAD+////bAAAAG0AAABuAAAA bwAAAHAAAABxAAAAcgAAAP7////9////dQAAAP7////+/////v////////////////////// ////////////////////////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH//////////wMAAAAGCQIAAAAAAMAA AAAAAABGAAAAAAAAAAAAAAAAgPyaGw0YxAF3AAAAgAAAAAAAAABEAGEAdABhAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgACAf// /////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYAAAC9gQAA AAAAADEAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAOAAIBAQAAAAYAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAVwAAAEsXAAAAAAAAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgECAAAABQAAAP////8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIioAAAAAAAAFAFMAdQBtAG0A YQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA KAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGMA AAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0A YQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIBBAAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAawAAAAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgD///////////// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAEAAAD+//////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////AQD+/wIAAQD///// BgkCAAAAAADAAAAAAAAARhQAAABNaWNyb3NvZnQgV29yZCCVto+RAP7///9OQjZXEAAAAFdv cmQuRG9jdW1lbnQuOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA= --------------020305050802080009070500-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Tue Apr 6 13:24:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08794 for ; Tue, 6 Apr 2004 13:24:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAuI7-0007rX-LW for megaco-archive@odin.ietf.org; Tue, 06 Apr 2004 13:23:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36HN5of030081 for megaco-archive@odin.ietf.org; Tue, 6 Apr 2004 13:23:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAtLx-00061B-SB for megaco-web-archive@optimus.ietf.org; Tue, 06 Apr 2004 12:23:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27164 for ; Tue, 6 Apr 2004 11:17:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAsKn-0007mb-00 for megaco-web-archive@ietf.org; Tue, 06 Apr 2004 11:17:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BArzc-0004Np-00 for megaco-web-archive@ietf.org; Tue, 06 Apr 2004 10:56:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BArUj-0000s2-00 for megaco-web-archive@ietf.org; Tue, 06 Apr 2004 10:24:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BArUf-0005Ao-9f; Tue, 06 Apr 2004 10:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAgOY-0005gB-V4 for megaco@optimus.ietf.org; Mon, 05 Apr 2004 22:32:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07176 for ; Mon, 5 Apr 2004 22:32:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAgOV-0002iu-00 for megaco@ietf.org; Mon, 05 Apr 2004 22:32:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAfve-0007OA-00 for megaco@ietf.org; Mon, 05 Apr 2004 22:03:08 -0400 Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1BAfa4-0004In-00 for megaco@ietf.org; Mon, 05 Apr 2004 21:40:48 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i361emWR027828 for ; Tue, 6 Apr 2004 03:40:48 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 6 Apr 2004 03:40:47 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 2CQBX2F0; Tue, 6 Apr 2004 03:41:10 +0200 Received: from ericsson.com (sealwa04-208.sw.ericsson.se [130.100.249.208]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 2A5WM43M; Tue, 6 Apr 2004 11:39:42 +1000 Message-ID: <40720AA2.9000101@ericsson.com> Date: Tue, 06 Apr 2004 11:40:50 +1000 X-Sybari-Trust: 227f4e00 272a6e05 0d802f51 00000139 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: megaco ietf Content-Type: multipart/mixed; boundary="------------020305050802080009070500" X-OriginalArrivalTime: 06 Apr 2004 01:40:47.0790 (UTC) FILETIME=[2F5D84E0:01C41B78] Subject: [Megaco] ITU-SG16 Q.3 [Fwd: Notice of the Beijing meeting (11-14 May 2004)] Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format. --------------020305050802080009070500 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello all, For your information, please find attached the invitation to the next SG16 meeting Q.3 meeting where H.248 will be discussed. If you are interested in attending it is important to sort out the visa issues as soon as possible. Regards, Christian -------- Original Message -------- Subject: Notice of the Beijing meeting (11-14 May 2004) Date: Thu, 1 Apr 2004 03:37:37 -0500 (EST) From: OKUBO Sakae To: itu-sg16@external.cisco.com CC: Pierre-Andre PROBST *** This notice and the host's information as attached will be *** *** placed at . *** To Experts of ITU-T SG16 Questions F, G, K, 2, 3, 4 and 5/16 Cc Mr. P-A. Probst, Chairman of SG16 Mr. M. Matsumoto, Vice-Chairman of SG16 Mr. S. Campos-Neto, ITU TSB Mr. L. Jiang, MII Ms. Y. Shen, MII Mr. C. Hansen, Rapporteur for Q.B/16 , Mr. P. Luthi, Rapporteur for Q.1/16 De S-H. Jeong Rapporteur for Q.F/16 M. Euchner Rapporteur for Q.G/16 L. Lehmann Rapporteur for Q.K/16 P. Jones Rapporteur for Q.2/16 C. Groves Rapporteur for Q.3/16 S. Okubo Rapporteur for Q.4/16 R. Gilman Rapporteur for Q.5/16 ------------------------------------------------------------------- Subject: Notice of Joint Rapporteur Meeting in Beijing, China Date: 31 March 2004 ------------------------------------------------------------------- Dear experts of Questions F, G, K, 2-5/16, The subject meeting of ITU-T SG16 experts will be held in Beijing, China at the kind invitation of China Academy of Telecommunications Research of MII and China Communications Standards Association. Details of the meeting are contained herein. Please note that Q.B/16 and Q.1/16 may meet concurrently and we will have joint sessions with these Questions in that case. 1. Date ^^^^^^^ 11 (Tuesday) - 14 (Friday) May 2004 Meeting will start at 9:00 AM on the first day Closing around 18:00 on the final day 2. Venue ^^^^^^^^ GUANGZHOU HOTEL No.A3, Xi Dan Heng Er Tiao, Xicheng District, Beijing, China Tel: +86 10 66078866 Fax: +86 10 66085998 Post Code: 100031 3. Topics (tentative) ^^^^^^^^^^^^^^^^^^^^^ 1) Review of the relevant group activities 2) Q.F/16 Quality of Service and End-to-end Performance in Multimedia Systems - Progress work for: * Annex N H.323 * H.priority * H.trans.cont 3) Q.G/16 Security of Multimedia Systems and Services - Progress work for: * H.235 Annex G * other study items in the living list (TD-71/WP2, January 2004) 4) Q.K/16 Mobility for Multimedia Systems and Services - Further elaboration TD-53/WP2 (January 2004) - Mobility aspects of presence service; co-ordination with Q.2/16 - Study of new service features - Follow up workplan 5) Q.2/16 Multimedia over packet networks using H.323 systems - Progress work for: * H.460.tppr * H.460.trans * H.460.relreq * H.gaam * H.323 Annexes I & N * H.323 Annexes Dv3, Gv2, Ov2 * H.sms * H.presence 6) Q.3/16 Infrastructure and interoperability for Multimedia over packet networks - Progress work for: * H.248-subseries * H.245 v11 * H.341 7) Q.4/16 Video and data conferencing using Internet-supported services - H.350-series maintenance - Addition to H.350-series - Presence use scenarios - Study of new service features 8) Q.5/16 Control of NAT and Firewall Traversal for Multimedia Systems - Progress NAT/firewall traversal methods 9) Interaction with other groups - NGN - Others 10) Future work plan 4. Documents ^^^^^^^^^^^^ /// Registration of the document: by 23:59 UTC, 30 April 2004 /// /// Distribution of the document: by 23:59 UTC, 4 May 2004 /// /// Use the ftp site (or e-mail reflector) for distribution /// 1) When you are going to submit a document, please notify Paul Jones , document manager of this meeting, as soon as possible, by 23:59 UTC, Friday 30 April 2004 at the latest. Document number AVD-nnnn will be allocated. Early indication of your submission plan is welcome and encouraged. Note: Prefix "AVD" comes from Audio, Video and Data. 2) You are advised to include a header as follows: ------------------------------------------------------------------ | | | ITU Telecommunication Standardization Sector Document AVD-{nnnn}| | Study Group 16 {Version m if relevant}| | Q.F, G, K, 2-5/16 Rapporteur Meeting {Date}| | Beijing, 11-14 May 2004 | | | | SOURCE*: { } | | TITLE : { } | | PURPOSE: {Proposal, Discussion, Information, Report, etc.} | | | | _________________________ | | | | | | | | *Contact: Name, e-mail | ------------------------------------------------------------------ Note: A template for the AVD document can be found at: This may be modified and used for the purpose of document submission at this meeting. 3) File format: Use of Word, PDF, ASCII or HTML is recommended. 4) All the contributors are requested to distribute their documents as early as possible, at least 7 calendar days in advance of the meeting (23:59 UTC, Tuesday 4 May 2004 or before) by posting them at either of the following: - Uploading via FTP Site: ftp3.itu.int/ User ID: avguest Password: Avguest (Note the uppercase 'A') Directory: avc-site/Incoming - E-mail reflector E-mail address: itu-sg16@external.cisco.com To subscribe: Send e-mail to majordomo@cisco.com In the body of the message, put: subscribe itu-sg16 Please avoid the use of reflector when your document is voluminous. 5) Input documents can be retrieved from /0405_Bei directory of the ftp site once Mr. Jones has an opportunity to put them into place. The documents will also be available through the following URLs: http://ftp3.itu.int/av-arch/avc-site/0405_Bei/ ftp://avguest:Avguest@ftp3.itu.int/avc-site/0405_Bei/ 6) The document distribution / presentation at the meeting will be all electronic. Participants must bring along a laptop and 802.11b wireless card in order to access the documents. 5. Logistic information ^^^^^^^^^^^^^^^^^^^^^^^ The meeting will be hosted by China Academy of Telecommunications Research of MII and China Communications Standards Association. Please refer to the participants' information document kindly prepared by the host, which is available at: 6. Registration ^^^^^^^^^^^^^^^ To register your meeting attendance, please send the Meeting Registration / Hotel Room Reservation Form provided by the host in the participants' information document to Ms. Jiang Hong with copy to Ms.Yaqin Shen and CCSA by 28 April 2004. 7. Hotel Room Reservation ^^^^^^^^^^^^^^^^^^^^^^^^^ You are recommended to stay at GUANGZHOU HOTEL, the meeting place. For room reservation, please indicate the dates of your stay in the Meeting Registration / Hotel Room Reservation Form. We are looking forward to meeting with you in Beijing. Sincerely yours, Seong-ho JEONG Martin EUCHNER Robert GILMAN Paul JONES (document manager of this meeting) Christian GROVES Sakae OKUBO (meeting organizer of this meeting) Leo LEHMANN ---------- --------------020305050802080009070500 Content-Type: application/msword; x-mac-type="5738424E"; x-mac-creator="4D535744"; name="Participants-info_Beijing.doc" Content-Disposition: inline; filename="Participants-info_Beijing.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAdAAAAAAA AAAAEAAAdgAAAAEAAAD+////AAAAAHMAAAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////spcEAiUAJBAAA+FK/AAAAAAABEQABAAEABgAA 8BMAAA4AamJqYp12nXYAAAAAAAAAAAAAAAAAAAAAAAARBBYAIioAAPcUAQD3FAEA1g0AAAAA AAAZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8A AAAAAAAAAAAAAAAAAAAAAGwAAAAAAOYCAAAAAAAA5gIAAOYCAAAAAAAA5gIAAAAAAADmAgAA AAAAAOYCAAAAAAAA5gIAABQAAAAAAAAAAAAAAD4DAAAAAAAAPgMAAAAAAAA+AwAAAAAAAD4D AAA4AAAAdgMAABwAAACSAwAALAAAAD4DAAAAAAAAMxMAAKgBAADSAwAAXgAAADAEAAAiAAAA UgQAAAAAAABSBAAAAAAAAFIEAAAAAAAApwgAAAAAAACnCAAAAAAAAKcIAAAAAAAA8BIAAAIA AADyEgAAAAAAAPISAAAAAAAA8hIAAAAAAADyEgAAAAAAAPISAAAAAAAA8hIAACwAAADbFAAA IAIAAPsWAABQAAAAHhMAABUAAAAAAAAAAAAAAAAAAAAAAAAA5gIAAAAAAACnCAAAAAAAAAAA AAAAAAAAAAAAAAAAAACFCAAAIgAAAKcIAAAAAAAApwgAAAAAAACnCAAAAAAAAB4TAAAAAAAA WQoAAAAAAADmAgAAAAAAAOYCAAAAAAAAUgQAAAAAAAAAAAAAAAAAAFIEAAAzBAAA0gMAAAAA AABZCgAAAAAAAFkKAAAAAAAAWQoAAAAAAACnCAAADAEAAOYCAAAAAAAAUgQAAAAAAADmAgAA AAAAAFIEAAAAAAAA8BIAAAAAAAAAAAAAAAAAAFkKAAAAAAAA+gIAACIAAAAcAwAAIgAAAOYC AAAAAAAA5gIAAAAAAADmAgAAAAAAAOYCAAAAAAAApwgAAAAAAADwEgAAAAAAAFkKAAA0BgAA WQoAAAAAAACNEAAAjgAAAEwSAABoAAAA5gIAAAAAAADmAgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1BIAAAAAAAAAAAAA AAAAAL4DAAAUAAAAbYCRvAAAAAA+AwAAAAAAAD4DAAAAAAAAswkAAKYAAAC0EgAAEAAAAAAA AAAAAAAA1BIAABwAAAAzEwAAAAAAADMTAAAAAAAAxBIAABAAAABLFwAAAAAAAFkKAAAAAAAA SxcAAAAAAADUEgAAAAAAAFkKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAABADDAA8A5QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQYXJ0 aWNpcGFudHOSIEluZm9ybWF0aW9uDQ1JVFUtVCBTRzE2IFJhcHBvcnRldXIgTWVldGluZw0x MSAtIDE0IE1heSwgIDIwMDQgDUd1YW5nemhvdSBIb3RlbCwgQmVpamluZywgIENoaW5hDQ0N VmVudWUgYW5kIER1cmF0aW9uDUNoaW5hIEFjYWRlbXkgb2YgVGVsZWNvbW11bmljYXRpb24g UmVzZWFyY2ggb2YgTUlJIGFuZCBDaGluYSBDb21tdW5pY2F0aW9ucyBTdGFuZGFyZHMgQXNz b2NpYXRpb24gaGF2ZSB0aGUgaG9ub3IgdG8gaW52aXRlIHRoZSBwYXJ0aWNpcGFudHMgdG8g dGhlIElUVS1UIFNHMTYgUmFwcG9ydGV1ciBNZWV0aW5nLCB3aGljaCB3aWxsIGJlIGhlbGQg aW4gR3Vhbmd6aG91IEhvdGVsLCBCZWlqaW5nIGZyb20gMTEgdG8gMTQgTWF5IDIwMDQuIA0N R1VBTkdaSE9VIEhPVEVMDU5vLkEzLCBYaSBEYW4gSGVuZyBFciBUaWFvLCANWGljaGVuZyBE aXN0cmljdCwgQmVpamluZywgDUNoaW5hDVRlbDoJKzg2IDEwIDY2MDc4ODY2DUZheDoJKzg2 IDEwIDY2MDg1OTk4DVBvc3QgQ29kZTogMTAwMDMxIA0BICAgICAgICABDSAgICAgDQ1SZWdp c3RyYXRpb24NVGhlIFJlZ2lzdHJhdGlvbiBDb3VudGVyIGZvciB0aGUgbWVldGluZyB3aWxs IGJlIHNldCB1cCBpbiBmcm9udCBvZiB0aGUgbWVldGluZyByb29tIGF0IDA4OjMwIGhvdXJz IG9uIFR1ZXNkYXkgMTEgTWF5IGFuZCB3aWxsIHJlbWFpbiBvcGVuIHRocm91Z2hvdXQgdGhl IG1lZXRpbmcuDQ1UcmFuc2ZlcnMgZnJvbSBBaXJwb3J0DUd1YW5nemhvdSBIb3RlbCBpcyBs b2NhdGVkIGluIHRoZSBkb3dudG93biBhcmVhIGFuZCB0aGUgY2VudGVyIG9mIEJlaWppbmcs IGFwcHJveGltYXRlbHkgMzAga2lsb21ldGVycyBmcm9tIHRoZSBhaXJwb3J0LiBBIHRheGkg ZmFyZSBmcm9tIHRoZSBhaXJwb3J0IHRvIHRoZSBjaXR5IGNlbnRlciAodGhlIG1lZXRpbmcg dmVudWUpIGlzIGFyb3VuZCBSTUIxMzAuMDAgliAxNTAuMDAgeXVhbi4gQSBzaHV0dGxlLWJ1 cyBmYXJlIGlzIGN1cnJlbnRseSBSTUIxNi4wMCB5dWFuLiANDUhvdGVsIEFjY29tbW9kYXRp b24NVGhlIHBhcnRpY2lwYW50cyBhcmUgcmVjb21tZW5kZWQgdG8gbGl2ZSBpbiBHdWFuZ3po b3UgSG90ZWwuDVJvb20gUmF0ZTogIFJNQjY1MC4wMCB5dWFuIHBlciByb29tIHBlciBuaWdo dCAoaW5jbHVkaW5nIGJyZWFrZmFzdCkNVGhlIGxvY2FsIHNlY3JldGFyaWF0IHdpbGwgY29v cmRpbmF0ZSBib29raW5nIG9mIGFsbCBob3RlbCByb29tcyBmb3IgcGFydGljaXBhbnRzLiAN DSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDUVsZWN0cmljYWwgU29ja2V0IERlc2ln bg1UaGUgc3RhbmRhcmQgcG93ZXIgc3VwcGx5IGluIENoaW5hIGlzIDIyMCBWb2x0cyA1MCBI ei4gIFBsZWFzZSBicmluZyB0aGUgYXBwcm9wcmlhdGUgYWRhcHRlcnMgYW5kIGNvbnZlcnRl cnMuDSAgICAgICAgICAIDTMgcGluIHNvY2tldA0NDQ0NDQ0NDQ0NQWlycG9ydCBUYXgNQWly cG9ydCBUYXggaXMgUk1COTAuMDAgeXVhbi4NDUZvcmVpZ24gRXhjaGFuZ2UgUmF0ZQ1QYXJ0 aWNpcGFudHMgYXJlIHJlcXVlc3RlZCB0byBjaGVjayB3aXRoIGxvY2FsIGJhbmtzIG9yIGZp bmFuY2lhbCBzZXJ2aWNlcyBmb3IgbGF0ZXN0IHJhdGVzLiBVU0QgMS4wMCBlcXVhbHMgYXBw cm94aW1hdGVseSBSTUI4LjMwLg0NV2VhdGhlcg1EdXJpbmcgTWF5IHRoZSBhdmVyYWdlIHRl bXBlcmF0dXJlIHZhcmllcyBmcm9tIGFwcHJveCAxNSB0byAyNSBkZWdyZWVzIENlbHNpdXMu IA0NSW5zdXJhbmNlDVRoZSBwYXJ0aWNpcGFudHMgYXJlIHJlcXVlc3RlZCB0byBraW5kbHkg bWFrZSBuZWNlc3NhcnkgYXJyYW5nZW1lbnRzIGZvciBpbnN1cmFuY2UgYW5kIG1lZGljYWwg Y292ZXJhZ2UgYmVmb3JlIHRyYXZlbC4gDQ1XaXJlbGVzcyBBY2Nlc3MNQXMgdGhlIG1lZXRp bmcgd2lsbCBiZSBhbiBhbGwtZWxlY3Ryb25pYyBtZWV0aW5nLCBubyBwYXBlciBjb3BpZXMg b2YgdGhlIGlucHV0IGNvbnRyaWJ1dGlvbnMgd2lsbCBiZSBhdmFpbGFibGUuIFBhcnRpY2lw YW50cyBhcmUgcmVtaW5kZWQgdG8gYnJpbmcgdGhlaXIgUEOScyBhbmQgd2lyZWxlc3MgbmV0 d29yayBjYXJkcyB3aXRoIHRoZW0uIFdpcmVsZXNzIDgwMi4xMWIgYWNjZXNzIHdpbGwgYmUg YXZhaWxhYmxlIGluIHRoZSBtZWV0aW5nIHJvb20uDQ1Mb2NhbCBTZWNyZXRhcmlhdA1Ncy4g SmlhbmcgSG9uZw1Ncy4gU2hlbiBZYXFpbg1DaGluYSBBY2FkZW15IG9mIFRlbGVjb21tdW5p Y2F0aW9uIFJlc2VhcmNoDVRlbDogICs4NiAxMCA2MjMwNDM3Ng1GYXg6ICs4NiAxMCA2MjMw NDM2NA1FbWFpbDogIBMgSFlQRVJMSU5LICJtYWlsdG86amlhbmdob25nQGNhdHIuY29tLmNu IiABFGppYW5naG9uZ0BjYXRyLmNvbS5jbhU7IBMgSFlQRVJMSU5LICJtYWlsdG86c2hlbnlh cWluQGNhdHIuY29tLmNuIiABFHNoZW55YXFpbkBjYXRyLmNvbS5jbhUNDA1NZWV0aW5nIFJl Z2lzdHJhdGlvbiAvIEhvdGVsIFJvb20gUmVzZXJ2YXRpb24gRm9ybSANV1AyIC8xNiBNZWV0 aW5nDTExLTE0ICBNYXkgMjAwNA0NUGxlYXNlIGNvbXBsZXRlIGEgc2VwYXJhdGUgZm9ybSBm b3IgZWFjaCBkZWxlZ2F0ZSBhbmQgcmV0dXJuIGJ5IDI4dGggQXByaWwgMjAwNCB0bzoNTXMu IEhvbmcgSmlhbmcgICAgICAgICBUZWwvRmF4OiArODYxMC02MjMwNDczNQ1FbWFpbDogIBMg SFlQRVJMSU5LICJtYWlsdG86amlhbmdob25nQGNhdHIuY29tLmNuIiABFGppYW5naG9uZ0Bj YXRyLmNvbS5jbhUNV2l0aCBhIGNvcHkgdG8gTXMuWWFxaW4gU2hlbiBhbmQgQ0NTQToNICAg ICAgICAgICAgICAgICAgICAgICAgICATIEhZUEVSTElOSyAibWFpbHRvOnNoZW55YXFpbkBj YXRyLmNvbS5jbiIgARRzaGVueWFxaW5AY2F0ci5jb20uY24VDSAgICAgICAgICAgICAgICAg ICAgICAgICAgEyBIWVBFUkxJTksgIm1haWx0bzpjY3NhY29udGFjdEBjY3NhLm9yZy5jbiIg ARRjY3NhY29udGFjdEBjY3NhLm9yZy5jbhUNDUZpcnN0IE5hbWU6IAlfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQ1GYW1pbHkgTmFtZTogCV9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NDUNvdW50cnk6ICAgICAgICAgCV9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NDUNvbXBhbnk6IAkJX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0NQWRkcmVzczogIAkJX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0NVGVsOiAJCQlfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQ1GYXg6 CQkJIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0NRW1haWw6IAkJX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0NSG90ZWwgUm9vbSBSZXNlcnZhdGlvbg1D aGVjay1pbiBkYXRlOiAgICAgICBfX18gTWF5DUNoZWNrLW91dCBkYXRlOiAgICAgX19fIE1h eQ0JTnVtYmVyIG9mIG5pZ2h0czogX19fDQ1GbGlnaHQgaW5mb3JtYXRpb24NQXJyaXZhbDog ICAgICBfX19fX19fX19fX19fX19fX18NRGVwYXJ0dXJlOiBfX19fX19fX19fX19fX19fX18N DVNwZWNpYWwgcmVxdWVzdHMgaWYgYW55OiANDRNQQUdFICAVDQ0NE1BBR0UgIBQzFQ0NDQ0N AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAABoGAAAbBgAA OQYAADsGAAA+BgAAQAYAAEEGAABEBgAASgYAAEsGAABeBgAAZQYAAGgGAABpBgAAbQYAAG4G AABvBgAAcAYAAIMGAABpBwAAawcAAG8HAABxBwAAcgcAAHUHAAB5BwAAegcAAH0HAAB+BwAA jQcAAI4HAADMBwAAzQcAAOEHAADiBwAA9gcAAPcHAAAICAAACggAAAsIAAATCAAAFAgAABoI AAAbCAAAHAgAACkIAADMCAAAzQgAAOQIAAD0CQAA9QkAAAkKAABVCgAAWAoAAIkKAACKCgAA 3goAAN8KAAD8CgAA/QoAABYLAAA7CwAAPgsAAIMLAACOCwAA/fr38/Hz8fPx8/Hz8fPx8wD6 AO3n7eft5+3n7eEA39zYAN8A3wDUy/rC1Ly4AO24AO24AO3n7eftuN+yAO3n7ecAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAKPioBQ0oWAG8oAQAHNQiBQ0oYAAo1CIFDShgAbygBABAD ajczAABDShgAVQgBbygBABADagAAAABDShgAVQgBbygBAAdDShgAbygBB21IFARvKAEEbUgU BAADbygBCgwqB0NKGABvKAEACjUIgUNKFgBvKAEABzUIgUNKFgADPioBBj4qAW8oAQAEQ0oc AAAEQ0oYAAAEQ0ooAEEABgAAGgYAABsGAAA5BgAATQYAAG4GAABvBgAAcAYAAIMGAAB9BwAA fgcAAI4HAACrBwAAxwcAAM0HAADiBwAA9wcAAAoIAAAVCAAAGwgAABwIAAApCAAAzAgAAM0I AADkCAAA9AkAAPUJAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7 AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA7gAA AAAAAAAAAAAAAO4AAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAA AAAAAAAAAADpAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADpAAAAAAAA AAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA4AAAAAAAAAAA AAAAAO4AAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAA AAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAAAAAAgQAAMkABGE8ABghPAAYSQAAAQQAAMk A2EkAwAHEAADJAASZGgBAQBhJAAABBAAAyQAYSQAAAEQAAABDwAAGgAGAAAaBgAAGwYAADkG AABNBgAAbgYAAG8GAABwBgAAgwYAAH0HAAB+BwAAjgcAAKsHAADHBwAAzQcAAOIHAAD3BwAA CggAABUIAAAbCAAAHAgAACkIAADMCAAAzQgAAOQIAAD0CQAA9QkAAAkKAABGCgAAigoAAN4K AADfCgAA/QoAABYLAACECwAAkAsAAJ0LAACeCwAAnwsAAKALAAChCwAAogsAAKMLAACkCwAA pQsAAKYLAACnCwAAswsAANELAADSCwAA6AsAAGwMAABtDAAAdQwAAMYMAADHDAAA0QwAAEkN AABKDQAAWg0AAF0OAABeDgAAcA4AAH8OAACODgAAug4AANAOAADlDgAAdg8AAHgPAACsDwAA vA8AAMwPAADNDwAAIRAAAFAQAACcEAAAwxAAACERAACDEQAAhBEAALQRAAC1EQAA5hEAAOcR AAAcEgAAHRIAAEsSAABMEgAAexIAAHwSAACnEgAAqBIAANISAADTEgAA/xIAAP39/fv7+/v7 +/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/v7+/sAAPkA9/kA9/sA9fn7+/v7 +/v7+/v7+/39+/Ly8vLy8vLy8vLy8vDy+/Ly8vLy8vLyAAIBAQAFAhAADQEDAhkAAwIXAAMC GAADAhAAAwIPAABf9QkAAAkKAABGCgAAigoAAN4KAADfCgAA/QoAABYLAACECwAAkAsAAJ0L AACeCwAAnwsAAKALAAChCwAAogsAAKMLAACkCwAApQsAAKYLAACnCwAAswsAANELAADSCwAA 6AsAAGwMAABtDAAAdQwAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA7gAAAAAAAAAA AAAAAOwAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB FwAABAAAAyQDYSQDAAQYAAMkA2EkAwABAAAABBAAAyQAYSQAABuOCwAAjwsAAJALAACcCwAA nQsAAKcLAACoCwAAswsAANELAADSCwAA0wsAAOgLAABsDAAAbQwAAG4MAAB0DAAAdQwAAMYM AADHDAAAyAwAANAMAADRDAAASQ0AAEoNAABaDQAA+A0AABMOAABcDgAAXg4AAHAOAADtDgAA 7g4AABgPAAAZDwAAGg8AAC8PAAAwDwAAMg8AADMPAABdDwAAXg8AAF8PAAB0DwAAdQ8AAHYP AAB3DwAAqg8AAKsPAACsDwAAsA8AALIPAACzDwAAvA8AAL4PAAC/DwAAwQ8AAPPt6e3l4d3a z+Hdys/h3QDaxuHdAL/PAOnt6cYA6bbprLantum26Z22p7bpm5iUkZSRlJGNmI0AAAAHQ0og AG8oAQRDShwAAAdDShwAbygBBENKIAAAAzUIgRMCCIEDakl+AAAGCAFDShYAVQgBCDBKEQBD ShYAABMCCIEDam59AAAGCAFDShYAVQgBEANqAAAAADUIgUNKFgBVCAEADUIqAENKFgBwaAAA AP8HNQiBQ0oYAAhDShYAbUgJBAAVQioAQ0oWAE9KAwBRSgMAcGgAAAD/BENKFgAABzUIgUNK HAAHNQiBQ0ooAAdDShgAbygBBzUIgUNKFgAKNQiBQ0oWAG8oAQAYA2oAAAAANQiBQ0oWAFUI AW1IAARuSAAEN3UMAADGDAAAxwwAANEMAABJDQAASg0AAFoNAABdDgAAXg4AAHAOAAB/DgAA jg4AALoOAADQDgAA5Q4AAHYPAAB4DwAArA8AALwPAADMDwAA/QAAAAAAAAAAAAAAAPgAAAAA AAAAAAAAAADzAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAAD4AAAAAAAA AAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAA AAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAA AAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAMgAAAAAAAAAAAAAAADIAAAAAAAAAAAAAAAA pAAAAAAAAAAAAAAAAAAAIxAAJGQEAQAAJWQEAQAEJmQEAQABJ2QEAQAETsYIAAAA/wQBAABP xggAAAD/BAEEAFDGCAAAAP8EAQEAUcYIAAAA/wQBBAAAIw8AJGQEAQAAJWQEAQAEJmQEAQAB J2QEAQAETsYIAAAA/wQBAABPxggAAAD/BAEEAFDGCAAAAP8EAQEAUcYIAAAA/wQBBAAABBgA AyQDYSQDAAEZAAAEAAADJANhJAMABBAAAyQAYSQAAAEXAAATwQ8AAMMPAADGDwAAyg8AAMsP AADMDwAAzQ8AAA8QAAAREAAAWBAAAFkQAACDEAAAhBAAAIUQAACaEAAAmxAAAN0QAADeEAAA CBEAAAkRAAAKEQAAHxEAACARAAA7EQAAPBEAAGgRAABpEQAAahEAAIERAACCEQAA5REAAOgR AADvEQAA+BEAABsSAAAcEgAAHxMAACATAADVEwAA1hMAANcTAADdEwAA3hMAAN8TAADhEwAA 4hMAAOgTAADpEwAA6hMAAOsTAADsEwAA7xMAAPATAAD9+f359f0A8wDuAObu4+4A7gDb7uPu AO4A0+7j7gDRANEA0QDRANHKx8rHAMrHysDKxwDRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADDBKGwBtSAAEbkgA BAAEMEobAAANA2oAAAAAMEobAFUIAQNvKAEPAgiBA2ragAAABggBVQgBDwIIgQNq/38AAAYI AVUIAQQwShEAAA8CCIEDaiR/AAAGCAFVCAEJA2oAAAAAVQgBA0gqAQcMKgdDSiAAB0NKIABv KAEEQ0ogADTMDwAAzQ8AACEQAABQEAAAnBAAAMMQAAAhEQAAgxEAAIQRAAC0EQAAtREAAOYR AADnEQAAHBIAAB0SAABLEgAATBIAAHsSAAB8EgAApxIAAKgSAADSEgAA0xIAAP8SAAAAEwAA FxMAAP0AAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAO8AAAAAAAAAAAAA AADkAAAAAAAAAAAAAAAA2QAAAAAAAAAAAAAAANkAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA +AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgA AAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAA AAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAA AAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAA AAAAAAAAAAAAAAAKEAADJAARhAgHV0RYAmCECAdhJAAAChAAAyQAEYSwBFdEkAFghLAEYSQA AAgQAAMkABGEiwtghIsLYSQAAAQQAAMkAGEkAAABEAAAGf8SAAAAEwAAFxMAADQTAABQEwAA ZxMAAGgTAAB7EwAAnBMAALoTAAC7EwAA1RMAANYTAADhEwAA6RMAAOoTAADsEwAA7RMAAO8T AADwEwAA/Pz8/Pz6+vz8/Pr6+Pj4+PX4+gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAhoADQECAQEAAwIQAAUC EAANAQATFxMAADQTAABQEwAAZxMAAGgTAAB7EwAAnBMAALoTAAC7EwAA1RMAANYTAADfEwAA 4BMAAOETAADsEwAA7RMAAO4TAADvEwAA8BMAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA 8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYA AAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADoAAAA AAAAAAAAAAAA4gAAAAAAAAAAAAAAAOAAAAAAAAAAAAAAAADoAAAAAAAAAAAAAAAA4gAAAAAA AAAAAAAAAOAAAAAAAAAAAAAAAADgAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAABRoADoRoAV2EaAEACBoAGIT4/xmEAQAbJmAj JAIABBAAAyQAYSQAAAgQAAMkABGE0AJghNACYSQAABIgABaQAYAfsNAvILDgPSGwigUisIoF I5DfBCSQ8QMlsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAADczAABEAGQAAAAAAAAAAAAAAAAAAAAAAAAAAAAtD5sK6APoAwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAADwAE8FAAAACyBArwCAAAAAEEAAAACgAAQwAL8CwAAAAEQQEA AAAFwRQAAAAGAQIAAAD/AQAACAAnWaZTuWVNTwdoTHIwADAAMQAAAAAAEPAEAAAAAAAAgGIA B/CTMgAABgbGv0ZaNuw6+Hel+9YN5MWp/wBvMgAAAQAAAEQAAAAAAAAAAG4e8GcyAADGv0Za Nuw6+Hel+9YN5MWp/4lQTkcNChoKAAAADUlIRFIAAAEDAAAAtQgDAAAAbOtqJQAAAwBQTFRF AAAA/////6ir/7u+/Zih/nyO/46c8nSL/6y76V1932F96WiG+X2Z6Iec015743mW4FyD22yM /+Dp3WGI5mmQ7JWw44Wk4qS7+7LS4ou5+87o/+D1//v+/uz/6t79+Pb/8fH/s7f4y876fpT/ jaD7gJj3dpX/eZT0fZv/dpr+f6X/k7T5tc//nMf9r+n8y/H+nOvy1/3/5/7/9P//etDKfuPU Z7yjkenOq/bc0PvocM+dqN2/Vrd8IiwmZ7x1RrBWdYJ2T61JVbVOXrZXf9B2YMBUktSIbspa XrtHXKxHpN6Vw/C4YWxdcr1JitRa5/7Y3/nI1e7A+P/yhcZIpNFy1/2s8v/j+v/0mtFPyPWE 9v/osudXXmVOw+dqS1E6v9pRcHVdlpmL3uTD/P/u/f/y/f/t4+tiNjcn+PyA//6a/v6v//69 ///E///I///N///QsbGR///T///V///W///Z///b///c///f///h///i///k///n///o///r 5ubU///s///u///x///z///0///2///4///6///8///+5uSq/fza8O27//3Y//3a7OixqaaB mZZ1wb+h8e7M//3n/PbC9fDC//rN//rR//zf//zh//3r1MyP//e7XFlF/vjJ2tfDLSsez8mn //jW//nb//C0W1Q5/+yq//bW//jh/fHO//jnd2Y+jn1Y//La/9GJ/OK4/ujE/teiz7eZOigU Szsp/7dualI6/6BScGhi/6Nl/+/lHxYR/9S7/8Wn//38/4ZL/4lZ/6yL/3lF/5x4/+DV/2o7 /4pn/1Qq/3tZ/1o5/2tJ/0Yn/zcc/417/5eJ/46C/y0b/y0d/ygZ/ykd/ywh/y4i/y0i/zMk /zgp/0g9/1NK/2pf/3t0/8/M/yEX/yMc/ycd/ych/ykh/y4k/zgz/yom8/Pz7u7u7e3t4+Pj 3d3dzMzMu7u7qqqqoKCgnJycmZmZiIiId3d3ZmZmZWVlY2NjXFxcRERENTU1Li4uIiIiHBwc ERERDAwMAQEB////9TZdnQAAAQB0Uk5T//////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////AFP3ByUAAAABYktHRACIBR1IAAAADGNtUFBKQ21wMDcxMgAAAANIAHO8AAAt 4ElEQVR4Xu2dCZycZZ3n6w2nxJmAyOpAi0O4D1FgZQRdd7kEUZiDOdBBdGZdDEmA7e6qeqve t955jzp1UVFnUUd0ZBZRFAPZFV2UhCSQcERQSCfhCkd0jZJG04nQIUY++/0971vd1Z2q6qrq gDCfftLdqa5+36fe5//87+tJWTMjNQMCawYG1gwMoIMZPJiBgdjhDB7MwGAGD2LFYIYWZmAw gwcztFA3E2b4wQw/qPODmlUpl4vFEv9VLata42WtWK1UqkXet2rVmlVkVEoW3xUrLBWLfqlc Kxd1f9Wq8LNWrtZqvC6FxWJolcOK3jR/1SjrR61SK9eqZe4OA7/g+oWC73iF0HcKBX66oR8W Q88PSlzKJH4Qhr7ve0HB8wtBoF/5wQs/5FXglYIgLJTCICyWy6VSpVQuVyq1XkxgPWhMC9Vq mafjP1bCT/PspVK8ArOAainibVZaLPF5ZT/0g4q5jHXr7/wQDCpRqRRY1ZBr9Xu1VCnXSjVm 4hmLlbAUea7Pl5tnuG42n8662Wwm4zj92XTattPpnMNsnu/xBUS8AqAKvCD0wmLJL7JPoV9i lsCvsvzAisJKiQcCBuYjOoZBAi1WYF6N84NiAxzHVz8OhhpLFBiqtXIpYjPqe20+Or4BULKx oeeEYbVWqhZL7BIwqBUr1ZJVqobFasjK2EnwwM15ju3YjKydyacBQX86faVjM03e81yXb8/3 XQdI+KEb8e2HpVKxEDJXKeRlKbIqjCp4UALHLIOQU45qRWipzauWK9VqkVUJBvxXqlZKodYR VYtcUq4w4UTc4i1za9niSpanh0hWPgYDM3PJLXh5cMqAJHkkpoSegEiF9UfFKAQZXMcHGXIF J5ezbQckACDZgUy/lUq5fgAEimADkHCgCQilAC6YUeRfFFYhyNCKSiJh6IGHKbFBU41kl9mQ WsUSyguFG/HA7KcWDo4nSDI2Z6XG1hdB7ahYC4s8VCUIIl+faiaKiSceVb/gecBHL+uYlVzE 5CXQiOdnJ32/5DrZTCGXtbPZXDqXGcgNDGbSPFHKsp2840SeV8g7eRtQRBAEmMAQ1xBrKEEt QY3fvRCsZFcYYl3toFB/yppVFt8bH8ID89sY9TdlLbVKpSyar9RqkHyRb/YlpkCuZ1bAajai Bgxsh8kgmxgyYJR5ZeBaKYmkICgQrwpbA+cLLrTgurbrpNMZ2AEwyOXTdt5zCwXHzTm+4zqF ogcrgTYCFs3wqiU2oswLQFAqG6agBbSAQbwHEFGlBqsvAYOKNshwPb4TfsAqIAK9Cd8Tr58E CR7a7CpX8LdqBQ4KRxjnQg2Xi+S1IRM2xTBQ3tSOVaKoyHNHJT9wMrmcFuzY+Yydy8MaYjzI Zu20uKbhoIUwdAPRA3wwlEAoVSOL2yMYDG9ADRUgara2I9EwdpHQfVwuCE4xq2gxAGIdBoJE xB7C8gzGT/5c2IThNPXJzEuRQS0C+qy+XIyE0ECx6GYdO1ew7fwArDEjxmhgMGBn0gPZQRvW 6RUQCyU/RETAC7SXReipKCQrWVGENGBG3u5EMkrgiaWzjVVuAhvY75gnJmNsU5vx12posCRZ W7UEjypH5bAZxLgsQNdosicJIlli5TD3GoIN7AbjHb/g2K7t5OyCgUE63Z9lpDM2xAAlQDEO zLMAKYD9yIegIhSwIMpiGUYFP+8EBmbD9BCssIqyYnaP1+MwaI9HMfvT3ppv5DQAAQboV5MA AZC9oFjnqjHV1VlnDEURJRsBX0BOIOx9H/6XLyBQHD+mBTuTs53BtJ1zPDcAGZCQYn8whCKv yrBjsAjhEEZI6VhasCbJ7q7HBDxIJFmLaUqTQCQyACWbDAQw+9VCWDM7D8sApcvIOIR/EDo+ fM+2kRCZrIFBJj2YTmcHB/mZzhaQM26ALpk3coGbQoAPGMWUJGbQVybLsRaQ4JPLoB+UUBTX A3lKxQl40B6CuqU505kItJrFQ6LXtFLaDG80qCS+CzZAz1EVUesEKESOF+NBLp1FazQqg3ij 7wIFvhAGBQjBjbyiJKVUtaKwKWbOHelIFkLEyAW01zLMFOW/Gz9SR0wX1o8Uhdh3AWkMKxgB AhIooDGhRYfScjBLgAF6QM7OJbQAArjpbD6Tz/XnAEIOxuhLNwoDWECxhGqAcg8tlCuI5Lrq 0wkd1KRLIa75EUrKB93BoJOPEKqgREZNYGBuNwIzwYNYEos5wehLqIaBl4/1g3QGvdkGFzLZ TD9C0047qI6FGMNCL6hgNYAC4AFGHdab5oy53VTIjBCFgWJgyJaBiyBTu8KDqT4h+XulEvot YcCKY22dbZCyFEk95zlE1LA5N6YFp5ApuBkPWpDCaOezGSfrGpPRj3y4TTWoonIj3YRQLUaz P6CuF+GiRSwCQBHBipilcxjIahw3ANqCo+ph17S9QjtmGIyoMZtK+cxcjDAPvTChBSRDNgNL ABVyfA1msCkLLrZibHN51QB+io6E/pp8Esg0FSbwidInkWjQguEHsJIJcqHDbZ7yskoJXt9o hE66Q+xI2jUKKZyhbC3ASJJnAgIK0UKMrmyjOef5RnFEQOaEDDk7iz3pBS6KQeRLTYz3ZBza U9GCQFDmbrcM+zEatxALAdeFfjDl6uMLZCHCrtsNpJN8FfyLIuuKVMpjX4TXCEwDAwxrHwvC YemgAoRg5wYkJSANz0VJLxqjYbIc6EA5kFhEW0UkIhTLFWRSl3KhQxiEtSL8oMOLwQVg4CcG ivBZMAgL+bwTuHk346JIp3N4Wzw4Ql4iAmUJ8SC7o2Hfk+VPJR2hllLJRxJjbsMSKljx3egH jbpvO4DjMEGLFKdpNeqSDAvEYHJ/KoXKYxDIDMEgYMs9N4+W7OTzIgPoAWU6l0Z39gogcjUx Ss0d4iyG1U5FDahG4AGqaSAPCHQBb5lAC+13rnF6nrLpiN8XDBrccO0NWnhgOpUS5Yg5oTsY GFgVdpuBS4pRKOTtvO0UMJ5dN59FYYIdYgXHM09QDqYEgmgO55Y8BTynrC1uif1I3Y32MBh/ rilnRV2yrKtSKSPgq/JRAA1mr8hhiR0lZ1vaRYe2szgRPBviwKB2+OMUUyOB2QjUjyiILLxw SMFCWMyhFwRw3mKEllCNMOLhw7FsxNtnNJc280qYoKSj0STY2uxaNjR5uyOgxo4Ny8qkUhOu ZxaYqjxG6Mi+PI7OILIBAZHOD9r5tJtJ42CLdn3eZJbrL/mnmy75/Kc++NWP/WvhY1+95JJ/ /Oyll156zecu/do/X3o9/osyjvEyGqJxBYWB7H8em3uncsnq73JTxLjWHA9qn+8OBmYq0HIg lUo4qKwZM7ssa54RZ7o87J4PU8ix/7bvYF7DKvCtRLvCOTFRP/b7D/7D9/71km8s/s7oP33i q9d8/fr5N//omhs/+6P/8rEf/W/UgRqECjdEYUQ5w9E/piNNtXFotGImsdOkBQys/9GKRtog GE8ADNAWxdGIXkh7T1lYlAABvy1AkKMdXQHPIi4GFw8jtraDo3UX0Rg7qizvG5/Y/p8uuf7r /1D94Deu/8RXL700qF7z9VuXfuzrN3/v67fKhxNCCZUIHVuuWDxiiX4wlUyJGQ/uuxhfWqz1 f8bvy3E6JSdouMDIhYQU9TmGH8AZIkMSYt0QNLwgn4Mz2m464DVeF88NJ/lNgCL393/vmq/8 n5sHv/PV//v9G77yvX/77Pe+YN38/bD2nZvdm7//BcztMPJkexV9lHOMrjFduRN+AEvwUPHb wABaiGllKu48EULggaubjFyIdSRMWuSrZfxtAQo+7kTCMo4NFsAREROokLmch6NGboD6iHcy XPy1f1l8U7V/8eJ+68obll55Q6m68GtWdKNTve5aGc5oBrIW4IiYzsYbPa4nyuM+xfYZJtoa D26KGXxb5tr4CcnT26kUHrTYw6sf4omyqcBTXMBIMrhxkfAa+kJIdM4LMKJxqeFiAy/xEes2 s/yETfZZffWdiF+MjyqMVkECOaEEDQUF6zAoozso1tbGKAI+RAtjptiOFhLG1Aaa4Q9/6CfL N7MhTrxxX5uZXQE83Ao8qrAVxoD3AO9qzrcLOO4lJfEtOYQYEG51//4U+xeDhTgqgrVc9WG4 zB+VjOczFmeaSAYsAbLJWm5j/CT5nBYw+EwHPPGm5auWrbqLrzuwkuORk67cMBIYKNJbgeRx L8QhlFLRDbV0+Zpt1o/aLA3KxxNTv9v4s7sfMQxiKqhWQKcp+WNLPPjMS1MlM9gP3LlooVPp CwduvGvVLcknwROBgXkC8474gR6maoUV3JK4z4tFhS5LVV9hvjAiFI27hWBTseRFkdegIk+E wK9+88KLv2e8+MJvftUWMOOPDQJiu1VEY1OMifut/VKQbuktk5SdXWb51v234SuLR/WW+xfF rwwt1Ic015QJXaE7y92DjV8qeqIGxGQZfcELXYKU2BGYlvAIeVYUEjdAM/pFMmq/2f6753+9 OfWLzb9+/nfbt7TjdY1bp1ixJusOBnKu6KY+9IO2XPXWe29snPnL98ZAwIeigPvYmExRSmxQ aARzR0oUdKFYPPwBTzvDJikBOy1R9cYe4JdbX/rtZt7V+pZu3vbS1l+2XlVz/0F7CTH5KcVc wYUp+IF/7+V9tdq3zZ4H3+W/MAZCoREP9NQJizKuT+QjLjMyD1DQcKKyPYYzoDuSmiH1SZiA lIB7EoxWiD8eta07R6ylsT0EEGojO7e2XlMTGMjl12SUTzz++Le9XX9owfu+1p4nPrCoz/rS 48sWLylatyxa/tjiqpVZcQWzQQv5+pNPnL1uUcCj5PMiyggM5AZRAkrB8XJh4BaIxHqokzAH KRh1HN7y0oiZM1V/ppGXtrREhGZ4YLJR6qM+a+n4I+ceOveIE1vDAKRujW/Wd+8kfrL8p/Ot 5YsKq/LV+1fwGctv40cDDBotMi1XtIl7Sb5MpQmNMyrIA30alyJeUUViC4QekKNEv+Mn+NX2 38YvxmBgbdvekjE2eeymaAAIDu3rWzr3KIDQYq2fbguDB0D8viU/vrG6ZNmSO8vWY3fyhOEy tKMW/MBwJnznmDZl+DQCsiHMrbih3MJyCooGAvkXuaKupf/md+IFjTBYuvl3v2m1Q01gYPKS jFurYcw98rhqba71p4cfdUorGHyhHQzCFVcxW+WuZf6SO29fac9apl+tu+bXrHxzflAnBPC/ HJoHibEzCVNJsQYGDq6mPPk/uFvy2UJJfmmNF54XL5iAB0uff6ELGDS7tHLY0ceIF8w9+ui3 t4IBzK3Vp1jWTXeG1k0PPrCkYC1ZeeeKoLrhwZ/sYVlLbrMsdGXZC2Nj0iysBZW5qbSCOlCc KuSpEZHGzZgngy2e5sVfx/9DCmPT/frF7mCwCzmUjj/uCMt6u/XWI4+d2woGbjsY3HF7ddbP Vy66a1mwZOWyFdasexff9cjj4R0/qFrcNllPbHhYGbeG2wsW8fsmC1CjopQOk5mhSDyiAtdb fMnvx0lh7KE2/74NDKYylXRr9bCjjreswyzrmKNOagUDpz0Mrnp09XzLenyRYHDLo/Ot2hNP 3n7HD4xsDFvjgVmtfiAbDCgasqUUr4QOUBbITyBLg7SeBJq//8WuePCLdjBoBZ4J7x969HEn 8cbco4/oawUDkLr1VLfcft3PVy+wrAdW3gYM7lpN8tXjT96+5HZ0hfa0YGAQcwLhATDQLwY0 Bg8KRlMiXSnnKIstwYMYBoYU6k/VAQwa5eGuS6mW5x5+3NtOfNuxRx7am1z45orc8kfuu7Hv gXtuv3/VymXA4IlH7swsQTj6bWCgxAKJffNAdS49xqxBibDkxnalSEGBhwQGMS1MgEFbWmic v/VG9s098uijjj3iT83UTS9riwfW/VfUbl18tQUMVq5aee/qAeuLNxSsVZcjIBP/QX3Oltgk K0IXYdDEYCBZkExeJ4+DJecRmJLxEM8S88QEBMmE3fLEpmvsO3QuSNAaBm35gfXgItlBtRgP Vq3u10S5ZfBxbwp7ofW2KEMOPwPcQGmcJrc5kTAvPJ/AIIaEmaKtbEzYzpTmIjpO7JhpsVMg devnZb2GX9XxwKgHyxdhbnUOg8nMWwF73MTQQYCfEL2RLKX4CdCRlo4tPgZCJzoSqedtVjDh Ty3WirLTZoba8uX6gJ8ktLCQ13evuJaf0MKYRd0MwpMeq+FX0gNJ4sXLJr8KDIGfiVz41XYQ Yexx9KL2fEe68iQwt7GzeuEHtb5li3mUB9fft/rR1Y/eAwzC2JYGD+xG2LW3vBqvlIWgDBZ5 nxENeBvrtGDJZpoAg5GXWqrKsW3ZiYbQ8OEtnrK9zWRZX773DmDw5EM/W7v+4dULrcLjsf8A PGjrP2iNW6Fyh2GNcQqrWIKyCcyQ7Ty+UymrQ9u5U0poyQ/a80Sm91c9WPtf9963evV9K26z Z92LTEhg0JYWWj0XJSaSEWSnVfEyk68kejAeag18KCl4QjxSv+3QhzL5s1qzhxZ4MCUMsA+e 2HPDrbfeessdy++97drE8w0rHfel6YGT/ZsaOc0ThgoC4n0m5kIYYpyqaluML+0X8qWlOvWl KSOjcXQNg/Y80UxdrdyyfNWqVctuX3TlmO8fWuiRHyBUlAdIzjAMQe53RsMKevCpvvy0kHzC F9JfChs+DJ6Yafzsznmi7iIeDhbIYhA/qNsLna/FkEp3l8fk1fymtrZz64+BFnrEAzMnSiO0 4Bcj0vaicIwfdLOs3QiDtrZz82cicqUYCwbU+OgKD1TBgQPJuJRI6Fb+LuFETVuDUUyOD/EX ZXaTjkUA2tTDKbttHA/GlOtOXjRfUSd3Nr1mwnQ9z9LdjcIgk524W2GAEdzjmIDBPc7R7W0U KJqKsN2cr7zgxhtu4Ou6665bsGCBfixcuGDhFXxfeVV/ur+fHGS+stl+ChP4lyYD1Sb/lNSK boi34VpFGzATSpR7RUTdCKYq+AJ6k2ZCNnKJ7DNld4yPJFvaxNNMaVO5y9y8Th4Ud29j7vTU Ir6TSdtfQ0mOkmRIt8SZQGTSZGXDHCQwGYTUuZ8HUZmAAEMiKAtXOhYyldD2bsaD6S+o+xlI dqUkCP8KayG8oGQeJVaQXxKpLBanu5xQqmglvaek7ExidophqrBKWPSahIFh9mOZ2qRUBBAC G67kFdIJihasHm88sQYqbBuSWROkTFQ/BexVaqmJxmTjWEFm93vxB7ijrl2TFqv8LSWjk7VC JrgpWYvJQFFI0ruRnfyNEnXVbEscolaZOl8TxZkAgz/AQqbxkeNaFRX4qhllcRXy9eRvw71U QQewSJtWKguAgEsBF7KQKHsgEUnV0tRYkosj1jCGB2OOy2k81yt0qyGDujEDvqvkU1nvJhne UhheqVoEJEnGNFH7JEnDJAOjEYAEZFrUcD1QakqUsjdd+RVabLuPqUsc+GG8vxIM/EDiARbQ nW03ldHGopI2DVEgIsjwYlryqiRKRBANtDCe0/MqWGBXj6AcfJWKKWMlXpLQRMW/oL1cK/jb qFAtFwMVLaBJqKIQ8ZCEp0yWeBcfyMwwnoZeC8NJSMvavCn57DGfFEDl6r/7q3Ll48F/+69/ 9eEP/+2H/5bx5/XxFxp/+YG/ZPzFBPdBZ89TT92PqZtUfvoKKBe9biHwvwo08CuEgQr5YBEY EkhFrUFVthXYAcqBqQSpw6A7VTN50PGbRnjnv3cyx0vNLpqw7k5mmf41RLNVz2Q2NIFBtbtZ xx96dGRkNPntmu7maLj6DwADyohM4wtlLCQwGPchLbjhxhuvk9ovvf86VH60/SuuuvKqK/nq Tw8M9PffOJaDt2VkZMfo6I6REZPncg3vd+yfH1/2JycZy93Yzii+VOfA9xCCMDnIAb0xyeGC W8bBaDECFZVSC8lF6jtAAYMpwpTuPEYLrcsEm5AnfsNkqaM7Rnfu2LGT/wwMunn63QMDsT9x QnQeKulwsooNKX+nBljkY6X0hUJyyuXJ1yFhhUJkJEYZWaq8fbiF4W674MHUPGncdzo6Yo1u gRZicniFYNBgiJE9XDE9APgfJRHnovo0SD2Q2mSK4kldM9gQqdCsSlkLehNNKALZVahJfoOO 1EGgbQw44/6i0ZFNqc0jo8PbpwODySl9XWAT/UfKNcoDi6iFyt0yWpJRgVUoKHczlR85VUQB CKhCqY0aZHKR7ila8Rv4QTdWLn7DOi288OKotWXn9lQMgylzdZvi2HT4gelLpUA0P6ibUNsg 040JY0hORmqHVRxK0YMNTuBvrPpBGUSQ1lSjeD6Ku7yIFpTb0QUQGmjht9s2WZtGRrYaGHy2 2Q6edMLbTjy5LX1NAwZGP2YnTWZ3nJ4xxpRNwkpEgyklqWR9iAWFkWxnuAG6E3nO6kNFf4ku avsaljEeXx5FMmqMCgZ9zWBwwnFHHHnE8Sazs9XomRYQ8aj91CSg+0vSowari5dpcqK/qZZR XcncXPpq3Ewk6+uPcXGnLCmyl8pErLvTE5NVjPvQJ8CgGR6c8FYB562HtQPCNPBANhKkD19D 2Ekkmp4zJq+T0ih4INSQcSkNzNm0KSNED1OIHKWrRFjSCkuYZhXQgmkUN7U4GLuCwFDyestw /GLY6Aef3YUfvP24OJp0wrGnvAx4kEw5gYzV7aP+USJv2jgF6jdDlTRsQvlr1IuLPaq9CqpD wVNFZReLTy4ttcjR35UWTjiGFGdS+o47tg0iTC6H61AusP/0BioGZHVLMhYDDAHWWSsVoAcV cKoLXlQs5Gmok/UKYD/ckII+FedhZmJW4kOgb1lvvjR86E0BtwsM+o4/6qjDSWA6/KhjTtjt eCCrKfYZICHh61J2DDYLq9UwCQWBzfdz+Uyaann1E1MTIbmWEAxKdDY5XKpO7wEPWsFgVx3p sCOV1XjCUYcf9TLgQexThBVE6otDWW8kOGAh4hxQnInuNHgLQm9gYDDvypugYJQyNsQVKKLF H094rkdaGOcHEzd3V1o49JhjkYtHHHPMEUkmUzNs6IkW5MFHG6yiIquvhZwhKrpDHNRYuCr2 5C0wwdjBwS9m6V5G9xOUJOIqmMsoT+iIxsuippU94EHn/MA6DAQ4+ZhjD4/z2ZqPHmCQhAwa 8ndFAzSHUV4GBaLUP6nBn5oHFWg1dS1xHLlP6Efp00PEJPbqh1Eae4MBdnZTMdJEP+g77Jhj jj36iLltQFDtAQbKP5GRBM7LVSPal4fQtPPU7wq4ikBkSZauSl+d9vCpqeUeDQ/Vdo0KEHUl Vc8+04Gle7nQOS0w91vmJkmNLT/nnzu3nWPQG8RXFT/N8yhP5Ftd5OQg1AujN2JBqeoDrKgW M98coFsrbdVU2AkJoEGoAQC1L8KJHvGg1kIu4EdqstA+Rls4Ty4B6kA2qseWUIBlSgmoKzjq eFuBH+BSE1DEAGnsls9l2Pli4KqhRME0J3MDfvNdIUPQm37QIgej2tRemBrNklLxsQvbwUBx Q5UBq5UsHcZU5wXCmwZLsZSIDQaQQV3xwIrQq7hUyqvaXVqRmvNGrum5pkZ1fqlXudAqD6VH GPTAD0zXOVVwmM5jcVo3bT1kMhuSCNWrS173wLbpWIo8MDqBeIGHbKATE0JCQhLy6A0Pis13 qtacFqZEhC74QeNc6l+ahJV429RqgxTYz2h+0ATuMxgFZeFqHCCxyEsnR2dnNQ3Iq+ghyKnP lN8bDJALTRfWIx50wQ9M00HiR4qV0fSrIqaGSWB6ptFp2NTK41wEIAq9EXDj2mKgsDxRWKrC 4rhLIhSBjgqGe5ON3fHEKfGgG36QTGY6whqVCAvJNNwSFiALlFZBohH8UA14y3STUg6rp1iT 2msZHdkYzaIGNezmzZ5kI/ygmcdlaY+0cEPnspE9g/UpUkI4DWkgIzFp7Ji09zH+RDWVpPBH QTjiS2iFanpA9xcJQ6xFGYwmDCdY9EgLLXjiK8MPtPsRtgCOEGQgrW1wJspkotGRmCMqgmJv 5DEb9qhOqyYaqdZaysxQEb36smEywhBxJPUIg0oqNSmlNUbRHvGgG34Qm4Ym3cdUNSUVuUZ3 ksSk640EhBAlUgorC5c8lMkYMwO5j1TsoGp5IyV6hEErXblHGFzbOS2oibDREIwawA9RhmEO MWwkJOkjLY1Z8ROZxvQFo+BLWTdxF06MRpPLSM0L3dzp6oss6UFXhhaa2gu9waDWBR7E+IZP 2JR+G34QZ+bEkRX5RtTSRGkZlP7idqdxr1RpWloanJDSIMmAO4VXhByEIK8CGFid4oH8JZIG pjGxACAwAI240Fs8waIXiImyqNU5LM8oh9p0kN4EE9QywJQ6gAaoCxFY0LtcaCrwesODjmFg 1CC0YWXgKpwgmcCIuQNmEmAQw0QnMAHHEO3AdAwV+1Nvc/ZeHkQCb2pcLkqgvQq97HvFg6Zh qc91YO00AR494ya822oWtY41DS94oX+knGAVqNs4PJAkZFJvwHTcSrSHpLGLuCHMAASgW5zA wdEB5QBXiiEFozFACMRceoXBmO+28el7hAE9JDuAgek4ok7KprG3wX9pSKZjU8Kd0IwIIxNT VcNt4qqQPkbiu09/79nv+wCeMzK6DQroS4AwPXpNRWRvPLEpLfQIg854ojEOpAiK66EYK/cQ GOiUgHpDIAwoJSMpM09HJJCUyavT//MFl83/0Fnn2xhIxQAHolGWFWkCGESko93ME3uLN3ZI C3X/WYyCcf6U/AQ66EXtEjENdEaIDn2hAxRtY0lD8oJ3n/PReTXrtDPP+yTJiuoPJSSQhqzj bejSOA2eKLLcZfSIBx3SQozwJg9JPTSlBooaGnpVABE8aHFKhrKUChxx8d6LVS922jlnXni1 2pVLKaAXKXJBPhSUZ5zuvdJCsz6WS3uEwXjryRiqzXiiiSTKGBIZqKGcSToxXc3VetxoDViG iq8BHLwrohIQ/s/POvfPcOufdsY5FyygHaMMaqmKqgyVnkht6O7VkWovIwyMaiyprz6WJrIi 5zmVjSZNF0UYGaFScAEKEleLFHlOP/6PZ5155oXQwllnXnQ5lCDHkVk8TdjoTMlpJyBDr3jw SstG6cbSB9T1TZtuKt9jFdnwCVW4GQFBiz36suuQEKjfCxeedd6ZF4IHZ5510XzyMWwtXP32 CLp7TlotnHuMsYCtCJQm/KA3njjYkWzET6JoEsgMnht+gJWo8LKxG9Rj0ARbBSpVdaAryT/g /fV55wkGZ5x52afwKRBYKrhK0QzoPAhTyNGPsGc8aNrXtkda6O8IBoqhKbTOP8WWIHfSq1SR oPNoipxFYJyLcdECnI+0VJ1tFS648Mxz3vWO/3jmxZerQ4KaNsfHPOmUNJ0D5jm7lSda1/em J145NQyUhCyfMaox1TlgAT+kJooCZBKRgU4CHmknBgfY5rTxoGIYuPM/esEZZ13w0XmfolWI znuhLy2HetB4Ts0HgzyGRK/8oE4Lm0bI1n2OhByNHmGAXJhghjaDpDmRTFU5GIIKpKg3tNKT QQwlo1V9ox7JjpKnhDw8lfmhFdEqcuHl8+ZdPp8O1Tolz3PjTs30qnZyLg1aTZV4b3rimK6s LJzRbTFv+Nzu5geFL9dhHdtF3t0bvkWsPPaeqEhBvlISUGo6w8H429V8k+MfqP/WGQV3/OQn P3mArwf4+cATy79EcpJEgc5A47gfveRouZ5hUH+250a2Dj/3QpKOMo4HJ77zne9qn4jVwFHR kSaYHwkeVAsHHXDgAbNM21GTKONtmLPffgcc9EPloCEdjQMBgRCaPr44C/ChyXGGnoiTDM95 4ZbHHnro6TVrNq5Z8/BPn3r6qZ/exdEmThoE4HQ4WpI6A3lfbfw7xoMJTtTxJi6pbSOk6v4W ZBAeJE9/0unnXnjRued8oJnsaPIe/GCCqE1muXvOG/fbe9br59xtZCG+wVlzZjH2nvNDyUNF 2+U5lMNAyVcABAWIZHQlXnCAEcrwHY8+uX79uvVr1/I1NPSzoTVr7uI4BxpUe3SphgxIXaS9 Vq5Tnrhhzuw5/2HD2PNPhsG2BAYJLZz+95fncvM/0ikQkAtN8MCfc8CB+1p9b9hvjgpTANKG /e82ocvZf0RpjuKupFzJYYLfpFr21QPU9FDHolJEOQhptHDfI+uGhtauX//I0NNrh9auvP/+ xV+mcbnOtqA9syPCgD12CIM9Z+81a8+9Zr+pDoTxxhXCg9GRbdsbeeK7L7Stk8jBOvvczgqw gUETPNiwPyCwqocceMAGVoa82/uApdYhB7953wNmgxmQA9xQBQvKTVbaidqTy3MiRZGURD83 eO21Nz22cePQ2p/9bN3Q+p+t/fGidP8X7fQXadlOnzky1XIFmlUXOuSJe+xzd40NmDW7jgnj TRtS20d37BjdbhhrLeEHZ5/7jnecP98qnX7O33REDU1hsHTW/vv2HfIG6w0H7j/LeJHDff6I fph91h77HbiHORFT5oEsBoxg1a3KVUS9SqBY4h1PJOPna4aGhtatXbfxkfVrhu5/PB53cbCL WvkjHTjtJtsRHpT3Yu1vPvgtb34jT2HGeJO34eHhbdv40YAHp5x9znnnsfq/u/CcD3UEA/ps N+mDseeeVWsDQftZB+5pYuz+XnMOPuTgQ6y+Pf94X5GOcSbKnwgeqL000IjEGOQpfeLJZzZu 3Pj0k0+tWTsENazbuHHt+jVrnjLj6afuuYEz8nRyKkeocrpFR/pBdrbJH/jh3gfO+XgdBrZ5 MTxehiEo1PHg7+d95Ox3Wdb551zeJitxHDy016qLmQTC+m/WQfEVb9l/D0pUIfK9997jzXvN sqx9999AUFUudPWYJaYYh1cIsSlZXRXM3330YZjA+vVD6x4aWrdm7dMPP71x7dqNTz899Ay8 ceiZ1Yv7zQGqOvaJc386woO7Z+tRrL7yPnMS3pVKZc3zbQIDnh0RHgxLS0pg8KH3WdZ8OuSd fgEt4joYwGBCZXYsF765z0F/8id86utnfzueY8lBfRKTb3nj6wsm9Y4DbU3JLvnHNFFUKEGe 8qDkBg8+8xDC4P9tXLdu7ca1Qw+tvHf9xrWPrB1a89RDa4Y2blz309sGadg+OJBxOTjSdoD/ 1DpSOPsQy3r9wXy/PtHnxpvA8lBxvjajzg8GL/wzdIOT3nnOvA4AwCWNslEiOJGN+77uj//4 oEPeBBqYI8mqlb3nvPmQg98ES4z7sJNiYBzMkTkFEI+CKeFifOuxh9dsXPfw6hXrnlm9YuiZ Hy/KP/7kUytXPvXUj2977MlnnnnmqTuv/DSL1wEvwCIddAIDa88YLd/wuj0SLaGOB+btrVsn wcCaf/F7Tz/9Pede1mFJPzyRvRgfggHAjvbYa/aBr9tnDw+dB/0vsuxZ++y33xv3urvCqmnH jlw0VfYqV5PNjOWk8GNUXLLajNuuWLX6B3yvuNJfcs89ixbfd88PFi65Z+V9K++5c6E5EC+j DgR2uiM8iA11jbpa38I2Go/Jn2Kd0kV1UAubqSZhNCGVScn55uDNDgbuV6NO9MUPb/TrGrNJ uZw8w9S0sOsHtrIPe7MbJzvPepylA7i0umQGBh3xg13A9+8VD3quz3yN3jiBCye/vEaX0vNj N4PBNFjKa/7WXnjia37RkxYwA4Pe5MIMHvx7g8AMHmhHZ/hB1zDYNCpvyaa6rThtuthmqkN3 y3huk7XluZ5m6hYPUoLBtu1xZGl6Q76XkZ3PJR6Y6c3F3TuHLfoxbBkd7RqsPcDgly/sFhBY OGTjYeA63UEfCimNwyMjXc/WNQyeG9nx4i+n+8Dmfi2dnYtfTHds2Tny3PD2bcObh8caFnU8 ZdcwGN6qx94dY+RZ69mdzzITL6Y9NkMEozu3j+5MxQ0puhldwaDBkTx9QIxACvSTYWyf/mRE v9WVZMfIs8NdrUigqnV1B47k1Ii+8Cd3A+im1z4rjjg8vDX13G6YzNq8M7VJsY5N3cOga/0A 2k3Ci9MGgmVt32pt4ly13TGGR3caLB3e3NWuxoypywcABpt2JgkHXd66y+XDo6kdO+JY5fTH MGxgZMR6tusV9QKD50Y279yxZXcoCNamLakdqdHpk5UgOLzj2S2jO1IjLz8MNqdScLBN2/is aY9toAEbN5rqWqlp9tHDqS3btyFhRnd2/WDd0sKWeNd2BxoMK5mJsXtw6tlkV+o9WrqARLcw 6GLq18ql1RkYdM8TXyub28VzTtKRenZVv0ZvjCE1uY7mNbqYHh+7GQwC5agQmabVnNoKmaPw OEzZz5vsX1UHqIEv6YHxUIllF0jXxaVxpNs0zCXTQDXsqmgPVc9J1R6JeNQ0099JxXvqeaUS 70iZ/PojvW+UuOJH5ONmv/3uU99z6ruvGHSzV/Qr1p6h+X/GVooiGTkFuv53ln/QxaPvpkvJ vdNxtqalGYmXpnZP9Tmq16USqUyaWskrlTizkYxc0nCDInvlRY7rck6VOa+KhFwn8JyBz5/6 /osuuui8sz6TyaXTA3ZuID1oD2SyaY4/yHJgOrvsWZVO5UKzSvfdtOIJ02inSTpV+xYqVWhm o7aoavZCoy+V7wMIatmr5tgR8hBV4k/FblBQm0iyTv3QzqkHEAukSVrOPvWieVdEV8+74Nyv DaQZ2cF0f16HPgw4DliRz5Kg16Xd+HIsetKcbLppC6q6FPLM1PSIPmfqa0A7Gx14TUqKOu1z igDn2Kp4nyMLXdPXIsw7tLnQkZ6c/l3w8nnb+8D759VOOcnq+8AZX7mqf3AgPdAPKAYG+9OD /QPZdMZN56jte9XpB2RgK/2WUh319jGdbqjfVE8D8COMavHpbPQAVbGuydAH811oATpwgQgl CeBFSC4qCUf/cv55p5106sUfr512xl9fxe+OktHsXEaJyzk7k4Ng3FcjDMi2AvNpmw066EgN Mu7U+tMiDVe5qJAGvdNrLgySwpSiMpPJPjeneAYqTIgKjm87RRKTs577rfed8Z73fmSh9fZT z7h4IUm6PhBIp3NXK1vZd/L5tJPNU47SKT94BcjAVHGy2ArrZtmgg07UMH1uSNdVA0TyrkhK hxro78P61e+G5GyS1ItqeGVKFgJ1ufC8HKd6Bnnn/DMumleyTjz7vDM+ei1c0bEzmXRmALaI fHDMATF2FzzxFYEBH6I6XWp1EG6mik0bb+p2TatMZF5UUd9DWkGSlesELB2W4HkliECNvzjZ 1HRUdul8QzLqpz95wTyaYvQv/Jv3XwazyOUQA7l83iFdmUom0vOcrP1qwwMqVxH8pKWaimwf /idUYOdpfkUlt2pUSiVPwiIflVi9ClXpeqXafrogeRmVKykz3/YGbZKRnfzVl5128sknn3Ly Oy6ej1TIeKg//YPOQDqfVfp6wfHyLnnCrypaMIUKVK2pD7p6oaliyxy0AzeQpFACO8oPza3g fpHq81yOYvGpYi+4bgGMoIAFhKCclbT0XCGXsxec/973vAeeMI90TNv2cqTuc6mdzpClm83D Iznh7dUkF+KmHuAuGZhqgqWfOotMPcTV/IAXOocMMolghWgGSElVa8IIQArpsmgJTt4F4X3p ujklYc6fd9lHL7tsPoSRsbMeZ0Jl7UxWqcr2QDqT5crgVacfkHVK8a7Zb9oDggpQvinUpzJB beACtUVUtXacl6ua7YC6ZR3a50QuTZNBDhXuZWguXci6duZL//bFhdfagZ/LIgwpXYEDSCIa FSmT8zrMV36luOEf7nNeZfzgDwKIGRhY1v8H5WlhJXQul2QAAAAASUVORK5CYII3SgAARABk AAAAAAAAAAAAAAAAAAAAAAAAAAAAPg0DDOgD6AMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAA8ABPBQAAAAsgQK8AgAAAACBAAAAAoAAEMAC/AsAAAABEECAAAABcEUAAAABgEC AAAA/wEAAAgAJ1mmU01Pbn8HaExyMAAwADIAAAAAABDwBAAAAAEAAIBiAAfwk0kAAAYGDBY2 Qww8Mmg1SqzKGJEIvf8Ab0kAAAEAAAB7MwAAAAAAAABuHvBnSQAADBY2Qww8Mmg1SqzKGJEI vf+JUE5HDQoaCgAAAA1JSERSAAAA4gAAAM0IAwAAAJI0XAYAAAMAUExURQAAAP////eIi/ma nvurrv7i5PBrg9lcf9xnh+J4mOiVtvvH3/zh/P7t/v74/tnY2fHQ9NHH97Wx9JKm9niR8qHX +eP8/r35/fr+/pCRkZ2fnoKEg6HuxHvVn97+6WTDd9f72PL+8mNmYz9BP09QT7y9vF++Ucbj wXZ5dSgqJ4WWe6a6mfL+6oPMUJjcZURPPOv93pOkg1BaRjg5N7/yhhEUDWt1XdvvvOj3zfb+ 5iMkIW1ua6awi/P+1TU3L9j5Zur+ql1iTejzwfP9zvP9w/j+3iAhG/r+4vr+2vr+zvr+1vj+ eN7guP39n/7+yv7+zv7+0v7+1rq6nf7+2v7+3v7+4v7+5v7+6v7+7v7+8v7+9v7++q2trP78 xI6NcFBPO/76yv76zufkwTEwJ6qolf72vENBMvPst/750v751v762qCZbLmyin15YZmUePPs xMrFpaSghv764mlkSebbpomDZf70w9XPr/753v765ltVOq+leWtnVf70zP7utOjizZGDW/76 7mVXNYd3T5uNav7svYeBcoh5WXlsT/3jq8q3jdjFm6eZePHdr8q7mf7swvHhvP7z2kA4KPbh t/7sxvjmwf7w00lIRv7mvGBXR+PPrHhuW/7szPPiw+PAhLSacZaEZv7itLilhkxFOenXuPDR ov7mwvnmyRoYFVlHLnRcPcSmfmtbRv7ZqK6bgsKuk/jgwP7mxrWmkfTkzsSVW5p6U6qLZr+d dXZiSldOQ+3aw/706Kh/U4ZoSPbHlM2rhf7gv/XYuTQnGoRtVejEnty6mKaOdYx4YywmIJiF cv7lzFA9LJFxVLWQbZp6XV1KOP3Oo9qyjP3hxvTdxz0tIOKqfGtRPNOid6KAY/3n1G9LL4Vb O7ODXSYcFMiVbe64jvzs4FIzHpdpSn1cRLmHZxkSDvzczRUNC/3MyvACAvIODtsNDfIdHfA1 NfFPT/Zubvi+vfzb2/7t7f709P76+v7+/vr6+vT09Ovr6+Hh4czMzFpaWhISEgwMDAICAv// /4dQojoAAAEAdFJOU/////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////wBT 9wclAAAAAWJLR0QAiAUdSAAAAAxjbVBQSkNtcDA3MTIAAAADSABzvAAAROBJREFUeF7tvQlc U3e6N+4BrLYzt85Y22EZb+cFsdj+W1+1deaFjr303svcO1VIyJ6AggiDVSwUDR0hlKsgmxCE gAECsoY1ClIBGdlBMMiOLFagilq0CrgcQNR+/s/zO0HR6nQD2/f99NSG5GThfM+zfZ/v7zlh HvX//DZvFhHS3/isWzfGYBueP4u/5Pt/1BxCvGkwev3aVdyuj+j9hCjnDOJN/etXr4/qjw0P DxuMjly7Nnrj+5//2XnHXEEcu351dOyWRELRNC2hqBt616/p35qdQ/6+nzJHEPWujIzdfhib tERyY/TqyM1vRuv3Pd4f8Po5gXh79MroN01mcO36TxKRcwJx9Ir+k8728LXrN3+AFX7sW+YC ov4VPfDI22P6BroUM6yvPwYBSQ1ffYJxfyyCb33/HEC8cW0U8NwavXplZEQP/PWm3sj1K1f0 blM0ZfBk837rUf6oF8wBxJFr6I76V64a3By7NkrdGrk2fEvvypUxPM6Ra88+HGcf4vBVEogj V0bAbqNXhonlbl+/Mop7b1zV+1EW+SFvnnWI9Oi1m+CnAA5zi94VvdErBgDtOolPihq9/swr x6xDnH8Nog4gjl27MjIM7jo6emWMHr5+5dowIqTHrgLgZ7vNNkTAQIKOevGy3sjobYMreiNX hm+OPiCpN68Th32W22xDpPSuQaW4oT86qj//1k2dFW/fvH1DD/dgjF5/lvDwd802RHr0+q3b elevXLl69ZoBrYNI0XrXrsG+a/q34RSgHz/LbbYh3h4ZoaFCXNUbvoF5BljACJQLvSujN4ah UF7Ro/SvPuuyMdsQqZGRGwAF6gQ9fPXaTQNMN8Pzr5JyCNCv39J/5pVxtiHSI6PDABFTzvC1 KwZMutG7Qgi4PrjqfH2M1We6zTrE0ZEb165cGQHiBj/1GCtijaSp+SNgRYjFZ03FZxuiBCo/ WOvKiP6t+QQiWnH0yshNUAEgRA2g9j/rpnG2IVIGV6HgX792nUAcZUr/CFjxJvT9IwbUrf8H 6uKNa8BCb94AR0WIQOBGrhgAX8WO4wZ46/A1/f/rrSgZuX4LBRuABNSb4agIEXbgTr1n3/nP uqNSD1joIxB1OebmdT3sjZ/pNusQ6VvXrzP8Zf4jViS76J/AiLNO4ADHGNMT0mhF/Sv6UDSY WMRSef2ZR+Lsc1QEMso0GwBxZBRjUQ/uEEe9OYLazf/16QaQ3BohGMFRcQOuw1ABQIi5BpPO M91mPRaZKESMN4HlTG+QZakbIOL8BAjnIhaJva7o3QT55sE2StGgFGPj/6xtODexiL4KzNtg vsEILk1duz4CWtzI1ZFn3UXpwmFOHBWNNTxy9bqewdgwLE2NjenBA4NnXhDnGCIWD1hevHYd tmvXgJ3+RMtScBxzZUVyBm8O64Nko6c/9qz7p0cy9pxCZH4TWWR8pmXi0V82mxB/Qhj/7Ff/ AvFnapjvdVi/WPF7na6f6Yt/seJ3Mcydp7xowsjhkWcmDb/Lp83+a2bBig4Hp554XON378/E aG65ZuoJ5XHSwXx89mHN/MRZgDi5YsWTMRrPs5rxqxaZzjv4GJiJO+YmlvPmGf3sId6x+nrZ xMSDwzScBBI+iaaxmDcDOk0ZzzN7+Cry8kmTefPm3Tto/vOC+E0qNml0b172MjOTaQvddjAa pxzuGVGGd9dMzPRMi68tHsMybrXu4DLTqTmmdz/KUSeNpxxM1ty/fy/73n2zB3AWWRpT5l8f pCZXzPRTanzZPQuruxYzk5ODzdSk1T2zp+WrWTLuj4JIW4CjfW1qvmhi3JARFsFq4+aWVpT5 PYsJB5tHgmzS8p7Z/XnzTGccuOk9kxVff20yS1Ce9jE/CiIE0wrwvhmOZrho0mGZ5dQikzUr lh00M575W6cA3zwb0xnhOZnt4nJ/3n0rCN653H4cREgplo8eoPGaFXct75pZmFnOO7hiBkTa 2AUQ3n0k9RrZ3Jk0m7duhencVo0fAHFmCqHX3H201k3dzwaA2RYrzM3uHnwA0dzE7Gtw6Qcp iTGamQU49H0HK7OfH8QZoKbuP17UjJYtWzPpYLJiatL87gOIWBwgDB87GzaLxg/Ou2+y7BF/ nn2X/SFWnHGkVvcer/r0orsrJimj7EXUxAMr0uNW9+bNW/FYVbQwAyMuW2G67LH9sw3yB0Cc cQgTK9Y87mTj5nfNJsaXrbhDj5s9yJU05WA5z2LR1KKZ73WB2mJhZWNj+TMr/Y+eYodvZvyJ NfdNadrU5g41bmb6cMRm6t79KfM1lsscHpjMHGmf8f15lpY2c5tSf5QVJw7e/0bZnlhzz5ym zNeAo5ote2BiyJzLJsYXLZv39QrgPmSzWGa07G42JFmz7J8xRId5TyjbU+B39PjUJDV+0EVn MsQ2D91xArmCEYnlyTVGU0b37gP1m2fx84U4afk4ryYEx1CXjiYO3mOO/c5dyDVMwaCB0DI1 wnjF5KSRpYP5inn3vl5n6jCHdeNHOOrkXcgp/yT9QVQybjzpYGT+INE4rLmL5wDT7aTpvYNm 982mHMzmzbOYO4w/HOK4kenkP1WAb1tl615Az1yPmiR8/Y7pi4DT3GqZyR2anjC2/HrunPVH QJz8tibozsP0+Q1j09OQmLN0x3juiuMPhzirFZpMsczR9sMggq8Zjo+PU+MTOsmJRiNMTGBA kZvJyUl4fnyCxv/xGcg0E+QN8CzcGI6TF4+jLccnxycn4G3wFgo/dLa3HwCRdjAxNjKnjU0m 6SkjOMY7UAfh0Ti1yGgRPWlkZGx8x9zY3NxqatzE+PYdCwdq0nxqynwc30CZGwHYcSOTiUkT Ywk1Zb7IfHLSxMHEwWjK3MLcwWjS3GImAZodsN8fIm10d9GksRFlbDVOL4JkTxshiZu6B32j 8cQkpI9FFlMOk7TxskkJ8nCzqdsmxuPjJka0sRVN3XFAhzSyomgrE9rcYoI2t1rkMHl3EZyE u+PU1B3zu7Ofdr4/xDvrkHlPUsaQ5++AcSYc7kJVX2S8BignbYQiG3rjFNAb2tSYppZNTZnB 3SmzOw4g3aDFAaIF9aKFEYU0nV7mQI1jGzl1986dRbS56c8BovkKijJ0MAGILyJEynzK6K4h NbXI3NJ8atzC6jZIAQ705DLkMKZW5sDkHNbAYS+C8vcAovEyc/NlRtQ60FVpUxN6gkA8aO4A J+lnAfHOuklwyYMA0RCNApq38ZopamqKMloDzgjuNg7+aQQ/AaLR5J2DYEVgCOYHdVYkFMdq 8o4VWBGU5PFlDrTOipMTEKsIcXx2s+v3d9QXTSwmJ4zvomdNAGkxNx9/0cKUNjeH8FpG37nr MDlh5WC+bgpkYPquMU0fNL9tYTwxYWREwxsm4UwQiDTEIuVgNTExZQquvgz2QhROQFbCD53l 5ur7Q6TGHYwdjPGgjECrHzeGAzI2hfyDUTkBNdzYwWHSxMLc3MSYtjKiJ02NgcRMwYmAnhHe gAYaN7EYn7AAT54yh8REQRMNn+Fw18HcAiA6OFg9WVv/wen1B0B8dDyI1GymcE/7l24X84M8 AReIPep8UOp1e2A/RCTzMt1rZpkG/CCIP/iE/iRv/AXiT3LaZ/mX/mLFH3FCb+gND+s/XBjW 0/uJFolndUDskfNB3/xqbIy5kO8mfpeI3lcG+I0iP+Kc/dC3zp2jGgLEEWK5sa+++ur6yAjc fjXyQ4/zR7xvjiDevEGhFUcM9eCKYpq+oaf3vJ6enr6h4U/grXMEEQ0HEMF6+tgSj301Att1 xqjPepsjiDdvSm5jLILdAKHh2FeG/8vwlbGfwk1/yDwqWWR66vbARDRNHJXYjX7Uiv/8E2b9 pM/6Bz50w4cQ4etuFo5+tWD0+Z9kdnrOIN7UZzLqjRsA2nB0ZPKrsZHrwz9FMM4NREP9619d I3XRcESPMjS4fv2m5KuxidGvnvglMXOcf+YI4rD+jbGvxm5gXp1veOurkYkbel8NGxrqPTfH cJ708XMDkYICeHPspuHE2Ngt8E14ZAgEjoYfs6tZfKcTNkcQMf5IuZg+iJ+k6DO/fO4gfqcz /Cxe9AvEZ3GW5/p3/GLFuT7Dz+Lzf7HiszjLc/07frHiXJ/hZ/H5v1jxWZzluf4dv1hxrs/w s/j8Z21FCV53K6FpsUgsFtMisUQiFlMSMdyKJTTuElMisUgoFghh4wv4fL6ABz94PAH8FAr4 Qh7sEwkFPHyWI2Dz+PgfHx4IuVwuvoHLE8DT8JPL4XA5XO4z6jQedomARoQXF0tEQhFCAlAU 4AXggFEHUQL4BSKRUEj+FwrgkOHV8AgOG0ES5IBXyONxeTwOD6DxuXwel8/BMyKAfXw+T8Dj iQTwQt4zgvjQH0USSiRCCwopCdxBDGJ8DLdoWLgLuwlEMUAjr+AzAOE/sBwg5uN9AeAEFACP A5DAgAiLC+bjcTg8NhoULA83HM4zhYj6G/oluibcgGOSRxLYYKVYQovgafh6akCKdsTTIIJ/ IoAFjgiowJoCEdwI4Sef2FcIToqmA5/li3joxAKwNJfFBnCAGOzK5j9TiGLBx2IavREwUGIR +bptxIlwATWcAfgfrKezGIQkuqoIYAAWEbodD70WHgr4HIhMEVgO4g28lYu2A4OiOcGEEIMQ u1wMS+7jEP/1X79jigNvmn4lHtojy/8Pnnnssy6/sHDh82MCwEijA6LxwHpoRIhKEXzix3wx P46xFvFd4qcCYYcCDQbBi3sAI4/nrqxKLeiIKASsgJfLBmQk/iDzAHQe5Bgu2JaN8DmPxKL4 96++9dbS308fmOd6avOWh0fpuUOse0Bv20k7envY6x4e2cHdx9XdX2/x+vsc6z9BwH1jExs8 p6evr/e8vhCMFWdkYmRi8a6A5FERWJQCS8bFewpTS9kiCfgnbAgPQ47TfQjcEhwT7AZZBOMr xSbabV1jYzNPBKgwa3LAXYVgOg5kHR6EIgKGuASIfOFDR6UFry5/cwP/7eVLGSvQAV7UxkDd kUauXrupxttvLY88s3ebx8p3bFx8yJOepqfWR6//MweTpsQ3x3LFppqc1R89QPggl3YsmP8i bDcWGEAqres6NzBwrIkDBgTzQcCBKXmlNpZ+HtGJaTy0oEAE1kZbiwWtaWIwIIYmZhxMp701 NdnZl7oqmIKBxuOyECugQ7zothiH6Lm8mUVj6ZsfbDCk/3X5cmJHjl/jirvrlhkZEdvtyvHd tmqVb5MtPhBbv77W5Z2V1nb4QOJ9f6XZO5Y28XhiJHneTeff/bedexK+YUSR3kKa+pdf//qF Bc9/LJbUrTM2NrZq4mB2xaQJkUjzyqMvfX7is8/O8MQisBkmFrGIs8XIxOagiYUnuq5IRANK WiTsDW56p//LEC6eARGUSUw5mF4BLpQPMCmHw7KD6OSwWRz2QysKXn0L11j+sHz5W+BKlDA5 t3yvS4BLsQCPtu7QausQt23J/4UPIrNX2KyzMYvm4wNh/u7+6E3RraXkdWH9iZnea1enkace 2XjP6b9I3aLn6y9ccFlE1XWdboq+MMCGCgEVEvBBXhV55PTXeVkd+QdTPeA/iVDMOfF57qWa 8s/P8AUkEiG/CgWc3lNNLtHZpZA30ZG5Qh4b6iKGJZYJBMgFc/K4AkDJn5Fu3l++fOnLEoS4 nNiK7bfWr3F9LjlYWuIavWOL9TZDEmOsoW2b1tmsZiDaNaelH4339g5Ga9N5TbvfCAwM3v7N jMN77nmK+jUk0ecXDIvFdU1H49OPHlEBFIhF8EEIxbbGdTX13U1DkG2EQiwWaF4RjxvUH8/i YG0EC8JzYrGA33s43cWtP5eF5QLClYSdEKoFBiIA5EDRgLew2XYcyD0PrEj/G2B7i1jxTUc8 2sSuxtJci726HPNfpa05OWGMXSQBnn7r+jdFk8AUvL8229o7JDgY0RvmpXj3W1p2ncVPeHQT 6D1vYPCcAU3rL+ijqMz+811fNp2vxzkpGkgbbk45K9PTTp8sR/4GEIHDgXNCrUjo76oCI0HB gKDFZ3jClrQ92S7Z5ZBiBFhJIKlCeQB4YESIPwEYFoGy7diYXR866n+/CRANiaOS/OgdGRi2 89I23YHa+1lbW6/l6CC+bu3hZr2CpBtRSNemVq/gwF0EfNhKt7Td+QHM6x7d9F948UWcCnv+ Ob6Izsx1r26qk7GFEIxA6IDEScTc0qb+/bX7S8FB0U3hjzfATwAaf/G0BzBSjEWIUGQBdrX7 u79s7O+B/IoUhsMFzobpBWgAhwUOyueCm7I5bDYYnz+D3Ujenob4HnHHEFPrSLtL23XHGbI3 OTk5OoHJj3tzchpzm2p6iTuy00LCPdK8UshTeU15m/N9t61/Akau3gv/QlG/eX5BByWmM9P3 1RUnyhLA7dBNIY+IRLLPNfkh5ZXph9mEvxBMIqHK6rx7aJeVChwSiR8yPoG2tdtvk83BJB4E JhZOnpAwVrhFqsqH3RCVHMDJsYPq+NCKEtc3l7/68u+WLn+L8bKQ7m5T69z0N8gDeu/qVate XzENMc8ud/3avbqA2+6xqnvHukryukOB69PzMt3WhX/TivRlvYXPL1z43BjSmfAvz6aqz67r 5oH5ADFEg1hSfaG6Jruk4lITm1R5hCMSOjed14j4gzW9EIcYimAWIV9z7nTr0IkLue2E92As YtqBn8AEECdh30gH4MfMjErRG94DX33zPVfm8JJZmvMl/OQTBIj4xN7PPvvsPFMJJSfCKTvN 2TodjOTiCseKM5iFKUlysuaMyO6zz6apAPN6/ABIWdxhA4OxOAlWQc1nbLHQ/8QZPukvoPSD YyraVGdOqA4MtsEu3A1vE4t5g3IwsUCjILmHsFKhiMvRpLL+bhsqI/QUeieACOYjdR/hAQvg An9j20I+erSZEm744IMPNnCnmQnt6iqh+MzB8jfwJRRnA5N7xBugQLBdp7Mml2eIhiEbjy+C 1zyJ3ABIKH7wHqgPIkrAR1gsHhIbKP1iIVPn+WyhEDIs2pDxSbwLBAU7QOwwYMP8AmYiT+Ie 9E3MOlhJmSfgGQkwISgeEItg55k0XCLhAi9/uEmgXE1vP35ZEEk3hh2YRwSIMKnAP2wVkbvo OinMPpBn8EkKDhXqCTyDjBUZEBiQtFeAAyoHgMMoRAZHij5yO0g0hOOggzJZ9TErPho/SDke bjN62kdfpnsk3PwRvJz/1DOBvQU2F2gtDDw4ftJfEHCk9YXjR39FforPojW4n6BtiLWgR4Kn RTyBmIfUDtoR+In/kWYEX4AOCh0HEnGeANIqlEQuHwn6U5spn/jg4ocm3ZkGULgYfQJf2Cva T8gbxhlzHoQex45to/h1Yo6vABukJ5wGaJzgtaQtEVMHtiEZgj5DVYfOS4n5UhG/Ho4WG2Zs PdCqaa1DKbbQS8HBt6fye1Mh4Ryu4/aw0DshaUKxFwGjwYIIDoppCFKMAM4Cph/SLEIReYTd PHZUYQGOtmJq87adlDjcl7szB+5wwyWC7bty2ZLIgE22hhHbtgspn23bMFjphECJqE4sDhPt jJZxwoRh7Ec+jSQOCFJwDNIvSsSVXW0UT8NXuqvOCHj1eYXiutYqXjtflHAyQsyvPwxgwVlT iqtyKoQRdqkaYXuoYEgjCE9pTeb1uNoeSilhceqDAzWkYcSUg1UCDA3EDWUNMCP2kJBS4d+M ovEYxIRN28IpTsDfAqTCEDjyPaF72axAwc6UUG+W017XEFeB9478nXRguC+pD3nbMfsLUgS2 Q3xRsedeQlhnbvi3piDbYDkHiJzS/SlCdq3ytFLRy1UE1rYI2s5KP2zhqC8MnlazckrKq9Ar T3b3NmmELZq0i4LiekG5Rt5dN1TPa1H657SXa7bmVpzOQ1xMjWBkDghA0Kug24DSj3oHBuZT HZUO74XUI90l2bZTFMyhdgYI99raBorCff8SwnJN4Qe72rbuDw6lD9uGRyKSiAABJ5gtCObY lfKounQd05uJEf+KCLgweCWEUkJXSJNCnBfcLAw6xgvaFVIrCDrG4bSwM3uFvRV2Q07n6pCr FTc7n24WFrcdbhb3tvNr26qG2CmVvNOphUOKlrbCXPmpEuxIEB2mIGR72C4TIQebKJJU4c7T YlGyEw+Tv803kCcs5tGh3r6+FDsPzLotmC/03VbOElWijyazInYiEHFeQECYiFcp4Jzwp9j5 05GK4Ya9PcqIJLkAH8VK39zOPZdHaXOqKdUJQV35ySG+c3kh7yLb+dj+XjvWsb8OVEPDKCjJ 9S1vo9v35uaJeyr+3qIRNAd01/Gbg1jnFANtnIsBOZUkTgEXJhxEC2bDos/EIdLWx/rFRz1L SHINxxW4NuYXW0eo7WACjiPucPwvEeyCe+CeTEWkOVhPSdBRCSUzm35If1B9mLLAUBaJIEhA c4PEIn8BxXOVsCs0qVxBqpNQKhQ5VcjEIieBOx+lHE5o6FaRmK9R8oSf8ERsvpDj78oTsFGK YnGEA4FDbVAwsYXCeok2IxGI2ikHaj7eIsH5VgXuG7mR2fHPyqRE9ii3IbxgumliajqUQhSE 4ZRgZwjSKlEaseBhvUDhjUhv2IIAt0FuAKcUwhM+BjkpEQDUg22QV/EhlhVUIuGtwGp0yQYl YwhEHps11woc+CXYA6o+8Da0MPmHrotdMOzGXpho4VAsCAUALNhfMJUS5TcofVgdxXBHl1kw gYLChsQNhFMiRSFFRawMDYfcCowO78BTc66GExGfkUSxqjM0BUQ4tJGu7OuaXzAIoThgI9SQ qWmNCt+DtfLhGzDu0FpELWZYKhRIfIwyDlHGicOCFZHezIUVH7Ci6euDsOIL4cBJI4hqFPot Lm0wAgb282ARcg6IBqXriZm2n1FT4W1wDoDLoVHRoISrEmYD8FC2EvDhrYSuomyAhgbYKD7O BcSH7AZw4DIMcBYhkdow1ER8BAVWISWS2JIRvacVcECDpBQPnjzHcDR8hQBBkOUcoHNITUk6 BU9FPwW+ijEJn4+FkizyoDLHfTzd/PiR2Md0YxJo2C6BfiEUfHEAUiWJOTE/CtpCEfYQxNVQ 98TGYmsH4dUQe4hES1RFZkEj7kMR7wDuBkPzM4B8YoFHr0T+RhY7yCqNrlJihcS6//jK1O+X Ln2oFD+BZj5p1zdPCq5P6LIuSvmkGcStT/85UMOHkchhOcpXYLGE546AuGXtvToPfVJyJITr sWl3fBXK3qLDp1P3eXiUIHa+qDKfl5YCd3CVKm1I7eFnvR91Y5TgsC/WWR7pKfaU4LigUJFm Y4aj/i9o+N96c/nS//NkcO8TgZFs2ObBsT/YfP57+q74UyH/3//6nxxdL4nhB0YEFxSJLi98 Th8EqgUG6H8J9l4u+476YIoRtcSXenuH5Bwj5yG/Jr/Rb1dNNZ6WI+fr5D09A3XAXoR8zslL fo3xhbimIYxsancaHISigR6ALSRGIkYp5lRCWHGdjpGQH9Fulr61wZbl+MHypYxh3n/jjXdX rfojc/D//tprK1e/9tp/Mo/CPLbvjnfTyToi9n/Hr2WzGVa6NZ99snuTzaEZtiUiG5wWPfjb BXAd4wsLhiW0oLupuz/nbBMLjklcfOpYdM6JvS3gnJK8xoZT0cfzu6qgdnAulPgluMtUcg56 8FjN0IULXcUYicKLJX5HNkdE+ChJ0JEumNRLsmLF8BrEjEs5IBs/tOJryzdQr7xiSL21/H3i aGF7crL35BIGCkJO/5703XtqPMgDSUSe4wb/gEDGHyNd3Lq6cnJ8ySNFq8JWmV8+rTGisIbu CCV+bAF8q7bBr//lhQX6YjG3u8K5O1Xe6g4lhW4+mWCWWF18DDNPW86KhnTTfV2ZkJ74zvvL 90Z3NUZXoErc1lTVpxoqBsUYnPVkeXNXTXbNAK7FIULSQpIlLVwFwV6LhCVg5c/oNCRL33zl d0tBSP398rd1bue6m4XCEYIqTrb1thXmHSIPfLYhV9vOrHfQvvlBQU4qxV/xAT8kO/59090f schCMO4h3RPq2gbPk0WPX+kteJ4n4rYeiUr39GmVoW/2njxXcym/FwQokejDXS6r1jS6pLdh jg27VK8MPdfU5o6BmdqV7uZW04yBxo/MLnH0T27SOBMVFTAyVQLdlfA4QgNQPwZHFTwsGuK3 lr/66nsc6nevomAMre8b5q+7rHpjFVHG6ff/9IbLa3/+I+O2kTvwdjsjsdJ5e5krZEm3pMnR lN63sXRzf4TiITh9EMOpX8ElYgueF4g4TZY1X7rUdMnQCL2HP0k08w5sQVuoz/Z3R59yacJY 5F7oqpdQ9d1cGvgdrzrv8J7iwUowkUhwoitPINF0w6opE4dEwwHPhJVIIDVwF5f6QTFmIwua 4ahvLX/zA5r+w1vLl7+Hh845vdftfnTw3iBindwcm5w9jXuOkTTiQ8ClMcoplRagSzyIkZfP ykyPj2+SIy+D5gkcETMqeJHBghfhb6LA9VML9ECfODFY0dTedo5Ysdktv6umKx3TDXhqk1f6 ka5DpApKe+sFwvpWAALLN6Uppb0tytZwpGnOxSUCYWruVsIWiOBKkOooBN5H5orLrWDGGRA3 oM5v+Ff3tyEmySbZdskP9TQCODzb5909LEbp8CQuGrafgegbwLyEbNx1q1cF7DqVY4fjCSA+ YZtBKKeAo/cCTb9IU7+CJQ2h6GMBJ1/zP/+DBU3U7BKf71fqEgBFg5bUfZnjtqZ1kw/SOHFv vUh4tJWH3EbVndea2e7RMgAGE4uam/mc7d12wAfIGABpiElGZcgNaZIh5xB5YwaBM/zgFbL9 /j0drL/szst5TXfoEtdStxXEP2ELxzuGjLtSdEogrtwzmyCkKbfLKz88B5c7yE6i2mP9Ew4/ 9/xvfv0byDbIcmgRu1tDqqJQ3FyT29091HUMmZt48PPUs5+nnjgHLSCUk0pa0zUEa3FC8dYz qbmtOWeVf8GFG2FzszD1fDlqNEydADaO3krYHFnbwbDEpIpLrDPqIvftV3F77z/IVL7kDyuL DZPXrcKDhazxn2/Y7Nm0iujBlM9G3OPBpBt+fBjJIwzEM46uPfHBFk18iE5mlobINuhQwmG9 5xYseM5AgHKqWPzJRS02kUBU29pw5aFtkDAEDlvYxhZzOQBXIqzQiLgVoaRfgvVgV01bEOrC QNc0Gh67wh/nT6A0EJw4moNEl5lhQRZHyj/8e4SjCja89957GxgY1N+aiqFDH8whTT21za00 WeCfw6x978TEujU3gjyIAKecudHSEv/PKwjfZMABLcVfjf3A5bHLB8gaIXAwOCikKshAESrs RY8mCqMEZFZ0QGw6mJkcMrtByBBsRMjAAQ6GxGCfCOiYnoPR/uG3oUhMZEcQpWdMT0FTd5vI SLjRTNzpHrIcRWBbWDfHTUye0rmznb8QxQvkoZhFcZFJDHIqxg8uq0HVwV4RFAPCh8jqBUam O5fkCqTXyMCxayftLjKUuIQOzJsyGajaCLTzSDWgPYDv4KviyMI59o/TcgbpPKbZKcN2MDJR 1yCgn9pp/OW11177w4yVUOH/1mEX/JGi//Tnh4b7845V012+jsgw5wEbDKzHKNhMz18wK2h8 UX3+sb2FsJcUNagIIG7n1aGlMHCrS8+VbwcItZnMyo1P+cXP63iilDDgogLwXb5gKwsHbhS2 uo4Kh1hIvSfUB6u/rpcm9VHwVIgRgZu2H/mIQsJKgPquhB8Akw5vFNBu+w3/zKPEfwJs/JDw ymb6T5u52KnzPT+iuZt5nuuxh8L1exKP6HMo3ZP2kAyG9SSq8/PEoqreQFiUqU8JVotEF9PC UknnzD/dzk/NVVBt59tIR8WrbRNqgAq05NSGi0XtdSJeb3ltKp+f19sQStYxiGuSISPiq0wb BVYk1fGfWZFiBVDrPe0DVv3VIxhz567g9Ty/EC+aCu/3/I8uX8/EXX/cWFvLpTgXvNa7Juwt 9zgsS4isDwiRewd67S3NQE2fmSwhLS2u6TPLGdg0UpVNLU3hIlFdoHce5M1DA4fEopI1LWxE KOSUy0UgmlKK0zBuA+/mlavIEF9vSU+LUFRSKeKcbmvu4QtKelvbSXUgoU5IKcpxRHXE4kFI DoJ+ekvMDqS2v2v/rrVniG0Ij/qP1RZr/yPANlhEhXtvXBW8yvr1jTuCHfMSKJHrmWOv7830 D06JCUvz2bg7Ya9r7sbEPLKAj8HFrBXiBkM25CdAbW+QlbQIBL4pudAp9bbVNVPiQ+cbGGlD cs6ezuqW0ewTzsh9BNyWOl5kpVDUWzfYKxAOVIpZp4MqK/mc0ubSPKK7YavP6FOEBZAERGqH bqnu6RAFKZS9h4entf0OQSKHfndb8p433hUGCAzDtgXuDt8f4mUfuYsTlkCxdvDW5xbb2ycG eu7YleiZGB5sd2z/DpB6GbFMgCOJTNFghp9I91jf6pV7BojYqVJgpiWatgGJ+Ez7QB0zqZFa vm9oUETxLm5F0U0kaisPLldK6IG2th6xuL2C4g84DVYIeOfKywcYfREEAFL9MYESE0KvAWWI pFPomZ8OUZhHRVQWHz4dVinu4VPwL7myTpwspkIzU5MdM0MvHnJM5oVKYXjlHCyhDpTvDb14 UTPYM1AxyJNfHJBi44uGg3OLGZSRqAhUtBS7YlAD+6QVbalCkZTHdRaLYEAG6ByO/onsKlKh bghYZMENFvtlbY6QeOGQOeDGHJGABZ2ugMeSsmxx1pGZ0CEZZloFwiSDAh3OqXzrsCbNg6RP wVV6WN5xchRle0MUuGHxjJFT6b8IoBaoiyV8OD5MLFCzofMjShvqDdCw4+8HB0KtgshtUE9Q uCH9MmhtMCGGQ4xEZsZwxQ9FzkBoEK4RgHggpHFuDhUgHGzEHoqQUsCBVBQ7DBzIJa0jNtAM AUByDlrYLE0Vi9jTZQTAoaJLlEKi6yIqooeTUMT5DJzzQ9WQyHF46IxGRcoi3DIrWIzXIs8m a6xEm2NI6fRCKhEtka8xgzrk7DH8hsw64j9opn78sCZamfwNImaMVJdaSJ2Ceg6Vj0FJCgYe MS6IY2tAKA3uJmSdUXgw3yKpw5diI03eQBRvaKeQ0SANZdZMiYvgI4xvHQMnAc8skDPNBt7j P70uPsLKvtMDHe2GA8baB1EA2ZA0cnCWyWAFBCakAnKUzNgJ+hp6HbO2j8FKBGJyFhgFEmUD ok8K0WMRMvFCbCnIGINOlEKQKNgwRmXYHOHnmItmy1GxLSbDtISNkd4cfiWXrDkQhkkOnXQW TH0kFkdmh/bVDRJDKCNmxj8J/yRep7MViWLEgFOA+LlMKOiSmC6bMVGvIwE43fmt6ebbzTet m2JiQBfC7I1TkrCaiSu3IIHBLc4kEnkDR74ZewEs6JfJPAPcMJP+xFVxqhpewsw+YHBhvwio yLIM6mykzycT8cw6BtmYBMTckCyLP0hlFM2aFYm0IZEgHpwOJRP3sLoHK7ckLLEwCz65c+dD tAnJDEjsEKpupYOUFuKeuDH48KxgymVSDelDiCJOBoxwFQcR4OgqphskAExPQ9oXEgJEh5sJ 0fD3S19d+vtXvt1yM19B6gazfIa9Kcy6wBAoy5aF02jQcoMczYdfj8H/j8VLYFvMOJdYmOAE b2PG4HGFHHYJ5Al8cofYm+RjPDFY4HS2gb3g+h1pVfWwWIExwRAKcjaI/SAHTMcikwZAzJkB 8f9buvzNt0Ck+ldGsMDzBueAFKy//ZFe/+86YE7T820frbe1h4pG2i/BxgQY52GzHNOqwnd4 +R5xZLFxehkleRD6SGx8sfi3uC1eDHkIzCHIhzFGMBC2XZCfwMsF/P3esJpElg8ZFxVpvP1A KPfeXYwdCZoFCwE3+Fh9vlctG62KdYaJSBKYzBthNz09MYdO8LAuglQMRGjDm68S1dc1Z/fK lSt378ZJN9rX7Y+bAA5sEkmwB04uwM7gQxU5th/BAow41n6Ly8GjXjt5LFl8eF7upi/LHe1s cZIQTMphE4rB5S/+HU4yUtSS30IpqT5yNDrxSCRYglyogAPi7qXHGxvz84/noWkhQlHZCjqT fKg/LzNZwzAG4rB8X5v6Xdm5ybAQTNaGmdaJJCeGz5E6gxYkMSp4WPrpPyz/N8NXXqYM32Z0 VIErK2SbdwQLe3ovtybLnBxQvw19V691sbFevQ3gsqKVmfkR0VWQDVP6z37++dnuEnac5zoL pU96r8xJFodD6Dg3gctG4Gt9S5a8/DJ8/G+XvARmSuw62990tiYVSx+GGOQhVsWZmoCKwcFU 0u1j4YF/vP2r7/mtTSCBgP0xlJDMrq7SrvTN+w5Nj1WBuzPJVVcWxSRcmXEjVKgeWBGgvbp0 KYhvsLJBzLV+ldtKl7Wr0C0DrXc0vusN00WSzEMhlSVdzZlgxqP9rpmbrFug2vFSQmxt7VyV UkdpQ2P6rhUrdm3MZLmz7MCKXHf4n1w9sQgD8V9efAVub4kEQ3mflA7Gna1CUQDtRfKsqmal Xwig1mUYPGrXphMDA+d7daWTmIjVlqtJzYluqgBfnK6nqIYwdiZ0gUz5kNKDsfbQUUFHffMt EPzfxsFb2AK8N4VsCuhC7SZwU6BLSiv0ikBI8zmOpUKIP25OdlDopRxb4C+cFA+23VZnmUqm unzcPuXLe9nZvk6OUltHO5adrZ0jZB42l30DsP2Wpl5asuSlf4j4tac2p+/wAUUYZBqScXBY 5fD9eN+aVFRMmGUQqPxOOfbrfXYXk5SC6RRh2HXnJ7Z2lRDezTA+Mh6gKyDYJOICK6Oroi73 EOLbb25wffstQ3BYYkU64F2P9QHrdyPEbatXubwev58Yt2WVVwBKM/wzTRlelwZ5XDt3rkei SqEqLOwrVCQ1WRyJPrgpOk0Wt5X1yYdk7NUZp+34XwA4QwqN+BJ4UW1/U3ZXdL+G+B8eJBwj e1N568YhDozeMQvleOiy803d3TWwWEMikVlnVjf1nh0ob0Hai6bDzhSRk+KIAjGjW5FVAExQ M9gN583fSeiPKcOljFQsCXQJ4e6NbvwboN2eGJ/tnWhPqrxjl42ScClWulu/m9TW1tFVetxP KlWqg9SqWC+bd8zij/utO6LoiHOUSaXudk4yd2d3SKyfQBBS9MsA8TdwLD2DiqE8ZY8CLIUz /sBxxeKUXG7+fYwGKPt4uR+6m2xPQqGitlhXR5GOC0SK0x3HI/cXowkZbIThAKdhIMFDoIHT oQl7ZkwVb3j197/7HUwVv8cM9Qfu2SBwDYuOoOiw9OPp2em703GVSuhZU/MGaltcWVNtgFvS EXu5qsxtxwGFok+dpdKWdhc3+a3b2LhdrlI4xck+ZNvKHFkf2oGvcm4uXvLyS2DKxUDrUBYt bcdQIUeHUxpizflIz001x1d9hEIrGdaB+HJqcutu7S9mDMXUA16G1+oLp2tOodRKKiwDkBQZ Ynmdqkfm5zEDzSga4g9gqBgWNthMAQx0gYF3a5udNEwQ+2c2Vfj7O8PE38qu5IrzNrvs7OwK o+3rL5maxR9Qb2mM1Aap1VVyuTpTXZDWlbiu0adD21eo2ur8odSd5W7HdsYu9u+/eWnJS4t/ A2OWREMaar9NOBYcEfFLjsa7ZkAKuQXNp6M4Ivezg6maz5t1h45JU6zOabrobHfmfAX6Juma SS9DGg9dM0UCFIsJMqhH+0XHDR9s2KATFultx5IrMpPPMlIxO5cFNY0Wt59LFbA1vZUctlNf t2dU+fk9RxSxvd0xSrVSDajUKnVBRknCobyCAqUqKEghl7tKXaVyO2fIrizWP/4xf/7Nj8nC PmSEMxpsGzAnkPwHNxUaASWUuZPqi5QJL+NMhX5bHkQuI8OjRjwwRA1opP9FLIcVghgX4eK5 IuYmq8+oNzxmRYTCXGtCNjs+zgTZotfCjKI/H4cPoM6xODI7WZBMJi0MVWcpq6sURVnV1drO goK+wg6tsrAMwGpj5eqCrCx1oUyhksbJ5HFSKcfOmQUXh8AMLNzAMCxfxMXQwSMjzkrGbhki ziwU6DRw1GNBLSeyHR4AyUzQMqPsRfphkQDhM9o50WR113PqUhhC/S40nFxHg4MvcP0DC1xU tlWulWV9EVdUFHNAFdVZoP20IzVVqVIqC6oKtOpOdZn2cmdh5+WOPpVSqy5UBMnlTrYssCTO FpILfvj8rZ5RXBkZpCEpn5xvEkmC9dsVKOUwdQ1JqJxLBAJ4FHfUS8YEpfBDUFF0PRfuIBAZ QyMdnvZrZib5qRC5f6U5cSyK+lAndYOU9reNq2K5zh8mbZmKKiiL6kz6W5Z080YfpadHvFdS oeKyOrZQ2aeVa6OykqIKqtSxSnW1MkZZVaBQyRVxW523SrHBwmFtLq8v8cTQ0VN92HrxPzkg EHyIAhOszYsodW1Pb2UKmDgOlozdeZwiXp1ia5GQvXkrn98y0HOCHSFjlSXIazOl4SxpBpnS 1NVFVBZ0G1kRYdR41Jiept04lr6/KzlTwN4RzrcDuYvF5juVDpzw+Mh/s9du61XryxJ83vBx eMP8eOR8K+/DTeb2xp6eGT7rt6xa77nKftWWsqwYbWFnX2yntgOqpcJf7uRo62gLDYgdUFcO t7Ll76GD3cdPHs2sPxwfH34kP3GfLOxoYq1cUpfvk1rflO/pNZR2NL/WPn7o6OH93bmeKeW1 PHULly+tD2k40j0U2O3rUe6VeIFFkimWfYxqYk4iiWFzBZdW4SzOP7GiuD26xNZ3+97WI77B adtD9sYIwlpYQXWJkRvXxrtZr53yMFnnsTbeZFNaXKCb1eEd1nusrSOtdvgd32edfnf1yi3a 1L6CKm1qQZayo0rZoVT2OcY5yT50ZgE+mKM4dJLP7SgfrM1PzgsYGmxo0LQEbz+5N3kwT8A5 cyElrTg5vkFaXlqRmV/sHxyQcqQ9vlh6jFPVK+R3JIYMBRS3pTSntQYeK1djkKJuR3In02lj UzZtTZ3a9VQFLqjf07G0VNqcdjixtCGs8gi/cgeX7eOd1hDvl7gxxNNvrYdnSLr1JvsM+x0h Kzd52cen2/v5+aV7e6eV5jedDArqUKurY/sKozqzOjuUWoVc5i+TObk72bFYLG576YG0ll5V Q+mRwNMtVbUNRQ3trSdLwnx66Ex7Xm1KXmZu8OaQEHv7vbt8egNP1WeWB64P4fCPRXqe7t2V 8lmzpjjg0JBXyYkq5kJqZGvEYBCHpNlgxslIeOI5eBpEfkNxwM6QYNv9Hok7ShsSwvMEmpDN aX75q+K9Ez1W3TVZk2ix4671suNpRaYWDm7eFhbx6RZu8ene1n72HlZ+R/uUN7KiLquzyqKy CpRVSqXaXy51+hC4kCPwVrbzxdpjbT3ynjPlF86ckQ/W16anDrXbXTwnE8vOtfRo2pSDFS0V za0XK1p7UysqlEEVYQ25XEp5sVnuNNCeqnFsq6ioaA7VcGCqdVqTw6TM1EdMNphrp4sjNQ/4 7swLMqZrhv85fk9lT3JKbWVvSkBJqKZCyK4sza1rDynd75u2o6E15LDvkXy4qC8yafue+JTw xE3xXrm1h0JqUwJ9wkpDEjrU1TGpHTEZGTGdUUl9hQVaZZ+qMM4dSADHzg6IQKoMJn+hALH/ Ai1X/anTEceCxFxUaQQgeWMd4VGVg6LQHnA68D9u3qkeuAxHAsQHDh1XucBaIPvg6is6J7le lwgipBoSYYS5BgTpHFhRN/v8oCKSOwJgejyhmMUWclkw6CH8i4hvF+TPck+VqoIUVaHV6pio jISyzIyoKG1CWVlGbFhDVkRWTAzk0Cj4H0pIp7KqKKosK6osqawoJikqolApLwxSyIDuyDhw YSG5HA86ZaxxykGopiTp4yguGeOEFT+4XJ3HxmViOE7bUHJ1FeHijPKjWx3RKT+4h6kaBCKB yTA7UG7RUR8bg0ZqgZ03Y18yBkzEPS4PiqK73VZH7QH5F1na+VF9RQWfZiR9Wl0WFdNZnRAb W1ZQUIR5tE/bMb9KWxZRFKNOiomKioiKiY1KjVAEfSGVuUtZdlL4GB5c6ovaDiywEAGYzKGS +MHjw6U7UOgAJ64zwx6cQSfSJHPcjH5FBC3yXrKTGcoFpYg0IGRBgTyDEJ/gp4+BZngxjCHb sdi2n0jlKmVhlHKzMioqqCwmJioiqSi2KErdV5DUWdAZlVqgropJhfCLia2uiu2M6uyMutxZ VpSR1QlnBkba3GW2tlCD8EpKvPgXl/wf0GlkN4wBCEiESNRHbCsZSVInPQIlIKosKj/MVVjE hMz3OSClIKsljBZAzcOx2Ed9VGdFNCNe20Nu8O2gHoIeY2cHXVKQurC6UF3YV9BXFNW3uejT JFWsQlsQq1QmpcoLIooUSpW0MyumKCurqKyoMwZ8tSwmqSCmQ64CLz/gekAmxUt+GU+FA9KJ jgANcei+sAGvsEJhiDEGgUK+34DMNhDWB5HI8CJ8npnFJjHIXLnEVA48W0/IqNOIsYvDeQRy InFdBGcD2bZsp61b5Yo+6IDVnSp1UmxSVEZSbFRVrLYwVlugrUrSxhR1xmYVqAvksUGxSRFg 5KiYqKKCpKzqPlXWAYV7nCPL0ZYNegDUSIQowFVEpq0i7kXGrSBWmNgk6HDqA56H9gqtixMd 5PCZgQJyl6EAKMUTXPg84/i6dDNtRLGw7+NHLTrNypmrDVAp5dhxbe2cHB2lUqlcKo8tjI2K jYrrjAHm1hej6gCaKlUoU6tSlcpqrbJAHVWUUVZU/WlRRh/46mtTL71k/qmTTKYAeCy45B6v VINVM1zmYKgqc3A4/g0woGMkii+ZeoBn8fs3REDyGP0YFSlmZpeQd9jLDNoz6z26VSISpDOt yNNfCGO/lx82G8RR8YQSK8KpxLUKVGI4jqo41YFOnyJtVpFaq4IIzNisVMtj1MqkTzfDf5/G QInoK9AmxXYWRGVEVYMZY2LMUaBassS8L6hP7VOWkVEdUw2KR+phzuFMlJH4Mk+4Qh/4VmQE fSScgoEpH095YCowF0lqmtMhHkki4rQSxldF4dXkKwF00hvJr4zHYmziI3iSGH4mRN7ChQv0 DPQXjOm+01S83nY9h6ytQb+4j4OrD8I4+y1btqwyNnd1ljmpIs0ythhvVquzYmIT1uwo7FN1 9HmaLoPN9GCkKjYWv+pDmVQUVRhVVBT1RdnUksWTEjG0xVPyuMjGSzY2No01mRyeZ6O92xG4 fjvxoFm/2cFEtiAhvjJj2V1Pviilq8nbZaPPJ+IYi5TI4zC2CDbkb9yHS91gxoHdfHRlyCNo VWbsCKsKfP8K8x1I01UEIE4bTfjCwgUGkGIWLoTr7nET5/vuzsQ78tdf9/hy7ev74Esg6vpb LV1azx93BU8Nsnfx2fiOUayqQFWUUHNKnhWlzIr88lL2Ozb3+8OVUBrlHdqoos6MvrKysohP Ny9ejMvNL/56yZIMbUZeWk1Ta/ugglfnFm3ZtSacLzsL05tfdp1li0LueZVEN/XwxS3eiS7R 3V1HxIfur1mZbbYmXGhrfdDF8uBxRzjXXM3nymktg8krugtb8SpWZuUL0yomyoeOennBAn0s hQsXTH9lcumRPRE8iHDNsdO1wXv3HhuEMZLW6mgX04Z8aADT3Na9s2Zd1/6gqrIt9m80ethv WR9VGNmYnn0/O/tUjEqbpY1VFMoh1ZRFRWTEZny65GWKWgwLJkuWTHV2bDHNtnRZG8lh17ud atwXXcnjtXXdt7wfXSXgHreJ3nfw+JYYcWDjmi+Pa3qPCFOi+7uiXaLbxdKzbRdb2nL8KYGP V4A0NUFH0qZTJ3bV6JzIFsgXzpBQnAHRAKHBTOzCBc+THnj9u2si97zrFwlBz9pnujbRNAGS WmZrYn96Tl4+MM22gZaaQ5sC5UqFT02jy32bFTZGqr5IN4t33sm+5KVWKJRyMKS6ENy0LAuq 4p0lL6E6Sk8CRKXcr9Emuia6gcupq2ntb6ppZ/Mio+81vuOWwI+7UL6v5UJTU5uw12VNa9OR wEruheJNh+N3t9aJpN2sI4fZe1LFnD2JvcK2XJyynx5B0xEDvOSFpB2SVPFaEAKRSaI42Tz/ JvxcqEcugm3+vCZyt+UJGXisMqdncHCoGNSUzPSU49m7jsbLWBx3lo/ZeutdB+TajsrKk/eP t+dlBmkjN3lkW9pk74Bko9b2yfu02r7qssJOKI2LlvzGkHr5lRcNIRg7+hqs0k/57Wg4wK7v 2ueyKzqPIwu2tEm/lB3A5Wm8bTZu3+TtLypudEs8bh0fyQ/dYbMsvrQ7U+gUbW22xjraVawo 3R/A4w3tB1aHSoeuAJKgxLpIhiFwgRnZ4IzvKq7CyWbYXtQ5qpjrvX1PCY5LUAo3E6NV6aBc ijXwVR/WXf3HWRxVvNm6+ysu3fOSBoEhve6vKSvsU2oj4/e9s87yvpdcrZUpFY6FcnlSUHVh bKey84uXXqFe/C18P8NLS8o6shJX5Ff2Z9c6OWZ2t2ant9ZxVKXv9Ef3f9ldyOm+VHyivKlV Iyq2iU9fZ5ldL0zJPh4f0DIUIXY8eyJ3z2dnpVR4aVgwX9JTDlfiQ1aB2Qhy+ZyO1pGL0Mhl k+TSSfHDWPwf/RdeeGE+JXlh4fSf9QjZvocZyOT0ltfk9mrAFzKbKj2ii5vz4ZtIzvQ0N16s 7Nph5xwnVR106/LCqnj04BaIxcZKhb8SfVVbqOgo0HbKL0doLy9CjDT18pLFWqXCo6s+prm1 4WO16TKzbLfV1qlbzwwl5gd2n5Hy2lrq29MOtQsEmi634guf99fxNQP5lbvaS1MlgtSP29Ng TkcyeKa+QeSjdMLlAmR1zGwosncyW4FWxGvqkOUCQXjIbrQwEfvCr8Z0RpQI15uF5UYIZGBH TmLm3spgH4jczOPzExuPZuRDB8TldBxXrXdJc5fGqSxq6gNstnwUqti4YvW6dTbeWkVQnFrR 569VQV5VxsYUBFV3aBe/9BJqxYt/rS3s27fGdK2VWeKBwosXT3S1DAykctwbLHO64kFFFh4O 01TuqxQL03LPBdiq0+tEwsyGHTkeOe44xZ13ErMID9LUquhQ6KrIF5GBS2JHBes/xEuZxUGs CcwC7UOIdB+O/S4YY0KT3ZpTY5+76vVNMMkXf44dn3nmfIREnJkdf/xS45p0thgWuKvSE7rP tzm61pn15ykL8u8bqfvy3Va4ddWkW0Uo5OC/clwEUCZlFRQlJRWp+34LIBcvBmqnDKptOn3h Qk4t29GO7dqt+QSky8qcc6EVF9pgpe5ij2jwfJ1A0NPGbeM2n5VKBJpzZzSfwdQxmKX9Iq49 wjfHXDjbA4WRUBryZQHMmD1hqMxMLWQOIsXOhAioL48Nf6xjc/wKx/Lwga6ui0KK1cMNOx8k GpSKJZrPLw6ADva5La7ka1pT2ypYTnZ1Z/MK5X3VF9Kk6va8oRPt9edOpKbK1QoVCHLavoKO y1na6o5OdcEXN391o+9GRKdW3Vdff0D2YdvgJ+5sbtwZJRBWjn8qXIPvzAb6plQK1G2wKonr gzylP+QTthS+vgjyOdSBre7MJZ1CDpeQG7zeDL2TmbbCb7eAOzojElvNTDc6aDN+2HH5tnYY 0ZQkSA5ZFk4a/+9QeQQCFpmC5KbabmU5OznJ5cBX5UFKubxQBtf/qOJkKq2rTCZXQB4KUkqh sUpVRhRUAwEoSiooi+i7XNihhpoCi3UKJ5mTVObs5O681RnaKzL4wGiiMKUDDBVTCDJHXAIA gg0gmLDTpVCcvcJnyIaNFUYl+fYHhIYTzATsdxkQwzqJA9CEi0OLA9f1ghwKcxm4fuhk6yx1 lamVl+XyDnlSVWGVUq0CwFLXIH+lQhFUqCzUauO0hUWdSZ0gAnREpEYplUGxamWqLMgpztF2 qyObZSsLgqVIkJLRdrqLgdzJ1Qo4u4ICBqEv8PuFn8LVgZhQmKsrSNiR4R0sEtAWwT0yjI9X iZBW/p/JUyJ7L09c3nCOiioAtRhOErxXvTElgQw3Qa2MIYyck5rot09l5y4L89ovk23ZuF2q kirkUltXmUIKUn+fuqOqoxBuqrRJ1R3VwNe11UmXOzz3+ZgcrdYeVsGiFdudXecXUs1mZ4bF 4CXCnHoFXPYdGBwZSa68JIMloan4JQXA1QNbelk498JJcCUX2iI4TDgQd8QKBDihGCS3kuuZ ni4V70kO3iny4frXhddJoyJ5/PDNPFHl6bZSWUakkHO0sL5SfTnysIzXHpKZfzQ8KDLtlF+k h5uHl5fflvX79nnaSZ2h3woCB5YqwYcLo6D/1yZ1oAjQmRSbmb/y5MnD1sfTPDxPArrehsr6 U6eOHE9MS6naf6q2NVKgqc0cLA3ZHJniExiYsXFbZJrHNllKIMf/GDc0c5evfYhv+f5t2yIb 4CsyyNcc4lc5YtUnFsUxkOmWkHxrztMc1c7b3s/HK3ij/Y4d727PP71j/4nunXRYyLv5kReO 2W88l7LfIyWv9FgFu333xuM7ajM89u1LjG9pjb8bHXzco3SowV0qVblLZYq4Ax2yy32FRYVJ ZRmdHYWqmKzY6oIYlVe/z67VDd2gyZa27GdXdO/yaukJbi3dnX+8uGeouJfNOhfi09uc2Hsm vrfdr7kk3rulOLHynDy0RCjY753oXXLId5uHR2kxubhAl2SwW9bpFcjbEDlZAno6RFZ3eMDa 3b7euxo8duw/7FoaYncogQ5raQvZVGnb5M09udcmUHk6OIJXV9sW4leb4LErcdNx6cZ07+MZ 3psiw3ZJ5TIpZBwVpBU1tMexMdXopWWwglXW2Xk5w6rLwSrdp9T7eP6p8Ganuure6LSCgNpT +SnpadKWiGaONDSz9GRCd2BUjm9GblhkTmleZXf4Ibn0GCutO/hkbabv/uDakw15JJsQAqbL MIwQRUbPiLtiCXm6FXPf990bYr//cOCuUycPyWtT7P3qqPaG9bXHAo4eOx3Z29x8+vDh2jRB RfzR3JZ8j5BTpYkh++Lja3f7lDf4WSeCKAAri66Qc4KUQUp1QXVWWVInrPVUQ4ucUXWk+3B3 bYtfa75ffm993oGexMRzpbXFvb0tDc21p4s1lVsVLacG2jUDJaeL80/lxRefKcmsqG9olYt6 TpdoevOSQyvqSoqbkzVYNMjF5VjxCT3F1Io9BpZ8jEX03qc5qvCzEwN2oS0V/uENFamh7IrQ Y02ZYv9zn1WwBz9jKwY0rnJ1Rc9AEFc28NmgNBkGtwfbKi72VLS3q+vqa5sa5AoFFBBVXJxK Cys3VWWxSZ0xUUkRKFNFFBTU1avrEjQ9bW31FRp/f6egisGgtgp/JQjSjqGhH8Kih1ChgYEd 9lap5pxj28BfYXqYm7rxNEssZMN3+sCXP4lx5ox4o47HzFARiSIJhsSMQ4jO04sGNP8wwWWY eU6IUlFdwAk2jgYTmY/oI/jdHeQLWOzYW0FetXWSOcscAZdzeGlInSooDmQ4hRZuqlILq7Qd BZ0dnZsvg5d2ajM6q2HFCoY8wJttpQp3mdTJ2dnWyRZWAlgsSJTwvTxkYRAulRexgii2E044 iPk4dMRU85l/SHQ6seA3BiFisr5MZiLIN7Og435rXZTo/hyN5Dv//SRdDn+USzB/7xRvMaF/ 58/SFQHyWY+Lu98kK0/e8/8DzaIQ5XrpD2kAAAAASUVORK5CYILbAAAARAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQ yep5+brOEYyCAKoAS6kLAgAAABcAAAAWAAAAagBpAGEAbgBnAGgAbwBuAGcAQABjAGEAdABy AC4AYwBvAG0ALgBjAG4AAADgyep5+brOEYyCAKoAS6kLOgAAAG0AYQBpAGwAdABvADoAagBp AGEAbgBnAGgAbwBuAGcAQABjAGEAdAByAC4AYwBvAG0ALgBjAG4AAADbAAAARAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AADQyep5+brOEYyCAKoAS6kLAgAAABcAAAAWAAAAcwBoAGUAbgB5AGEAcQBpAG4AQABjAGEA dAByAC4AYwBvAG0ALgBjAG4AAADgyep5+brOEYyCAKoAS6kLOgAAAG0AYQBpAGwAdABvADoA cwBoAGUAbgB5AGEAcQBpAG4AQABjAGEAdAByAC4AYwBvAG0ALgBjAG4AAADbAAAARAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAADQyep5+brOEYyCAKoAS6kLAgAAABcAAAAWAAAAagBpAGEAbgBnAGgAbwBuAGcAQABj AGEAdAByAC4AYwBvAG0ALgBjAG4AAADgyep5+brOEYyCAKoAS6kLOgAAAG0AYQBpAGwAdABv ADoAagBpAGEAbgBnAGgAbwBuAGcAQABjAGEAdAByAC4AYwBvAG0ALgBjAG4AAADbAAAARAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAADQyep5+brOEYyCAKoAS6kLAgAAABcAAAAWAAAAcwBoAGUAbgB5AGEAcQBpAG4A QABjAGEAdAByAC4AYwBvAG0ALgBjAG4AAADgyep5+brOEYyCAKoAS6kLOgAAAG0AYQBpAGwA dABvADoAcwBoAGUAbgB5AGEAcQBpAG4AQABjAGEAdAByAC4AYwBvAG0ALgBjAG4AAADjAAAA RAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAADQyep5+brOEYyCAKoAS6kLAgAAABcAAAAYAAAAYwBjAHMAYQBjAG8AbgB0 AGEAYwB0AEAAYwBjAHMAYQAuAG8AcgBnAC4AYwBuAAAA4Mnqefm6zhGMggCqAEupCz4AAABt AGEAaQBsAHQAbwA6AGMAYwBzAGEAYwBvAG4AdABhAGMAdABAAGMAYwBzAGEALgBvAHIAZwAu AGMAbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAASABwACgABAGkADwACAAAABAAAACAAAEDx/wIAIAAMAAIA GWqWbgAAAgAAAAgAbUgJBG5IBAgyAAEAAQACADIADAAFAIuJ+lFXMCAAMQAAAA4AAQADJAMG JAFAJgBhJAMHADUIgUNKHAAAAAAAAAAAAAAAAAAAAAAAABwAQUDy/6EAHAAMAQYAtWs9hNUw qTDzMMgwAAAAAAAAAAAAAAAAIgA+QAEA8gAiAAwAAgBoiEyYAAAIAA8AAyQBYSQBAwA1CIEA JgBKQAEAAgEmAAwAAgBvUkyYAAAIABAAAyQBYSQBBwA1CIFDShwAACQAVUCiABEBJAAMAAcA zzCkMNEw/DDqMPMwrzAAAAYAPioBQioCLABWQKIAIQEsAAwACwBoiDp5VzBfMM8wpDDRMPww 6jDzMK8wAAAGAD4qAUIqDDYA/g/x/zIBNgAMAAkASABUAE0ATAAgAEIAbwBkAHkAAAACABMA DwBPSgIAUUoCAGgIAG1ICQQAPAD+D/H/QgE8AAwADABIAFQATQBMACAAUAByAGUALQB0AGEA ZwAAAAIAFAAPAE9KBQBRSgUAaAgAbUgJBAAiAP4PAQBSASIADAEFAHli6GxGaIdlLGcAAAIA FQAEAENKEgAwAB8AAQBiATAADAAEANgwwzDAMPwwAAANABYADcYIAAI5EHIgAQIACABQSgYA bUgJDCYAQkABAHIBJgAMAAIALGeHZQAACAAXAAMkA2EkAwgAQ0oYAG1ICQwuAFFAAQCCAS4A DAAEACxnh2UgADMAAAACABgAEQBCKgZDShgAbUgJDHBo/wAAAAA0AFBAAQCSATQADAAEACxn h2UgADIAAAAIABkAAyQDYSQDEQBCKgZDShgAbUgJDHBo/wAAAAAuACBAAQCiAS4ADAAEANUw wzC/MPwwAAAQABoADcYIAAI5EHIgAQJHJAAEAENKEgAaAClAogCxARoADAAFANow/DC4MGp1 91MAAAAAAAAAAPANAAAGAAAqAAAAAP////8DAAAABCH//wEAoHqZAAAh//8CAKB6mQAEIP// AwCgepkAAAAAAIoEAAB3CQAA8A0AAAAAVAAAAAEAAQAAAAIAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsAAAAYAAAAGAAAABgAAAAbAAAAAAYAAI4LAADBDwAA 8BMAAAsAAAAPAAAAEQAAAAAGAAD1CQAAdQwAAMwPAAAXEwAA8BMAAAwAAAAOAAAAEAAAABIA AAAUAAAAAAYAAP8SAADwEwAADQAAABMAAADtCAAAGQkAAC8JAAAyCQAAXgkAAHQJAABYCgAA hAoAAJoKAADdCgAACQsAAB8LAAA7CwAAaQsAAIELAADwDQAAE1gU/xWEE1gU/xWEE1gU/xWE E1gU/xWEE1gU/xWEAAAAAAcAAAALAAAAEgAAABQAAAAbAAAAEyGVABMhlP+VgA8AAPA4AAAA AAAG8BgAAAACCAAAAgAAABAAAAABAAAAAQAAABEAAABAAB7xEAAAAP//AAAAAP8AgICAAPcA ABAADwAC8OoDAAAQAAjwCAAAAAcAAAAQBAAADwAD8IgDAAAPAATwKAAAAAEACfAQAAAAAAAA AAAAAAAAAAAAAAAAAAIACvAIAAAAAAQAAAUAAAAPAAPwUAMAAA8ABPBcAQAAAQAJ8BAAAAAI BwAAVRYAAMgoAAAFKgAAAgAK8AgAAAAIBAAAAQIAADMAC/AAAQAAfwCAAIAAg8PuAAAAvwMg ACAAHQAgAAgA1iEAAIYFAADvHwAAxwUAANUbAACKCAAA1RsAAIsJAADuGQAAjw0AAMIYAACU EQAAURgAAJkVAABRGAAAnRkAAMIYAACiHQAAyBkAAKYhAACKGwAAqyUAALAbAABsJgAApB8A AK8pAACFIAAArykAAOQjAACvKQAAxCQAAK8pAAC5KAAAbCYAAN4oAACrJQAAxioAAKYhAACn KwAAoh0AABgsAACdGQAAGCwAAJkVAACCKwAAlBEAAHsqAACPDQAAbigAAIsJAACUKAAAiggA AHokAADHBQAAkiIAAIYFAADWIQAAhgUAACMAIvEMAAAAkQMAAAAAAAUAAAAAAAAQ8AQAAAAA AAAAAAAR8AQAAAABAAAADwAE8HQAAACyBArwCAAAAAcEAAACCgAAcwAL8CoAAAB/AAQABABY AQAAAAB/ATkAOQC/AQEAEQD/AQAACAA/AwAAEAC/AyAAIAATACLxBgAAAL8BAABgAAAAD/AQ AAAACAcAAFUWAADIKAAABSoAAAAAEfAEAAAABQAAAA8ABPBCAAAAMgAK8AgAAAAOBAAAAgoA ABMAC/AGAAAAvwMgACAAAAAP8BAAAADgEAAAtRcAAJwYAAAlIAAAAAAR8AQAAAACAAAADwAE 8FoAAABCAQrwCAAAAAkEAAACCgAAUwAL8B4AAABEAQQAAAB/AQAAAQC/AQAAEAD/ARAAEAC/ AyAAIAAAAA/wEAAAALQUAAByGAAAtRQAAI0aAAAAABHwBAAAAAUAAAAPAATwWgAAAEIBCvAI AAAACgQAAEIKAABTAAvwHgAAAEQBBAAAAH8BAAABAL8BAAAQAP8BEAAQAL8DIAAgAAAAD/AQ AAAA5REAABwcAAABFAAAOB4AAAAAEfAEAAAABQAAAA8ABPBaAAAAQgEK8AgAAAALBAAAAgoA AFMAC/AeAAAARAEEAAAAfwEAAAEAvwEAABAA/wEQABAAvwMgACAAAAAP8BAAAABpFQAAQxwA ADQXAAA4HgAAAAAR8AQAAAAFAAAADwAE8EIAAAASAArwCAAAAAEEAAAADgAAUwAL8B4AAAC/ AQAAEADLAQAAAAD/AQAACAAEAwkAAAA/AwEAAQAAABHwBAAAAAEAAACOBQAA8A0AAAgEAAAA AAAAHAEAAMAhAADMFAAAlEAAAAAAAAAAACYAAAAwAAAAjgEAAJQBAACVAQAAlwEAAJgBAACq AQAAqwEAALwBAAC9AQAAxQEAAMcBAADMAQAAvgMAAMIDAADtAwAA8QMAAFwEAABgBAAAywUA AM8FAAB0CAAAeQgAAIMIAACHCAAAiAgAAI0IAAAqCgAALwoAAKsKAACzCgAAtAoAALgKAADn CwAA5wsAAGgNAABuDQAA1g0AAN4NAADhDQAA6w0AAO4NAADxDQAABwAcAAcABQAHAAUABwAF AAcABQAHAAUABwAFAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH AAQABwAEAAcABwAHAAcABwAHAAAAAAA5AAAARAAAAEsAAABlAAAAbQAAAG4AAACOAQAAqgEA AKsBAADGAQAAxwEAAMwBAAC8CQAAvwkAAMYJAADMCQAA5wsAAOcLAABoDQAAeg0AANYNAADe DQAA4Q0AAOsNAADsDQAA7g0AAPENAAAHAAcAOgAHADoABwAHAAUABwAFAAcABQAHAAcAOgAH AAcABAAHAAQABwAHAAcABwAFAAcABwD//xQAAAABACAAdwBDADoAXABEAG8AYwB1AG0AZQBu AHQAcwAgAGEAbgBkACAAUwBlAHQAdABpAG4AZwBzAFwAdQBzAGUAcgBfAGMAbwBtAG0AbwBu AFwAQQBwAHAAbABpAGMAYQB0AGkAbwBuACAARABhAHQAYQBcAE0AaQBjAHIAbwBzAG8AZgB0 AFwAVwBvAHIAZABcABwg6oGoUmJgDVkdIN1PWFtXAFAAMgAgAFMARwAxADYAIABiAGUAaQBq AGkAbgBnACgAUABhAHIAdABpAGMAaQBwAGEAbgB0AHMAJwAgAEkAbgBmAG8AKQAxAC4AYQBz AGQABQAnWUVO3U8gAK5pMABMAEgARAAtADAAOgBVAHMAZQByAHMAOgBvAGsAdQBiAG8AOgBH ADQALQBUAG8AZABhAHkAOgBQAGEAcgB0AGkAYwBpAHAAYQBuAHQAcwAtAGkAbgBmAG8ALgBk AG8AYwAFACdZRU7dTyAArmlLAE0AYQBjAGkAbgB0AG8AcwBoACAASABEADoAcAByAGkAdgBh AHQAZQA6AHQAbQBwADoANQAwADEAOgBUAGUAbQBwAG8AcgBhAHIAeQBJAHQAZQBtAHMAOgBB AHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABQAGEAcgB0AGkAYwBp AHAAYQBuAAUAJ1lFTt1PIACuaUsATQBhAGMAaQBuAHQAbwBzAGgAIABIAEQAOgBwAHIAaQB2 AGEAdABlADoAdABtAHAAOgA1ADAAMQA6AFQAZQBtAHAAbwByAGEAcgB5AEkAdABlAG0AcwA6 AEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAFAAYQByAHQAaQBj AGkAcABhAG4ABQAnWUVO3U8gAK5pOgBNAGEAYwBpAG4AdABvAHMAaAAgAEgARAA6AFUAcwBl AHIAcwA6AG8AawB1AGIAbwA6AFQAbwBkAGEAeQAgAC0AIABHADQARAA6AFAAYQByAHQAaQBj AGkAcABhAG4AdABzAC0AaQBuAGYAbwAuAGQAbwBjAAUAJ1lFTt1PIACuaToATQBhAGMAaQBu AHQAbwBzAGgAIABIAEQAOgBVAHMAZQByAHMAOgBvAGsAdQBiAG8AOgBUAG8AZABhAHkAIAAt ACAARwA0AEQAOgBQAGEAcgB0AGkAYwBpAHAAYQBuAHQAcwAtAGkAbgBmAG8ALgBkAG8AYwAF ACdZRU7dTyAArmlLAE0AYQBjAGkAbgB0AG8AcwBoACAASABEADoAcAByAGkAdgBhAHQAZQA6 AHQAbQBwADoANQAwADEAOgBUAGUAbQBwAG8AcgBhAHIAeQBJAHQAZQBtAHMAOgBBAHUAdABv AFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABQAGEAcgB0AGkAYwBpAHAAYQBu AAUAJ1lFTt1PIACuaUsATQBhAGMAaQBuAHQAbwBzAGgAIABIAEQAOgBwAHIAaQB2AGEAdABl ADoAdABtAHAAOgA1ADAAMQA6AFQAZQBtAHAAbwByAGEAcgB5AEkAdABlAG0AcwA6AEEAdQB0 AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAFAAYQByAHQAaQBjAGkAcABh AG4ABQAnWUVO3U8gAK5pQwBNAGEAYwBpAG4AdABvAHMAaAAgAEgARAA6AFUAcwBlAHIAcwA6 AG8AawB1AGIAbwA6AFQAbwBkAGEAeQAgAC0AIABHADQARAA6ADAANAAwADUAXwBCAGUAaQA6 AFAAYQByAHQAaQBjAGkAcABhAG4AdABzAC0AaQBuAGYAbwAuAGQAbwBjAAUAJ1lFTt1PIACu aUsATQBhAGMAaQBuAHQAbwBzAGgAIABIAEQAOgBVAHMAZQByAHMAOgBvAGsAdQBiAG8AOgBU AG8AZABhAHkAIAAtACAARwA0AEQAOgAwADQAMAA1AF8AQgBlAGkAOgBQAGEAcgB0AGkAYwBp AHAAYQBuAHQAcwAtAGkAbgBmAG8AXwBCAGUAaQBqAGkAbgBnAC4AZABvAGMABQA2VDAeIAY6 yP8P/w//D/8P/w//D/8P/w//DwEAAEwQRBcACQT/D/8P/w//D/8P/w//D/8P/w8BALRNPlYc q1R1/w//D/8P/w//D/8P/w//D/8PAQA+ZNFh1oaOsv8P/w//D/8P/w//D/8P/w//DwEAOxOp bhYinsb/D/8P/w//D/8P/w//D/8P/w8BAAMAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAMYAAAP hLMBEYSJ/hXGBQABswEGXoSzAWCEif5vKAECAAAADv8BAAAABAABAAAAAAAAAAAAAAAAAAAA AAADGAAAD4RoARGEmP4VxgUAAWgBBl6EaAFghJj+bygAAgAAACkAAgAAAAAAAQAAAAAAAAAA AAAAAAAAAAAAAxgAAA+EdwERhIn+FcYFAAF3AQZehHcBYISJ/m8oAQIAAAAO/wEAAAAAAAEA AAAAAAAAAAAAAAAAAAAAAAMYAAAPhGgBEYSY/hXGBQABaAEGXoRoAWCEmP5vKAECAAAAATAB AAAAAAABAAAAAAAAAAAAAAAAAAAAAAADGAAAD4TQAhGEMP0VxgUAAdACBl6E0AJghDD9bygA AgAAAC4ABQAAADsTqW4AAAAAAAAAAAAAAAAATBBEAAAAAAAAAAAAAAAAtE0+VgAAAAAAAAAA AAAAAD5k0WEAAAAAAAAAAAAAAAA2VDAeAAAAAAAAAAAAAAAA//////////////////////// /////wUAAAAAAAAAAAAAAAAA//8FAAAAAAAAAAAAAAAAAAAAAAB9AQAAKQIAAPENAAAAAAAA AQAAAAEAAAD/QACAAQDnCwAA5wsAADwkpQsBAAAA5wsAAAAAAAAAAAAAAAAAAAMAAwB8BEkD AhAAAAAAAAAA8A0AAGAAAAwAQAAABwAAAEcGkAEAAAACAgYDBQQFAgMAAAADAAAAAAAAAAAA AAAAAQAAAAAAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAADUGkAECAAACAAUA AAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAAADMGkAEAAAACCwYE AgICAgIAAAADAAAAAAAAAAAAAAAAAQAAAAAAAABBAHIAaQBhAGwAAAA7BpABAAAAAgAFAAAA AAAAAAAAAwAAAAAAAAAAAAAAAAEAAAAAAAAASABlAGwAdgBlAHQAaQBjAGEAAAA5BpABhgMC AQYAAwEBAQEBAwAAAAAADggQAAAAAAAAAAEABAAAAAAAi1tTTwAALf8z/yAADmYdZwAAPwaQ AQAAAAIHAwkCAgUCBAAAAAMAAAAAAAAAAAAAAAABAAAAAAAAAEMAbwB1AHIAaQBlAHIAIABO AGUAdwAAADs1kAGBAAIDBgkAAQEBAQGvAgCw+3zXaTAAAAAAAAAAnwAIAAAAAABCAGEAdABh AG4AZwBDAGgAZQAAACIABAAxCIgYAPDQAgAAaAEAAAAAQPiDZlAMhIYu1IOmBgBgAAAAAAIA AGkLAAADAAUAAAAEAAMQGAAAAFUBAACdBwAAAwADAAAAEAAAAAAAAABhJQDwEAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAClBsAHtAC0AIAAHjAAAAAAAAAA AAAAAAAAAAMOAADyCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAE0CAAAAAAkzg3EA8BAA398AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAASAD//xIAAAAAAAAABQBOAGUAdwAgAFEAAAAAAAAACQBUAG8AbQAg AFcAYQBsAHMAaAAFACdZRU7dTyAArmkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAD+/wAAAwoBAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAA AACIAQAAEgAAAAEAAACYAAAAAgAAAKAAAAADAAAAsAAAAAQAAAC8AAAABQAAANAAAAAGAAAA 3AAAAAcAAADoAAAACAAAAPgAAAAJAAAAEAEAABIAAAAcAQAACgAAADgBAAALAAAARAEAAAwA AABQAQAADQAAAFwBAAAOAAAAaAEAAA8AAABwAQAAEAAAAHgBAAATAAAAgAEAAAIAAADp/QAA HgAAAAYAAABOZXcgUQAAZh4AAAABAAAAAGV3IB4AAAAKAAAAVG9tIFdhbHNoAAAgHgAAAAEA AAAAb20gHgAAAAEAAAAAb20gHgAAAAcAAABOb3JtYWwAcx4AAAAOAAAA5aSn5LmF5L+dIOam rgAAbx4AAAACAAAANgCn5B4AAAAUAAAATWljcm9zb2Z0IFdvcmQgMTAuMQBAAAAAAEA6aQ0A AABAAAAAACyEYQYTxAFAAAAAAED8DXAWxAFAAAAAAODgkMEXxAEDAAAAAwAAAAMAAAAAAgAA AwAAAGkLAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA /v8AAAMKAQAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQk5cIACss+a5EAAAABdXN1Zwu GxCTlwgAKyz5rmQBAAAgAQAADAAAAAEAAABoAAAADwAAAHAAAAAFAAAAjAAAAAYAAACUAAAA EQAAAJwAAAAXAAAApAAAAAsAAACsAAAAEAAAALQAAAATAAAAvAAAABYAAADEAAAADQAAAMwA AAAMAAAA6AAAAAIAAADp/QAAHgAAABQAAABMdWNlbnQgVGVjaG5vbG9naWVzAAMAAAAYAAAA AwAAAAUAAAADAAAAAw4AAAMAAAAEAQoACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAA AAAeEAAAAgAAAAYAAABOZXcgUQAGAAAATmV3IFEADBAAAAQAAAAeAAAABgAAAFRpdGxlAAMA AAABAAAAHgAAAAcAAADpopjnm64AAwAAAAEAAAAAAAAQAwAAAwAAAAAAAAAgAAAAAQAAADgA AAACAAAAQAAAAAEAAAACAAAADAAAAF9QSURfSExJTktTAAIAAADp/QAAQQAAAMgCAAAqAAAA AwAAAGYAGQADAAAADAAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAHwAAAG0AYQBpAGwAdABvADoA YwBjAHMAYQBjAG8AbgB0AGEAYwB0AEAAYwBjAHMAYQAuAG8AcgBnAC4AYwBuAAAAAAAfAAAA AQAAAAAAAAADAAAABAB6AAMAAAAJAAAAAwAAAAAAAAADAAAABQAAAB8AAAAdAAAAbQBhAGkA bAB0AG8AOgBzAGgAZQBuAHkAYQBxAGkAbgBAAGMAYQB0AHIALgBjAG8AbQAuAGMAbgAAAAAA HwAAAAEAAAAAAAAAAwAAABAAdQADAAAABgAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAHQAAAG0A YQBpAGwAdABvADoAagBpAGEAbgBnAGgAbwBuAGcAQABjAGEAdAByAC4AYwBvAG0ALgBjAG4A AAAAAB8AAAABAAAAAAAAAAMAAAAEAHoAAwAAAAMAAAADAAAAAAAAAAMAAAAFAAAAHwAAAB0A AABtAGEAaQBsAHQAbwA6AHMAaABlAG4AeQBhAHEAaQBuAEAAYwBhAHQAcgAuAGMAbwBtAC4A YwBuAAAAAAAfAAAAAQAAAAAAAAADAAAAEAB1AAMAAAAAAAAAAwAAAAAAAAADAAAABQAAAB8A AAAdAAAAbQBhAGkAbAB0AG8AOgBqAGkAYQBuAGcAaABvAG4AZwBAAGMAYQB0AHIALgBjAG8A bQAuAGMAbgAAAAAAHwAAAAEAAAAAAAAAAwAAAJdumFQDAAAACggAAAMAAAABBAAAAwAAAAEA AAAfAAAACgAAACdZplO5ZU1PB2hMcjAAMAAxAAAAHwAAAAEAAAAAAAAAAwAAALReb34DAAAA EwgAAAMAAAACBAAAAwAAAAEAAAAfAAAACgAAACdZplNNT25/B2hMcjAAMAAyAAAAHwAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAA AwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAA AAARAAAAEgAAABMAAAAUAAAAFQAAAP7///8XAAAAGAAAABkAAAAaAAAAGwAAABwAAAAdAAAA HgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsA AAAsAAAALQAAAC4AAAAvAAAAMAAAADEAAAAyAAAAMwAAADQAAAA1AAAANgAAADcAAAA4AAAA OQAAADoAAAA7AAAAPAAAAD0AAAA+AAAAPwAAAEAAAABBAAAAQgAAAEMAAABEAAAARQAAAEYA AABHAAAASAAAAEkAAABKAAAASwAAAEwAAABNAAAATgAAAE8AAABQAAAAUQAAAFIAAABTAAAA VAAAAFUAAABWAAAA/v///1gAAABZAAAAWgAAAFsAAABcAAAAXQAAAF4AAABfAAAAYAAAAGEA AABiAAAA/v///2QAAABlAAAAZgAAAGcAAABoAAAAaQAAAGoAAAD+////bAAAAG0AAABuAAAA bwAAAHAAAABxAAAAcgAAAP7////9////dQAAAP7////+/////v////////////////////// ////////////////////////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH//////////wMAAAAGCQIAAAAAAMAA AAAAAABGAAAAAAAAAAAAAAAAgPyaGw0YxAF3AAAAgAAAAAAAAABEAGEAdABhAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgACAf// /////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYAAAC9gQAA AAAAADEAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAOAAIBAQAAAAYAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAVwAAAEsXAAAAAAAAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgECAAAABQAAAP////8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIioAAAAAAAAFAFMAdQBtAG0A YQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA KAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGMA AAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0A YQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIBBAAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAawAAAAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgD///////////// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAEAAAD+//////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////AQD+/wIAAQD///// BgkCAAAAAADAAAAAAAAARhQAAABNaWNyb3NvZnQgV29yZCCVto+RAP7///9OQjZXEAAAAFdv cmQuRG9jdW1lbnQuOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA= --------------020305050802080009070500-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Apr 12 09:16:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18551 for ; Mon, 12 Apr 2004 09:16:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD1IB-0002Kh-Tf; Mon, 12 Apr 2004 09:16:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCzmm-0004nw-J6 for megaco@optimus.ietf.org; Mon, 12 Apr 2004 07:39:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16150 for ; Mon, 12 Apr 2004 07:39:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCzmk-0005ZV-00 for megaco@ietf.org; Mon, 12 Apr 2004 07:39:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCzlh-0005SS-00 for megaco@ietf.org; Mon, 12 Apr 2004 07:38:25 -0400 Received: from mail.relianceinfo.com ([202.138.126.29]) by ietf-mx with esmtp (Exim 4.12) id 1BCzjz-000589-00 for megaco@ietf.org; Mon, 12 Apr 2004 07:36:40 -0400 Received: from INFWHUB011.ril.com (GBLWMRH011 [127.0.0.1]) by mail.relianceinfo.com (8.12.10/8.12.10) with ESMTP id i3CBXndo014058 for ; Mon, 12 Apr 2004 17:03:50 +0530 From: Viral Harsora To: megaco@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Mon, 12 Apr 2004 17:05:51 +0530 X-MIMETrack: Serialize by Router on INFWHUB011/SVR/RIL(Release 6.5|September 26, 2003) at 04/12/2004 05:05:54 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Megaco] (no subject) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Dear All, Can some one suggest a Book covering Megaco / H.248 in detail including concepts, architecture, call flows, Interworking etc. Thanks & Regards, Viral. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Mon Apr 12 09:19:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18753 for ; Mon, 12 Apr 2004 09:19:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD1LB-0002oD-Jh for megaco-archive@odin.ietf.org; Mon, 12 Apr 2004 09:19:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3CDJ91A010792 for megaco-archive@odin.ietf.org; Mon, 12 Apr 2004 09:19:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD1LB-0002ny-D1 for megaco-web-archive@optimus.ietf.org; Mon, 12 Apr 2004 09:19:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18721 for ; Mon, 12 Apr 2004 09:19:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD1L9-0000fd-00 for megaco-web-archive@ietf.org; Mon, 12 Apr 2004 09:19:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD1JR-0000QJ-00 for megaco-web-archive@ietf.org; Mon, 12 Apr 2004 09:17:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BD1IG-0000GC-00 for megaco-web-archive@ietf.org; Mon, 12 Apr 2004 09:16:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD1IB-0002Kh-Tf; Mon, 12 Apr 2004 09:16:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCzmm-0004nw-J6 for megaco@optimus.ietf.org; Mon, 12 Apr 2004 07:39:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16150 for ; Mon, 12 Apr 2004 07:39:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCzmk-0005ZV-00 for megaco@ietf.org; Mon, 12 Apr 2004 07:39:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCzlh-0005SS-00 for megaco@ietf.org; Mon, 12 Apr 2004 07:38:25 -0400 Received: from mail.relianceinfo.com ([202.138.126.29]) by ietf-mx with esmtp (Exim 4.12) id 1BCzjz-000589-00 for megaco@ietf.org; Mon, 12 Apr 2004 07:36:40 -0400 Received: from INFWHUB011.ril.com (GBLWMRH011 [127.0.0.1]) by mail.relianceinfo.com (8.12.10/8.12.10) with ESMTP id i3CBXndo014058 for ; Mon, 12 Apr 2004 17:03:50 +0530 From: Viral Harsora To: megaco@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Mon, 12 Apr 2004 17:05:51 +0530 X-MIMETrack: Serialize by Router on INFWHUB011/SVR/RIL(Release 6.5|September 26, 2003) at 04/12/2004 05:05:54 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [Megaco] (no subject) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Dear All, Can some one suggest a Book covering Megaco / H.248 in detail including concepts, architecture, call flows, Interworking etc. Thanks & Regards, Viral. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Mon Apr 12 09:19:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18775 for ; Mon, 12 Apr 2004 09:19:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD1LG-0002oW-0b for megaco-archive@odin.ietf.org; Mon, 12 Apr 2004 09:19:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3CDJD7s010812 for megaco-archive@odin.ietf.org; Mon, 12 Apr 2004 09:19:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD1LF-0002oJ-TH for megaco-web-archive@optimus.ietf.org; Mon, 12 Apr 2004 09:19:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18727 for ; Mon, 12 Apr 2004 09:19:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD1LD-0000fx-00 for megaco-web-archive@ietf.org; Mon, 12 Apr 2004 09:19:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD1JS-0000QU-00 for megaco-web-archive@ietf.org; Mon, 12 Apr 2004 09:17:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BD1IG-0000GD-00 for megaco-web-archive@ietf.org; Mon, 12 Apr 2004 09:16:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD1IB-0002KK-6T; Mon, 12 Apr 2004 09:16:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCuiC-0002Eh-7s for megaco@optimus.ietf.org; Mon, 12 Apr 2004 02:14:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06446 for ; Mon, 12 Apr 2004 02:14:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCui7-0002Mm-00 for megaco@ietf.org; Mon, 12 Apr 2004 02:14:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCugz-0002E2-00 for megaco@ietf.org; Mon, 12 Apr 2004 02:13:13 -0400 Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1BCug6-000255-00 for megaco@ietf.org; Mon, 12 Apr 2004 02:12:19 -0400 Received: from PKdasCL5019 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HW100JU7NSER9@mta0.huawei.com> for megaco@ietf.org; Mon, 12 Apr 2004 14:09:51 +0800 (CST) Date: Mon, 12 Apr 2004 11:44:34 +0530 From: Prasenjit Das To: megaco@ietf.org Reply-to: Prasenjit Das Message-id: <009a01c42055$6d9a3c30$f904120a@in.huawei.com> Organization: Huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [Megaco] MEGACO/H.248 Is there any difference ? Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi , I would like to know if there is any difference between MEGACO 1.0 and H.248 protocol. I read that this is published by IETF and ITU-T respectively of the jointly developed standard. I think as per protocol wise there is no difference. But some body told me that there is some difference for some package support. Could anybody confirm that. I will be greatly benefited by this info. Thanks in advance. Regards, Prasenjit Email Privacy Declaration ***************************************************************** This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ***************************************************************** _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Apr 12 10:11:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18552 for ; Mon, 12 Apr 2004 09:16:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD1IB-0002KK-6T; Mon, 12 Apr 2004 09:16:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCuiC-0002Eh-7s for megaco@optimus.ietf.org; Mon, 12 Apr 2004 02:14:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06446 for ; Mon, 12 Apr 2004 02:14:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCui7-0002Mm-00 for megaco@ietf.org; Mon, 12 Apr 2004 02:14:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCugz-0002E2-00 for megaco@ietf.org; Mon, 12 Apr 2004 02:13:13 -0400 Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1BCug6-000255-00 for megaco@ietf.org; Mon, 12 Apr 2004 02:12:19 -0400 Received: from PKdasCL5019 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HW100JU7NSER9@mta0.huawei.com> for megaco@ietf.org; Mon, 12 Apr 2004 14:09:51 +0800 (CST) Date: Mon, 12 Apr 2004 11:44:34 +0530 From: Prasenjit Das To: megaco@ietf.org Reply-to: Prasenjit Das Message-id: <009a01c42055$6d9a3c30$f904120a@in.huawei.com> Organization: Huawei MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Subject: [Megaco] MEGACO/H.248 Is there any difference ? Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hi , I would like to know if there is any difference between MEGACO 1.0 and H.248 protocol. I read that this is published by IETF and ITU-T respectively of the jointly developed standard. I think as per protocol wise there is no difference. But some body told me that there is some difference for some package support. Could anybody confirm that. I will be greatly benefited by this info. Thanks in advance. Regards, Prasenjit Email Privacy Declaration ***************************************************************** This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ***************************************************************** _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Apr 12 22:00:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01290 for ; Mon, 12 Apr 2004 22:00:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDDDW-0007vl-BT; Mon, 12 Apr 2004 22:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDDDM-0007ux-Mb for megaco@optimus.ietf.org; Mon, 12 Apr 2004 21:59:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01262 for ; Mon, 12 Apr 2004 21:59:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDDDH-0005Zu-00 for megaco@ietf.org; Mon, 12 Apr 2004 21:59:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDDCJ-0005RA-00 for megaco@ietf.org; Mon, 12 Apr 2004 21:58:48 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BDDAw-0005A9-00 for megaco@ietf.org; Mon, 12 Apr 2004 21:57:22 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3D1vAAh008873 for ; Tue, 13 Apr 2004 03:57:10 +0200 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 13 Apr 2004 03:57:09 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 2PVK1H2L; Tue, 13 Apr 2004 03:57:09 +0200 Received: from ericsson.com (sealwa04-240.sw.ericsson.se [130.100.249.240]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 2YXBV3HA; Tue, 13 Apr 2004 11:56:55 +1000 Message-ID: <407B4925.9070001@ericsson.com> Date: Tue, 13 Apr 2004 11:57:57 +1000 X-Sybari-Trust: c1224cfe 2c4885b5 3944f865 00000138 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Prasenjit Das CC: megaco@ietf.org Subject: Re: [Megaco] MEGACO/H.248 Is there any difference ? References: <009a01c42055$6d9a3c30$f904120a@in.huawei.com> In-Reply-To: <009a01c42055$6d9a3c30$f904120a@in.huawei.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Apr 2004 01:57:09.0699 (UTC) FILETIME=[A1853130:01C420FA] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Prasenjit, H.248 and Megaco are exactly the same protocol and can support exactly the same things. Christian Prasenjit Das wrote: > Hi , > I would like to know if there is any difference between MEGACO 1.0 and > H.248 protocol. I read that this is published by IETF and ITU-T respectively > of the jointly developed standard. I think as per protocol wise there is no > difference. But some body told me that there is some difference for some > package support. > Could anybody confirm that. I will be greatly benefited by this info. > Thanks in advance. > Regards, > Prasenjit > > > > Email Privacy Declaration > ***************************************************************** > This e-mail and its attachments contain confidential information from > HUAWEI, which is intended only for the person or entity whose address is > listed above. Any use of the information contained herein in any way > (including, but not limited to, total or partial disclosure, reproduction, > or dissemination) by persons other than the intended recipient(s) is > prohibited. If you receive this e-mail in error, please notify the sender by > phone or email immediately and delete it! > ***************************************************************** > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Mon Apr 12 22:02:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01357 for ; Mon, 12 Apr 2004 22:02:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDDFA-000855-QG for megaco-archive@odin.ietf.org; Mon, 12 Apr 2004 22:01:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3D21iIh031060 for megaco-archive@odin.ietf.org; Mon, 12 Apr 2004 22:01:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDDFA-00084t-K9 for megaco-web-archive@optimus.ietf.org; Mon, 12 Apr 2004 22:01:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01353 for ; Mon, 12 Apr 2004 22:01:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDDF6-0005sY-00 for megaco-web-archive@ietf.org; Mon, 12 Apr 2004 22:01:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDDEV-0005jI-00 for megaco-web-archive@ietf.org; Mon, 12 Apr 2004 22:01:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDDDW-0005ad-00 for megaco-web-archive@ietf.org; Mon, 12 Apr 2004 22:00:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDDDW-0007vl-BT; Mon, 12 Apr 2004 22:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDDDM-0007ux-Mb for megaco@optimus.ietf.org; Mon, 12 Apr 2004 21:59:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01262 for ; Mon, 12 Apr 2004 21:59:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDDDH-0005Zu-00 for megaco@ietf.org; Mon, 12 Apr 2004 21:59:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDDCJ-0005RA-00 for megaco@ietf.org; Mon, 12 Apr 2004 21:58:48 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BDDAw-0005A9-00 for megaco@ietf.org; Mon, 12 Apr 2004 21:57:22 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3D1vAAh008873 for ; Tue, 13 Apr 2004 03:57:10 +0200 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 13 Apr 2004 03:57:09 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 2PVK1H2L; Tue, 13 Apr 2004 03:57:09 +0200 Received: from ericsson.com (sealwa04-240.sw.ericsson.se [130.100.249.240]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 2YXBV3HA; Tue, 13 Apr 2004 11:56:55 +1000 Message-ID: <407B4925.9070001@ericsson.com> Date: Tue, 13 Apr 2004 11:57:57 +1000 X-Sybari-Trust: c1224cfe 2c4885b5 3944f865 00000138 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Prasenjit Das CC: megaco@ietf.org Subject: Re: [Megaco] MEGACO/H.248 Is there any difference ? References: <009a01c42055$6d9a3c30$f904120a@in.huawei.com> In-Reply-To: <009a01c42055$6d9a3c30$f904120a@in.huawei.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Apr 2004 01:57:09.0699 (UTC) FILETIME=[A1853130:01C420FA] Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Prasenjit, H.248 and Megaco are exactly the same protocol and can support exactly the same things. Christian Prasenjit Das wrote: > Hi , > I would like to know if there is any difference between MEGACO 1.0 and > H.248 protocol. I read that this is published by IETF and ITU-T respectively > of the jointly developed standard. I think as per protocol wise there is no > difference. But some body told me that there is some difference for some > package support. > Could anybody confirm that. I will be greatly benefited by this info. > Thanks in advance. > Regards, > Prasenjit > > > > Email Privacy Declaration > ***************************************************************** > This e-mail and its attachments contain confidential information from > HUAWEI, which is intended only for the person or entity whose address is > listed above. Any use of the information contained herein in any way > (including, but not limited to, total or partial disclosure, reproduction, > or dissemination) by persons other than the intended recipient(s) is > prohibited. If you receive this e-mail in error, please notify the sender by > phone or email immediately and delete it! > ***************************************************************** > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Apr 13 08:30:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08540 for ; Tue, 13 Apr 2004 08:30:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDN3C-0005gI-Ri; Tue, 13 Apr 2004 08:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDFvU-0002Hx-Rz for megaco@optimus.ietf.org; Tue, 13 Apr 2004 00:53:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06462 for ; Tue, 13 Apr 2004 00:53:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDFvR-0002Bu-00 for megaco@ietf.org; Tue, 13 Apr 2004 00:53:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDFsl-00026v-00 for megaco@ietf.org; Tue, 13 Apr 2004 00:50:48 -0400 Received: from fw.cdotb.ernet.in ([202.41.72.207] helo=ws9.cdotb.ernet.in) by ietf-mx with esmtp (Exim 4.12) id 1BDFq6-0001xl-00 for megaco@ietf.org; Tue, 13 Apr 2004 00:48:03 -0400 Received: from cdotb.ernet.in ([192.168.51.210]) by ws9.cdotb.ernet.in (8.9.3/8.9.3) with ESMTP id JAA07712; Tue, 13 Apr 2004 09:47:41 +0500 (GMT+0500) Message-ID: <407B6EF5.8060901@cdotb.ernet.in> Date: Tue, 13 Apr 2004 10:09:17 +0530 From: Prakash R Reply-To: rprakash@cdotb.ernet.in Organization: Center for Development of Telematics User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: cdotb.itg.stacks.megaco To: Prasenjit Das CC: megaco@ietf.org Subject: Re: [Megaco] MEGACO/H.248 Is there any difference ? References: <009a01c42055$6d9a3c30$f904120a@in.huawei.com> In-Reply-To: <009a01c42055$6d9a3c30$f904120a@in.huawei.com> Content-Type: multipart/mixed; boundary="------------020907060404030208020108" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------020907060404030208020108 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, We had compiled a small document on the relationship between the major Megaco recommendations/RFCs. Maybe this will help. Regards, -- Prakash R Business Unit Head, Softswitch and Media Gateway,(Cell & Packet Tech.) ====================================================================== C-DOT (Centre for Development of Telematics) 71/1, Sneha Complex, Miller Road, Bangalore - 560052, India email: rprakash@cdotb.ernet.in, prakash_r@hotmail.com Tel: +91-80-22263399 Ext. 268, +91-80-22383951, Fax: +91-80-22263256 ====================================================================== Prasenjit Das wrote: > Hi , > I would like to know if there is any difference between MEGACO 1.0 and > H.248 protocol. I read that this is published by IETF and ITU-T respectively > of the jointly developed standard. I think as per protocol wise there is no > difference. But some body told me that there is some difference for some > package support. > Could anybody confirm that. I will be greatly benefited by this info. > Thanks in advance. > Regards, > Prasenjit > > --------------020907060404030208020108 Content-Type: application/pdf; name="megaco-std-hist.pdf" Content-Disposition: inline; filename="megaco-std-hist.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjQNCiXk9tzfDQoxIDAgb2JqDQo8PCAvTGVuZ3RoIDIgMCBSDQogICAvRmlsdGVy IC9GbGF0ZURlY29kZQ0KPj4NCnN0cmVhbQ0KeJzVXMmuK7cR3T/g/YPWAXJDFtkTYAS490rK 2skD8gGZgCAOYG/y+yGlrkE8RaplO4vgAYYv1c2urvHUwP7xFMq/aZve0mnNdPrpb6c//+b0 769ffrz9EE4//ePrl49vX79ECm/raZmWt+n07a+n313jKebTt7+fvgvx96dv/yxXpLJHqD9+ FyikkO/L5T7i5SnMcq0sLvel9LbxyrpfFHlhC+/7UnibefEjfO6LWTc7h8u+KEvXMMewL668 OFda4k455Td51DlSTJFpr297/yFO96X1bdFn5TjHnXyaDRFljxz3t6BVfojbfSm/MR0xl4v3 dyOS5UD3pVk5OvGKULqzcpGV+MF8ExrNUn/vKDsJWQuviEx2jsjGgV9FVnZpZKGP970U9fke NYqmUEhYitI1+lQkU4R23bkyKcOR8vN9ZVIxXfS5haFT/4UGbNiA6am5q/NKWyjCWGIV5O2d 6FTU8G4j1SR2WSxvueFqZ7uiXf5uE5uMMpvNqFiWWAixJW32wmJM4UNI2cwPrOGy9ln+vT9/ 43nb2CsojcUSWYZxVZpW1hvR2nCAC+4TPC6Up7JVx02fmtpLq5WD22KzNzumGNjyo5pteRAx s3KjPnOjcsYvuELKrMLiJZbiFch5ZlzvfpUpT8bvEfuWYulJ73iPHyzrYg2L/vAZzyHGS7xS OCDftb7EI/fZ3Fd1SJfWRcWZGb+JJfKbmfcNvJIbcY0UwiHpqFmwCu5/MweSca0Ume6luSuB B1G6iURuUV+PwFNOj5pSHjd+4bsQFiqPfnxjysTKOYObNBwGvaaxa75x2Hmex2Fvo7cpxG02 2y1FKd0NV2IBhY54Ahm26lsqW8XgJmLgYGJiAGagXV5CIjYfI01xTGrkLXGt0YfMuqs4QfWr Lw/Y54OvUGNmTm2qpy6rmDNkdLDROHovjF/lMmHWVFmBjJggilDM8JozKFmJegLHMmwnKhNv SlPiv1GTv/zw9Usoe//nQaH++IeyevptPP1wopzKz+V//3X608BophoEGqOJ9T0lMq1dUT43 EWd3z0Too/Um9ElnBi9RpHJhXdUALBcFlfoGl8EKXRuBw9ZwxWcKdC6gWqhNirU75Fby+NlF jfrk4EqKzeNbcq5A8OfzlUJ8Fn6x5SRqBJvYIg2uM+hnbUkUM2IuDt10CoDX4rVoXBaNU2rB yMUZGnyQknF/AmjVsqKJ6+2GKReLVkPnZRL73bouKCV+/bm7Pec4K4TJPIAFoZW1eOSpzxmF dcFIDS5LQGIbbAVv9V8riQ2zLlCOjGU14CTm2ECiMVUBkDrlDULnCH+KUEZCCDQbNyvhkILa Ag3uNoqk3KalhDJVHHX8GN8c1OwgQV7p62o8srPIt83L5wFfC4pX++vrmIqd5VkMlzMldTLx zLow9ANx8XKiJCJRayiAn9HHBum9YvyBsb1sagvYkD6Hzsmp6CA5sX241m0Gtzmp2ARuPPdk mp2sIXXfHkI6PjuDPs3PeOjgfqFuBXoVq5XETfmKBKDJx4YdQ0QG1zj7JCaq9Vc2kezuw3+L CqFwlOK0FB9SyzhSS0vJkRQ1D1kgBDiBpFHACbyb1TZr+aP3finypjVtJT3YrTaRbvN+CCOE DMmrBkFA94YDJf2/VAJolqwigcsYPXpaFoCsFp4Q2q4W4Eh5mYUflUlSXzX+/QLeCvdz3tm+ 4/6GM5iVbiHZXNcOiiYy0ZoQacRUE0JqHt5XnthxKvOAcaOiB0IX9Q1paYl0S1QcPQgswTBK oitWYrQo1osO0yAmo6NBr3rE8yo9AlMxpYSVCLjdoVlqBUqPFvAGFZ4UIM1lhRvpdZ9HrQMy KmI9FfpWvRBRCuc8KjYGKLqSjviGOZfrG98AZRaEYMX+ua2j3iMupham5ZOofha1RUz2vdVM 1NWRRiEewjgDMUPd2Qok1lI2LYLhSRPj8Hg37PYBFgWuAHMWdGJME0THgVtgwfVoixrdNNGJ Ql73UdafahYRc/1BumEI89WoiqJreXsBegE7dhVf1VyI+2i9HJctTMPhytf0dCCcWW/EogF7 E1/D1EWmBRA8eOC5K7W+x+vLETWKZhaj+ESxBIBA/RC13NLAJEqPmZOVKUYqJmLoc6b4P/c4 bKRGzfUVRH6HtEtzPwoOP/pdLqfNE/GaQq1axmD7R1SL5RBxT9MdxGqSn5YBD2qOUpDRvcnE bfnkFA/sDYL9DMUXaUvYnOUAmHKK84AKnBrAKxUIcHRYWZGVq4gjDIy2XznDutDLIqyJhmi1 3K0DEW1t0quwtO9sJOVEmghwwkkuwUiP9BGnon1LY+4enDG1NkE9/QSRb1uk3Sw82VotcPAj ivN5w05cW+w5+7t82QxokNWi3+1qZuur524E+/UlPYFega01jq0nqBGAFR5cWeBxVFQpLn8t 3i2aIPXcvk0TywsiLSm+ZLuerH8jZmBmowjexNloAJkVPvUhIrOkDwHElxt3h4lqrqhggPXM fuo+B5WxIzCBKv75XwMFIdZMbOg7kJ2Vodq0Zx2lSfEzjEUccYx5W6BplOaS/3O52Fo6I09b K+YLN6MitfAhxG+21fWYaqp9GGhvYLiTKsesENPyUKsqLcjpPdyMpExVQ2vxZ2eqKaisUuII 5lFaTjW7s2ds+wNYXZ4s3aPBHE0NmzDg2QsXB/eXcEYYMWKbuZN+j9+tAu76bjLV+cZDMjNw /x8Z+fyawSwRK6jnJ3fGW9nV3BrFlbwX7buyhJKB9p+NyLEJ/eSZU82bPHK1snMwIUcP2qly 9y+MUUO+0QAdTUSwb/pCXthrqr9zI2cviMl+x6q/CI7VFKoLZo9LCRGKPn1l2jdTXSwJF9U2 qeQ6EZN3fdYmTmjEpcMdB6/J3MqmX8ebAXhjG6SjknlafqkR8Hjc2NCmBea9flnXzkR1qcvC +M6gbabZ5YFgWLNxKQWaTiRpQIzZ+l0uAKmbdgqJg/j3st82dY2Dor/7zhS5zCuyZ6lrgnlE wM5GdyUi4onGpJGYMoVQATtPDBlut4//KDqmk406nH+EqtgiKaZFh53VitrpdTMQvdGFQ7SZ k07O7BDrp5nG7WcW3pSLuETrz0zBbaP2VANdpElPA0pqSBGghi2S9ODcw5r01MamdTDHavh2 AxKln4b1lJHHR3RT9P3KfoK8onjrUzvqkHJUZQAFFS8n9YPUElcVdvyEtc41OwoHE5/OtAu4 9rbKoAnb+qtIeHZaXi+0HrAwb8/7tDEooqgv97RxF6zJMJcjVh0ylI4ORuTX+gZClVR6I1a+ x/MSUZOJ/vxKAnW7Z2yAsEajES+DDm+6xdRqBRpB4ayvF1hw7J33Wep2RpAafeSYiiiUpEvy Lh8tCBmbZph7WhOAe8gmO7C5DZF3yEnh8zbas1s3HksWHEdnoBFHBI2y9YrIElc2B2Ur5VI5 +jWAr1O3IbIDKINndIulQ+eRtgjVo58HCuhagMk5BTlUo7pfFUEyIRMF79Wyj0fk95DVaHJi YjlUThwDxJwGuhx4tmZQyzcvQ4aoB5QaTPd2M05KSlUiK0mris6pglekEOY06WhlMtI8HzuQ lOYM9TKYID9SDPA2euLGYlgebzwALUQKYhXvPrGiNYskD/TWgvLUbGK2Lbi5gMXMyTNNJlUm aiW0FAeQKJX/HgnBRWYw0Ro/H9TheUds0A8leBvo8ByBj4DilgIpTZJPzoythD0DKHoXpU46 hr0UZxrXFE2xWGEozkEzj8F82qweoL/dKPB0ZwoenfmA1p8xEjjcTVJ7Oat9qGcHuCYlkAc+ ztnZFMNoNOH6YvPIDOGOOTuO2I2XeDZtuhtuWvH4Jo6ewATHSOHMIMwrQ5KjDn07zZ44EXZc BKbQpiDZtoGj2P4GeQ6epzel1xdGJifQlWS6JV117Yfpp+xxvGH/Hqfd3C/bm8hNI/Y8P8XY lTrOKIg6ObgsfpJO3Zgq5JmLMW7iKytSm3goxLWX+eXoezFCYFuGDXpFVqpJu7G84yihLYod 7jXkpZYpPWvXgkSf8TXnkeB3eIhr9zCU8WzyCwC7F/GfdET6jWcAF4+zbNEZi2grF+jEzcCC AQo9B+4eJjLzY1jUGZD/dJjBnkeIJqEsEUICiRRiz90wxbudW+LbHkCLtpMMT5sUnr/PEmGb 4dHQC7A7ADmtomBFZ1LdhTNfI0SpzsL4D9uRMqAaNQMPsY2k2Z+S/Rnloa46GcQxtuIb1Ghw QuvSScpFJl90zlSm8Rm5mGpUNU8U/0h2pnBzSoyK1h120HsoJsYsIDP7VlLX26eAokhRtOL2 qRK5x3w9B6a7+XT3w9BDE8tjONNHSaCvxdg/9Ws02RRoziVF+3zSY7klurRODXtKinekN4M3 1kgWAFufS0K/FTIFr5MZ6TuXnz6Y8WRqrEkLFrykn3YyeHiji4w9mFM8nVJe/3B6my7Lh5QE NFS2xEJX3FtM9Rs391x4Nw+VKs0l6Q0y8WFU7JYNNxw6mBzT7QGPtmM/RuXB5dHYJ8alWmaU ooBBVO3pdtjK6bmiLZWkljR8aPgnjNlHDuXi4Z5sZsEGE6qqWVjmMsM/wK5+A6L9W7W4G/q9 09aKaTFAOBcdHdD2G34QXVtouAny9cbyX6L1EO7Fg8A/42UdRbxqj1wevpv2qI+PXQwZf+wP q792cErM7lk18Gb904rjie1sar99FpP5xtRgzhyyxCOH320bcXCVBlNTgBfD7p/at53f/lVk tx98AsAZ6XSmD9uIu+iXzqKd9tCPXEhl6t18FAHOkI6+PwHHEPpHFwa7HBtD8tJUJcQ40n57 eXCOe0CfjrSaal5/pNXzCq/0t0HBhej++8fFG6tB9y92t4z0bdhil5mrMZTNS2WycQE+5DJN pBvoOuJWcuVEs+cNq5F8jEfFtMm3Kp7PaJrvVSmixUO/ktXoAIqZ5HaGdhpU2MNxduc+khty iFI9XmM4JI43Q5gZ5I9wKvDIPIb3lQ49kuCEU2ifOoe/+uc17fe5+t+XG1bpi/utHyvdI9Go rI2YiAc3zImwPhtfyXb1ruf9aUlYVPXxO0Bmw24Bw9QZQvLmDj5Fi+0sWJIgd3Tw927BKeJg P9CWZSxXa9bd6KLzPOA+N1ZhnCfQKIAfyHUKwOA3Jt4IRa+fXmVX2vukGs06x+8MVejhfAMo cahBQPJUYKom7YPvKEy9SGD4MpnA6vWMFIRF9ZjHv5qSjAGZBKtf63IO8pix4GGpFj8xZYQ0 vGo4WnBkIIGPScs1ppOAAteoFJzwgnrR9S19JXkWu6dq0MZKmzJUzYolCTKYbfxR3N324/oG RZhagZJK1GPhadZvNJcLZq2oGOU+VFx68sleyrUaYagzkbNxat+f/gu+6+CcZW5kc3RyZWFt DQplbmRvYmoNCg0KMiAwIG9iag0KICA0MDE0DQplbmRvYmoNCg0KMyAwIG9iag0KPDwgL0xl bmd0aCA0IDAgUg0KICAgL0ZpbHRlciAvRmxhdGVEZWNvZGUNCj4+DQpzdHJlYW0NCnicTVHL asQwDLwH8g869+Ad2ZYTw1LoxhvosRDoB/QFhW3J/v+h6tpKFvvimdFoZK0EPZLFBRqjp+sH vT7QT9+tNwJ0/eq709J3LOyYQo4u0vJOh5mJPS2fdFRmeqTlWzVwoiVKHxFQfGywaGWFvVQo Om/CgpEnLhX32AiGSa0YCXNzZI3bHJ8qlO4dU8WyaYpi3ErH3c9rSss46FwNFm00YERumZIz I1gze58wofAZs7UMYbNnqI8Y4ffIzFpTlI6ceEDEzIN9oYgbmiy0xLIni/YpDPOatmE3GSeL ftbFveillTIoQijqMjyFJPebruC/ZUhRh61aHeTt0ndEh+eLUPmlm9Mf9IpzHWVuZHN0cmVh bQ0KZW5kb2JqDQoNCjQgMCBvYmoNCiAgMjY3DQplbmRvYmoNCg0KNSAwIG9iag0KPDwgL1R5 cGUgL1hPYmplY3QNCiAgIC9TdWJ0eXBlIC9JbWFnZQ0KICAgL1dpZHRoIDc0NA0KICAgL0hl aWdodCA2NTQNCiAgIC9CaXRzUGVyQ29tcG9uZW50IDgNCiAgIC9MZW5ndGggNiAwIFINCiAg IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlDQogICAvQ29sb3JTcGFjZSBbICAvSW5kZXhlZCAvRGV2 aWNlUkdCIDI1NSA8DQowMDAwMDAgRkZGRkZGIDAwMDAwMCAwMDAwMDAgMDAwMDAwIDAwMDAw MCAwMDAwMDAgMDAwMDAwDQowMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwIDAw MDAwMCAwMDAwMDAgMDAwMDAwDQowMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAw IDAwMDAwMCAwMDAwMDAgMDAwMDAwDQowMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAw MDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwDQowMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAg MDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwDQowMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAw MDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwDQowMDAwMDAgMDAwMDAwIDAwMDAwMCAw MDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwDQowMDAwMDAgMDAwMDAwIDAwMDAw MCAwMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwDQowMDAwMDAgMDAwMDAwIDAw MDAwMCAwMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwDQowMDAwMDAgMDAwMDAw IDAwMDAwMCAwMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwDQowMDAwMDAgMDAw MDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwDQowMDAwMDAg MDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwDQowMDAw MDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwDQow MDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAw DQowMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAw MDAwDQowMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAg MDAwMDAwDQowMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAw MDAgMDAwMDAwDQowMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwIDAwMDAwMCAw MDAwMDAgMDAwMDAwDQowMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwIDAwMDAw MCAwMDAwMDAgMDAwMDAwDQowMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwIDAw MDAwMCAwMDAwMDAgMDAwMDAwDQowMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAw IDAwMDAwMCAwMDAwMDAgMDAwMDAwDQowMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAw MDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwDQowMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAg MDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwDQowMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAw MDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwDQowMDAwMDAgMDAwMDAwIDAwMDAwMCAw MDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwDQowMDAwMDAgMDAwMDAwIDAwMDAw MCAwMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwDQowMDAwMDAgMDAwMDAwIDAw MDAwMCAwMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwDQowMDAwMDAgMDAwMDAw IDAwMDAwMCAwMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwDQowMDAwMDAgMDAw MDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwDQowMDAwMDAg MDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwDQowMDAw MDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwDQow MDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgRkZGRkZG DQo+IF0NCj4+DQpzdHJlYW0NCnic7Z2LluooEADh/396z94xoR9EhaikO1Vnd1TCuytInDG3 VoAbUADSg+dwB/73fPU7CsB3wXO4A3gOdwDP4Q7gOdwBPIc7gOdwB/Ac7gCewx3Ac7gDeA53 AM/hDuA53IE3PF/9h2Zf5UfT/G1WT+NX+cwEvfb8E+1clCxjyzKOHnh+nixjyzKOHnh+nixj yzKOHnh+nixjyzKOHnh+nixjyzKOHnh+nixjyzKOHnh+nixjyzKOHnh+nixjyzKOHnh+nixj yzKOHnh+nixjyzKOHnh+nixjyzKOHnh+nixjyzKOHnh+nixjyzKOHnh+nixjyzKOHnh+nixj yzKOHnh+nixjyzKOHnh+nixjyzKOHnh+nixjyzKOHnh+nixjs+P4F9LeV9D0l9Hki2Jf/HQA T8Dz82QZ20nPi35uv5ipz4XWwJbzt2ObqwTPM3DguU2xsZaJ4sgu+/5S+W+8x/Prk2VsH/W8 SSxebqIYzz85iAPw/DxZxvYNz/dKd6W3fJ19zBfB8/NkGdvT/XlLsVvv3v6860Nb06tcyTvb +M+Lj+fnyTK259ehe8qR5/q592E/Far1vK3+5hL3e2ObqwTPM3Bq31JM7p4P7QRwO3OuQ69P lrF98zrU788rngcjy9g+6vm+wPc+b5Gebx82tmLsW65JlrEN7M9dtq7nUlixcTfV9bLh+QXJ MraznlsLtK/6WtWU/PoU4vl5sowtyzh64Pl5sowtyzh64Pl5sowtyzh6rPe892uG/cXZfn2t atXM56paSpZx9LiO5+aix153qyzVPenWP1j1kzYmxxaLLOPocQXP24P9+LVptqlpZVWfU52r +kkbL4b/KsNCRt65rjyOs1zV87agVnXY/7rhScNjVR+18XRcz8d2Aeyb17OsX+/MOi7uefuz zieemyjKSkaq7rbxjiDX9qMIXuT8TYeWcAXP/Sa6X11RWusypjdTVbv9+Zsr4cX9KIbjjD/s 1K+5juf6eac6sWWu6onYg2y9mam6tgytDV31+2Ozcl2Nd8eRhSt4/vfTbi58viJ+FK23eCLi OFS1Po+K2hs95+p+vGf59cdxhqt4/upiUdm675ud5zqSQ1W3s2J/lcPzdxT/y/izLv2eq3ou 19j2stmun6j4vboOPaja7dGTeP6W4n85f9GdRVzZcxkc+8bbDrsYvuN5p+rO9VoGP94bwl/W jzarY7Ynmo61znWCIrOqms3K9sYILuS5raSnuUhVTzoVjldd7aOe7YmxredNxf/yfrjdKc+L fOEPdDxXOXXCh8d2yvP4ZBnbpz1vjz3PbYLemIqd5b68+XyPZ2J5qvocabV/alB4Hp4reP5P YLX+FyO291zkLCpBtnR2QFtTeB6eS3j+99mCSNulV/k6npdS8fybZBnbVT23ZfzGpEjP2Z9/ iSxjC+v5/kGD2J/blqZHYrqL5+H5jedS0znPqylahOLtstWUOj8kPF/dgQ/xE8/LC8/1dWhT 1lyHiqJFnz6+5o+NDc9T8E3PxScnnVz9nKVb2HouPzSXnzGalj41KDwPz/c8V5uVTi6Zxe5t bFn13tAOi0Q+P/8OWcb2Rc/7F4ddzzvZzYv9wWnN5y3fJMvYsoyjB56fJ8vYsoyjB56fJ8vY soyjB56fJ8vYsoyjB56fJ8vYsoyjB56fJ8vYsoyjB56fJ8vYsoyjB56fJ8vYsoyjB56fJ8vY soyjB56fJ8vYsoyjB56fJ8vYsoyjB56fJ8vYsoyjB56fJ8vYsoyjB56fJ8vYsoyjB56fJ8vY soyjB56fJ8vYsoyjB56fJ8vYsoyjB56fJ8vYsoyjB56fJ8vYsoyjB56fJ8vYsoyjB56fJ8vY soyjB56fJ8vYsoyjB56fJ8vYsoyjB56fJ8vYsoyjx888z8wn5vACrJ7Gr/KZCXrpOYAmoC94 DsME9AXPYZiAvuA5DBPQFzyHYQL6gucwTEBf8ByGCegLnsMwAX3BcxgmoC94DsME9AXPYZiA vuA5DBPQFzyHYQL6gucwTEBf8ByGCegLnsMwAX3BcxgmoC94DsME9AXPYZiAvuA5DBPQFzyH YQL6gucwTEBf8ByGCegLnsMwAX3BcxgmoC94DsME9AXPYZiAvuA5DBPQFzw3rL5p5lusnqPF 7U+A54YIc7G6j6vbnwDPDRHmYnUfV7c/AZ4bIszF6j6ubn8CPDdEmIvVfVzd/gR4bogwF6v7 uLr9CfDcEGEuVvdxdfsT4Lkhwlys7uPq9ifAc0OEuVjdx9XtT4DnhghzsbqPq9ufAM8NEeZi dR9Xtz8BnhsizMXqPq5ufwI8N0SYi9V9XN3+BHhuiDAXq/u4uv0J8NwQYS5W93F1+xPguSHC XKzu4+r2J8BzQ4S5WN3H1e1PgOcGMxfb1xqm5sgV2uo6OeOr47W6/Qnw3KDnYv/+zsc8L3i+ Ajw3qLnY19/6998j7bHAq6NN36bxY3Kb1tJzkV2V99U87+MCVrc/AZ4bjOdbmljY5WM5OrAX V9/oFIbberaETjXP+7iA1e1PgOeGnud1V7bum5h97e0dUJ6Lepza1ZZ36S/7uIDV7U+A54Yn nhu3q9xj6HVZFDKey8V837GIih+vZfqLPi5gdfsT4LnhcN9S5T7k0PO2KNd3PG/lq3xd8fzD 4Lnh+Dq0VvHY37f8OyPafuO55/Vv3S6qAZWO5x8Dzw16LuRW2m5P2mF54ShX5Seem+x6iec6 9OPgucHMxb7CHuxbhNfi4bnnraKqziS11Mt9/os+/pzV7U+A54apuTg7g4PlV8drdfsT4Llh cC701eNEczPlV8drdfsT4LlhdC7OaT5XfnW8Vrc/AZ4bIszF6j6ubn8CPDdEmIvVfVzd/gR4 bogwF6v7uLr9CfDcEGEuVvdxdfsT4Lkhwlys7uPq9ifAc0OEuVjdx9XtT4DnhghzsbqPq9uf AM8NEeZidR9Xtz8BnhsizMXqPq5ufwI8N0SYi9V9XN3+BHhuiDAXq/u4uv0J8NwQYS5W93F1 +xPgueHlXKg/Nt/T6v5lo34ZPcsnZ/xX8Tr6C7OAvuC54R3Py008P/qr4YC+4LlhzHPxbaOH 5/tXRdu3PtUXi/xJ8oU+fgz9Xb7ft/8x8Nww5Ln8Et3uufoenPbcfjfuW338HMXw6/Y/BZ4b RjyXjov1vC3q3nM945NfRirev98y2uH14LnhDc83yWvdVuau54/M24PcsOzJc9r8Ml49yQP6 gueGIc/LoOfyvPhmHz9Hdx0P6AueG0Y8l9eg7+1balWeX349729VAvqC54Yxz5+t58KP9kHM ln/7RObanh90L6AveG5403P1+UnP82eft9QJt4f6+CGOehnQFzw3fHYuvjO1q+O1uv0J8Nzw qbn45kdwq+O1uv0J8Nzwsbn44ifNq+O1uv0J8NwQYS5W93F1+xPguSHCXKzu4+r2J8BzQ4S5 WN3H1e1PgOeGCHOxuo+r258Azw0R5mJ1H1e3PwGeGyLMxeo+rm5/Ajw3RJiL1X1c3f4EeG6I MBer+7i6/Qnw3BBhLlb3cXX7E+C5IcJcrO7j6vYnwHNDhLlY3cfV7U+A54YIc7G6j6vbnwDP DRHmYnUfV7c/AZ4bIszF6j6ubn8CPDdEmIvVfVzd/gR4bogwF6v7uLr9CfDcEGEuVvdxdfsT 4LmhfXFZTIz6QrN4+WTu3p3U3tfpXxVdHa/V7U+A5wbhc5N7+wrc/nMXHc9jgOeGrud1myh1 Z6Lanu83qyjqTlyl2OOykrLdCkYlqqLP+riO1e1PgOcGtYRbz+uB5+2uVWLp3xd+ebzqR1Pq 8aq2bE/6uI7V7U+A54aO548EuVar/Xlpa/C2Ru/P22JeVZpI2N8J9jun1xdxWR2v1e1PgOeG 7nXow0SxpTD7FqVt28xsq7XyfN/M6JOgnUaPBo+jsjpeq9ufAM8NR5+3VKWt3Z8/87x0PC+v PK/sWz4Knht6nrfditp+b4eeeF63Tb3at1RToKjSWzfw/IPgucF6Lq8d1WVnrTpLdfvzKpZu 4b9b4E3iX7Ws5x8Fzw0dz4v2XG0pOp6LBb8Ue3zfeZsFXr9L6GuAgz6uY3X7E+C54eRc6E32 l1gdr9XtT4DnhvOef5/V8Vrd/gR4bsDz67c/AZ4bIszF6j6ubn8CPDdEmIvVfVzd/gR4bhie C//BiP7Y/Qusjtfq9ifAc8PoXHQ+6cbz64HnhsG5UL8/Ek/Er/Y/P72r47W6/Qnw3DDsuX5q f7X09Pc9s6yO1+r2J8Bzw4zn+jf5tSne/gRgZR8/zur2J8Bzw4TnpeP549jzv1P5UR8/zur2 J8Bzw9y+5YXnH57g1fFa3f4EeG74yHWo3rd83IvV8Vrd/gR4bpj8XHG/5OQ69JLguWHy90Tb 5aj503M+V7wIeG6IMBer+7i6/Qnw3BBhLlb3cXX7E+C5IcJcrO7j6vYnwHNDhLlY3cfV7U+A 54YIc7G6j6vbnwDPDRHmYmEfy+L2Z8FzQ4S5WOn59nuvCPMkwHNDicDS6ak1oDN4DkOUf78U W3quzYDnMMQF3lNmwHMYIqbmeA5j4DncATyHW4DncAfwHO5ASM3xHAbBc7gDeA63AM/hDuA5 3IGImuM5jILncAfwHG4BnsMdwHO4AxF9wXMYJaIveA6jRPQFz2GYgL7geXTO3z0gH71ZwvPY EDwHnieE4DnwPCEEz4HnCSF4DjxPCMFz4HlCCJ4DzxNC8Bx4nhCC58DzhBA8B54nhOA58Dwh BM+B5wkheA48TwjBc+B5QgieA88TQvAceJ4QgufA84QQPAeeJ4TgOfA8IQTPgecJIXgOPE8I wXPgeUIIngPPE0LwHHieEILnwPOEEDwHnieE4DnwPCEqePaua2+H9uB2bb6CR0L//m5Pmvs7 9FfmKNth8UFD8TwhWmuj37uhfXpfwl5Cv8BLz+uM5wen4DF4nhBldXmkPCQUP7dA/3u6JQhr 6+7g/iCKFnHgUaK2+lRDu5aipk65PbOpW7dfRUVTU9KmBs9j01u9t9V2/yE9bwe1faLk/mhq KT3P20GTsV9uP8OKLV59aTuw4SmRNeB5ZIznD02qMWd//LeA7st0aQUfT9qyb/4vSpbShNQH W7P10Q0t2X6CtZPtT/6tUt2u6d/wlOipGaoFLkXH884K2TwXK63xfFPhyHXvefUHt+ed/U0r 6D23Wxw8B43yXFsjhWue6y2HKjiynu9tHq3n29uK97zKlyKV9RwOkcErmm07rNdzdVAVdNuR tp9WB6r3XBWXzZlye6vipPPF8RwsKnh/7ihv7fquD6qC27HqPVcHqvFcbjzUJqS4cnrj44r7 zurWJqak1YDnkZkPXskaeDxPyHTw0mqO5xk54fknu3El8DwhBM+B5wkheA48TwjBc+B5Qgie A88TQvAceJ4QgufA84QQPAeeJ4TgOfA8IQTPgecJIXgOPE8IwXPgeUIIngPPE0LwHHieEILn wPOEEDwHnieE4DnwPCEEz4HnCSF4DjxPCMFz4HlCCJ4DzxNC8Bx4nhCC58DzhBA8B54nhOA5 8DwhBM+B5wl5O3jiHqL6XrbiNrUih3y+v/jGAD4PnifkW54X/Vzl2Q61/J2EdeB5QkY9tyk2 /jJR3zhaLunWf5+wEDxPyG88b2u1eCnl6dy1fBl4npCfer63VrY8bYtjEhaC5wmZ25+3FLv1 7u3Pu47ILCKls43/tfh4npDJ69A95chz/dw7ItZxtakRCaa5n4HnCfnOvqWY3D1Hmr7bKWRr XgSeJ2TJdWjbn++Z1aKN5/Bhfvm5ov+8ZduS6yNypWffAp/gE/tzl63ruRRWbNzlo70OZX8O H+JrnlsztK/qWlWdBj/X2oHnCSF4DjxPCMFz4HlCCJ4DzxNC8Bx4nhCC58DzhBA8B54nhOA5 8DwhBM+B5wkheA48TwjBc+B5QgieA88TQvAceJ4QgufA84QQPAeeJ4TgOfA8IQTPgecJIXgO PE8IwXPgeUIIngPPE0LwHHieEILnwPOEEDwHnieE4DnwPCEEz4HnCSF4DjxPCMFz4HlCCJ4D zxNC8Bx4nhAbPHlXz/2Wnv6GoP5fsJBHZVZVc639u4S+VujAsvfcGzMUzxPyMc+LfOEPdDxX OXWCLNGeqpvslr37LrmTcGZKKp7Hp+d5e+ze+tkkSH/lz+3e0LZGtfLLW0E/eWOQp5/K2Ev2 +fpvIu9OScXz+HzK8/owrCUVI7b3XOQsKuGRUS39u+vV5FZP/o6LAqbWmSmR7UBQPuZ5fRi2 p8mthazReb4VfMfzvwKtuKlHV6bOpDfnQ3TYjBfPI/NNz20ZvTF5pImCx/tzdx60bYuqx5w0 IiOe35ulnovtyJ6h24r13Fxf6p1M53zA87vzvudS0znPqylqdiNys2Oy+n1NEU3ITmnPzcXB e+B5Qt72vLzwXF+HFmFfMflaQXX6HJ9B1vM9Y2fNLnqzX1xV41OyT8D7VcDVeOW51sXm6ucs 3cLW85ZLnkJveF6s8EVn0u8QvsOvwPOEPPdcbVY6uWQWu7exZdV7QzssErcEv9nQBew7gEs2 Cb0zdWBKKp7H54Xntat51/NOdvNif9Ba78fsmt7d4oiM9tQyjwfvEsNTUvE8PkGCd1IyPL87 QYJ3TrKx0niekCjBO2UZnt8egufA84QQPAeeJ4TgOfA8IQTPgecJIXgOPE8IwXPgeUIIngPP E0LwHHieEILnwPOEEDwHnieE4DnwPCEEz4HnCSF4DjxPCMFz4HlCCJ4DzxNC8Bx4nhCC58Dz hBA8B54nhOA58DwhBM+B5wkheA48T0gBR2+W8BwGCegLnsMwAX3BcxgmoC94DsME9AXPYZiA vuA5DBPQFzyHYQL6gucwTEBf8ByGCegLnsMwAX3BcxgmoC94DsME9AXPYZiAvuA5DBPQFzyH YQL6gucwTEBf8ByGCegLnsMwAX3BcxgmoC94DsME9AXPYZiAvuA5DBPQFzyHYQL6gucwTEBf 8ByGCegLnsMwAX3BcxgmoC94DsME9AXPYZiAvuA5DBPQFzyHYQL6gucwTEBf8ByGCegLnsMw AX3BcxgmoC94DsME9AXPYZiAvuA5DBPQFzyHYQL6gueD/P6fvrweITqpwfNBvjxXIUIRopMa PB8Ez4N0UoPng+B5kE5q8HwQPA/SSQ2eD4LnQTqpwfNB8DxIJzV4PgieB+mkBs8HwfMgndTg +SB4HqSTGjwfBM+DdFKD54PgeZBOavB8EDwP0kkNng+C50E6qcHzQfA8SCc1eD4IngfppAbP BzmeK/cX5DPzGiIUITqpwfNB8DxIJzV4Psgzz/cnZbP+X+rj1cnqL0SITmrwfJA3PP/n9ra4 D34lLkQoQnRSg+eDvNy3bE8f8/pw/d1ZDhGKEJ3U4Pkg73ped8/3Y+eqvxAhOqnB80He2bc4 z9m3rAbPB3nX8yI8Fwv7fPUXIkQnNXg+yDufKz625LvsXIcuB88HecNz6Tr7lmuA54Pc6ff+ RyfnpTr5Hng+yJ0897/ifSQv6cwp8HyQW3mu7iYpUtd1aBY8H+Renrvbpv4lLu7UBHg+yLc9 D8F35+Ab4PkgN1vPOyfeBTv5Gjwf5Gaed9fxq3XyDfB8kHt53t+qXKyT74Dng9zK84Pd+LU6 +RZ4PsidPD8S41KdfA88H0S/gb/48EF8xcj//7r6qxKikxo8H0TO1ctP2fD8KuD5IPLXgvsX hra/BPn3x1vbsSJeC7//Hdn/uquKR1P9dQnRSQ2eD6I831L2D5bLLvxD53YCSM9V5ngf2YXo pAbPB/Ge70t63f/qvC3m6q/Qre+dfUyIUITopAbPB+l5vl+Qti8Obet57e/N7breq/66hOik Bs8HebFvqfvC/qbnZT9JbPXXJUQnNXg+SO86VOlchd9He5b92L+TZKvJVH9dQnRSg+eD9D5X lCtzlQnigPy/6DWf9fz74Pkgaq7Mxytvfd6ye15NYV/9VQnRSQ2eD/J0rtrn51+p/gKU/Ucs 8HyQV55/s/oLsF1UXL6jBjwf5Paeb1fOq3syBp4P8uW5unwo/l1diA+IgoDng+C5/oAoCHg+ CJ5H1BzPR8FzPL8DeI7nd+Dunlc8vwV4jud3AM8jao7no+A5nt8BPMfzO3B7zyue34HyZVaP 7zVBuqnBcxgkouZ4DqPgOdwBPIdbgOdwB/Ac7kBEX/AcRonoC57DKBF9wXMYJqAveB6db/+C NiK9WcLz2BA8B54nhOA58DwhBM+B5wkheA48TwjBc+B5QgieA88TQvAceJ4QgufA84QQPAee J4TgOfA8IQTPgecJIXgOPE8IwXPgeUIIngPPE0LwHHieEILnwPOEqODZbxm8HdqDryf4Ch4J /e8zPGnu71B5/AvYz/K83bfjtvpV43lktNbGiXdD+/R7OL2EfoGXntcJzw/7dtxWv2o8j4yy ujxSHmaIn1ug/z3dEoS1dXdwfxBFizjwKFFbfaqh/X5doqZOuT2zqVu3r4tMTEmbGjyPTW/1 3pbA/Yf0vB3U9omS+6OppfQ8bwdNxn65/Qwrtnj1pf3QBqdElsfzyBgZHppUY87+WErdhdwj L0+Q5oT+vyhZShNSH2zN1lqLK7cdkifbn/xbpbrdajo4OiV6akYqgWvR8byzQjbPxUprPN9U OHLde179we15Z3/TCnrP7RZHealW9rEp0VMzVAtcCuW5tkYK1zzXWw5VcGQ939s8Ws+3txXv eZUvRerBej7sJ54nRAavaLbtsF7P1UFV0G1H2n5aHajec1VcNmfK7a2Kk84X77wFjDiK5wlR wftzR3lr13d9UBXcjlXvuTpQjedy46E2IcWV0xsfV9x3VpwGc1PSWsXzyMwHb0yeQOB5QqaD l1ZzPM/ICc8/2Y0rgecJIXgOPE8IwXPgeUIIngPPE0LwHHieEILnwPOEEDwHnieE4DnwPCEE z4HnCSF4DjxPCMFz4HlCCJ4DzxNC8Bx4nhCC58DzhBA8B54nhOA58DwhBM+B5wkheA48TwjB c+B5QgieA88TQvAceJ4QgufA84QQPAeeJ4TgOfA8IQTPgecJIXgOPE+ICJ64S6i+W624Ee0d wPOE4LkDzxPiPa8mpR9hn7bfA7qTZb9r9Km++prbydfuS627VGr3tb3PtHyO5wn5mOfFuWA9 /9wbgr+1ubhpemm5zJuQzW7Hged5mfF8W7mL+UcRnVbyYNVH9yo2P3XFenn263IzT1awdcok iW6rY7X1TJ0EnVnC8+Ac7c9bikkT62R3D29UPj5oy7aK9Wu7TMvCe6+r9FyeK/5NpWXfaqqi ixXPU3J4HbqnWM839bblV7hl3w2eHpQNbieFdLvadFu4iN5UtfA3Lc15p5f8NsTWUz0lrrcQ lPF9SzsFmiPHnh8fdCeWrFi8Fum+p/sKLOpqJ4c/O/6qF7XJ0wHP83Lac6uylFsrLNM6nrf3 EOW9aLBbXatC6y/OAll/q0ZXjue5mfG87Vv0ZqDneZWr7aHntVa5b9lrauldz/f+aZHtPkQe Vz3cx6bzd2YJz4PjPddrq3ho+Zoz+oXbJwjlj/ctbf1WyKpLcYVl9dX0pfbLWb1lz8p+YuF5 RiY8t1uVJ56rDcSh5yKXELyt7dvxJz3V7w1We9lxVUNtfuN5ai4XvPU64XlCLhS84hfgNf3o JOF5cK4UvGtojucZIXgOPE8IwXPgeUIIngPPE0LwHHieEILnwPOEEDwHnieE4DnwPCEEz4Hn CSF4DjxPCMFz4HlCVgTvKn/IcgCeJ2RB8Aqew68heA48TwjBc+B5QtifO/A8IezPHXieEILn wPOEEDwHnieE4DnwPCEEz4HnCSF4DjxPCMFz4HlCCJ4DzxNC8Bx4nhCC58DzhHSDJ+7Cae7U 2XLoX2rq33Cq33aq33zu9wV9tyuuX1MF38/Vz4jn0fms50W+8Ac6nqucOkGWaE/3461en9xP mJ8SPI/Ooeftsee5TZD+yp/bPZdtjWrl371UCfth1ch+XGTsJft8/TeR96YEz6PzUc/rw7CW VIzY3nORs6iER0a19O+uy9b3V/K4zje0oON5Qj7reS3mn3LbpVf5Op6X0jOy73lb2Pe6leeq MnUmvZ6P2p0SPI/O1z23ZfTG5JEmCh7vz4sRWm7PZT3mpKm74Xh+X9Z7LrYjVerrWrGemw2M 3vdIz8vRCPrgeUIGPZeaznleTVG3GzEbjCPPbROyU9pzc3HwEjxPyJjn5YXn+jq0CPuKydcK qtPn+Aw69lzU0/PcXAy8Bs8T8pbnWhebq5+zdAtbz1sueQq94Xk7izonUlHXocVX9RQ8T8gb nqvNSieXzGL3Nrasem9oh0XiluA3G7qAzmeSe5+fd87Ut6cEz6Pzjue7U/1cLYdyWx0yZTZv TDGZved5kdXJfPYsa48H7xKDU4Ln0YkUvJOm4fmNiRS8c6a9XRrPExIqeKdUw/M7Q/AceJ4Q gufA84QQPAeeJ4TgOfA8IQTPgecJIXgOPE8IwXPgeUIIngPPE0LwHHieEILnwPOEEDwHnieE 4DnwPCEEz4HnCSF4DjxPCMFz4HlCCJ4DzxNC8Bx4nhCC58DzhBA8B54nhOA58DwhBM+B5wkp 4OjNEp5DfvAc7gCewx3Ac7gDeA53AM/hDuA53AE8hzuA53AH8BzuAJ7DHcBzuAN4DncAz+EO 4DncATyHO4DncAfwHO4AnsMd+PMcIDt4Dndg9TsKwE/4D/B2HBQNCmVuZHN0cmVhbQ0KZW5k b2JqDQoNCjYgMCBvYmoNCjgwMTENCmVuZG9iag0KDQo4IDAgb2JqDQo8PCAvVHlwZSAvUGFn ZQ0KICAgL1BhcmVudCA3IDAgUg0KICAgL01lZGlhQm94IFsgMCAwIDU5NSA4NDIgXQ0KICAg L0NvbnRlbnRzIDEgMCBSDQo+Pg0KZW5kb2JqDQoNCjkgMCBvYmoNCjw8IC9UeXBlIC9QYWdl DQogICAvUGFyZW50IDcgMCBSDQogICAvTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBdDQogICAv Q29udGVudHMgMyAwIFINCj4+DQplbmRvYmoNCg0KMTAgMCBvYmoNCjw8IC9MZW5ndGggMTEg MCBSDQogICAvRmlsdGVyIC9GbGF0ZURlY29kZQ0KICAgL0xlbmd0aDEgNDgxMjgNCj4+DQpz dHJlYW0NCnic1Lx5fBvV1Td+752RRrtG+y6NLI0Wa7Ul2ZZj4nEcO6uJs9sBY2chCRCIbUIg QBqzZmGJS9kClISWtaSNk5DgsJRAgUKhJbSUAl1I3ydQKLikfQJtn2Dpd+7IDqGf930/778/ jeYus2ju3HPuOd9zzr3aMHjFhUiHhhCDpJWXLu+fEbIg+LyJEDav3LhBeOy3nWYoH0eIe3l1 /5pLb/vB5j8gpH4YIcXla9ZtWp3e+MpehIxOhNa9tPbC5asy5c1GhK6Ba1DdWjiwvbSJQ+ha K9TDay/dcNVVllNfQ70BflO3bv3K5e+PvnErQpunw/ltly6/qv+3/MUKqMPzkXDZ8ksvvHp7 4EOof45Q+vf96y/fsAqFywjtfY2e7x+8sP+f0dVfQv2TShsQho1+dFBU0jphWIWSU6k1Wp3e YORNZovVZnc4XW6P1+cPCMGqUFiMRGPx6kQylc5ka2pz+UJdfUOxcUrTOVObpWno/+cfxe2w z0UB2L3MnciDUPnPsJ+A/ZPS7PLXiktQqHRx+ThDyf7jiR0hEd2NdqMwOolr0EvoKJqNHkUt qBPdiWagt9A+ZECb8BuIRSE0HT2ORBxABLUjB1agXeh9dD4aRB+h4yiG5qA/YTP8ThvqR3ZU LH8K6Ry0rXwErtKgVvQT9AxehxeiDJRnkiROwJN3lo8iB4qVf1l+D2rfRx/hcHk/mgmlj5EJ RdEW9F1kRhejX5SBk+C3V6DH8LX4UxREfegWNs/uKF+CpqBD6Ld4DpQ60CbFe+pDaB3c9UPs wEfLH5b/gn7KYnQh/NL1aBu0+AA6StJMq2IPElAEnYPORcvh7DXofWzBNYxUjpanlXfB0cfQ P0iCvMpw0I4EmoV60W3oIeiNd9EJ9CXW4gL+Pn4Strfx3xTvQdvmoCvQ1TC2vg+99xjai47g GlxDHMQBveVAcbQYzu1Ej8DzD6JjeA7uxkfxi8wjimypuWwt28p/KZdRNeqCFu5GL8IzTuEs XANPYKqYDayf3aCoHb8O3nAVegAdQ29DO/4E/f4l+heuhu3P5DtkS3lp+fHyR9AWFQqgBjQf LUPr0UZ0JfoBUPUl9DL6Oz5N1HDlW+wriqsVJ8t3QN9G0DRo+zy4eiH89i1ApQNoFLZ34S1N WIC3aMDn4gV4Dd6J78aj+H38PlGSIBkgf2VGmDeYP7B1CkW5EX7Jjvzw3BBaitYCBb4DvX0H vO/j6BX0OrbhCE7BG70L939FppDpsP2QvEX+xNzE7GS/VtxcOl76rHS6vANxwGUzoB+uQD+C XvgC26ENcXwxvhz/F7R8mDzFGBieCTEFpoVZxHQz25g7mdeYX7GD7JPsB4pZiuWKJ7nlpctK b5fnlG9EVEoooV1RlER5VA/8sxq46RJoXz9sg+hadB3agW4HfrkD7UFPwnu/gF5Hv0V/RJ8D BRAOQpsvgqdfClx3E74dtl14L34Rv4Jfx3/GX9GNVMEWI3WkmbSSdrKG3ATbneQYeZd8wniZ lcwWZgi2B5nDzPssYlm2rKiFbabiFsVjyje4GDeTW6F68+ux8erx7vE/lVDJXTqvdHfpxdJf ykvKm6D9IkqhNLR0K7RyF/DgI7D9CDjxMHoVZPfv5Lb+AxOsAI534hBwQxKo1oxn4FmwdeD5 sC2GbSleBttyvAKvhW0LHsLX4xvwjfg2fJe83Qvv9gh+Ah+G7Wn8DGy/xR/ij/Ff8T8IMDFh gJtFEiUZUoQ3bSUzyDyyALY1ZD1s/WSQbAQKPUYOkiPkXcbCiEyKWc4MMLuYnzAvMe8w/2YJ m2QzbBO7hF3D3sC+xb7NvseeVgQUbYq1igcVLyk9yrxysfJi5b3KfcpPlF9zSq6TW8Fdy73D lVUiSKufw3sf+pbIyyjfwpcrrOxV5EMYF06mX7EVL4YeU5JFzDrmdubXitX4JCPgD/AO5iLm kvIPmXbyL2Y9XkJewFVMQNHIrEa3ojJ+kvyZnCJ/YW14EfkUx9jv4qfJeqaVKGW5+hvWxt6g AL1DfocayWZ8lLzC3MDcUH4eNSoexB8qHiRvI4E9TizoQxjVW8k9cNOvyEXkFtTF5hWn0UXQ 708oroL+nkq24WrmHfZB9BETIv+NT+K7QWr8Es9mw+QCUsRPgsQdx340hgdQP74LSfhZ/Ec8 ijB+nHkMzyU6oNYI0eN6UH2/ZIL4HUaDumkbcYTYcCc5SRYzzymPMQWMQUr8Gl2NGZwF3pn8 lNBlMALuJFGQaW0gTX6Da5ET3QPy/lTpOSqxFe8pbgE+e4hJogUoi3rIG6gRxsZHsHWhm1Et egZ4cBvKknvRteUhvArkfgfIT4JG8cUog7UgLR3Qti2gL+ykCmRhLzz1XyD/fwFSfw7+G7oS CzCyjqIYS8/cyraBZOoD+XsLbKtQD9QeQHcoDyl+g+ZhB0KsUHoQuPwP6ALQOf8Fz3ejJmjf MvQQm4RWCyCZB+COB0ozkQTbzegNTNBmaPNUGOed7EyQvHeXL4Y3vAh01FzQia+ji8r3oFag 3YLyDeVbUG/5ofL5aA1aWH4c5O/G8gFUh7YquskSRYLNg4x9Hb8M+uj3+BaQ2zPRByCPROxE f4XtJ9CiqYpn0Q72dyA7m8u3ln+LbNAfVdBDK0CLnkCXor9Bv81kjqJc6Vyyv9zO9IOG+hDN Lz9WDmANWlteB5L3OfQIpwDZM4T8ikckSWqeek7TlMZiQ31dIZ+rrclm0qlkojoei0bEcKgq KAT8Pq/H7XI67FaL2cQbDXqdVqNWcUoFyxCMkm2h9j5hJNI3wkZCM2emaD20HA4sP+tA34gA h9q/fc2I0CdfJnz7SgmuXP0fV0qVK6UzV2JeaEJNqaTQFhJGfjk9JIziZfO7oHzb9FC3MDIm lzvk8rBc1kM5GIQbhDbn2unCCO4T2kbaN67d0dY3HX5uv1bTGmq9UJNKov0aLRS1UBpxhPr3 Y8dULBeIo61xP0EqPTRqxB2a3jbiCk2nLRhhxLblq0Y653e1TfcEg92p5AhuXRlaMYJC00aM CfkS1Co/ZkTZOsLJjxEuom+DbhH2J4/uuHWURyv6ErpVoVXLz+8aYZZ302eYEvDc6SOOq084 v6nCj5tbu7aefdbD7GhzXiTQ6o4dW4WRPfO7zj4bpGl3N/zGCBHb+3a0w4NvhS6cs1CAZ5Gb urtG8E3wQIG+B32nyttdGGqjR/ouFkbUoWmhtTsu7gPCuHeMoAWbggfcbulI+Thytwk7FnWF giPNnlD38une/Va0Y8Gmgy5JcH37TCq5nzdVunW/wThR0OnPLlx45pxcki+npTkLzvQrpi0K zQJ2GBFWCtCSrhC8UwNNLmxAO1Y2wGXw6cZw18gqoMdFI+rWvh18Ixzn6f0jCpEPCTu+RED/ 0Njn3z6yfOKIUuS/RLRIueQMo8H5yfJIIjFSXU0ZhGsFikIbp8r1Qiq5cZSMhPp5ATLoPtQJ fbu8uzEDnR8MUvLeMiqhFVAZGZrfVakLaIXnAJIyie4R0kfPHJ08Y1tMzwxNnjlze18I+Pgp 2RqxjagiZ75G3m5pW9s4gu3/l9MXVs7PWRiaM39Zl9C2o2+ib+cs+latcr7hzLmJEq6cgA4f YUXoqVkhYL0Fy7roAfgqxPZQ20V9M2GoQRtHLK1djId0V0rEw8g/Bfx7/plfppUuHf0tVlTK /L9qlFMBA8tHsNA+wvfNrKTdmmDw//Gm0fJJepecfXPbxDuNNCa+XZ/yrfq3mqfbwUCD2QiZ s2jZjh2ab51rB2G1Y0d7SGjf0bdj+Wh5aEVI4EM7jjBdTNeO/ra+SfKPlp+5xTPSfms3vMRa 3JgCtU5po4ANLGMOdewn+FnyU8CNHHnhAFKwo+SnTzFIw9HCIYxcKqXiBThPEIPjSI0vwRcg Z4L/qmm86Vz+VFPHeBNqhjL/NSQ12aApaBIhwaARvxaYo19LCnQa0MJRuD8ET90E1pod7Jm3 pPO0Hq3vZv4u/re8YiO/0bqVv9eyy/a653XfO7zKaTJbfX6Gs+Gt7m1+ElMpAx4UrOICHn0w 5Ai6AjGDQU9cMbsdqbxN88wYmXmzYM6aJbPCPCs0Wj4quZsLUggLIdwf2hM6HmJCQUcVp3yw avlKZ2Ki4R18z8Bg4quewY4xeAd+jO6mYjGRqMm2bpK8br/RxovWiN/oXYLdNkh8psAS7LG4 lqBEAifgc911qGcAD/YM5Aq5WtBgpnw0EgoVggJrtvGcMhi152qRiUehKi6UWxK2e6MdORID lH3Oi3tfLF3x+y1LPsG1pV+dXHa5WB+8nFm3RUiKO0o//U3po5++s8KL2wHjuvB0H9AMzSqP MduZfYAJziGLpfVa744cMS+sw2YhUBxqflx9WMOYE+bNaHPuZnSL9paC0me2N/LNQ82s2jtX MVfZJrRVzW2Umrf7VBoDJ6CqWXiOZpZ2VmFOfWvjrHOWatdob1LfqLlRa1xkv8FOAs29zaRP lUP5pnQ8lX8We5AO6cpHD6uLupi2qJO7uLHA6zp1RIKkT8cIcrZRx+qanKPl96S4tjjP2etc 72Qyzi1O4vxOgMe86OeyTVITaUqy/amhFEkV4snsKNMumVht+mgKp/pElNPrdPl87lm8Bmxg ER5kNRSRGBCHxGGRlcSTIhkSsfgsaQX2tZWPHggUbaN4jeT3ZIo1nGQoCgCkhziG5/BJDndy mGud2nqZTHWg92CiY+zUWIIfp7SnjFvZvuoBPj41fqKHHxtoHhuEswlTkV6SSGTGTOYifIsy W8woTPGGFJb6hroGolSrNCqiDFYJVURZ0BYFZPJZvMhsMQb0XlwVmqIoelGDKi/gQl5r9vJe bKiCpFHZ5AUOSsBzgY0ggW+iurr6uuuuw4MAhQfwwCDqae060GzGPd24J4EGQeI8VQOvlh4t Hz/Ay9lhQ7FegJcdLX9yQEez45JWW3QK2qIDdi9IH8mtLWqAWPUxmmsg10CuhlxdpM8/+9ON ekQlpwxVRQr5+rq6+kI+AkyrtDmslWN1uVqH3WG3max2O2X1ehs9HjXBPUqbFQ6RGbeF687p vcYff+PzpQubxQjJRMTMyO6rz53iNWscRl5na+pfXdOI70nOm76kYe6Nl5pc11/cWjP9qiXh 7aurqpKN6dp8aslwPDAtcVPp9RumWDl9U8Pd07+He5pcyb7izF5q3VrLfydN7IuAbN89gvTl T6QWXbEX9xLS7Ntl2uV6wfaCfdT1iYvb7cPb3Xiebp6+V9er/9KpUDptzqiTsducLjeDaWL1 7MGMLcuOYo/kxUyWEKzUFVRJo9b+lu1D2xc2xnah1fMm0o7iz6WkoMO6dMY34iM+ME9YVhG2 dlrwkAUjC28ZsRy1HLMctygtfd4nt1PpCJwzyVs9p3rG+DHgPWCw8RNUxvBjcOoENjmKCHYz 8BUa6AGa96DBBDblbCET7dC6+pyS9nGkYAoVgCJ19Xj2u+/mYsGppmhoaHq6q/q79ZenHHH2 xdJv2sd/0j01HluxMte7kqwN2i+aGaFWytzyCWYhM4KsyEdaJZe519nj6kN91ncZhUvwAp94 i3bJWwzQwaxpnZ1XBVr1PXW0ejAWy8uHz6tO5z1Kl7rLcoG917HMeZ6bw4xayalVOoVtlnI7 uVW5VbeDv8n3Q/Kk85DlHfK+8QP+FPlvxmKG0aniOV7Vx/Wp+mFAble/yL1mPMnpWMzpbySM +hmAcEpg29Y6dTuZoZ4XWEQWqVeAZb3dst21y/Kw+mHNqOqQekTzc/IXclx3SmNVHeMw4o5x ROCGuT3cCMdym1krytpttK0Wc9Hca9ti2w3kY202z29YzI6Wjx2wFlk6SCw0e0+aaS6yNVrt +R7sEU0c96bKHvMUjXa83r7FvtPO2E9ZrUMqnFUNq0hWtVP1oYrhVZIKXkE1ojquUqp+ZLCx aDu1AZmkZM4aJEOngUEG3iAYmJMGbKAtUUNnGlr9rXNkqZMAqdMxPtBEZU4PZGMgXHhQOWOD zWMw9AZNxQwd7ettMNplkUTlFHAF7kENDZQ1WrueUiJMyEC3LJDoRxYJRxAHD9OGijopVdTD roKHH4gVuUqmpJmnUvNUzk3UNJWaplJTyzXJoC7aeFfRJZiKethlHfctMdFtUTpkxnRQxiSF vDlXa7eJwUg0AsJC+QFetWrrsptSAdsv7n3ks78fvu/V8a34cQXvWlm38AYy5c0NG1ZeZd3+ Z4zf/wxzb/yosSvcIF0H/ThSPoGHgUu1yIGm7Wdco1iUfPo1dcOuPS6ilBCnk8xao2RjJHV+ 2LbHRmzPYRHs+F8DjpHH2qkxuTebx2iXJTC0aVJoWc4q42C6pSUNezLTMo3mzIhchX3cMq1S mkZlTBVCyn8ATsniF6VPjE5sQCqHwaWPGePGajbLmc/B52S6nevxWuelmU3Oe/B9mTecHzg/ wZ859Xon1jiU2fYsU+esy84AeZONOiNZRulUZB0OJoHiUJuCGh1FZ8FVyDbXzqtdi65GG52b XBuyO9B2503ZXeie7BPo0eye2pHaNx2vO4/W/sHxvvNY7Zjjr86/uo7XfoX+x/HPrDgTz3K0 Z5bhbseSzMWOq1yvOl/Jvut8N/uR86OswRjwqEEpBTzuYFU64IkFq0jAowqG+IDHHgwFA54o oCinswphK3K6EHY5naPkdWlqNmPNOh3ZjDODM9B2h9vlchC1SoVQNhuNqbLnARBxZdJVghDc ExwJHg0eCx4PKoMPSrW4FhP4icO88cGa5X84G2GBYoVCE/B4CUDWhLptllNHEZuKW1XphGIz /zLkTrngrDAbpWXPAHxgAACrS54Mb9U140rCF51OU9HJm4tI5Sw6YJAfchQdWWuRojJU2UFx op4gNlmBZ3O24DcALQIADeOgTdZv/3EaM+3jpzxiZ7YUywJesxrmLMRD+HN8Ag9llgJ+Ezsz 40ezS0P28S/ZK77euDlQLYp5YZDZuCzmi4qnf8/K1a93nDmx4/QtlKf00HNPA3qLoYel9QIR jLWk1igRyXg9y0nVuLcaB+J+Z7TKFPc7bg5Fo0JLxB+djjTaapNV4DHrHFJjdZEHJdTNAGp3 OjS9SiwpsTIdqMbVyBQOBAICHhKGBYIEXhgRjgrHBIXQF3/0DPABYoBoGTwB2KKZEmBscKzH REkAyAbxX459jb+Ue31wAPVgW11ucujQbuJoN9lpN1HVT7uRjnguKuK5l2+qn5kPh5bazLZU 1qKfNrWUaK9yaRT6kDsQ1WAbs+9Xv2pNRuvarPELSrPmRj3hcNjOh0ydeOWec7zGcD/0ThJM kScVa5Eft0vXc05AME7vOXmnBImLJka/3R7nmrhZ3BOcUhLOY5epzgNddIlqg2mD+QHt9w27 THu1ew2vK153vOZ8H4bLceHf7L8dNhv2sS6Fx+ayuxw+J6d2aJ1aX941w7XdsVPgnC5CgMV1 LqWecRFACABvrJyF1Y/itZJaLQGn0V4fZXKSjle4d7rwbtc+F3E9w+TAFrrtICY6/yi+TdIj 5f+aZ+m1rLdssbCWUcxJFgleyo0ESRgSmD5hDxDc9Sz+N9hbeixJ1l6ynmwhO8kL5C3yIfmC qIgr8Ay+HWNUoVXHiaaxc8E2+aqnQ8YOQK8xUB1NzeMDiRMms4OCUZlshDc0beUVm182vAyE owCipzIAMBMsICRjOCUXqqsQE8hIuGAtQAnmyd6vj+PlWHjwslW7I6Lrrfsf+WN29qP/nopX rFva7saK0mkRT8P3PnHdo1cMHHn1neE1a35wqHSyga9JgbwWgFpHgFoa4OrfSTG7HhtRm14y MpIRV+uwjcNECRhBocSsTqtHrE7PKnV66FWvZOZUVo5TqRiWU+pUKKDH+mfxA2B7avFuSa/A AKiVSpWC1enYZ/Es6C8VXi1p1Wojg3cz+xjCjOJ/Sk7cLHevEfcZ9xiPGxmjUgKQ7zKc1Yeg ZWn/NUEHQvFjnlqpzcWMLH3G+PFBkEcmuQ+3phMsCB1aNBqNgMQGezAMFgwgLGQKFnAOMswc OfzI+EvkisseKYXxqdtL9+HVQ8z1X99KHhqXUellpSfxveg10F8LpWg36Xa8bGfUjj7XMRej BrzCskaVGR02Szot22i0BWxDgC1HcbWkDRh7jcTocj7w8ATlx3uoJjsh09chQwA8YAH0V6CG ZRV3BovTsXnZmgE1x2lFs7WmcU7dtDU7S08mq3Z2WvRqq7oxV9N+ee+a/dRynF3+hHka6MWD NfXMgeUqYRQrDygUNprp9e5RbJTMajeKSBEiRfoieyLHI2zERA8betF6tAXtRHuQArnEZ7D/ Gx6tcGjHpOIFy2guDofCVWGiJJgBFuBEr8fn8XsYpSViFLURp8sB6jzImlaggNK9AlsNULLr oBTGwgrsUUFi5m0rkEsDCVUBsoldLe9gHFny5nrZCjFZCfRDNFLPV9BIHRXqle4hs2/dsKzv gWvv3/abFS9dd+nLbcWBug3+dDZcjDdOL8zMkwc/wfMWtOx+pbTv89Lhuz568Z+lT/bftXxw Ly5+cv/l2eA5C0sPAD2Hyn9mFYpLUANZCqj5riQ2YiPRMsjIxlBckZiH5xG1qXEUpNWxuoY6 N+Nhe529rl53r0ep0CsMqPpoI7tBu0G/wbDR2O/vD/Rn+rPbVTdrt+q3Gm40bk08zj6e4836 nD6vL/hyvryvAAqXpFjBLwTi8VRuKp5KmtmsK+vPBqBR+XMKM/Uzqxdpl+iX8kviSxK+AA4Q Ty5Q8NQtci5yLXJ3156fOz9/fuH8umX1BkarjVu0nnhIKzROiWcbB82Dlu3he7l7M7uyj2eO xl6sfjVxtPFko/VcVYMHrSeeffgtTPAWjPEzAGrnSPrCfTVAu/UBj9//jI8eybvuswIhmnQG q05nSOiqDWxELWfKEB4HvBSrYUIxq5rsxZK/Ko9xIIIjozgk8RnTCybyoQkLpn2mD02MaZRs fTqw15/gqWSFCwK70/iF9BfpcppJg20tpd+CCoPSQjqbPppm08/hdlTE7dg5wXc9AKY7xgZP UYE4OD5YzCQqHEhdN2ZHZdhsNaQTBookEP/5qTHMg70vl3owPwBlmVnrwlnOEotok+ocihsj ORy2QMJloapJ6XJIq0smonx1DhsN8WrRHMohVUaZw8CXVIZUEpk/E2C0g+EGAF5Sr9Su1q/h VybYnm5qzyUQqFKKXXRap7HIZo3FHOyUtbuxKZQmIJxtoFcdfiJr2gqK5kKmnJ8AX4P0jkbC kUnbm3I686Ro7tl7/tptiamf/vSWOV88NyUf+Jnb5eNE0d11aN3m79Y3RksPf2/u8R+v29Tg cAc1iktKia17Ltgyf2puzubVl945/74P1Ypmfwa/fcd3+25cVrs66f/ZhlsX3fGbgiuQobKi DSzGI4BTjMiHu6Q285ANP2Y/bH8Fv65+2fe+Wmn+iwbPVLfZl9puwreqtxvf93ABqbbAyobj 7gB+1fa6m0gBPEvFi4hziCqtmaW2RcKsbZ7HYonFx2jayfax/ewwO8Iq2c8pvG+WdLt1RHfG ZKJemh7qfpkzEls4Z6Rz/rL9Ov+s/QF21oJlXc9TRxRiYQ+UjzY0NHS3dj2H3EwtYpGVqf2U /9RzVhX0Z/c3MqoO+8yiIUJEb0QjKiMmo1WAN3UL2K6GkpODkkXPC9jDQGLTOgTkUkByRhpV PrKbBiyxAUxtM8l0BblCebXmasPV5qvsVziv8KqA/hXKq728qeiBHQzUk/u1E8SvpUhDKZMc qFvnqKI+FLNM82iEoGPfuWTjW1veunrN5jcXFi6Ztvv65d+5aAaz78Gt+675euiRW378nX9f 2dL84LWvlf6052enbu2jGogA3caZO5GI/iAVcLQPqCFE+6L90ZEom9fWBxqFmYGZgsKtsswD mBkKzvOL0ZAqils4v2q6oBV9qlHcJlk0SBRdLqfSlzQYNFqNVhsUqGfNgEYwyMB+vBskBYtH yfOSaHa5w2Zzp2XYQoYgGbEw1BMiTPhClJa+yEtbvg09KYQZpxbApLNVVsYUx5wBn0Ah3uM1 mrxGtxfxJg/v8wKYgaFGHa3UtptwPzkUocKkcwSgKFcITrhMoBYtMCuNQXsgaij9LbXx2raO gaS3fiZu6W5OXDqnuIy5c/y3u2d4TaGBl4amdd86hHe11HqwOH7/UGfdXMKdW09E6M926M/Z MA6C+PqnVCw2yy7ly6tTeRSinO7QL1UQr2URu1CxULmI6/J0ebk1io2KITQUfMrzCmDv4+gj hboez8BLnIu9vaE+Z593o3PQu8N8u2XYNOx8FD9M9oUO4hfxz7mfuz5VnfD+VTiFnaDAzEvN twRuEYZCJ0OcScDPlY8jAfZA+fgB5EPUU5rlg7gvOBQkKMgHhWBnsC/YHxw+yyI7GdQHV/s+ BKX1c7uo5nyj5fcOWIs0kxrMRV8Now2+GdDhebqdMOQyPMoiCfWhfjSMRtBRdByp6QGCfnS5 +wY36XTj3W4MKAGG6UklRkpeKSizSkmpULZWtR4h360I5sEBGLCDA+MDPWBgUJGcSDSPjQ3I 5D9BXVwwTnEDHqAQdRDB2KEeTcQ7ix4YGIctRQXYdJg6I3jqyjy6ny9ODLpuPIAn3A1o0iYB SVnR97LnESwSZrb43g0PfILxU1t/UpOc4jdpQ6Gpq86Z/9D2FefW5/H5h36GlR++hw07OyKZ iG1jwD97xUMPn25Nb6JjZx7g2asVtwKj+aSptwi7bLsizHRmum6m6ybmJp3iPhZnUluCw8ph brdqt/pB/kHTSErNK3mO9Fb3JohXZXjKr7qjCj/l50YZlRQI+Xf7X/ATvyksOnCik8d8tjpu NilVnIb3YM8oXnBwZwqnRslXB3B1YhTzkj4Wx2ajib/DaMRh6kA62NeXl/PGxkre3FzJwzVy Ltm9wfywAVO3U6+h33DUcMygNLiSzzBKhpvQlBVPUQdoxlPyUGuC7OOeExXrr6kJMHDzuKnY k5kYd2YxarVHRFtEtMe8KGoNe7Es8qhPGqgG+9mmNCBSU6iQo9IrV5FmdDBSooAos+Vs+FGv OHXh+B/jsWmuAwe6Dg1c1NWY9ztyswOBSFryfs7MHX90qCoZDsemryDLZjZt/+kV01MN/kLw UoulZs2702YCXVaVT5DfwhisYdRSXJ10JYnZnJa0xWRMW3Rau3XLIvfzd4YVGk4T08T7cv25 oZzSmBvFgrQVhugb+jcML4dfFn8Xejf8fvJj9uPQx+FPk1pzc7IneVlqc3In3kl2MkO2IfeQ Z8i7PbUzracoT8OodUqvJvla1eshlZexW81eu88V9yR3qXdp7he+F/peWGtO6GPJ2cl5ud7c VfGrkjcbHg/ty33CfOzVxVU1fvQ88eMAzgCkGsWJA+j59Ch2S6Zqp9/1vMfvDrgx7xbcxE1P up6305NVZnM4pNeyxqicKfz45yidqa5BSCFWc+7vgEimA99qz/hFs5a8acbY/Fbww+AXQSY4 ylglbT+1hfqNw2ALjeI6yRV1u9IBFVYld0cx1QJDUUaIZqMk+gwWUC0W9s+ZFM0US8mieZy6 IMtB3NNdzMDYPFDGUJSNkVNUWo9RHjpxFsgCvacJh0Jhvdaq12snIVd3BXP1DH4LdU2CLm8s HhB4k5ILmIJerIyrvEjg/V7ExRReXImpXUeDIDKYOs19xX9lOh0DMAUSgyKpLsm1G+8mu5nd 2vv0w7Zh97Bn2Lur6p7Q7pQONG4CD8iCpUvSZkKZ8C3J+8P3JxU93VQPm2KCq6iOuYpY0hQJ 7J6K/9NNB5NLU0zDoaS8q4s63m9uNgg0Adl0wFOUM1cxXHEihyqZDjKQW0mnpfJb5spvGcF0 k8zwCHMxKZjpPScloxEuMxYZXg/P0dMfOCmZ9fAcPVwDu9Mk7/8Zkvn2B8sxGsCNMkqUcaNj UhrS8KIpRzUjRY3h6NmYkQwHI1ee375ECPTe8cbzVyxaF7Q59MGg98EVbUuXl/6USt1/TV1H zsSbdcy+0mvfu3h2qiEWT89Y+YPNu/waN55x6+3zi20XDDcWlw7c6zAanLI3q3xC8RSgjSRT td+cpq/tbS7YowIvmMSokO5NX6TuT38qfhr7l/ivmI5ecMBSkK97zRPIB9Pp+Ko6n8sV8IT4 NKuJ+CLJSDGy2PGY4zHnYxGVVqwP10fnobm4g5ulmhFuj3bEOuLbuCF+yHSbuC22LT6Uvo+/ k14sPssfEY/EXki/Jr4We198P3YsHUAKFhQD61CLXFQdU8YLjla+1dSpWMAtcS6Ib9fu5Lc5 t7u2h7aJ2yJDacdW9c2OrRFGr+7GV/JXmli1WgWCTBQ1mINxzDtMfl4IBf0Ciif9yKgx+I0B l98fGC3ffFAVi4Ku2ixJTjEsqDiVmgvHY9Z4PAaCUIxmVWqrSqV22pwuW1gjWjUaMRQOZ50u q9PpikdCLqeDzmPSoFjwWfw5EpAff34wgI0mWuORAX8uaYxGng8EBAERehCjJFwCKtj5LL4Y oJ4KPyoZYxI0FuSoVvjaeKEGRM7+p46iC+OhUaySbJIn0+nCe1z4eddbrg9djOuOcMY5ij1P C0YR8yIWqU7R6vLis5hHEWQDrKeTNJneCJYiQxECJtznT6k3RzOqZ7AHHueRNAKK4aHYyRiJ wa2H4NbYHo5CRE9nHA/FMYrzcSEuxUfiR+PH4ly8L3UmHjZ2KtEz4HKPjZ8AmTDgPOUec/H0 kBsOwGnnCfcYf4rucjAeNjeNlDU30eDZZJS2Uh6riKGtiorMAdnjTKhoQTFZmDySSIA8Agvw 6P895XhVk6qp4nHGMkKhA66HYpRDEepxpsP4IOQWGn71UYfzmcxKs5MHHEWRZja5tt9WPGMt dFuCNgrvHRYL9VJEC1DlKnXZxJPrOMTgEAa+0+MhwLIvv5J3Ru1N+KmZfqvq2IvWaBEHl8ZL v4p/VPpSLH3ga2hi7hRZvzeQHP87/vHWJoeBEUXGwYestvF/4NN1gsVPRFF/0defkVnjTzNk Vk4PeK4JDDxOcTvSoir0e8k1HMZ94f7wcHhP+GRYIYQ7w0SiSZjyRG1tXs4bGit5KlvJQ6Kc S2mXO++M+y2zq/Rxv3l2KBh1tQj+4HSdS2cZVmJlEaEqHWcxa4ap35qhEqC1wMgCsrnAXKLT 6V36sFNKFJ3yRIK6xvywE3c6cZ+z3zns3OM86VQ4D4QO/HCCdxIJWf+cgryCX5rHBsFwOMtr XZGRPYBSBr8VAJINBuq3rpt0/stu63j1lCnV1U1TvuOqaSm1tqY9as7v9sYM2Kq4nZ5oqq6e UgqOC0uK3nDY3bQYL78rKbgq3mo94MX/hn6sQ/8jZRqk6oKmgdpbRtEYGWoYbmBHGo42HGtg Ekrc2dDX0E8PSQ1YUEF/mUYZo2SqSsX90dlVmrifh56L+yOjjEFKhwrRdEveX5iOhWgdQr4k y0FzTSZe43KG1cMaPKLBRk2/ZrfmLQ2rkW2wFAqG04FUZ6ov1Z9ih1LDKTKSwijFp46mjqXY VF/9o1vkHpwIR49X8onxBUZxk+mM8TUBA61ur0KlFD0Rr8LlxZzKzfkoEKQzFCgUpBMToJeh q02yV1meETARGpB9cROhARoxOBMwODte0LH++pZz+z0WgyYrlabapFoNE5ierbl4tq3YXmo8 J2R1GgNuW8aAzYrbx1dc3bbkfOlHpeeWCk6gQzTCn4un331BJj+v5L0gHQiHLZqGJcw535/p 5kOUMjqgzD8BMeZA9jUWgDKqAqVMttBZ6Cv0F4YLihSLJbk8BLWRgnKkcKxARgq4Dw4cLTA+ lT3uN1aIFI/7w7OrVHG/YXbIF/eHKkSqiVa3ZP01070oVJvj3EnCAQgyGg0ahz3MDavwiAob Vf2q3aq3VKyKEskTz/nC1YF4Z7wv3h9nh+LDIBwZKidJXA4VW+35eF++QqjE/zuhzE4Xo2RF F+PwYoXSqXBPkoniJ5BiAxUxhv+PVAJ6nH3wGxrl8JyH7pizTrAbtDXTSlMsUk7DtnRcuVFr qJlTmmJtrwEKeaNGbE2QsZfmLGm6trRpacAl08c4D1+5eeD6kq/H7vOEwzNW4UWPzHTTYQPy Z3r5BKuAcRNAKZw+gjIgTmbMyGdoJ0xLpPN9mWvZaxU72KHMvszRDCdlhjIEZezVtsRixWLV osTdHDeTw0KmXjNDs0RzL/tY9Z4MdzRzMkFAPwpBOplAWz4utTUJ84QLhNWadcLVwm60W/gR d4R7tVobUVmiuhaz3zLd5ovaW7x+3/QA3KZlkzYkgpUcSOJkMsBoA0gb1MleD7Otzz5k32dn AvZhO7F/Fu9UyjMj0nmaPz2joGxNt1Z8HNTOGh/soe4N+NB4zSAQzeSYkFAT4TWZbu5IglVF xYgqLqAEC0mMEwVcrUgKaGJWGfV1NFBzGcyuAWp8JRKisiLPzIDqCmfodJYzxES9iRP2MPl5 69Dsu4//62eb5hkFpzuhx6aUMWj3pLSlk2ll08pMV9t5I+vOW9N+zulXXsEzOp6ojJ/Tf3xI dou8jt+b3l+ct/a1X/yOYr2Z5T8rfqS4BOWxKC3SsO1pAtZFjPBO3kWEOqmur+4qVb+z33VV 9bBz2DXiHHFpU5mN2q1axlmXdnfW9dfdyv6YPV7H6pibtUfrmJkqf8Dj/O8qc8DjCIbyHjSK FQeJB+Nn8EEYvnOkRM19SRqcVsaSjCFWpcaJgL/KZOo0D5uJ0TzPTOhcvy3mspk1m0fJvyRe 09QZwcZIAPDKrMKqHRPWb8f4Vxk6ivjxphOy/89czDSd8QdPDKK8kADdL8ai8Wh1lFHqImHR GDRNwUKAN3EJTQrpQ5DwgmEKUkeVKawVDSlUAeOyB5iGJqhU7ElQsUgdGwPYEqJ2sECJYZ70 SdGQ80S8GSgpROVJVvWVoUkvYT8NhQqLNv20NL514O7/Hppza0ugZQHRu871WS8/vr105Zu7 lqw+cNcbszetb7BYPIziktKiPfOv+OWPv3ipdPSuiIi3rW4ORiJ58dLS8qmNXz//z4MP/+yi pc64LZSjUrHUzpwCtF6L10lPqnmzttmQuCtOLPm0fVXdDYqblEStVphVLpVbnbC6I+qwOQxM 2oDrzAXPDPNa9VrNRa7V7pWetcmrVJs0m1xXujd4rkpu12x33YvuVd/jvjvxLDqW/0gZAuic SCSrqzVYBdDZ4rL6LShZ60dmjclvjqgEl9udrdZY4YJkIhFWq6zqRDXcUu1WsxpVEnIXAGJV yGIG+xYpo/KcFGhtNBMq+ox5h8PtoqDWs1ODP9Sc1JA+UIZfaBjN5mb1PHWvmlFvVo1ig+RL vGsUsFHYLRBhZ28SZ5LNSZJ05fJPBKmQTZxLmeNEz8CJ8VM9p0Azjp/bduH0j1Fzx/iJREXe nokjqM4CmBNBwv8jnvwGQ+IByg0JC6X4GaBXmXYASJADtKc8a04dJX89jsjYUIeftKVSwQ9/ aeJUVQlcLcacalfplrp986fMrc8GizGNf0a4pfS0MejiHTnAgFFftK1Ui/8nHjOrtXpRZJ1B Q/PXl920bXqyOmc3Tu3eTQ4G0iEdr0MMndfCfqyYi/wogRpIt5Rdhpb5t6Nt/u25Xe7vR/e6 90Y/df81+peMrgFdHd2Uu692V+6R8I9y77nfi74X07CNo+QvB41r6hqpFPRW5Wku/ZfNkc9J wSQkLn++VgrFIPH48tPD08Xt7vfxu+EPch+JHBvGor6WZ2xKj9vqt4ftMVs2XdsWnp1firtc y6J3ExOP+MbFeFm4r7G/cahxT6PKnXXXdiKG59xhf8yVYZWE8Tv883LbwveF389xQqPU2Nm4 kqxk+hR9yj6uL7tRebn7ck+/f0P48ujVsRuVN3tu9u/MDTX+IvNB5rPw/4Rd3arKzJjKPJhc GDFsEhUSgTBTFW9I5ph0VaxQUNvjMTCtSToG1ptqmAayAL02FuRsGs2GDja35Gn1YGu7nEtW OD6314s1/qyXeBeziUBDsoae4NsKZondwxIEyXGWkYMhGr0pj1gs0Olp+O3DySre+GCx8Tn8 Ngqi5XKkC5i0qYOGuAAQtHYdQTVM6lOPnI11g+RpolPEBsdkzDv4zdRlkHBj8uwARyW47Zic ytySyYdiTj/m3B6XhyiVIOaImIvEnJEcznA1ORzyR3JMHtfkmCjgFZxVpHNI9FXlkL+WKeRg NIKsazo7BlJd8dOAehqkQu9MgARR68k+Ed4IfntSNDA7PS7Kfoq6ygRT04TPQoaMzIHb2pcP ffjR+FBusejw0bnSsx9eefeD145fI/YW7/jeuS89s6pzw8Chny55aefULg95yj/t/JsuPLJY rAsNMuu+E0yKzvDTV65+yMhxzdd3XPm4/fR6zw+vmnfHIlZBNRmgA8V+4P80dh5BWaBedSaf pVQUwnIuLbJ78zFlo3KucpORFUNitDZUG20LtUUfiXLxaDFKOrMbtNcY74u+EP1XRNlkUAU8 JFgVCHhcwarqgAcHQxZQbUGw7J2EYCLG9OrqOJ1YZQbJKOmKKqm5IKiyKgKsTZ8nNBf4LO7P 7smOZI9n2WxAqDKbt1jwegsIz8ypH0xEPOXoCY22J74CKCDXqEJrmtBAQOI58zftr1cBoSPB mMZUFQwFidIoRsWwQQDtZYro4qC6NEEeDIaYVqQaDE/MOqaElLEiIA1KwjNqSg5PgUySkeI3 2ssqhyYnaMq8jY/nOhO2+WNv/unjrNBG6ZVfFHb55u5ce9OvO7zRDkVUFFsDA+MfvPnnh+67 vvtLYt58rigWwoPj++e9OTh7w6H3iLhFSFLqzAacYQScEUanpWlqPw2IZ5hM4G7jLv8PjT80 HzY+bdaq/MBbeDNzje0q+23MDvv3mbvde5lnGbWOMbDEN5PpZhQZFW8Ky6jikIwqaET7sHCf IuZl8Cj58JApMcJjfpRpObRTv1tP9KNMRorTyDXCGNfye/eZcMDUbCImtwRDX90kOLHRGXAS 5yxx1cpJbEEnP3xFQx6nBsZQ8/gAaJKPm8cmwQX/ujzqBJtHqeNEd0QbsYtKjzqFdDZIVC5F Cmsc+tQk3puwrCo+dkvFv0cmwYNDyVbwgjlc0RaAG9i3A4GpHz+09YPNG8fuvfEXmwKrSyef Le07suMwbn7+ezurzR6rWwsYIffW4e2ldz4cLf1jeOBx66HH/+eZr9/Ai56dabd4stDjC/EQ 6SIO0AzNkkAUQ75VdVsUMNYJGmEYRHjcifvwMN6Dj2ElHsX5Q2iIXbSMminjPTSKl6E2uTzl ElRdcCFRjJ8mjnso0qeY8SqgpQ550H6p5h7z49wTmid49kq8iduKt3Fsq0ofQ4wtplQ7mwJM hiEg5hmByTISo2Bm+SbWbwg+yUd8piZeLaiJUR1QE/Us71lE6OAHJldvTMZ3a7GHzjVxRywR g86UQh7sTGErByW7Akq8Rp/CLgKJWWVLIQdrS307tguDoQcLdMlGkKb1dXTRiEmeaGI28dEI GcMqfEPp6tJnpU9KN/zhhX8evmz77ZcefOHf2y+DDl9feqf0Rmktvh034dY398/a+njpudJT B7fhatyCz39yG+XzqaCFR+j/FqDXpcZleBlZ5lvmvwRfQi7xXeJXZYLNwXnBexX3eB5XPOrh CPb57QEPH6xSBzzGYIhzhlCA8EZVcJQclSyAjZHkMDSbjfBznWgfYtEoiT2tUlc57IGEXwZQ 9DTy8/5e/x4/63+GxJCdgMhb1UMJeaqHahc/KDZtgV5+QGvMJxLdiRM8mDKnZDc8krQF2CeP fyy7X8abqAh5nTK67C+TMS/Iif+YTUllhpILWdiHjBGtJbBm0QueyLzM+It0auUPe2P52VyE V8wtvbQo3Fh/+tTknElWZ7CsOx9Ppb313fIJvB69hLQoIXmRpNQykhpMezVI0l413q3eBzxx k+7iq+nLyG4iRBlBPHvaL8pI8jzflyqzfTMS5VCKhRIyFZL43CMoDT31vcZCJn2Fc4Nng/fa WH/6Li+3yfl0+JnY7z2/934QVrqifDoWKYrF6JRYNr0selG0Pz2U1r6KsNsb987x/s71e4/i 8Rj+Rfh9xwfh9wExfRZWeqWQL6Yy0Mm3VTjg4YIhACC2YAj5hGS1L9YcmhcioRBnq46BaiQq TmVGbh5wj+Tudyvcs9ITAwFUlpQeSZPd6aPpY2kmncRVRsODqfQovvJgkC5okvHCNwuaOihV IxXMEKGYYWLGJ0UIPWAIFc3FSTeCNxx3eJ1iLBJ30EkwXkiiruocFj1gO3yzymnWok0S768K BkJT2Cq/MAWGRwBhWQOhhCy8Bgbx4GSM/j9n3Mra3z5Bk6j9G53P4Ye9kY78+LO5JaLVAwof //3wr4d//1rNYEthgW/tPTNvXJTrJNeUrhgKJEWxIbCBWUdLcw5c/egxwwyN5qGhrnvmWIBP TEBPneJ2VE+mSGVjMVAkZiWP4fs99V2aYe2w7n7jfab7zfcFdhcPajRFV9Hdy/eaegPr+PWm 9YH7ifoz/1iADKmvM7zKvGr8lHxqHDN9YVY1m5qdzYEGobnYbhzUXGFUZUg1L4hCJFNswA08 Z+MX4wX8IoEN8UvxUuPH/Je8YpZpZuAl9Uua/9IoHGo7H/AFAm1kmlGpNRkterfOZ/QbAsqF zGJ2oaKbX2RaZFG6jD6fP7CQsLwRE5PZYuFdAbfflY77o9EqDVH7NdRJGA3VRTMtBX/ddJRB WgvPh4WAVcBECBh5gBHEijEB0SUEJKMFs1Fi1PC8U1OPkIMuYJnr1L2p1WqUMExdLqdGm9UN 6chJHT6mO64j/bqjdCaAw7HbiZ3uQBEXg+E0CmcyKM0D31GmU3Sm8VB6OE3SfQ3FUXzVwSCd WQx8NzBIAcoYDypxkE64pIilZ+CM66qp4sR3UdajjAemFeBX2aIyTM76pgVEbasJf65sT1XS rfTcyxxH5yUPDtDZA4MgoekHDaABeQkEX/5EsoKZGIiZixh2nwT0jxmLRJZnRS3NTEVjJVNX Mrp8bb+p4qRHicmJBj3YJM9unvDKKznOYqeLnigvy1Mw5eknjv/NLOh5n87WqYIRfPuCS1s+ +2xFVTbsmlpqjXhipb+40h2ldHvIpjUaBLet2oR5xe1f9/92ulmns/qIIJD0lPdLv7smmDFo wmFsszhyeE3pWHeDE4fDJq0jOJ+ZtnuGxxTqn1hBuRakVgzl8QvS6NYqbL4p8krolRQzK/xY ijgDjvTqMKPGajEizkBdeD1ZH74GX0MuD1wubKy6StyBtwr3pp7ET4pPR55LlcM2pXAjvjV8 Y/S+8CP4YfJoeF/qhdR72S9S5ZTejOzYTcwxkEY1jenG7OrwRRlNtYp4vdhGdVEVEmMeBBDY EAyBivIGQxJJiuFwFcFWQL/hvUQgXHX8EY7nOrk+jqHrdQiHPHu9+VH8XclYG/P5vMRoMADi UJmDlC5dBZpJwXkFFNwXJPOCe4IkeIivw1Jdf92xOqYur6qy2x4sLD+CXejMGgO+Z/AU9UhT mZepyLzMhMyb5EBgQXOxZzBDV2S53PzYGYPeXHQDE1f4TZ5IXZN1UqGYqvGHAmIqlMnhGj8k 6apkDoXCWaGWTgGcmPr3zcwImQ/F8vEDOjqH5eQBazFGF+hZi4R30eLJQ3wxy9OpfxMcB7wW DOLKCrr/i7TkMLAbrp2Ql8BqirWlu0uFnKD3897I3IIsN210USn+23u/3PnDJ7Gzb8f6r8+x eNUvvbL7BjCOryYYlzZ+W3o2P3HF5tFI6Zqbu3TkTvz49Vt2UwlaDRL0KeCtHPpCWiwV1niv 9N6ffcK5N/ts9nhBtcTVr+zntqi2qIeUQ9xO1U61Ohzw+IJVYsCTCIZUQYMhoPaouCAhAaWH 8/IegkMGo9GXQ48k0jQiQVKj5DfSzGQyAdj2EZ/nE6/Xp1LvVamUe5u5LRxBwCjzOIbbmN6b TARSGbhhnXuv4JE8H3oYz8LOQn9hT4EpIL5KDD+YP34Eb51chkzXmIyd6jkx/lVPD50HSgn/ ORhJkJV6qP+Pev7Gm6j3hh/7HPFf4kpGNaDstjMF6XjOmSogJii7VWU3eX2OqdDlG8JQfA4l vBdXb4jmlaJoMJgXLC69y8caPr58bXZqS+yK059lswnB4Q4vyrI2Y9SWq41dqCDjn4TSG0qx ld5QrNSyLOoQMlM3l/aKDl5ayQxc54+Jpd9d0mkzVnSZMsvsQ0vxdMmb5451f2FnhrqxqZvG MhJ6PNyNBZUQ9ztHyddPVdXH/TVQkLRVc+P+GbPlFSSjjOGpUCLuz44y+qdCLXF/OxSkqaHF 0Y6WRf7F01Xx+g6pGI+pECfOWLKUa0oqxKROo+WUrIKb0Q6DwKHpdjjcYEkFswLuF0YEIozi gmSsj6cT4YZsPe6vH6kn9fSYvWNpS3ju3EBHZwcZ6hjuIKiD7yAdMJIPW+35jr6u7lGy7CD1 vY3iVTdRlZE4MyXwFA1znKhkTRN+ONmF3ix/O2TdMTHlpIjOBEAmY1VVYZ1RL4YiYV3Qiw3G KoN4dqwK4EgCkAkGQsqe1v9NwGpCjMvzljjO8U2w8Mxh7qxI1rdCiDncucqcWptbcq1tze1z Zg0E7XpN3TmlJsuUoEPDeqJLCpfMJcTW2F6qmVvUKoLJeXWFhSkXDaE017rlcGMlhvL5KmOk elXvVXPmLG68trRxiWAPhMMOeYXMjv60VJipTZTmyNEuUAgL4FiN5EvWl2zL6jzhsGfKYnzB PcmgHJoE3jkHwK0RcJAN3f/0sOOo46SDccjzx9rzNJcai1Py2HFAv6qu04ElR6ejz9HvGHbs gQs5XdzPza7Ccb8yGrJG9S0Wv3W6DSFOqUE4rNdN/Exl5XdhSn5Yhzt1uE/XrxvW7dGd1Cl0 B+xnBWwr4avmpm9CtD14QJ5Shgfxt7t0Uote48rPKDU3p92GgNMdM2GT4vbTLUsafHIElpHu nyGH+RAp/7s0m3kGRkgUFTErfUczhc7JLPKz+PP47Sb25iSekmyeMid5XvJi08XJy1WbTJuS N6oe4T5V/Vutz07pynXn1+VZaQrOqJhY3GyBseS6ucpCF2CFUDQ4L+pH04k5EWPYNCifum66 biYtGrQup6G2JqAZpq7nIc0+DaP5TCAWefaDIHQG+4NkKIjppMzKRExFsK/xpTmTq4ErM2Dp 1Egaz6Pxa8eZ+DVjoD69porXIFPg9CoxH9FFsmKBqxVwRg9JTl0n4BptWvgPr8EgAKGeBCPm bJMz8Th5SlB0sotz9rMCsIoK71NNM8HdBLsjM3bO23H+wLb+H82ui9U6inNKgqs+arHxIb9T xHm14dKFq6bOP1/qymbCTHHw3U3L1934ztj9W2zGVOnTC3J+UcR2bc0qZkV31mnYUvrR+lBj 17mrj/x64Fynmdpay0vtXBJ4chpahP8oXfwoerTl8xYGuZCXd9m8na7F3o12DvMo9gn6a8vx JV+1sV2dj9oetR9bwgqdwnxhQa+TDSIBgwyax65FF5I1vq2I3YR2oNMtzH5Vy7RpuWlo3oKa aS0EsVrWXT2vJUfYVg8aZaZJan4qnroWteJWqD09zdgeQdM477PMNHi+h5lxaO51df52EJjz pTquPZ2v0yxYwzbU1Cxeom2vbnb/WPBkQQMxHveSYoNx1tAsMutxS6NQla2Sqjqr2CrX4iWj +P2DwQcuAOFWLwu3Huq3BTAMVtjYKdniGv+I/rPAqTF+/GP+I6A8/2XPeM9HslQzFyeWc/Gv b+UNFQaYMn1O/TmK7IyZ7TPbZjLKKY1NjUSZjKhFW0QQTWI4EhP1kennzNqA5tTP8iFlhvUh VUq7AdsDwItXHEROnxvyp7HXA1hHpMckHzJE4YqZja0b8OyGuT6kyHI+pElwG5A16JDvcnkr uTlkhPwQ1sWNG/CZKWnfBLzO+lT+sWBAhuMNDfSfMJiJPwOoMxfyJByqYqkfi80JyJIjKFgV JgXejHK1rNkmr+GhYbDJyGYlGlbPUYk78SMVLK4YuqLFmxBm/fKOR0q/OfyX0oa/vIH738Ec fmJD47JSpPT230pr/9e/8Aun38IdP/nh19vndpjvPDB9xmXPP3D5ea3dfPClOR0DnVNmJBuH bhUaZjE/LQ0cvyosJO/AMw88iavu/7KU/9fHpW0vYjc2lv5W2vtn/P1/YRV+HeMnS08febq0 6+GZLQ3nHbx4y8XfxWsHFra1XWaZt+GV4a7meV1Pn7971bRzQR6dpqsmgMPt9H8lpU18BD+s PKw8xP01wCoiVDYJkSuYjezNzFb2UeZJFTeDw42qSRHrdOgQ67EjPoiD3YTziGqtvyagGFaQ PsWQYp+CUXymsyPkDOt0vL5T368f1rNDkIzoGaTn9YI+C8Wj+mN6Tk/D0k0FfZ/40sTC8zOK dlL2jNFF5yB5volHx1wCo+UiAuMXsFvj9CKXU6vzqqAWYIMCdmk9XuRTemS5I/9bxYR6RQNY jnoO4snVhTKa/SY4bbJ/g1uVeMpN99326x/c8mTnI0uMgtNbbcCWVO7S4nnf//6qQiFGvjry 97dP3TXU2MgcekCORo/Hxv9Qm3vthZHnPVaEy1+U2llz6T7EIOEIIkxU0iMjg+oUBK9hZ8wE GfslneYsO39wsBBkzaf/yIZK7YuQ/I+Ct7HnsT9DWrRbclOvMqAnNZtBgkJQZrTr0Xqtsk+J lS1GZj7imCjSQK5FDJQIlBBSQUnNzD+s1aI+BVY8DwdZhGjKRJ/GfSqselapHYU2uRV98Lhn BZIlEuknx4hCIJicr+u6oKIETtEJAid6UGbsBH+ih85nGpO/4yd6KkhUNEHbTTlT0BY0EUfJ gP/RiU+VdLfh/16A/14yLijRZcRoPnDb44q1yIGiWCflrom+r/hd1ftRdi27SbFZdbX6St1V +k2WK4VbVDdYNGrVzjiZolJEncGoU8H4RRZximfwSuTE0lNR+ucoo7hVUmfE9SIRReSniwIN CjyKb33K4UB65zN4KoKR8XTlD3YY8yi+UDKjuBQfijNSvC++J348zsbxM1hCQbhM0rygIRpX jC4V/OTMUsET8mLM8ROVUNWY7IUa5E9V/ldlYgmyzIzVnrDKpIvwojcSigT0wRXIZ6QLBFVQ ErT+FdhjgqRKLa6YYMez3ec9DrDSzfWT/2FS0YYE+BJPRpjorFngyXXXH387/v0tO99cfc2r j115x59efeinJGeetqmj++bult70/9felwe0dZyJz7yn+5Y4JCGBniQE4pIECDAYm4cNvrAN tvGBHYIFCFAsEJYEBB+F3HHS1G5zNElT223q3KkxxATbaex203a7PZLdNt22222c1ts2m82u m02TTRPj3zfznjA4To/9/f74/WHEzHxv5pvr+775ZubN8T5j9zBDOPd4+F9fnLz36Xue/ejX s6O33MScunV96M2bjx7+8ciWYmDzRRABGXAhE32RT+ctOy1HLectEmThLcwwuhMxuvo0HMH1 SImPIhdiKawAGObw+H+QHkdgfl0P8Lu8Duv1jJLBUqVCw7DoNP4A0FfzJp1OzxsrAvox/SH9 Ub1EbzWfZnLxBZGqZCEICCsMsuiB4LkBMhWm3e1pwg4R8r5iKTM3cr2I1zjTam+YZXYuylTJ PVmeZZLvfuWju+KLyJZBJrt0D/PLBwq5HAe5HWrf5d+z90AdrSgPleM9/Ok2jJXljvLC/Fj5 Hte4elxDds/f6hnPu6f8acuxrCc9U5oXsl7MO5P/bdW31f+szZQjFZZpmSxlfqbWnOXRenRN +LP4Nu0duqeRbjGqwU2oCa/2duAd+TeU34RuwhGmN++m/L7yvXhf/nDxvvKDkoPScfm44lbj raaD6QczH5Y8pHjA+JDpS5lP5D2f/3z5jGRa8Zb63zVv6d7Kf6usQK5V5tfAoHBRmbRBgTRZ +RJqGcz0zKtMWkKcNG12vRLrgTM8NQGADbiHN6AKvoIh28OOVpyvkFS4X4IAFuS/EOt5VcDM w0CZNVuDp/F/4rfmZBsaMAj3OxfeE7QrlWezIM1lRf4clzFTosjwOKXuTuSQZ3fi4vTCTuQz BUCMJVwnziHHXosySzqR31giSPXcuUJBrMkrBpx35divPHNu3zf4ecSVVNJlmtNS3S8Z3eED X2n/wdNf+/vosxPVa39x4pvRLaO49GZ+uKdnvKK0clPLff3RW/NWMs/efnTL7Wcn42sP77p7 fc/ug98fDSW2n/hpdH9zZGS4Odjnn/3dimM7b/nSnq2rqm8iq0YgE1tAJsrw2lNIRd95kJdq fK2mul7ZqFqhbnJJXlXigoJFBXxwZ/DV4PngByo5CuJ65Zh7j++Z3FO5p33f873hfsPzL75/ d73l0axWFIC6mfJ6DWiGuTD1WgDDvDV4kpUaMnHmDD5yMpsv8gezQU9NGbQF3jO4D6UjJfMb Xt3CjXPMIXq+foYtn5rQYM0MPgT+5GapQyVHyUsHtvxkB3m/IJ9h/o1X8UF8NHguyATRDF76 Ip92No1Js5Yv0FaCsnqHqGuwLgjdShHZ0EVenfvFc4Q+f06eSi+RkcXWXKfHKZFJPbq8PBVw 0y8pAb7qAXKq8zuxSumTAbcd2uxOenpUZC9dQaftNI52FxWlzQ3fM2ln6pzbICJsEaqgZ5zJ Kwhoy7RP7as5cfvjW5ed3j8++IXZtw90+Z3WLOPNZk9hzxfdWY6ih9ZzzUdW3bLzS32SNQce vKl5+wOHS6f3TtzyVEN+drFCWidTH442Ny3K9tbnqG68vbl37AnSV3YCd8kdbU4s45d/TYJN bTmRnDHpmGws+7OS+7LlFUyFczO7mdvq3GUflo7a72LuybrH/jj7lJJcsqZHbkxvIs/INCvS tQzLkkP/Rs6ZzrESzplls7Nyi0QKvkemOM6Zdhp/iCxsGq/RavGvEfNrpxN6VtLj2PDKk+P0 heEM/iNwzY1590434wZx+HDawByFoRJJhFdyvOGogTFYXafxg2KjvNBOXke3kxfPlJFCr0P6 Hco+0JOpvT1S4b0zPWe/Wzywqd4liZm6cwalg9lScvcWljvlEmE/w7zT9yJLyJ4dzI6un+1r w8ov3bH19g2J0T0xnzsr39+0bujE4Xv7X8IS6dpnpvMP3z2za3o8v2pTmb3I4AyeGNv7ek2J nNGT/nwb0PwEtCgL8qJ3+MIh5bBqRHer8ueetzwyGYv3s3skezLvMEtqFV6ZlHVbvVYZy3XA sANaxDSXB7pBD/31fVMWJCVqbkqvxYj0x25ysF+dhQr5QoYv3Fl4tPB8oaTQKtAXgoTzmoE0 Pu1Q2tE0eZq14MoB/4/b1126IJ7wf0/YbiB226nNUbQZFNs9SlO2PcfOyIwwK/Eo3SDoBlsn cuoAylXldWK7ietELg03v8cuFCUfZ+hY+ZXhY36eMWjKrSzHVJnNjR5l7EO3P/n4rtxDn7/3 B737fnBv6OUvYP3/7Lr0A9PKFeWrtx64e3/eVmmfR9v81e8e6Do/8cxnn7lhCmdP41Wz2y41 3LVp55vL/F97+Nk/cUS+bdCt/Y59AC1iw/xlU6MKH9Qe1B003pV3V/Cn6p+af5H/i3Kl3pen 8qhzNXHVkPq3ZXJ7jU+/vVLiq5PWGeqMi/LqvNXBQM1qdbOh2bgiZ3XeWm9TkK/ZYt3iaakZ ko+pxwxjxrHMMfOD8iOGI8YnLWfycnRSvUFv1Bc7DA6jo7hAVWD216gMNZuV2ytbaiR5FosV mnl+MFihUms05RaVUi635gUrguUVHtPBTL8RGyugiWRqsvdbW3JwDgzW3GPQGg66sdvq8fmq y0veLSjIL2+BCu6vwBVSqdxjlctzKzzpFRUeTWZ+fqBck15ergFyWpQac3m+x6pe5OcL8ywq VhOUV+jt2O5wFPv9vjQDsygHmYxGsgPPJynBJSU5OdkqUKuNJ2Ogjn2eGayb4qzYSnS+xlDB Wyes560XrRLiMaU3Ba1nmEpUjuS4d7LClz+DFVMwdCg/w3wTVaMaZt2U84cHLEVF5I0tTIiL 2ot2v/Neu3jio128F8hAttEa6FHhdjI2pBelief679LtF/bjEQBbTNX7/Zb/gDZPJtoXiAWm 3d9Oxtf00bDvPwCSKwy1utq7dIba/a+8QpxXFK/IwVHUkkk3jrfTqUxqRUl9+eKkiiwc/c+L ymozOQgG8O+nwM0Al1fajXVa3maosxBfeCAun2bW1UnJSXa5BaxKApENci+CW+DVk9QuTuur PZy+WkXO4+rJ1VvnwSkjKwVaCNBSH3KALI8jxgh+RhLvZ5NqEuf8pElwjNThbdpqA9TfCMbM m6oNBn21EUwxn1GdJhxFyRQcE1lbySDH0y7yaRnVlYqMam8gvboAjFGRSXpvSCyzuoA3gsmo LiMGcjaT3MGY5q2VffLv6kNreEEAOfySOqxGJ/Nu4fgLWVlLLaRBz5ZPZ/zkmbx0ryL9nA0f L3C61Zn1TatcebiyNLd08/4LrauqZ1tKrGn8nfc3lJTMvp5ry9t+7utrNixhH/DYzZYyg6uv rysrI9vjYS2u+JOzM6OlbG5uus5sbn/llR1GSz6TmytNzx65/HG0ioxvl8yuYP+FPY4Wo9Wo DYYHt5oyW76Y90gli0oMO5jhwuFNDCqU+WQb7+UkdVXNO2JVQ3mDO8iY9Dbz7ZaDFfcsva3x YNOdzQ+aH7Q80jwjOSV9wfyC5XvB7zWd2/HajvM7Lu6wZXEZ5YaK9ErHDumTijWVdTaUyVY6 19iQdfmV26yVaWnpSsW4B5vogax0TR1xeTXIzhHPcc9ZDwvN7jCv21Y07sSmI87jzrPk5KeA Sl3AdBIU06E1eA25uWgNEcA1Lek4HZrgtKJC9gh9BVbKa6xrVH4rbrGOWxnrN5h/QjKY3K5D tRCkksmtG/CG4mL9upfZAAqgHLCr0To2wFsMARwLHAwcCbCBimofO96KWz0OLyanwPhsc1bw oBc3ewe957yveSXeIW5HYAe/4ygQQbqDHldWa4I7dAcfWoFXlHKZWJ85mPlqJptJzkekPVKH 60oDbAvLtLCY7ANiyDmhKWt2kLjTEJONbN9xGt8MgxLVCao8isiLDXpJ5zvxC4Yi6OV3F8Xf 2W24QHZFGt4R79a79Fty016dgU414waI9A6Y5dteIEdnmfa2+HvvtJNlwxde9bzhIc9E94jv 4+auWErNTPc0ba1pzK2wZ5stWJrnKSstLw2WsrL6vOY8n6cwb4unFXTo4hw7aqpYx6FluI5D S6R1dtRSss6ONha1crjBssKON+dvteMtW7NrbIBuW4zWlq7hcNOaikqeWc6R3UGSWjte799g R5sKNnCo0bzcLswJUneOiFbRguZYSCcLZMmjnd4kSS8H5FU+ste7wmAi14VePGESL59I3Sgi LIZAxytzu8UJhUzoeMlvrksWdqpX0Vh4bgpNJxiy+U/wXNG6/YdHb9v5rSIdzIxZfdHIoleO NawsdjgD9sEfLWmP3fTYR9+8o0ltrJB3BIuqccaa7oZgy9rOxvLZ//EHarq/8cKz5cFH38Tr C+5vu/sVXipTmrNUUtmqwfHp9LzqdCMnl7BSpXZw4+6uL2wtq7RYPMuUXY5Sh/tG5q7hPYe3 LovvObJ92ce3lG/zBHKXjq0KZmZKZKTPv/ymfD+MaauZp3irUqaVaxTQw6pUAVm13KSzpFVr xDO8Uwpl0Ea294JrB5e/DEClssK/Rtkm2aZ8UinLkxUpitVejTfNm1VgK/Tml1bKqrOCgZWy BnmTepWtVbZNvk3Rptqm2Za1LdBaGpF1y6Pqvqw+267yYcmwbFg+rLpZvVezN+tm2377zdyQ /w7JZxX32O/23x04UPoF+SPq+9PutzyS9bDtAe+D/gcCTymeUT6jfibrKdvT9meyn/RPyacU L6pmsl4IfDfwoeJD9cfZH3Jr+vzhQF/pAaVkkS2aE3MMlEjC8rCiT8k2Kdc6Vnmb/JI221b/ Bmhi8hbFdjUrgVk5q1bbM/2F9gJHqbxarVTa7QqlUmW327JzchRIhm0oLSvdxmekef0FNq9J Y7SZ8nPybPnVpYts1TOXB6dsahU3cznGpwcUck6jVrtsgG/LsttzlCoV2fOaYbODh92frVC4 yL2CAX8pqH0SYg+UwmNpminf64UGhhi1SqVQyJWLD8uOlQLZJ/mKUmHLNd1CnVcSCAZKx0sP lbLNpR2lO0sH6cP50oulitLfK36n3Ki2ncxSn2Y4lIX/xKvJbcSvaVjNkzWLZ5ibppy77hHG GxeshgsWw6X36GaBoku/ndsfIB4uJcdJ6ehCKo4uBEAhArq/5TiprpYcBpAL2yPFP9ROV24w vfqCT/d6M7V1OcTiAmA5yKhBWNohsw7oNclBATcmx0LzU+dHSHvDafn5wmmB+Z5YmI24K+T7 K5blpBfN3umd/f7sD3Nn+0s06Y2L8fuWikXFWP2ml8vI0qZZrWkFjCF3UbAESzBTnJ2Zt0S6 1pMXdN/+0Rm26+MvS3o+Y87zeDwBl/szl+TMXfEdZXlpWpNCBl4F5WOXHMzb+wJmr0LnIWPq cpjE3Ez30u3l2528t8LqDBm7K4Xd0RaHzeR0WenuaKXDZnS6TUaGwQqL1aUcVIwrzivYy+S2 1RbFTgXboTineE3BKkLcoHPced7JBujtJixZTWPotZKg98m1BeS1tri+KKwGFxV55m+hyF+w Z5nu4WFuvnQm0Jpn0aocxYEA01i6Kc+qVXFFAahnKbeHjfY6rSYLhT9+gMKkbk6EJOQLUyUY nfD6Z3AOX+XprlRKlKoJP/tw0emi7xT9nP1x0VuSt1QfST5SKWHeKBuTjynGpeOyg/KDINYq ZSEjd2pgBJ3HaxU2eTY59+SSORmG+BRIbTIdPY2Q47DlOd1FxV6VQiORAoncMOQ3lyB3HvIa yHFr5se8B1jPwNQ6v8j7HCKHrQMFPDlUWHBIJnPIcbMcn6UvdE/yKqRz5WQf9s277ZxexENe Q9P3sCD8/9k+tzdCuOCadHhkXyfZHXEp5QqXE0ObwUZ6JzG9uMotErX8k0RPI+H48Q82N2s9 Hpzf2PABULk4UHrptEh94Bb7B607qzF8k5S59HZTbLaieY1ndssV+qd4MfvTjjYv4YLx8gX2 HZi1cUwNrzRtUm2z7LCyVjoyrnARHRHKqEi3pme5lS6V08iZci2clcuqUVarakzkptWarDWK 1coGVaOl0bo6K6J4TPGI8stZj9qOuJ5GTymOKb9q/Sqo2JcVJ5XTqmnLi9bTWWds51yvW95X vW/5KKvkiBK76KHonUHqFpUKbk6B4K5cKbj5+YLrdguu0Uhdnrfag3rXPhTHcWZQuo+7RXqH 8aBLWaMIqoKWatt3ZOecP8uS3606YLnLylaZVlmYNAs5O2XjxLNTM5fv5IuVWVbOYrUGlKp0 UNW2rCx6gkr4EoqEHrgSzk1lWdWWGZzNmzpU2KDKVR1RTat+opKq9ittZKnawMv8RxWnFD+C drZfaR3KIle7c0gpzN6U4tCL7pMrqyDOi5oKpDynZJQz+Oy0wYXHXQI1AIu40/q0oJMc8rfC CGt3/L120iCzLll+a4WGKp7yb49b3hFkjh7iJzdf3yUerZpTrdfQrILy3D03oyC7S4swGduc VHGgMxUw73oRXGWumpwjPz+ZJsyMVGnVCg66dDDifissTEWucR5L0LJkT0++ER+35xdkvP5T s0LtCuKiYLrbPnumYPZUptdhLIMpRh7nDszKGO2ibJ1Sr/Z4JMacFR//Jyut9BuUCiKn7OUL zFLp52BmsZFXIun3Hb2VCGOyNKRl2HSGYVny9QU1msEOPp1sd9/JDrJH2fOsjD2Dn2e+L5nB sRNvkMUicVJcR3slIA9oONIVMEtnM1rw29LP/WmL9BmSI9kR+GXQT43ou/zuwZVHV7628vxK SdrKw3a+sgVAxuSwqZ0uF9mg5wo6bD6nq9FhW0ovBFbR8yo2p9vjsJU43RUO2xKnG5J05+ba li5ZolarGF9JCYwJFKY0F8O78BsuTJa+B11HXa+5zrtkrhmG47MMK3euPLeS5VbilY0eV0VL cGeQCR5eQdT1OsN7VFEbiFwsONEsnLOjuifFXuHy5nbsvEqBz2nwK8rG+enqR4yCjzHDVLsH mAa6G0tQ+5deCoDav3QPDSq9qkMIFDkszD/j2/sERWQ21Hd//OAVrYS/PNs1T0ftmodGOFEA E8oo6KgM3MEvMikkFskRyRHtEd3TkhmJ/IgZa81D2tLKFrRN35LB2iRmXZr+RslG/RuS1/Ry 9L7BUJ+RQ66az+XLpNIXVDlqiU6vz2Ul6SwrYdWMRI81OrOW1TM6SYsUSwNajczQocf6AGZU +jPMUqRDEmYpX8xi3xEoja9FiwNaXjuoZbVZfnOdudnMmjU+dQXIH2PNNH9FeA2z/r3d694j 7/nIMYr32i8Y4Ec+5xGvpVaqUxAnRNBm79r/igUv2EVHXp+geBG0TfruRHf5NV6ZY6pjA2DR 025aAPQ8ecrNJNtwfzmdWS3xphPwZ9Pp1ZJBEwEPTZuqJZYMAv5+OgNAPQVP6Be+eKD3OrPO CuykAyR3lTMDO+lWPfYG9cc/Y3bO/iRUm2aTeGUsuvQoXh9pMhvU2Dr7u1y20OouWzPr+fgn 7mKuV+SY5EVoOxy6k7cZkIFsnsa8ayvTy4ww93CPcE9zpzgNKDv8Ob5c1125mbkhh4ExDOt0 ZVbZjEtcKnIyw805OHqDGot+ZzcaGLubYRXoORxlZphXeHWm2QXa+rAz1C52xNDnvkevOCEn uC60Vws78XGciL6ZvWobaEaeKP50Q2Kl5CFn8qPfpvZ8Mj3RrZxBU3Zb12Of6cMj8tlDnkVc kt1FPiLiwYX86MfPbXJkpPuGoK4bWDfOoidyNvA2lW48p7dSbSmsCGoWgTWj/nv1z9S/V0s0 oJlaX5SxOrM5S4lm2ApepdEo+9lxbevXqFaq9r+z3pA6LkvfnEHp09i5xSk5e7jSHCwpWZxV CRl69xbxNYsDns/P/pzQu3V2DbMPtGMaquHdDxmfNDJ3ag4YGdXDSiN6GKdhhFTKp3SuFhmW jae3Cmvm74gXBtLzPXSzZgY0dKbCgKoyZOSUlDmHYfZ9MXzoMVz2/t7D651Za/bPxjxrez6P 7/kJrsSXBwob/mP2oW//9Pg9Tz5K2gWUYQstQzWfWyApVKySspC5EQqRBqpaqYICCNfbsbLx jG1f+2QhcHtaBegeU4YBycl6M3QlPsb3cPjgY7OvfrD3yDqntWmftLuwqecLsyOvz/7DLB7w NL6Nd3379Yl7nngUMWg528tuAk5kohJ0K+/FSCexmD02h9elMKq9vGvabOTV08jMItYPbNDT 756Q9z+FvN5WcxS6sr/T6xy6cR2rI35KSc3xdJxu9cHgNDnlJOezUpuQSMHbxU2VdeuEzQZX BnriF01wxtwsvnzeqRnPtb3xim1rVUqttthUsGRN1fLoHcyOMK9Wa9TFmQVL1i1adtOd0l0F vu7Fbq1Ov6Q40Jjc3P18Xl7NDUvtOp1hcVHpqvjmyPPo8uUUFTCL6qEVPo6gzmRaxyDMFLIF 0GG3k5WR5bOvsJvovcp+dC+/5DHbY76n/TP+v/e/5Zft0Q2Z79HdYZZYrPZ8hCV6p6JQY5ku 5HPVwlXLpXX2mpYSrC9xlIyXsCWUgEfzcf7fLbiDeUpvDZTOJx25gvn9drJbhlwbcAH+CaHm U2x3+6fdyCz9FP9EuE6l1qoyMzMLa9dVLdt1F+7auk6l0mgzzUYgZGVD9I7ZVwqr25cAmRSK 2qLAqvjWyNdzC0vCi906rUKxtCiwYghIKX6dQPoz0FrLGZ7/w17dyzomivAYGmL26oYDoxV7 Ks+qTmsV/QibJI0+mIZVMpuZMDPOHOAPMY/wU9oXdKfLTy9/XfvPZVqTGrM6RsZIy+5Fd5Ud BqV1VPePZQo1IocApRqHMkdbiDzYryQH7D+LvhP8OXo3qFeqreoArmDK+WV8S+MT+HHmGD/N TKsmlv0Q/RK9hn/C/JR9G72NL+I/qi5q3tVaMsszg8GyQLAVP4Ie0D5U9mCQvISxycg9EE6X n36foLZ+ia0WxrE2qZ7eC+Gg3yhYHKyxLQa94NJp03U6LYgKeX/QGgimBwJBhLXBemljANUH JTVazJAXqXK5blB3Vsfo8uQSuTwz0/qcpXbxYq83f0lNTUFB3nP5FrNZJpPmM1JF7f0SXSDg l4xL8SB0qDPMIl7Da1u0zLgWT2ixdob58EW/3uXIOdzQ+BKupUezrWjuqBXZ00kuNKUjWpCU OkNq6cJw5Sc80BUJk5mefRFXMeZdKiCOe8VTCAse6MrEbrQ7Ts7h+ctL6v3LSpaTu4XpGwRV pQXGviouXVhCMFTzBh05fvD7SV01IqNhXepCTTTvQk3xDQPdV4Cx+BKevjzAf3FQZaysQsJb fOKnY8iF8t34vb1f33ppb015WsVsMR1X+S69PG9ctcznL3ZY0odwwVJbYZkDv1u8qm9t5knm 4qx+b5vM48m3WPKC+NXZpgXzP5dFGFvx3bOhtCg27PDmmN1ko2ndivRT9Du3oB8eefQtqeb3 HfraPyqsCvrBz6/+JvtbqY9/kj1j8v3kK9FIKX47m8aTO2cb0da5b4RitPBvuawa26XfRW72 PrSaqUbp4K4Fd4KBQHk2cjHPIK0EoWIwHPgNgLtGkkDj4DaCYQB/BeA0s9moG9LRQtxa8Cdx NGAawG8VgaVbkAtgNbhrAH8T9f8NWgppfh7ScwGOEcLc4Fcoq0ZGSGeJBF3+UH4jCoH7EZj/ ktyGPIC3AcxFMPvAbALTCWYbGBuYJfL7kA3SL4c0nSRNSIcV61cAaRfg3WgDhLeC8YHf8pQB HNA1aDH6BdPOvCdZKSHrHqdkq+QO+VPyDxSHVFrVW+rPa+7SbtJzho+MR0zRtMXpmekfZHxk 3mtZA/PzgPXlrM1Zt9gi9l/mqHJedbzD7XRWuZ5yt7lH3G/kfpV8WS1fm/9d7/7C24tHfPm+ B/3bAs8F/q30mbLbyj4sX1y+v/zlYH2wNfiryhDl0nK0HQZZAfJxXmSAHgHUgfSHegv4Edas ZLcjsqYjfPcViTBGOfSJwAzSYbsIszAZLxRhCcrBj4mwFFnwaRGWIRf+JxGWo5/h90RYgfKY H4iwEt3JvCvCKukW9mYRVqO44kcirEE9Sl6EtbIXlE+IsA7dYNg+J39jhmkRxkhvrBBhBsmN DSLMompjkwhLAOd2EZYijfF+EZYho/GICMtR1DghwgqUZrKLsBItN/lFWMU8a4qLsBpVZ2TP fWW+PGOLCGvZ7RkHRFiHfJbfQEmwhFBdYzVSWEo4Ys2msIz6l1BYTv2rKayg8GoKKwmPrG0i DDzK2irCwKOsIREGHmXdJsLAo6w/ijDwyJYmwsAjW5EIA49s60QYeGT3iDDwyN4kwsAj+z+K MPDIlS/CwCPXIyIMPHJdFmHgUcEUhVWkXoV6CqtJXQptFNZQf6EMOgpXUdhA6lK4nMJpAJsK N1A4neJ0UTiDphOjcCb1H6Owlca9l8I2iiOULZviPE1hB4VPUjiX4n+TwoUUfpXCJRT+VwIr hPK/TWEhrw8IrKH+RSyFaV2KaB31RH56imyoFY2iQRRGPSiEusDl0NNgWlEfhdehGBoAkxSx OGilMRQHmNgh8I9QDA58ohDfB1AD9Q/9X6bknysZhzZBSBQNzeEk6JeSB8T8SlE1/AIw3hag MupbDzGi4G6EOL1QhiSNtRHSS4CJo2GwuyGPCOqnfhxaD+4IxYmBXwjSJ9i9kG8UnuKfqEHN X4jNXRW/Bm2hOSfmakpKWoUqASLfnY5AfeIQkgDTA7kU/IX0Py21K7GEOFditAAl10H4n0/3 65RrhCfdENZPy74L/Eip/vf85MCXUCMCuSZpyQn9OXgmOEkx1c1QQg7KSeJzKI/mtw7sZsi7 h/KVlJDEC0OqCVr2PjE13zXKJMhQDPIlZRoE3NFPxQpT2SV4I7RUvXP5RsSWUUJlMUnLEAWf UZEOcVorkmox+Gyh+Enqz6G1lH6EkgO0TkRGy4FXhI4RyoH4PCqHUCdNmZsr3ZV2ScoRp9Tj aF1IaOgqOqZSTz2nuDWf4wIf19Lydos8GqCUTECaIZpunNakR6zDCC1rF9gk3ST1CdG0umma pIUN0HIQDpG2SXD6RJwEtIBOyqvdAAl0iFLadcJTF5W7MC3XgOj2zJOIEVqGKKRN0uqn7SMp ptpFKZOAXw9tZdw8nnZRyoTm6QyhbCmKCFzrpXQK0bjdC3ifoHkLksVR/nRTaIhSLUzp8udl IV+kUISm0TWvRXRS7D8vJ0IL+CT/5lNYoNGAWNKBOT+iRYao1uNETRRGN9NWN0C5NUzTjIjt UKCR4DdI46aoKkjRMNW+w3NtgtA6LuYdn+PQrjmZu7p9CXT469qYULtlVHIEuY7NlV+QS4EO A6I+X0hxQea6KfcF6R6iFBZSGqJ1F/JsoWmRFJPgH5qnV1qoth6gNBHac2SBNAs6cpSWLEpj JGhNo6LU9VE+hsR846K+I7VLUM4PLWg/pLSkxaXKSKSBo1Ip8IPUu4vquugch6OiHu0EE6Wl GxVrPER1rZDSCA3po6nF4CfozC6RN/0QR6D1VsDrpjmMijSar086adxdYlkFChEK9ILZQ3GI pMzXFUTWhT4gKYbEFujQbipfQwu4mEo5RHV6bF5q3ZR+g5QnowswuymF4pS2Kb76aD+fBPwa GD/4gQbk56NaY75E+kSt46f4/ZC6H+wk1QSkXOQpgTpo2kKrE/RjfK6P9M3F/H+b4wjlREon XsllPbSSVmj1K8Ash7ENgZvBl7SeFVR7EP9G8NkENhn9rIQevRF+66hvK9LS77mp5vU7n+xh Uv5983TBoEjl0TnN/Nf1sld4FRG5LMhWSvuNUnlN5UlqPDxvVDBfy6bKI7Sn/nl9WIi2BkGy BsTUQ7QUYdqnChJG5LxNzI20zmFR/3dS7R0Rey4hn0+jTGpMNiL2uKQtRebpwPlaXmhJPaK0 XIteMbFehGLhBZo01WY/mV+3qEnitOUPzWmMTpEz8/vOq3N8ndZqIaWEvuSTUvHJnCNiG+WA ciE6Dr8ySgnRfiJM9dK18ybU3yz2kUKfMvoJXgh8WjgmFDRhiJZokFI2ImqRv4bnnCiLKT3e Oy9foju6KaWF/ljo/ePz5gnFc9jxeXJ7ZVzy5ykVpVojcpVOv5Jeqr9MUPm7MipI6bwrmDHA FUbQQ5TiJP2+ufoI5Zov3f2ilhToL7SqQVE+rmjThTL052p0RT5W07p/knOpvlAY2SXm1Ubo abooVweu4kH8KnpfSZnUL0bHct1iX0LGHcIMJaUH/hrup9IT2mRY7E8X9oup9D7JR4FaQg2S Yl9+rXac4ljoKlr3/E2lvULlT+bQJY7fOsWn+SUKiz1hEvqeVApk/lSPhJmKFy1CQZgRFgBc BTODReAbAB+y85e8NdmMmkTMAISWQkhQhKtgDlFFY1WiCphREENS/9v6uv99z5gK819Fvbn+ sHV0MNwT6gpzT3OtfWFuXWwglgQvbnksPhiLh5KR2AA3GO3ycQ2hZOgvIPlJYtymWHSI+CS4 1QMQr7S6OlACVpmPq49GuY2R3r5kgtsYToTjw+Hu1kh/OMGtD49wG2P9oYGN4d6haCieyqDm qmBODK/ZEo4nSKZlvqpKzrsu0hWPJWI9yYKr8Oej0SAIoQEtm9a1XoX7FNcaD3WH+0PxXVys 58/Wk4uHeyOJZDge7uYiA1wSUDdv4lpCSS6Pa13HNff0+LjQQDcXjibCI32A5ptLCSgU642H BvtG53uFuYZ4aCQy0EviRoAZJdymZGggGh6FMsQjidhAMbcl0pWMxbm1oXh3eCAJZC0va+2L JKAspMihzmiYS6Z42ROJJ5JcaHAwHBLLSNCJS6olVBzquDY20A01GgiPJAZDg+F4MdcDOYz0 Rbr6uEiSGwkluO5wItI7EO72cdzqJNcHPomhzkR49xCUITrKdYa7Yv1hLjYQJukRQozE4tHu BNcfgwIkhrq6wolEz1CUFo3riocpDROQGikIVK03MhCKct1C7RPcCBCL6wc2cEMD3eH41VTI hwJF4uEuyojO0atpAgyYq59QYCjRACQ6QKB4bKi3D/jChW9OhgcSkeEwVDJMuArQYDxGigok Go5FhwkneobiEDtOKrSLUC7FLyjDNTgG2S0LJYDWMZI+0BLKMAByLhYcKNfNdQG5h7qSgDSU IDFbwvHBcHIoRGWlJRoaSEaAzxGBzCCRo1ws2s0lkqPA2q6+UDwEcSG1ZKQrwXUOCfwJdYcG SYrJGNdL6hG+uSscjZIKR0FGOyPRSHIUMh4ajALSSCTZx/XGYiCZUJZY/yiUemukOwyMHEoI ctIZi+1K0AL1h3pDeyID4YQgFfEwtIAkPMQECe2OdQ0JVSTIoWgiRtG6I4nBaGhU8OweDseT EVJXX18yOVjj94+MjPj6RUL6QHT8fcn+qL8/ORDqD/v7Ex1JwjqQxzhpkT4S+FdGHAlHiSTS KOubW1evWL28vnV183queQW3dvXyxvWbGrn6lRsbG9c1rm/VqrQq2nbmGgyB+6gUAOuAYiDM 12iytFYRqDJQi4jfaGyIxOyKDVNVIIgsSQf41E9bWIiLArEGAD3UGw+HCcF8XBtE6wsBs2Kd yRBQGLi3oDBEk41Aw+XCESqBgsgDk3qALFfKBdROxnrDgpASzs7FAyYk4xEQEUgaiim2zlTE HyZShYJWMkeKucgAh7jhUHSIqpRQIhFOzo/t4zZDi4SWMpqqBdRJ1IQghCEuMRjuioCIfLLm HFCRyHgvjRvq7o6QdgzNP077hGLiHae0pbrkqkJFI/0RUdIpHmmXiaSgk4nkUc/YCCjooc5o JNFH8oG0BHL3g0hC+YFVg6OcIKYihRZmROmxuudK5UgrBGWXoNlAo+kKxwfEGsTFclPkRF9s CBprPDwcgQ6FyMAnq0/wgJNhaKdiWyR4c3WEYkEGSWjlV3hMKhYSS91z7WRpkecidIF+6wyn EoJ8QskagrB5Uz10Kt5FwaoCrqp0ETkoEFAqNzeBZ6C0NBgEu6q8iquqrKiuqNaqPqXV/dnG SJ78YvFoO4TJcoxOM8m0gEwSR7EWhh43wRDkLTpwSYWlXv51Cy/u2EfZE+w32LNgTrGn2eeu L6xcX1i5vrByfWEFXV9Yub6wcn1h5frCyvWFlesLK9cXVq4vrFxfWLm+sHJ9YeX6wsr/lwsr C95+XIFDFP9aYW9eFSe84L2IMPK+dppRKuHzniU5klJJk2SlZAnY1QtyIDr401JZT9sM0T1C 7fvwBP4Ki2i7qAesOO3zSJk+PYVrw6vFuT2ZjxCdQJ7IccKVMLZLzVrI24VdADXQVrFSnIuv AriR0oxIQos47xbklsy9N9JekuTlS+1pR5edkOQ1/k5dPse+OdXYWMbPgFvko+6kt6CMBkxm 2cu+wb7JPAezAQd4vDGZaaMhv5pctkwEKhcJwFRhSdkb9Sr2V+i/wDDsr9g3QJZprCmvr+xi vRY8MPsZpMcYOdBR9l/RBBgG8ewvpnLzyo6cZX8A4f/Afg9KSqJ9b1JrLIMEv8u+iEzIwU6z J8WQk1M6YxmqT7D3IYzOgf0amPNgLoKRoBj7JBoDcxDMcTASpAfbAcYPppn4sM+yz0I5j5Ht 8mD7wcTAHAQjQa3sM+C/i9jsU+xNyAVxP0sO54J7L3s/db8Gbha4XwX/HHC/As/EPSI+fwlc Ev6o6P8IPGeC+7DofhH8beA+BM/EfVB8HmaHaLyk6B5lE5M5DkN9DoRzYAJgWIAeAOgBIN0D hMFgY/Y2NkpzOgFuGbj9ggvk2j/pdFMe7Z8yW8uOAkn3A+n3A+X2A+X2IwkE7Uvh7BNwSth9 gLMPcPYBzj6gSoBNQH4JclwCbAMYDgwLdE8A3RP0w28JwE8APvG/HexDYI6SJ3YE6FgApTrA 3jTpdYCQ9U5V82V1Z9geIDXP9kxZs8sOXnlSqogggqsTXT3BDdPQ8JRSQ3zDU1nZggtYu+p1 bBfaC4ZB6WDnggmCaQAjYbsmc/2O0+x61K9AvM4xxoyxY5IxqSTQgE1n2TLUokAgkia2BNUC QoGjoxZX7VQOKseVLPl8XEDJK1uU0hg7xh5kWfLJuTq2me1gpeSElLymnBxUXimrKT+kPqqe UJ9Tv6aWTsjOyV6TnZddlEmFE6Etsp2yQdm47JDsqEx5SHZIzuxUD6rH1axBzakDal7dopY6 5Pho/R1sJzkuAbYBzCCYQ2AkQOMO8OfYG8F0ADc6gBQ30rukbwTTAdgdQPkbgR8dSApPesDT A54efPXgqwdfBDYJaQGzE8ygGCqbC0nFIfgXSQiYfAjVgS85oHAe7IsEArMGnrTwpIUnLWC9 xnwMJTSAzYFpAcNSv/NgQGrAToUFxPCdYGQ0/CLFSYXxJC7zMR/KP1eAJwrw0QJ8qADztXX1 ZbwLLJPJ1OHu8HR4O45JYu6YJ+aNHZM0u5s9zd7mY5I6d52nzlt3TOJ3+z1+r/+YxOF2eBxe xzHJwbXH155d++paScfa2NqxtWwVuYtisihQRl2Xh7gnJ61ZZVX6+iXMcahOB9hHwLwBhkV6 sB1g/GDqwMTASJnj1Pd58H0efJ9HzWA6wEgh1vNExYDtEMOI/xEaRiASziwIZ6Hyz03WlDfX rwW12wHmCBgW0n4Owp+j2AJ0nPpPgH2e+jeL+EepP8FygEnFI0pwO1V326EZbkd1YDrADIKR olfZregNMJA62A4wg2COg5Gw2+G3ld3KPA+/55jn2GJeW5rhQJmZ0H2YjApDvYHRgCxo8VPU fpjaB6hdR+1cXrdG+/4a7ctrtHeu0eYDwHih89TiB6jt5NX12hfqtc312oJ6LaRmRk6kZTKo LSM2fpva66ldzKc7tR86tf/t1P7Bqf2yU7vbqV3iJPHs0Ia1TDq11cTGD1F7DbXzeLVD+x2H dqtDW+XQ1mvxYQy5o2XUzqG2jdj43Rf0DXqkPIPfhX5Xy+DJ2gLHDIOogy9P1taDMztZuxKc S5O1h8H502Tt/Y6X8IeYdm34/cncC476DPweXi0hz/8tun/Aq9Gz4F4EtxfcJ1At9oD7tcna Wwj+4xD/UXj+KnIpCP5XUAuNdwSvpv5fFuM9NlncCbl+abJ4FHJ9FBXTXL84WXwBfO+fLD4A zhcmi6PgHJz0kALeNFlb6Kg34l6UyxDcLuRhSEnWijmugpSj4K4UIjdOFpNYDSSDGbx80l0K Tj4p5UvYjVpodo5JN61kNnLTJOzITQttQx7q6rCeFl6LXNRVTLpvgVRkL3guOD6oPUMqjv6I 9ZOHHb95Ceq3BR5/jVdPPuv4x1OEXJOOV4tnsGfa8SP3Gce3c2fwlknHueIZBQScLZ5h8EnH CSDyBOAyeNpxvLjX8bybhh5zQyiw+khtieNL7u2ORzzwPOm4pfglUgzUDzXeAsFtxUsda2uf dazwzGAI5mshM17lqHHHHdXgvWgGr5561lGaO0OKEoA0np12FEKOeW5alM1Vp5kKJMdDfLE8 Ke+Ub5FvkC+Wl8tL5Jw8W26XpytMCoNCp9AoVAqFQqaQKBgFUqST+2WKyBm9dJmBODIJsSUU NjDEZoRDpQxWMNB2JtLYJqZp0zI8YWpCTa3LJqqKmmbklzdOLCpqmlC07Nh2AuPPtcHTBHP3 DEat20BAidcdtgkT+aIZxv477rMRd98d97W14aaJc12oqZObeH8T1EO1YfuE1L3MgjKH6yx1 pqXG6hUN17B2iva8izQsC27ttGRPPNS0advEM9ltE2UEuJzd1jSxchN3w7ZTzG4m1thwihkk Ttu2U3gPs7txI/HHexra5tCQixkENFRLHII2hVwEDbnwFEVbS9FATF2NDSdcLgHpW3g1QQLx +RZF6hXSyoUsIK0W4gAak4NyaVq5TA5BA3kQEtPPT0yDsJ4mptcgmpidIJ3weACl2ENQTlR5 AOGEp4oGP3sl2O0RitOGPDQfD26j+WB8Bccr4IAUiDiMAnCufSvq//IvvOxvQMZToV92dzWG 3Y073Y1hMDsn7h3us0yMd3Lcie5fkgBugs3b2dnVR9xQeOKX7nDDRLe7gTsR6rpGcBcJDrkb TqCuxtZtJ7r4cMNkiA81ukMNbVNPjC1vWpDXgbm8lo9dI7ExkthyktcTTdcIbiLBT5C8mkhe TSSvJ/gnaF5NG5fhppZtJxRoWdvyGwR3ilGroD3stDnblmUaBpfSxrHYafmM7bQEQbelLmqb 0LiXTWjBkKCS+pJ6EgStkwTpwFsvBlk+s9hpO42fEoMM4G10L0NFyNIYaZj7TyQSSWKGhorA Tg5ZqF8SGq1zU9PEig3bt03UTtQ2TvA7G9roDTVD4t/ybbzhbO2rtUysdqz2YO2R2uO10qGh NvA2nXW96mI6XDHXmOug64jruEtGAm7YNs3XHnH9l4sdAmnCSfhrbKB5DoEL/+QxOZQgfwgy SIARsisaKlq+rd6FumDUi2GEXoLSwLjBlIPZBEaK/g7sH4P5DZj/BiNBt4F9P5jHwUwRH7aE LWm0RBpIjm30M4oWtmwqUFG2aAbcUI/gbtouuI3rBbe2vswC7mRduapeDwNwjE6D/Q9gfgHm 38H8CYyULWPLaOJDgtS2JVCiCEPxyW0ESWIlipKY3OuDCbmTiaIilBBuD8bAAfq9sIVyj3AC JtsJBAwBB5Cob4JEGyJu6u//AD3UkVsNCmVuZHN0cmVhbQ0KZW5kb2JqDQoNCjExIDAgb2Jq DQozMDQ3Mg0KZW5kb2JqDQoNCjEyIDAgb2JqDQo8PCAvVHlwZSAvRm9udERlc2NyaXB0b3IN CiAgIC9Gb250TmFtZSAvQ0FBQUFBK1RpbWVzTmV3Um9tYW5QU01UDQogICAvRmxhZ3MgNA0K ICAgL0ZvbnRCQm94IFsgLTU2OCAtMzA2IDIwMjcgMTAwNiBdDQogICAvSXRhbGljQW5nbGUg MA0KICAgL0FzY2VudCA4OTENCiAgIC9EZXNjZW50IC0yMTYNCiAgIC9DYXBIZWlnaHQgMTAw Ng0KICAgL1N0ZW1WIDgwDQogICAvRm9udEZpbGUyIDEwIDAgUg0KPj4NCmVuZG9iag0KDQox MyAwIG9iag0KPDwgL0xlbmd0aCA1MTQNCiAgIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+DQpz dHJlYW0NCnicXZTLjpswFIb3SLyDl9PFCHxsw4wUIeUykbLoRc30AQg4KVIDyCGLvH3h/z2j qptEH/a5fDaHbHvYHfpuUtmPMDRHP6lz17fB34Z7aLw6+UvXp4kW1XbN9IH4a671mCbZHH98 3CZ/PfTnQa1WaaJU9nPecJvCQz2t2+Hkv+Dh99D60PUX9fRre+Sj430c//ir7yeVp0lVqdaf l5xf6/FbffUqQ/jzoZ13dNPjeQ78Z8v7Y/RK+ECzt2Zo/W2sGx/q/uLTZJXnlVrt91Wa+L79 f7VwjDqdm991WHbreXeeW1stIIBCAwyg5IrligM4gFkDCoDkgJLZdoAXJhDAK2MIawJTb5hg C9hyhdl2AGcAb+xgD9gzNdrROVewTdOnKAD0KbkSfUpA9HkF0Kd4AdCneAPQp0Cjmj6WCehT MgF9LOQ0fRx7o49lB/QRnI6mj4WPpo9DHaGPoAOhj8OBSLyfDYA+DkWFPhZFJfqgjkQfHK/Q p2S26EOgT8Fs9HHoTeL9sGi8H2gLfQxeF6GPwSEKfQy0DX0MejP0MbgfE+8HMYY+BY7X0McR 6GNR1NDHMkH0IdBH0LWhj2Vq+pR4YQ19LA7E0EdYJ94PY+gjLLr4SK4RY3MCjtfG+dlw3j7m ahk9fC0+B7u5hzDPND4qmOVlirvef354xmFEXPz5C0lRCQVlbmRzdHJlYW0NCmVuZG9iag0K DQoxNCAwIG9iag0KPDwgL1R5cGUgL0ZvbnQNCiAgIC9TdWJ0eXBlIC9UcnVlVHlwZQ0KICAg L0Jhc2VGb250IC9DQUFBQUErVGltZXNOZXdSb21hblBTTVQNCiAgIC9GaXJzdENoYXIgMA0K ICAgL0xhc3RDaGFyIDY1DQogICAvV2lkdGhzIFsgNzc3IDcyMiA0NDMgMjc3IDQ0MyAyNzcg MjUwIDg4OQ0KICAgICAzMzMgNTAwIDUwMCAyNTAgNTAwIDU1NiA1MDAgNTAwDQogICAgIDQ0 MyAzMzMgMzg5IDcyMiAyNzcgNTAwIDUwMCA1MDANCiAgICAgNzIyIDUwMCA2NjYgNzIyIDY2 NiAzMzMgNzIyIDYxMA0KICAgICAyNTAgNTU2IDUwMCA2NjYgNjEwIDc3NyAyNzcgNTAwDQog ICAgIDkyMCA1MDAgNTAwIDU2MyA1MDAgNTAwIDUwMCA1MDANCiAgICAgNTAwIDUwMCA1MDAg NTAwIDk0MyAzMzMgNTU2IDUwMA0KICAgICAyNzcgNzIyIDQ0MyA2MTAgMTgwIDMzMyAzMzMg NDQzDQogICAgIDQ0MyA3MjIgXQ0KICAgL0ZvbnREZXNjcmlwdG9yIDEyIDAgUg0KICAgL1Rv VW5pY29kZSAxMyAwIFINCj4+DQplbmRvYmoNCg0KMTUgMCBvYmoNCjw8IC9MZW5ndGggMTYg MCBSDQogICAvRmlsdGVyIC9GbGF0ZURlY29kZQ0KICAgL0xlbmd0aDEgNDIxNTYNCj4+DQpz dHJlYW0NCnic3Lx5gBTV1Td8762u6r2ret+7urt6mZma7p6lZ2WYKZiFYRkYFBGQlmEVAWVm VBDRgIoiowbirphXNO6aMLIOaAJxi0YTMGYx0UdJwmOMyah5gphEpvs7t7oHMeZ5v+/vb3r6 bnXr1l3OPed3zj3VVw5etRyZ0GbEIGXpZYv75zenwwihNxHCtqXrrgwb3+euhfQJhHS6Ff2X XPb2aeEehPQfIcR2X7Jmw4rQIXERQnwVQjNjK5cvXnaHa4OAUG4OtFG/Egquzm/QQv42yMdW Xnbl1efbPD+C/DDkX1uzduniTa+v/AVCF18N+RWXLb66v87mgPoXw/NQ+PLFly0Pjn7/BwjB I1DtW/1rr7jyJRQrIHTHL+n1/sHl/ZNeOpmA/CmErPuhDMOH/pkgydE8YTQsp9XpDUaT2cIL Vpvd4XS5PV6fPxAMieFIVIrFE8my8gq5MpXOVFWj/5/9sd9GIjtD/QaYu5AfocLv4XsSvh/l pxXOsKuRlF9VOMHYYbJixW/pL462oBj6CN2DjqAceoMwqBOn0TykwR7kRQQ3oelYQG7EYgMq QxKajnqRE01D/43NaDeqRh/jLnQ9jqNZ6EEURTORC01C30G78JTCn9H16G18KXoG7n4SKyiJ ZuDuwgdoNuotHIRnIDQB3YsewBYkwhUDlgrvQwtXoK3oMPo1KqAF6D52F7TSi85DlxcOooXo LbwAX1QIoKnocvQtdB96GP0QncS34KMattCH6tASNIi12I7LmBsKT6JG9h39/sLLheNIgPoP Q6t/JbKmq/AJUtBHGlxYCbvBjmrhczl6BB1A72EPrmPakQVl4Vk5dC3azZRBH7vRNhjbYbwR 72YshUdhNA1oKdqETuCr8VESYd9hPytcg2wwviz0dAg9in6MXkJ/gda68BzmsnxbYSbQqw7J qBOetAXdjH4AM/cifF7GPI7gqdDyj/H7+PfM5cyH0PITaBSdRv/AZfhS/C3SRm5ga8auL+xH CRihAm1MRReiNehZnMAKvgjufZCsJ98im5gDzHuaMs2nhcbCS4hDGah7A3oaxvVz9Db6DaxX F+7BvybfYvayNxc2Qn8zaCWMYgt6DB1Cn2MW67EJO3AY1+IGGNlGfBT/ngSJROYxS5jd7G2F DYXbUQRoJYeWw52r0I3oJnQQHUN/QH9Bo9gHd2bgzjbci2/H2/HL5BhzIbOQuUejaO7RPKN5 UXOGtbIv5t/Kn4BZp+1UoR745NAKdA3M9Qh8XkK/wwz24xC0NBFPg5YW4RX4WrwD342/hx/H B/BP8HH8Z/wp/ifxkNvIXeR58go5Ro4zQaaC6WAeYt7URDS/03ypXTwWzB/Jf1owFuRCbWFH 4cHCu4VRdRUCQPFtqB2oazXwwy1oB7obfRfmfB/6GfoV0N0H6uck+gzW4EvMATV5oUdRLOEk roTRXYjn4fV4CN+JH8Wv4t/jk/gMQcREovCpIPVkGllIbiB/JWcYAyMxk5irmXuZXzD/0mxg a+DzDLuf/Yw7qY3r3jyzc+z9PMpfmr8nv7NQB7TIAeXZYc9l0WSguWmwysvQAHwG0Tq0Hubo GpjxB4FydqM96Hn0GnDvY/B5F72n9pd+/gwrcQqNoTwmsJ4s1sGn2PcqWJl2oJY+vBzWtvjZ iG/A2/B98NmJ/w9+GOb3LfwL/Db+AP8Rfw5jQiRFJpEpMKJechHJwWcRWUquJ7eSffD5Ofk1 eZf8gfyLERgrIzJJppO5hLmFGWKGmX3ML5lfaRKaSZpuzWrNTzRvwci72ansInYpeyv7MPs9 9kX2p+xJtsDdyT3CjXAfaQ3aem2vdo52m/Yp7fPa97QFXRLoqQd6X34Om7sTX6TJkB24QEZg 3D8iVzJvkLvwM1/jhEPQg2VoERlhfki+e+0O5g/Ms+QGhDQd6uWJwMXeRC+gN9m3NU72I/QT 4kOfAD+8i1lMfkTuJx5cz0zQ3KR5E7jOBujn98gHREt2Q42/wGosQhdgL/ofzVz0Kcz/MXYI 5rSLvI+fIa+SaUDJ76BHyfPofrQLLccN0LtlaD/6F/oOPsSE8QGgu03oOPorOvFVbzWZscmk jfOQdVwzrNAhPLvwE1Je+Avs+t/jm9C7zL+A9ufimTiDHkd/hFX/Fc5iUZPX+NFbwPlCaCdQ 7Z/QXtiDP9XEYAd9jg4xWbRAcwLWPDP2er6DvZK5EZ8mk2A53SrnnkW5MfDg+4BXUT5qQbuB EoCLqDv6L+hnOAqz+Db3O/QA2o4OM04UZx4jm0mBeU0TRnegE8wMeOp1wJ8COAstXYYuhXGE Cx/mH4UWVqFG1IiX4AWoA650o1DhMuj548CLlMLCwv3sfFZGP8czsBMdAe7lgVm8h9XnR6Hm PtiH76JufCvam1+GjoJc8eA4rgFqGmXXsTvYp9l97I/Yn3HV6GrYtTthFf+AToHUCOOlMBcf oy+A1ifD7qmE/TMJetENMmwNmc/8ELVjH+oHHlgGfHsyzMECWMkroJUb0G2wnx4DGfJz9BkW 8EL0I/QO7Bw37POl8HwdtDMdXQCrfgV6HLjjjXgvlCxDIVQB8/QvbMGN5Ep4HuWz9wCfPQp9 eg99CJyjoParEk/AHbB6S9EXdC/DE+pRL34OdRUOACXMRB3Mm+i/UQyk62TYo4/CfX1AGxYU RE3sHzFBlfmZhUZyKfND7AJpaAGqmgOSfSIegF7wMI4x5MSzUF1+CmoCGbsZ9bKPKYrS1jqx ZUJzU2NDXba2proqk05VyhXlZclEPCZFI2ExFAz4fV6P2+V02G1WgbeYTUaDXqflWA1DMKrs lLr6wsOJvmFNQuruTtG8tBgKFp9T0DcchqKur9cZDvep1cJfr6lAzRX/VlMp1lTO1sRCuAW1 pCrDnVJ4+GcdUngEL5g9D9K3d0jzw8OjarpHTe9Q02ZIRyJwQ7jTs7IjPIz7wp3DXetWDnX2 dUBzzxkN7VL7ckOqEj1nMELSCKlht9T/HHa3YjVB3J3NzxGkM0Onhn1SR+ewV+qgPRhm4p2L lw33zp7X2eGPROanKodx+1JpyTCSJg/zsloFtauPGebah7XqY8KX0tGgW8PPVR4dum1EQEv6 ZNMyadnihfOGmcXz6TOsMjy3Y9h9zUnPV1lo3NY+b+u5V/3MUKfn0jDNDg1tDQ/vmj3v3KsR Gs6fD23AvSTe1TfUBY++DSZx+vlheBq5af68YXwTPDJMR0JHVRzfcqmTlvStCg/rpcnSyqFV fbA0vqFhdN6GyB6fTzlUOIF8neGhOfOkyHCbX5q/uCPwnAMNnbdhr1cJe79+JVX5nGAtTuxz Fr6UMJnPTSw/e01NqdVpavp5Z2cW0x5JU4EghsNLw9CTeRKMqZEGyxvR0NJGqAZ/8zHcNbwM VuTSYX1735DQTMvp/cNsXJDCQ58joABp9K9fL1lcKuHiwueIJimdnCU1uD6eHpbl4YoKSiLa dlhT6GOrmq9LVa4bIQ9J/UIYIpg+1Atzu3h+cwamPxKhC3zriIKWQGZ48+x5xXwYLfHvQUpG nj9M+uiVo+NXnBfQK5vHr5y9vU8CSt6n6jTOYV3i7D8vuOydK5uHsev/cnl58fr086XpsxfM C3cO9ZXmdvqcr+WK1xvPXiulhu3t8xg/KaWIn1GvAlEuPFuZZuaZhjVx+OdUol42otUBVaol ONw1LPR1F8P5hkjk/+NNI4XP6F1q9NVtpW4ON8tfz0/4Wv5r3TMNMdBhTYJMn7NgaMjwtWtd wIGGhrqkcNdQ39DikcLmJVJYkIYOAVpJDvV39o2v6Ejh8K3+4a7b5sMgVuLmFOg9FEvAB3CZ Fk3eR/BLnHaE0Sl2xGpeYpBBq3kJI6+OY18izAt4EtKDsJqLPLJwumWsZaZwqqVnrAW1QVo4 A0F1VcQascYhwEiDzoSZo2cUFn2JwpqjVJsFjKNdCbpbPZ6lDIYEo63NGML60MYQqWrsrO9t fALkJBsP1OP1aH1gffBmtDWwNXh/8Mngx8F/BU39jScaiWgT7aJDiAlxlrfxdt4BADuur+cM 4SCJRn3hoC0aTTcHE9GoMRy0RiWxORiPSplwsC4qjRRuUdpRMBCGQZcF/I5AwI/q6xFKBUOO YDCEcH0wwIggRevrCCaJeDBgs+oQamj0Cz7sazUcM35gJEZf40jhqKIPhLJqhyC3WdE7XdnG kFiWSdNrVnotfSJNjqaPp0na29A4gufsjUxc5xnBlTfJ8sxTuUGZTtxMQR6UT+cgmWvxWm1N GQ9MJf2jIYYCm7tJtzUts9cJL0PsUROyR1b/qqtwLjeYGwA8NiBjHHFKUS2n5ZxWh8tVW+uM 1NXWNNQ31NdZASJZHW4opGWuerUsm0hIUl2EOY77SVllS8zLG10dTZVjLcX02D88Y5+x5gtz +SpLamaZkcBFmVTgnzPfijstEc/yMzeszCbjkI56VjCjX8qaN890LnPXtMXjWMxmjBcxCy6p TcYRoLFZhZNMjnkJEFkY1ynzONt0R86x1rHSudyzwaGNG54ATPm69S3yFvOO+R3n35l/mA2b nDiq2J3ZucwKZm10PbMpeiNzs+Vj80dOfYWu4MI6vV5GOkEX1jG6HBt2IdzlGsFl+/wJu5Yd waG9JqPeRRfCWONtcyneaNZ1KYL8AcjyQIaQ3Gu0ZGmseKx1yJeJtkUXRT+NaqLhch6LgI1q BFoJ6qtxyFaME1VZGismkyV7XMCCN9L4bY8MuyBHFwRW8eRMIXdalgfknlFZhn0x2jZ6CrZG C9Q4iYXXB6qr2jcoIWsoGPe4vW7CBWxiCPkcrhAOWf0h7HZCgGQZy3KFfD3OyWgghwdwxOV2 1dbUN7g5ToomE3VZW22NS5tNJBN0yZ1OJjdW0C/oXNyypDE6Y2TD8dVzx57+9lufSHGnlI1M wJ8fXnN++4Wundfvuv7Ix9j550cevlq01c7fKcGe78l3Me/C6lShiWgGflSZHReMfFtlfKv+ ltSd5fs1h/R7yg+kP4t93mEw1OrruCZuQngmq4t74uX6crFR7BZv091UsVP/ROqJdqPSHZsc MZd7BMQ0a2OO1nJzxtRK58sHE9iq2JpalUQy26qERAicnmxVK6aX99o82dYRRqM4HQ667I5g w70mUzBDGCVTnWVGmIBiglmpvjej7UwE+W51+WxtNFYM0NtwN+7u9jSPFI4rTlgxczNurvEM agkeFLU4o8XAzzilvHKyAjdBwLdlJmN+sjiZTO6OCLRQUAsFzAuiQIQRhlUciWwVNEWymM+K WZJVIgm5kj5PhNJKpaw8W6lI8SxfubZyeyXTW3m8klSu72m8gPLF3ADQwsmWUYiF0RxQRikc yw2caRFOjqrFslwkjpYxuYVu/FFbk5wZlVU6kqGgCb64FNOvtam6CgEt5JBMd7qLwlqVGqKc 0+GqbahRC7RQkgD6qG8oBjSsrdEW69TU12WTCYZSzNlcgnwXT9hbbfesPTKNG0xNbGj9/i9m Day84Ponv3V8QefFN6y64uarTwznpjX3zqpv6U2Fr1oRaVr3vVsf4v2XMQ9eXl1WP2HZneez E8pjwOaUmy64NVJdfWFVeqpXGey8oap616XbXm+9auTutZc/tHdS1Zd/s4p1tedPa/daQy7K GRYW/s68D7RXjVrIBMXJCUKTJiw01SgtHdlb6+7U7qxjVOpZPL3uQBP+lvbx1LMtB1Ovpt6J /Cb1Tt2HKX2dtlM7zT7NPbVunnuF7m60s+4xfAAf0JlqtXhz6/2aB1IPVmtQa2/rUldf66D7 Hudu/FjzEXyi1aBz9bZeOYHp1hGnzUkm0Ke87G76dAKuqdWBjiBXlsmVcbmyvKX2mdrnaxlN 7cTantrram+vfaj2+7U/rP157X/VjtYa+2tx7QSHLqJbrrtKpyG6CboZumt023QP6R7Xvab7 rU5v1Pl1/TrGYdMxHnNClKHF8hWZCd2k5l6Uy2SIRymXs7xH9CzyrPU85NntOeLRfuD5q+eM h/F4FIuQ9RBRS4x8pViZqWyr1FR2lLfzcTFO4h8jlNG36Tfpj+g1YYgI0gt6oh/BzyuC0rq5 lSitfa2k9Ukndvrp6Mp6y9oKfuyXUYPQQBpqWEq+a9nPWFLFKmwv28dqWO9EIOARXH2TytEo Dxs4NSD/OCfkBk6BpGkBCj59Mofa2iitUuoGtjYqjApjp04Ko1Z3U25g0EYDa1ORdIXXdUKL paUF5WQ8qHK+msbmgGQQGA0fDyYicWOiKWEBbohMYX0IR6VmpiGEhIA5hA1RCBo1E0IIuCGw Q6GlKPPk6+EPD8I2GKScEfgjlMUp1QOlx+uoVFPpW90NxVLYAHS3qFKxpshCE0krV6xVW0Om PnNL76oRXOdWyiZV+AKJqRPaLhh88/KbdrotBofZ5w/VrO7oXWDYMCEZ8aZqhu69dNbqZ759 8aqG8qDN4xTlsurOGbXdN3YNTK64N3+3EhHinmnt0+/GTVNm1zekJT+Im5kgARcBnUvob8pl n3M4psfz9Y+HXiGvSO/gj/EfiNagw5WkwnGhuEJ/ibhOv84wGLrX/qz9WccIOew4EDosvRI6 Frci7LQjxhI4DtozQcfxCUw02AHCKmJ3eryez6zY+hdPwqiNdGuMvAVbZFySYTRW/Hprlsd4 Fx6GO3y7458CFfEBMUACNdpSPRofKJOzxynPpBgHxJzWGyvJOMqcekZzVMJRFtdzclBlYaMD QgusuBVWvmkA1t0N606hCRVdgwNxdcJJXbaBrkNxUZLjgstRlGuMIk5+Ze3zJ1ZsfOc7z3Q2 TujRc263WBXNzpnaML163t88127AvlePfGf3HQuaOmYua/N6a3se2vK3CXKacpFpMLsHYXbN KILnKJ6f+HDShG0X6iwJM0Zad0Kr1xmDioaOxwJj1CgJ2HIarPEBHDy6Z3qdGk0pRm1qtLdp YpbGSgzm4qh0XCJIUqQ+iSZh3zwkEYm3iTZiU44bsbE0d2oMTdP4AMyb0Uvx5uZ9ybrGAQBs dP5kOVecv4FBlZZP01kcpYhvlH7VHdKBgYJIXAyFQ4Rz2J12wnEJf8AX8AYYjjfbkjDKYAi7 9LYQ8miDSWw1WZI4xFhC2G5wh1CAdSfplqEQgoKIigrYM+3zlOoy3ISn4qnCBhPbz20ybRL6 vZu57abtwmbva+RV0bBJ22/u5zd5tms3mzfz2z06WMHcwHyQOLjGBQunLS6jzR3l1J3jKqJL K0UhOH/NLy5bfs1v3j7552O1U90WY3c6FUqaHYm4j3npWx8N/eTmR3DZS69jeUrPH3+6Ojdl mjc6cRGOPL0p6KRaASn8nrSxqwGN1CtBhHEbYRyEMIjBmBiZ3cjH4t2kUvNCJ0jXU6MzhdPq pLW1bGXTMuBhIDZAuKQt374ZH2FX/2sdO0RblRHiHKBrtOM2xdYelVAkLISDumjUo9iMbR6V HhoCbcgjeHZ5mHA46Bkhvz0YrQkHK6LRZnrZDvWaFajDN4vNu5uZyeFgM9Q5ENXSFrRnW9AK 2l1aBoeDWtqCZA0H3VGpfLyFcrWFcrF8dzkjhYPlUEe5WKoNB5uiUjRS1o54JKI2qn5VlJd7 PG7S3NSk02l1EposAERpreFrMfwvAllzHers6yRKZ2/nrs7hTk1nuIhVW61IwPDfC4j0ug7Q Mor8e1BVK3qA3E6PZ2DagGm3FENb02AGVDYgFRV1qOE5SUZgW6AWqHT4GxpFSXs4q3FEvlHy 73eQKnd7U2psQmpCzGcxuiBNXqFp3og/oIoHebmyRfJ9pYTQNLktv/AcLePar9L5zXjzV7kz W75K40fp2i8o/Ak/gbPIiKL70FTOyIxgu2IM66tARHpNa7fRGTqTo2QEuw7XfCUsMOpavKSz c/FinFWjzs4ltL0aUI8fZFeiAPpIid1CfkCeZZik6W6GGIwGI0as37bLtc9FXAFC3Nhg1AVG cN8BW8Y97CbuERzdg206FbSas7oRJrbPwmITdOmU4keswBL2PdvbfAAfCeCALwQs+gjG2Bs8 jOfhHYj29GRugKLKnlOgX4D0HZXbF85T7DrFZW7TKW4LBF4eAnMTXbv5IKXh+iHkhgdCDTd9 MFRSY7+gxnsC1ja17knrWaCZszZRlDnOvHORSB2ygUCFBU2qMlTlAThSA/pjLdN75g947Xdv uPiBC+L17+245Om+acvzz+L4mkkV0ZgL78fpHZfe+oD56EjfE1Nv2nYov98md1JeXQvz+H2Y RwNw6/sVT5sZ12LMIA3R6g2szmxCGp3ZbDSO4IWKgLADpt6IsFZnNGMNeh6fQSwyEEEx6TCr M5mpBkh0zzN6aFiL+xRPRtOmIbxG1BCNj0dUk0Bey+d/U6eQ4vJcD8BtugnahFMtp1tKMMXW BAq2BvgIz/PFodtxrbXWKQFVRxoi1lqy5Zprr82P5p2L8RAuMJeeufdY/jiuOkbcsGm7QfqM sEuRG8VQDTYoFzImjd1qctg7TSsTGxLaOG5wz61Zr7mRbPE+YN4Ze9r8dGxEd8BhAvyPsibm fFNvfKnpCtONiI2bzOYaTyyGTLwnXh1FTn/cAzPC2WpwLDbC6BWnucYBVXCMidaYq3lzDNdo OHEEG/bY2DSNOLO/RGb+EQYpQWdV9XsK08vsYhjGl+WjYpRE3+OrKhS9OVtBa1i267GeTpTe W0snSjgtD47Kp0ZzwukBUFyLOgpI9LOayFZLWt5que5lZC2V0kJbk9YitGy1CC+/DCpKTlVU ctj11a4aV0RUFaVeVTwkVSdhgFfQuKiOkMPb137xy9ff23TXwxf96fUX3xp4KR5rrJjWfvGl KdHsCFfNz0xdRvKX7r/q0T++uv2yRzs2PnjJLccObu67U1dz7bQbOusWd0/9bv61gFu6eerF mxpX514EwsgipHkMpIAP1ufYIRQu/GOPqSk8UviHstDYNCuB7/Wcdp8O/zOqqdAFEDYBD49G gZNzUclMTUmSP21D6UCAs9uIltMJERx5v8+12fWQi3ENZRI44S+y4JQZmQQT6TX1mYjpunji BUxQBE3EWuQpmnvGefFpCgFU6UWVPmF0nNEWDQOi5PAVDQOSI5LBog+CqDOWwWF3KINKhoHr r6fzSzMqlwUmC3uyyJPrIuGiGshYi1OakEi5v3Ph2KyL2/3+jhyZhWP5R3cs/lPEes2WLTeS FflbLm+KxuNS4+VMP00df3DLC1EPuW/sAPnOfffeRnnfdNizlwO+KsdJ0LYTxiajwyQU4U40 RuHOn/b6xaxM89VZGm/eI9ap2WCoWMwLaqwkHa6sION7jDtkYvSaAY4GUQiVi0EhJJRz2Oly u1H0ETE0gj/ZF3W/KgZpQpJiYjkklKBkqOGVUEsbrwQa2vhLWEajReVcKGjgc8hwGC9CGrzo 4A7tce0JLaMdwYcVIyrn3SKw4AopWsR6NNpblc2qsT+sxorD5soejeL+KEZRAXbI7ypmFvV4 VZGXgWWcOpUbHRVOqstGkZos03WjRN/SotI7SMyBkoJC18VZfy7YLYlEp5uiJjcsl7paoHsn 6/DrudsmNbZPStfN1BrMQV+5M4y1pkxjXjtR1hkSVcwTv/zOos629mkdGs4VbVt81W8amwS/ l4nF2KZrCNvrCvjYOKxRovB3co9mDHnRfbCnjdtNRA2MJuQdwQcUL9Y4HIzzRoK5sLHKqBgZ 46B+ucVIQAhZlCBrPGDy+bFGg3hWBHFUYXc5NzgcdsXkaLPTGRKC0WzGftR+3M7YvT46O0WT FxD0KaoVUpygwjLIoraxkzlqD1atXi1YlScDCDQDylLHlTB1YuqsEsxFAx55/30+IUxqDs0+ MH+j1XDNt56brBnLP7107MjsTHCp6+jSidF78D+l+S9vKOE6EoMdLaCjSsC22epu67PhYRvm WcQhQWQFThA4Y0zkVDLCMZFVycgUEwVKRi4J7uRYAypu3AqTUYEmKDnvaa5TqTqVVUH83rCk xopkd2eHjXg7CHqjYCTGjaJtl23YxmRsbbbttqO2EzbWVqJ+Gh9IpbPWmUeBggDvD4xTkVyU PEA+Kr6igmZA3cAqQRQxFdDD3nR7XtsacqQnszO+XLe0QROLkah7KfPakgZNvGRBJ59QDyg0 pKQiFFqea/j2h4OgRhcN3zYrIVjn4/2in/hbjQbV2NkltZ0w4CqDYug3HDVoFkFADN5wRFUQ /cHsiQjujxyNkKqIElkU2RwZhgynIkqqtKioUh5HkupQqBVajv9foCFdcfLJfwJ+AAjj/wHb qWiuOFLNv2Ck1XimMurSePUkXFtV21+7o/ZJ928cv3F/6P7Crd9guNJ5bXobc4eD3Wa4j7nP cKfzSeZJAxd2dDqV2t7aDQxrYAwGUqs4TG13aR7UP6r5gf5xB2sC1XC2yfSGLqilyD8alWdX V/++MihzszF+gw1yEUDqUQlzyKQ1I6fgJE6X7HC6GLfW7dprS3uqy8px2mTylBOPjtPy2lla 0gbBdu1u7THtB1qO167VEm1N7W75iEwycps8S14kr5U3ydvlh2SdfKPg6nftACHiUwDXI94s mom5NRL21kzcr+4udZJVVbsH4J9VtatkWlTbCxUbwuhoy7gIzhXFsIyF0b8iYawUjWdL0gVE hjyQgz91J9YAhrNKaVLckGqWOWcJVQUdFtEqJWiKpP3XXykkEqaeFYvt2ebZP/rvmvjEL9cU V5Q1+BOTU5q1ieClfY0PaPJj7zzyf8aar7yrNn9Df014eF9+9vgSL3RK9kA8v/bOzSEbrO80 hFgTrG8YPXsIRWH/eHxFfjxBsGXDUSXaGz0a1VRBguD/0mrPkCD2hINCNKoPB/moJP6Xz3cm FBS1vjIUJgKvQ/0Am0dwhRLV8XoRgH6rV/DgsKfXs8PDeMKCiMNir7hJ3CFqxMO4AnnID/ZG Lp9HOT2QdQuoSXSLniqR9ljL+DyOTyRlYzkqdIuTIn1DxVEpXrKyplh4Zkdi0XJ3e3NqrLlI 60u2tV7oTrAz8t/ZtDZi+/Ljr8hd42qefQ9eS/d2Gij+cZiRShxRerQavaGSiRqnGVmO5QwJ kmASmoQhYUyYZjFdhlnGFYZ1hpsNlmvKd6T3a/YbXtW8avhQ86HhNHvaYLCEg46oFAwHndFo YnZl5QgpU1Ylgwleh3WU7PVBHUBm7WxC3uCC2lA4GItKOq02QUyzzIAREkfiOO4bTuM0wmbe IlqIpTVI1VSCWkOhoDflcFaWxUgZLgPIGnNYgk20II7K4jHi1KXSX0M/QLMtlGJbTqmG7pZR NYNVGhcAaVLxUaR0yH8ofKhWKk3657l/i4unXgMlIlapOPGf1qLEhcYJuDa5YHCWSZLsT61O /rseqrm63HLFZS2PAOm+Xb/5srELf7wxv/jf1c78xm1b/PToqAvWqAHQkEw0hxBX+Gi/sUnP 4RSl28bpdb0pzLIsF+eY35JfM7/yMU6uju0izK/xB35i4y0wK7JoESKCvJs/AovhDzhiIj9C 3lWs0URMjEhRQ0y0SFIgJoZHyO8Up5SMibIkRcJhnrcYvCso6PGP4EV7j1NiL+xX5nrqMIhF mTOIAOUrnE6HEpnU5lAm1vEOHHYccxCH0jkl61Da6xxKUzMk6uohqKqGQE5BkCyDAICcg57K OBTBmhUc2EHtyLyYGk6RTKo/RVJKa11KtYw1Z9UYGlFjaEeNK9PFGFpTY2hLnRMedItUoEg6 FclkQrWZQAc/S+BM4mjiOBA1rd7QnFXjTLUaK/pgLJvwVs683jNuOBugYANIRSjBLJnapGX5 qxxIWKFk4TglD4wWjWrUzKFeZwQLhWqqYhymJ07GtrD6IBALPJUNas4O+jJPNWqeatS8Auoy T4FBxNE2/qD5wEoH6ZlcbpAan0tQr2hfPkeUU9D3DeH+UveWGRdd7RCSrflknVuwyb6505J1 +eQErzXZyjyxYeaU5dObHsnftaZOG4tp496leNcVLZGNeeOljVDAhV1riLAqqxs/VdV0Aq8I oRS+RpHuMz9pPmQ+6NLYbA06FBJCxC2m9DoPoOlXJF4rgiyiKAg/womQuOigTt5iMumMoDwu UrzuDZGEQwtNoaJKXUFtYsRTgcdtpjyehckwUJwvU8TRNNo7YWI2o+JnkyXbmzmeIf2ZXRmS EUErUtRTUnoYxwu4SlCEXuG4oBG86cbrPWcPF6gllBpCTxdzo0XOO3qKrtuo8PnoGfx5TmZU kK2ibFCQyqIVZnssLsUJZ0uUJcuThLPEo/ZEElWYIYhbI0mc5OVkSVWi9s/rqfUz02/ut/dH +yuGM0czXL9lk22de5PUX74xdbN7KHWf+V7XzsrHXc9UHq60bOa3WQm1Xefmq9SSgZF6I23q iD1hNd7jFtto6/NBqFqLoJ6tGz+aLdKDiu+lOrsK/scN3Q3MLzhdqjF/1ZS1XXtXzlm5f2X7 ygl6U9XkrdNWxz3xTDblLps3E4Dfm5c5ImFNpOeuua27bvjhvZ9ek52EfatdwUDF2M3fdogP Pvzc0wn7EHCjqsIJ9lGggjRmlIc9vDdKPIZktELaKN1u+ba0W/qZVJD01MKKGAELRGD6cT/Z 5NrkPmR5reydso/KLKzktAjRcCQhVUcWRLUvRj6XyOOWAxZSq9NSMBkVVXhUEU4HUTRWNG16 3G4MbZpWxfSCtSy8ScSLxIJIxOuqqpSq3qr+ql1VbJWuSHWt5eW9Fbjiusy4WbK4jVVNeKDo O3LOPlUXORop0/OGRCJuiRvjugxKlpklAfTgiD5pyiA+CgEVyi2lQyGqDg8MglAYtFPUyZUw Z0knTiaKYLSIRYuLlFB3qLaKvCDNmuBt+Fbf5Tt7EsHUefhXgaYZVnPbqbeH+25c41PmsjPi keYrx1YeWDdz6Q/eIeUXzeTd8Xg6HT5/bOzTX+7JKK89Re67qgkUR2ojxGvJBtKKGORTTORd RM3WXs33b1fNT8KHKNNDbY2RugjZMHaITMFrj9F9nAAU9FtYQQn28dVK2wW+Qd99TkYneaTp vimBKdHFgaVRrQ2BbiOAZqOpylziX+9fH71FetP/hnQ8o7vf9UvfPz1fer/0sRmdaYT8ap9q wVAT1IgBCaWJGjICfuQXQBNISVGHJEU3SbdKREIVgYh/c/Rk9FSUEQBwHY8yx6M46q4IRKVE PA2S5g+KW0KIi6XSdruNhH8RiURhirU6UBkwq+hNqEKoIBXvu0cYorhMsTgwp5JFxGTqNWPz demJh7BX9RfKqQyaLrUwRuX+uDVaoAQw1qJig7GWkjlyYDDXZKWwNkdNTjnLdcLLnnECCScr HT5n3Jsoi1c6KjI46YNAdqUyuNyTyCCfnxIGlseJA+eKfL+s8A/FaGqSdaamgMfubMVUV59P DX7/yZBSMnhqMWxdYOOYUQGHalEJ+ztyY9NKFpV1p0/uWNN5Le5S/OX1+Qvy0+c33To06zsP k1X5LV+3rXQc3HjPklYxXzffJTJxsorcP/aD2ptW77yLUs8MmOSrAFd0kZmKOIVgm01UDKEG HW9HLahLtMM0dXG4vsEbEx0j5Df7oqmYWAYJxRGdFBNbpCgfE+2SpCRxNCYmR8g7ByVlAm6I iRMgrVRIk2NilyRpo6n6iBZrQi01KzShFQaDRou6uJYJZUmH3dCtAL9WnSouCEWzqHtX93D3 0W5Nt9vts/C8yBO+wucFYOGlwOEh7xHvMS+jeLd7iffPkWhFOgWXUuql1JHUsRSjpLYDcPgz 4hvEBtJQMXmS6ggSjGb7Jp2YRHZNGp50dBKTgeD4JGaSd0r3CDl/b4RKfGovG1cz1ZNGAOOl GFSizuUdHw5QVFnyk2qjKFIYHVeG1MOL4ilGSearJBPLVPuDRjPLVSUCiWo2HcKcNmj0hbDJ nOFqQthvChUdb8bZCj1nRlPnbFBsYlinD+tCSVbUR5IoHNFpscqukKyKllhf94luwplipqxJ 6f61kZ3FztLN1M8yHu1mG8ksbpbpX5yGEuHAYFGgdFO7fFCd6L2Cs40bKfxjLwAQNQZYYhop fHY2BmaklkOs5nljMc+Xrgul+yCm+eeMTegrTISLEqqEUEo2/G/AFE5LRRgtayXjyIX7JnZ5 vefGmQuuifTe2bv4ihQAmGCT3+aQg/K8lNU9KR9IpnhHxl8WydTBtVAJ0Gyc0z5n7oLe+dvu yV+/JquLxdikfzG+47qOSFtb3rDcF6fWDan6PHzHJiXmFKfnDUvbuK8BHQCNwCQldg0yogB6 V3GFqL2HtyIbCohWwSYEOHdMtKmWHnNMtKqWHk9MDDyPPwGWylFfvGx9djeHOQVhU4CzWQ16 SocBKC16TChMuclU1L8rPG5qC3IXbUHukg1Ije1uNVYyqarssBtvd2PkFtzEvVEJ9YaIGOoL 7QoNhzSZUFtoOySOhk6EuKBqBIJ1/5oNSDg1mpOLlsTR0mEbNaGcewhl/8bsJyYtuEhRFix4 8yvz0Bq1QFEuyk8Y8581FJHoUmoowmh24ST5JfCTGrJVWWiscgptGsFc7hCC5RrO4XK8Gn81 8VvhY+GfgrZciFc0CvUVW413S3fHnjJ+Txox7pOMoJubdeVO0xTjdBOnGEGk2WpEtJOIGFO8 jKnf1EOqxt2p2NFOWwYKspm/yx7Ru9Mv+nzUEgZVdviwbwSvViTvTtffbTY2IWttoYTNaCtK CcXmzOKLbCgiRIhqhDIa+WwxF7XQfBp4kmjBFh+fxZnsrOyi7NrspuzuLJe18ToRwKoCNxRT UV952biTH6im4w4MZd5aegJP9QjAmSdh0gdgH+7XhQHd01M5xQ036BRHpE3X4pQgcMUhC10v AX56Xn96kCLU4o2RMAwf+npC0UMLkYvhbtrzvdCAGkMbagzN0HjP2Zbk+SfVFhQvVso8MIMB KwSCHwKLGwKzq1hxPkAi+qBQKMS3hUYKf9hrchRjqEHjPVBdrajWO4RY0ANtUJcNQUU2BLVY x3gV4a+U3kB7PjWKhL+qJ4d8RjFY2zKKnocAxkKr0UrFWvTJ8RR0zThSOL63GMNQQR+Kp0Az gtzbih4S8RQoS/GRwt/2AhqG+ORBQMemAEDlr1jQfDQA6hLF0tRtzS4lisc+bpdm3HuNchuJ qS0dAKmeIepJUdHfkdzFRyfeOKm82RHGidzMb89t7w8ZI66IEE19t6tqYsvK+1OT7759xhS/ 1ebyMD/O//jbKxtifm/5T26dO/Oe3gpjDe7dsmVCRVXXlFWN5y1dszvO8xLwlGR+msYHeyOK MvhKxWvL6HgOaZFV5AStYOXsGQl4RYwqSp8oRmpB5l6RStxF8UupLW6t1QachIsnRCOntQjl uFzx+2zVRd2ouqQb0VipAv23t/p4NamqVqp7q/urNdUlyq8w2xQTrjIppl7TUdNxE2vyVs0c KPoPqqtqKioeppLiYSopHnRaW4q2Qao8qVWri1WrS1Wrz6l6unTcNFrkOFQsfk2jCicqPSFv XE4EE8l4pac8iRMhCCp8qSQuC8TPalKqSARxNyGmtE3JSjTY5NkU2pTYVKm50rHJ2x+8VupP bpJvctwm3eO413N/6P7oztjjjqeiT8cOOF6I2TqcWKUEirni43jrLIeLOOsbSofMRbpIqv4l xZNCLd7truoa+4vK+PAt1bVT517y1LyLvr+qp72mYe6SeinblFCWT1qUf7Q764nHScTdx7xL +eDG7nDmhv/e8u2/bIz6Hr2mac5f/2f+hDuQyh1/z17IrkYxHDyEXIXNe/WGbGCkGHOl2Ez9 uudDwuTT++vtPb6bXbf6tvu3BXSrrattG6wbbNusT3BPmh9z/8T9ht/AuVCi3TUpsNl1k/tm /5bAQc3zIUMmsVJcz60zr/PfbD/MaxssVlssiBaQIOWbDgWSkaesNgu7KshYVjn1eFHGiq2+ ftCgbfHLD+Ea9fgfZh30IdFADD1e76meP+f8e4up0fklA7F6TGttaoK9Xtrpr1dXTT9/w3M1 Oop9XAHObEq44zq9Vk84f8LsMsQRF4DA6LHEkd7HxvG4vgyrTO1ruQF10VVjZ1F5ctjULemk yxOjjkCx8V3KXpis/Oy+Tb+sblv48oObf7Vu8IvHfpvfffANPP/F7Q8t9IYzWnZ1vmLk5TvW 3XvoQP5X9/dvu2r96h/grpEX8cKjrbFMLV2RzsJJZi/oQVHcq6QtHNYbvIYyVMZoHAan3xlg Grmp3EGWMbLY5zcENEEBwqAG+zQMU/QWiDoQitr48UO8EUa/z4Y0WDOCPz1gCzNHGHrYFd2L kQbk0QOKgbeLdmJ/z2QmI+S1vfgtHXqecMASgvhzxafoenW7dIzOFxPe2h4tOqNHvVLRl+CU PNhzkh6Qg1p3is59DjaX6nShOBjK1BlqOGKoHYmhPhoqJ8wXN7UGdijU0JScMTQl5ww1hqo0 3lNkyXDPqMoJlFCUNhqljUZpo1HaaJRy7ij1Qyqx2pIz1PjBvLupyHkHYSUjTESrUT0iNSUb hWqycheZbiwCG6yRbFw+9nEtnn/4/m/n8w88Pr91kpzsXTyxUkyed0V+V/6Uv56dkc9vNT90 40vXfXp9a2WjPDncUSGYrp4z/B61L8yA9XuRXYncKImOKXoHg1e41rmIgZ60O22ObAUTc/7E ybTp2KjHI7L6hPOH5KcI47sRQnr8wP5EQkAs9WXYJ5ij75lG8O/3Il+5Z4S8vp/3iT7iG2EM irHoHu4tG18IajaiB4+nqSdP6WjkpOrTQXUBlcGl/XGDPZYI+IN+wtnilkTcEF2CQ1bfEhTm ISUZE0uw3y4uQREzBGjcdY464F9PPVdzAKEtRFs/7sBIQZpK/5huiuIkCpRNMS/uf3eTVBmc NPm+Ny7/6RXX/XL9u/jO/Ou6unQkle5ul6eWsSsD6e8cuz+kd/zXkZtPXLMN63aexNv+PHb5 kDKUz2fjqx/Fjks7YDdECn9khmA2ZZhLUcu7+ZXyBvkm502unfa7XU/ZHncdthtTgbYAceiA kdyt6BESYBFQxDhJj/uQDkXImyhBfo58SAeUZbZmVf8jAFu6EfLzA4qF9ZkR6JH2fWGMWcNh WAYj9h0IFd2RYKoPWt9G5UI5KafTbuXd2O1L8SEcovMf8lae45skD8BWgHWgTiOnxqxNGa9v tAV52tp8o9Tn/aRwEpYlN0pXQ1W1qZpxjlcR9VagXB9FomdFfwkM4MzgPGXDgtuWxLt/P3T7 wQsuumpj/mf5/LOzmibLkaDw0gXTVh0lT0qRpqtazl9/l/mJJ5+9YvqtdU1PfOuX+d80lbWl J1l0D121YNufSj6i+2E+XQBDpilevZ8Tubi+3K31+J1hZ9xTrtfq8HpdsOhLk4RoL2e2ueng 40iJJbJIkdMQ1ILWoIBsV1Av2kUtPSlb0auG1rRsN2MznSCzt7JIoKeBU4zmgH+7o0osmY3S RqK0kShtZG0UD5QQ5mk10TPaXvLbgsqq2gH11RhuofF+uKvPXbpLZfoqiS/BFeGIGCEcbxEs hItJcYlwRpPBpDfpTBrO6XK4COf1+Dx+D8MRzGANZrgKuVwmXMgaXYISWggCdvcSXMZCELEE YVuYkkuQxwUpGUNKHt8WFaW/69EAHsAOrYWUHHqph2+Rr7DCuIMvZxXGHUWZ/U3RK+6Yu+T/ TKyMyK21x69c97Oq9vybGkPC2yh74z4H3whQv4Ijj78xvGZo9rJcx8D93/uvQ/d/7+Fbnn8P L5twa3XYIz039mn+xJIpVeHGq6jM2IoQs1TlOTe+gCz4+7gO6fBjB6KL6NkrnmRWS7T4n6AJ uvBjiMdfICeUuAhRLLwOsTqtqWSsot5VgsXSy6/ld/OMwGPe67H8CDaUjryKPMSNP1AtWCep AbNkwaSgytakWqmpveHrXpL1Zw8BknGy09XVI47Vxy6cBhgxXDvVhv/Orvzymes6K+Pxsq7N 5MjFmUg4dpJaA3cX/oTPMC+CtutGNYeQFxCk12bPclOR1jTVZuSZqfrKI07s9HreOVY0p/ac KppQR7+hRJ7r1ThXdWVcvLij5N3IvLi46N24eGzwXD/H8/IryB2Ai2yoVynbajnIkwbNfeQu /ZPkMT2LX0SM6UWz3WyiP0dT5aAG3gx1tSHAgBQBC3Pta+9RASz1H1NNe6Weqf5gTo46BIDS Tq0NCWQFhnXHyuqORNWF07O5v+WfwzPZ1emOSQtu351/Nf9OfmR5V13NbPx33IEVTH/Rwgt9 m6/27TwlWq/Zyt7Cj/Cae8j9+sfJU3oN9M4OvWOoN2641CvrLNorB4gZk8lcZT9vG3UgLtoc aSfP6Z2dQtGGeqtAgHbrXLR33pXV7cli5/Cs/HP5FenOSQtuG8bNuAxPUTuXN+dfyP84T39q Bp1fOMHF2DWoFq9RXAaBjTFxS/nV4i3iltiW+O3lt1QYpBKuNP0bzqygOLMdEiu1K43rjetj h5gfaUa4g7GDiYMVhg6pq1yp2Fp+cwV7f+Leiie472mfNL4Sf6NcO83ioZCg34NDrwU9C6Oq fcIBJZvc2PoatdPXngM1o2hB1VNySMSCaHZ7PFG2TmbMdVE9jNRKrK045KsrKsxCts5W5s3W vYDPRxF0OT5R9GDraZ93oHisTgHoc3oVfMqnW3pK00itt7amJgxfJIzjUNUQp24ORNFoJ0Wj NeEKjjcmQNtIxpIMp42bJH0cWSLCZBwWeYGrgJwhaY4jPmyejHTlKjZV3wBR7XJFqayexMsy PQaWEjEAqGQcn571P+FUiz9FPPQIuE5AkZJkaWBvirfnTz1030/nLPzZ7dWX1Ls6qyVy5/QJ gv6G/J/u/XHhpYYuDPB0+ezKV2yBKgeA1+jLbz6T//nDL+V/N+R0YF9vJhGPs2LMPi3/YfOE S59ZPfQMrsGPC7rp5U2UFqyFk+we5glUSS4EDGrFlRQEPQEgCCSGxugyugUkMIJGm3FkXBl3 m6PN1eae5ZjlmuWex86zzQ1dxq4wLDOutK12rXYvC60Q1wnX2K5zXeu+IrQhfHVye/o++R3u I/Sh5ePKf6DPDZ8bT1u+rExwBs7IWTQCa9WElHRvui+tx5jYbFa7HRkEo2gANU/0aJI4KZeJ yaLtS6MT9W57GHpmd4nuRDguJpSRwrq9VoaERwpXKJeKqDIsV1Z2iWGHKIbtSI84kaCLxRBk QxpGz2DmYqvgsFoFYKKIdFltkLYJGoZo9JUhuw0jzmoM47+EvwyTsJwU5bAYoj/GoMGGymTC 4zbouUqGIGOaeg1W1qXVs+DGrBqHI2qseLy+bFqhr2vCmMjuNE673b7kVWEAi6kDSp+1H+j3 eZxCYaQfP3PUb9IX9EyVXtH36hm9N5UeIXP3Rn58wVev3w7IPm/PWM7nGfN5xzyqUTlXfClD NSwXjcvjjq+5AUhZ3U1be9KyDjA2S9/EHbB8M0UTsuzzIAHo/6gaysXoaO5rUTHcKuhadC2q Xwl901NVEEKFE/TdRmHkbPwPxWBtcukcTW74FqHpfBYzEkPFLhC6alGx21V/Qkr2ak41phR3 AWZOFtCX2X82Jr21+J2qWHjbFkMolcEfNIaCW672JRqwM10v5/8VID8YO488vjMTtsTjAZv1 gvyd+DLP9HJdPM543a7pkO3t9iVjmnicq7t2zKtSer6LGQVKz+Cl+1Ubqokai35gd7bSF5Om oWnmbt983wL/vPQq3yr/yvQ2/4j/Nb+lzF7maESNvi7UZb6Eu0R7iem+zJPoSd9vvGZo1Zwx mzIWzqQVOafXJToF+gs/GpF1WOyio8KZLIvJlkymy+d1+Hxek9nsMbvazBdTd3GzBVh9JOPz WswmpHUmMyhGk5hlfbGP5R0hPvZxyOkACM9yPmTsqz5R/Vk1o9ppzI6ybDXQFe/MOIlzBIP2 xpaXh5PZZEeSSb4ekRF7HJCxt6oarqmkpJKR6pIPaEAlIHlQNetSRtUj0BejqBZWPM5yUy9z XVpWKWSrpUQqqHTWdS69fJ1CtDqhSCGUQHIs/l/XmGhLov6sZgfiDP9P/hcdk9L4b9VlNbsu m1DdipvSzR35z5dXd648/5Ip2ZqJGOt0vMdfVp8g+7/bDetOop5Ef/4O7L93QrySAJeb+NzY 9PyZljmL2ptnKO0JozFYcQ9deaHwe3YP6OsRbDiEJJjBZl8se1zCtZp7nUSQcKMbN7kvdT/l HnFrXG630+P10p9WCyIvgGSnJWg26YxBU8QbDkaA5dym1Lu1XFhHhTfRalNuGKDbyXJcmdsL Ka9Tp+U0Jtbr9rqdOpbVRmB9Ych6+pbWwdTUrARLhw7jNHLjGxRb2KRAWZ8Jm7xRaU1k+2Vf 7Xt125c2fNEKX9zm1L29uMHP3cy5l7++mb++RFsFSwv9UkV7kCrachHjYKm0TuPvuGFcXzRu SnXsnmnNFefnU5F8Zk7TLDLkmhd2C2kcwaYqV1iUp7Az4qb2mkNfntLUv9Shj8ddfNBWvXos R+ZfNs0XSpus9EzkfHKM2Q1IyI0y6Eol/E/yTx+JiAGvFlCQ90XPm7GpFRjg0JsAGXFgemoE dykGby0PrP8fmulOmrXjWl5xerPbAemqJ3tzq9Yewu+iIqbMyUDXo6dzEKC2sVOj9Hv2DQBK jPa6cSf+c8gO0Cb7v5Rfdck6jmFZY7iq+cJlU8/f+DhO/3sJOVaT+N48u57TuXNKx/JtV279 9eRvlADdTQbMPxnGnsKyslDJYM4uxgg131LjraZCBgZQbhUAotqAG8gCT+24r5RsuNQVts3P 7PZjf03iBidOWW6shCqwZoaM6vWTETMfZJgMEBNW3w+r8vqznlB5VIE4uqM887sPUjj1a4TK y8edh4/DBP76uAVbfm0228pNJXOOST0qKq/Jhk3HTQSZwqYq02bTDtMuE0dfE+hTk8dNn5m0 Jm84U5Uh6cxPI4fxMsxRsDVQPP+Ue062CCcHTg4Af1FTH4I+eerHsEKqtBqn3p6xFmA19ICJ HncKLS1aGpfCsy9j0DO+htIZn1RXW5fMfuWhTjW38Vcy3M5aJ/7AEZ479tu2Osctt+C3921c P21idiJsP8EdTJIhpnNs/cWeOBOLYX/VDLJtSWdmx9GFjanJ9RF9wMo7DXxV3e71qjZBfeUa VX/GD6iv3Gd7jE2qRM9Mr8uyXYT00l/H0LIs5+ISnIY3oyiqFM1CVKjkbLstRyzEj5E9JlqK /nHJmBiVovqYaFb94yLUP26pVBYTKyUJ++FW5Fmh0UYjEYvFbNCp3nAOO3WGs1MHOLsysc6u tMO3qRkyVdUQJMsgkFMQRGMQhEQIBGv2mB3zdhy2H7MTwY7t1BXOdjSNxfRwmmTS/fRN99Yi VIGm0iUvuHTJ+y1d8n5Ll7zi1AFb7M5sGhVftq0oS551gkviTPJo8jhImJITXLLkBJcsvV2R LDrDRbJJb+orZ7iiN9w5znBALrBrS2+VymePGsff9htto+86fcMPLlL0g4uM+8FZlOLBVtEP zkJ3hIX6wVmommH5dz+4og/7IPUrRjK2/r8fL5/jB9ezuXPedeVlE/OJGq/NJvvLZlTy9gn5 hHpuzM4Y++Ps9mVbd+XvXK06wkV8y/HDV06INHTmjcu8UZ16QryaOaCeEAOFFE4ynwAGCeAt is9GEME2ZMOaqtB893xPb+ig6UTos5A2RBGmuS5Eh5cIiNk21yzXXI7RWnSiVuPGbr9HdCNO 4AiHWZFzCU7RNVLYpqziUSDsDwS6eMHB8wJG6GLeAilLwIKRhhPCMFMCPRCkTm5E8Lt5v8Bb MBsAXUOr5bgAMvq/EDZU8QrfyzN8zvIxptZb9Qg1jHdhQhnJMczgXtqzvS2zsmoP/VIyG1LM fFZQT5ZPhDRCCA/DOEgw9BUAKa74KaoLjXlP5U55Rs8CkLPQVZYhubUo1ray4xj1PyGO8Yga EmTVZUZxhmhnQ7SzRLAG2jANgBJO7HE0qZGTRv/YY+Tb8DhdAEgp4VLtN2EK/kv+laawO4X/ lrF6Kh/YWJdqwjWVjY351wLkVzdKPpB4VlcoviL/MM7cUC8mAYFw9VvGopSbZIDzfwDr3Ewe UaYng/eLxBcQmontiRBuNl9ddaiZsVkcYkJcT+6xPFD9Ov6gRSdoBZ3gFjwaj1unpfQsanu1 n2kZWBnQcBNxIUbfrKMH1XxbrF7i6NRvtnvbHqg/XE/SKZwJhkRzJmgRzc08SJxmXmsGcvEG faI3loqLsfrmBrH+MIdVmvHwbtEjiVFRqstkxbp0yAIEooaS96HMsxmyMHNb5gUQL8F7+Web X2hmFjbf1vwFz1zIb+UfamaCXXwzEFZzqvQ+OcSvKTfbnNk/pvD5qc2pZ1NvpzQpbDOXgbrG YieO40G8BbPbzC+JX4jMHPFG8U7xSVHzPfN75tNm5lZ8P34eM7/FGF9sFh1ms9is2KQ2EFdm PsM3a0QsmsWM2KxpzqTEIG/GOu5syltfF5M4rwfk4q6Woy2khaIs3pptAcFI5+hAiG87BqM+ jCneDu3J7Aj+EIdQiqxHE1AL6dob+R9KnqdGT48B4ipirdxZvUolTXfTwIC81QJ4i76TAPxM 5UgYlB5YJUyVH3eqGDvKijEfUuM9phIPmg90TH9WRUXT0ISaLZ5+wPc/oLZiiHP/2xUe/op2 PFuTfF0m52lpeZ96o12byckeSAIGH0DqtvDVyZ0yWYUuNV4SWpV+Aj8rPhs+JL5h/rPZgOkr 89TMbXe5x9/1yiaT6qswZ33MGhqYIkDUFn+Ewu1uOGeTkMsfmVPtz4x9MTEYnt2Z4XT2SGX+ jo6BNT0Pz5pZRTh/Vscy3qmJXimFp09cNZlMzL/5sOwmsRjrsgda7lveabYDKfKx2PSHBnHF HZNBYcM2rcAL2swt9ZdXOoMs4PwpK+iecsKeWgN7yob/WzHaEONi/sx8yWjMI4WPFL0UzzJh X5AehH60NxSm8WfKDIBCzWQaWclsYq4yDZHbmHvMX9LfbJrOdJk6zBcxc03PMz9ltKADxLNX mf6HkIwuow9bw7a5pt+Y/mT6AnA/0Zj8xGHS0LellCaroU2nt9qs8HiT2bbMfKV5i/ku86Pm feZXzSeBlPXmi4u/B0AwY0Z6k8NILJjpMupHmIRiNhqQTbARmw0bOBstKTN3IXIAYYODurMh B3ZQ2wEoET6j7oBeb7gIM1cZy22y+uNPgqMJKbCf2lABkbX0l6FIfI/5KtXx2aA6PmPstTtG 8PSzOt+A3DNG7QfyqVP0dTdhtIjH5AEKyHpGhdFP6DlUTmj5hDqlnfOOLDDhQZXKzUDNVGWl VA3UDPFhquqrecFZjHm1/MQei/3s+d51L9O2hNeF1xE1qNFNgwcHih5EarsM3KfnVUcwRQ+M mngggFY+ec7dRN9LxPL8SKQOUxdZrWSNOHHxvZ/2M78g5J7Fc7IBibHniXL0aTngYuZIPUux 4D+z7/I71B/kI/c/8F9f5J9fxLd8rvPq1N90feSPdV1f/cJrvku7kl0DdfWl3yyn9IW0kXwn uvBsJYy+/lfDNeGA9nZUztyOZmkQ6oHvQkjPhHgaaUKEa0IyQWgB5GvgWwvfbkJ/T/aPKAv1 ppOnUQLqyUwQlbNz1e80uJbWXIG64DuL/Qmqgjo1ECe4p9EMqFsBdWfDtSSUzYb2OuE7A74R +kz4boX6u+F7Hny98PzzoZ4Vyq0QCxCfD+WT1fYRssM3A/2AfYTqcRUuMBM1z7F93CRujXaV 9g5dve4h/Vr9WoNg+INxnvE3phnmFvMrlnv5d4X3rY9aj9hecsxy/MW1wX2Np90reX/qG/Tn /K8GuMCcwPeCT4mhsD/828iF0ZTUF5sTzydtpRmsQT2IUeePIAHk4iSY5yHrfiijU7NIcw1C pet5NWTU+0JqjlHv0uH/p71rD27jOO97dxCfAh96WTIl4yTSNAWQIAU9KNEVBb5kKxQoWqIc yXEtHYEDeRYIQLgDGTquRSXjPCZNrKnbJlZaW4nT2IkbGzxkEtqyEnbSpkk7HqmZpJbjVFIS Z1LnYTlp7Uych/rb7xYgKMmmHHem/YMEd/e7b7/39+3ugTcAVwpYYTH6jnQOu1iDdEzAC9hy aUrARbiDPyPgYnZW+p2ASxD77wi4lH1QfkPAZQtuVyYEXM5SJf8u4IUsWnqrgN1FXyp9UsAV 7M6qwXxtHKn6qoAlVlm9VcAyc1XvFLDCNlX3C9jFllR/UMAL2MLq4wIuYsuqPyfgYharflbA JWzxogYBl7KuRTcLuEx+YtF9Ai5nW5auzX/z/vqlOdvcyh1L/0rAFcy//CIskVw86hUrVgnY xfwrfAQvAL5sxX4Bu5h3RZjgIuCLVnxMwC5Wv+JBgot5XlY8LWDkYsU/EFwC/MIVLwvYxRpX vEZwKc/v9asFjPzWeAQMOTVbBYz81vQIGDJrJgWM/Na8IGDkt+aXAkZ+V64SMPK7MqcL+V1V I2Dkd9WnBYz8rvm1gJHfWkPAyG/taQEjv94PEFzGY+U9L2DEyvsLgsuBx/sAAbtYwNdE8ELu i++AgGG/b4jgCl75vgcE7GItvkcIriI5pwXM5fyA4MU85o2LBYyYN64geAm3p3GbgGFPY4jg pcAvaXyfgF1sQ6OjaxnRf13AnP7fCF5B9JcEDPomR1cNr4GmWwSMGmi6jeBV3J6m9wkY9jQd JdhD9I8JmNM7+arjNdD0ooBRA00/IdjL4+NfLGDEx+/EsInwXQLm+F4Ol1D8/aaAYb+f9JaQ X/6nBMzxpzi80KH/mYA5/jcEU16abxIw5Dc3swE2zpJMZ1GmsTBGlX0ebYANExxiCRZHswSV yrpwlQLMew14gyhUYGLg9wPqJrz2DiXNWKayPZiJsXSexgSOfze4o28d24JXC2sSUICwHeCI YdwNniHYYBHXbsgz0fh31ussAh0GGyGcyvowjhFNAjgN8jtJb+QK29vm4FPznG3sdtJm5r3j 1rWyTYAaINeADynMmGhRyF97zZLfTO4Mv8M9w9uPODYV+DQwh64nKXs8NxHMcVyKHQKOW/rH 51UFVkdGDGi1yAeeBxXXnMYSUvfCVhUWc36V1ZO+EPpd0B2l/HILOZ8OqSbZPiyk+a9ik1NL CejlNiVBO/6mVDrVMKcbI6uG8noNsUKaqCYtsiEGzLiIQ4q84lIbgbmd6C3Cq2wnxY9HMk4+ 8Vpdj6zxOBqUgVRBlDU2SJLVvHUz65PbkaLoqeQLn9Uui2NOeu46l63CjDt53En2RkSO4hRJ EzI1kpsiT6LChzGyNYyey7UIo5GsCMnkKy1OdvAM8TXKaYYFjYkVPEi5OgzIiUOMYjeIqzDV nU52xcUYLaiIMbIhRt+Nr4IyISLApYYpMiZeUVzFCqKm0vrSC+rQFLblIuJkbYjipBFvZFbu TdLtVJZK+YkQlKao6RSXt66Fm0SEDJIRLlgRg0T91nXirIAr81cYYSdGcWFpPI/jO0uadj9V 7B46ey+tujhla5RkGmIdOjFycEnizUXVqaJR2jlG82uCxzoldKfyGTqUr7nL15cTh2tbY453 nVQ5Tl0n8vY7denEIS729dkRd2ouQtl3qjtNEXYkpcl3R2c/yeISLeC1gn2lH75qJN8Q69mY Vc3OHjlOlsWIwyRPY6LqhimPmtCbEvsd986kzKdnrR9uLV9xORt5NahUlU4+uN9h2uti+QzH xD46iBYj68aFx2naax1JYzQzTNISeDl7ZljkZgQ8TqzfDboIaRgXMSrcTwaJ95Cw1YkQj8AQ 2j1EwyulcK/gte6cAZaYSczaQyNUX+lZWcxJ1mhPTxRIi1D8kpST8VmUEYpQimKby6ufznsL 9G24j2hGDPjLT7tGYUX6xa7TTPQjkN6M3qKdgNvFr0x2gGQ7q87ZH1P5M9Kf5/zf1ThGmcjt iTNa+rBKBrDqt6N14R6Hw7uA5atnO+0eHN8DzB70/C7oFpzoPXiFCDvA3PQtbmUF586VJ0wO P1ywFyRFlMfzO/O1nbIzuTJElp3ayu1+41SvOZ3c49GCu4LCXTZnj7OeRgrOMI1Wg1NZcSFd Iyt0OlOdCuN1vl9o46tzVOz/g7R7G+LkcvS8WWRy92lj4sTla8ko2AMLd3lnJUVFtVwtXgnh F4+YPmsnza3ZK/VFxE6SopWfzu8YgyIzhWfn5Rq/S17NjpRzllxZFVdqNsQaVRE5je7HZ+5S NDondNqXrq6bR3+vOCOdM2X8ilw4eZp9T+jshBpZlKTIGmIXuZacq6IWc/v4UIFevndEKNLO eeyc/qmC9wuNeepUQd3O3Je8daRitGsYl+3pM/Jy56VJ9TdzV5Db82YoE6B17qDTFHEufzjv j2NXYXWPiF3Sib+zqpKiPmZ209k19FYezdTHDvL9yszlzkLnzs4s8MY5acKU1fhlOUhdFu8Z ydy/BN3LRcRZwu87nHcouX3gWrKfk+esSV2cp7PPxZy8K/PoRMvxwBJn+dXWcS5j2mWxjr4t a2eifKWGsLh/GxRXhRbp4iS0cPbkJPD3Tx3MeafSwDazDXhvuBZwK94ZbAa2BZgWvPhfiPay XkHZgtl1mNkg4Fa8h2glrk1sI95R8Malv72z7o8/GXNzzZdFL38eDown9agW1tXPqwPDuhpK xBMWUGpXIpVMpDTLSMTVZCzsV7s1S5uDqJkLU/ckYmmOMdUdcfCt27KlpQldwK92xGLqbmNo 2DLV3bqpp0b1yIAxoptqnz6m7k6MaPHORCySk9522ZzKJ9tu11MmVxfwt25SG0JGOJUwE1Fr 7dWIC2lpHtM027+niTQNXMb1uDqQ0iL6iJY6pCaib+mrmtKHDNPSU3pENeKqBdK9e9R+zVLr 1YGQuisa9ataPKLqMVMfGwaZPy8JUUoMpbTk8HghSle7U9qYER/ivAYS0qTusbR4TB+HDSnD TMQb1duNsJVIqTu1VESPWwjt+sDAsGHCFm6yNhjTVSuXz6iRMi1VSyZ1TdjIyfnI3XIch487 E/EIPIrrY2ZSS+qpRjUKDWPDRnhYNSx1TDPViG4aQ3E94lfVHZY6DIyZHjT1w2nYEBtXB/Vw YkRXE3Gdy+OBGEukYhFTHUnAADMdDuumGU3HyDQ1nNIphiakcUPg2pAR12JqxPHeVMcQLHUE aVDT8YieujwKN8EgI6WHKRGD45fHBAnI++cYDIviEBrnUCqRHhpGXlT9vZYeN41RHU7qPKuA kqkENxUhGk3ERnkmoukUuFPcoUM8crl8wYarZAzqOjUTsU5w+YglbIij1oXhiFxEDSPc6bAF orTJOfv1VFK30hrVSn9Mi1sG8mw4YUZFjquoU9W0xpHa8LCW0sALaZYRNtXBtJMfLaIluUQr oQ5xP/T3hvVYjDscQ40OGjHDGofidDIGojHDGlaHEglUJmxJjIzD6ncbER2JTJtOnQwmEodM MmhEG9LuMeK66VRFSscKsHCRcCo0kginHRc5sRYzE0QWMcxkTBt3kJFRPWUZ3Ff/sGUl25qb x8bG/CMikH6UTvOwNRJrHrH4fwluHjEPWDx1qMcUX5F+PnmNjGN6jFcisfTtGtixfUdXx8CO XX3qru3qzh1dPX17etSOW3b39IR6+gbcZe4yWjv5BcPhYaoCpA4RQzFfZcmSVwZcRrR4+Y0n 0pwznBilrcApWS4HeRqhFaapMQQrDnJtKKXrPGB+dT/YhjUkKzFoaYgwsjfLGL6njWHhqrpB FeiUPJIURVhm7EK0rcSQ7hQpz2yeD0mwUgZKBKJhplidOcbnzJxRWCX5UOSZAWvqqBZL05ai maZuFXL71b1YkVgp4zkv4JPYCVGEmmom9bCBErnScxVR5DU+RLxaJGLwdYzln6JzoZGjUxRb 2ksuMypmjBii0omOr0vTcvZkXnmETIxhg04PxgxzmOuBLCfcIyhJ2I9UJcdVp0xFhGYronjs iM44x1chNjuT1GDRhPVUXHiQEnYTsTmcSGOxpvRRAwcKr4Er3ed0yKSOdSrWIqfL+wizoMDC Kp/JMXdME1ZHry6WTM4zhLG/Deo5QdCjWW2cYO+eDhwqDZs3tK5VW9dtbmrZ0NJSWrq3F8iW des2bEDfur5Vbd20ccvGLe6yN1l1b7kY+VWzMI/WIf1R3LlN4zdbc/1pfja1xdKSG/iX5+Sb oYyyuR9KqIJqO+mx5qQWdMqHlVPKPypfQz85F89ltPMPiOYfEM0/IJp/QDT/gGj+AdH8A6L5 B0TzD4jmHxDNPyCaf0A0/4Bo/gHR/AOi+QdE/48fEOX/JmOwt/MXHId6J0anghOESc/JfyXH LbS7mHNy5ui2s5dh9SH2OmS8DNzcf92ZTZ+T4+y1fEe5Vs0zHLcTNBefQ3Ur7Yqj9DepuXlm U/eLO4E03aE6O+xcEq7GU5i1uf2dRe3yuNpdN7u6XJtcm11B11ZXr2vLXBLehOda/9o3Q7n9 mmLmUPXyyEnrgJmLfoayV9xjH7qGqBTQStXsh0otZubgydPtpHcNxjWsDofunazJd5Drd6T3 7a7j/Gd52KXV7OvsKj9PX5p2KdmenkBwCqPPT6PdsDZAE/b1KwOnXIr8EN4Ve4CQ7GU1NMPs zk4BbNrsAFlvU+B8R5mLsYtosou5JOzpxJVt8Ade/RquJeUPrFKSOFb5XbZqCbQpv89WLg4E O6qU37B+NJlllEk2jSazhPIaO4Img/wpu2kdV6Q8lS2rCFSB/iJT0SYU/kmaE+glug6icfqL 2cXLuPif2JXVxHfebtngANmq5YH+jiXK92HPt5Rvs1rmUX6I8QaM/4xxFcZvKN/EGcLt/Gy2 siowAX2PgvxRZRwHlEf5O+UeFsD4uHIfqyGyF+wKR88LdoM30FGmPKbcSySmchgnlUeJKYfs gEc9qXwWlgaVn2dLy7l9P7erlgZOKS8rh9gSUL0Equs8laeUOGtG455MZUvdgWMdC5UpuDmF sHhgo8QeoT6ofNuGIOj7vDLBlmHutHKULcX4BeX99lLP9Enl10T2OpcCfZ+xS9bzIeuuCEx3 lCqfwWxG+RUi/ivS9t/Z+s0B1lGv/DlrQZMR1B8B+hH/0IzyCqBXkKZXkJpXkJpXYMUrrAhV 9gvM/AI0zco5llReZMfQHgHsgshxGxF8moC6hsDTyp8p9yISVScROwnY+7KlFdyye+1Fi4ns 3uzCisC2U8rzbBeaDOPPZq9bHkicVD5OrhzLLq/hDN+xSxcidO9zcgHGe3gOTikTyvspEkcp Apmv4lJilcoHiPlSdmF14AiyP4DLBPoH0M6gXURzgWwAPgywA2gKyPuzFZWBypPKHcS8w65Y 7zml3ArXb6Vo3WovXUM235IFcNtJpRdFskvpsyMeGHibDWY+25fd3BZoOan0kcN9tqfWQduL VxCw3S51iqcrW1bN1XUToc8uqSC0T6w7xZtdcl3Ag2JsI5fW8w+UKbj3QWtBmwCGRzyQrVqE Eo8oATI7wA6inUDLoLmQyADIA0hkgF0gTKWyCT5tYpfQFCRwE3sVTQZ+HduG9gDa19AuoC0g 7EE0GfgWaDiI/hiaDInN/Pt90AfRDqJNoJ1Am0Z7Fa2YnVaaoId/yqgF/QRaBu28wj9rlFAa YUcj/ySWorLflzDmYUfkh4Jt0hF2RDoiH1GOuI4sOFJ1pLokuPHGxkDwbt75edeArvVgabJ0 Iv/tXVWlaqnMv3uiuG09/1TuoqK29d8L/TT0RkhZ1Hqs6FixfLpjIQ6Q82gX0RR2WqrCVRWu qoIfUk63n2+/2K6cDp0PXQwpp8+dP3fxnHK66XzTxSYlGKppC7QekBLSEekByeWRmqVt0i7J dUBJKEeUBxSXR2lWtqEWXAfLk+UT5Qr/15n95UpVuVouHys/UZ4pny4/U74gUzRddKboQtGr RQv6iw4WJYsmio4VnSgq4l+PuK04WOR6taNLfhFBPYE+gyazCfTHCKqimWn0Z+j6GF0fRJ+k 6yD6foJq0bdwCK0Wsr4Hugn0x9A4Hb+uRd/Cr9FqsYW/AFwS/TE0WX4huHJNS12wTq6qU+tk Vie9WiedqbtQJ2fqpuvk6Y42+SxZeRZWniUrz4LzLOk+C7mA0Gph7fNE9zzonie650HHoavh DqJPEhRE309QLfoWDsnP27WtlR0r5E9B4gH0j6CdR1NYM/ptaAm6qkTvQZPlT6EPysezNzUG Jqbk43Y9NkMMa5zhBmdYSUN2xfWBAx2V8nGIPQ6xx0nQcQg6DtG4ujQtP2R3c9qH7K3O0Lb+ fMcWHJfcnIfYU2gy24X+EYKa0W8j6CmiqcxfZ9BfICiJ/kSe7wBBnM6DluN3ycfxeghQpXwP sPcEy2W2bBmO80XVJYum5GdsY5FnSv6S3VCFIesMNh86FssKcuCm/3Dhlp6k/hHq/5L6d1Nf GSyvdf+m1v1Pte7Hat0dZfK7WB3Qr1L/MvV3Byvq3P9Z5/5GnfvROvdn6twnpR+xNZhYHbx+ jfvHa9z/scb9lTXuL6xxP7jGfeca921r3DvXcFENuD9xy6t4L91F/crgdar7d6r7B6r7X1X3 N1X3p1X3ftXdpoJc+hUOT7f0N9R/gvqNX9ng9mxwr9rgfkZGbKT32JWs9KQsS+9hbqXM9rZ7 ppRSGuTVduhGDCvtUAeGGju0G8P1diiFYbEdetDTUSpXSpO4M/HIFdJkCR8X2t6jmC53hhLb exeGBbZ3i2dK+oPtrcXwWzu6CsMbdvQGDK/b0Q0YXuPDs9J/sagMMdIv7ejDEC/9lDVwsdJP WL38BMYpO7QN1F9xtEtfYu3SjUDbLMitkP7e9sI46XHb24DhMdtbh+FzzvCo7fVg+LQd9WN4 2I4+iOFv7ehLGI7bDTEu7yHWQHI+yeppNO1QDaYP2yEuIWmHmjEk7NBGDIfs9ucwGHb7S5x1 SJqUUN1SlHnJUs2Oevn/eBOO/ClroOk72UaSfIsd4iHZzoV0uKUe4Ui31MVv8KROaZKkBG1v C8jabW89hq1O5P7EjvowbLYbEGOp1W54GJHbJBSs5fl5VqqDGVxQre19AkQeO7oWww12tAdD DeeEUYuF1kWsnYyqtr2cqsr2qp6vSuUsShLLWL10/Mue30Pub9unpNttzxvBqRLJ9vy6AcOX PT8PDXp+FprC7a3np1jGT3zZcx6k59oBBss93/e+5HkxusbzL15QBGs83/L6PV+vH/dMNZz0 ZEM3eCZhWCY66HkqShKerAeb7Xm8YUqWwH0iutPzSa/P84n6KW7DX4D4Q1wHBN3vHfe8v/6o J41SsEIf8ZjeVZ5kw12euxu4ous8hne3ZxiODIFHjw55NO+DnoMbyeK7vM959mwkH3qj5NGO dpq4Nbrbsx0WYGIbn4AFN6MuA2D1bzzJY8SapK7sc569rc/KOI2lCbRU0F98qvi+4sHigeJO nDs3Fd9YvLr4huIlJYtKqkoqShaWlJWUlBSVuErkElbC5CX8ixp9/DP2S4qq+FDk4r2L4CqZ 0T+No68bkKUSmb2LZRYrvXLvns5Mq693qvjS7sxmX2+muP89+yYl6eP7pd7MdJj1DqqZ1/fU Tkllt92RWVDbKWUW9bLegc7lIM7IH56S2MC+KekS57i/JrOIf9u1JDXe/7EaPm6//2P797Nl o9uWb1vUXr1le/dVuoOi7+ku+Kqr5T7frKtVmb/u3bMv84VV+zMBDlxatb83s3aPeue+p+WY fHdP99PyIT7s3/e0NCzHenZzvDTcvR9kNxMZa5cPgYyF+AAy+U7WzsmAv7OATJoEunuyvd0h 2iVNciIsml1EdIdD1FVIpHxU6iKiLuWjRPSwo9ALO6AwyAeQLYgxLyn0LogR2XJONllfD0nR ek4yGagHwWR9gKZvm5lucKa/6Ex/kU9PSdLM/MZ6x9oGVk8a6uUG0Pj+D3/0zj+CScpuHY3v 69Frew7W9uhoBzMfHR1enpkYVNXJ+CifUDNK/cHB8DAfNT0zWqt3Z+K13erk1n1Xmd7Hp7fW dk+yfT0D+yb3BfVue2twa0+t1r0/23d08+FZuj6S17X56FWEHeXCNnNdfYevMn2YT/dxXYe5 rsNcV1+wj3T17u6Uevv3TZawTv7/wmjMyuVlWC0Ha1bv71xWlWynpXPz6uX31TzjYtLjrNy3 P7OwtjPjRuNTTR1NHXwKS5pPVQBdKaaW33fz6ppnpMfFVBXQ1bWdzFreY3Tj18SPZaXxgxib phPr5c6E5euheRBYgCz6ASVg3kzCinmLpWd+fD6Hlpm+rn2ToVDPcqO7hn/NFb//9u03mc/n KPT5GHTCa7rhX0Y3/OVFy9Z/N/Tj0GshZZru9M+gXaA7/Wnc5Z9Bu4A7/RuU6fYz7RfalenQ mdAF0J47c+7COWW66UzThSalVVhg0n/8g4Uzr7TPTJv0Xx/IW/Ibl5bP9HGXczHAlY9jeVTw 4+CJzwcpvjyvbwYwnck0sThYM1+/2Fv/B2FXd20NCmVuZHN0cmVhbQ0KZW5kb2JqDQoNCjE2 IDAgb2JqDQoyNDIxNA0KZW5kb2JqDQoNCjE3IDAgb2JqDQo8PCAvVHlwZSAvRm9udERlc2Ny aXB0b3INCiAgIC9Gb250TmFtZSAvQkFBQUFBK1RpbWVzTmV3Um9tYW5QUy1Cb2xkTVQNCiAg IC9GbGFncyA0DQogICAvRm9udEJCb3ggWyAtNTU4IC0zMDYgMjAzMiAxMDI1IF0NCiAgIC9J dGFsaWNBbmdsZSAwDQogICAvQXNjZW50IDg5MQ0KICAgL0Rlc2NlbnQgLTIxNg0KICAgL0Nh cEhlaWdodCAxMDI1DQogICAvU3RlbVYgODANCiAgIC9Gb250RmlsZTIgMTUgMCBSDQo+Pg0K ZW5kb2JqDQoNCjE4IDAgb2JqDQo8PCAvTGVuZ3RoIDQ0Ng0KICAgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4NCnN0cmVhbQ0KeJxdk8tuozAUhvdIvIOXnUUEtsE0UoSU5iJlMTPVpH0AAicp 0sQghyzy9gP/T6tqNok+nwvn8yXZHLYH3w4qeQ1dfZRBnVvfBLl191CLOsml9XGkjWraevhE /NXXqo+jZKw/Pm6DXA/+3KnVKo6USv6MCbchPNTTuulO8gOLv0MjofUX9fS+OXLpeO/7v3IV P6g0jspSNXKeev6s+l/VVVSC8sWhGTPa4bEYC7+lvD16UYYLmrPVXSO3vqolVP4icbRK01Kt 9vsyjsQ3/0ezJatO5/qjClO2HrPTNNuWExiAywGWUAAyggbkBAtwhD2gABjCM1s/A5aM7ABr gDWAF0IG2BBYs2VNCtgBcsIeUKCBTglooOnjNgD6ZEsAfTLIafrkrKFP5gCzDwbV9HFMo0/O BrMP9k3TJ+c49HGM0MdxAvoU2DdNnwI+mj4ZIoY+Ft8x9LGYzdDHMo0+Fg0MfSzOx9DHrgH0 MdhRM58PxjHz+eCADX0KAn0KptEn5wSTj0k15Ax9HCP0cfzOfD6I2Pl8ELH0Kda8n5/3cLqq eF1fD6G+hzC+ATxC3P3p1rdevh5q3/Wom3/+ATPp4ndlbmRzdHJlYW0NCmVuZG9iag0KDQox OSAwIG9iag0KPDwgL1R5cGUgL0ZvbnQNCiAgIC9TdWJ0eXBlIC9UcnVlVHlwZQ0KICAgL0Jh c2VGb250IC9CQUFBQUErVGltZXNOZXdSb21hblBTLUJvbGRNVA0KICAgL0ZpcnN0Q2hhciAw DQogICAvTGFzdENoYXIgNDkNCiAgIC9XaWR0aHMgWyA3NzcgOTQzIDQ0MyA1MDAgNTAwIDQ0 MyA1MDAgMjc3DQogICAgIDc3NyAyNTAgNTAwIDUwMCA1MDAgMjUwIDYxMCA0NDMNCiAgICAg MzMzIDI3NyAzODkgNjY2IDY2NiA2MTAgNTU2IDU1Ng0KICAgICA3MjIgMzMzIDcyMiA4MzMg Mjc3IDM4OSA1NTYgNzIyDQogICAgIDUwMCA1MDAgNTAwIDUwMCA1MDAgMzMzIDMzMyAzMzMN CiAgICAgNzc3IDcyMiA1MDAgNzIyIDUwMCAzMzMgNTU2IDUwMA0KICAgICA1MDAgNDQzIF0N CiAgIC9Gb250RGVzY3JpcHRvciAxNyAwIFINCiAgIC9Ub1VuaWNvZGUgMTggMCBSDQo+Pg0K ZW5kb2JqDQoNCjIwIDAgb2JqDQo8PCAvRjEgMTkgMCBSDQogICAvRjIgMTQgMCBSDQogICA+ Pg0KZW5kb2JqDQoNCjIxIDAgb2JqDQo8PCAvSW01IDUgMCBSDQogICA+Pg0KZW5kb2JqDQoN CjIyIDAgb2JqDQo8PA0KICAgL0ZvbnQgMjAgMCBSDQogICAvWE9iamVjdCAyMSAwIFINCiAg IC9Qcm9jU2V0IFsgL1BERiAvSW1hZ2VDIC9JbWFnZUkgXQ0KPj4NCmVuZG9iag0KDQo3IDAg b2JqDQo8PCAvVHlwZSAvUGFnZXMNCiAgIC9SZXNvdXJjZXMgMjIgMCBSDQogICAvTWVkaWFC b3ggWyAwIDAgNTk1IDg0MiBdDQogICAvS2lkcyBbIDggMCBSDQogICAgICAgICAgIDkgMCBS DQogICAgICAgICAgIF0NCiAgIC9Db3VudCAyDQo+Pg0KZW5kb2JqDQoNCjIzIDAgb2JqDQo8 PCAvVHlwZSAvQ2F0YWxvZw0KICAgL1BhZ2VzIDcgMCBSDQo+Pg0KZW5kb2JqDQoNCjI0IDAg b2JqDQo8PCAvUHJvZHVjZXIgPEZFRkYwMDRGMDA3MDAwNjUwMDZFMDA0RjAwNjYwMDY2MDA2 OTAwNjMwMDY1MDAyRTAwNkYwMDcyMDA2NzAwMjAwMDMxMDAyRTAwMzEwMDJFMDAzMD4NCi9D cmVhdGlvbkRhdGUgKEQ6MjAwNDA0MTMxMDA0MzErMDUnMzAnKQ0KPj4NCmVuZG9iag0KDQp4 cmVmDQowIDI1DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMTcgMDAwMDAgbg0KMDAw MDAwNDExNiAwMDAwMCBuDQowMDAwMDA0MTQzIDAwMDAwIG4NCjAwMDAwMDQ0OTUgMDAwMDAg bg0KMDAwMDAwNDUyMSAwMDAwMCBuDQowMDAwMDE0NTg3IDAwMDAwIG4NCjAwMDAwNzI1NzIg MDAwMDAgbg0KMDAwMDAxNDYxMiAwMDAwMCBuDQowMDAwMDE0NzE5IDAwMDAwIG4NCjAwMDAw MTQ4MjYgMDAwMDAgbg0KMDAwMDA0NTQwNiAwMDAwMCBuDQowMDAwMDQ1NDMzIDAwMDAwIG4N CjAwMDAwNDU2ODMgMDAwMDAgbg0KMDAwMDA0NjI4MCAwMDAwMCBuDQowMDAwMDQ2Nzk0IDAw MDAwIG4NCjAwMDAwNzExMTYgMDAwMDAgbg0KMDAwMDA3MTE0MyAwMDAwMCBuDQowMDAwMDcx Mzk4IDAwMDAwIG4NCjAwMDAwNzE5MjcgMDAwMDAgbg0KMDAwMDA3MjM3MCAwMDAwMCBuDQow MDAwMDcyNDI3IDAwMDAwIG4NCjAwMDAwNzI0NjkgMDAwMDAgbg0KMDAwMDA3MjcyNyAwMDAw MCBuDQowMDAwMDcyNzg3IDAwMDAwIG4NCnRyYWlsZXINCjw8IC9TaXplIDI1DQogICAvUm9v dCAyMyAwIFINCiAgIC9JbmZvIDI0IDAgUg0KPj4NCnN0YXJ0eHJlZg0KNzI5NTMNCiUlRU9G DQo= --------------020907060404030208020108-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Tue Apr 13 08:33:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08691 for ; Tue, 13 Apr 2004 08:33:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDN6D-00068V-0G for megaco-archive@odin.ietf.org; Tue, 13 Apr 2004 08:33:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DCX8wR023583 for megaco-archive@odin.ietf.org; Tue, 13 Apr 2004 08:33:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDN6C-00068I-P9 for megaco-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 08:33:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08632 for ; Tue, 13 Apr 2004 08:33:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDN6B-0005bm-00 for megaco-web-archive@ietf.org; Tue, 13 Apr 2004 08:33:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDN4k-0005Vt-00 for megaco-web-archive@ietf.org; Tue, 13 Apr 2004 08:31:39 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDN3L-0005Ob-00 for megaco-web-archive@ietf.org; Tue, 13 Apr 2004 08:30:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDN3C-0005gI-Ri; Tue, 13 Apr 2004 08:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDFvU-0002Hx-Rz for megaco@optimus.ietf.org; Tue, 13 Apr 2004 00:53:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06462 for ; Tue, 13 Apr 2004 00:53:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDFvR-0002Bu-00 for megaco@ietf.org; Tue, 13 Apr 2004 00:53:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDFsl-00026v-00 for megaco@ietf.org; Tue, 13 Apr 2004 00:50:48 -0400 Received: from fw.cdotb.ernet.in ([202.41.72.207] helo=ws9.cdotb.ernet.in) by ietf-mx with esmtp (Exim 4.12) id 1BDFq6-0001xl-00 for megaco@ietf.org; Tue, 13 Apr 2004 00:48:03 -0400 Received: from cdotb.ernet.in ([192.168.51.210]) by ws9.cdotb.ernet.in (8.9.3/8.9.3) with ESMTP id JAA07712; Tue, 13 Apr 2004 09:47:41 +0500 (GMT+0500) Message-ID: <407B6EF5.8060901@cdotb.ernet.in> Date: Tue, 13 Apr 2004 10:09:17 +0530 From: Prakash R Reply-To: rprakash@cdotb.ernet.in Organization: Center for Development of Telematics User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: cdotb.itg.stacks.megaco To: Prasenjit Das CC: megaco@ietf.org Subject: Re: [Megaco] MEGACO/H.248 Is there any difference ? References: <009a01c42055$6d9a3c30$f904120a@in.huawei.com> In-Reply-To: <009a01c42055$6d9a3c30$f904120a@in.huawei.com> Content-Type: multipart/mixed; boundary="------------020907060404030208020108" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format. --------------020907060404030208020108 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, We had compiled a small document on the relationship between the major Megaco recommendations/RFCs. Maybe this will help. Regards, -- Prakash R Business Unit Head, Softswitch and Media Gateway,(Cell & Packet Tech.) ====================================================================== C-DOT (Centre for Development of Telematics) 71/1, Sneha Complex, Miller Road, Bangalore - 560052, India email: rprakash@cdotb.ernet.in, prakash_r@hotmail.com Tel: +91-80-22263399 Ext. 268, +91-80-22383951, Fax: +91-80-22263256 ====================================================================== Prasenjit Das wrote: > Hi , > I would like to know if there is any difference between MEGACO 1.0 and > H.248 protocol. I read that this is published by IETF and ITU-T respectively > of the jointly developed standard. I think as per protocol wise there is no > difference. But some body told me that there is some difference for some > package support. > Could anybody confirm that. I will be greatly benefited by this info. > Thanks in advance. > Regards, > Prasenjit > > --------------020907060404030208020108 Content-Type: application/pdf; name="megaco-std-hist.pdf" Content-Disposition: inline; filename="megaco-std-hist.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjQNCiXk9tzfDQoxIDAgb2JqDQo8PCAvTGVuZ3RoIDIgMCBSDQogICAvRmlsdGVy IC9GbGF0ZURlY29kZQ0KPj4NCnN0cmVhbQ0KeJzVXMmuK7cR3T/g/YPWAXJDFtkTYAS490rK 2skD8gGZgCAOYG/y+yGlrkE8RaplO4vgAYYv1c2urvHUwP7xFMq/aZve0mnNdPrpb6c//+b0 769ffrz9EE4//ePrl49vX79ECm/raZmWt+n07a+n313jKebTt7+fvgvx96dv/yxXpLJHqD9+ FyikkO/L5T7i5SnMcq0sLvel9LbxyrpfFHlhC+/7UnibefEjfO6LWTc7h8u+KEvXMMewL668 OFda4k455Td51DlSTJFpr297/yFO96X1bdFn5TjHnXyaDRFljxz3t6BVfojbfSm/MR0xl4v3 dyOS5UD3pVk5OvGKULqzcpGV+MF8ExrNUn/vKDsJWQuviEx2jsjGgV9FVnZpZKGP970U9fke NYqmUEhYitI1+lQkU4R23bkyKcOR8vN9ZVIxXfS5haFT/4UGbNiA6am5q/NKWyjCWGIV5O2d 6FTU8G4j1SR2WSxvueFqZ7uiXf5uE5uMMpvNqFiWWAixJW32wmJM4UNI2cwPrOGy9ln+vT9/ 43nb2CsojcUSWYZxVZpW1hvR2nCAC+4TPC6Up7JVx02fmtpLq5WD22KzNzumGNjyo5pteRAx s3KjPnOjcsYvuELKrMLiJZbiFch5ZlzvfpUpT8bvEfuWYulJ73iPHyzrYg2L/vAZzyHGS7xS OCDftb7EI/fZ3Fd1SJfWRcWZGb+JJfKbmfcNvJIbcY0UwiHpqFmwCu5/MweSca0Ume6luSuB B1G6iURuUV+PwFNOj5pSHjd+4bsQFiqPfnxjysTKOYObNBwGvaaxa75x2Hmex2Fvo7cpxG02 2y1FKd0NV2IBhY54Ahm26lsqW8XgJmLgYGJiAGagXV5CIjYfI01xTGrkLXGt0YfMuqs4QfWr Lw/Y54OvUGNmTm2qpy6rmDNkdLDROHovjF/lMmHWVFmBjJggilDM8JozKFmJegLHMmwnKhNv SlPiv1GTv/zw9Usoe//nQaH++IeyevptPP1wopzKz+V//3X608BophoEGqOJ9T0lMq1dUT43 EWd3z0Too/Um9ElnBi9RpHJhXdUALBcFlfoGl8EKXRuBw9ZwxWcKdC6gWqhNirU75Fby+NlF jfrk4EqKzeNbcq5A8OfzlUJ8Fn6x5SRqBJvYIg2uM+hnbUkUM2IuDt10CoDX4rVoXBaNU2rB yMUZGnyQknF/AmjVsqKJ6+2GKReLVkPnZRL73bouKCV+/bm7Pec4K4TJPIAFoZW1eOSpzxmF dcFIDS5LQGIbbAVv9V8riQ2zLlCOjGU14CTm2ECiMVUBkDrlDULnCH+KUEZCCDQbNyvhkILa Ag3uNoqk3KalhDJVHHX8GN8c1OwgQV7p62o8srPIt83L5wFfC4pX++vrmIqd5VkMlzMldTLx zLow9ANx8XKiJCJRayiAn9HHBum9YvyBsb1sagvYkD6Hzsmp6CA5sX241m0Gtzmp2ARuPPdk mp2sIXXfHkI6PjuDPs3PeOjgfqFuBXoVq5XETfmKBKDJx4YdQ0QG1zj7JCaq9Vc2kezuw3+L CqFwlOK0FB9SyzhSS0vJkRQ1D1kgBDiBpFHACbyb1TZr+aP3finypjVtJT3YrTaRbvN+CCOE DMmrBkFA94YDJf2/VAJolqwigcsYPXpaFoCsFp4Q2q4W4Eh5mYUflUlSXzX+/QLeCvdz3tm+ 4/6GM5iVbiHZXNcOiiYy0ZoQacRUE0JqHt5XnthxKvOAcaOiB0IX9Q1paYl0S1QcPQgswTBK oitWYrQo1osO0yAmo6NBr3rE8yo9AlMxpYSVCLjdoVlqBUqPFvAGFZ4UIM1lhRvpdZ9HrQMy KmI9FfpWvRBRCuc8KjYGKLqSjviGOZfrG98AZRaEYMX+ua2j3iMupham5ZOofha1RUz2vdVM 1NWRRiEewjgDMUPd2Qok1lI2LYLhSRPj8Hg37PYBFgWuAHMWdGJME0THgVtgwfVoixrdNNGJ Ql73UdafahYRc/1BumEI89WoiqJreXsBegE7dhVf1VyI+2i9HJctTMPhytf0dCCcWW/EogF7 E1/D1EWmBRA8eOC5K7W+x+vLETWKZhaj+ESxBIBA/RC13NLAJEqPmZOVKUYqJmLoc6b4P/c4 bKRGzfUVRH6HtEtzPwoOP/pdLqfNE/GaQq1axmD7R1SL5RBxT9MdxGqSn5YBD2qOUpDRvcnE bfnkFA/sDYL9DMUXaUvYnOUAmHKK84AKnBrAKxUIcHRYWZGVq4gjDIy2XznDutDLIqyJhmi1 3K0DEW1t0quwtO9sJOVEmghwwkkuwUiP9BGnon1LY+4enDG1NkE9/QSRb1uk3Sw82VotcPAj ivN5w05cW+w5+7t82QxokNWi3+1qZuur524E+/UlPYFega01jq0nqBGAFR5cWeBxVFQpLn8t 3i2aIPXcvk0TywsiLSm+ZLuerH8jZmBmowjexNloAJkVPvUhIrOkDwHElxt3h4lqrqhggPXM fuo+B5WxIzCBKv75XwMFIdZMbOg7kJ2Vodq0Zx2lSfEzjEUccYx5W6BplOaS/3O52Fo6I09b K+YLN6MitfAhxG+21fWYaqp9GGhvYLiTKsesENPyUKsqLcjpPdyMpExVQ2vxZ2eqKaisUuII 5lFaTjW7s2ds+wNYXZ4s3aPBHE0NmzDg2QsXB/eXcEYYMWKbuZN+j9+tAu76bjLV+cZDMjNw /x8Z+fyawSwRK6jnJ3fGW9nV3BrFlbwX7buyhJKB9p+NyLEJ/eSZU82bPHK1snMwIUcP2qly 9y+MUUO+0QAdTUSwb/pCXthrqr9zI2cviMl+x6q/CI7VFKoLZo9LCRGKPn1l2jdTXSwJF9U2 qeQ6EZN3fdYmTmjEpcMdB6/J3MqmX8ebAXhjG6SjknlafqkR8Hjc2NCmBea9flnXzkR1qcvC +M6gbabZ5YFgWLNxKQWaTiRpQIzZ+l0uAKmbdgqJg/j3st82dY2Dor/7zhS5zCuyZ6lrgnlE wM5GdyUi4onGpJGYMoVQATtPDBlut4//KDqmk406nH+EqtgiKaZFh53VitrpdTMQvdGFQ7SZ k07O7BDrp5nG7WcW3pSLuETrz0zBbaP2VANdpElPA0pqSBGghi2S9ODcw5r01MamdTDHavh2 AxKln4b1lJHHR3RT9P3KfoK8onjrUzvqkHJUZQAFFS8n9YPUElcVdvyEtc41OwoHE5/OtAu4 9rbKoAnb+qtIeHZaXi+0HrAwb8/7tDEooqgv97RxF6zJMJcjVh0ylI4ORuTX+gZClVR6I1a+ x/MSUZOJ/vxKAnW7Z2yAsEajES+DDm+6xdRqBRpB4ayvF1hw7J33Wep2RpAafeSYiiiUpEvy Lh8tCBmbZph7WhOAe8gmO7C5DZF3yEnh8zbas1s3HksWHEdnoBFHBI2y9YrIElc2B2Ur5VI5 +jWAr1O3IbIDKINndIulQ+eRtgjVo58HCuhagMk5BTlUo7pfFUEyIRMF79Wyj0fk95DVaHJi YjlUThwDxJwGuhx4tmZQyzcvQ4aoB5QaTPd2M05KSlUiK0mris6pglekEOY06WhlMtI8HzuQ lOYM9TKYID9SDPA2euLGYlgebzwALUQKYhXvPrGiNYskD/TWgvLUbGK2Lbi5gMXMyTNNJlUm aiW0FAeQKJX/HgnBRWYw0Ro/H9TheUds0A8leBvo8ByBj4DilgIpTZJPzoythD0DKHoXpU46 hr0UZxrXFE2xWGEozkEzj8F82qweoL/dKPB0ZwoenfmA1p8xEjjcTVJ7Oat9qGcHuCYlkAc+ ztnZFMNoNOH6YvPIDOGOOTuO2I2XeDZtuhtuWvH4Jo6ewATHSOHMIMwrQ5KjDn07zZ44EXZc BKbQpiDZtoGj2P4GeQ6epzel1xdGJifQlWS6JV117Yfpp+xxvGH/Hqfd3C/bm8hNI/Y8P8XY lTrOKIg6ObgsfpJO3Zgq5JmLMW7iKytSm3goxLWX+eXoezFCYFuGDXpFVqpJu7G84yihLYod 7jXkpZYpPWvXgkSf8TXnkeB3eIhr9zCU8WzyCwC7F/GfdET6jWcAF4+zbNEZi2grF+jEzcCC AQo9B+4eJjLzY1jUGZD/dJjBnkeIJqEsEUICiRRiz90wxbudW+LbHkCLtpMMT5sUnr/PEmGb 4dHQC7A7ADmtomBFZ1LdhTNfI0SpzsL4D9uRMqAaNQMPsY2k2Z+S/Rnloa46GcQxtuIb1Ghw QuvSScpFJl90zlSm8Rm5mGpUNU8U/0h2pnBzSoyK1h120HsoJsYsIDP7VlLX26eAokhRtOL2 qRK5x3w9B6a7+XT3w9BDE8tjONNHSaCvxdg/9Ws02RRoziVF+3zSY7klurRODXtKinekN4M3 1kgWAFufS0K/FTIFr5MZ6TuXnz6Y8WRqrEkLFrykn3YyeHiji4w9mFM8nVJe/3B6my7Lh5QE NFS2xEJX3FtM9Rs391x4Nw+VKs0l6Q0y8WFU7JYNNxw6mBzT7QGPtmM/RuXB5dHYJ8alWmaU ooBBVO3pdtjK6bmiLZWkljR8aPgnjNlHDuXi4Z5sZsEGE6qqWVjmMsM/wK5+A6L9W7W4G/q9 09aKaTFAOBcdHdD2G34QXVtouAny9cbyX6L1EO7Fg8A/42UdRbxqj1wevpv2qI+PXQwZf+wP q792cErM7lk18Gb904rjie1sar99FpP5xtRgzhyyxCOH320bcXCVBlNTgBfD7p/at53f/lVk tx98AsAZ6XSmD9uIu+iXzqKd9tCPXEhl6t18FAHOkI6+PwHHEPpHFwa7HBtD8tJUJcQ40n57 eXCOe0CfjrSaal5/pNXzCq/0t0HBhej++8fFG6tB9y92t4z0bdhil5mrMZTNS2WycQE+5DJN pBvoOuJWcuVEs+cNq5F8jEfFtMm3Kp7PaJrvVSmixUO/ktXoAIqZ5HaGdhpU2MNxduc+khty iFI9XmM4JI43Q5gZ5I9wKvDIPIb3lQ49kuCEU2ifOoe/+uc17fe5+t+XG1bpi/utHyvdI9Go rI2YiAc3zImwPhtfyXb1ruf9aUlYVPXxO0Bmw24Bw9QZQvLmDj5Fi+0sWJIgd3Tw927BKeJg P9CWZSxXa9bd6KLzPOA+N1ZhnCfQKIAfyHUKwOA3Jt4IRa+fXmVX2vukGs06x+8MVejhfAMo cahBQPJUYKom7YPvKEy9SGD4MpnA6vWMFIRF9ZjHv5qSjAGZBKtf63IO8pix4GGpFj8xZYQ0 vGo4WnBkIIGPScs1ppOAAteoFJzwgnrR9S19JXkWu6dq0MZKmzJUzYolCTKYbfxR3N324/oG RZhagZJK1GPhadZvNJcLZq2oGOU+VFx68sleyrUaYagzkbNxat+f/gu+6+CcZW5kc3RyZWFt DQplbmRvYmoNCg0KMiAwIG9iag0KICA0MDE0DQplbmRvYmoNCg0KMyAwIG9iag0KPDwgL0xl bmd0aCA0IDAgUg0KICAgL0ZpbHRlciAvRmxhdGVEZWNvZGUNCj4+DQpzdHJlYW0NCnicTVHL asQwDLwH8g869+Ad2ZYTw1LoxhvosRDoB/QFhW3J/v+h6tpKFvvimdFoZK0EPZLFBRqjp+sH vT7QT9+tNwJ0/eq709J3LOyYQo4u0vJOh5mJPS2fdFRmeqTlWzVwoiVKHxFQfGywaGWFvVQo Om/CgpEnLhX32AiGSa0YCXNzZI3bHJ8qlO4dU8WyaYpi3ErH3c9rSss46FwNFm00YERumZIz I1gze58wofAZs7UMYbNnqI8Y4ffIzFpTlI6ceEDEzIN9oYgbmiy0xLIni/YpDPOatmE3GSeL ftbFveillTIoQijqMjyFJPebruC/ZUhRh61aHeTt0ndEh+eLUPmlm9Mf9IpzHWVuZHN0cmVh bQ0KZW5kb2JqDQoNCjQgMCBvYmoNCiAgMjY3DQplbmRvYmoNCg0KNSAwIG9iag0KPDwgL1R5 cGUgL1hPYmplY3QNCiAgIC9TdWJ0eXBlIC9JbWFnZQ0KICAgL1dpZHRoIDc0NA0KICAgL0hl aWdodCA2NTQNCiAgIC9CaXRzUGVyQ29tcG9uZW50IDgNCiAgIC9MZW5ndGggNiAwIFINCiAg IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlDQogICAvQ29sb3JTcGFjZSBbICAvSW5kZXhlZCAvRGV2 aWNlUkdCIDI1NSA8DQowMDAwMDAgRkZGRkZGIDAwMDAwMCAwMDAwMDAgMDAwMDAwIDAwMDAw MCAwMDAwMDAgMDAwMDAwDQowMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwIDAw MDAwMCAwMDAwMDAgMDAwMDAwDQowMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAw IDAwMDAwMCAwMDAwMDAgMDAwMDAwDQowMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAw MDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwDQowMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAg MDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwDQowMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAw MDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwDQowMDAwMDAgMDAwMDAwIDAwMDAwMCAw MDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwDQowMDAwMDAgMDAwMDAwIDAwMDAw MCAwMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwDQowMDAwMDAgMDAwMDAwIDAw MDAwMCAwMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwDQowMDAwMDAgMDAwMDAw IDAwMDAwMCAwMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwDQowMDAwMDAgMDAw MDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwDQowMDAwMDAg MDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwDQowMDAw MDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwDQow MDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAw DQowMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAw MDAwDQowMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAg MDAwMDAwDQowMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAw MDAgMDAwMDAwDQowMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwIDAwMDAwMCAw MDAwMDAgMDAwMDAwDQowMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwIDAwMDAw MCAwMDAwMDAgMDAwMDAwDQowMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwIDAw MDAwMCAwMDAwMDAgMDAwMDAwDQowMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAw IDAwMDAwMCAwMDAwMDAgMDAwMDAwDQowMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAw MDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwDQowMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAg MDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwDQowMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAw MDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwDQowMDAwMDAgMDAwMDAwIDAwMDAwMCAw MDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwDQowMDAwMDAgMDAwMDAwIDAwMDAw MCAwMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwDQowMDAwMDAgMDAwMDAwIDAw MDAwMCAwMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwDQowMDAwMDAgMDAwMDAw IDAwMDAwMCAwMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwDQowMDAwMDAgMDAw MDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwDQowMDAwMDAg MDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwDQowMDAw MDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwDQow MDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgMDAwMDAwIDAwMDAwMCAwMDAwMDAgRkZGRkZG DQo+IF0NCj4+DQpzdHJlYW0NCnic7Z2LluooEADh/396z94xoR9EhaikO1Vnd1TCuytInDG3 VoAbUADSg+dwB/73fPU7CsB3wXO4A3gOdwDP4Q7gOdwBPIc7gOdwB/Ac7gCewx3Ac7gDeA53 AM/hDuA53IE3PF/9h2Zf5UfT/G1WT+NX+cwEvfb8E+1clCxjyzKOHnh+nixjyzKOHnh+nixj yzKOHnh+nixjyzKOHnh+nixjyzKOHnh+nixjyzKOHnh+nixjyzKOHnh+nixjyzKOHnh+nixj yzKOHnh+nixjyzKOHnh+nixjyzKOHnh+nixjyzKOHnh+nixjyzKOHnh+nixjyzKOHnh+nixj yzKOHnh+nixjyzKOHnh+nixjyzKOHnh+nixjyzKOHnh+nixjs+P4F9LeV9D0l9Hki2Jf/HQA T8Dz82QZ20nPi35uv5ipz4XWwJbzt2ObqwTPM3DguU2xsZaJ4sgu+/5S+W+8x/Prk2VsH/W8 SSxebqIYzz85iAPw/DxZxvYNz/dKd6W3fJ19zBfB8/NkGdvT/XlLsVvv3v6860Nb06tcyTvb +M+Lj+fnyTK259ehe8qR5/q592E/Far1vK3+5hL3e2ObqwTPM3Bq31JM7p4P7QRwO3OuQ69P lrF98zrU788rngcjy9g+6vm+wPc+b5Gebx82tmLsW65JlrEN7M9dtq7nUlixcTfV9bLh+QXJ MraznlsLtK/6WtWU/PoU4vl5sowtyzh64Pl5sowtyzh64Pl5sowtyzh6rPe892uG/cXZfn2t atXM56paSpZx9LiO5+aix153qyzVPenWP1j1kzYmxxaLLOPocQXP24P9+LVptqlpZVWfU52r +kkbL4b/KsNCRt65rjyOs1zV87agVnXY/7rhScNjVR+18XRcz8d2Aeyb17OsX+/MOi7uefuz zieemyjKSkaq7rbxjiDX9qMIXuT8TYeWcAXP/Sa6X11RWusypjdTVbv9+Zsr4cX9KIbjjD/s 1K+5juf6eac6sWWu6onYg2y9mam6tgytDV31+2Ozcl2Nd8eRhSt4/vfTbi58viJ+FK23eCLi OFS1Po+K2hs95+p+vGf59cdxhqt4/upiUdm675ud5zqSQ1W3s2J/lcPzdxT/y/izLv2eq3ou 19j2stmun6j4vboOPaja7dGTeP6W4n85f9GdRVzZcxkc+8bbDrsYvuN5p+rO9VoGP94bwl/W jzarY7Ynmo61znWCIrOqms3K9sYILuS5raSnuUhVTzoVjldd7aOe7YmxredNxf/yfrjdKc+L fOEPdDxXOXXCh8d2yvP4ZBnbpz1vjz3PbYLemIqd5b68+XyPZ2J5qvocabV/alB4Hp4reP5P YLX+FyO291zkLCpBtnR2QFtTeB6eS3j+99mCSNulV/k6npdS8fybZBnbVT23ZfzGpEjP2Z9/ iSxjC+v5/kGD2J/blqZHYrqL5+H5jedS0znPqylahOLtstWUOj8kPF/dgQ/xE8/LC8/1dWhT 1lyHiqJFnz6+5o+NDc9T8E3PxScnnVz9nKVb2HouPzSXnzGalj41KDwPz/c8V5uVTi6Zxe5t bFn13tAOi0Q+P/8OWcb2Rc/7F4ddzzvZzYv9wWnN5y3fJMvYsoyjB56fJ8vYsoyjB56fJ8vY soyjB56fJ8vYsoyjB56fJ8vYsoyjB56fJ8vYsoyjB56fJ8vYsoyjB56fJ8vYsoyjB56fJ8vY soyjB56fJ8vYsoyjB56fJ8vYsoyjB56fJ8vYsoyjB56fJ8vYsoyjB56fJ8vYsoyjB56fJ8vY soyjB56fJ8vYsoyjB56fJ8vYsoyjB56fJ8vYsoyjB56fJ8vYsoyjB56fJ8vYsoyjB56fJ8vY soyjB56fJ8vYsoyjB56fJ8vYsoyjB56fJ8vYsoyjx888z8wn5vACrJ7Gr/KZCXrpOYAmoC94 DsME9AXPYZiAvuA5DBPQFzyHYQL6gucwTEBf8ByGCegLnsMwAX3BcxgmoC94DsME9AXPYZiA vuA5DBPQFzyHYQL6gucwTEBf8ByGCegLnsMwAX3BcxgmoC94DsME9AXPYZiAvuA5DBPQFzyH YQL6gucwTEBf8ByGCegLnsMwAX3BcxgmoC94DsME9AXPYZiAvuA5DBPQFzw3rL5p5lusnqPF 7U+A54YIc7G6j6vbnwDPDRHmYnUfV7c/AZ4bIszF6j6ubn8CPDdEmIvVfVzd/gR4bogwF6v7 uLr9CfDcEGEuVvdxdfsT4Lkhwlys7uPq9ifAc0OEuVjdx9XtT4DnhghzsbqPq9ufAM8NEeZi dR9Xtz8BnhsizMXqPq5ufwI8N0SYi9V9XN3+BHhuiDAXq/u4uv0J8NwQYS5W93F1+xPguSHC XKzu4+r2J8BzQ4S5WN3H1e1PgOcGMxfb1xqm5sgV2uo6OeOr47W6/Qnw3KDnYv/+zsc8L3i+ Ajw3qLnY19/6998j7bHAq6NN36bxY3Kb1tJzkV2V99U87+MCVrc/AZ4bjOdbmljY5WM5OrAX V9/oFIbberaETjXP+7iA1e1PgOeGnud1V7bum5h97e0dUJ6Lepza1ZZ36S/7uIDV7U+A54Yn nhu3q9xj6HVZFDKey8V837GIih+vZfqLPi5gdfsT4LnhcN9S5T7k0PO2KNd3PG/lq3xd8fzD 4Lnh+Dq0VvHY37f8OyPafuO55/Vv3S6qAZWO5x8Dzw16LuRW2m5P2mF54ShX5Seem+x6iec6 9OPgucHMxb7CHuxbhNfi4bnnraKqziS11Mt9/os+/pzV7U+A54apuTg7g4PlV8drdfsT4Llh cC701eNEczPlV8drdfsT4LlhdC7OaT5XfnW8Vrc/AZ4bIszF6j6ubn8CPDdEmIvVfVzd/gR4 bogwF6v7uLr9CfDcEGEuVvdxdfsT4Lkhwlys7uPq9ifAc0OEuVjdx9XtT4DnhghzsbqPq9uf AM8NEeZidR9Xtz8BnhsizMXqPq5ufwI8N0SYi9V9XN3+BHhuiDAXq/u4uv0J8NwQYS5W93F1 +xPgueHlXKg/Nt/T6v5lo34ZPcsnZ/xX8Tr6C7OAvuC54R3Py008P/qr4YC+4LlhzHPxbaOH 5/tXRdu3PtUXi/xJ8oU+fgz9Xb7ft/8x8Nww5Ln8Et3uufoenPbcfjfuW338HMXw6/Y/BZ4b RjyXjov1vC3q3nM945NfRirev98y2uH14LnhDc83yWvdVuau54/M24PcsOzJc9r8Ml49yQP6 gueGIc/LoOfyvPhmHz9Hdx0P6AueG0Y8l9eg7+1balWeX349729VAvqC54Yxz5+t58KP9kHM ln/7RObanh90L6AveG5403P1+UnP82eft9QJt4f6+CGOehnQFzw3fHYuvjO1q+O1uv0J8Nzw qbn45kdwq+O1uv0J8Nzwsbn44ifNq+O1uv0J8NwQYS5W93F1+xPguSHCXKzu4+r2J8BzQ4S5 WN3H1e1PgOeGCHOxuo+r258Azw0R5mJ1H1e3PwGeGyLMxeo+rm5/Ajw3RJiL1X1c3f4EeG6I MBer+7i6/Qnw3BBhLlb3cXX7E+C5IcJcrO7j6vYnwHNDhLlY3cfV7U+A54YIc7G6j6vbnwDP DRHmYnUfV7c/AZ4bIszF6j6ubn8CPDdEmIvVfVzd/gR4bogwF6v7uLr9CfDcEGEuVvdxdfsT 4LmhfXFZTIz6QrN4+WTu3p3U3tfpXxVdHa/V7U+A5wbhc5N7+wrc/nMXHc9jgOeGrud1myh1 Z6Lanu83qyjqTlyl2OOykrLdCkYlqqLP+riO1e1PgOcGtYRbz+uB5+2uVWLp3xd+ebzqR1Pq 8aq2bE/6uI7V7U+A54aO548EuVar/Xlpa/C2Ru/P22JeVZpI2N8J9jun1xdxWR2v1e1PgOeG 7nXow0SxpTD7FqVt28xsq7XyfN/M6JOgnUaPBo+jsjpeq9ufAM8NR5+3VKWt3Z8/87x0PC+v PK/sWz4Knht6nrfditp+b4eeeF63Tb3at1RToKjSWzfw/IPgucF6Lq8d1WVnrTpLdfvzKpZu 4b9b4E3iX7Ws5x8Fzw0dz4v2XG0pOp6LBb8Ue3zfeZsFXr9L6GuAgz6uY3X7E+C54eRc6E32 l1gdr9XtT4DnhvOef5/V8Vrd/gR4bsDz67c/AZ4bIszF6j6ubn8CPDdEmIvVfVzd/gR4bhie C//BiP7Y/Qusjtfq9ifAc8PoXHQ+6cbz64HnhsG5UL8/Ek/Er/Y/P72r47W6/Qnw3DDsuX5q f7X09Pc9s6yO1+r2J8Bzw4zn+jf5tSne/gRgZR8/zur2J8Bzw4TnpeP549jzv1P5UR8/zur2 J8Bzw9y+5YXnH57g1fFa3f4EeG74yHWo3rd83IvV8Vrd/gR4bpj8XHG/5OQ69JLguWHy90Tb 5aj503M+V7wIeG6IMBer+7i6/Qnw3BBhLlb3cXX7E+C5IcJcrO7j6vYnwHNDhLlY3cfV7U+A 54YIc7G6j6vbnwDPDRHmYmEfy+L2Z8FzQ4S5WOn59nuvCPMkwHNDicDS6ak1oDN4DkOUf78U W3quzYDnMMQF3lNmwHMYIqbmeA5j4DncATyHW4DncAfwHO5ASM3xHAbBc7gDeA63AM/hDuA5 3IGImuM5jILncAfwHG4BnsMdwHO4AxF9wXMYJaIveA6jRPQFz2GYgL7geXTO3z0gH71ZwvPY EDwHnieE4DnwPCEEz4HnCSF4DjxPCMFz4HlCCJ4DzxNC8Bx4nhCC58DzhBA8B54nhOA58Dwh BM+B5wkheA48TwjBc+B5QgieA88TQvAceJ4QgufA84QQPAeeJ4TgOfA8IQTPgecJIXgOPE8I wXPgeUIIngPPE0LwHHieEILnwPOEEDwHnieE4DnwPCEqePaua2+H9uB2bb6CR0L//m5Pmvs7 9FfmKNth8UFD8TwhWmuj37uhfXpfwl5Cv8BLz+uM5wen4DF4nhBldXmkPCQUP7dA/3u6JQhr 6+7g/iCKFnHgUaK2+lRDu5aipk65PbOpW7dfRUVTU9KmBs9j01u9t9V2/yE9bwe1faLk/mhq KT3P20GTsV9uP8OKLV59aTuw4SmRNeB5ZIznD02qMWd//LeA7st0aQUfT9qyb/4vSpbShNQH W7P10Q0t2X6CtZPtT/6tUt2u6d/wlOipGaoFLkXH884K2TwXK63xfFPhyHXvefUHt+ed/U0r 6D23Wxw8B43yXFsjhWue6y2HKjiynu9tHq3n29uK97zKlyKV9RwOkcErmm07rNdzdVAVdNuR tp9WB6r3XBWXzZlye6vipPPF8RwsKnh/7ihv7fquD6qC27HqPVcHqvFcbjzUJqS4cnrj44r7 zurWJqak1YDnkZkPXskaeDxPyHTw0mqO5xk54fknu3El8DwhBM+B5wkheA48TwjBc+B5Qgie A88TQvAceJ4QgufA84QQPAeeJ4TgOfA8IQTPgecJIXgOPE8IwXPgeUIIngPPE0LwHHieEILn wPOEEDwHnieE4DnwPCEEz4HnCSF4DjxPCMFz4HlCCJ4DzxNC8Bx4nhCC58DzhBA8B54nhOA5 8DwhBM+B5wl5O3jiHqL6XrbiNrUih3y+v/jGAD4PnifkW54X/Vzl2Q61/J2EdeB5QkY9tyk2 /jJR3zhaLunWf5+wEDxPyG88b2u1eCnl6dy1fBl4npCfer63VrY8bYtjEhaC5wmZ25+3FLv1 7u3Pu47ILCKls43/tfh4npDJ69A95chz/dw7ItZxtakRCaa5n4HnCfnOvqWY3D1Hmr7bKWRr XgSeJ2TJdWjbn++Z1aKN5/Bhfvm5ov+8ZduS6yNypWffAp/gE/tzl63ruRRWbNzlo70OZX8O H+JrnlsztK/qWlWdBj/X2oHnCSF4DjxPCMFz4HlCCJ4DzxNC8Bx4nhCC58DzhBA8B54nhOA5 8DwhBM+B5wkheA48TwjBc+B5QgieA88TQvAceJ4QgufA84QQPAeeJ4TgOfA8IQTPgecJIXgO PE8IwXPgeUIIngPPE0LwHHieEILnwPOEEDwHnieE4DnwPCEEz4HnCSF4DjxPCMFz4HlCCJ4D zxNC8Bx4nhAbPHlXz/2Wnv6GoP5fsJBHZVZVc639u4S+VujAsvfcGzMUzxPyMc+LfOEPdDxX OXWCLNGeqpvslr37LrmTcGZKKp7Hp+d5e+ze+tkkSH/lz+3e0LZGtfLLW0E/eWOQp5/K2Ev2 +fpvIu9OScXz+HzK8/owrCUVI7b3XOQsKuGRUS39u+vV5FZP/o6LAqbWmSmR7UBQPuZ5fRi2 p8mthazReb4VfMfzvwKtuKlHV6bOpDfnQ3TYjBfPI/NNz20ZvTF5pImCx/tzdx60bYuqx5w0 IiOe35ulnovtyJ6h24r13Fxf6p1M53zA87vzvudS0znPqylqdiNys2Oy+n1NEU3ITmnPzcXB e+B5Qt72vLzwXF+HFmFfMflaQXX6HJ9B1vM9Y2fNLnqzX1xV41OyT8D7VcDVeOW51sXm6ucs 3cLW85ZLnkJveF6s8EVn0u8QvsOvwPOEPPdcbVY6uWQWu7exZdV7QzssErcEv9nQBew7gEs2 Cb0zdWBKKp7H54Xntat51/NOdvNif9Ba78fsmt7d4oiM9tQyjwfvEsNTUvE8PkGCd1IyPL87 QYJ3TrKx0niekCjBO2UZnt8egufA84QQPAeeJ4TgOfA8IQTPgecJIXgOPE8IwXPgeUIIngPP E0LwHHieEILnwPOEEDwHnieE4DnwPCEEz4HnCSF4DjxPCMFz4HlCCJ4DzxNC8Bx4nhCC58Dz hBA8B54nhOA58DwhBM+B5wkheA48T0gBR2+W8BwGCegLnsMwAX3BcxgmoC94DsME9AXPYZiA vuA5DBPQFzyHYQL6gucwTEBf8ByGCegLnsMwAX3BcxgmoC94DsME9AXPYZiAvuA5DBPQFzyH YQL6gucwTEBf8ByGCegLnsMwAX3BcxgmoC94DsME9AXPYZiAvuA5DBPQFzyHYQL6gucwTEBf 8ByGCegLnsMwAX3BcxgmoC94DsME9AXPYZiAvuA5DBPQFzyHYQL6gucwTEBf8ByGCegLnsMw AX3BcxgmoC94DsME9AXPYZiAvuA5DBPQFzyHYQL6gueD/P6fvrweITqpwfNBvjxXIUIRopMa PB8Ez4N0UoPng+B5kE5q8HwQPA/SSQ2eD4LnQTqpwfNB8DxIJzV4PgieB+mkBs8HwfMgndTg +SB4HqSTGjwfBM+DdFKD54PgeZBOavB8EDwP0kkNng+C50E6qcHzQfA8SCc1eD4IngfppAbP BzmeK/cX5DPzGiIUITqpwfNB8DxIJzV4Psgzz/cnZbP+X+rj1cnqL0SITmrwfJA3PP/n9ra4 D34lLkQoQnRSg+eDvNy3bE8f8/pw/d1ZDhGKEJ3U4Pkg73ped8/3Y+eqvxAhOqnB80He2bc4 z9m3rAbPB3nX8yI8Fwv7fPUXIkQnNXg+yDufKz625LvsXIcuB88HecNz6Tr7lmuA54Pc6ff+ RyfnpTr5Hng+yJ0897/ifSQv6cwp8HyQW3mu7iYpUtd1aBY8H+Renrvbpv4lLu7UBHg+yLc9 D8F35+Ab4PkgN1vPOyfeBTv5Gjwf5Gaed9fxq3XyDfB8kHt53t+qXKyT74Dng9zK84Pd+LU6 +RZ4PsidPD8S41KdfA88H0S/gb/48EF8xcj//7r6qxKikxo8H0TO1ctP2fD8KuD5IPLXgvsX hra/BPn3x1vbsSJeC7//Hdn/uquKR1P9dQnRSQ2eD6I831L2D5bLLvxD53YCSM9V5ngf2YXo pAbPB/Ge70t63f/qvC3m6q/Qre+dfUyIUITopAbPB+l5vl+Qti8Obet57e/N7breq/66hOik Bs8HebFvqfvC/qbnZT9JbPXXJUQnNXg+SO86VOlchd9He5b92L+TZKvJVH9dQnRSg+eD9D5X lCtzlQnigPy/6DWf9fz74Pkgaq7Mxytvfd6ye15NYV/9VQnRSQ2eD/J0rtrn51+p/gKU/Ucs 8HyQV55/s/oLsF1UXL6jBjwf5Paeb1fOq3syBp4P8uW5unwo/l1diA+IgoDng+C5/oAoCHg+ CJ5H1BzPR8FzPL8DeI7nd+Dunlc8vwV4jud3AM8jao7no+A5nt8BPMfzO3B7zyue34HyZVaP 7zVBuqnBcxgkouZ4DqPgOdwBPIdbgOdwB/Ac7kBEX/AcRonoC57DKBF9wXMYJqAveB6db/+C NiK9WcLz2BA8B54nhOA58DwhBM+B5wkheA48TwjBc+B5QgieA88TQvAceJ4QgufA84QQPAee J4TgOfA8IQTPgecJIXgOPE8IwXPgeUIIngPPE0LwHHieEILnwPOEqODZbxm8HdqDryf4Ch4J /e8zPGnu71B5/AvYz/K83bfjtvpV43lktNbGiXdD+/R7OL2EfoGXntcJzw/7dtxWv2o8j4yy ujxSHmaIn1ug/z3dEoS1dXdwfxBFizjwKFFbfaqh/X5doqZOuT2zqVu3r4tMTEmbGjyPTW/1 3pbA/Yf0vB3U9omS+6OppfQ8bwdNxn65/Qwrtnj1pf3QBqdElsfzyBgZHppUY87+WErdhdwj L0+Q5oT+vyhZShNSH2zN1lqLK7cdkifbn/xbpbrdajo4OiV6akYqgWvR8byzQjbPxUprPN9U OHLde179we15Z3/TCnrP7RZHealW9rEp0VMzVAtcCuW5tkYK1zzXWw5VcGQ939s8Ws+3txXv eZUvRerBej7sJ54nRAavaLbtsF7P1UFV0G1H2n5aHajec1VcNmfK7a2Kk84X77wFjDiK5wlR wftzR3lr13d9UBXcjlXvuTpQjedy46E2IcWV0xsfV9x3VpwGc1PSWsXzyMwHb0yeQOB5QqaD l1ZzPM/ICc8/2Y0rgecJIXgOPE8IwXPgeUIIngPPE0LwHHieEILnwPOEEDwHnieE4DnwPCEE z4HnCSF4DjxPCMFz4HlCCJ4DzxNC8Bx4nhCC58DzhBA8B54nhOA58DwhBM+B5wkheA48TwjB c+B5QgieA88TQvAceJ4QgufA84QQPAeeJ4TgOfA8IQTPgecJIXgOPE+ICJ64S6i+W624Ee0d wPOE4LkDzxPiPa8mpR9hn7bfA7qTZb9r9Km++prbydfuS627VGr3tb3PtHyO5wn5mOfFuWA9 /9wbgr+1ubhpemm5zJuQzW7Hged5mfF8W7mL+UcRnVbyYNVH9yo2P3XFenn263IzT1awdcok iW6rY7X1TJ0EnVnC8+Ac7c9bikkT62R3D29UPj5oy7aK9Wu7TMvCe6+r9FyeK/5NpWXfaqqi ixXPU3J4HbqnWM839bblV7hl3w2eHpQNbieFdLvadFu4iN5UtfA3Lc15p5f8NsTWUz0lrrcQ lPF9SzsFmiPHnh8fdCeWrFi8Fum+p/sKLOpqJ4c/O/6qF7XJ0wHP83Lac6uylFsrLNM6nrf3 EOW9aLBbXatC6y/OAll/q0ZXjue5mfG87Vv0ZqDneZWr7aHntVa5b9lrauldz/f+aZHtPkQe Vz3cx6bzd2YJz4PjPddrq3ho+Zoz+oXbJwjlj/ctbf1WyKpLcYVl9dX0pfbLWb1lz8p+YuF5 RiY8t1uVJ56rDcSh5yKXELyt7dvxJz3V7w1We9lxVUNtfuN5ai4XvPU64XlCLhS84hfgNf3o JOF5cK4UvGtojucZIXgOPE8IwXPgeUIIngPPE0LwHHieEILnwPOEEDwHnieE4DnwPCEEz4Hn CSF4DjxPCMFz4HlCVgTvKn/IcgCeJ2RB8Aqew68heA48TwjBc+B5QtifO/A8IezPHXieEILn wPOEEDwHnieE4DnwPCEEz4HnCSF4DjxPCMFz4HlCCJ4DzxNC8Bx4nhCC58DzhHSDJ+7Cae7U 2XLoX2rq33Cq33aq33zu9wV9tyuuX1MF38/Vz4jn0fms50W+8Ac6nqucOkGWaE/3461en9xP mJ8SPI/Ooeftsee5TZD+yp/bPZdtjWrl371UCfth1ch+XGTsJft8/TeR96YEz6PzUc/rw7CW VIzY3nORs6iER0a19O+uy9b3V/K4zje0oON5Qj7reS3mn3LbpVf5Op6X0jOy73lb2Pe6leeq MnUmvZ6P2p0SPI/O1z23ZfTG5JEmCh7vz4sRWm7PZT3mpKm74Xh+X9Z7LrYjVerrWrGemw2M 3vdIz8vRCPrgeUIGPZeaznleTVG3GzEbjCPPbROyU9pzc3HwEjxPyJjn5YXn+jq0CPuKydcK qtPn+Aw69lzU0/PcXAy8Bs8T8pbnWhebq5+zdAtbz1sueQq94Xk7izonUlHXocVX9RQ8T8gb nqvNSieXzGL3Nrasem9oh0XiluA3G7qAzmeSe5+fd87Ut6cEz6Pzjue7U/1cLYdyWx0yZTZv TDGZved5kdXJfPYsa48H7xKDU4Ln0YkUvJOm4fmNiRS8c6a9XRrPExIqeKdUw/M7Q/AceJ4Q gufA84QQPAeeJ4TgOfA8IQTPgecJIXgOPE8IwXPgeUIIngPPE0LwHHieEILnwPOEEDwHnieE 4DnwPCEEz4HnCSF4DjxPCMFz4HlCCJ4DzxNC8Bx4nhCC58DzhBA8B54nhOA58DwhBM+B5wkp 4OjNEp5DfvAc7gCewx3Ac7gDeA53AM/hDuA53AE8hzuA53AH8BzuAJ7DHcBzuAN4DncAz+EO 4DncATyHO4DncAfwHO4AnsMd+PMcIDt4Dndg9TsKwE/4D/B2HBQNCmVuZHN0cmVhbQ0KZW5k b2JqDQoNCjYgMCBvYmoNCjgwMTENCmVuZG9iag0KDQo4IDAgb2JqDQo8PCAvVHlwZSAvUGFn ZQ0KICAgL1BhcmVudCA3IDAgUg0KICAgL01lZGlhQm94IFsgMCAwIDU5NSA4NDIgXQ0KICAg L0NvbnRlbnRzIDEgMCBSDQo+Pg0KZW5kb2JqDQoNCjkgMCBvYmoNCjw8IC9UeXBlIC9QYWdl DQogICAvUGFyZW50IDcgMCBSDQogICAvTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBdDQogICAv Q29udGVudHMgMyAwIFINCj4+DQplbmRvYmoNCg0KMTAgMCBvYmoNCjw8IC9MZW5ndGggMTEg MCBSDQogICAvRmlsdGVyIC9GbGF0ZURlY29kZQ0KICAgL0xlbmd0aDEgNDgxMjgNCj4+DQpz dHJlYW0NCnic1Lx5fBvV1Td+752RRrtG+y6NLI0Wa7Ul2ZZj4nEcO6uJs9sBY2chCRCIbUIg QBqzZmGJS9kClISWtaSNk5DgsJRAgUKhJbSUAl1I3ydQKLikfQJtn2Dpd+7IDqGf930/778/ jeYus2ju3HPuOd9zzr3aMHjFhUiHhhCDpJWXLu+fEbIg+LyJEDav3LhBeOy3nWYoH0eIe3l1 /5pLb/vB5j8gpH4YIcXla9ZtWp3e+MpehIxOhNa9tPbC5asy5c1GhK6Ba1DdWjiwvbSJQ+ha K9TDay/dcNVVllNfQ70BflO3bv3K5e+PvnErQpunw/ltly6/qv+3/MUKqMPzkXDZ8ksvvHp7 4EOof45Q+vf96y/fsAqFywjtfY2e7x+8sP+f0dVfQv2TShsQho1+dFBU0jphWIWSU6k1Wp3e YORNZovVZnc4XW6P1+cPCMGqUFiMRGPx6kQylc5ka2pz+UJdfUOxcUrTOVObpWno/+cfxe2w z0UB2L3MnciDUPnPsJ+A/ZPS7PLXiktQqHRx+ThDyf7jiR0hEd2NdqMwOolr0EvoKJqNHkUt qBPdiWagt9A+ZECb8BuIRSE0HT2ORBxABLUjB1agXeh9dD4aRB+h4yiG5qA/YTP8ThvqR3ZU LH8K6Ry0rXwErtKgVvQT9AxehxeiDJRnkiROwJN3lo8iB4qVf1l+D2rfRx/hcHk/mgmlj5EJ RdEW9F1kRhejX5SBk+C3V6DH8LX4UxREfegWNs/uKF+CpqBD6Ld4DpQ60CbFe+pDaB3c9UPs wEfLH5b/gn7KYnQh/NL1aBu0+AA6StJMq2IPElAEnYPORcvh7DXofWzBNYxUjpanlXfB0cfQ P0iCvMpw0I4EmoV60W3oIeiNd9EJ9CXW4gL+Pn4Strfx3xTvQdvmoCvQ1TC2vg+99xjai47g GlxDHMQBveVAcbQYzu1Ej8DzD6JjeA7uxkfxi8wjimypuWwt28p/KZdRNeqCFu5GL8IzTuEs XANPYKqYDayf3aCoHb8O3nAVegAdQ29DO/4E/f4l+heuhu3P5DtkS3lp+fHyR9AWFQqgBjQf LUPr0UZ0JfoBUPUl9DL6Oz5N1HDlW+wriqsVJ8t3QN9G0DRo+zy4eiH89i1ApQNoFLZ34S1N WIC3aMDn4gV4Dd6J78aj+H38PlGSIBkgf2VGmDeYP7B1CkW5EX7Jjvzw3BBaitYCBb4DvX0H vO/j6BX0OrbhCE7BG70L939FppDpsP2QvEX+xNzE7GS/VtxcOl76rHS6vANxwGUzoB+uQD+C XvgC26ENcXwxvhz/F7R8mDzFGBieCTEFpoVZxHQz25g7mdeYX7GD7JPsB4pZiuWKJ7nlpctK b5fnlG9EVEoooV1RlER5VA/8sxq46RJoXz9sg+hadB3agW4HfrkD7UFPwnu/gF5Hv0V/RJ8D BRAOQpsvgqdfClx3E74dtl14L34Rv4Jfx3/GX9GNVMEWI3WkmbSSdrKG3ATbneQYeZd8wniZ lcwWZgi2B5nDzPssYlm2rKiFbabiFsVjyje4GDeTW6F68+ux8erx7vE/lVDJXTqvdHfpxdJf ykvKm6D9IkqhNLR0K7RyF/DgI7D9CDjxMHoVZPfv5Lb+AxOsAI534hBwQxKo1oxn4FmwdeD5 sC2GbSleBttyvAKvhW0LHsLX4xvwjfg2fJe83Qvv9gh+Ah+G7Wn8DGy/xR/ij/Ff8T8IMDFh gJtFEiUZUoQ3bSUzyDyyALY1ZD1s/WSQbAQKPUYOkiPkXcbCiEyKWc4MMLuYnzAvMe8w/2YJ m2QzbBO7hF3D3sC+xb7NvseeVgQUbYq1igcVLyk9yrxysfJi5b3KfcpPlF9zSq6TW8Fdy73D lVUiSKufw3sf+pbIyyjfwpcrrOxV5EMYF06mX7EVL4YeU5JFzDrmdubXitX4JCPgD/AO5iLm kvIPmXbyL2Y9XkJewFVMQNHIrEa3ojJ+kvyZnCJ/YW14EfkUx9jv4qfJeqaVKGW5+hvWxt6g AL1DfocayWZ8lLzC3MDcUH4eNSoexB8qHiRvI4E9TizoQxjVW8k9cNOvyEXkFtTF5hWn0UXQ 708oroL+nkq24WrmHfZB9BETIv+NT+K7QWr8Es9mw+QCUsRPgsQdx340hgdQP74LSfhZ/Ec8 ijB+nHkMzyU6oNYI0eN6UH2/ZIL4HUaDumkbcYTYcCc5SRYzzymPMQWMQUr8Gl2NGZwF3pn8 lNBlMALuJFGQaW0gTX6Da5ET3QPy/lTpOSqxFe8pbgE+e4hJogUoi3rIG6gRxsZHsHWhm1Et egZ4cBvKknvRteUhvArkfgfIT4JG8cUog7UgLR3Qti2gL+ykCmRhLzz1XyD/fwFSfw7+G7oS CzCyjqIYS8/cyraBZOoD+XsLbKtQD9QeQHcoDyl+g+ZhB0KsUHoQuPwP6ALQOf8Fz3ejJmjf MvQQm4RWCyCZB+COB0ozkQTbzegNTNBmaPNUGOed7EyQvHeXL4Y3vAh01FzQia+ji8r3oFag 3YLyDeVbUG/5ofL5aA1aWH4c5O/G8gFUh7YquskSRYLNg4x9Hb8M+uj3+BaQ2zPRByCPROxE f4XtJ9CiqYpn0Q72dyA7m8u3ln+LbNAfVdBDK0CLnkCXor9Bv81kjqJc6Vyyv9zO9IOG+hDN Lz9WDmANWlteB5L3OfQIpwDZM4T8ikckSWqeek7TlMZiQ31dIZ+rrclm0qlkojoei0bEcKgq KAT8Pq/H7XI67FaL2cQbDXqdVqNWcUoFyxCMkm2h9j5hJNI3wkZCM2emaD20HA4sP+tA34gA h9q/fc2I0CdfJnz7SgmuXP0fV0qVK6UzV2JeaEJNqaTQFhJGfjk9JIziZfO7oHzb9FC3MDIm lzvk8rBc1kM5GIQbhDbn2unCCO4T2kbaN67d0dY3HX5uv1bTGmq9UJNKov0aLRS1UBpxhPr3 Y8dULBeIo61xP0EqPTRqxB2a3jbiCk2nLRhhxLblq0Y653e1TfcEg92p5AhuXRlaMYJC00aM CfkS1Co/ZkTZOsLJjxEuom+DbhH2J4/uuHWURyv6ErpVoVXLz+8aYZZ302eYEvDc6SOOq084 v6nCj5tbu7aefdbD7GhzXiTQ6o4dW4WRPfO7zj4bpGl3N/zGCBHb+3a0w4NvhS6cs1CAZ5Gb urtG8E3wQIG+B32nyttdGGqjR/ouFkbUoWmhtTsu7gPCuHeMoAWbggfcbulI+Thytwk7FnWF giPNnlD38une/Va0Y8Gmgy5JcH37TCq5nzdVunW/wThR0OnPLlx45pxcki+npTkLzvQrpi0K zQJ2GBFWCtCSrhC8UwNNLmxAO1Y2wGXw6cZw18gqoMdFI+rWvh18Ixzn6f0jCpEPCTu+RED/ 0Njn3z6yfOKIUuS/RLRIueQMo8H5yfJIIjFSXU0ZhGsFikIbp8r1Qiq5cZSMhPp5ATLoPtQJ fbu8uzEDnR8MUvLeMiqhFVAZGZrfVakLaIXnAJIyie4R0kfPHJ08Y1tMzwxNnjlze18I+Pgp 2RqxjagiZ75G3m5pW9s4gu3/l9MXVs7PWRiaM39Zl9C2o2+ib+cs+latcr7hzLmJEq6cgA4f YUXoqVkhYL0Fy7roAfgqxPZQ20V9M2GoQRtHLK1djId0V0rEw8g/Bfx7/plfppUuHf0tVlTK /L9qlFMBA8tHsNA+wvfNrKTdmmDw//Gm0fJJepecfXPbxDuNNCa+XZ/yrfq3mqfbwUCD2QiZ s2jZjh2ab51rB2G1Y0d7SGjf0bdj+Wh5aEVI4EM7jjBdTNeO/ra+SfKPlp+5xTPSfms3vMRa 3JgCtU5po4ANLGMOdewn+FnyU8CNHHnhAFKwo+SnTzFIw9HCIYxcKqXiBThPEIPjSI0vwRcg Z4L/qmm86Vz+VFPHeBNqhjL/NSQ12aApaBIhwaARvxaYo19LCnQa0MJRuD8ET90E1pod7Jm3 pPO0Hq3vZv4u/re8YiO/0bqVv9eyy/a653XfO7zKaTJbfX6Gs+Gt7m1+ElMpAx4UrOICHn0w 5Ai6AjGDQU9cMbsdqbxN88wYmXmzYM6aJbPCPCs0Wj4quZsLUggLIdwf2hM6HmJCQUcVp3yw avlKZ2Ki4R18z8Bg4quewY4xeAd+jO6mYjGRqMm2bpK8br/RxovWiN/oXYLdNkh8psAS7LG4 lqBEAifgc911qGcAD/YM5Aq5WtBgpnw0EgoVggJrtvGcMhi152qRiUehKi6UWxK2e6MdORID lH3Oi3tfLF3x+y1LPsG1pV+dXHa5WB+8nFm3RUiKO0o//U3po5++s8KL2wHjuvB0H9AMzSqP MduZfYAJziGLpfVa744cMS+sw2YhUBxqflx9WMOYE+bNaHPuZnSL9paC0me2N/LNQ82s2jtX MVfZJrRVzW2Umrf7VBoDJ6CqWXiOZpZ2VmFOfWvjrHOWatdob1LfqLlRa1xkv8FOAs29zaRP lUP5pnQ8lX8We5AO6cpHD6uLupi2qJO7uLHA6zp1RIKkT8cIcrZRx+qanKPl96S4tjjP2etc 72Qyzi1O4vxOgMe86OeyTVITaUqy/amhFEkV4snsKNMumVht+mgKp/pElNPrdPl87lm8Bmxg ER5kNRSRGBCHxGGRlcSTIhkSsfgsaQX2tZWPHggUbaN4jeT3ZIo1nGQoCgCkhziG5/BJDndy mGud2nqZTHWg92CiY+zUWIIfp7SnjFvZvuoBPj41fqKHHxtoHhuEswlTkV6SSGTGTOYifIsy W8woTPGGFJb6hroGolSrNCqiDFYJVURZ0BYFZPJZvMhsMQb0XlwVmqIoelGDKi/gQl5r9vJe bKiCpFHZ5AUOSsBzgY0ggW+iurr6uuuuw4MAhQfwwCDqae060GzGPd24J4EGQeI8VQOvlh4t Hz/Ay9lhQ7FegJcdLX9yQEez45JWW3QK2qIDdi9IH8mtLWqAWPUxmmsg10CuhlxdpM8/+9ON ekQlpwxVRQr5+rq6+kI+AkyrtDmslWN1uVqH3WG3max2O2X1ehs9HjXBPUqbFQ6RGbeF687p vcYff+PzpQubxQjJRMTMyO6rz53iNWscRl5na+pfXdOI70nOm76kYe6Nl5pc11/cWjP9qiXh 7aurqpKN6dp8aslwPDAtcVPp9RumWDl9U8Pd07+He5pcyb7izF5q3VrLfydN7IuAbN89gvTl T6QWXbEX9xLS7Ntl2uV6wfaCfdT1iYvb7cPb3Xiebp6+V9er/9KpUDptzqiTsducLjeDaWL1 7MGMLcuOYo/kxUyWEKzUFVRJo9b+lu1D2xc2xnah1fMm0o7iz6WkoMO6dMY34iM+ME9YVhG2 dlrwkAUjC28ZsRy1HLMctygtfd4nt1PpCJwzyVs9p3rG+DHgPWCw8RNUxvBjcOoENjmKCHYz 8BUa6AGa96DBBDblbCET7dC6+pyS9nGkYAoVgCJ19Xj2u+/mYsGppmhoaHq6q/q79ZenHHH2 xdJv2sd/0j01HluxMte7kqwN2i+aGaFWytzyCWYhM4KsyEdaJZe519nj6kN91ncZhUvwAp94 i3bJWwzQwaxpnZ1XBVr1PXW0ejAWy8uHz6tO5z1Kl7rLcoG917HMeZ6bw4xayalVOoVtlnI7 uVW5VbeDv8n3Q/Kk85DlHfK+8QP+FPlvxmKG0aniOV7Vx/Wp+mFAble/yL1mPMnpWMzpbySM +hmAcEpg29Y6dTuZoZ4XWEQWqVeAZb3dst21y/Kw+mHNqOqQekTzc/IXclx3SmNVHeMw4o5x ROCGuT3cCMdym1krytpttK0Wc9Hca9ti2w3kY202z29YzI6Wjx2wFlk6SCw0e0+aaS6yNVrt +R7sEU0c96bKHvMUjXa83r7FvtPO2E9ZrUMqnFUNq0hWtVP1oYrhVZIKXkE1ojquUqp+ZLCx aDu1AZmkZM4aJEOngUEG3iAYmJMGbKAtUUNnGlr9rXNkqZMAqdMxPtBEZU4PZGMgXHhQOWOD zWMw9AZNxQwd7ettMNplkUTlFHAF7kENDZQ1WrueUiJMyEC3LJDoRxYJRxAHD9OGijopVdTD roKHH4gVuUqmpJmnUvNUzk3UNJWaplJTyzXJoC7aeFfRJZiKethlHfctMdFtUTpkxnRQxiSF vDlXa7eJwUg0AsJC+QFetWrrsptSAdsv7n3ks78fvu/V8a34cQXvWlm38AYy5c0NG1ZeZd3+ Z4zf/wxzb/yosSvcIF0H/ThSPoGHgUu1yIGm7Wdco1iUfPo1dcOuPS6ilBCnk8xao2RjJHV+ 2LbHRmzPYRHs+F8DjpHH2qkxuTebx2iXJTC0aVJoWc4q42C6pSUNezLTMo3mzIhchX3cMq1S mkZlTBVCyn8ATsniF6VPjE5sQCqHwaWPGePGajbLmc/B52S6nevxWuelmU3Oe/B9mTecHzg/ wZ859Xon1jiU2fYsU+esy84AeZONOiNZRulUZB0OJoHiUJuCGh1FZ8FVyDbXzqtdi65GG52b XBuyO9B2503ZXeie7BPo0eye2pHaNx2vO4/W/sHxvvNY7Zjjr86/uo7XfoX+x/HPrDgTz3K0 Z5bhbseSzMWOq1yvOl/Jvut8N/uR86OswRjwqEEpBTzuYFU64IkFq0jAowqG+IDHHgwFA54o oCinswphK3K6EHY5naPkdWlqNmPNOh3ZjDODM9B2h9vlchC1SoVQNhuNqbLnARBxZdJVghDc ExwJHg0eCx4PKoMPSrW4FhP4icO88cGa5X84G2GBYoVCE/B4CUDWhLptllNHEZuKW1XphGIz /zLkTrngrDAbpWXPAHxgAACrS54Mb9U140rCF51OU9HJm4tI5Sw6YJAfchQdWWuRojJU2UFx op4gNlmBZ3O24DcALQIADeOgTdZv/3EaM+3jpzxiZ7YUywJesxrmLMRD+HN8Ag9llgJ+Ezsz 40ezS0P28S/ZK77euDlQLYp5YZDZuCzmi4qnf8/K1a93nDmx4/QtlKf00HNPA3qLoYel9QIR jLWk1igRyXg9y0nVuLcaB+J+Z7TKFPc7bg5Fo0JLxB+djjTaapNV4DHrHFJjdZEHJdTNAGp3 OjS9SiwpsTIdqMbVyBQOBAICHhKGBYIEXhgRjgrHBIXQF3/0DPABYoBoGTwB2KKZEmBscKzH REkAyAbxX459jb+Ue31wAPVgW11ucujQbuJoN9lpN1HVT7uRjnguKuK5l2+qn5kPh5bazLZU 1qKfNrWUaK9yaRT6kDsQ1WAbs+9Xv2pNRuvarPELSrPmRj3hcNjOh0ydeOWec7zGcD/0ThJM kScVa5Eft0vXc05AME7vOXmnBImLJka/3R7nmrhZ3BOcUhLOY5epzgNddIlqg2mD+QHt9w27 THu1ew2vK153vOZ8H4bLceHf7L8dNhv2sS6Fx+ayuxw+J6d2aJ1aX941w7XdsVPgnC5CgMV1 LqWecRFACABvrJyF1Y/itZJaLQGn0V4fZXKSjle4d7rwbtc+F3E9w+TAFrrtICY6/yi+TdIj 5f+aZ+m1rLdssbCWUcxJFgleyo0ESRgSmD5hDxDc9Sz+N9hbeixJ1l6ynmwhO8kL5C3yIfmC qIgr8Ay+HWNUoVXHiaaxc8E2+aqnQ8YOQK8xUB1NzeMDiRMms4OCUZlshDc0beUVm182vAyE owCipzIAMBMsICRjOCUXqqsQE8hIuGAtQAnmyd6vj+PlWHjwslW7I6Lrrfsf+WN29qP/nopX rFva7saK0mkRT8P3PnHdo1cMHHn1neE1a35wqHSyga9JgbwWgFpHgFoa4OrfSTG7HhtRm14y MpIRV+uwjcNECRhBocSsTqtHrE7PKnV66FWvZOZUVo5TqRiWU+pUKKDH+mfxA2B7avFuSa/A AKiVSpWC1enYZ/Es6C8VXi1p1Wojg3cz+xjCjOJ/Sk7cLHevEfcZ9xiPGxmjUgKQ7zKc1Yeg ZWn/NUEHQvFjnlqpzcWMLH3G+PFBkEcmuQ+3phMsCB1aNBqNgMQGezAMFgwgLGQKFnAOMswc OfzI+EvkisseKYXxqdtL9+HVQ8z1X99KHhqXUellpSfxveg10F8LpWg36Xa8bGfUjj7XMRej BrzCskaVGR02Szot22i0BWxDgC1HcbWkDRh7jcTocj7w8ATlx3uoJjsh09chQwA8YAH0V6CG ZRV3BovTsXnZmgE1x2lFs7WmcU7dtDU7S08mq3Z2WvRqq7oxV9N+ee+a/dRynF3+hHka6MWD NfXMgeUqYRQrDygUNprp9e5RbJTMajeKSBEiRfoieyLHI2zERA8betF6tAXtRHuQArnEZ7D/ Gx6tcGjHpOIFy2guDofCVWGiJJgBFuBEr8fn8XsYpSViFLURp8sB6jzImlaggNK9AlsNULLr oBTGwgrsUUFi5m0rkEsDCVUBsoldLe9gHFny5nrZCjFZCfRDNFLPV9BIHRXqle4hs2/dsKzv gWvv3/abFS9dd+nLbcWBug3+dDZcjDdOL8zMkwc/wfMWtOx+pbTv89Lhuz568Z+lT/bftXxw Ly5+cv/l2eA5C0sPAD2Hyn9mFYpLUANZCqj5riQ2YiPRMsjIxlBckZiH5xG1qXEUpNWxuoY6 N+Nhe529rl53r0ep0CsMqPpoI7tBu0G/wbDR2O/vD/Rn+rPbVTdrt+q3Gm40bk08zj6e4836 nD6vL/hyvryvAAqXpFjBLwTi8VRuKp5KmtmsK+vPBqBR+XMKM/Uzqxdpl+iX8kviSxK+AA4Q Ty5Q8NQtci5yLXJ3156fOz9/fuH8umX1BkarjVu0nnhIKzROiWcbB82Dlu3he7l7M7uyj2eO xl6sfjVxtPFko/VcVYMHrSeeffgtTPAWjPEzAGrnSPrCfTVAu/UBj9//jI8eybvuswIhmnQG q05nSOiqDWxELWfKEB4HvBSrYUIxq5rsxZK/Ko9xIIIjozgk8RnTCybyoQkLpn2mD02MaZRs fTqw15/gqWSFCwK70/iF9BfpcppJg20tpd+CCoPSQjqbPppm08/hdlTE7dg5wXc9AKY7xgZP UYE4OD5YzCQqHEhdN2ZHZdhsNaQTBookEP/5qTHMg70vl3owPwBlmVnrwlnOEotok+ocihsj ORy2QMJloapJ6XJIq0smonx1DhsN8WrRHMohVUaZw8CXVIZUEpk/E2C0g+EGAF5Sr9Su1q/h VybYnm5qzyUQqFKKXXRap7HIZo3FHOyUtbuxKZQmIJxtoFcdfiJr2gqK5kKmnJ8AX4P0jkbC kUnbm3I686Ro7tl7/tptiamf/vSWOV88NyUf+Jnb5eNE0d11aN3m79Y3RksPf2/u8R+v29Tg cAc1iktKia17Ltgyf2puzubVl945/74P1Ypmfwa/fcd3+25cVrs66f/ZhlsX3fGbgiuQobKi DSzGI4BTjMiHu6Q285ANP2Y/bH8Fv65+2fe+Wmn+iwbPVLfZl9puwreqtxvf93ABqbbAyobj 7gB+1fa6m0gBPEvFi4hziCqtmaW2RcKsbZ7HYonFx2jayfax/ewwO8Iq2c8pvG+WdLt1RHfG ZKJemh7qfpkzEls4Z6Rz/rL9Ov+s/QF21oJlXc9TRxRiYQ+UjzY0NHS3dj2H3EwtYpGVqf2U /9RzVhX0Z/c3MqoO+8yiIUJEb0QjKiMmo1WAN3UL2K6GkpODkkXPC9jDQGLTOgTkUkByRhpV PrKbBiyxAUxtM8l0BblCebXmasPV5qvsVziv8KqA/hXKq728qeiBHQzUk/u1E8SvpUhDKZMc qFvnqKI+FLNM82iEoGPfuWTjW1veunrN5jcXFi6Ztvv65d+5aAaz78Gt+675euiRW378nX9f 2dL84LWvlf6052enbu2jGogA3caZO5GI/iAVcLQPqCFE+6L90ZEom9fWBxqFmYGZgsKtsswD mBkKzvOL0ZAqils4v2q6oBV9qlHcJlk0SBRdLqfSlzQYNFqNVhsUqGfNgEYwyMB+vBskBYtH yfOSaHa5w2Zzp2XYQoYgGbEw1BMiTPhClJa+yEtbvg09KYQZpxbApLNVVsYUx5wBn0Ah3uM1 mrxGtxfxJg/v8wKYgaFGHa3UtptwPzkUocKkcwSgKFcITrhMoBYtMCuNQXsgaij9LbXx2raO gaS3fiZu6W5OXDqnuIy5c/y3u2d4TaGBl4amdd86hHe11HqwOH7/UGfdXMKdW09E6M926M/Z MA6C+PqnVCw2yy7ly6tTeRSinO7QL1UQr2URu1CxULmI6/J0ebk1io2KITQUfMrzCmDv4+gj hboez8BLnIu9vaE+Z593o3PQu8N8u2XYNOx8FD9M9oUO4hfxz7mfuz5VnfD+VTiFnaDAzEvN twRuEYZCJ0OcScDPlY8jAfZA+fgB5EPUU5rlg7gvOBQkKMgHhWBnsC/YHxw+yyI7GdQHV/s+ BKX1c7uo5nyj5fcOWIs0kxrMRV8Now2+GdDhebqdMOQyPMoiCfWhfjSMRtBRdByp6QGCfnS5 +wY36XTj3W4MKAGG6UklRkpeKSizSkmpULZWtR4h360I5sEBGLCDA+MDPWBgUJGcSDSPjQ3I 5D9BXVwwTnEDHqAQdRDB2KEeTcQ7ix4YGIctRQXYdJg6I3jqyjy6ny9ODLpuPIAn3A1o0iYB SVnR97LnESwSZrb43g0PfILxU1t/UpOc4jdpQ6Gpq86Z/9D2FefW5/H5h36GlR++hw07OyKZ iG1jwD97xUMPn25Nb6JjZx7g2asVtwKj+aSptwi7bLsizHRmum6m6ybmJp3iPhZnUluCw8ph brdqt/pB/kHTSErNK3mO9Fb3JohXZXjKr7qjCj/l50YZlRQI+Xf7X/ATvyksOnCik8d8tjpu NilVnIb3YM8oXnBwZwqnRslXB3B1YhTzkj4Wx2ajib/DaMRh6kA62NeXl/PGxkre3FzJwzVy Ltm9wfywAVO3U6+h33DUcMygNLiSzzBKhpvQlBVPUQdoxlPyUGuC7OOeExXrr6kJMHDzuKnY k5kYd2YxarVHRFtEtMe8KGoNe7Es8qhPGqgG+9mmNCBSU6iQo9IrV5FmdDBSooAos+Vs+FGv OHXh+B/jsWmuAwe6Dg1c1NWY9ztyswOBSFryfs7MHX90qCoZDsemryDLZjZt/+kV01MN/kLw UoulZs2702YCXVaVT5DfwhisYdRSXJ10JYnZnJa0xWRMW3Rau3XLIvfzd4YVGk4T08T7cv25 oZzSmBvFgrQVhugb+jcML4dfFn8Xejf8fvJj9uPQx+FPk1pzc7IneVlqc3In3kl2MkO2IfeQ Z8i7PbUzracoT8OodUqvJvla1eshlZexW81eu88V9yR3qXdp7he+F/peWGtO6GPJ2cl5ud7c VfGrkjcbHg/ty33CfOzVxVU1fvQ88eMAzgCkGsWJA+j59Ch2S6Zqp9/1vMfvDrgx7xbcxE1P up6305NVZnM4pNeyxqicKfz45yidqa5BSCFWc+7vgEimA99qz/hFs5a8acbY/Fbww+AXQSY4 ylglbT+1hfqNw2ALjeI6yRV1u9IBFVYld0cx1QJDUUaIZqMk+gwWUC0W9s+ZFM0US8mieZy6 IMtB3NNdzMDYPFDGUJSNkVNUWo9RHjpxFsgCvacJh0Jhvdaq12snIVd3BXP1DH4LdU2CLm8s HhB4k5ILmIJerIyrvEjg/V7ExRReXImpXUeDIDKYOs19xX9lOh0DMAUSgyKpLsm1G+8mu5nd 2vv0w7Zh97Bn2Lur6p7Q7pQONG4CD8iCpUvSZkKZ8C3J+8P3JxU93VQPm2KCq6iOuYpY0hQJ 7J6K/9NNB5NLU0zDoaS8q4s63m9uNgg0Adl0wFOUM1cxXHEihyqZDjKQW0mnpfJb5spvGcF0 k8zwCHMxKZjpPScloxEuMxYZXg/P0dMfOCmZ9fAcPVwDu9Mk7/8Zkvn2B8sxGsCNMkqUcaNj UhrS8KIpRzUjRY3h6NmYkQwHI1ee375ECPTe8cbzVyxaF7Q59MGg98EVbUuXl/6USt1/TV1H zsSbdcy+0mvfu3h2qiEWT89Y+YPNu/waN55x6+3zi20XDDcWlw7c6zAanLI3q3xC8RSgjSRT td+cpq/tbS7YowIvmMSokO5NX6TuT38qfhr7l/ivmI5ecMBSkK97zRPIB9Pp+Ko6n8sV8IT4 NKuJ+CLJSDGy2PGY4zHnYxGVVqwP10fnobm4g5ulmhFuj3bEOuLbuCF+yHSbuC22LT6Uvo+/ k14sPssfEY/EXki/Jr4We198P3YsHUAKFhQD61CLXFQdU8YLjla+1dSpWMAtcS6Ib9fu5Lc5 t7u2h7aJ2yJDacdW9c2OrRFGr+7GV/JXmli1WgWCTBQ1mINxzDtMfl4IBf0Ciif9yKgx+I0B l98fGC3ffFAVi4Ku2ixJTjEsqDiVmgvHY9Z4PAaCUIxmVWqrSqV22pwuW1gjWjUaMRQOZ50u q9PpikdCLqeDzmPSoFjwWfw5EpAff34wgI0mWuORAX8uaYxGng8EBAERehCjJFwCKtj5LL4Y oJ4KPyoZYxI0FuSoVvjaeKEGRM7+p46iC+OhUaySbJIn0+nCe1z4eddbrg9djOuOcMY5ij1P C0YR8yIWqU7R6vLis5hHEWQDrKeTNJneCJYiQxECJtznT6k3RzOqZ7AHHueRNAKK4aHYyRiJ wa2H4NbYHo5CRE9nHA/FMYrzcSEuxUfiR+PH4ly8L3UmHjZ2KtEz4HKPjZ8AmTDgPOUec/H0 kBsOwGnnCfcYf4rucjAeNjeNlDU30eDZZJS2Uh6riKGtiorMAdnjTKhoQTFZmDySSIA8Agvw 6P895XhVk6qp4nHGMkKhA66HYpRDEepxpsP4IOQWGn71UYfzmcxKs5MHHEWRZja5tt9WPGMt dFuCNgrvHRYL9VJEC1DlKnXZxJPrOMTgEAa+0+MhwLIvv5J3Ru1N+KmZfqvq2IvWaBEHl8ZL v4p/VPpSLH3ga2hi7hRZvzeQHP87/vHWJoeBEUXGwYestvF/4NN1gsVPRFF/0defkVnjTzNk Vk4PeK4JDDxOcTvSoir0e8k1HMZ94f7wcHhP+GRYIYQ7w0SiSZjyRG1tXs4bGit5KlvJQ6Kc S2mXO++M+y2zq/Rxv3l2KBh1tQj+4HSdS2cZVmJlEaEqHWcxa4ap35qhEqC1wMgCsrnAXKLT 6V36sFNKFJ3yRIK6xvywE3c6cZ+z3zns3OM86VQ4D4QO/HCCdxIJWf+cgryCX5rHBsFwOMtr XZGRPYBSBr8VAJINBuq3rpt0/stu63j1lCnV1U1TvuOqaSm1tqY9as7v9sYM2Kq4nZ5oqq6e UgqOC0uK3nDY3bQYL78rKbgq3mo94MX/hn6sQ/8jZRqk6oKmgdpbRtEYGWoYbmBHGo42HGtg Ekrc2dDX0E8PSQ1YUEF/mUYZo2SqSsX90dlVmrifh56L+yOjjEFKhwrRdEveX5iOhWgdQr4k y0FzTSZe43KG1cMaPKLBRk2/ZrfmLQ2rkW2wFAqG04FUZ6ov1Z9ih1LDKTKSwijFp46mjqXY VF/9o1vkHpwIR49X8onxBUZxk+mM8TUBA61ur0KlFD0Rr8LlxZzKzfkoEKQzFCgUpBMToJeh q02yV1meETARGpB9cROhARoxOBMwODte0LH++pZz+z0WgyYrlabapFoNE5ierbl4tq3YXmo8 J2R1GgNuW8aAzYrbx1dc3bbkfOlHpeeWCk6gQzTCn4un331BJj+v5L0gHQiHLZqGJcw535/p 5kOUMjqgzD8BMeZA9jUWgDKqAqVMttBZ6Cv0F4YLihSLJbk8BLWRgnKkcKxARgq4Dw4cLTA+ lT3uN1aIFI/7w7OrVHG/YXbIF/eHKkSqiVa3ZP01070oVJvj3EnCAQgyGg0ahz3MDavwiAob Vf2q3aq3VKyKEskTz/nC1YF4Z7wv3h9nh+LDIBwZKidJXA4VW+35eF++QqjE/zuhzE4Xo2RF F+PwYoXSqXBPkoniJ5BiAxUxhv+PVAJ6nH3wGxrl8JyH7pizTrAbtDXTSlMsUk7DtnRcuVFr qJlTmmJtrwEKeaNGbE2QsZfmLGm6trRpacAl08c4D1+5eeD6kq/H7vOEwzNW4UWPzHTTYQPy Z3r5BKuAcRNAKZw+gjIgTmbMyGdoJ0xLpPN9mWvZaxU72KHMvszRDCdlhjIEZezVtsRixWLV osTdHDeTw0KmXjNDs0RzL/tY9Z4MdzRzMkFAPwpBOplAWz4utTUJ84QLhNWadcLVwm60W/gR d4R7tVobUVmiuhaz3zLd5ovaW7x+3/QA3KZlkzYkgpUcSOJkMsBoA0gb1MleD7Otzz5k32dn AvZhO7F/Fu9UyjMj0nmaPz2joGxNt1Z8HNTOGh/soe4N+NB4zSAQzeSYkFAT4TWZbu5IglVF xYgqLqAEC0mMEwVcrUgKaGJWGfV1NFBzGcyuAWp8JRKisiLPzIDqCmfodJYzxES9iRP2MPl5 69Dsu4//62eb5hkFpzuhx6aUMWj3pLSlk2ll08pMV9t5I+vOW9N+zulXXsEzOp6ojJ/Tf3xI dou8jt+b3l+ct/a1X/yOYr2Z5T8rfqS4BOWxKC3SsO1pAtZFjPBO3kWEOqmur+4qVb+z33VV 9bBz2DXiHHFpU5mN2q1axlmXdnfW9dfdyv6YPV7H6pibtUfrmJkqf8Dj/O8qc8DjCIbyHjSK FQeJB+Nn8EEYvnOkRM19SRqcVsaSjCFWpcaJgL/KZOo0D5uJ0TzPTOhcvy3mspk1m0fJvyRe 09QZwcZIAPDKrMKqHRPWb8f4Vxk6ivjxphOy/89czDSd8QdPDKK8kADdL8ai8Wh1lFHqImHR GDRNwUKAN3EJTQrpQ5DwgmEKUkeVKawVDSlUAeOyB5iGJqhU7ElQsUgdGwPYEqJ2sECJYZ70 SdGQ80S8GSgpROVJVvWVoUkvYT8NhQqLNv20NL514O7/Hppza0ugZQHRu871WS8/vr105Zu7 lqw+cNcbszetb7BYPIziktKiPfOv+OWPv3ipdPSuiIi3rW4ORiJ58dLS8qmNXz//z4MP/+yi pc64LZSjUrHUzpwCtF6L10lPqnmzttmQuCtOLPm0fVXdDYqblEStVphVLpVbnbC6I+qwOQxM 2oDrzAXPDPNa9VrNRa7V7pWetcmrVJs0m1xXujd4rkpu12x33YvuVd/jvjvxLDqW/0gZAuic SCSrqzVYBdDZ4rL6LShZ60dmjclvjqgEl9udrdZY4YJkIhFWq6zqRDXcUu1WsxpVEnIXAGJV yGIG+xYpo/KcFGhtNBMq+ox5h8PtoqDWs1ODP9Sc1JA+UIZfaBjN5mb1PHWvmlFvVo1ig+RL vGsUsFHYLRBhZ28SZ5LNSZJ05fJPBKmQTZxLmeNEz8CJ8VM9p0Azjp/bduH0j1Fzx/iJREXe nokjqM4CmBNBwv8jnvwGQ+IByg0JC6X4GaBXmXYASJADtKc8a04dJX89jsjYUIeftKVSwQ9/ aeJUVQlcLcacalfplrp986fMrc8GizGNf0a4pfS0MejiHTnAgFFftK1Ui/8nHjOrtXpRZJ1B Q/PXl920bXqyOmc3Tu3eTQ4G0iEdr0MMndfCfqyYi/wogRpIt5Rdhpb5t6Nt/u25Xe7vR/e6 90Y/df81+peMrgFdHd2Uu692V+6R8I9y77nfi74X07CNo+QvB41r6hqpFPRW5Wku/ZfNkc9J wSQkLn++VgrFIPH48tPD08Xt7vfxu+EPch+JHBvGor6WZ2xKj9vqt4ftMVs2XdsWnp1firtc y6J3ExOP+MbFeFm4r7G/cahxT6PKnXXXdiKG59xhf8yVYZWE8Tv883LbwveF389xQqPU2Nm4 kqxk+hR9yj6uL7tRebn7ck+/f0P48ujVsRuVN3tu9u/MDTX+IvNB5rPw/4Rd3arKzJjKPJhc GDFsEhUSgTBTFW9I5ph0VaxQUNvjMTCtSToG1ptqmAayAL02FuRsGs2GDja35Gn1YGu7nEtW OD6314s1/qyXeBeziUBDsoae4NsKZondwxIEyXGWkYMhGr0pj1gs0Olp+O3DySre+GCx8Tn8 Ngqi5XKkC5i0qYOGuAAQtHYdQTVM6lOPnI11g+RpolPEBsdkzDv4zdRlkHBj8uwARyW47Zic ytySyYdiTj/m3B6XhyiVIOaImIvEnJEcznA1ORzyR3JMHtfkmCjgFZxVpHNI9FXlkL+WKeRg NIKsazo7BlJd8dOAehqkQu9MgARR68k+Ed4IfntSNDA7PS7Kfoq6ygRT04TPQoaMzIHb2pcP ffjR+FBusejw0bnSsx9eefeD145fI/YW7/jeuS89s6pzw8Chny55aefULg95yj/t/JsuPLJY rAsNMuu+E0yKzvDTV65+yMhxzdd3XPm4/fR6zw+vmnfHIlZBNRmgA8V+4P80dh5BWaBedSaf pVQUwnIuLbJ78zFlo3KucpORFUNitDZUG20LtUUfiXLxaDFKOrMbtNcY74u+EP1XRNlkUAU8 JFgVCHhcwarqgAcHQxZQbUGw7J2EYCLG9OrqOJ1YZQbJKOmKKqm5IKiyKgKsTZ8nNBf4LO7P 7smOZI9n2WxAqDKbt1jwegsIz8ypH0xEPOXoCY22J74CKCDXqEJrmtBAQOI58zftr1cBoSPB mMZUFQwFidIoRsWwQQDtZYro4qC6NEEeDIaYVqQaDE/MOqaElLEiIA1KwjNqSg5PgUySkeI3 2ssqhyYnaMq8jY/nOhO2+WNv/unjrNBG6ZVfFHb55u5ce9OvO7zRDkVUFFsDA+MfvPnnh+67 vvtLYt58rigWwoPj++e9OTh7w6H3iLhFSFLqzAacYQScEUanpWlqPw2IZ5hM4G7jLv8PjT80 HzY+bdaq/MBbeDNzje0q+23MDvv3mbvde5lnGbWOMbDEN5PpZhQZFW8Ky6jikIwqaET7sHCf IuZl8Cj58JApMcJjfpRpObRTv1tP9KNMRorTyDXCGNfye/eZcMDUbCImtwRDX90kOLHRGXAS 5yxx1cpJbEEnP3xFQx6nBsZQ8/gAaJKPm8cmwQX/ujzqBJtHqeNEd0QbsYtKjzqFdDZIVC5F Cmsc+tQk3puwrCo+dkvFv0cmwYNDyVbwgjlc0RaAG9i3A4GpHz+09YPNG8fuvfEXmwKrSyef Le07suMwbn7+ezurzR6rWwsYIffW4e2ldz4cLf1jeOBx66HH/+eZr9/Ai56dabd4stDjC/EQ 6SIO0AzNkkAUQ75VdVsUMNYJGmEYRHjcifvwMN6Dj2ElHsX5Q2iIXbSMminjPTSKl6E2uTzl ElRdcCFRjJ8mjnso0qeY8SqgpQ550H6p5h7z49wTmid49kq8iduKt3Fsq0ofQ4wtplQ7mwJM hiEg5hmByTISo2Bm+SbWbwg+yUd8piZeLaiJUR1QE/Us71lE6OAHJldvTMZ3a7GHzjVxRywR g86UQh7sTGErByW7Akq8Rp/CLgKJWWVLIQdrS307tguDoQcLdMlGkKb1dXTRiEmeaGI28dEI GcMqfEPp6tJnpU9KN/zhhX8evmz77ZcefOHf2y+DDl9feqf0Rmktvh034dY398/a+njpudJT B7fhatyCz39yG+XzqaCFR+j/FqDXpcZleBlZ5lvmvwRfQi7xXeJXZYLNwXnBexX3eB5XPOrh CPb57QEPH6xSBzzGYIhzhlCA8EZVcJQclSyAjZHkMDSbjfBznWgfYtEoiT2tUlc57IGEXwZQ 9DTy8/5e/x4/63+GxJCdgMhb1UMJeaqHahc/KDZtgV5+QGvMJxLdiRM8mDKnZDc8krQF2CeP fyy7X8abqAh5nTK67C+TMS/Iif+YTUllhpILWdiHjBGtJbBm0QueyLzM+It0auUPe2P52VyE V8wtvbQo3Fh/+tTknElWZ7CsOx9Ppb313fIJvB69hLQoIXmRpNQykhpMezVI0l413q3eBzxx k+7iq+nLyG4iRBlBPHvaL8pI8jzflyqzfTMS5VCKhRIyFZL43CMoDT31vcZCJn2Fc4Nng/fa WH/6Li+3yfl0+JnY7z2/934QVrqifDoWKYrF6JRYNr0selG0Pz2U1r6KsNsb987x/s71e4/i 8Rj+Rfh9xwfh9wExfRZWeqWQL6Yy0Mm3VTjg4YIhACC2YAj5hGS1L9YcmhcioRBnq46BaiQq TmVGbh5wj+Tudyvcs9ITAwFUlpQeSZPd6aPpY2kmncRVRsODqfQovvJgkC5okvHCNwuaOihV IxXMEKGYYWLGJ0UIPWAIFc3FSTeCNxx3eJ1iLBJ30EkwXkiiruocFj1gO3yzymnWok0S768K BkJT2Cq/MAWGRwBhWQOhhCy8Bgbx4GSM/j9n3Mra3z5Bk6j9G53P4Ye9kY78+LO5JaLVAwof //3wr4d//1rNYEthgW/tPTNvXJTrJNeUrhgKJEWxIbCBWUdLcw5c/egxwwyN5qGhrnvmWIBP TEBPneJ2VE+mSGVjMVAkZiWP4fs99V2aYe2w7n7jfab7zfcFdhcPajRFV9Hdy/eaegPr+PWm 9YH7ifoz/1iADKmvM7zKvGr8lHxqHDN9YVY1m5qdzYEGobnYbhzUXGFUZUg1L4hCJFNswA08 Z+MX4wX8IoEN8UvxUuPH/Je8YpZpZuAl9Uua/9IoHGo7H/AFAm1kmlGpNRkterfOZ/QbAsqF zGJ2oaKbX2RaZFG6jD6fP7CQsLwRE5PZYuFdAbfflY77o9EqDVH7NdRJGA3VRTMtBX/ddJRB WgvPh4WAVcBECBh5gBHEijEB0SUEJKMFs1Fi1PC8U1OPkIMuYJnr1L2p1WqUMExdLqdGm9UN 6chJHT6mO64j/bqjdCaAw7HbiZ3uQBEXg+E0CmcyKM0D31GmU3Sm8VB6OE3SfQ3FUXzVwSCd WQx8NzBIAcoYDypxkE64pIilZ+CM66qp4sR3UdajjAemFeBX2aIyTM76pgVEbasJf65sT1XS rfTcyxxH5yUPDtDZA4MgoekHDaABeQkEX/5EsoKZGIiZixh2nwT0jxmLRJZnRS3NTEVjJVNX Mrp8bb+p4qRHicmJBj3YJM9unvDKKznOYqeLnigvy1Mw5eknjv/NLOh5n87WqYIRfPuCS1s+ +2xFVTbsmlpqjXhipb+40h2ldHvIpjUaBLet2oR5xe1f9/92ulmns/qIIJD0lPdLv7smmDFo wmFsszhyeE3pWHeDE4fDJq0jOJ+ZtnuGxxTqn1hBuRakVgzl8QvS6NYqbL4p8krolRQzK/xY ijgDjvTqMKPGajEizkBdeD1ZH74GX0MuD1wubKy6StyBtwr3pp7ET4pPR55LlcM2pXAjvjV8 Y/S+8CP4YfJoeF/qhdR72S9S5ZTejOzYTcwxkEY1jenG7OrwRRlNtYp4vdhGdVEVEmMeBBDY EAyBivIGQxJJiuFwFcFWQL/hvUQgXHX8EY7nOrk+jqHrdQiHPHu9+VH8XclYG/P5vMRoMADi UJmDlC5dBZpJwXkFFNwXJPOCe4IkeIivw1Jdf92xOqYur6qy2x4sLD+CXejMGgO+Z/AU9UhT mZepyLzMhMyb5EBgQXOxZzBDV2S53PzYGYPeXHQDE1f4TZ5IXZN1UqGYqvGHAmIqlMnhGj8k 6apkDoXCWaGWTgGcmPr3zcwImQ/F8vEDOjqH5eQBazFGF+hZi4R30eLJQ3wxy9OpfxMcB7wW DOLKCrr/i7TkMLAbrp2Ql8BqirWlu0uFnKD3897I3IIsN210USn+23u/3PnDJ7Gzb8f6r8+x eNUvvbL7BjCOryYYlzZ+W3o2P3HF5tFI6Zqbu3TkTvz49Vt2UwlaDRL0KeCtHPpCWiwV1niv 9N6ffcK5N/ts9nhBtcTVr+zntqi2qIeUQ9xO1U61Ohzw+IJVYsCTCIZUQYMhoPaouCAhAaWH 8/IegkMGo9GXQ48k0jQiQVKj5DfSzGQyAdj2EZ/nE6/Xp1LvVamUe5u5LRxBwCjzOIbbmN6b TARSGbhhnXuv4JE8H3oYz8LOQn9hT4EpIL5KDD+YP34Eb51chkzXmIyd6jkx/lVPD50HSgn/ ORhJkJV6qP+Pev7Gm6j3hh/7HPFf4kpGNaDstjMF6XjOmSogJii7VWU3eX2OqdDlG8JQfA4l vBdXb4jmlaJoMJgXLC69y8caPr58bXZqS+yK059lswnB4Q4vyrI2Y9SWq41dqCDjn4TSG0qx ld5QrNSyLOoQMlM3l/aKDl5ayQxc54+Jpd9d0mkzVnSZMsvsQ0vxdMmb5451f2FnhrqxqZvG MhJ6PNyNBZUQ9ztHyddPVdXH/TVQkLRVc+P+GbPlFSSjjOGpUCLuz44y+qdCLXF/OxSkqaHF 0Y6WRf7F01Xx+g6pGI+pECfOWLKUa0oqxKROo+WUrIKb0Q6DwKHpdjjcYEkFswLuF0YEIozi gmSsj6cT4YZsPe6vH6kn9fSYvWNpS3ju3EBHZwcZ6hjuIKiD7yAdMJIPW+35jr6u7lGy7CD1 vY3iVTdRlZE4MyXwFA1znKhkTRN+ONmF3ix/O2TdMTHlpIjOBEAmY1VVYZ1RL4YiYV3Qiw3G KoN4dqwK4EgCkAkGQsqe1v9NwGpCjMvzljjO8U2w8Mxh7qxI1rdCiDncucqcWptbcq1tze1z Zg0E7XpN3TmlJsuUoEPDeqJLCpfMJcTW2F6qmVvUKoLJeXWFhSkXDaE017rlcGMlhvL5KmOk elXvVXPmLG68trRxiWAPhMMOeYXMjv60VJipTZTmyNEuUAgL4FiN5EvWl2zL6jzhsGfKYnzB PcmgHJoE3jkHwK0RcJAN3f/0sOOo46SDccjzx9rzNJcai1Py2HFAv6qu04ElR6ejz9HvGHbs gQs5XdzPza7Ccb8yGrJG9S0Wv3W6DSFOqUE4rNdN/Exl5XdhSn5Yhzt1uE/XrxvW7dGd1Cl0 B+xnBWwr4avmpm9CtD14QJ5Shgfxt7t0Uote48rPKDU3p92GgNMdM2GT4vbTLUsafHIElpHu nyGH+RAp/7s0m3kGRkgUFTErfUczhc7JLPKz+PP47Sb25iSekmyeMid5XvJi08XJy1WbTJuS N6oe4T5V/Vutz07pynXn1+VZaQrOqJhY3GyBseS6ucpCF2CFUDQ4L+pH04k5EWPYNCifum66 biYtGrQup6G2JqAZpq7nIc0+DaP5TCAWefaDIHQG+4NkKIjppMzKRExFsK/xpTmTq4ErM2Dp 1Egaz6Pxa8eZ+DVjoD69porXIFPg9CoxH9FFsmKBqxVwRg9JTl0n4BptWvgPr8EgAKGeBCPm bJMz8Th5SlB0sotz9rMCsIoK71NNM8HdBLsjM3bO23H+wLb+H82ui9U6inNKgqs+arHxIb9T xHm14dKFq6bOP1/qymbCTHHw3U3L1934ztj9W2zGVOnTC3J+UcR2bc0qZkV31mnYUvrR+lBj 17mrj/x64Fynmdpay0vtXBJ4chpahP8oXfwoerTl8xYGuZCXd9m8na7F3o12DvMo9gn6a8vx JV+1sV2dj9oetR9bwgqdwnxhQa+TDSIBgwyax65FF5I1vq2I3YR2oNMtzH5Vy7RpuWlo3oKa aS0EsVrWXT2vJUfYVg8aZaZJan4qnroWteJWqD09zdgeQdM477PMNHi+h5lxaO51df52EJjz pTquPZ2v0yxYwzbU1Cxeom2vbnb/WPBkQQMxHveSYoNx1tAsMutxS6NQla2Sqjqr2CrX4iWj +P2DwQcuAOFWLwu3Huq3BTAMVtjYKdniGv+I/rPAqTF+/GP+I6A8/2XPeM9HslQzFyeWc/Gv b+UNFQaYMn1O/TmK7IyZ7TPbZjLKKY1NjUSZjKhFW0QQTWI4EhP1kennzNqA5tTP8iFlhvUh VUq7AdsDwItXHEROnxvyp7HXA1hHpMckHzJE4YqZja0b8OyGuT6kyHI+pElwG5A16JDvcnkr uTlkhPwQ1sWNG/CZKWnfBLzO+lT+sWBAhuMNDfSfMJiJPwOoMxfyJByqYqkfi80JyJIjKFgV JgXejHK1rNkmr+GhYbDJyGYlGlbPUYk78SMVLK4YuqLFmxBm/fKOR0q/OfyX0oa/vIH738Ec fmJD47JSpPT230pr/9e/8Aun38IdP/nh19vndpjvPDB9xmXPP3D5ea3dfPClOR0DnVNmJBuH bhUaZjE/LQ0cvyosJO/AMw88iavu/7KU/9fHpW0vYjc2lv5W2vtn/P1/YRV+HeMnS08febq0 6+GZLQ3nHbx4y8XfxWsHFra1XWaZt+GV4a7meV1Pn7971bRzQR6dpqsmgMPt9H8lpU18BD+s PKw8xP01wCoiVDYJkSuYjezNzFb2UeZJFTeDw42qSRHrdOgQ67EjPoiD3YTziGqtvyagGFaQ PsWQYp+CUXymsyPkDOt0vL5T368f1rNDkIzoGaTn9YI+C8Wj+mN6Tk/D0k0FfZ/40sTC8zOK dlL2jNFF5yB5volHx1wCo+UiAuMXsFvj9CKXU6vzqqAWYIMCdmk9XuRTemS5I/9bxYR6RQNY jnoO4snVhTKa/SY4bbJ/g1uVeMpN99326x/c8mTnI0uMgtNbbcCWVO7S4nnf//6qQiFGvjry 97dP3TXU2MgcekCORo/Hxv9Qm3vthZHnPVaEy1+U2llz6T7EIOEIIkxU0iMjg+oUBK9hZ8wE GfslneYsO39wsBBkzaf/yIZK7YuQ/I+Ct7HnsT9DWrRbclOvMqAnNZtBgkJQZrTr0Xqtsk+J lS1GZj7imCjSQK5FDJQIlBBSQUnNzD+s1aI+BVY8DwdZhGjKRJ/GfSqselapHYU2uRV98Lhn BZIlEuknx4hCIJicr+u6oKIETtEJAid6UGbsBH+ih85nGpO/4yd6KkhUNEHbTTlT0BY0EUfJ gP/RiU+VdLfh/16A/14yLijRZcRoPnDb44q1yIGiWCflrom+r/hd1ftRdi27SbFZdbX6St1V +k2WK4VbVDdYNGrVzjiZolJEncGoU8H4RRZximfwSuTE0lNR+ucoo7hVUmfE9SIRReSniwIN CjyKb33K4UB65zN4KoKR8XTlD3YY8yi+UDKjuBQfijNSvC++J348zsbxM1hCQbhM0rygIRpX jC4V/OTMUsET8mLM8ROVUNWY7IUa5E9V/ldlYgmyzIzVnrDKpIvwojcSigT0wRXIZ6QLBFVQ ErT+FdhjgqRKLa6YYMez3ec9DrDSzfWT/2FS0YYE+BJPRpjorFngyXXXH387/v0tO99cfc2r j115x59efeinJGeetqmj++bult70/9felwe0dZyJz7yn+5Y4JCGBniQE4pIECDAYm4cNvrAN tvGBHYIFCFAsEJYEBB+F3HHS1G5zNElT223q3KkxxATbaex203a7PZLdNt22222c1ts2m82u m02TTRPj3zfznjA4To/9/f74/WHEzHxv5pvr+775ZubN8T5j9zBDOPd4+F9fnLz36Xue/ejX s6O33MScunV96M2bjx7+8ciWYmDzRRABGXAhE32RT+ctOy1HLectEmThLcwwuhMxuvo0HMH1 SImPIhdiKawAGObw+H+QHkdgfl0P8Lu8Duv1jJLBUqVCw7DoNP4A0FfzJp1OzxsrAvox/SH9 Ub1EbzWfZnLxBZGqZCEICCsMsuiB4LkBMhWm3e1pwg4R8r5iKTM3cr2I1zjTam+YZXYuylTJ PVmeZZLvfuWju+KLyJZBJrt0D/PLBwq5HAe5HWrf5d+z90AdrSgPleM9/Ok2jJXljvLC/Fj5 Hte4elxDds/f6hnPu6f8acuxrCc9U5oXsl7MO5P/bdW31f+szZQjFZZpmSxlfqbWnOXRenRN +LP4Nu0duqeRbjGqwU2oCa/2duAd+TeU34RuwhGmN++m/L7yvXhf/nDxvvKDkoPScfm44lbj raaD6QczH5Y8pHjA+JDpS5lP5D2f/3z5jGRa8Zb63zVv6d7Kf6usQK5V5tfAoHBRmbRBgTRZ +RJqGcz0zKtMWkKcNG12vRLrgTM8NQGADbiHN6AKvoIh28OOVpyvkFS4X4IAFuS/EOt5VcDM w0CZNVuDp/F/4rfmZBsaMAj3OxfeE7QrlWezIM1lRf4clzFTosjwOKXuTuSQZ3fi4vTCTuQz BUCMJVwnziHHXosySzqR31giSPXcuUJBrMkrBpx35divPHNu3zf4ecSVVNJlmtNS3S8Z3eED X2n/wdNf+/vosxPVa39x4pvRLaO49GZ+uKdnvKK0clPLff3RW/NWMs/efnTL7Wcn42sP77p7 fc/ug98fDSW2n/hpdH9zZGS4Odjnn/3dimM7b/nSnq2rqm8iq0YgE1tAJsrw2lNIRd95kJdq fK2mul7ZqFqhbnJJXlXigoJFBXxwZ/DV4PngByo5CuJ65Zh7j++Z3FO5p33f873hfsPzL75/ d73l0axWFIC6mfJ6DWiGuTD1WgDDvDV4kpUaMnHmDD5yMpsv8gezQU9NGbQF3jO4D6UjJfMb Xt3CjXPMIXq+foYtn5rQYM0MPgT+5GapQyVHyUsHtvxkB3m/IJ9h/o1X8UF8NHguyATRDF76 Ip92No1Js5Yv0FaCsnqHqGuwLgjdShHZ0EVenfvFc4Q+f06eSi+RkcXWXKfHKZFJPbq8PBVw 0y8pAb7qAXKq8zuxSumTAbcd2uxOenpUZC9dQaftNI52FxWlzQ3fM2ln6pzbICJsEaqgZ5zJ Kwhoy7RP7as5cfvjW5ed3j8++IXZtw90+Z3WLOPNZk9hzxfdWY6ih9ZzzUdW3bLzS32SNQce vKl5+wOHS6f3TtzyVEN+drFCWidTH442Ny3K9tbnqG68vbl37AnSV3YCd8kdbU4s45d/TYJN bTmRnDHpmGws+7OS+7LlFUyFczO7mdvq3GUflo7a72LuybrH/jj7lJJcsqZHbkxvIs/INCvS tQzLkkP/Rs6ZzrESzplls7Nyi0QKvkemOM6Zdhp/iCxsGq/RavGvEfNrpxN6VtLj2PDKk+P0 heEM/iNwzY1590434wZx+HDawByFoRJJhFdyvOGogTFYXafxg2KjvNBOXke3kxfPlJFCr0P6 Hco+0JOpvT1S4b0zPWe/Wzywqd4liZm6cwalg9lScvcWljvlEmE/w7zT9yJLyJ4dzI6un+1r w8ov3bH19g2J0T0xnzsr39+0bujE4Xv7X8IS6dpnpvMP3z2za3o8v2pTmb3I4AyeGNv7ek2J nNGT/nwb0PwEtCgL8qJ3+MIh5bBqRHer8ueetzwyGYv3s3skezLvMEtqFV6ZlHVbvVYZy3XA sANaxDSXB7pBD/31fVMWJCVqbkqvxYj0x25ysF+dhQr5QoYv3Fl4tPB8oaTQKtAXgoTzmoE0 Pu1Q2tE0eZq14MoB/4/b1126IJ7wf0/YbiB226nNUbQZFNs9SlO2PcfOyIwwK/Eo3SDoBlsn cuoAylXldWK7ietELg03v8cuFCUfZ+hY+ZXhY36eMWjKrSzHVJnNjR5l7EO3P/n4rtxDn7/3 B737fnBv6OUvYP3/7Lr0A9PKFeWrtx64e3/eVmmfR9v81e8e6Do/8cxnn7lhCmdP41Wz2y41 3LVp55vL/F97+Nk/cUS+bdCt/Y59AC1iw/xlU6MKH9Qe1B003pV3V/Cn6p+af5H/i3Kl3pen 8qhzNXHVkPq3ZXJ7jU+/vVLiq5PWGeqMi/LqvNXBQM1qdbOh2bgiZ3XeWm9TkK/ZYt3iaakZ ko+pxwxjxrHMMfOD8iOGI8YnLWfycnRSvUFv1Bc7DA6jo7hAVWD216gMNZuV2ytbaiR5FosV mnl+MFihUms05RaVUi635gUrguUVHtPBTL8RGyugiWRqsvdbW3JwDgzW3GPQGg66sdvq8fmq y0veLSjIL2+BCu6vwBVSqdxjlctzKzzpFRUeTWZ+fqBck15ergFyWpQac3m+x6pe5OcL8ywq VhOUV+jt2O5wFPv9vjQDsygHmYxGsgPPJynBJSU5OdkqUKuNJ2Ogjn2eGayb4qzYSnS+xlDB Wyes560XrRLiMaU3Ba1nmEpUjuS4d7LClz+DFVMwdCg/w3wTVaMaZt2U84cHLEVF5I0tTIiL 2ot2v/Neu3jio128F8hAttEa6FHhdjI2pBelief679LtF/bjEQBbTNX7/Zb/gDZPJtoXiAWm 3d9Oxtf00bDvPwCSKwy1utq7dIba/a+8QpxXFK/IwVHUkkk3jrfTqUxqRUl9+eKkiiwc/c+L ymozOQgG8O+nwM0Al1fajXVa3maosxBfeCAun2bW1UnJSXa5BaxKApENci+CW+DVk9QuTuur PZy+WkXO4+rJ1VvnwSkjKwVaCNBSH3KALI8jxgh+RhLvZ5NqEuf8pElwjNThbdpqA9TfCMbM m6oNBn21EUwxn1GdJhxFyRQcE1lbySDH0y7yaRnVlYqMam8gvboAjFGRSXpvSCyzuoA3gsmo LiMGcjaT3MGY5q2VffLv6kNreEEAOfySOqxGJ/Nu4fgLWVlLLaRBz5ZPZ/zkmbx0ryL9nA0f L3C61Zn1TatcebiyNLd08/4LrauqZ1tKrGn8nfc3lJTMvp5ry9t+7utrNixhH/DYzZYyg6uv rysrI9vjYS2u+JOzM6OlbG5uus5sbn/llR1GSz6TmytNzx65/HG0ioxvl8yuYP+FPY4Wo9Wo DYYHt5oyW76Y90gli0oMO5jhwuFNDCqU+WQb7+UkdVXNO2JVQ3mDO8iY9Dbz7ZaDFfcsva3x YNOdzQ+aH7Q80jwjOSV9wfyC5XvB7zWd2/HajvM7Lu6wZXEZ5YaK9ErHDumTijWVdTaUyVY6 19iQdfmV26yVaWnpSsW4B5vogax0TR1xeTXIzhHPcc9ZDwvN7jCv21Y07sSmI87jzrPk5KeA Sl3AdBIU06E1eA25uWgNEcA1Lek4HZrgtKJC9gh9BVbKa6xrVH4rbrGOWxnrN5h/QjKY3K5D tRCkksmtG/CG4mL9upfZAAqgHLCr0To2wFsMARwLHAwcCbCBimofO96KWz0OLyanwPhsc1bw oBc3ewe957yveSXeIW5HYAe/4ygQQbqDHldWa4I7dAcfWoFXlHKZWJ85mPlqJptJzkekPVKH 60oDbAvLtLCY7ANiyDmhKWt2kLjTEJONbN9xGt8MgxLVCao8isiLDXpJ5zvxC4Yi6OV3F8Xf 2W24QHZFGt4R79a79Fty016dgU414waI9A6Y5dteIEdnmfa2+HvvtJNlwxde9bzhIc9E94jv 4+auWErNTPc0ba1pzK2wZ5stWJrnKSstLw2WsrL6vOY8n6cwb4unFXTo4hw7aqpYx6FluI5D S6R1dtRSss6ONha1crjBssKON+dvteMtW7NrbIBuW4zWlq7hcNOaikqeWc6R3UGSWjte799g R5sKNnCo0bzcLswJUneOiFbRguZYSCcLZMmjnd4kSS8H5FU+ste7wmAi14VePGESL59I3Sgi LIZAxytzu8UJhUzoeMlvrksWdqpX0Vh4bgpNJxiy+U/wXNG6/YdHb9v5rSIdzIxZfdHIoleO NawsdjgD9sEfLWmP3fTYR9+8o0ltrJB3BIuqccaa7oZgy9rOxvLZ//EHarq/8cKz5cFH38Tr C+5vu/sVXipTmrNUUtmqwfHp9LzqdCMnl7BSpXZw4+6uL2wtq7RYPMuUXY5Sh/tG5q7hPYe3 LovvObJ92ce3lG/zBHKXjq0KZmZKZKTPv/ymfD+MaauZp3irUqaVaxTQw6pUAVm13KSzpFVr xDO8Uwpl0Ea294JrB5e/DEClssK/Rtkm2aZ8UinLkxUpitVejTfNm1VgK/Tml1bKqrOCgZWy BnmTepWtVbZNvk3Rptqm2Za1LdBaGpF1y6Pqvqw+267yYcmwbFg+rLpZvVezN+tm2377zdyQ /w7JZxX32O/23x04UPoF+SPq+9PutzyS9bDtAe+D/gcCTymeUT6jfibrKdvT9meyn/RPyacU L6pmsl4IfDfwoeJD9cfZH3Jr+vzhQF/pAaVkkS2aE3MMlEjC8rCiT8k2Kdc6Vnmb/JI221b/ Bmhi8hbFdjUrgVk5q1bbM/2F9gJHqbxarVTa7QqlUmW327JzchRIhm0oLSvdxmekef0FNq9J Y7SZ8nPybPnVpYts1TOXB6dsahU3cznGpwcUck6jVrtsgG/LsttzlCoV2fOaYbODh92frVC4 yL2CAX8pqH0SYg+UwmNpminf64UGhhi1SqVQyJWLD8uOlQLZJ/mKUmHLNd1CnVcSCAZKx0sP lbLNpR2lO0sH6cP50oulitLfK36n3Ki2ncxSn2Y4lIX/xKvJbcSvaVjNkzWLZ5ibppy77hHG GxeshgsWw6X36GaBoku/ndsfIB4uJcdJ6ehCKo4uBEAhArq/5TiprpYcBpAL2yPFP9ROV24w vfqCT/d6M7V1OcTiAmA5yKhBWNohsw7oNclBATcmx0LzU+dHSHvDafn5wmmB+Z5YmI24K+T7 K5blpBfN3umd/f7sD3Nn+0s06Y2L8fuWikXFWP2ml8vI0qZZrWkFjCF3UbAESzBTnJ2Zt0S6 1pMXdN/+0Rm26+MvS3o+Y87zeDwBl/szl+TMXfEdZXlpWpNCBl4F5WOXHMzb+wJmr0LnIWPq cpjE3Ez30u3l2528t8LqDBm7K4Xd0RaHzeR0WenuaKXDZnS6TUaGwQqL1aUcVIwrzivYy+S2 1RbFTgXboTineE3BKkLcoHPced7JBujtJixZTWPotZKg98m1BeS1tri+KKwGFxV55m+hyF+w Z5nu4WFuvnQm0Jpn0aocxYEA01i6Kc+qVXFFAahnKbeHjfY6rSYLhT9+gMKkbk6EJOQLUyUY nfD6Z3AOX+XprlRKlKoJP/tw0emi7xT9nP1x0VuSt1QfST5SKWHeKBuTjynGpeOyg/KDINYq ZSEjd2pgBJ3HaxU2eTY59+SSORmG+BRIbTIdPY2Q47DlOd1FxV6VQiORAoncMOQ3lyB3HvIa yHFr5se8B1jPwNQ6v8j7HCKHrQMFPDlUWHBIJnPIcbMcn6UvdE/yKqRz5WQf9s277ZxexENe Q9P3sCD8/9k+tzdCuOCadHhkXyfZHXEp5QqXE0ObwUZ6JzG9uMotErX8k0RPI+H48Q82N2s9 Hpzf2PABULk4UHrptEh94Bb7B607qzF8k5S59HZTbLaieY1ndssV+qd4MfvTjjYv4YLx8gX2 HZi1cUwNrzRtUm2z7LCyVjoyrnARHRHKqEi3pme5lS6V08iZci2clcuqUVarakzkptWarDWK 1coGVaOl0bo6K6J4TPGI8stZj9qOuJ5GTymOKb9q/Sqo2JcVJ5XTqmnLi9bTWWds51yvW95X vW/5KKvkiBK76KHonUHqFpUKbk6B4K5cKbj5+YLrdguu0Uhdnrfag3rXPhTHcWZQuo+7RXqH 8aBLWaMIqoKWatt3ZOecP8uS3606YLnLylaZVlmYNAs5O2XjxLNTM5fv5IuVWVbOYrUGlKp0 UNW2rCx6gkr4EoqEHrgSzk1lWdWWGZzNmzpU2KDKVR1RTat+opKq9ittZKnawMv8RxWnFD+C drZfaR3KIle7c0gpzN6U4tCL7pMrqyDOi5oKpDynZJQz+Oy0wYXHXQI1AIu40/q0oJMc8rfC CGt3/L120iCzLll+a4WGKp7yb49b3hFkjh7iJzdf3yUerZpTrdfQrILy3D03oyC7S4swGduc VHGgMxUw73oRXGWumpwjPz+ZJsyMVGnVCg66dDDifissTEWucR5L0LJkT0++ER+35xdkvP5T s0LtCuKiYLrbPnumYPZUptdhLIMpRh7nDszKGO2ibJ1Sr/Z4JMacFR//Jyut9BuUCiKn7OUL zFLp52BmsZFXIun3Hb2VCGOyNKRl2HSGYVny9QU1msEOPp1sd9/JDrJH2fOsjD2Dn2e+L5nB sRNvkMUicVJcR3slIA9oONIVMEtnM1rw29LP/WmL9BmSI9kR+GXQT43ou/zuwZVHV7628vxK SdrKw3a+sgVAxuSwqZ0uF9mg5wo6bD6nq9FhW0ovBFbR8yo2p9vjsJU43RUO2xKnG5J05+ba li5ZolarGF9JCYwJFKY0F8O78BsuTJa+B11HXa+5zrtkrhmG47MMK3euPLeS5VbilY0eV0VL cGeQCR5eQdT1OsN7VFEbiFwsONEsnLOjuifFXuHy5nbsvEqBz2nwK8rG+enqR4yCjzHDVLsH mAa6G0tQ+5deCoDav3QPDSq9qkMIFDkszD/j2/sERWQ21Hd//OAVrYS/PNs1T0ftmodGOFEA E8oo6KgM3MEvMikkFskRyRHtEd3TkhmJ/IgZa81D2tLKFrRN35LB2iRmXZr+RslG/RuS1/Ry 9L7BUJ+RQ66az+XLpNIXVDlqiU6vz2Ul6SwrYdWMRI81OrOW1TM6SYsUSwNajczQocf6AGZU +jPMUqRDEmYpX8xi3xEoja9FiwNaXjuoZbVZfnOdudnMmjU+dQXIH2PNNH9FeA2z/r3d694j 7/nIMYr32i8Y4Ec+5xGvpVaqUxAnRNBm79r/igUv2EVHXp+geBG0TfruRHf5NV6ZY6pjA2DR 025aAPQ8ecrNJNtwfzmdWS3xphPwZ9Pp1ZJBEwEPTZuqJZYMAv5+OgNAPQVP6Be+eKD3OrPO CuykAyR3lTMDO+lWPfYG9cc/Y3bO/iRUm2aTeGUsuvQoXh9pMhvU2Dr7u1y20OouWzPr+fgn 7mKuV+SY5EVoOxy6k7cZkIFsnsa8ayvTy4ww93CPcE9zpzgNKDv8Ob5c1125mbkhh4ExDOt0 ZVbZjEtcKnIyw805OHqDGot+ZzcaGLubYRXoORxlZphXeHWm2QXa+rAz1C52xNDnvkevOCEn uC60Vws78XGciL6ZvWobaEaeKP50Q2Kl5CFn8qPfpvZ8Mj3RrZxBU3Zb12Of6cMj8tlDnkVc kt1FPiLiwYX86MfPbXJkpPuGoK4bWDfOoidyNvA2lW48p7dSbSmsCGoWgTWj/nv1z9S/V0s0 oJlaX5SxOrM5S4lm2ApepdEo+9lxbevXqFaq9r+z3pA6LkvfnEHp09i5xSk5e7jSHCwpWZxV CRl69xbxNYsDns/P/pzQu3V2DbMPtGMaquHdDxmfNDJ3ag4YGdXDSiN6GKdhhFTKp3SuFhmW jae3Cmvm74gXBtLzPXSzZgY0dKbCgKoyZOSUlDmHYfZ9MXzoMVz2/t7D651Za/bPxjxrez6P 7/kJrsSXBwob/mP2oW//9Pg9Tz5K2gWUYQstQzWfWyApVKySspC5EQqRBqpaqYICCNfbsbLx jG1f+2QhcHtaBegeU4YBycl6M3QlPsb3cPjgY7OvfrD3yDqntWmftLuwqecLsyOvz/7DLB7w NL6Nd3379Yl7nngUMWg528tuAk5kohJ0K+/FSCexmD02h9elMKq9vGvabOTV08jMItYPbNDT 756Q9z+FvN5WcxS6sr/T6xy6cR2rI35KSc3xdJxu9cHgNDnlJOezUpuQSMHbxU2VdeuEzQZX BnriF01wxtwsvnzeqRnPtb3xim1rVUqttthUsGRN1fLoHcyOMK9Wa9TFmQVL1i1adtOd0l0F vu7Fbq1Ov6Q40Jjc3P18Xl7NDUvtOp1hcVHpqvjmyPPo8uUUFTCL6qEVPo6gzmRaxyDMFLIF 0GG3k5WR5bOvsJvovcp+dC+/5DHbY76n/TP+v/e/5Zft0Q2Z79HdYZZYrPZ8hCV6p6JQY5ku 5HPVwlXLpXX2mpYSrC9xlIyXsCWUgEfzcf7fLbiDeUpvDZTOJx25gvn9drJbhlwbcAH+CaHm U2x3+6fdyCz9FP9EuE6l1qoyMzMLa9dVLdt1F+7auk6l0mgzzUYgZGVD9I7ZVwqr25cAmRSK 2qLAqvjWyNdzC0vCi906rUKxtCiwYghIKX6dQPoz0FrLGZ7/w17dyzomivAYGmL26oYDoxV7 Ks+qTmsV/QibJI0+mIZVMpuZMDPOHOAPMY/wU9oXdKfLTy9/XfvPZVqTGrM6RsZIy+5Fd5Ud BqV1VPePZQo1IocApRqHMkdbiDzYryQH7D+LvhP8OXo3qFeqreoArmDK+WV8S+MT+HHmGD/N TKsmlv0Q/RK9hn/C/JR9G72NL+I/qi5q3tVaMsszg8GyQLAVP4Ie0D5U9mCQvISxycg9EE6X n36foLZ+ia0WxrE2qZ7eC+Gg3yhYHKyxLQa94NJp03U6LYgKeX/QGgimBwJBhLXBemljANUH JTVazJAXqXK5blB3Vsfo8uQSuTwz0/qcpXbxYq83f0lNTUFB3nP5FrNZJpPmM1JF7f0SXSDg l4xL8SB0qDPMIl7Da1u0zLgWT2ixdob58EW/3uXIOdzQ+BKupUezrWjuqBXZ00kuNKUjWpCU OkNq6cJw5Sc80BUJk5mefRFXMeZdKiCOe8VTCAse6MrEbrQ7Ts7h+ctL6v3LSpaTu4XpGwRV pQXGviouXVhCMFTzBh05fvD7SV01IqNhXepCTTTvQk3xDQPdV4Cx+BKevjzAf3FQZaysQsJb fOKnY8iF8t34vb1f33ppb015WsVsMR1X+S69PG9ctcznL3ZY0odwwVJbYZkDv1u8qm9t5knm 4qx+b5vM48m3WPKC+NXZpgXzP5dFGFvx3bOhtCg27PDmmN1ko2ndivRT9Du3oB8eefQtqeb3 HfraPyqsCvrBz6/+JvtbqY9/kj1j8v3kK9FIKX47m8aTO2cb0da5b4RitPBvuawa26XfRW72 PrSaqUbp4K4Fd4KBQHk2cjHPIK0EoWIwHPgNgLtGkkDj4DaCYQB/BeA0s9moG9LRQtxa8Cdx NGAawG8VgaVbkAtgNbhrAH8T9f8NWgppfh7ScwGOEcLc4Fcoq0ZGSGeJBF3+UH4jCoH7EZj/ ktyGPIC3AcxFMPvAbALTCWYbGBuYJfL7kA3SL4c0nSRNSIcV61cAaRfg3WgDhLeC8YHf8pQB HNA1aDH6BdPOvCdZKSHrHqdkq+QO+VPyDxSHVFrVW+rPa+7SbtJzho+MR0zRtMXpmekfZHxk 3mtZA/PzgPXlrM1Zt9gi9l/mqHJedbzD7XRWuZ5yt7lH3G/kfpV8WS1fm/9d7/7C24tHfPm+ B/3bAs8F/q30mbLbyj4sX1y+v/zlYH2wNfiryhDl0nK0HQZZAfJxXmSAHgHUgfSHegv4Edas ZLcjsqYjfPcViTBGOfSJwAzSYbsIszAZLxRhCcrBj4mwFFnwaRGWIRf+JxGWo5/h90RYgfKY H4iwEt3JvCvCKukW9mYRVqO44kcirEE9Sl6EtbIXlE+IsA7dYNg+J39jhmkRxkhvrBBhBsmN DSLMompjkwhLAOd2EZYijfF+EZYho/GICMtR1DghwgqUZrKLsBItN/lFWMU8a4qLsBpVZ2TP fWW+PGOLCGvZ7RkHRFiHfJbfQEmwhFBdYzVSWEo4Ys2msIz6l1BYTv2rKayg8GoKKwmPrG0i DDzK2irCwKOsIREGHmXdJsLAo6w/ijDwyJYmwsAjW5EIA49s60QYeGT3iDDwyN4kwsAj+z+K MPDIlS/CwCPXIyIMPHJdFmHgUcEUhVWkXoV6CqtJXQptFNZQf6EMOgpXUdhA6lK4nMJpAJsK N1A4neJ0UTiDphOjcCb1H6Owlca9l8I2iiOULZviPE1hB4VPUjiX4n+TwoUUfpXCJRT+VwIr hPK/TWEhrw8IrKH+RSyFaV2KaB31RH56imyoFY2iQRRGPSiEusDl0NNgWlEfhdehGBoAkxSx OGilMRQHmNgh8I9QDA58ohDfB1AD9Q/9X6bknysZhzZBSBQNzeEk6JeSB8T8SlE1/AIw3hag MupbDzGi4G6EOL1QhiSNtRHSS4CJo2GwuyGPCOqnfhxaD+4IxYmBXwjSJ9i9kG8UnuKfqEHN X4jNXRW/Bm2hOSfmakpKWoUqASLfnY5AfeIQkgDTA7kU/IX0Py21K7GEOFditAAl10H4n0/3 65RrhCfdENZPy74L/Eip/vf85MCXUCMCuSZpyQn9OXgmOEkx1c1QQg7KSeJzKI/mtw7sZsi7 h/KVlJDEC0OqCVr2PjE13zXKJMhQDPIlZRoE3NFPxQpT2SV4I7RUvXP5RsSWUUJlMUnLEAWf UZEOcVorkmox+Gyh+Enqz6G1lH6EkgO0TkRGy4FXhI4RyoH4PCqHUCdNmZsr3ZV2ScoRp9Tj aF1IaOgqOqZSTz2nuDWf4wIf19Lydos8GqCUTECaIZpunNakR6zDCC1rF9gk3ST1CdG0umma pIUN0HIQDpG2SXD6RJwEtIBOyqvdAAl0iFLadcJTF5W7MC3XgOj2zJOIEVqGKKRN0uqn7SMp ptpFKZOAXw9tZdw8nnZRyoTm6QyhbCmKCFzrpXQK0bjdC3ifoHkLksVR/nRTaIhSLUzp8udl IV+kUISm0TWvRXRS7D8vJ0IL+CT/5lNYoNGAWNKBOT+iRYao1uNETRRGN9NWN0C5NUzTjIjt UKCR4DdI46aoKkjRMNW+w3NtgtA6LuYdn+PQrjmZu7p9CXT469qYULtlVHIEuY7NlV+QS4EO A6I+X0hxQea6KfcF6R6iFBZSGqJ1F/JsoWmRFJPgH5qnV1qoth6gNBHac2SBNAs6cpSWLEpj JGhNo6LU9VE+hsR846K+I7VLUM4PLWg/pLSkxaXKSKSBo1Ip8IPUu4vquugch6OiHu0EE6Wl GxVrPER1rZDSCA3po6nF4CfozC6RN/0QR6D1VsDrpjmMijSar086adxdYlkFChEK9ILZQ3GI pMzXFUTWhT4gKYbEFujQbipfQwu4mEo5RHV6bF5q3ZR+g5QnowswuymF4pS2Kb76aD+fBPwa GD/4gQbk56NaY75E+kSt46f4/ZC6H+wk1QSkXOQpgTpo2kKrE/RjfK6P9M3F/H+b4wjlREon XsllPbSSVmj1K8Ash7ENgZvBl7SeFVR7EP9G8NkENhn9rIQevRF+66hvK9LS77mp5vU7n+xh Uv5983TBoEjl0TnN/Nf1sld4FRG5LMhWSvuNUnlN5UlqPDxvVDBfy6bKI7Sn/nl9WIi2BkGy BsTUQ7QUYdqnChJG5LxNzI20zmFR/3dS7R0Rey4hn0+jTGpMNiL2uKQtRebpwPlaXmhJPaK0 XIteMbFehGLhBZo01WY/mV+3qEnitOUPzWmMTpEz8/vOq3N8ndZqIaWEvuSTUvHJnCNiG+WA ciE6Dr8ySgnRfiJM9dK18ybU3yz2kUKfMvoJXgh8WjgmFDRhiJZokFI2ImqRv4bnnCiLKT3e Oy9foju6KaWF/ljo/ePz5gnFc9jxeXJ7ZVzy5ykVpVojcpVOv5Jeqr9MUPm7MipI6bwrmDHA FUbQQ5TiJP2+ufoI5Zov3f2ilhToL7SqQVE+rmjThTL052p0RT5W07p/knOpvlAY2SXm1Ubo abooVweu4kH8KnpfSZnUL0bHct1iX0LGHcIMJaUH/hrup9IT2mRY7E8X9oup9D7JR4FaQg2S Yl9+rXac4ljoKlr3/E2lvULlT+bQJY7fOsWn+SUKiz1hEvqeVApk/lSPhJmKFy1CQZgRFgBc BTODReAbAB+y85e8NdmMmkTMAISWQkhQhKtgDlFFY1WiCphREENS/9v6uv99z5gK819Fvbn+ sHV0MNwT6gpzT3OtfWFuXWwglgQvbnksPhiLh5KR2AA3GO3ycQ2hZOgvIPlJYtymWHSI+CS4 1QMQr7S6OlACVpmPq49GuY2R3r5kgtsYToTjw+Hu1kh/OMGtD49wG2P9oYGN4d6haCieyqDm qmBODK/ZEo4nSKZlvqpKzrsu0hWPJWI9yYKr8Oej0SAIoQEtm9a1XoX7FNcaD3WH+0PxXVys 58/Wk4uHeyOJZDge7uYiA1wSUDdv4lpCSS6Pa13HNff0+LjQQDcXjibCI32A5ptLCSgU642H BvtG53uFuYZ4aCQy0EviRoAZJdymZGggGh6FMsQjidhAMbcl0pWMxbm1oXh3eCAJZC0va+2L JKAspMihzmiYS6Z42ROJJ5JcaHAwHBLLSNCJS6olVBzquDY20A01GgiPJAZDg+F4MdcDOYz0 Rbr6uEiSGwkluO5wItI7EO72cdzqJNcHPomhzkR49xCUITrKdYa7Yv1hLjYQJukRQozE4tHu BNcfgwIkhrq6wolEz1CUFo3riocpDROQGikIVK03MhCKct1C7RPcCBCL6wc2cEMD3eH41VTI hwJF4uEuyojO0atpAgyYq59QYCjRACQ6QKB4bKi3D/jChW9OhgcSkeEwVDJMuArQYDxGigok Go5FhwkneobiEDtOKrSLUC7FLyjDNTgG2S0LJYDWMZI+0BLKMAByLhYcKNfNdQG5h7qSgDSU IDFbwvHBcHIoRGWlJRoaSEaAzxGBzCCRo1ws2s0lkqPA2q6+UDwEcSG1ZKQrwXUOCfwJdYcG SYrJGNdL6hG+uSscjZIKR0FGOyPRSHIUMh4ajALSSCTZx/XGYiCZUJZY/yiUemukOwyMHEoI ctIZi+1K0AL1h3pDeyID4YQgFfEwtIAkPMQECe2OdQ0JVSTIoWgiRtG6I4nBaGhU8OweDseT EVJXX18yOVjj94+MjPj6RUL6QHT8fcn+qL8/ORDqD/v7Ex1JwjqQxzhpkT4S+FdGHAlHiSTS KOubW1evWL28vnV183queQW3dvXyxvWbGrn6lRsbG9c1rm/VqrQq2nbmGgyB+6gUAOuAYiDM 12iytFYRqDJQi4jfaGyIxOyKDVNVIIgsSQf41E9bWIiLArEGAD3UGw+HCcF8XBtE6wsBs2Kd yRBQGLi3oDBEk41Aw+XCESqBgsgDk3qALFfKBdROxnrDgpASzs7FAyYk4xEQEUgaiim2zlTE HyZShYJWMkeKucgAh7jhUHSIqpRQIhFOzo/t4zZDi4SWMpqqBdRJ1IQghCEuMRjuioCIfLLm HFCRyHgvjRvq7o6QdgzNP077hGLiHae0pbrkqkJFI/0RUdIpHmmXiaSgk4nkUc/YCCjooc5o JNFH8oG0BHL3g0hC+YFVg6OcIKYihRZmROmxuudK5UgrBGWXoNlAo+kKxwfEGsTFclPkRF9s CBprPDwcgQ6FyMAnq0/wgJNhaKdiWyR4c3WEYkEGSWjlV3hMKhYSS91z7WRpkecidIF+6wyn EoJ8QskagrB5Uz10Kt5FwaoCrqp0ETkoEFAqNzeBZ6C0NBgEu6q8iquqrKiuqNaqPqXV/dnG SJ78YvFoO4TJcoxOM8m0gEwSR7EWhh43wRDkLTpwSYWlXv51Cy/u2EfZE+w32LNgTrGn2eeu L6xcX1i5vrByfWEFXV9Yub6wcn1h5frCyvWFlesLK9cXVq4vrFxfWLm+sHJ9YeX6wsr/lwsr C95+XIFDFP9aYW9eFSe84L2IMPK+dppRKuHzniU5klJJk2SlZAnY1QtyIDr401JZT9sM0T1C 7fvwBP4Ki2i7qAesOO3zSJk+PYVrw6vFuT2ZjxCdQJ7IccKVMLZLzVrI24VdADXQVrFSnIuv AriR0oxIQos47xbklsy9N9JekuTlS+1pR5edkOQ1/k5dPse+OdXYWMbPgFvko+6kt6CMBkxm 2cu+wb7JPAezAQd4vDGZaaMhv5pctkwEKhcJwFRhSdkb9Sr2V+i/wDDsr9g3QJZprCmvr+xi vRY8MPsZpMcYOdBR9l/RBBgG8ewvpnLzyo6cZX8A4f/Afg9KSqJ9b1JrLIMEv8u+iEzIwU6z J8WQk1M6YxmqT7D3IYzOgf0amPNgLoKRoBj7JBoDcxDMcTASpAfbAcYPppn4sM+yz0I5j5Ht 8mD7wcTAHAQjQa3sM+C/i9jsU+xNyAVxP0sO54J7L3s/db8Gbha4XwX/HHC/As/EPSI+fwlc Ev6o6P8IPGeC+7DofhH8beA+BM/EfVB8HmaHaLyk6B5lE5M5DkN9DoRzYAJgWIAeAOgBIN0D hMFgY/Y2NkpzOgFuGbj9ggvk2j/pdFMe7Z8yW8uOAkn3A+n3A+X2A+X2IwkE7Uvh7BNwSth9 gLMPcPYBzj6gSoBNQH4JclwCbAMYDgwLdE8A3RP0w28JwE8APvG/HexDYI6SJ3YE6FgApTrA 3jTpdYCQ9U5V82V1Z9geIDXP9kxZs8sOXnlSqogggqsTXT3BDdPQ8JRSQ3zDU1nZggtYu+p1 bBfaC4ZB6WDnggmCaQAjYbsmc/2O0+x61K9AvM4xxoyxY5IxqSTQgE1n2TLUokAgkia2BNUC QoGjoxZX7VQOKseVLPl8XEDJK1uU0hg7xh5kWfLJuTq2me1gpeSElLymnBxUXimrKT+kPqqe UJ9Tv6aWTsjOyV6TnZddlEmFE6Etsp2yQdm47JDsqEx5SHZIzuxUD6rH1axBzakDal7dopY6 5Pho/R1sJzkuAbYBzCCYQ2AkQOMO8OfYG8F0ADc6gBQ30rukbwTTAdgdQPkbgR8dSApPesDT A54efPXgqwdfBDYJaQGzE8ygGCqbC0nFIfgXSQiYfAjVgS85oHAe7IsEArMGnrTwpIUnLWC9 xnwMJTSAzYFpAcNSv/NgQGrAToUFxPCdYGQ0/CLFSYXxJC7zMR/KP1eAJwrw0QJ8qADztXX1 ZbwLLJPJ1OHu8HR4O45JYu6YJ+aNHZM0u5s9zd7mY5I6d52nzlt3TOJ3+z1+r/+YxOF2eBxe xzHJwbXH155d++paScfa2NqxtWwVuYtisihQRl2Xh7gnJ61ZZVX6+iXMcahOB9hHwLwBhkV6 sB1g/GDqwMTASJnj1Pd58H0efJ9HzWA6wEgh1vNExYDtEMOI/xEaRiASziwIZ6Hyz03WlDfX rwW12wHmCBgW0n4Owp+j2AJ0nPpPgH2e+jeL+EepP8FygEnFI0pwO1V326EZbkd1YDrADIKR olfZregNMJA62A4wg2COg5Gw2+G3ld3KPA+/55jn2GJeW5rhQJmZ0H2YjApDvYHRgCxo8VPU fpjaB6hdR+1cXrdG+/4a7ctrtHeu0eYDwHih89TiB6jt5NX12hfqtc312oJ6LaRmRk6kZTKo LSM2fpva66ldzKc7tR86tf/t1P7Bqf2yU7vbqV3iJPHs0Ia1TDq11cTGD1F7DbXzeLVD+x2H dqtDW+XQ1mvxYQy5o2XUzqG2jdj43Rf0DXqkPIPfhX5Xy+DJ2gLHDIOogy9P1taDMztZuxKc S5O1h8H502Tt/Y6X8IeYdm34/cncC476DPweXi0hz/8tun/Aq9Gz4F4EtxfcJ1At9oD7tcna Wwj+4xD/UXj+KnIpCP5XUAuNdwSvpv5fFuM9NlncCbl+abJ4FHJ9FBXTXL84WXwBfO+fLD4A zhcmi6PgHJz0kALeNFlb6Kg34l6UyxDcLuRhSEnWijmugpSj4K4UIjdOFpNYDSSDGbx80l0K Tj4p5UvYjVpodo5JN61kNnLTJOzITQttQx7q6rCeFl6LXNRVTLpvgVRkL3guOD6oPUMqjv6I 9ZOHHb95Ceq3BR5/jVdPPuv4x1OEXJOOV4tnsGfa8SP3Gce3c2fwlknHueIZBQScLZ5h8EnH CSDyBOAyeNpxvLjX8bybhh5zQyiw+khtieNL7u2ORzzwPOm4pfglUgzUDzXeAsFtxUsda2uf dazwzGAI5mshM17lqHHHHdXgvWgGr5561lGaO0OKEoA0np12FEKOeW5alM1Vp5kKJMdDfLE8 Ke+Ub5FvkC+Wl8tL5Jw8W26XpytMCoNCp9AoVAqFQqaQKBgFUqST+2WKyBm9dJmBODIJsSUU NjDEZoRDpQxWMNB2JtLYJqZp0zI8YWpCTa3LJqqKmmbklzdOLCpqmlC07Nh2AuPPtcHTBHP3 DEat20BAidcdtgkT+aIZxv477rMRd98d97W14aaJc12oqZObeH8T1EO1YfuE1L3MgjKH6yx1 pqXG6hUN17B2iva8izQsC27ttGRPPNS0advEM9ltE2UEuJzd1jSxchN3w7ZTzG4m1thwihkk Ttu2U3gPs7txI/HHexra5tCQixkENFRLHII2hVwEDbnwFEVbS9FATF2NDSdcLgHpW3g1QQLx +RZF6hXSyoUsIK0W4gAak4NyaVq5TA5BA3kQEtPPT0yDsJ4mptcgmpidIJ3weACl2ENQTlR5 AOGEp4oGP3sl2O0RitOGPDQfD26j+WB8Bccr4IAUiDiMAnCufSvq//IvvOxvQMZToV92dzWG 3Y073Y1hMDsn7h3us0yMd3Lcie5fkgBugs3b2dnVR9xQeOKX7nDDRLe7gTsR6rpGcBcJDrkb TqCuxtZtJ7r4cMNkiA81ukMNbVNPjC1vWpDXgbm8lo9dI7ExkthyktcTTdcIbiLBT5C8mkhe TSSvJ/gnaF5NG5fhppZtJxRoWdvyGwR3ilGroD3stDnblmUaBpfSxrHYafmM7bQEQbelLmqb 0LiXTWjBkKCS+pJ6EgStkwTpwFsvBlk+s9hpO42fEoMM4G10L0NFyNIYaZj7TyQSSWKGhorA Tg5ZqF8SGq1zU9PEig3bt03UTtQ2TvA7G9roDTVD4t/ybbzhbO2rtUysdqz2YO2R2uO10qGh NvA2nXW96mI6XDHXmOug64jruEtGAm7YNs3XHnH9l4sdAmnCSfhrbKB5DoEL/+QxOZQgfwgy SIARsisaKlq+rd6FumDUi2GEXoLSwLjBlIPZBEaK/g7sH4P5DZj/BiNBt4F9P5jHwUwRH7aE LWm0RBpIjm30M4oWtmwqUFG2aAbcUI/gbtouuI3rBbe2vswC7mRduapeDwNwjE6D/Q9gfgHm 38H8CYyULWPLaOJDgtS2JVCiCEPxyW0ESWIlipKY3OuDCbmTiaIilBBuD8bAAfq9sIVyj3AC JtsJBAwBB5Cob4JEGyJu6u//AD3UkVsNCmVuZHN0cmVhbQ0KZW5kb2JqDQoNCjExIDAgb2Jq DQozMDQ3Mg0KZW5kb2JqDQoNCjEyIDAgb2JqDQo8PCAvVHlwZSAvRm9udERlc2NyaXB0b3IN CiAgIC9Gb250TmFtZSAvQ0FBQUFBK1RpbWVzTmV3Um9tYW5QU01UDQogICAvRmxhZ3MgNA0K ICAgL0ZvbnRCQm94IFsgLTU2OCAtMzA2IDIwMjcgMTAwNiBdDQogICAvSXRhbGljQW5nbGUg MA0KICAgL0FzY2VudCA4OTENCiAgIC9EZXNjZW50IC0yMTYNCiAgIC9DYXBIZWlnaHQgMTAw Ng0KICAgL1N0ZW1WIDgwDQogICAvRm9udEZpbGUyIDEwIDAgUg0KPj4NCmVuZG9iag0KDQox MyAwIG9iag0KPDwgL0xlbmd0aCA1MTQNCiAgIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+DQpz dHJlYW0NCnicXZTLjpswFIb3SLyDl9PFCHxsw4wUIeUykbLoRc30AQg4KVIDyCGLvH3h/z2j qptEH/a5fDaHbHvYHfpuUtmPMDRHP6lz17fB34Z7aLw6+UvXp4kW1XbN9IH4a671mCbZHH98 3CZ/PfTnQa1WaaJU9nPecJvCQz2t2+Hkv+Dh99D60PUX9fRre+Sj430c//ir7yeVp0lVqdaf l5xf6/FbffUqQ/jzoZ13dNPjeQ78Z8v7Y/RK+ECzt2Zo/W2sGx/q/uLTZJXnlVrt91Wa+L79 f7VwjDqdm991WHbreXeeW1stIIBCAwyg5IrligM4gFkDCoDkgJLZdoAXJhDAK2MIawJTb5hg C9hyhdl2AGcAb+xgD9gzNdrROVewTdOnKAD0KbkSfUpA9HkF0Kd4AdCneAPQp0Cjmj6WCehT MgF9LOQ0fRx7o49lB/QRnI6mj4WPpo9DHaGPoAOhj8OBSLyfDYA+DkWFPhZFJfqgjkQfHK/Q p2S26EOgT8Fs9HHoTeL9sGi8H2gLfQxeF6GPwSEKfQy0DX0MejP0MbgfE+8HMYY+BY7X0McR 6GNR1NDHMkH0IdBH0LWhj2Vq+pR4YQ19LA7E0EdYJ94PY+gjLLr4SK4RY3MCjtfG+dlw3j7m ahk9fC0+B7u5hzDPND4qmOVlirvef354xmFEXPz5C0lRCQVlbmRzdHJlYW0NCmVuZG9iag0K DQoxNCAwIG9iag0KPDwgL1R5cGUgL0ZvbnQNCiAgIC9TdWJ0eXBlIC9UcnVlVHlwZQ0KICAg L0Jhc2VGb250IC9DQUFBQUErVGltZXNOZXdSb21hblBTTVQNCiAgIC9GaXJzdENoYXIgMA0K ICAgL0xhc3RDaGFyIDY1DQogICAvV2lkdGhzIFsgNzc3IDcyMiA0NDMgMjc3IDQ0MyAyNzcg MjUwIDg4OQ0KICAgICAzMzMgNTAwIDUwMCAyNTAgNTAwIDU1NiA1MDAgNTAwDQogICAgIDQ0 MyAzMzMgMzg5IDcyMiAyNzcgNTAwIDUwMCA1MDANCiAgICAgNzIyIDUwMCA2NjYgNzIyIDY2 NiAzMzMgNzIyIDYxMA0KICAgICAyNTAgNTU2IDUwMCA2NjYgNjEwIDc3NyAyNzcgNTAwDQog ICAgIDkyMCA1MDAgNTAwIDU2MyA1MDAgNTAwIDUwMCA1MDANCiAgICAgNTAwIDUwMCA1MDAg NTAwIDk0MyAzMzMgNTU2IDUwMA0KICAgICAyNzcgNzIyIDQ0MyA2MTAgMTgwIDMzMyAzMzMg NDQzDQogICAgIDQ0MyA3MjIgXQ0KICAgL0ZvbnREZXNjcmlwdG9yIDEyIDAgUg0KICAgL1Rv VW5pY29kZSAxMyAwIFINCj4+DQplbmRvYmoNCg0KMTUgMCBvYmoNCjw8IC9MZW5ndGggMTYg MCBSDQogICAvRmlsdGVyIC9GbGF0ZURlY29kZQ0KICAgL0xlbmd0aDEgNDIxNTYNCj4+DQpz dHJlYW0NCnic3Lx5gBTV1Td8762u6r2ret+7urt6mZma7p6lZ2WYKZiFYRkYFBGQlmEVAWVm VBDRgIoiowbirphXNO6aMLIOaAJxi0YTMGYx0UdJwmOMyah5gphEpvs7t7oHMeZ5v+/vb3r6 bnXr1l3OPed3zj3VVw5etRyZ0GbEIGXpZYv75zenwwihNxHCtqXrrgwb3+euhfQJhHS6Ff2X XPb2aeEehPQfIcR2X7Jmw4rQIXERQnwVQjNjK5cvXnaHa4OAUG4OtFG/Egquzm/QQv42yMdW Xnbl1efbPD+C/DDkX1uzduniTa+v/AVCF18N+RWXLb66v87mgPoXw/NQ+PLFly0Pjn7/BwjB I1DtW/1rr7jyJRQrIHTHL+n1/sHl/ZNeOpmA/CmErPuhDMOH/pkgydE8YTQsp9XpDUaT2cIL Vpvd4XS5PV6fPxAMieFIVIrFE8my8gq5MpXOVFWj/5/9sd9GIjtD/QaYu5AfocLv4XsSvh/l pxXOsKuRlF9VOMHYYbJixW/pL462oBj6CN2DjqAceoMwqBOn0TykwR7kRQQ3oelYQG7EYgMq QxKajnqRE01D/43NaDeqRh/jLnQ9jqNZ6EEURTORC01C30G78JTCn9H16G18KXoG7n4SKyiJ ZuDuwgdoNuotHIRnIDQB3YsewBYkwhUDlgrvQwtXoK3oMPo1KqAF6D52F7TSi85DlxcOooXo LbwAX1QIoKnocvQtdB96GP0QncS34KMattCH6tASNIi12I7LmBsKT6JG9h39/sLLheNIgPoP Q6t/JbKmq/AJUtBHGlxYCbvBjmrhczl6BB1A72EPrmPakQVl4Vk5dC3azZRBH7vRNhjbYbwR 72YshUdhNA1oKdqETuCr8VESYd9hPytcg2wwviz0dAg9in6MXkJ/gda68BzmsnxbYSbQqw7J qBOetAXdjH4AM/cifF7GPI7gqdDyj/H7+PfM5cyH0PITaBSdRv/AZfhS/C3SRm5ga8auL+xH CRihAm1MRReiNehZnMAKvgjufZCsJ98im5gDzHuaMs2nhcbCS4hDGah7A3oaxvVz9Db6DaxX F+7BvybfYvayNxc2Qn8zaCWMYgt6DB1Cn2MW67EJO3AY1+IGGNlGfBT/ngSJROYxS5jd7G2F DYXbUQRoJYeWw52r0I3oJnQQHUN/QH9Bo9gHd2bgzjbci2/H2/HL5BhzIbOQuUejaO7RPKN5 UXOGtbIv5t/Kn4BZp+1UoR745NAKdA3M9Qh8XkK/wwz24xC0NBFPg5YW4RX4WrwD342/hx/H B/BP8HH8Z/wp/ifxkNvIXeR58go5Ro4zQaaC6WAeYt7URDS/03ypXTwWzB/Jf1owFuRCbWFH 4cHCu4VRdRUCQPFtqB2oazXwwy1oB7obfRfmfB/6GfoV0N0H6uck+gzW4EvMATV5oUdRLOEk roTRXYjn4fV4CN+JH8Wv4t/jk/gMQcREovCpIPVkGllIbiB/JWcYAyMxk5irmXuZXzD/0mxg a+DzDLuf/Yw7qY3r3jyzc+z9PMpfmr8nv7NQB7TIAeXZYc9l0WSguWmwysvQAHwG0Tq0Hubo GpjxB4FydqM96Hn0GnDvY/B5F72n9pd+/gwrcQqNoTwmsJ4s1sGn2PcqWJl2oJY+vBzWtvjZ iG/A2/B98NmJ/w9+GOb3LfwL/Db+AP8Rfw5jQiRFJpEpMKJechHJwWcRWUquJ7eSffD5Ofk1 eZf8gfyLERgrIzJJppO5hLmFGWKGmX3ML5lfaRKaSZpuzWrNTzRvwci72ansInYpeyv7MPs9 9kX2p+xJtsDdyT3CjXAfaQ3aem2vdo52m/Yp7fPa97QFXRLoqQd6X34Om7sTX6TJkB24QEZg 3D8iVzJvkLvwM1/jhEPQg2VoERlhfki+e+0O5g/Ms+QGhDQd6uWJwMXeRC+gN9m3NU72I/QT 4kOfAD+8i1lMfkTuJx5cz0zQ3KR5E7jOBujn98gHREt2Q42/wGosQhdgL/ofzVz0Kcz/MXYI 5rSLvI+fIa+SaUDJ76BHyfPofrQLLccN0LtlaD/6F/oOPsSE8QGgu03oOPorOvFVbzWZscmk jfOQdVwzrNAhPLvwE1Je+Avs+t/jm9C7zL+A9ufimTiDHkd/hFX/Fc5iUZPX+NFbwPlCaCdQ 7Z/QXtiDP9XEYAd9jg4xWbRAcwLWPDP2er6DvZK5EZ8mk2A53SrnnkW5MfDg+4BXUT5qQbuB EoCLqDv6L+hnOAqz+Db3O/QA2o4OM04UZx4jm0mBeU0TRnegE8wMeOp1wJ8COAstXYYuhXGE Cx/mH4UWVqFG1IiX4AWoA650o1DhMuj548CLlMLCwv3sfFZGP8czsBMdAe7lgVm8h9XnR6Hm PtiH76JufCvam1+GjoJc8eA4rgFqGmXXsTvYp9l97I/Yn3HV6GrYtTthFf+AToHUCOOlMBcf oy+A1ifD7qmE/TMJetENMmwNmc/8ELVjH+oHHlgGfHsyzMECWMkroJUb0G2wnx4DGfJz9BkW 8EL0I/QO7Bw37POl8HwdtDMdXQCrfgV6HLjjjXgvlCxDIVQB8/QvbMGN5Ep4HuWz9wCfPQp9 eg99CJyjoParEk/AHbB6S9EXdC/DE+pRL34OdRUOACXMRB3Mm+i/UQyk62TYo4/CfX1AGxYU RE3sHzFBlfmZhUZyKfND7AJpaAGqmgOSfSIegF7wMI4x5MSzUF1+CmoCGbsZ9bKPKYrS1jqx ZUJzU2NDXba2proqk05VyhXlZclEPCZFI2ExFAz4fV6P2+V02G1WgbeYTUaDXqflWA1DMKrs lLr6wsOJvmFNQuruTtG8tBgKFp9T0DcchqKur9cZDvep1cJfr6lAzRX/VlMp1lTO1sRCuAW1 pCrDnVJ4+GcdUngEL5g9D9K3d0jzw8OjarpHTe9Q02ZIRyJwQ7jTs7IjPIz7wp3DXetWDnX2 dUBzzxkN7VL7ckOqEj1nMELSCKlht9T/HHa3YjVB3J3NzxGkM0Onhn1SR+ewV+qgPRhm4p2L lw33zp7X2eGPROanKodx+1JpyTCSJg/zsloFtauPGebah7XqY8KX0tGgW8PPVR4dum1EQEv6 ZNMyadnihfOGmcXz6TOsMjy3Y9h9zUnPV1lo3NY+b+u5V/3MUKfn0jDNDg1tDQ/vmj3v3KsR Gs6fD23AvSTe1TfUBY++DSZx+vlheBq5af68YXwTPDJMR0JHVRzfcqmTlvStCg/rpcnSyqFV fbA0vqFhdN6GyB6fTzlUOIF8neGhOfOkyHCbX5q/uCPwnAMNnbdhr1cJe79+JVX5nGAtTuxz Fr6UMJnPTSw/e01NqdVpavp5Z2cW0x5JU4EghsNLw9CTeRKMqZEGyxvR0NJGqAZ/8zHcNbwM VuTSYX1735DQTMvp/cNsXJDCQ58joABp9K9fL1lcKuHiwueIJimdnCU1uD6eHpbl4YoKSiLa dlhT6GOrmq9LVa4bIQ9J/UIYIpg+1Atzu3h+cwamPxKhC3zriIKWQGZ48+x5xXwYLfHvQUpG nj9M+uiVo+NXnBfQK5vHr5y9vU8CSt6n6jTOYV3i7D8vuOydK5uHsev/cnl58fr086XpsxfM C3cO9ZXmdvqcr+WK1xvPXiulhu3t8xg/KaWIn1GvAlEuPFuZZuaZhjVx+OdUol42otUBVaol ONw1LPR1F8P5hkjk/+NNI4XP6F1q9NVtpW4ON8tfz0/4Wv5r3TMNMdBhTYJMn7NgaMjwtWtd wIGGhrqkcNdQ39DikcLmJVJYkIYOAVpJDvV39o2v6Ejh8K3+4a7b5sMgVuLmFOg9FEvAB3CZ Fk3eR/BLnHaE0Sl2xGpeYpBBq3kJI6+OY18izAt4EtKDsJqLPLJwumWsZaZwqqVnrAW1QVo4 A0F1VcQascYhwEiDzoSZo2cUFn2JwpqjVJsFjKNdCbpbPZ6lDIYEo63NGML60MYQqWrsrO9t fALkJBsP1OP1aH1gffBmtDWwNXh/8Mngx8F/BU39jScaiWgT7aJDiAlxlrfxdt4BADuur+cM 4SCJRn3hoC0aTTcHE9GoMRy0RiWxORiPSplwsC4qjRRuUdpRMBCGQZcF/I5AwI/q6xFKBUOO YDCEcH0wwIggRevrCCaJeDBgs+oQamj0Cz7sazUcM35gJEZf40jhqKIPhLJqhyC3WdE7XdnG kFiWSdNrVnotfSJNjqaPp0na29A4gufsjUxc5xnBlTfJ8sxTuUGZTtxMQR6UT+cgmWvxWm1N GQ9MJf2jIYYCm7tJtzUts9cJL0PsUROyR1b/qqtwLjeYGwA8NiBjHHFKUS2n5ZxWh8tVW+uM 1NXWNNQ31NdZASJZHW4opGWuerUsm0hIUl2EOY77SVllS8zLG10dTZVjLcX02D88Y5+x5gtz +SpLamaZkcBFmVTgnzPfijstEc/yMzeszCbjkI56VjCjX8qaN890LnPXtMXjWMxmjBcxCy6p TcYRoLFZhZNMjnkJEFkY1ynzONt0R86x1rHSudyzwaGNG54ATPm69S3yFvOO+R3n35l/mA2b nDiq2J3ZucwKZm10PbMpeiNzs+Vj80dOfYWu4MI6vV5GOkEX1jG6HBt2IdzlGsFl+/wJu5Yd waG9JqPeRRfCWONtcyneaNZ1KYL8AcjyQIaQ3Gu0ZGmseKx1yJeJtkUXRT+NaqLhch6LgI1q BFoJ6qtxyFaME1VZGismkyV7XMCCN9L4bY8MuyBHFwRW8eRMIXdalgfknlFZhn0x2jZ6CrZG C9Q4iYXXB6qr2jcoIWsoGPe4vW7CBWxiCPkcrhAOWf0h7HZCgGQZy3KFfD3OyWgghwdwxOV2 1dbUN7g5ToomE3VZW22NS5tNJBN0yZ1OJjdW0C/oXNyypDE6Y2TD8dVzx57+9lufSHGnlI1M wJ8fXnN++4Wundfvuv7Ix9j550cevlq01c7fKcGe78l3Me/C6lShiWgGflSZHReMfFtlfKv+ ltSd5fs1h/R7yg+kP4t93mEw1OrruCZuQngmq4t74uX6crFR7BZv091UsVP/ROqJdqPSHZsc MZd7BMQ0a2OO1nJzxtRK58sHE9iq2JpalUQy26qERAicnmxVK6aX99o82dYRRqM4HQ667I5g w70mUzBDGCVTnWVGmIBiglmpvjej7UwE+W51+WxtNFYM0NtwN+7u9jSPFI4rTlgxczNurvEM agkeFLU4o8XAzzilvHKyAjdBwLdlJmN+sjiZTO6OCLRQUAsFzAuiQIQRhlUciWwVNEWymM+K WZJVIgm5kj5PhNJKpaw8W6lI8SxfubZyeyXTW3m8klSu72m8gPLF3ADQwsmWUYiF0RxQRikc yw2caRFOjqrFslwkjpYxuYVu/FFbk5wZlVU6kqGgCb64FNOvtam6CgEt5JBMd7qLwlqVGqKc 0+GqbahRC7RQkgD6qG8oBjSsrdEW69TU12WTCYZSzNlcgnwXT9hbbfesPTKNG0xNbGj9/i9m Day84Ponv3V8QefFN6y64uarTwznpjX3zqpv6U2Fr1oRaVr3vVsf4v2XMQ9eXl1WP2HZneez E8pjwOaUmy64NVJdfWFVeqpXGey8oap616XbXm+9auTutZc/tHdS1Zd/s4p1tedPa/daQy7K GRYW/s68D7RXjVrIBMXJCUKTJiw01SgtHdlb6+7U7qxjVOpZPL3uQBP+lvbx1LMtB1Ovpt6J /Cb1Tt2HKX2dtlM7zT7NPbVunnuF7m60s+4xfAAf0JlqtXhz6/2aB1IPVmtQa2/rUldf66D7 Hudu/FjzEXyi1aBz9bZeOYHp1hGnzUkm0Ke87G76dAKuqdWBjiBXlsmVcbmyvKX2mdrnaxlN 7cTantrram+vfaj2+7U/rP157X/VjtYa+2tx7QSHLqJbrrtKpyG6CboZumt023QP6R7Xvab7 rU5v1Pl1/TrGYdMxHnNClKHF8hWZCd2k5l6Uy2SIRymXs7xH9CzyrPU85NntOeLRfuD5q+eM h/F4FIuQ9RBRS4x8pViZqWyr1FR2lLfzcTFO4h8jlNG36Tfpj+g1YYgI0gt6oh/BzyuC0rq5 lSitfa2k9Ukndvrp6Mp6y9oKfuyXUYPQQBpqWEq+a9nPWFLFKmwv28dqWO9EIOARXH2TytEo Dxs4NSD/OCfkBk6BpGkBCj59Mofa2iitUuoGtjYqjApjp04Ko1Z3U25g0EYDa1ORdIXXdUKL paUF5WQ8qHK+msbmgGQQGA0fDyYicWOiKWEBbohMYX0IR6VmpiGEhIA5hA1RCBo1E0IIuCGw Q6GlKPPk6+EPD8I2GKScEfgjlMUp1QOlx+uoVFPpW90NxVLYAHS3qFKxpshCE0krV6xVW0Om PnNL76oRXOdWyiZV+AKJqRPaLhh88/KbdrotBofZ5w/VrO7oXWDYMCEZ8aZqhu69dNbqZ759 8aqG8qDN4xTlsurOGbXdN3YNTK64N3+3EhHinmnt0+/GTVNm1zekJT+Im5kgARcBnUvob8pl n3M4psfz9Y+HXiGvSO/gj/EfiNagw5WkwnGhuEJ/ibhOv84wGLrX/qz9WccIOew4EDosvRI6 Frci7LQjxhI4DtozQcfxCUw02AHCKmJ3eryez6zY+hdPwqiNdGuMvAVbZFySYTRW/Hprlsd4 Fx6GO3y7458CFfEBMUACNdpSPRofKJOzxynPpBgHxJzWGyvJOMqcekZzVMJRFtdzclBlYaMD QgusuBVWvmkA1t0N606hCRVdgwNxdcJJXbaBrkNxUZLjgstRlGuMIk5+Ze3zJ1ZsfOc7z3Q2 TujRc263WBXNzpnaML163t88127AvlePfGf3HQuaOmYua/N6a3se2vK3CXKacpFpMLsHYXbN KILnKJ6f+HDShG0X6iwJM0Zad0Kr1xmDioaOxwJj1CgJ2HIarPEBHDy6Z3qdGk0pRm1qtLdp YpbGSgzm4qh0XCJIUqQ+iSZh3zwkEYm3iTZiU44bsbE0d2oMTdP4AMyb0Uvx5uZ9ybrGAQBs dP5kOVecv4FBlZZP01kcpYhvlH7VHdKBgYJIXAyFQ4Rz2J12wnEJf8AX8AYYjjfbkjDKYAi7 9LYQ8miDSWw1WZI4xFhC2G5wh1CAdSfplqEQgoKIigrYM+3zlOoy3ISn4qnCBhPbz20ybRL6 vZu57abtwmbva+RV0bBJ22/u5zd5tms3mzfz2z06WMHcwHyQOLjGBQunLS6jzR3l1J3jKqJL K0UhOH/NLy5bfs1v3j7552O1U90WY3c6FUqaHYm4j3npWx8N/eTmR3DZS69jeUrPH3+6Ojdl mjc6cRGOPL0p6KRaASn8nrSxqwGN1CtBhHEbYRyEMIjBmBiZ3cjH4t2kUvNCJ0jXU6MzhdPq pLW1bGXTMuBhIDZAuKQt374ZH2FX/2sdO0RblRHiHKBrtOM2xdYelVAkLISDumjUo9iMbR6V HhoCbcgjeHZ5mHA46Bkhvz0YrQkHK6LRZnrZDvWaFajDN4vNu5uZyeFgM9Q5ENXSFrRnW9AK 2l1aBoeDWtqCZA0H3VGpfLyFcrWFcrF8dzkjhYPlUEe5WKoNB5uiUjRS1o54JKI2qn5VlJd7 PG7S3NSk02l1EposAERpreFrMfwvAllzHers6yRKZ2/nrs7hTk1nuIhVW61IwPDfC4j0ug7Q Mor8e1BVK3qA3E6PZ2DagGm3FENb02AGVDYgFRV1qOE5SUZgW6AWqHT4GxpFSXs4q3FEvlHy 73eQKnd7U2psQmpCzGcxuiBNXqFp3og/oIoHebmyRfJ9pYTQNLktv/AcLePar9L5zXjzV7kz W75K40fp2i8o/Ak/gbPIiKL70FTOyIxgu2IM66tARHpNa7fRGTqTo2QEuw7XfCUsMOpavKSz c/FinFWjzs4ltL0aUI8fZFeiAPpIid1CfkCeZZik6W6GGIwGI0as37bLtc9FXAFC3Nhg1AVG cN8BW8Y97CbuERzdg206FbSas7oRJrbPwmITdOmU4keswBL2PdvbfAAfCeCALwQs+gjG2Bs8 jOfhHYj29GRugKLKnlOgX4D0HZXbF85T7DrFZW7TKW4LBF4eAnMTXbv5IKXh+iHkhgdCDTd9 MFRSY7+gxnsC1ja17knrWaCZszZRlDnOvHORSB2ygUCFBU2qMlTlAThSA/pjLdN75g947Xdv uPiBC+L17+245Om+acvzz+L4mkkV0ZgL78fpHZfe+oD56EjfE1Nv2nYov98md1JeXQvz+H2Y RwNw6/sVT5sZ12LMIA3R6g2szmxCGp3ZbDSO4IWKgLADpt6IsFZnNGMNeh6fQSwyEEEx6TCr M5mpBkh0zzN6aFiL+xRPRtOmIbxG1BCNj0dUk0Bey+d/U6eQ4vJcD8BtugnahFMtp1tKMMXW BAq2BvgIz/PFodtxrbXWKQFVRxoi1lqy5Zprr82P5p2L8RAuMJeeufdY/jiuOkbcsGm7QfqM sEuRG8VQDTYoFzImjd1qctg7TSsTGxLaOG5wz61Zr7mRbPE+YN4Ze9r8dGxEd8BhAvyPsibm fFNvfKnpCtONiI2bzOYaTyyGTLwnXh1FTn/cAzPC2WpwLDbC6BWnucYBVXCMidaYq3lzDNdo OHEEG/bY2DSNOLO/RGb+EQYpQWdV9XsK08vsYhjGl+WjYpRE3+OrKhS9OVtBa1i267GeTpTe W0snSjgtD47Kp0ZzwukBUFyLOgpI9LOayFZLWt5que5lZC2V0kJbk9YitGy1CC+/DCpKTlVU ctj11a4aV0RUFaVeVTwkVSdhgFfQuKiOkMPb137xy9ff23TXwxf96fUX3xp4KR5rrJjWfvGl KdHsCFfNz0xdRvKX7r/q0T++uv2yRzs2PnjJLccObu67U1dz7bQbOusWd0/9bv61gFu6eerF mxpX514EwsgipHkMpIAP1ufYIRQu/GOPqSk8UviHstDYNCuB7/Wcdp8O/zOqqdAFEDYBD49G gZNzUclMTUmSP21D6UCAs9uIltMJERx5v8+12fWQi3ENZRI44S+y4JQZmQQT6TX1mYjpunji BUxQBE3EWuQpmnvGefFpCgFU6UWVPmF0nNEWDQOi5PAVDQOSI5LBog+CqDOWwWF3KINKhoHr r6fzSzMqlwUmC3uyyJPrIuGiGshYi1OakEi5v3Ph2KyL2/3+jhyZhWP5R3cs/lPEes2WLTeS FflbLm+KxuNS4+VMP00df3DLC1EPuW/sAPnOfffeRnnfdNizlwO+KsdJ0LYTxiajwyQU4U40 RuHOn/b6xaxM89VZGm/eI9ap2WCoWMwLaqwkHa6sION7jDtkYvSaAY4GUQiVi0EhJJRz2Oly u1H0ETE0gj/ZF3W/KgZpQpJiYjkklKBkqOGVUEsbrwQa2vhLWEajReVcKGjgc8hwGC9CGrzo 4A7tce0JLaMdwYcVIyrn3SKw4AopWsR6NNpblc2qsT+sxorD5soejeL+KEZRAXbI7ypmFvV4 VZGXgWWcOpUbHRVOqstGkZos03WjRN/SotI7SMyBkoJC18VZfy7YLYlEp5uiJjcsl7paoHsn 6/DrudsmNbZPStfN1BrMQV+5M4y1pkxjXjtR1hkSVcwTv/zOos629mkdGs4VbVt81W8amwS/ l4nF2KZrCNvrCvjYOKxRovB3co9mDHnRfbCnjdtNRA2MJuQdwQcUL9Y4HIzzRoK5sLHKqBgZ 46B+ucVIQAhZlCBrPGDy+bFGg3hWBHFUYXc5NzgcdsXkaLPTGRKC0WzGftR+3M7YvT46O0WT FxD0KaoVUpygwjLIoraxkzlqD1atXi1YlScDCDQDylLHlTB1YuqsEsxFAx55/30+IUxqDs0+ MH+j1XDNt56brBnLP7107MjsTHCp6+jSidF78D+l+S9vKOE6EoMdLaCjSsC22epu67PhYRvm WcQhQWQFThA4Y0zkVDLCMZFVycgUEwVKRi4J7uRYAypu3AqTUYEmKDnvaa5TqTqVVUH83rCk xopkd2eHjXg7CHqjYCTGjaJtl23YxmRsbbbttqO2EzbWVqJ+Gh9IpbPWmUeBggDvD4xTkVyU PEA+Kr6igmZA3cAqQRQxFdDD3nR7XtsacqQnszO+XLe0QROLkah7KfPakgZNvGRBJ59QDyg0 pKQiFFqea/j2h4OgRhcN3zYrIVjn4/2in/hbjQbV2NkltZ0w4CqDYug3HDVoFkFADN5wRFUQ /cHsiQjujxyNkKqIElkU2RwZhgynIkqqtKioUh5HkupQqBVajv9foCFdcfLJfwJ+AAjj/wHb qWiuOFLNv2Ck1XimMurSePUkXFtV21+7o/ZJ928cv3F/6P7Crd9guNJ5bXobc4eD3Wa4j7nP cKfzSeZJAxd2dDqV2t7aDQxrYAwGUqs4TG13aR7UP6r5gf5xB2sC1XC2yfSGLqilyD8alWdX V/++MihzszF+gw1yEUDqUQlzyKQ1I6fgJE6X7HC6GLfW7dprS3uqy8px2mTylBOPjtPy2lla 0gbBdu1u7THtB1qO167VEm1N7W75iEwycps8S14kr5U3ydvlh2SdfKPg6nftACHiUwDXI94s mom5NRL21kzcr+4udZJVVbsH4J9VtatkWlTbCxUbwuhoy7gIzhXFsIyF0b8iYawUjWdL0gVE hjyQgz91J9YAhrNKaVLckGqWOWcJVQUdFtEqJWiKpP3XXykkEqaeFYvt2ebZP/rvmvjEL9cU V5Q1+BOTU5q1ieClfY0PaPJj7zzyf8aar7yrNn9Df014eF9+9vgSL3RK9kA8v/bOzSEbrO80 hFgTrG8YPXsIRWH/eHxFfjxBsGXDUSXaGz0a1VRBguD/0mrPkCD2hINCNKoPB/moJP6Xz3cm FBS1vjIUJgKvQ/0Am0dwhRLV8XoRgH6rV/DgsKfXs8PDeMKCiMNir7hJ3CFqxMO4AnnID/ZG Lp9HOT2QdQuoSXSLniqR9ljL+DyOTyRlYzkqdIuTIn1DxVEpXrKyplh4Zkdi0XJ3e3NqrLlI 60u2tV7oTrAz8t/ZtDZi+/Ljr8hd42qefQ9eS/d2Gij+cZiRShxRerQavaGSiRqnGVmO5QwJ kmASmoQhYUyYZjFdhlnGFYZ1hpsNlmvKd6T3a/YbXtW8avhQ86HhNHvaYLCEg46oFAwHndFo YnZl5QgpU1Ylgwleh3WU7PVBHUBm7WxC3uCC2lA4GItKOq02QUyzzIAREkfiOO4bTuM0wmbe IlqIpTVI1VSCWkOhoDflcFaWxUgZLgPIGnNYgk20II7K4jHi1KXSX0M/QLMtlGJbTqmG7pZR NYNVGhcAaVLxUaR0yH8ofKhWKk3657l/i4unXgMlIlapOPGf1qLEhcYJuDa5YHCWSZLsT61O /rseqrm63HLFZS2PAOm+Xb/5srELf7wxv/jf1c78xm1b/PToqAvWqAHQkEw0hxBX+Gi/sUnP 4RSl28bpdb0pzLIsF+eY35JfM7/yMU6uju0izK/xB35i4y0wK7JoESKCvJs/AovhDzhiIj9C 3lWs0URMjEhRQ0y0SFIgJoZHyO8Up5SMibIkRcJhnrcYvCso6PGP4EV7j1NiL+xX5nrqMIhF mTOIAOUrnE6HEpnU5lAm1vEOHHYccxCH0jkl61Da6xxKUzMk6uohqKqGQE5BkCyDAICcg57K OBTBmhUc2EHtyLyYGk6RTKo/RVJKa11KtYw1Z9UYGlFjaEeNK9PFGFpTY2hLnRMedItUoEg6 FclkQrWZQAc/S+BM4mjiOBA1rd7QnFXjTLUaK/pgLJvwVs683jNuOBugYANIRSjBLJnapGX5 qxxIWKFk4TglD4wWjWrUzKFeZwQLhWqqYhymJ07GtrD6IBALPJUNas4O+jJPNWqeatS8Auoy T4FBxNE2/qD5wEoH6ZlcbpAan0tQr2hfPkeUU9D3DeH+UveWGRdd7RCSrflknVuwyb6505J1 +eQErzXZyjyxYeaU5dObHsnftaZOG4tp496leNcVLZGNeeOljVDAhV1riLAqqxs/VdV0Aq8I oRS+RpHuMz9pPmQ+6NLYbA06FBJCxC2m9DoPoOlXJF4rgiyiKAg/womQuOigTt5iMumMoDwu UrzuDZGEQwtNoaJKXUFtYsRTgcdtpjyehckwUJwvU8TRNNo7YWI2o+JnkyXbmzmeIf2ZXRmS EUErUtRTUnoYxwu4SlCEXuG4oBG86cbrPWcPF6gllBpCTxdzo0XOO3qKrtuo8PnoGfx5TmZU kK2ibFCQyqIVZnssLsUJZ0uUJcuThLPEo/ZEElWYIYhbI0mc5OVkSVWi9s/rqfUz02/ut/dH +yuGM0czXL9lk22de5PUX74xdbN7KHWf+V7XzsrHXc9UHq60bOa3WQm1Xefmq9SSgZF6I23q iD1hNd7jFtto6/NBqFqLoJ6tGz+aLdKDiu+lOrsK/scN3Q3MLzhdqjF/1ZS1XXtXzlm5f2X7 ygl6U9XkrdNWxz3xTDblLps3E4Dfm5c5ImFNpOeuua27bvjhvZ9ek52EfatdwUDF2M3fdogP Pvzc0wn7EHCjqsIJ9lGggjRmlIc9vDdKPIZktELaKN1u+ba0W/qZVJD01MKKGAELRGD6cT/Z 5NrkPmR5reydso/KLKzktAjRcCQhVUcWRLUvRj6XyOOWAxZSq9NSMBkVVXhUEU4HUTRWNG16 3G4MbZpWxfSCtSy8ScSLxIJIxOuqqpSq3qr+ql1VbJWuSHWt5eW9Fbjiusy4WbK4jVVNeKDo O3LOPlUXORop0/OGRCJuiRvjugxKlpklAfTgiD5pyiA+CgEVyi2lQyGqDg8MglAYtFPUyZUw Z0knTiaKYLSIRYuLlFB3qLaKvCDNmuBt+Fbf5Tt7EsHUefhXgaYZVnPbqbeH+25c41PmsjPi keYrx1YeWDdz6Q/eIeUXzeTd8Xg6HT5/bOzTX+7JKK89Re67qgkUR2ojxGvJBtKKGORTTORd RM3WXs33b1fNT8KHKNNDbY2RugjZMHaITMFrj9F9nAAU9FtYQQn28dVK2wW+Qd99TkYneaTp vimBKdHFgaVRrQ2BbiOAZqOpylziX+9fH71FetP/hnQ8o7vf9UvfPz1fer/0sRmdaYT8ap9q wVAT1IgBCaWJGjICfuQXQBNISVGHJEU3SbdKREIVgYh/c/Rk9FSUEQBwHY8yx6M46q4IRKVE PA2S5g+KW0KIi6XSdruNhH8RiURhirU6UBkwq+hNqEKoIBXvu0cYorhMsTgwp5JFxGTqNWPz demJh7BX9RfKqQyaLrUwRuX+uDVaoAQw1qJig7GWkjlyYDDXZKWwNkdNTjnLdcLLnnECCScr HT5n3Jsoi1c6KjI46YNAdqUyuNyTyCCfnxIGlseJA+eKfL+s8A/FaGqSdaamgMfubMVUV59P DX7/yZBSMnhqMWxdYOOYUQGHalEJ+ztyY9NKFpV1p0/uWNN5Le5S/OX1+Qvy0+c33To06zsP k1X5LV+3rXQc3HjPklYxXzffJTJxsorcP/aD2ptW77yLUs8MmOSrAFd0kZmKOIVgm01UDKEG HW9HLahLtMM0dXG4vsEbEx0j5Df7oqmYWAYJxRGdFBNbpCgfE+2SpCRxNCYmR8g7ByVlAm6I iRMgrVRIk2NilyRpo6n6iBZrQi01KzShFQaDRou6uJYJZUmH3dCtAL9WnSouCEWzqHtX93D3 0W5Nt9vts/C8yBO+wucFYOGlwOEh7xHvMS+jeLd7iffPkWhFOgWXUuql1JHUsRSjpLYDcPgz 4hvEBtJQMXmS6ggSjGb7Jp2YRHZNGp50dBKTgeD4JGaSd0r3CDl/b4RKfGovG1cz1ZNGAOOl GFSizuUdHw5QVFnyk2qjKFIYHVeG1MOL4ilGSearJBPLVPuDRjPLVSUCiWo2HcKcNmj0hbDJ nOFqQthvChUdb8bZCj1nRlPnbFBsYlinD+tCSVbUR5IoHNFpscqukKyKllhf94luwplipqxJ 6f61kZ3FztLN1M8yHu1mG8ksbpbpX5yGEuHAYFGgdFO7fFCd6L2Cs40bKfxjLwAQNQZYYhop fHY2BmaklkOs5nljMc+Xrgul+yCm+eeMTegrTISLEqqEUEo2/G/AFE5LRRgtayXjyIX7JnZ5 vefGmQuuifTe2bv4ihQAmGCT3+aQg/K8lNU9KR9IpnhHxl8WydTBtVAJ0Gyc0z5n7oLe+dvu yV+/JquLxdikfzG+47qOSFtb3rDcF6fWDan6PHzHJiXmFKfnDUvbuK8BHQCNwCQldg0yogB6 V3GFqL2HtyIbCohWwSYEOHdMtKmWHnNMtKqWHk9MDDyPPwGWylFfvGx9djeHOQVhU4CzWQ16 SocBKC16TChMuclU1L8rPG5qC3IXbUHukg1Ije1uNVYyqarssBtvd2PkFtzEvVEJ9YaIGOoL 7QoNhzSZUFtoOySOhk6EuKBqBIJ1/5oNSDg1mpOLlsTR0mEbNaGcewhl/8bsJyYtuEhRFix4 8yvz0Bq1QFEuyk8Y8581FJHoUmoowmh24ST5JfCTGrJVWWiscgptGsFc7hCC5RrO4XK8Gn81 8VvhY+GfgrZciFc0CvUVW413S3fHnjJ+Txox7pOMoJubdeVO0xTjdBOnGEGk2WpEtJOIGFO8 jKnf1EOqxt2p2NFOWwYKspm/yx7Ru9Mv+nzUEgZVdviwbwSvViTvTtffbTY2IWttoYTNaCtK CcXmzOKLbCgiRIhqhDIa+WwxF7XQfBp4kmjBFh+fxZnsrOyi7NrspuzuLJe18ToRwKoCNxRT UV952biTH6im4w4MZd5aegJP9QjAmSdh0gdgH+7XhQHd01M5xQ036BRHpE3X4pQgcMUhC10v AX56Xn96kCLU4o2RMAwf+npC0UMLkYvhbtrzvdCAGkMbagzN0HjP2Zbk+SfVFhQvVso8MIMB KwSCHwKLGwKzq1hxPkAi+qBQKMS3hUYKf9hrchRjqEHjPVBdrajWO4RY0ANtUJcNQUU2BLVY x3gV4a+U3kB7PjWKhL+qJ4d8RjFY2zKKnocAxkKr0UrFWvTJ8RR0zThSOL63GMNQQR+Kp0Az gtzbih4S8RQoS/GRwt/2AhqG+ORBQMemAEDlr1jQfDQA6hLF0tRtzS4lisc+bpdm3HuNchuJ qS0dAKmeIepJUdHfkdzFRyfeOKm82RHGidzMb89t7w8ZI66IEE19t6tqYsvK+1OT7759xhS/ 1ebyMD/O//jbKxtifm/5T26dO/Oe3gpjDe7dsmVCRVXXlFWN5y1dszvO8xLwlGR+msYHeyOK MvhKxWvL6HgOaZFV5AStYOXsGQl4RYwqSp8oRmpB5l6RStxF8UupLW6t1QachIsnRCOntQjl uFzx+2zVRd2ouqQb0VipAv23t/p4NamqVqp7q/urNdUlyq8w2xQTrjIppl7TUdNxE2vyVs0c KPoPqqtqKioeppLiYSopHnRaW4q2Qao8qVWri1WrS1Wrz6l6unTcNFrkOFQsfk2jCicqPSFv XE4EE8l4pac8iRMhCCp8qSQuC8TPalKqSARxNyGmtE3JSjTY5NkU2pTYVKm50rHJ2x+8VupP bpJvctwm3eO413N/6P7oztjjjqeiT8cOOF6I2TqcWKUEirni43jrLIeLOOsbSofMRbpIqv4l xZNCLd7truoa+4vK+PAt1bVT517y1LyLvr+qp72mYe6SeinblFCWT1qUf7Q764nHScTdx7xL +eDG7nDmhv/e8u2/bIz6Hr2mac5f/2f+hDuQyh1/z17IrkYxHDyEXIXNe/WGbGCkGHOl2Ez9 uudDwuTT++vtPb6bXbf6tvu3BXSrrattG6wbbNusT3BPmh9z/8T9ht/AuVCi3TUpsNl1k/tm /5bAQc3zIUMmsVJcz60zr/PfbD/MaxssVlssiBaQIOWbDgWSkaesNgu7KshYVjn1eFHGiq2+ ftCgbfHLD+Ea9fgfZh30IdFADD1e76meP+f8e4up0fklA7F6TGttaoK9Xtrpr1dXTT9/w3M1 Oop9XAHObEq44zq9Vk84f8LsMsQRF4DA6LHEkd7HxvG4vgyrTO1ruQF10VVjZ1F5ctjULemk yxOjjkCx8V3KXpis/Oy+Tb+sblv48oObf7Vu8IvHfpvfffANPP/F7Q8t9IYzWnZ1vmLk5TvW 3XvoQP5X9/dvu2r96h/grpEX8cKjrbFMLV2RzsJJZi/oQVHcq6QtHNYbvIYyVMZoHAan3xlg Grmp3EGWMbLY5zcENEEBwqAG+zQMU/QWiDoQitr48UO8EUa/z4Y0WDOCPz1gCzNHGHrYFd2L kQbk0QOKgbeLdmJ/z2QmI+S1vfgtHXqecMASgvhzxafoenW7dIzOFxPe2h4tOqNHvVLRl+CU PNhzkh6Qg1p3is59DjaX6nShOBjK1BlqOGKoHYmhPhoqJ8wXN7UGdijU0JScMTQl5ww1hqo0 3lNkyXDPqMoJlFCUNhqljUZpo1HaaJRy7ij1Qyqx2pIz1PjBvLupyHkHYSUjTESrUT0iNSUb hWqycheZbiwCG6yRbFw+9nEtnn/4/m/n8w88Pr91kpzsXTyxUkyed0V+V/6Uv56dkc9vNT90 40vXfXp9a2WjPDncUSGYrp4z/B61L8yA9XuRXYncKImOKXoHg1e41rmIgZ60O22ObAUTc/7E ybTp2KjHI7L6hPOH5KcI47sRQnr8wP5EQkAs9WXYJ5ij75lG8O/3Il+5Z4S8vp/3iT7iG2EM irHoHu4tG18IajaiB4+nqSdP6WjkpOrTQXUBlcGl/XGDPZYI+IN+wtnilkTcEF2CQ1bfEhTm ISUZE0uw3y4uQREzBGjcdY464F9PPVdzAKEtRFs/7sBIQZpK/5huiuIkCpRNMS/uf3eTVBmc NPm+Ny7/6RXX/XL9u/jO/Ou6unQkle5ul6eWsSsD6e8cuz+kd/zXkZtPXLMN63aexNv+PHb5 kDKUz2fjqx/Fjks7YDdECn9khmA2ZZhLUcu7+ZXyBvkm502unfa7XU/ZHncdthtTgbYAceiA kdyt6BESYBFQxDhJj/uQDkXImyhBfo58SAeUZbZmVf8jAFu6EfLzA4qF9ZkR6JH2fWGMWcNh WAYj9h0IFd2RYKoPWt9G5UI5KafTbuXd2O1L8SEcovMf8lae45skD8BWgHWgTiOnxqxNGa9v tAV52tp8o9Tn/aRwEpYlN0pXQ1W1qZpxjlcR9VagXB9FomdFfwkM4MzgPGXDgtuWxLt/P3T7 wQsuumpj/mf5/LOzmibLkaDw0gXTVh0lT0qRpqtazl9/l/mJJ5+9YvqtdU1PfOuX+d80lbWl J1l0D121YNufSj6i+2E+XQBDpilevZ8Tubi+3K31+J1hZ9xTrtfq8HpdsOhLk4RoL2e2ueng 40iJJbJIkdMQ1ILWoIBsV1Av2kUtPSlb0auG1rRsN2MznSCzt7JIoKeBU4zmgH+7o0osmY3S RqK0kShtZG0UD5QQ5mk10TPaXvLbgsqq2gH11RhuofF+uKvPXbpLZfoqiS/BFeGIGCEcbxEs hItJcYlwRpPBpDfpTBrO6XK4COf1+Dx+D8MRzGANZrgKuVwmXMgaXYISWggCdvcSXMZCELEE YVuYkkuQxwUpGUNKHt8WFaW/69EAHsAOrYWUHHqph2+Rr7DCuIMvZxXGHUWZ/U3RK+6Yu+T/ TKyMyK21x69c97Oq9vybGkPC2yh74z4H3whQv4Ijj78xvGZo9rJcx8D93/uvQ/d/7+Fbnn8P L5twa3XYIz039mn+xJIpVeHGq6jM2IoQs1TlOTe+gCz4+7gO6fBjB6KL6NkrnmRWS7T4n6AJ uvBjiMdfICeUuAhRLLwOsTqtqWSsot5VgsXSy6/ld/OMwGPe67H8CDaUjryKPMSNP1AtWCep AbNkwaSgytakWqmpveHrXpL1Zw8BknGy09XVI47Vxy6cBhgxXDvVhv/Orvzymes6K+Pxsq7N 5MjFmUg4dpJaA3cX/oTPMC+CtutGNYeQFxCk12bPclOR1jTVZuSZqfrKI07s9HreOVY0p/ac KppQR7+hRJ7r1ThXdWVcvLij5N3IvLi46N24eGzwXD/H8/IryB2Ai2yoVynbajnIkwbNfeQu /ZPkMT2LX0SM6UWz3WyiP0dT5aAG3gx1tSHAgBQBC3Pta+9RASz1H1NNe6Weqf5gTo46BIDS Tq0NCWQFhnXHyuqORNWF07O5v+WfwzPZ1emOSQtu351/Nf9OfmR5V13NbPx33IEVTH/Rwgt9 m6/27TwlWq/Zyt7Cj/Cae8j9+sfJU3oN9M4OvWOoN2641CvrLNorB4gZk8lcZT9vG3UgLtoc aSfP6Z2dQtGGeqtAgHbrXLR33pXV7cli5/Cs/HP5FenOSQtuG8bNuAxPUTuXN+dfyP84T39q Bp1fOMHF2DWoFq9RXAaBjTFxS/nV4i3iltiW+O3lt1QYpBKuNP0bzqygOLMdEiu1K43rjetj h5gfaUa4g7GDiYMVhg6pq1yp2Fp+cwV7f+Leiie472mfNL4Sf6NcO83ioZCg34NDrwU9C6Oq fcIBJZvc2PoatdPXngM1o2hB1VNySMSCaHZ7PFG2TmbMdVE9jNRKrK045KsrKsxCts5W5s3W vYDPRxF0OT5R9GDraZ93oHisTgHoc3oVfMqnW3pK00itt7amJgxfJIzjUNUQp24ORNFoJ0Wj NeEKjjcmQNtIxpIMp42bJH0cWSLCZBwWeYGrgJwhaY4jPmyejHTlKjZV3wBR7XJFqayexMsy PQaWEjEAqGQcn571P+FUiz9FPPQIuE5AkZJkaWBvirfnTz1030/nLPzZ7dWX1Ls6qyVy5/QJ gv6G/J/u/XHhpYYuDPB0+ezKV2yBKgeA1+jLbz6T//nDL+V/N+R0YF9vJhGPs2LMPi3/YfOE S59ZPfQMrsGPC7rp5U2UFqyFk+we5glUSS4EDGrFlRQEPQEgCCSGxugyugUkMIJGm3FkXBl3 m6PN1eae5ZjlmuWex86zzQ1dxq4wLDOutK12rXYvC60Q1wnX2K5zXeu+IrQhfHVye/o++R3u I/Sh5ePKf6DPDZ8bT1u+rExwBs7IWTQCa9WElHRvui+tx5jYbFa7HRkEo2gANU/0aJI4KZeJ yaLtS6MT9W57GHpmd4nuRDguJpSRwrq9VoaERwpXKJeKqDIsV1Z2iWGHKIbtSI84kaCLxRBk QxpGz2DmYqvgsFoFYKKIdFltkLYJGoZo9JUhuw0jzmoM47+EvwyTsJwU5bAYoj/GoMGGymTC 4zbouUqGIGOaeg1W1qXVs+DGrBqHI2qseLy+bFqhr2vCmMjuNE673b7kVWEAi6kDSp+1H+j3 eZxCYaQfP3PUb9IX9EyVXtH36hm9N5UeIXP3Rn58wVev3w7IPm/PWM7nGfN5xzyqUTlXfClD NSwXjcvjjq+5AUhZ3U1be9KyDjA2S9/EHbB8M0UTsuzzIAHo/6gaysXoaO5rUTHcKuhadC2q Xwl901NVEEKFE/TdRmHkbPwPxWBtcukcTW74FqHpfBYzEkPFLhC6alGx21V/Qkr2ak41phR3 AWZOFtCX2X82Jr21+J2qWHjbFkMolcEfNIaCW672JRqwM10v5/8VID8YO488vjMTtsTjAZv1 gvyd+DLP9HJdPM543a7pkO3t9iVjmnicq7t2zKtSer6LGQVKz+Cl+1Ubqokai35gd7bSF5Om oWnmbt983wL/vPQq3yr/yvQ2/4j/Nb+lzF7maESNvi7UZb6Eu0R7iem+zJPoSd9vvGZo1Zwx mzIWzqQVOafXJToF+gs/GpF1WOyio8KZLIvJlkymy+d1+Hxek9nsMbvazBdTd3GzBVh9JOPz WswmpHUmMyhGk5hlfbGP5R0hPvZxyOkACM9yPmTsqz5R/Vk1o9ppzI6ybDXQFe/MOIlzBIP2 xpaXh5PZZEeSSb4ekRF7HJCxt6oarqmkpJKR6pIPaEAlIHlQNetSRtUj0BejqBZWPM5yUy9z XVpWKWSrpUQqqHTWdS69fJ1CtDqhSCGUQHIs/l/XmGhLov6sZgfiDP9P/hcdk9L4b9VlNbsu m1DdipvSzR35z5dXd648/5Ip2ZqJGOt0vMdfVp8g+7/bDetOop5Ef/4O7L93QrySAJeb+NzY 9PyZljmL2ptnKO0JozFYcQ9deaHwe3YP6OsRbDiEJJjBZl8se1zCtZp7nUSQcKMbN7kvdT/l HnFrXG630+P10p9WCyIvgGSnJWg26YxBU8QbDkaA5dym1Lu1XFhHhTfRalNuGKDbyXJcmdsL Ka9Tp+U0Jtbr9rqdOpbVRmB9Ych6+pbWwdTUrARLhw7jNHLjGxRb2KRAWZ8Jm7xRaU1k+2Vf 7Xt125c2fNEKX9zm1L29uMHP3cy5l7++mb++RFsFSwv9UkV7kCrachHjYKm0TuPvuGFcXzRu SnXsnmnNFefnU5F8Zk7TLDLkmhd2C2kcwaYqV1iUp7Az4qb2mkNfntLUv9Shj8ddfNBWvXos R+ZfNs0XSpus9EzkfHKM2Q1IyI0y6Eol/E/yTx+JiAGvFlCQ90XPm7GpFRjg0JsAGXFgemoE dykGby0PrP8fmulOmrXjWl5xerPbAemqJ3tzq9Yewu+iIqbMyUDXo6dzEKC2sVOj9Hv2DQBK jPa6cSf+c8gO0Cb7v5Rfdck6jmFZY7iq+cJlU8/f+DhO/3sJOVaT+N48u57TuXNKx/JtV279 9eRvlADdTQbMPxnGnsKyslDJYM4uxgg131LjraZCBgZQbhUAotqAG8gCT+24r5RsuNQVts3P 7PZjf03iBidOWW6shCqwZoaM6vWTETMfZJgMEBNW3w+r8vqznlB5VIE4uqM887sPUjj1a4TK y8edh4/DBP76uAVbfm0228pNJXOOST0qKq/Jhk3HTQSZwqYq02bTDtMuE0dfE+hTk8dNn5m0 Jm84U5Uh6cxPI4fxMsxRsDVQPP+Ue062CCcHTg4Af1FTH4I+eerHsEKqtBqn3p6xFmA19ICJ HncKLS1aGpfCsy9j0DO+htIZn1RXW5fMfuWhTjW38Vcy3M5aJ/7AEZ479tu2Osctt+C3921c P21idiJsP8EdTJIhpnNs/cWeOBOLYX/VDLJtSWdmx9GFjanJ9RF9wMo7DXxV3e71qjZBfeUa VX/GD6iv3Gd7jE2qRM9Mr8uyXYT00l/H0LIs5+ISnIY3oyiqFM1CVKjkbLstRyzEj5E9JlqK /nHJmBiVovqYaFb94yLUP26pVBYTKyUJ++FW5Fmh0UYjEYvFbNCp3nAOO3WGs1MHOLsysc6u tMO3qRkyVdUQJMsgkFMQRGMQhEQIBGv2mB3zdhy2H7MTwY7t1BXOdjSNxfRwmmTS/fRN99Yi VIGm0iUvuHTJ+y1d8n5Ll7zi1AFb7M5sGhVftq0oS551gkviTPJo8jhImJITXLLkBJcsvV2R LDrDRbJJb+orZ7iiN9w5znBALrBrS2+VymePGsff9htto+86fcMPLlL0g4uM+8FZlOLBVtEP zkJ3hIX6wVmommH5dz+4og/7IPUrRjK2/r8fL5/jB9ezuXPedeVlE/OJGq/NJvvLZlTy9gn5 hHpuzM4Y++Ps9mVbd+XvXK06wkV8y/HDV06INHTmjcu8UZ16QryaOaCeEAOFFE4ynwAGCeAt is9GEME2ZMOaqtB893xPb+ig6UTos5A2RBGmuS5Eh5cIiNk21yzXXI7RWnSiVuPGbr9HdCNO 4AiHWZFzCU7RNVLYpqziUSDsDwS6eMHB8wJG6GLeAilLwIKRhhPCMFMCPRCkTm5E8Lt5v8Bb MBsAXUOr5bgAMvq/EDZU8QrfyzN8zvIxptZb9Qg1jHdhQhnJMczgXtqzvS2zsmoP/VIyG1LM fFZQT5ZPhDRCCA/DOEgw9BUAKa74KaoLjXlP5U55Rs8CkLPQVZYhubUo1ray4xj1PyGO8Yga EmTVZUZxhmhnQ7SzRLAG2jANgBJO7HE0qZGTRv/YY+Tb8DhdAEgp4VLtN2EK/kv+laawO4X/ lrF6Kh/YWJdqwjWVjY351wLkVzdKPpB4VlcoviL/MM7cUC8mAYFw9VvGopSbZIDzfwDr3Ewe UaYng/eLxBcQmontiRBuNl9ddaiZsVkcYkJcT+6xPFD9Ov6gRSdoBZ3gFjwaj1unpfQsanu1 n2kZWBnQcBNxIUbfrKMH1XxbrF7i6NRvtnvbHqg/XE/SKZwJhkRzJmgRzc08SJxmXmsGcvEG faI3loqLsfrmBrH+MIdVmvHwbtEjiVFRqstkxbp0yAIEooaS96HMsxmyMHNb5gUQL8F7+Web X2hmFjbf1vwFz1zIb+UfamaCXXwzEFZzqvQ+OcSvKTfbnNk/pvD5qc2pZ1NvpzQpbDOXgbrG YieO40G8BbPbzC+JX4jMHPFG8U7xSVHzPfN75tNm5lZ8P34eM7/FGF9sFh1ms9is2KQ2EFdm PsM3a0QsmsWM2KxpzqTEIG/GOu5syltfF5M4rwfk4q6Woy2khaIs3pptAcFI5+hAiG87BqM+ jCneDu3J7Aj+EIdQiqxHE1AL6dob+R9KnqdGT48B4ipirdxZvUolTXfTwIC81QJ4i76TAPxM 5UgYlB5YJUyVH3eqGDvKijEfUuM9phIPmg90TH9WRUXT0ISaLZ5+wPc/oLZiiHP/2xUe/op2 PFuTfF0m52lpeZ96o12byckeSAIGH0DqtvDVyZ0yWYUuNV4SWpV+Aj8rPhs+JL5h/rPZgOkr 89TMbXe5x9/1yiaT6qswZ33MGhqYIkDUFn+Ewu1uOGeTkMsfmVPtz4x9MTEYnt2Z4XT2SGX+ jo6BNT0Pz5pZRTh/Vscy3qmJXimFp09cNZlMzL/5sOwmsRjrsgda7lveabYDKfKx2PSHBnHF HZNBYcM2rcAL2swt9ZdXOoMs4PwpK+iecsKeWgN7yob/WzHaEONi/sx8yWjMI4WPFL0UzzJh X5AehH60NxSm8WfKDIBCzWQaWclsYq4yDZHbmHvMX9LfbJrOdJk6zBcxc03PMz9ltKADxLNX mf6HkIwuow9bw7a5pt+Y/mT6AnA/0Zj8xGHS0LellCaroU2nt9qs8HiT2bbMfKV5i/ku86Pm feZXzSeBlPXmi4u/B0AwY0Z6k8NILJjpMupHmIRiNhqQTbARmw0bOBstKTN3IXIAYYODurMh B3ZQ2wEoET6j7oBeb7gIM1cZy22y+uNPgqMJKbCf2lABkbX0l6FIfI/5KtXx2aA6PmPstTtG 8PSzOt+A3DNG7QfyqVP0dTdhtIjH5AEKyHpGhdFP6DlUTmj5hDqlnfOOLDDhQZXKzUDNVGWl VA3UDPFhquqrecFZjHm1/MQei/3s+d51L9O2hNeF1xE1qNFNgwcHih5EarsM3KfnVUcwRQ+M mngggFY+ec7dRN9LxPL8SKQOUxdZrWSNOHHxvZ/2M78g5J7Fc7IBibHniXL0aTngYuZIPUux 4D+z7/I71B/kI/c/8F9f5J9fxLd8rvPq1N90feSPdV1f/cJrvku7kl0DdfWl3yyn9IW0kXwn uvBsJYy+/lfDNeGA9nZUztyOZmkQ6oHvQkjPhHgaaUKEa0IyQWgB5GvgWwvfbkJ/T/aPKAv1 ppOnUQLqyUwQlbNz1e80uJbWXIG64DuL/Qmqgjo1ECe4p9EMqFsBdWfDtSSUzYb2OuE7A74R +kz4boX6u+F7Hny98PzzoZ4Vyq0QCxCfD+WT1fYRssM3A/2AfYTqcRUuMBM1z7F93CRujXaV 9g5dve4h/Vr9WoNg+INxnvE3phnmFvMrlnv5d4X3rY9aj9hecsxy/MW1wX2Np90reX/qG/Tn /K8GuMCcwPeCT4mhsD/828iF0ZTUF5sTzydtpRmsQT2IUeePIAHk4iSY5yHrfiijU7NIcw1C pet5NWTU+0JqjlHv0uH/p71rD27jOO97dxCfAh96WTIl4yTSNAWQIAU9KNEVBb5kKxQoWqIc yXEtHYEDeRYIQLgDGTquRSXjPCZNrKnbJlZaW4nT2IkbGzxkEtqyEnbSpkk7HqmZpJbjVFIS Z1LnYTlp7Uych/rb7xYgKMmmHHem/YMEd/e7b7/39+3ugTcAVwpYYTH6jnQOu1iDdEzAC9hy aUrARbiDPyPgYnZW+p2ASxD77wi4lH1QfkPAZQtuVyYEXM5SJf8u4IUsWnqrgN1FXyp9UsAV 7M6qwXxtHKn6qoAlVlm9VcAyc1XvFLDCNlX3C9jFllR/UMAL2MLq4wIuYsuqPyfgYharflbA JWzxogYBl7KuRTcLuEx+YtF9Ai5nW5auzX/z/vqlOdvcyh1L/0rAFcy//CIskVw86hUrVgnY xfwrfAQvAL5sxX4Bu5h3RZjgIuCLVnxMwC5Wv+JBgot5XlY8LWDkYsU/EFwC/MIVLwvYxRpX vEZwKc/v9asFjPzWeAQMOTVbBYz81vQIGDJrJgWM/Na8IGDkt+aXAkZ+V64SMPK7MqcL+V1V I2Dkd9WnBYz8rvm1gJHfWkPAyG/taQEjv94PEFzGY+U9L2DEyvsLgsuBx/sAAbtYwNdE8ELu i++AgGG/b4jgCl75vgcE7GItvkcIriI5pwXM5fyA4MU85o2LBYyYN64geAm3p3GbgGFPY4jg pcAvaXyfgF1sQ6OjaxnRf13AnP7fCF5B9JcEDPomR1cNr4GmWwSMGmi6jeBV3J6m9wkY9jQd JdhD9I8JmNM7+arjNdD0ooBRA00/IdjL4+NfLGDEx+/EsInwXQLm+F4Ol1D8/aaAYb+f9JaQ X/6nBMzxpzi80KH/mYA5/jcEU16abxIw5Dc3swE2zpJMZ1GmsTBGlX0ebYANExxiCRZHswSV yrpwlQLMew14gyhUYGLg9wPqJrz2DiXNWKayPZiJsXSexgSOfze4o28d24JXC2sSUICwHeCI YdwNniHYYBHXbsgz0fh31ussAh0GGyGcyvowjhFNAjgN8jtJb+QK29vm4FPznG3sdtJm5r3j 1rWyTYAaINeADynMmGhRyF97zZLfTO4Mv8M9w9uPODYV+DQwh64nKXs8NxHMcVyKHQKOW/rH 51UFVkdGDGi1yAeeBxXXnMYSUvfCVhUWc36V1ZO+EPpd0B2l/HILOZ8OqSbZPiyk+a9ik1NL CejlNiVBO/6mVDrVMKcbI6uG8noNsUKaqCYtsiEGzLiIQ4q84lIbgbmd6C3Cq2wnxY9HMk4+ 8Vpdj6zxOBqUgVRBlDU2SJLVvHUz65PbkaLoqeQLn9Uui2NOeu46l63CjDt53En2RkSO4hRJ EzI1kpsiT6LChzGyNYyey7UIo5GsCMnkKy1OdvAM8TXKaYYFjYkVPEi5OgzIiUOMYjeIqzDV nU52xcUYLaiIMbIhRt+Nr4IyISLApYYpMiZeUVzFCqKm0vrSC+rQFLblIuJkbYjipBFvZFbu TdLtVJZK+YkQlKao6RSXt66Fm0SEDJIRLlgRg0T91nXirIAr81cYYSdGcWFpPI/jO0uadj9V 7B46ey+tujhla5RkGmIdOjFycEnizUXVqaJR2jlG82uCxzoldKfyGTqUr7nL15cTh2tbY453 nVQ5Tl0n8vY7denEIS729dkRd2ouQtl3qjtNEXYkpcl3R2c/yeISLeC1gn2lH75qJN8Q69mY Vc3OHjlOlsWIwyRPY6LqhimPmtCbEvsd986kzKdnrR9uLV9xORt5NahUlU4+uN9h2uti+QzH xD46iBYj68aFx2naax1JYzQzTNISeDl7ZljkZgQ8TqzfDboIaRgXMSrcTwaJ95Cw1YkQj8AQ 2j1EwyulcK/gte6cAZaYSczaQyNUX+lZWcxJ1mhPTxRIi1D8kpST8VmUEYpQimKby6ufznsL 9G24j2hGDPjLT7tGYUX6xa7TTPQjkN6M3qKdgNvFr0x2gGQ7q87ZH1P5M9Kf5/zf1ThGmcjt iTNa+rBKBrDqt6N14R6Hw7uA5atnO+0eHN8DzB70/C7oFpzoPXiFCDvA3PQtbmUF586VJ0wO P1ywFyRFlMfzO/O1nbIzuTJElp3ayu1+41SvOZ3c49GCu4LCXTZnj7OeRgrOMI1Wg1NZcSFd Iyt0OlOdCuN1vl9o46tzVOz/g7R7G+LkcvS8WWRy92lj4sTla8ko2AMLd3lnJUVFtVwtXgnh F4+YPmsnza3ZK/VFxE6SopWfzu8YgyIzhWfn5Rq/S17NjpRzllxZFVdqNsQaVRE5je7HZ+5S NDondNqXrq6bR3+vOCOdM2X8ilw4eZp9T+jshBpZlKTIGmIXuZacq6IWc/v4UIFevndEKNLO eeyc/qmC9wuNeepUQd3O3Je8daRitGsYl+3pM/Jy56VJ9TdzV5Db82YoE6B17qDTFHEufzjv j2NXYXWPiF3Sib+zqpKiPmZ209k19FYezdTHDvL9yszlzkLnzs4s8MY5acKU1fhlOUhdFu8Z ydy/BN3LRcRZwu87nHcouX3gWrKfk+esSV2cp7PPxZy8K/PoRMvxwBJn+dXWcS5j2mWxjr4t a2eifKWGsLh/GxRXhRbp4iS0cPbkJPD3Tx3MeafSwDazDXhvuBZwK94ZbAa2BZgWvPhfiPay XkHZgtl1mNkg4Fa8h2glrk1sI95R8Malv72z7o8/GXNzzZdFL38eDown9agW1tXPqwPDuhpK xBMWUGpXIpVMpDTLSMTVZCzsV7s1S5uDqJkLU/ckYmmOMdUdcfCt27KlpQldwK92xGLqbmNo 2DLV3bqpp0b1yIAxoptqnz6m7k6MaPHORCySk9522ZzKJ9tu11MmVxfwt25SG0JGOJUwE1Fr 7dWIC2lpHtM027+niTQNXMb1uDqQ0iL6iJY6pCaib+mrmtKHDNPSU3pENeKqBdK9e9R+zVLr 1YGQuisa9ataPKLqMVMfGwaZPy8JUUoMpbTk8HghSle7U9qYER/ivAYS0qTusbR4TB+HDSnD TMQb1duNsJVIqTu1VESPWwjt+sDAsGHCFm6yNhjTVSuXz6iRMi1VSyZ1TdjIyfnI3XIch487 E/EIPIrrY2ZSS+qpRjUKDWPDRnhYNSx1TDPViG4aQ3E94lfVHZY6DIyZHjT1w2nYEBtXB/Vw YkRXE3Gdy+OBGEukYhFTHUnAADMdDuumGU3HyDQ1nNIphiakcUPg2pAR12JqxPHeVMcQLHUE aVDT8YieujwKN8EgI6WHKRGD45fHBAnI++cYDIviEBrnUCqRHhpGXlT9vZYeN41RHU7qPKuA kqkENxUhGk3ERnkmoukUuFPcoUM8crl8wYarZAzqOjUTsU5w+YglbIij1oXhiFxEDSPc6bAF orTJOfv1VFK30hrVSn9Mi1sG8mw4YUZFjquoU9W0xpHa8LCW0sALaZYRNtXBtJMfLaIluUQr oQ5xP/T3hvVYjDscQ40OGjHDGofidDIGojHDGlaHEglUJmxJjIzD6ncbER2JTJtOnQwmEodM MmhEG9LuMeK66VRFSscKsHCRcCo0kginHRc5sRYzE0QWMcxkTBt3kJFRPWUZ3Ff/sGUl25qb x8bG/CMikH6UTvOwNRJrHrH4fwluHjEPWDx1qMcUX5F+PnmNjGN6jFcisfTtGtixfUdXx8CO XX3qru3qzh1dPX17etSOW3b39IR6+gbcZe4yWjv5BcPhYaoCpA4RQzFfZcmSVwZcRrR4+Y0n 0pwznBilrcApWS4HeRqhFaapMQQrDnJtKKXrPGB+dT/YhjUkKzFoaYgwsjfLGL6njWHhqrpB FeiUPJIURVhm7EK0rcSQ7hQpz2yeD0mwUgZKBKJhplidOcbnzJxRWCX5UOSZAWvqqBZL05ai maZuFXL71b1YkVgp4zkv4JPYCVGEmmom9bCBErnScxVR5DU+RLxaJGLwdYzln6JzoZGjUxRb 2ksuMypmjBii0omOr0vTcvZkXnmETIxhg04PxgxzmOuBLCfcIyhJ2I9UJcdVp0xFhGYronjs iM44x1chNjuT1GDRhPVUXHiQEnYTsTmcSGOxpvRRAwcKr4Er3ed0yKSOdSrWIqfL+wizoMDC Kp/JMXdME1ZHry6WTM4zhLG/Deo5QdCjWW2cYO+eDhwqDZs3tK5VW9dtbmrZ0NJSWrq3F8iW des2bEDfur5Vbd20ccvGLe6yN1l1b7kY+VWzMI/WIf1R3LlN4zdbc/1pfja1xdKSG/iX5+Sb oYyyuR9KqIJqO+mx5qQWdMqHlVPKPypfQz85F89ltPMPiOYfEM0/IJp/QDT/gGj+AdH8A6L5 B0TzD4jmHxDNPyCaf0A0/4Bo/gHR/AOi+QdE/48fEOX/JmOwt/MXHId6J0anghOESc/JfyXH LbS7mHNy5ui2s5dh9SH2OmS8DNzcf92ZTZ+T4+y1fEe5Vs0zHLcTNBefQ3Ur7Yqj9DepuXlm U/eLO4E03aE6O+xcEq7GU5i1uf2dRe3yuNpdN7u6XJtcm11B11ZXr2vLXBLehOda/9o3Q7n9 mmLmUPXyyEnrgJmLfoayV9xjH7qGqBTQStXsh0otZubgydPtpHcNxjWsDofunazJd5Drd6T3 7a7j/Gd52KXV7OvsKj9PX5p2KdmenkBwCqPPT6PdsDZAE/b1KwOnXIr8EN4Ve4CQ7GU1NMPs zk4BbNrsAFlvU+B8R5mLsYtosou5JOzpxJVt8Ade/RquJeUPrFKSOFb5XbZqCbQpv89WLg4E O6qU37B+NJlllEk2jSazhPIaO4Img/wpu2kdV6Q8lS2rCFSB/iJT0SYU/kmaE+glug6icfqL 2cXLuPif2JXVxHfebtngANmq5YH+jiXK92HPt5Rvs1rmUX6I8QaM/4xxFcZvKN/EGcLt/Gy2 siowAX2PgvxRZRwHlEf5O+UeFsD4uHIfqyGyF+wKR88LdoM30FGmPKbcSySmchgnlUeJKYfs gEc9qXwWlgaVn2dLy7l9P7erlgZOKS8rh9gSUL0Equs8laeUOGtG455MZUvdgWMdC5UpuDmF sHhgo8QeoT6ofNuGIOj7vDLBlmHutHKULcX4BeX99lLP9Enl10T2OpcCfZ+xS9bzIeuuCEx3 lCqfwWxG+RUi/ivS9t/Z+s0B1lGv/DlrQZMR1B8B+hH/0IzyCqBXkKZXkJpXkJpXYMUrrAhV 9gvM/AI0zco5llReZMfQHgHsgshxGxF8moC6hsDTyp8p9yISVScROwnY+7KlFdyye+1Fi4ns 3uzCisC2U8rzbBeaDOPPZq9bHkicVD5OrhzLLq/hDN+xSxcidO9zcgHGe3gOTikTyvspEkcp Apmv4lJilcoHiPlSdmF14AiyP4DLBPoH0M6gXURzgWwAPgywA2gKyPuzFZWBypPKHcS8w65Y 7zml3ArXb6Vo3WovXUM235IFcNtJpRdFskvpsyMeGHibDWY+25fd3BZoOan0kcN9tqfWQduL VxCw3S51iqcrW1bN1XUToc8uqSC0T6w7xZtdcl3Ag2JsI5fW8w+UKbj3QWtBmwCGRzyQrVqE Eo8oATI7wA6inUDLoLmQyADIA0hkgF0gTKWyCT5tYpfQFCRwE3sVTQZ+HduG9gDa19AuoC0g 7EE0GfgWaDiI/hiaDInN/Pt90AfRDqJNoJ1Am0Z7Fa2YnVaaoId/yqgF/QRaBu28wj9rlFAa YUcj/ySWorLflzDmYUfkh4Jt0hF2RDoiH1GOuI4sOFJ1pLokuPHGxkDwbt75edeArvVgabJ0 Iv/tXVWlaqnMv3uiuG09/1TuoqK29d8L/TT0RkhZ1Hqs6FixfLpjIQ6Q82gX0RR2WqrCVRWu qoIfUk63n2+/2K6cDp0PXQwpp8+dP3fxnHK66XzTxSYlGKppC7QekBLSEekByeWRmqVt0i7J dUBJKEeUBxSXR2lWtqEWXAfLk+UT5Qr/15n95UpVuVouHys/UZ4pny4/U74gUzRddKboQtGr RQv6iw4WJYsmio4VnSgq4l+PuK04WOR6taNLfhFBPYE+gyazCfTHCKqimWn0Z+j6GF0fRJ+k 6yD6foJq0bdwCK0Wsr4Hugn0x9A4Hb+uRd/Cr9FqsYW/AFwS/TE0WX4huHJNS12wTq6qU+tk Vie9WiedqbtQJ2fqpuvk6Y42+SxZeRZWniUrz4LzLOk+C7mA0Gph7fNE9zzonie650HHoavh DqJPEhRE309QLfoWDsnP27WtlR0r5E9B4gH0j6CdR1NYM/ptaAm6qkTvQZPlT6EPysezNzUG Jqbk43Y9NkMMa5zhBmdYSUN2xfWBAx2V8nGIPQ6xx0nQcQg6DtG4ujQtP2R3c9qH7K3O0Lb+ fMcWHJfcnIfYU2gy24X+EYKa0W8j6CmiqcxfZ9BfICiJ/kSe7wBBnM6DluN3ycfxeghQpXwP sPcEy2W2bBmO80XVJYum5GdsY5FnSv6S3VCFIesMNh86FssKcuCm/3Dhlp6k/hHq/5L6d1Nf GSyvdf+m1v1Pte7Hat0dZfK7WB3Qr1L/MvV3Byvq3P9Z5/5GnfvROvdn6twnpR+xNZhYHbx+ jfvHa9z/scb9lTXuL6xxP7jGfeca921r3DvXcFENuD9xy6t4L91F/crgdar7d6r7B6r7X1X3 N1X3p1X3ftXdpoJc+hUOT7f0N9R/gvqNX9ng9mxwr9rgfkZGbKT32JWs9KQsS+9hbqXM9rZ7 ppRSGuTVduhGDCvtUAeGGju0G8P1diiFYbEdetDTUSpXSpO4M/HIFdJkCR8X2t6jmC53hhLb exeGBbZ3i2dK+oPtrcXwWzu6CsMbdvQGDK/b0Q0YXuPDs9J/sagMMdIv7ejDEC/9lDVwsdJP WL38BMYpO7QN1F9xtEtfYu3SjUDbLMitkP7e9sI46XHb24DhMdtbh+FzzvCo7fVg+LQd9WN4 2I4+iOFv7ehLGI7bDTEu7yHWQHI+yeppNO1QDaYP2yEuIWmHmjEk7NBGDIfs9ucwGHb7S5x1 SJqUUN1SlHnJUs2Oevn/eBOO/ClroOk72UaSfIsd4iHZzoV0uKUe4Ui31MVv8KROaZKkBG1v C8jabW89hq1O5P7EjvowbLYbEGOp1W54GJHbJBSs5fl5VqqDGVxQre19AkQeO7oWww12tAdD DeeEUYuF1kWsnYyqtr2cqsr2qp6vSuUsShLLWL10/Mue30Pub9unpNttzxvBqRLJ9vy6AcOX PT8PDXp+FprC7a3np1jGT3zZcx6k59oBBss93/e+5HkxusbzL15QBGs83/L6PV+vH/dMNZz0 ZEM3eCZhWCY66HkqShKerAeb7Xm8YUqWwH0iutPzSa/P84n6KW7DX4D4Q1wHBN3vHfe8v/6o J41SsEIf8ZjeVZ5kw12euxu4ous8hne3ZxiODIFHjw55NO+DnoMbyeK7vM959mwkH3qj5NGO dpq4Nbrbsx0WYGIbn4AFN6MuA2D1bzzJY8SapK7sc569rc/KOI2lCbRU0F98qvi+4sHigeJO nDs3Fd9YvLr4huIlJYtKqkoqShaWlJWUlBSVuErkElbC5CX8ixp9/DP2S4qq+FDk4r2L4CqZ 0T+No68bkKUSmb2LZRYrvXLvns5Mq693qvjS7sxmX2+muP89+yYl6eP7pd7MdJj1DqqZ1/fU Tkllt92RWVDbKWUW9bLegc7lIM7IH56S2MC+KekS57i/JrOIf9u1JDXe/7EaPm6//2P797Nl o9uWb1vUXr1le/dVuoOi7+ku+Kqr5T7frKtVmb/u3bMv84VV+zMBDlxatb83s3aPeue+p+WY fHdP99PyIT7s3/e0NCzHenZzvDTcvR9kNxMZa5cPgYyF+AAy+U7WzsmAv7OATJoEunuyvd0h 2iVNciIsml1EdIdD1FVIpHxU6iKiLuWjRPSwo9ALO6AwyAeQLYgxLyn0LogR2XJONllfD0nR ek4yGagHwWR9gKZvm5lucKa/6Ex/kU9PSdLM/MZ6x9oGVk8a6uUG0Pj+D3/0zj+CScpuHY3v 69Frew7W9uhoBzMfHR1enpkYVNXJ+CifUDNK/cHB8DAfNT0zWqt3Z+K13erk1n1Xmd7Hp7fW dk+yfT0D+yb3BfVue2twa0+t1r0/23d08+FZuj6S17X56FWEHeXCNnNdfYevMn2YT/dxXYe5 rsNcV1+wj3T17u6Uevv3TZawTv7/wmjMyuVlWC0Ha1bv71xWlWynpXPz6uX31TzjYtLjrNy3 P7OwtjPjRuNTTR1NHXwKS5pPVQBdKaaW33fz6ppnpMfFVBXQ1bWdzFreY3Tj18SPZaXxgxib phPr5c6E5euheRBYgCz6ASVg3kzCinmLpWd+fD6Hlpm+rn2ToVDPcqO7hn/NFb//9u03mc/n KPT5GHTCa7rhX0Y3/OVFy9Z/N/Tj0GshZZru9M+gXaA7/Wnc5Z9Bu4A7/RuU6fYz7RfalenQ mdAF0J47c+7COWW66UzThSalVVhg0n/8g4Uzr7TPTJv0Xx/IW/Ibl5bP9HGXczHAlY9jeVTw 4+CJzwcpvjyvbwYwnck0sThYM1+/2Fv/B2FXd20NCmVuZHN0cmVhbQ0KZW5kb2JqDQoNCjE2 IDAgb2JqDQoyNDIxNA0KZW5kb2JqDQoNCjE3IDAgb2JqDQo8PCAvVHlwZSAvRm9udERlc2Ny aXB0b3INCiAgIC9Gb250TmFtZSAvQkFBQUFBK1RpbWVzTmV3Um9tYW5QUy1Cb2xkTVQNCiAg IC9GbGFncyA0DQogICAvRm9udEJCb3ggWyAtNTU4IC0zMDYgMjAzMiAxMDI1IF0NCiAgIC9J dGFsaWNBbmdsZSAwDQogICAvQXNjZW50IDg5MQ0KICAgL0Rlc2NlbnQgLTIxNg0KICAgL0Nh cEhlaWdodCAxMDI1DQogICAvU3RlbVYgODANCiAgIC9Gb250RmlsZTIgMTUgMCBSDQo+Pg0K ZW5kb2JqDQoNCjE4IDAgb2JqDQo8PCAvTGVuZ3RoIDQ0Ng0KICAgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4NCnN0cmVhbQ0KeJxdk8tuozAUhvdIvIOXnUUEtsE0UoSU5iJlMTPVpH0AAicp 0sQghyzy9gP/T6tqNok+nwvn8yXZHLYH3w4qeQ1dfZRBnVvfBLl191CLOsml9XGkjWraevhE /NXXqo+jZKw/Pm6DXA/+3KnVKo6USv6MCbchPNTTuulO8gOLv0MjofUX9fS+OXLpeO/7v3IV P6g0jspSNXKeev6s+l/VVVSC8sWhGTPa4bEYC7+lvD16UYYLmrPVXSO3vqolVP4icbRK01Kt 9vsyjsQ3/0ezJatO5/qjClO2HrPTNNuWExiAywGWUAAyggbkBAtwhD2gABjCM1s/A5aM7ABr gDWAF0IG2BBYs2VNCtgBcsIeUKCBTglooOnjNgD6ZEsAfTLIafrkrKFP5gCzDwbV9HFMo0/O BrMP9k3TJ+c49HGM0MdxAvoU2DdNnwI+mj4ZIoY+Ft8x9LGYzdDHMo0+Fg0MfSzOx9DHrgH0 MdhRM58PxjHz+eCADX0KAn0KptEn5wSTj0k15Ax9HCP0cfzOfD6I2Pl8ELH0Kda8n5/3cLqq eF1fD6G+hzC+ATxC3P3p1rdevh5q3/Wom3/+ATPp4ndlbmRzdHJlYW0NCmVuZG9iag0KDQox OSAwIG9iag0KPDwgL1R5cGUgL0ZvbnQNCiAgIC9TdWJ0eXBlIC9UcnVlVHlwZQ0KICAgL0Jh c2VGb250IC9CQUFBQUErVGltZXNOZXdSb21hblBTLUJvbGRNVA0KICAgL0ZpcnN0Q2hhciAw DQogICAvTGFzdENoYXIgNDkNCiAgIC9XaWR0aHMgWyA3NzcgOTQzIDQ0MyA1MDAgNTAwIDQ0 MyA1MDAgMjc3DQogICAgIDc3NyAyNTAgNTAwIDUwMCA1MDAgMjUwIDYxMCA0NDMNCiAgICAg MzMzIDI3NyAzODkgNjY2IDY2NiA2MTAgNTU2IDU1Ng0KICAgICA3MjIgMzMzIDcyMiA4MzMg Mjc3IDM4OSA1NTYgNzIyDQogICAgIDUwMCA1MDAgNTAwIDUwMCA1MDAgMzMzIDMzMyAzMzMN CiAgICAgNzc3IDcyMiA1MDAgNzIyIDUwMCAzMzMgNTU2IDUwMA0KICAgICA1MDAgNDQzIF0N CiAgIC9Gb250RGVzY3JpcHRvciAxNyAwIFINCiAgIC9Ub1VuaWNvZGUgMTggMCBSDQo+Pg0K ZW5kb2JqDQoNCjIwIDAgb2JqDQo8PCAvRjEgMTkgMCBSDQogICAvRjIgMTQgMCBSDQogICA+ Pg0KZW5kb2JqDQoNCjIxIDAgb2JqDQo8PCAvSW01IDUgMCBSDQogICA+Pg0KZW5kb2JqDQoN CjIyIDAgb2JqDQo8PA0KICAgL0ZvbnQgMjAgMCBSDQogICAvWE9iamVjdCAyMSAwIFINCiAg IC9Qcm9jU2V0IFsgL1BERiAvSW1hZ2VDIC9JbWFnZUkgXQ0KPj4NCmVuZG9iag0KDQo3IDAg b2JqDQo8PCAvVHlwZSAvUGFnZXMNCiAgIC9SZXNvdXJjZXMgMjIgMCBSDQogICAvTWVkaWFC b3ggWyAwIDAgNTk1IDg0MiBdDQogICAvS2lkcyBbIDggMCBSDQogICAgICAgICAgIDkgMCBS DQogICAgICAgICAgIF0NCiAgIC9Db3VudCAyDQo+Pg0KZW5kb2JqDQoNCjIzIDAgb2JqDQo8 PCAvVHlwZSAvQ2F0YWxvZw0KICAgL1BhZ2VzIDcgMCBSDQo+Pg0KZW5kb2JqDQoNCjI0IDAg b2JqDQo8PCAvUHJvZHVjZXIgPEZFRkYwMDRGMDA3MDAwNjUwMDZFMDA0RjAwNjYwMDY2MDA2 OTAwNjMwMDY1MDAyRTAwNkYwMDcyMDA2NzAwMjAwMDMxMDAyRTAwMzEwMDJFMDAzMD4NCi9D cmVhdGlvbkRhdGUgKEQ6MjAwNDA0MTMxMDA0MzErMDUnMzAnKQ0KPj4NCmVuZG9iag0KDQp4 cmVmDQowIDI1DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMTcgMDAwMDAgbg0KMDAw MDAwNDExNiAwMDAwMCBuDQowMDAwMDA0MTQzIDAwMDAwIG4NCjAwMDAwMDQ0OTUgMDAwMDAg bg0KMDAwMDAwNDUyMSAwMDAwMCBuDQowMDAwMDE0NTg3IDAwMDAwIG4NCjAwMDAwNzI1NzIg MDAwMDAgbg0KMDAwMDAxNDYxMiAwMDAwMCBuDQowMDAwMDE0NzE5IDAwMDAwIG4NCjAwMDAw MTQ4MjYgMDAwMDAgbg0KMDAwMDA0NTQwNiAwMDAwMCBuDQowMDAwMDQ1NDMzIDAwMDAwIG4N CjAwMDAwNDU2ODMgMDAwMDAgbg0KMDAwMDA0NjI4MCAwMDAwMCBuDQowMDAwMDQ2Nzk0IDAw MDAwIG4NCjAwMDAwNzExMTYgMDAwMDAgbg0KMDAwMDA3MTE0MyAwMDAwMCBuDQowMDAwMDcx Mzk4IDAwMDAwIG4NCjAwMDAwNzE5MjcgMDAwMDAgbg0KMDAwMDA3MjM3MCAwMDAwMCBuDQow MDAwMDcyNDI3IDAwMDAwIG4NCjAwMDAwNzI0NjkgMDAwMDAgbg0KMDAwMDA3MjcyNyAwMDAw MCBuDQowMDAwMDcyNzg3IDAwMDAwIG4NCnRyYWlsZXINCjw8IC9TaXplIDI1DQogICAvUm9v dCAyMyAwIFINCiAgIC9JbmZvIDI0IDAgUg0KPj4NCnN0YXJ0eHJlZg0KNzI5NTMNCiUlRU9G DQo= --------------020907060404030208020108-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Apr 14 05:58:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12922 for ; Wed, 14 Apr 2004 05:58:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDh0w-0005IU-1R; Wed, 14 Apr 2004 05:49:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDgpj-0002r2-Co for megaco@optimus.ietf.org; Wed, 14 Apr 2004 05:37:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12037 for ; Wed, 14 Apr 2004 05:37:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDgpf-0004XV-00 for megaco@ietf.org; Wed, 14 Apr 2004 05:37:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDgoj-0004RC-00 for megaco@ietf.org; Wed, 14 Apr 2004 05:36:26 -0400 Received: from sym.gdsz.cncnet.net ([210.21.224.29] helo=szsmtp.utstar.com.cn) by ietf-mx with esmtp (Exim 4.12) id 1BDgnw-00048Z-00 for megaco@ietf.org; Wed, 14 Apr 2004 05:35:36 -0400 Received: from SZVSAATTO ([172.19.18.87]) by szsmtp.utstar.com.cn (8.11.6/8.11.1) with SMTP id i3E9YB631287 for ; Wed, 14 Apr 2004 17:34:11 +0800 Message-ID: <046901c42203$963a35a0$c801a8c0@cn.utstarcom.com> From: "atto" To: References: <009a01c42055$6d9a3c30$f904120a@in.huawei.com> <407B4925.9070001@ericsson.com> Date: Wed, 14 Apr 2004 17:33:47 +0800 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Megaco] question about extension in serviceChangeParm Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi, I have a question about extension in serviceChangeParm. refer to RFC3525 : ------------------------------------------------------------- serviceChangeDescriptor = ServicesToken LBRKT serviceChangeParm *(COMMA serviceChangeParm) RBRKT ; each parameter at-most-once ; at most one of either serviceChangeAddress or serviceChangeMgcId ; but not both ; serviceChangeMethod and serviceChangeReason are REQUIRED serviceChangeParm = (serviceChangeMethod / serviceChangeReason / serviceChangeDelay / serviceChangeAddress / serviceChangeProfile / extension / TimeStamp / serviceChangeMgcId / serviceChangeVersion ) extension = extensionParameter parmValue ---------------------------------------------------------------------------- ----- does this means: it is a error when >1 extensions with differenet extensionParameters exist in one serviceChangeDescriptor ? such as message: MEGACO/1 Transaction=1{Context=-{ServiceChange=ROOT{Services{Method=Restart, X-VENDER=AAA, X-IDMETH=1, X-IDDATA=70da}}}} there are three extensions in serviceChangeDescriptor, so return 400? thanks atto _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Apr 14 06:17:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13658 for ; Wed, 14 Apr 2004 06:17:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDhJE-0000cz-Ra for megaco-archive@odin.ietf.org; Wed, 14 Apr 2004 06:07:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EA7u0p002408 for megaco-archive@odin.ietf.org; Wed, 14 Apr 2004 06:07:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDhAz-0006rd-W0 for megaco-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 05:59:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12959 for ; Wed, 14 Apr 2004 05:59:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDhAw-0007Ix-00 for megaco-web-archive@ietf.org; Wed, 14 Apr 2004 05:59:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDhA1-0007DF-00 for megaco-web-archive@ietf.org; Wed, 14 Apr 2004 05:58:26 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDh9c-00077S-00 for megaco-web-archive@ietf.org; Wed, 14 Apr 2004 05:58:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDh0w-0005IU-1R; Wed, 14 Apr 2004 05:49:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDgpj-0002r2-Co for megaco@optimus.ietf.org; Wed, 14 Apr 2004 05:37:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12037 for ; Wed, 14 Apr 2004 05:37:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDgpf-0004XV-00 for megaco@ietf.org; Wed, 14 Apr 2004 05:37:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDgoj-0004RC-00 for megaco@ietf.org; Wed, 14 Apr 2004 05:36:26 -0400 Received: from sym.gdsz.cncnet.net ([210.21.224.29] helo=szsmtp.utstar.com.cn) by ietf-mx with esmtp (Exim 4.12) id 1BDgnw-00048Z-00 for megaco@ietf.org; Wed, 14 Apr 2004 05:35:36 -0400 Received: from SZVSAATTO ([172.19.18.87]) by szsmtp.utstar.com.cn (8.11.6/8.11.1) with SMTP id i3E9YB631287 for ; Wed, 14 Apr 2004 17:34:11 +0800 Message-ID: <046901c42203$963a35a0$c801a8c0@cn.utstarcom.com> From: "atto" To: References: <009a01c42055$6d9a3c30$f904120a@in.huawei.com> <407B4925.9070001@ericsson.com> Date: Wed, 14 Apr 2004 17:33:47 +0800 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [Megaco] question about extension in serviceChangeParm Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi, I have a question about extension in serviceChangeParm. refer to RFC3525 : ------------------------------------------------------------- serviceChangeDescriptor = ServicesToken LBRKT serviceChangeParm *(COMMA serviceChangeParm) RBRKT ; each parameter at-most-once ; at most one of either serviceChangeAddress or serviceChangeMgcId ; but not both ; serviceChangeMethod and serviceChangeReason are REQUIRED serviceChangeParm = (serviceChangeMethod / serviceChangeReason / serviceChangeDelay / serviceChangeAddress / serviceChangeProfile / extension / TimeStamp / serviceChangeMgcId / serviceChangeVersion ) extension = extensionParameter parmValue ---------------------------------------------------------------------------- ----- does this means: it is a error when >1 extensions with differenet extensionParameters exist in one serviceChangeDescriptor ? such as message: MEGACO/1 Transaction=1{Context=-{ServiceChange=ROOT{Services{Method=Restart, X-VENDER=AAA, X-IDMETH=1, X-IDDATA=70da}}}} there are three extensions in serviceChangeDescriptor, so return 400? thanks atto _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Apr 14 15:32:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18191 for ; Wed, 14 Apr 2004 15:32:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDq1K-0001xz-6G; Wed, 14 Apr 2004 15:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDpv5-0007l7-2n for megaco@optimus.ietf.org; Wed, 14 Apr 2004 15:19:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17074 for ; Wed, 14 Apr 2004 15:19:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDpv3-0001UL-00 for megaco@ietf.org; Wed, 14 Apr 2004 15:19:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDpu6-0001S9-00 for megaco@ietf.org; Wed, 14 Apr 2004 15:18:35 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1BDptU-0001OW-00 for megaco@ietf.org; Wed, 14 Apr 2004 15:17:56 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3EJHOT06299 for ; Wed, 14 Apr 2004 15:17:24 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Apr 2004 15:17:25 -0400 Message-ID: From: "Kevin Boyle" To: atto , megaco@ietf.org Subject: RE: [Megaco] question about extension in serviceChangeParm Date: Wed, 14 Apr 2004 15:17:22 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Correct. "At-most-once" means no duplicates. In this case, the definition clearly forbids more than one extension in a given ServiceChange descriptor. Now, whether or not this was the intent here is a different question... Kevin -----Original Message----- From: atto [mailto:atto.mu@utstar.com] Sent: Wednesday, April 14, 2004 5:34 AM To: megaco@ietf.org Subject: [Megaco] question about extension in serviceChangeParm hi, I have a question about extension in serviceChangeParm. refer to RFC3525 : ------------------------------------------------------------- serviceChangeDescriptor = ServicesToken LBRKT serviceChangeParm *(COMMA serviceChangeParm) RBRKT ; each parameter at-most-once ; at most one of either serviceChangeAddress or serviceChangeMgcId ; but not both ; serviceChangeMethod and serviceChangeReason are REQUIRED serviceChangeParm = (serviceChangeMethod / serviceChangeReason / serviceChangeDelay / serviceChangeAddress / serviceChangeProfile / extension / TimeStamp / serviceChangeMgcId / serviceChangeVersion ) extension = extensionParameter parmValue ---------------------------------------------------------------------------- ----- does this means: it is a error when >1 extensions with differenet extensionParameters exist in one serviceChangeDescriptor ? such as message: MEGACO/1 Transaction=1{Context=-{ServiceChange=ROOT{Services{Method=Restart, X-VENDER=AAA, X-IDMETH=1, X-IDDATA=70da}}}} there are three extensions in serviceChangeDescriptor, so return 400? thanks atto _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Apr 14 16:13:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21379 for ; Wed, 14 Apr 2004 16:13:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDqF8-0008BO-Rj for megaco-archive@odin.ietf.org; Wed, 14 Apr 2004 15:40:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EJeI0t031437 for megaco-archive@odin.ietf.org; Wed, 14 Apr 2004 15:40:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDq8b-0003rj-FS for megaco-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 15:33:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18321 for ; Wed, 14 Apr 2004 15:33:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDq8a-0002YW-00 for megaco-web-archive@ietf.org; Wed, 14 Apr 2004 15:33:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDq7h-0002VJ-00 for megaco-web-archive@ietf.org; Wed, 14 Apr 2004 15:32:37 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDq6p-0002SG-00 for megaco-web-archive@ietf.org; Wed, 14 Apr 2004 15:31:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDq1K-0001xz-6G; Wed, 14 Apr 2004 15:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDpv5-0007l7-2n for megaco@optimus.ietf.org; Wed, 14 Apr 2004 15:19:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17074 for ; Wed, 14 Apr 2004 15:19:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDpv3-0001UL-00 for megaco@ietf.org; Wed, 14 Apr 2004 15:19:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDpu6-0001S9-00 for megaco@ietf.org; Wed, 14 Apr 2004 15:18:35 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1BDptU-0001OW-00 for megaco@ietf.org; Wed, 14 Apr 2004 15:17:56 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3EJHOT06299 for ; Wed, 14 Apr 2004 15:17:24 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Apr 2004 15:17:25 -0400 Message-ID: From: "Kevin Boyle" To: atto , megaco@ietf.org Subject: RE: [Megaco] question about extension in serviceChangeParm Date: Wed, 14 Apr 2004 15:17:22 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Correct. "At-most-once" means no duplicates. In this case, the definition clearly forbids more than one extension in a given ServiceChange descriptor. Now, whether or not this was the intent here is a different question... Kevin -----Original Message----- From: atto [mailto:atto.mu@utstar.com] Sent: Wednesday, April 14, 2004 5:34 AM To: megaco@ietf.org Subject: [Megaco] question about extension in serviceChangeParm hi, I have a question about extension in serviceChangeParm. refer to RFC3525 : ------------------------------------------------------------- serviceChangeDescriptor = ServicesToken LBRKT serviceChangeParm *(COMMA serviceChangeParm) RBRKT ; each parameter at-most-once ; at most one of either serviceChangeAddress or serviceChangeMgcId ; but not both ; serviceChangeMethod and serviceChangeReason are REQUIRED serviceChangeParm = (serviceChangeMethod / serviceChangeReason / serviceChangeDelay / serviceChangeAddress / serviceChangeProfile / extension / TimeStamp / serviceChangeMgcId / serviceChangeVersion ) extension = extensionParameter parmValue ---------------------------------------------------------------------------- ----- does this means: it is a error when >1 extensions with differenet extensionParameters exist in one serviceChangeDescriptor ? such as message: MEGACO/1 Transaction=1{Context=-{ServiceChange=ROOT{Services{Method=Restart, X-VENDER=AAA, X-IDMETH=1, X-IDDATA=70da}}}} there are three extensions in serviceChangeDescriptor, so return 400? thanks atto _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Apr 15 00:41:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17146 for ; Thu, 15 Apr 2004 00:41:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDyab-00044d-SW; Thu, 15 Apr 2004 00:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDyVp-00037e-8m for megaco@optimus.ietf.org; Thu, 15 Apr 2004 00:30:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16617 for ; Thu, 15 Apr 2004 00:30:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDyVm-0007iA-00 for megaco@ietf.org; Thu, 15 Apr 2004 00:30:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDyUn-0007ea-00 for megaco@ietf.org; Thu, 15 Apr 2004 00:29:02 -0400 Received: from [202.41.97.50] (helo=u1.doe.ernet.in) by ietf-mx with esmtp (Exim 4.12) id 1BDyUO-0007at-00 for megaco@ietf.org; Thu, 15 Apr 2004 00:28:36 -0400 Received: from uucp-relay-delhi.ernet.in (uucp-relay-delhi.ernet.in [202.41.97.134]) by u1.doe.ernet.in (8.12.8/8.12.8) with ESMTP id i3F4EbHi009447; Thu, 15 Apr 2004 09:44:42 +0530 Received: by uucp-relay-delhi.ernet.in (8.9.3+Sun/SMI-4.1-MHS-7.0) id KAA21672; Thu, 15 Apr 2004 10:09:30 -0500 (GMT) >Received: from cdotd.ernet.in by cdotd.cdotd.ernet.in (SMI-8.6/SMI-SVR4) id JAA01999; Thu, 15 Apr 2004 09:46:35 -0500 X-Authentication-Warning: relay.cdotd.ernet.in: iscan owned process doing -bs Message-ID: <407E0924.AF15A152@cdotd.ernet.in> Date: Thu, 15 Apr 2004 09:31:40 +0530 From: Prateek Raj Singh Organization: CDOT X-Mailer: Mozilla 4.73 [en] (X11; I; HP-UX B.11.00 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: megaco@ietf.org, prasenjitd@huawei.com References: <20040412160003.20094.99247.Mailman@www1.ietf.org> Received: from cdotd by vikram.eis.ernet.in; Thu, 15 Apr 2004 10:09 GMT Content-Type: multipart/alternative; boundary="------------3820B4002F6E09A00011A29D" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,HTML_MESSAGE, MSGID_FROM_MTA_HEADER autolearn=no version=2.60 Subject: [Megaco] Re: Megaco digest, Vol 1 #1133 - 2 msgs Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --------------3820B4002F6E09A00011A29D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi prasenjit , H.248.2 and megaco v2 are same stds for the media gateway control protocol . All the mandatory packages are same in both the stds, regards, Prateek uucp-relay-delhi!megaco-request@ietf.org wrote: > Send Megaco mailing list submissions to > megaco@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www1.ietf.org/mailman/listinfo/megaco > or, via email, send a message with subject or body 'help' to > megaco-request@ietf.org > > You can reach the person managing the list at > megaco-admin@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Megaco digest..." > > Today's Topics: > > 1. MEGACO/H.248 Is there any difference ? (Prasenjit Das) > 2. (no subject) (Viral Harsora) > > --__--__-- > > Message: 1 > Date: Mon, 12 Apr 2004 11:44:34 +0530 > From: Prasenjit Das > To: megaco@ietf.org > Reply-to: Prasenjit Das > Organization: Huawei > Subject: [Megaco] MEGACO/H.248 Is there any difference ? > > Hi , > I would like to know if there is any difference between MEGACO 1.0 and > H.248 protocol. I read that this is published by IETF and ITU-T respectively > of the jointly developed standard. I think as per protocol wise there is no > difference. But some body told me that there is some difference for some > package support. > Could anybody confirm that. I will be greatly benefited by this info. > Thanks in advance. > Regards, > Prasenjit > > Email Privacy Declaration > ***************************************************************** > This e-mail and its attachments contain confidential information from > HUAWEI, which is intended only for the person or entity whose address is > listed above. Any use of the information contained herein in any way > (including, but not limited to, total or partial disclosure, reproduction, > or dissemination) by persons other than the intended recipient(s) is > prohibited. If you receive this e-mail in error, please notify the sender by > phone or email immediately and delete it! > ***************************************************************** > > --__--__-- > > Message: 2 > From: Viral Harsora > To: megaco@ietf.org > Date: Mon, 12 Apr 2004 17:05:51 +0530 > Subject: [Megaco] (no subject) > > Dear All, > Can some one suggest a Book covering Megaco / H.248 in detail including > concepts, architecture, call flows, Interworking etc. > > Thanks & Regards, > Viral. > > --__--__-- > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > > End of Megaco Digest -- PRATEEK RAJ SINGH PAWAR Research Engineer Mobile Solutions C-DOT Ph(O):24677525 ext. 324 Room No 824,9th Floor Cell : +919810652039 Akber Bhavan ,Chankya mail :pprateekraj@yahoo Puri , New Delhi-21 pratraj@rediff ---------------------------------------------------------------------------- --------------3820B4002F6E09A00011A29D Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi  prasenjit ,

H.248.2  and megaco v2 are same  stds  for the media gateway control protocol .
All the mandatory packages are same in both the stds,

regards,
Prateek

uucp-relay-delhi!megaco-request@ietf.org wrote:

Send Megaco mailing list submissions to
        megaco@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://www1.ietf.org/mailman/listinfo/megaco
or, via email, send a message with subject or body 'help' to
        megaco-request@ietf.org

You can reach the person managing the list at
        megaco-admin@ietf.org

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

Today's Topics:

   1. MEGACO/H.248 Is there any difference ? (Prasenjit Das)
   2. (no subject) (Viral Harsora)

--__--__--

Message: 1
Date: Mon, 12 Apr 2004 11:44:34 +0530
From: Prasenjit Das <prasenjitd@huawei.com>
To: megaco@ietf.org
Reply-to: Prasenjit Das <prasenjitd@huawei.com>
Organization: Huawei
Subject: [Megaco] MEGACO/H.248 Is there any difference ?

Hi ,
   I would like to know if there is any difference between MEGACO 1.0 and
H.248 protocol. I read that this is published by IETF and ITU-T respectively
of the jointly developed standard. I think as per protocol wise there is no
difference. But some body told me that there is some difference for some
package support.
Could anybody confirm that. I will be greatly benefited by this info.
Thanks in advance.
Regards,
Prasenjit

Email Privacy Declaration
*****************************************************************
This e-mail and its attachments contain confidential information from
HUAWEI, which is intended only for the person or entity whose address is
listed above. Any use of the information contained herein in any way
(including, but not limited to, total or partial disclosure, reproduction,
or dissemination) by persons other than the intended recipient(s) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!
*****************************************************************

--__--__--

Message: 2
From: Viral Harsora <Viral.Harsora@ril.com>
To: megaco@ietf.org
Date: Mon, 12 Apr 2004 17:05:51 +0530
Subject: [Megaco] (no subject)

Dear All,
Can some one suggest a Book covering Megaco / H.248 in detail including
concepts, architecture, call flows, Interworking etc.

Thanks & Regards,
Viral.

--__--__--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

End of Megaco Digest

-- 

PRATEEK RAJ SINGH PAWAR 
  Research Engineer 
   Mobile Solutions   
      C-DOT            Ph(O):24677525 ext. 324
Room No 824,9th Floor  Cell : +919810652039
Akber Bhavan ,Chankya  mail :pprateekraj@yahoo
Puri ,  New Delhi-21         pratraj@rediff 
----------------------------------------------------------------------------
  --------------3820B4002F6E09A00011A29D-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Apr 15 00:45:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17334 for ; Thu, 15 Apr 2004 00:45:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDyiU-0006Oi-Pr for megaco-archive@odin.ietf.org; Thu, 15 Apr 2004 00:43:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3F4hAN0024592 for megaco-archive@odin.ietf.org; Thu, 15 Apr 2004 00:43:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDyiA-00065Q-Ru for megaco-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 00:42:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17173 for ; Thu, 15 Apr 2004 00:42:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDyi8-0000ku-00 for megaco-web-archive@ietf.org; Thu, 15 Apr 2004 00:42:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDyhB-0000iG-00 for megaco-web-archive@ietf.org; Thu, 15 Apr 2004 00:41:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDygh-0000gA-00 for megaco-web-archive@ietf.org; Thu, 15 Apr 2004 00:41:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDyab-00044d-SW; Thu, 15 Apr 2004 00:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDyVp-00037e-8m for megaco@optimus.ietf.org; Thu, 15 Apr 2004 00:30:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16617 for ; Thu, 15 Apr 2004 00:30:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDyVm-0007iA-00 for megaco@ietf.org; Thu, 15 Apr 2004 00:30:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDyUn-0007ea-00 for megaco@ietf.org; Thu, 15 Apr 2004 00:29:02 -0400 Received: from [202.41.97.50] (helo=u1.doe.ernet.in) by ietf-mx with esmtp (Exim 4.12) id 1BDyUO-0007at-00 for megaco@ietf.org; Thu, 15 Apr 2004 00:28:36 -0400 Received: from uucp-relay-delhi.ernet.in (uucp-relay-delhi.ernet.in [202.41.97.134]) by u1.doe.ernet.in (8.12.8/8.12.8) with ESMTP id i3F4EbHi009447; Thu, 15 Apr 2004 09:44:42 +0530 Received: by uucp-relay-delhi.ernet.in (8.9.3+Sun/SMI-4.1-MHS-7.0) id KAA21672; Thu, 15 Apr 2004 10:09:30 -0500 (GMT) >Received: from cdotd.ernet.in by cdotd.cdotd.ernet.in (SMI-8.6/SMI-SVR4) id JAA01999; Thu, 15 Apr 2004 09:46:35 -0500 X-Authentication-Warning: relay.cdotd.ernet.in: iscan owned process doing -bs Message-ID: <407E0924.AF15A152@cdotd.ernet.in> Date: Thu, 15 Apr 2004 09:31:40 +0530 From: Prateek Raj Singh Organization: CDOT X-Mailer: Mozilla 4.73 [en] (X11; I; HP-UX B.11.00 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: megaco@ietf.org, prasenjitd@huawei.com References: <20040412160003.20094.99247.Mailman@www1.ietf.org> Received: from cdotd by vikram.eis.ernet.in; Thu, 15 Apr 2004 10:09 GMT Content-Type: multipart/alternative; boundary="------------3820B4002F6E09A00011A29D" Subject: [Megaco] Re: Megaco digest, Vol 1 #1133 - 2 msgs Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,HTML_MESSAGE, MSGID_FROM_MTA_HEADER autolearn=no version=2.60 --------------3820B4002F6E09A00011A29D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi prasenjit , H.248.2 and megaco v2 are same stds for the media gateway control protocol . All the mandatory packages are same in both the stds, regards, Prateek uucp-relay-delhi!megaco-request@ietf.org wrote: > Send Megaco mailing list submissions to > megaco@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www1.ietf.org/mailman/listinfo/megaco > or, via email, send a message with subject or body 'help' to > megaco-request@ietf.org > > You can reach the person managing the list at > megaco-admin@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Megaco digest..." > > Today's Topics: > > 1. MEGACO/H.248 Is there any difference ? (Prasenjit Das) > 2. (no subject) (Viral Harsora) > > --__--__-- > > Message: 1 > Date: Mon, 12 Apr 2004 11:44:34 +0530 > From: Prasenjit Das > To: megaco@ietf.org > Reply-to: Prasenjit Das > Organization: Huawei > Subject: [Megaco] MEGACO/H.248 Is there any difference ? > > Hi , > I would like to know if there is any difference between MEGACO 1.0 and > H.248 protocol. I read that this is published by IETF and ITU-T respectively > of the jointly developed standard. I think as per protocol wise there is no > difference. But some body told me that there is some difference for some > package support. > Could anybody confirm that. I will be greatly benefited by this info. > Thanks in advance. > Regards, > Prasenjit > > Email Privacy Declaration > ***************************************************************** > This e-mail and its attachments contain confidential information from > HUAWEI, which is intended only for the person or entity whose address is > listed above. Any use of the information contained herein in any way > (including, but not limited to, total or partial disclosure, reproduction, > or dissemination) by persons other than the intended recipient(s) is > prohibited. If you receive this e-mail in error, please notify the sender by > phone or email immediately and delete it! > ***************************************************************** > > --__--__-- > > Message: 2 > From: Viral Harsora > To: megaco@ietf.org > Date: Mon, 12 Apr 2004 17:05:51 +0530 > Subject: [Megaco] (no subject) > > Dear All, > Can some one suggest a Book covering Megaco / H.248 in detail including > concepts, architecture, call flows, Interworking etc. > > Thanks & Regards, > Viral. > > --__--__-- > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > > End of Megaco Digest -- PRATEEK RAJ SINGH PAWAR Research Engineer Mobile Solutions C-DOT Ph(O):24677525 ext. 324 Room No 824,9th Floor Cell : +919810652039 Akber Bhavan ,Chankya mail :pprateekraj@yahoo Puri , New Delhi-21 pratraj@rediff ---------------------------------------------------------------------------- --------------3820B4002F6E09A00011A29D Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi  prasenjit ,

H.248.2  and megaco v2 are same  stds  for the media gateway control protocol .
All the mandatory packages are same in both the stds,

regards,
Prateek

uucp-relay-delhi!megaco-request@ietf.org wrote:

Send Megaco mailing list submissions to
        megaco@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://www1.ietf.org/mailman/listinfo/megaco
or, via email, send a message with subject or body 'help' to
        megaco-request@ietf.org

You can reach the person managing the list at
        megaco-admin@ietf.org

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

Today's Topics:

   1. MEGACO/H.248 Is there any difference ? (Prasenjit Das)
   2. (no subject) (Viral Harsora)

--__--__--

Message: 1
Date: Mon, 12 Apr 2004 11:44:34 +0530
From: Prasenjit Das <prasenjitd@huawei.com>
To: megaco@ietf.org
Reply-to: Prasenjit Das <prasenjitd@huawei.com>
Organization: Huawei
Subject: [Megaco] MEGACO/H.248 Is there any difference ?

Hi ,
   I would like to know if there is any difference between MEGACO 1.0 and
H.248 protocol. I read that this is published by IETF and ITU-T respectively
of the jointly developed standard. I think as per protocol wise there is no
difference. But some body told me that there is some difference for some
package support.
Could anybody confirm that. I will be greatly benefited by this info.
Thanks in advance.
Regards,
Prasenjit

Email Privacy Declaration
*****************************************************************
This e-mail and its attachments contain confidential information from
HUAWEI, which is intended only for the person or entity whose address is
listed above. Any use of the information contained herein in any way
(including, but not limited to, total or partial disclosure, reproduction,
or dissemination) by persons other than the intended recipient(s) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!
*****************************************************************

--__--__--

Message: 2
From: Viral Harsora <Viral.Harsora@ril.com>
To: megaco@ietf.org
Date: Mon, 12 Apr 2004 17:05:51 +0530
Subject: [Megaco] (no subject)

Dear All,
Can some one suggest a Book covering Megaco / H.248 in detail including
concepts, architecture, call flows, Interworking etc.

Thanks & Regards,
Viral.

--__--__--

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

End of Megaco Digest

-- 

PRATEEK RAJ SINGH PAWAR 
  Research Engineer 
   Mobile Solutions   
      C-DOT            Ph(O):24677525 ext. 324
Room No 824,9th Floor  Cell : +919810652039
Akber Bhavan ,Chankya  mail :pprateekraj@yahoo
Puri ,  New Delhi-21         pratraj@rediff 
----------------------------------------------------------------------------
  --------------3820B4002F6E09A00011A29D-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Apr 15 08:55:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20656 for ; Thu, 15 Apr 2004 08:55:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE6Jf-0005Ga-BF; Thu, 15 Apr 2004 08:50:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE62J-0006ac-EQ for megaco@optimus.ietf.org; Thu, 15 Apr 2004 08:32:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19336 for ; Thu, 15 Apr 2004 08:32:05 -0400 (EDT) From: Dana.Herskowitz@veraznetworks.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE62I-00047r-00 for megaco@ietf.org; Thu, 15 Apr 2004 08:32:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE61P-00042T-00 for megaco@ietf.org; Thu, 15 Apr 2004 08:31:11 -0400 Received: from vlib.ecitele.com ([147.234.1.11] helo=ilsmtp01.ecitele.com) by ietf-mx with esmtp (Exim 4.12) id 1BE60X-0003yO-00 for megaco@ietf.org; Thu, 15 Apr 2004 08:30:19 -0400 To: megaco@ietf.org Cc: Ilana.Leibovitch@veraznetworks.com X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 Message-ID: Date: Thu, 15 Apr 2004 15:29:46 +0300 X-MIMETrack: Serialize by Router on ILSMTP01/ECI Telecom(Release 6.5|September 18, 2003) at 04/15/2004 15:32:43 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Subject: [Megaco] Failure of add command Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hello, Suppose the following: MEGACO/1 []: Transaction=1 {Context=$ {Add=${Media{LocalControl{Mode = SendOnly}}}} Suppose that MG fails to Add the termination to a specific context (although the creation of the context has succeeded). Where should be the Error descriptor? Option 1 - On the whole Action (as there is no point in creating an empty specific context) Option 2 - On the Add command (as only it has failed) Regards, Dana H. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Apr 15 09:19:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22333 for ; Thu, 15 Apr 2004 09:19:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE6dF-0006NT-2C for megaco-archive@odin.ietf.org; Thu, 15 Apr 2004 09:10:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FDAHjc024507 for megaco-archive@odin.ietf.org; Thu, 15 Apr 2004 09:10:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE6Xi-0003iA-DT for megaco-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 09:04:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21108 for ; Thu, 15 Apr 2004 09:04:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE6Xg-0007Hn-00 for megaco-web-archive@ietf.org; Thu, 15 Apr 2004 09:04:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE6Vm-0006ta-00 for megaco-web-archive@ietf.org; Thu, 15 Apr 2004 09:02:35 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BE6V9-0006lP-03 for megaco-web-archive@ietf.org; Thu, 15 Apr 2004 09:01:56 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BE6Of-0001f4-Qr for megaco-web-archive@ietf.org; Thu, 15 Apr 2004 08:55:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE6Jf-0005Ga-BF; Thu, 15 Apr 2004 08:50:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE62J-0006ac-EQ for megaco@optimus.ietf.org; Thu, 15 Apr 2004 08:32:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19336 for ; Thu, 15 Apr 2004 08:32:05 -0400 (EDT) From: Dana.Herskowitz@veraznetworks.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE62I-00047r-00 for megaco@ietf.org; Thu, 15 Apr 2004 08:32:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE61P-00042T-00 for megaco@ietf.org; Thu, 15 Apr 2004 08:31:11 -0400 Received: from vlib.ecitele.com ([147.234.1.11] helo=ilsmtp01.ecitele.com) by ietf-mx with esmtp (Exim 4.12) id 1BE60X-0003yO-00 for megaco@ietf.org; Thu, 15 Apr 2004 08:30:19 -0400 To: megaco@ietf.org Cc: Ilana.Leibovitch@veraznetworks.com X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 Message-ID: Date: Thu, 15 Apr 2004 15:29:46 +0300 X-MIMETrack: Serialize by Router on ILSMTP01/ECI Telecom(Release 6.5|September 18, 2003) at 04/15/2004 15:32:43 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [Megaco] Failure of add command Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Hello, Suppose the following: MEGACO/1 []: Transaction=1 {Context=$ {Add=${Media{LocalControl{Mode = SendOnly}}}} Suppose that MG fails to Add the termination to a specific context (although the creation of the context has succeeded). Where should be the Error descriptor? Option 1 - On the whole Action (as there is no point in creating an empty specific context) Option 2 - On the Add command (as only it has failed) Regards, Dana H. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Apr 15 09:47:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23766 for ; Thu, 15 Apr 2004 09:47:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE72B-0005t2-72; Thu, 15 Apr 2004 09:36:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE708-0004Ud-Rk for megaco@optimus.ietf.org; Thu, 15 Apr 2004 09:33:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23113 for ; Thu, 15 Apr 2004 09:33:53 -0400 (EDT) From: bvswamy@hss.hns.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE706-0002XN-00 for megaco@ietf.org; Thu, 15 Apr 2004 09:33:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE6yT-0002Tf-00 for megaco@ietf.org; Thu, 15 Apr 2004 09:32:13 -0400 Received: from spark.hss.co.in ([203.200.71.140]) by ietf-mx with esmtp (Exim 4.12) id 1BE6xu-0002K4-00 for megaco@ietf.org; Thu, 15 Apr 2004 09:31:39 -0400 Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id i3FDTrd8021335; Thu, 15 Apr 2004 18:59:53 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id i3FDVrh00285; Thu, 15 Apr 2004 19:01:53 +0530 (IST) Subject: Re: [Megaco] Failure of add command To: Dana.Herskowitz@veraznetworks.com Cc: megaco@ietf.org, Ilana.Leibovitch@veraznetworks.com Date: Thu, 15 Apr 2004 18:56:50 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 15/04/2004 06:50:27 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.2 required=5.0 tests=NO_REAL_NAME, ROUND_THE_WORLD_LOCAL autolearn=no version=2.60 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi Dana You can return a command level error descriptor (option 2) with a context id as $, since MG might have deleted the newly created context on add failure. Regards Venkat Hughes Software Systems www.hssworld.com Dana.Herskowitz@veraznetworks.com@ietf.org on 04/15/2004 05:59:46 PM Sent by: megaco-admin@ietf.org To: megaco@ietf.org cc: Ilana.Leibovitch@veraznetworks.com Subject: [Megaco] Failure of add command Hello, Suppose the following: MEGACO/1 []: Transaction=1 {Context=$ {Add=${Media{LocalControl{Mode = SendOnly}}}} Suppose that MG fails to Add the termination to a specific context (although the creation of the context has succeeded). Where should be the Error descriptor? Option 1 - On the whole Action (as there is no point in creating an empty specific context) Option 2 - On the Add command (as only it has failed) Regards, Dana H. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Apr 15 10:07:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25095 for ; Thu, 15 Apr 2004 10:07:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7LO-0004wV-F1 for megaco-archive@odin.ietf.org; Thu, 15 Apr 2004 09:55:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FDtsJw018995 for megaco-archive@odin.ietf.org; Thu, 15 Apr 2004 09:55:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE7Eq-0002vx-3Q for megaco-web-archive@optimus.ietf.org; Thu, 15 Apr 2004 09:49:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23807 for ; Thu, 15 Apr 2004 09:49:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE7Eo-0003zo-00 for megaco-web-archive@ietf.org; Thu, 15 Apr 2004 09:49:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE7Dq-0003sl-00 for megaco-web-archive@ietf.org; Thu, 15 Apr 2004 09:48:06 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BE7Cw-0003ni-00 for megaco-web-archive@ietf.org; Thu, 15 Apr 2004 09:47:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE72B-0005t2-72; Thu, 15 Apr 2004 09:36:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE708-0004Ud-Rk for megaco@optimus.ietf.org; Thu, 15 Apr 2004 09:33:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23113 for ; Thu, 15 Apr 2004 09:33:53 -0400 (EDT) From: bvswamy@hss.hns.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE706-0002XN-00 for megaco@ietf.org; Thu, 15 Apr 2004 09:33:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE6yT-0002Tf-00 for megaco@ietf.org; Thu, 15 Apr 2004 09:32:13 -0400 Received: from spark.hss.co.in ([203.200.71.140]) by ietf-mx with esmtp (Exim 4.12) id 1BE6xu-0002K4-00 for megaco@ietf.org; Thu, 15 Apr 2004 09:31:39 -0400 Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id i3FDTrd8021335; Thu, 15 Apr 2004 18:59:53 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id i3FDVrh00285; Thu, 15 Apr 2004 19:01:53 +0530 (IST) Subject: Re: [Megaco] Failure of add command To: Dana.Herskowitz@veraznetworks.com Cc: megaco@ietf.org, Ilana.Leibovitch@veraznetworks.com Date: Thu, 15 Apr 2004 18:56:50 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 15/04/2004 06:50:27 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.8 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Hi Dana You can return a command level error descriptor (option 2) with a context id as $, since MG might have deleted the newly created context on add failure. Regards Venkat Hughes Software Systems www.hssworld.com Dana.Herskowitz@veraznetworks.com@ietf.org on 04/15/2004 05:59:46 PM Sent by: megaco-admin@ietf.org To: megaco@ietf.org cc: Ilana.Leibovitch@veraznetworks.com Subject: [Megaco] Failure of add command Hello, Suppose the following: MEGACO/1 []: Transaction=1 {Context=$ {Add=${Media{LocalControl{Mode = SendOnly}}}} Suppose that MG fails to Add the termination to a specific context (although the creation of the context has succeeded). Where should be the Error descriptor? Option 1 - On the whole Action (as there is no point in creating an empty specific context) Option 2 - On the Add command (as only it has failed) Regards, Dana H. _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Apr 16 10:13:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11196 for ; Fri, 16 Apr 2004 10:13:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BETxr-0006oN-58; Fri, 16 Apr 2004 10:05:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEPxz-0003VD-34 for megaco@optimus.ietf.org; Fri, 16 Apr 2004 05:48:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26407 for ; Fri, 16 Apr 2004 05:48:55 -0400 (EDT) From: liu.qifeng@zte.com.cn Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEPxv-000332-GE for megaco@ietf.org; Fri, 16 Apr 2004 05:48:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEPwx-0002y8-00 for megaco@ietf.org; Fri, 16 Apr 2004 05:47:56 -0400 Received: from [210.21.227.66] (helo=mail2.zte.com.cn) by ietf-mx with esmtp (Exim 4.12) id 1BEPvz-0002oO-00 for megaco@ietf.org; Fri, 16 Apr 2004 05:46:56 -0400 Subject: RE: [Megaco] question about extension in serviceChangeParm To: megaco@ietf.org Cc: kboyle@nortelnetworks.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Fri, 16 Apr 2004 17:45:33 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 5.0.10 |March 22, 2002) at 2004-04-16 17:49:30 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , I think the extensionParameter in Megaco need not be conformance with the restriction of At Most Once,the extensionParameter is available for different vender,it is uncertainty. if it is at most once ,the use of the extensionParameter will be restricted.maybe later the extensionParameter will be the Confirmed parameter if the extensionParameter is accepted by people . BTW: rfc3525 page 122 have a case ; at-most-once except for extensionParameter thanks and regards! liuqifeng _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri Apr 16 10:25:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12087 for ; Fri, 16 Apr 2004 10:25:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEU8z-0003wQ-Ba for megaco-archive@odin.ietf.org; Fri, 16 Apr 2004 10:16:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GEGbUB015144 for megaco-archive@odin.ietf.org; Fri, 16 Apr 2004 10:16:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEU7o-0003MK-Ec for megaco-web-archive@optimus.ietf.org; Fri, 16 Apr 2004 10:15:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11367 for ; Fri, 16 Apr 2004 10:15:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEU7m-0000bg-76 for megaco-web-archive@ietf.org; Fri, 16 Apr 2004 10:15:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEU6d-0000ZK-00 for megaco-web-archive@ietf.org; Fri, 16 Apr 2004 10:14:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BEU5x-0000XV-00 for megaco-web-archive@ietf.org; Fri, 16 Apr 2004 10:13:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BETxr-0006oN-58; Fri, 16 Apr 2004 10:05:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEPxz-0003VD-34 for megaco@optimus.ietf.org; Fri, 16 Apr 2004 05:48:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26407 for ; Fri, 16 Apr 2004 05:48:55 -0400 (EDT) From: liu.qifeng@zte.com.cn Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEPxv-000332-GE for megaco@ietf.org; Fri, 16 Apr 2004 05:48:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEPwx-0002y8-00 for megaco@ietf.org; Fri, 16 Apr 2004 05:47:56 -0400 Received: from [210.21.227.66] (helo=mail2.zte.com.cn) by ietf-mx with esmtp (Exim 4.12) id 1BEPvz-0002oO-00 for megaco@ietf.org; Fri, 16 Apr 2004 05:46:56 -0400 Subject: RE: [Megaco] question about extension in serviceChangeParm To: megaco@ietf.org Cc: kboyle@nortelnetworks.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Fri, 16 Apr 2004 17:45:33 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 5.0.10 |March 22, 2002) at 2004-04-16 17:49:30 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 I think the extensionParameter in Megaco need not be conformance with the restriction of At Most Once,the extensionParameter is available for different vender,it is uncertainty. if it is at most once ,the use of the extensionParameter will be restricted.maybe later the extensionParameter will be the Confirmed parameter if the extensionParameter is accepted by people . BTW: rfc3525 page 122 have a case ; at-most-once except for extensionParameter thanks and regards! liuqifeng _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Sat Apr 17 22:58:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11960 for ; Sat, 17 Apr 2004 22:58:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BF2Mr-0002Qk-0Q; Sat, 17 Apr 2004 22:49:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BF1y1-0000Pj-KN for megaco@optimus.ietf.org; Sat, 17 Apr 2004 22:23:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08980 for ; Sat, 17 Apr 2004 22:23:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BF1xy-0000DW-E8 for megaco@ietf.org; Sat, 17 Apr 2004 22:23:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BF1xA-00002Q-00 for megaco@ietf.org; Sat, 17 Apr 2004 22:22:40 -0400 Received: from sym.gdsz.cncnet.net ([210.21.224.29] helo=szsmtp.utstar.com.cn) by ietf-mx with esmtp (Exim 4.12) id 1BF1wM-0007SJ-00 for megaco@ietf.org; Sat, 17 Apr 2004 22:21:51 -0400 Received: from SZVSAATTO ([172.19.18.87]) by szsmtp.utstar.com.cn (8.11.6/8.11.1) with SMTP id i3I2Kk627238; Sun, 18 Apr 2004 10:20:46 +0800 Message-ID: <086801c424eb$d83234e0$c801a8c0@cn.utstarcom.com> From: "atto" To: , Cc: References: Subject: Re: [Megaco] question about extension in serviceChangeParm Date: Sun, 18 Apr 2004 10:21:19 +0800 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi, It is really a good suggestion, and can make megaco more expansible. I hope it could be a part of next version. but now, if more than one extension in serviceChangeParm, there will be problem when interoperate with stacks that strictly comply with protocol. b.r. atto ----- Original Message ----- From: To: Cc: Sent: Friday, April 16, 2004 5:45 PM Subject: RE: [Megaco] question about extension in serviceChangeParm > > I think the extensionParameter in Megaco need not be conformance with the > restriction of At Most Once,the extensionParameter is available for > different vender,it is uncertainty. if it is at most once ,the use of the > extensionParameter will be restricted.maybe later the extensionParameter > will be the Confirmed parameter if the extensionParameter is accepted by > people . > BTW: > rfc3525 page 122 have a case > ; at-most-once except for extensionParameter > thanks and regards! > liuqifeng > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Sat Apr 17 23:11:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12534 for ; Sat, 17 Apr 2004 23:11:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BF2gI-00015T-UF for megaco-archive@odin.ietf.org; Sat, 17 Apr 2004 23:09:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3I39I9i004174 for megaco-archive@odin.ietf.org; Sat, 17 Apr 2004 23:09:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BF2X1-0005jr-DV for megaco-web-archive@optimus.ietf.org; Sat, 17 Apr 2004 22:59:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12028 for ; Sat, 17 Apr 2004 22:59:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BF2Wx-00001P-UX for megaco-web-archive@ietf.org; Sat, 17 Apr 2004 22:59:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BF2WA-0007fT-00 for megaco-web-archive@ietf.org; Sat, 17 Apr 2004 22:58:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BF2Ve-0007U3-00 for megaco-web-archive@ietf.org; Sat, 17 Apr 2004 22:58:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BF2Mr-0002Qk-0Q; Sat, 17 Apr 2004 22:49:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BF1y1-0000Pj-KN for megaco@optimus.ietf.org; Sat, 17 Apr 2004 22:23:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08980 for ; Sat, 17 Apr 2004 22:23:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BF1xy-0000DW-E8 for megaco@ietf.org; Sat, 17 Apr 2004 22:23:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BF1xA-00002Q-00 for megaco@ietf.org; Sat, 17 Apr 2004 22:22:40 -0400 Received: from sym.gdsz.cncnet.net ([210.21.224.29] helo=szsmtp.utstar.com.cn) by ietf-mx with esmtp (Exim 4.12) id 1BF1wM-0007SJ-00 for megaco@ietf.org; Sat, 17 Apr 2004 22:21:51 -0400 Received: from SZVSAATTO ([172.19.18.87]) by szsmtp.utstar.com.cn (8.11.6/8.11.1) with SMTP id i3I2Kk627238; Sun, 18 Apr 2004 10:20:46 +0800 Message-ID: <086801c424eb$d83234e0$c801a8c0@cn.utstarcom.com> From: "atto" To: , Cc: References: Subject: Re: [Megaco] question about extension in serviceChangeParm Date: Sun, 18 Apr 2004 10:21:19 +0800 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi, It is really a good suggestion, and can make megaco more expansible. I hope it could be a part of next version. but now, if more than one extension in serviceChangeParm, there will be problem when interoperate with stacks that strictly comply with protocol. b.r. atto ----- Original Message ----- From: To: Cc: Sent: Friday, April 16, 2004 5:45 PM Subject: RE: [Megaco] question about extension in serviceChangeParm > > I think the extensionParameter in Megaco need not be conformance with the > restriction of At Most Once,the extensionParameter is available for > different vender,it is uncertainty. if it is at most once ,the use of the > extensionParameter will be restricted.maybe later the extensionParameter > will be the Confirmed parameter if the extensionParameter is accepted by > people . > BTW: > rfc3525 page 122 have a case > ; at-most-once except for extensionParameter > thanks and regards! > liuqifeng > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Sun Apr 18 23:49:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00965 for ; Sun, 18 Apr 2004 23:49:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFPhR-00046p-Mj; Sun, 18 Apr 2004 23:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFPg1-0003kR-3p for megaco@optimus.ietf.org; Sun, 18 Apr 2004 23:42:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00657 for ; Sun, 18 Apr 2004 23:42:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFPfy-0000Yk-Ug for megaco@ietf.org; Sun, 18 Apr 2004 23:42:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFPf1-0000L9-00 for megaco@ietf.org; Sun, 18 Apr 2004 23:41:31 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BFPeA-00007r-00 for megaco@ietf.org; Sun, 18 Apr 2004 23:40:39 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3J3ecPA024186 for ; Mon, 19 Apr 2004 05:40:38 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 19 Apr 2004 05:40:38 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JDLX8S1G; Mon, 19 Apr 2004 03:45:33 +0200 Received: from ericsson.com (sealwa04-202.sw.ericsson.se [130.100.249.202]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JDJMRFRH; Mon, 19 Apr 2004 11:45:13 +1000 Message-ID: <40832F2B.3010305@ericsson.com> Date: Mon, 19 Apr 2004 11:45:15 +1000 X-Sybari-Trust: 6bbe89b1 272a6e05 24fedf83 00000139 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atto CC: liu.qifeng@zte.com.cn, megaco@ietf.org, kboyle@nortelnetworks.com Subject: Re: [Megaco] question about extension in serviceChangeParm References: <086801c424eb$d83234e0$c801a8c0@cn.utstarcom.com> In-Reply-To: <086801c424eb$d83234e0$c801a8c0@cn.utstarcom.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Apr 2004 03:40:38.0348 (UTC) FILETIME=[14A458C0:01C425C0] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello, H.248.1v2 states: ; each parameter at-most-once ; at most one of either serviceChangeAddress or serviceChangeMgcId but ; not both ; serviceChangeMethod and serviceChangeReason are REQUIRED serviceChangeParm = (serviceChangeMethod / serviceChangeReason / serviceChangeDelay / serviceChangeAddress / serviceChangeProfile / extension / TimeStamp / serviceChangeMgcId / serviceChangeVersion / auditItem) So there's only one extension paramter. The parameter is basically an (octet)string that you can put vendor specific data in. You can format it however you like so if you want to carry multiple values then you carry these in the data field and seperate then in some vendor specific way. I would discourage the general use of this field as it does harm interoperability. Regards, Christian atto wrote: > hi, > It is really a good suggestion, and can make megaco more expansible. > I hope it could be a part of next version. > but now, if more than one extension in serviceChangeParm, > there will be problem when interoperate with stacks that strictly comply > with protocol. > > b.r. > atto > > ----- Original Message ----- > From: > To: > Cc: > Sent: Friday, April 16, 2004 5:45 PM > Subject: RE: [Megaco] question about extension in serviceChangeParm > > > >>I think the extensionParameter in Megaco need not be conformance with the >>restriction of At Most Once,the extensionParameter is available for >>different vender,it is uncertainty. if it is at most once ,the use of the >>extensionParameter will be restricted.maybe later the extensionParameter >>will be the Confirmed parameter if the extensionParameter is accepted by >>people . >>BTW: >>rfc3525 page 122 have a case >> ; at-most-once except for extensionParameter >> thanks and regards! >> liuqifeng >> >> >> >>_______________________________________________ >>Megaco mailing list >>Megaco@ietf.org >>https://www1.ietf.org/mailman/listinfo/megaco > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Sun Apr 18 23:55:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01204 for ; Sun, 18 Apr 2004 23:55:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFPof-0005UA-Lc for megaco-archive@odin.ietf.org; Sun, 18 Apr 2004 23:51:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3J3pTt0021082 for megaco-archive@odin.ietf.org; Sun, 18 Apr 2004 23:51:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFPo0-0005IQ-GU for megaco-web-archive@optimus.ietf.org; Sun, 18 Apr 2004 23:50:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01026 for ; Sun, 18 Apr 2004 23:50:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFPny-0002Iz-7w for megaco-web-archive@ietf.org; Sun, 18 Apr 2004 23:50:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFPn9-00024o-00 for megaco-web-archive@ietf.org; Sun, 18 Apr 2004 23:49:56 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFPmZ-0001qp-00 for megaco-web-archive@ietf.org; Sun, 18 Apr 2004 23:49:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFPhR-00046p-Mj; Sun, 18 Apr 2004 23:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFPg1-0003kR-3p for megaco@optimus.ietf.org; Sun, 18 Apr 2004 23:42:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00657 for ; Sun, 18 Apr 2004 23:42:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFPfy-0000Yk-Ug for megaco@ietf.org; Sun, 18 Apr 2004 23:42:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFPf1-0000L9-00 for megaco@ietf.org; Sun, 18 Apr 2004 23:41:31 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BFPeA-00007r-00 for megaco@ietf.org; Sun, 18 Apr 2004 23:40:39 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3J3ecPA024186 for ; Mon, 19 Apr 2004 05:40:38 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 19 Apr 2004 05:40:38 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JDLX8S1G; Mon, 19 Apr 2004 03:45:33 +0200 Received: from ericsson.com (sealwa04-202.sw.ericsson.se [130.100.249.202]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JDJMRFRH; Mon, 19 Apr 2004 11:45:13 +1000 Message-ID: <40832F2B.3010305@ericsson.com> Date: Mon, 19 Apr 2004 11:45:15 +1000 X-Sybari-Trust: 6bbe89b1 272a6e05 24fedf83 00000139 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atto CC: liu.qifeng@zte.com.cn, megaco@ietf.org, kboyle@nortelnetworks.com Subject: Re: [Megaco] question about extension in serviceChangeParm References: <086801c424eb$d83234e0$c801a8c0@cn.utstarcom.com> In-Reply-To: <086801c424eb$d83234e0$c801a8c0@cn.utstarcom.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Apr 2004 03:40:38.0348 (UTC) FILETIME=[14A458C0:01C425C0] Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, H.248.1v2 states: ; each parameter at-most-once ; at most one of either serviceChangeAddress or serviceChangeMgcId but ; not both ; serviceChangeMethod and serviceChangeReason are REQUIRED serviceChangeParm = (serviceChangeMethod / serviceChangeReason / serviceChangeDelay / serviceChangeAddress / serviceChangeProfile / extension / TimeStamp / serviceChangeMgcId / serviceChangeVersion / auditItem) So there's only one extension paramter. The parameter is basically an (octet)string that you can put vendor specific data in. You can format it however you like so if you want to carry multiple values then you carry these in the data field and seperate then in some vendor specific way. I would discourage the general use of this field as it does harm interoperability. Regards, Christian atto wrote: > hi, > It is really a good suggestion, and can make megaco more expansible. > I hope it could be a part of next version. > but now, if more than one extension in serviceChangeParm, > there will be problem when interoperate with stacks that strictly comply > with protocol. > > b.r. > atto > > ----- Original Message ----- > From: > To: > Cc: > Sent: Friday, April 16, 2004 5:45 PM > Subject: RE: [Megaco] question about extension in serviceChangeParm > > > >>I think the extensionParameter in Megaco need not be conformance with the >>restriction of At Most Once,the extensionParameter is available for >>different vender,it is uncertainty. if it is at most once ,the use of the >>extensionParameter will be restricted.maybe later the extensionParameter >>will be the Confirmed parameter if the extensionParameter is accepted by >>people . >>BTW: >>rfc3525 page 122 have a case >> ; at-most-once except for extensionParameter >> thanks and regards! >> liuqifeng >> >> >> >>_______________________________________________ >>Megaco mailing list >>Megaco@ietf.org >>https://www1.ietf.org/mailman/listinfo/megaco > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Apr 19 01:57:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05036 for ; Mon, 19 Apr 2004 01:57:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFRjF-00049M-Q2; Mon, 19 Apr 2004 01:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFRj2-0003yM-BX for megaco@optimus.ietf.org; Mon, 19 Apr 2004 01:53:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04904 for ; Mon, 19 Apr 2004 01:53:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFRiy-0005sa-UN for megaco@ietf.org; Mon, 19 Apr 2004 01:53:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFRi8-0005eu-00 for megaco@ietf.org; Mon, 19 Apr 2004 01:52:53 -0400 Received: from [210.22.146.172] (helo=asbmx.sbell.com.cn) by ietf-mx with esmtp (Exim 4.12) id 1BFRhR-0005P9-00 for megaco@ietf.org; Mon, 19 Apr 2004 01:52:10 -0400 Received: from asbwebshld.sbell.com.cn (asbwebshld [172.24.208.38]) by asbmx.sbell.com.cn (8.12.10+Sun/8.12.3) with SMTP id i3J5ngMm007820 for ; Mon, 19 Apr 2004 13:49:48 +0800 (CST) Received: FROM bellnet-mail4.sbell.com.cn BY asbwebshld.sbell.com.cn ; Mon Apr 19 13:51:27 2004 +0800 Received: from bellnet-mail1.sbell.com.cn ([172.24.208.21]) by bellnet-mail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Mon, 19 Apr 2004 13:51:27 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C425D2.5ACA3467" Date: Mon, 19 Apr 2004 13:51:26 +0800 Message-ID: Thread-Topic: about add command failure Thread-Index: AcQl0lnuiuXk1Rz3Rrqq9jGsQJzniA== From: "FCG Huang Qiang (B300)" To: X-OriginalArrivalTime: 19 Apr 2004 05:51:27.0004 (UTC) FILETIME=[5ACE35C0:01C425D2] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_40_50, HTML_FONT_FACE_BAD,HTML_MESSAGE autolearn=no version=2.60 Subject: [Megaco] about add command failure Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C425D2.5ACA3467 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable hello! for the case gived: MEGACO/1 []: Transaction=3D1 {Context=3D$ {Add=3D${Media{LocalControl{Mode =3D = SendOnly}}}} wihle add command fail, then the termination will be deleted from the = context created successfully, and then MG will delete the empty context. But for another case: context contains two commands, show below: MEGACO/1 []: Transaction=3D1 {Context=3D$=20 {Add=3Dtdm/1/1/1{Media{LocalControl{Mode =3D SendReceive}}}, {Add=3D${Media{LocalControl{Mode =3D SendOnly}}} } while add tdm success and the second add command is failure, MGC and MG = how to process it? will MG detele the rtp terminater and still leave one tdm terminater in = the context created ? BR huangq ------_=_NextPart_001_01C425D2.5ACA3467 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable about add command failure

hello!
for the = case gived:
MEGACO/1 = [<IP>]:<port>
Transaction=3D1 {Context=3D$ = {Add=3D${Media{LocalControl{Mode =3D SendOnly}}}}
wihle add = command fail, then the termination will be deleted from the context = created successfully, and then MG will delete the empty = context.

But for = another case: context contains two commands, show below:
MEGACO/1 = [<IP>]:<port>
Transaction=3D1 {Context=3D$
{Add=3Dtdm/1/1/1{Media{LocalControl{Mode =3D = SendReceive}}},
{Add=3D${Media{LocalControl{Mode =3D = SendOnly}}}
}
while add = tdm success and the second add command is failure, MGC and MG how to = process it?
will MG = detele the rtp terminater and still leave one tdm terminater in the = context created ?

BR
huangq

------_=_NextPart_001_01C425D2.5ACA3467-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Mon Apr 19 02:03:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08991 for ; Mon, 19 Apr 2004 02:03:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFRpF-0005Sp-6d for megaco-archive@odin.ietf.org; Mon, 19 Apr 2004 02:00:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3J60D4P020997 for megaco-archive@odin.ietf.org; Mon, 19 Apr 2004 02:00:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFRo3-00055x-LH for megaco-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 01:58:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05086 for ; Mon, 19 Apr 2004 01:58:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFRo0-00070A-AH for megaco-web-archive@ietf.org; Mon, 19 Apr 2004 01:58:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFRmq-0006kv-00 for megaco-web-archive@ietf.org; Mon, 19 Apr 2004 01:57:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFRmB-0006Xb-00 for megaco-web-archive@ietf.org; Mon, 19 Apr 2004 01:57:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFRjF-00049M-Q2; Mon, 19 Apr 2004 01:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFRj2-0003yM-BX for megaco@optimus.ietf.org; Mon, 19 Apr 2004 01:53:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04904 for ; Mon, 19 Apr 2004 01:53:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFRiy-0005sa-UN for megaco@ietf.org; Mon, 19 Apr 2004 01:53:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFRi8-0005eu-00 for megaco@ietf.org; Mon, 19 Apr 2004 01:52:53 -0400 Received: from [210.22.146.172] (helo=asbmx.sbell.com.cn) by ietf-mx with esmtp (Exim 4.12) id 1BFRhR-0005P9-00 for megaco@ietf.org; Mon, 19 Apr 2004 01:52:10 -0400 Received: from asbwebshld.sbell.com.cn (asbwebshld [172.24.208.38]) by asbmx.sbell.com.cn (8.12.10+Sun/8.12.3) with SMTP id i3J5ngMm007820 for ; Mon, 19 Apr 2004 13:49:48 +0800 (CST) Received: FROM bellnet-mail4.sbell.com.cn BY asbwebshld.sbell.com.cn ; Mon Apr 19 13:51:27 2004 +0800 Received: from bellnet-mail1.sbell.com.cn ([172.24.208.21]) by bellnet-mail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Mon, 19 Apr 2004 13:51:27 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C425D2.5ACA3467" Date: Mon, 19 Apr 2004 13:51:26 +0800 Message-ID: Thread-Topic: about add command failure Thread-Index: AcQl0lnuiuXk1Rz3Rrqq9jGsQJzniA== From: "FCG Huang Qiang (B300)" To: X-OriginalArrivalTime: 19 Apr 2004 05:51:27.0004 (UTC) FILETIME=[5ACE35C0:01C425D2] Subject: [Megaco] about add command failure Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_40_50, HTML_FONT_FACE_BAD,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C425D2.5ACA3467 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable hello! for the case gived: MEGACO/1 []: Transaction=3D1 {Context=3D$ {Add=3D${Media{LocalControl{Mode =3D = SendOnly}}}} wihle add command fail, then the termination will be deleted from the = context created successfully, and then MG will delete the empty context. But for another case: context contains two commands, show below: MEGACO/1 []: Transaction=3D1 {Context=3D$=20 {Add=3Dtdm/1/1/1{Media{LocalControl{Mode =3D SendReceive}}}, {Add=3D${Media{LocalControl{Mode =3D SendOnly}}} } while add tdm success and the second add command is failure, MGC and MG = how to process it? will MG detele the rtp terminater and still leave one tdm terminater in = the context created ? BR huangq ------_=_NextPart_001_01C425D2.5ACA3467 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable about add command failure

hello!
for the = case gived:
MEGACO/1 = [<IP>]:<port>
Transaction=3D1 {Context=3D$ = {Add=3D${Media{LocalControl{Mode =3D SendOnly}}}}
wihle add = command fail, then the termination will be deleted from the context = created successfully, and then MG will delete the empty = context.

But for = another case: context contains two commands, show below:
MEGACO/1 = [<IP>]:<port>
Transaction=3D1 {Context=3D$
{Add=3Dtdm/1/1/1{Media{LocalControl{Mode =3D = SendReceive}}},
{Add=3D${Media{LocalControl{Mode =3D = SendOnly}}}
}
while add = tdm success and the second add command is failure, MGC and MG how to = process it?
will MG = detele the rtp terminater and still leave one tdm terminater in the = context created ?

BR
huangq

------_=_NextPart_001_01C425D2.5ACA3467-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Apr 19 02:31:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19908 for ; Mon, 19 Apr 2004 02:31:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFS9R-0007yB-EV; Mon, 19 Apr 2004 02:21:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFS6C-0006KZ-Jn for megaco@optimus.ietf.org; Mon, 19 Apr 2004 02:17:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18832 for ; Mon, 19 Apr 2004 02:17:42 -0400 (EDT) From: bvswamy@hss.hns.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFS68-0003LU-Tr for megaco@ietf.org; Mon, 19 Apr 2004 02:17:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFS5K-00038i-00 for megaco@ietf.org; Mon, 19 Apr 2004 02:16:51 -0400 Received: from spark.hss.co.in ([203.200.71.140]) by ietf-mx with esmtp (Exim 4.12) id 1BFS4i-0002su-00 for megaco@ietf.org; Mon, 19 Apr 2004 02:16:12 -0400 Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id i3J6EOd8017450; Mon, 19 Apr 2004 11:44:24 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id i3J6GRA06231; Mon, 19 Apr 2004 11:46:27 +0530 (IST) Subject: Re: [Megaco] about add command failure To: "FCG Huang Qiang (B300)" Cc: Date: Mon, 19 Apr 2004 11:41:24 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 19/04/2004 11:34:54 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.0 required=5.0 tests=AWL,NO_REAL_NAME, ROUND_THE_WORLD_LOCAL autolearn=no version=2.60 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi Huangq From the protocol perspective as mentioned in section 8 of the protocol RFC 3525: " A TransactionReply includes the results for all of the Commands in the corresponding TransactionRequest. The TransactionReply includes the return values for the Commands that were executed successfully, and the Command and error descriptor for any Command that failed." So in your case the transaction reply would consist of : 1) Add reply for the tdm termination and context id would be that of newly created context 2) command level error for the rtp termination. MG should not delete the tdm termination of its own. Its the MGC responsibility to continue with the call by giving another add command or freeing the context by giving subtract command for the tdm termination added. Regards Venkat Hughes Software Systems www.hssworld.com "FCG Huang Qiang (B300)" @ietf.org on 04/19/2004 11:21:26 AM Sent by: megaco-admin@ietf.org To: cc: Subject: [Megaco] about add command failure hello! for the case gived: MEGACO/1 []: Transaction=1 {Context=$ {Add=${Media{LocalControl{Mode = SendOnly}}}} wihle add command fail, then the termination will be deleted from the context created successfully, and then MG will delete the empty context. But for another case: context contains two commands, show below: MEGACO/1 []: Transaction=1 {Context=$ {Add=tdm/1/1/1{Media{LocalControl{Mode = SendReceive}}}, {Add=${Media{LocalControl{Mode = SendOnly}}} } while add tdm success and the second add command is failure, MGC and MG how to process it? will MG detele the rtp terminater and still leave one tdm terminater in the context created ? BR huangq _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Mon Apr 19 02:38:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20349 for ; Mon, 19 Apr 2004 02:38:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFSNB-0003eC-5C for megaco-archive@odin.ietf.org; Mon, 19 Apr 2004 02:35:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3J6ZHb0014020 for megaco-archive@odin.ietf.org; Mon, 19 Apr 2004 02:35:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFSL6-00036N-8r for megaco-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 02:33:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20062 for ; Mon, 19 Apr 2004 02:33:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFSL2-00070P-Iu for megaco-web-archive@ietf.org; Mon, 19 Apr 2004 02:33:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFSK7-0006lP-00 for megaco-web-archive@ietf.org; Mon, 19 Apr 2004 02:32:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFSJL-0006Vq-00 for megaco-web-archive@ietf.org; Mon, 19 Apr 2004 02:31:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFS9R-0007yB-EV; Mon, 19 Apr 2004 02:21:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFS6C-0006KZ-Jn for megaco@optimus.ietf.org; Mon, 19 Apr 2004 02:17:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18832 for ; Mon, 19 Apr 2004 02:17:42 -0400 (EDT) From: bvswamy@hss.hns.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFS68-0003LU-Tr for megaco@ietf.org; Mon, 19 Apr 2004 02:17:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFS5K-00038i-00 for megaco@ietf.org; Mon, 19 Apr 2004 02:16:51 -0400 Received: from spark.hss.co.in ([203.200.71.140]) by ietf-mx with esmtp (Exim 4.12) id 1BFS4i-0002su-00 for megaco@ietf.org; Mon, 19 Apr 2004 02:16:12 -0400 Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id i3J6EOd8017450; Mon, 19 Apr 2004 11:44:24 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id i3J6GRA06231; Mon, 19 Apr 2004 11:46:27 +0530 (IST) Subject: Re: [Megaco] about add command failure To: "FCG Huang Qiang (B300)" Cc: Date: Mon, 19 Apr 2004 11:41:24 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 19/04/2004 11:34:54 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.5 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Hi Huangq From the protocol perspective as mentioned in section 8 of the protocol RFC 3525: " A TransactionReply includes the results for all of the Commands in the corresponding TransactionRequest. The TransactionReply includes the return values for the Commands that were executed successfully, and the Command and error descriptor for any Command that failed." So in your case the transaction reply would consist of : 1) Add reply for the tdm termination and context id would be that of newly created context 2) command level error for the rtp termination. MG should not delete the tdm termination of its own. Its the MGC responsibility to continue with the call by giving another add command or freeing the context by giving subtract command for the tdm termination added. Regards Venkat Hughes Software Systems www.hssworld.com "FCG Huang Qiang (B300)" @ietf.org on 04/19/2004 11:21:26 AM Sent by: megaco-admin@ietf.org To: cc: Subject: [Megaco] about add command failure hello! for the case gived: MEGACO/1 []: Transaction=1 {Context=$ {Add=${Media{LocalControl{Mode = SendOnly}}}} wihle add command fail, then the termination will be deleted from the context created successfully, and then MG will delete the empty context. But for another case: context contains two commands, show below: MEGACO/1 []: Transaction=1 {Context=$ {Add=tdm/1/1/1{Media{LocalControl{Mode = SendReceive}}}, {Add=${Media{LocalControl{Mode = SendOnly}}} } while add tdm success and the second add command is failure, MGC and MG how to process it? will MG detele the rtp terminater and still leave one tdm terminater in the context created ? BR huangq _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Apr 19 08:41:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07834 for ; Mon, 19 Apr 2004 08:41:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFY0I-0001yH-53; Mon, 19 Apr 2004 08:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEo70-0006KD-0q for megaco@optimus.ietf.org; Sat, 17 Apr 2004 07:35:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03904 for ; Sat, 17 Apr 2004 07:35:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEo6z-00072u-9U for megaco@ietf.org; Sat, 17 Apr 2004 07:35:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEo65-0006xM-00 for megaco@ietf.org; Sat, 17 Apr 2004 07:34:58 -0400 Received: from web90109.mail.scd.yahoo.com ([66.218.94.80]) by ietf-mx with smtp (Exim 4.12) id 1BEo5s-0006rM-00 for megaco@ietf.org; Sat, 17 Apr 2004 07:34:44 -0400 Message-ID: <20040417113413.73093.qmail@web90109.mail.scd.yahoo.com> Received: from [217.218.155.70] by web90109.mail.scd.yahoo.com via HTTP; Sat, 17 Apr 2004 04:34:13 PDT Date: Sat, 17 Apr 2004 04:34:13 -0700 (PDT) From: Mary Malven To: megaco@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1081443089-1082201653=:72816" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=FORGED_YAHOO_RCVD,HTML_20_30, HTML_MESSAGE autolearn=no version=2.60 Subject: [Megaco] QoS Package Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --0-1081443089-1082201653=:72816 Content-Type: text/plain; charset=us-ascii Hello, What is the QoS Package parameters in Megaco stack for R-Factor. Does it include every fields of RTCP report? Thanks. --------------------------------- Do you Yahoo!? Yahoo! Tax Center - File online by April 15th --0-1081443089-1082201653=:72816 Content-Type: text/html; charset=us-ascii
Hello,
What is the QoS Package parameters in Megaco stack for R-Factor. Does it include every fields of RTCP report?
Thanks.

Do you Yahoo!?
Yahoo! Tax Center - File online by April 15th --0-1081443089-1082201653=:72816-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Mon Apr 19 08:46:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08206 for ; Mon, 19 Apr 2004 08:46:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFY99-0004aU-26 for megaco-archive@odin.ietf.org; Mon, 19 Apr 2004 08:45:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JCjBxv017626 for megaco-archive@odin.ietf.org; Mon, 19 Apr 2004 08:45:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFY78-00043E-O7 for megaco-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 08:43:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07942 for ; Mon, 19 Apr 2004 08:43:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFY77-0003Z6-G7 for megaco-web-archive@ietf.org; Mon, 19 Apr 2004 08:43:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFY69-0003Kx-00 for megaco-web-archive@ietf.org; Mon, 19 Apr 2004 08:42:05 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFY5Q-00037c-00 for megaco-web-archive@ietf.org; Mon, 19 Apr 2004 08:41:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFY0I-0001yH-53; Mon, 19 Apr 2004 08:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEo70-0006KD-0q for megaco@optimus.ietf.org; Sat, 17 Apr 2004 07:35:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03904 for ; Sat, 17 Apr 2004 07:35:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEo6z-00072u-9U for megaco@ietf.org; Sat, 17 Apr 2004 07:35:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEo65-0006xM-00 for megaco@ietf.org; Sat, 17 Apr 2004 07:34:58 -0400 Received: from web90109.mail.scd.yahoo.com ([66.218.94.80]) by ietf-mx with smtp (Exim 4.12) id 1BEo5s-0006rM-00 for megaco@ietf.org; Sat, 17 Apr 2004 07:34:44 -0400 Message-ID: <20040417113413.73093.qmail@web90109.mail.scd.yahoo.com> Received: from [217.218.155.70] by web90109.mail.scd.yahoo.com via HTTP; Sat, 17 Apr 2004 04:34:13 PDT Date: Sat, 17 Apr 2004 04:34:13 -0700 (PDT) From: Mary Malven To: megaco@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1081443089-1082201653=:72816" Subject: [Megaco] QoS Package Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,FORGED_YAHOO_RCVD, HTML_MESSAGE autolearn=no version=2.60 --0-1081443089-1082201653=:72816 Content-Type: text/plain; charset=us-ascii Hello, What is the QoS Package parameters in Megaco stack for R-Factor. Does it include every fields of RTCP report? Thanks. --------------------------------- Do you Yahoo!? Yahoo! Tax Center - File online by April 15th --0-1081443089-1082201653=:72816 Content-Type: text/html; charset=us-ascii
Hello,
What is the QoS Package parameters in Megaco stack for R-Factor. Does it include every fields of RTCP report?
Thanks.

Do you Yahoo!?
Yahoo! Tax Center - File online by April 15th --0-1081443089-1082201653=:72816-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Apr 19 09:04:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08977 for ; Mon, 19 Apr 2004 09:04:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFYIi-0006WO-Nf; Mon, 19 Apr 2004 08:55:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFYGi-00062N-FX for megaco@optimus.ietf.org; Mon, 19 Apr 2004 08:53:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08527 for ; Mon, 19 Apr 2004 08:52:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFYGh-0005so-2W for megaco@ietf.org; Mon, 19 Apr 2004 08:52:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFYFs-0005gT-00 for megaco@ietf.org; Mon, 19 Apr 2004 08:52:08 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1BFYFL-0005Tn-00 for megaco@ietf.org; Mon, 19 Apr 2004 08:51:35 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3JCp3l11835 for ; Mon, 19 Apr 2004 08:51:03 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JCT8HQ2X; Mon, 19 Apr 2004 08:51:03 -0400 Received: from nortelnetworks.com (acart1eq.ca.nortel.com [47.129.129.132]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JCVF1HXW; Mon, 19 Apr 2004 08:51:03 -0400 Message-ID: <4083CB34.3070407@nortelnetworks.com> Date: Mon, 19 Apr 2004 08:51:00 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: megaco@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Megaco] test -- pls ignore Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit My account keeps getting disabled. This is a test to see if something gets through for once. Tom _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Mon Apr 19 09:12:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09439 for ; Mon, 19 Apr 2004 09:12:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFYWF-0001CI-1V for megaco-archive@odin.ietf.org; Mon, 19 Apr 2004 09:09:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JD93Pm004594 for megaco-archive@odin.ietf.org; Mon, 19 Apr 2004 09:09:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFYSf-0000BC-Om for megaco-web-archive@optimus.ietf.org; Mon, 19 Apr 2004 09:05:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09094 for ; Mon, 19 Apr 2004 09:05:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFYSe-0000ot-AU for megaco-web-archive@ietf.org; Mon, 19 Apr 2004 09:05:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFYRh-0000ZY-00 for megaco-web-archive@ietf.org; Mon, 19 Apr 2004 09:04:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BFYR5-0000Jb-00 for megaco-web-archive@ietf.org; Mon, 19 Apr 2004 09:03:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFYIi-0006WO-Nf; Mon, 19 Apr 2004 08:55:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFYGi-00062N-FX for megaco@optimus.ietf.org; Mon, 19 Apr 2004 08:53:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08527 for ; Mon, 19 Apr 2004 08:52:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BFYGh-0005so-2W for megaco@ietf.org; Mon, 19 Apr 2004 08:52:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFYFs-0005gT-00 for megaco@ietf.org; Mon, 19 Apr 2004 08:52:08 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1BFYFL-0005Tn-00 for megaco@ietf.org; Mon, 19 Apr 2004 08:51:35 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3JCp3l11835 for ; Mon, 19 Apr 2004 08:51:03 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JCT8HQ2X; Mon, 19 Apr 2004 08:51:03 -0400 Received: from nortelnetworks.com (acart1eq.ca.nortel.com [47.129.129.132]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JCVF1HXW; Mon, 19 Apr 2004 08:51:03 -0400 Message-ID: <4083CB34.3070407@nortelnetworks.com> Date: Mon, 19 Apr 2004 08:51:00 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: megaco@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Megaco] test -- pls ignore Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit My account keeps getting disabled. This is a test to see if something gets through for once. Tom _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Apr 21 09:45:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20738 for ; Wed, 21 Apr 2004 09:45:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGHvS-00063M-KN; Wed, 21 Apr 2004 09:38:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGHkY-0000yB-3f for megaco@optimus.ietf.org; Wed, 21 Apr 2004 09:26:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19624 for ; Wed, 21 Apr 2004 09:26:47 -0400 (EDT) From: bvswamy@hss.hns.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGHkW-0005Fr-DO for megaco@ietf.org; Wed, 21 Apr 2004 09:26:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGHjX-00053c-00 for megaco@ietf.org; Wed, 21 Apr 2004 09:25:48 -0400 Received: from spark.hss.co.in ([203.200.71.140]) by ietf-mx with esmtp (Exim 4.12) id 1BGHic-0004lu-00 for megaco@ietf.org; Wed, 21 Apr 2004 09:24:54 -0400 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id i3LDN0d8015741 for ; Wed, 21 Apr 2004 18:53:00 +0530 (IST) To: megaco@ietf.org Date: Wed, 21 Apr 2004 18:50:05 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 21/04/2004 06:43:35 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,EXCUSE_16,NO_REAL_NAME autolearn=no version=2.60 Subject: [Megaco] InterOp Event/Interop Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi I would like to know if there is going to be any Interop event/Bakeoff in near future. Its being a long time we had any Megaco interop events(last was in April 2001, I hope not missing any event) and lot of things have been changed or added in Megaco after that specially support of 3G. Thanking you in advance. Regards Venkat Hughes Software Systems www.hssworld.com "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Apr 21 10:03:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21948 for ; Wed, 21 Apr 2004 10:03:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGI8R-00040Y-LB for megaco-archive@odin.ietf.org; Wed, 21 Apr 2004 09:51:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3LDpV1X015402 for megaco-archive@odin.ietf.org; Wed, 21 Apr 2004 09:51:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGI7k-0003Yd-43 for megaco-web-archive@optimus.ietf.org; Wed, 21 Apr 2004 09:50:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20928 for ; Wed, 21 Apr 2004 09:50:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGI7i-0001OC-6y for megaco-web-archive@ietf.org; Wed, 21 Apr 2004 09:50:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGI65-00012F-00 for megaco-web-archive@ietf.org; Wed, 21 Apr 2004 09:49:06 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BGI5F-0000rb-02 for megaco-web-archive@ietf.org; Wed, 21 Apr 2004 09:48:13 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BGI1n-0007na-9d for megaco-web-archive@ietf.org; Wed, 21 Apr 2004 09:44:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGHvS-00063M-KN; Wed, 21 Apr 2004 09:38:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGHkY-0000yB-3f for megaco@optimus.ietf.org; Wed, 21 Apr 2004 09:26:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19624 for ; Wed, 21 Apr 2004 09:26:47 -0400 (EDT) From: bvswamy@hss.hns.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BGHkW-0005Fr-DO for megaco@ietf.org; Wed, 21 Apr 2004 09:26:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGHjX-00053c-00 for megaco@ietf.org; Wed, 21 Apr 2004 09:25:48 -0400 Received: from spark.hss.co.in ([203.200.71.140]) by ietf-mx with esmtp (Exim 4.12) id 1BGHic-0004lu-00 for megaco@ietf.org; Wed, 21 Apr 2004 09:24:54 -0400 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by spark.hss.co.in (8.12.10/8.12.10) with ESMTP id i3LDN0d8015741 for ; Wed, 21 Apr 2004 18:53:00 +0530 (IST) To: megaco@ietf.org Date: Wed, 21 Apr 2004 18:50:05 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 21/04/2004 06:43:35 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [Megaco] InterOp Event/Interop Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.4 required=5.0 tests=AWL,EXCUSE_16,NO_REAL_NAME, ROUND_THE_WORLD_LOCAL autolearn=no version=2.60 Hi I would like to know if there is going to be any Interop event/Bakeoff in near future. Its being a long time we had any Megaco interop events(last was in April 2001, I hope not missing any event) and lot of things have been changed or added in Megaco after that specially support of 3G. Thanking you in advance. Regards Venkat Hughes Software Systems www.hssworld.com "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Apr 26 09:11:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18422 for ; Mon, 26 Apr 2004 09:11:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI5nG-0000rO-Bh; Mon, 26 Apr 2004 09:05:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI5bj-00070a-Fg for megaco@optimus.ietf.org; Mon, 26 Apr 2004 08:53:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16826 for ; Mon, 26 Apr 2004 08:53:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI5bh-0003zi-RX for megaco@ietf.org; Mon, 26 Apr 2004 08:53:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI5ae-0003nG-00 for megaco@ietf.org; Mon, 26 Apr 2004 08:52:08 -0400 Received: from mailrelay2.alcatel.de ([194.113.59.71] helo=mailrelay1.alcatel.de) by ietf-mx with esmtp (Exim 4.12) id 1BI5YP-0003LZ-00 for megaco@ietf.org; Mon, 26 Apr 2004 08:49:45 -0400 Received: from ks.sel.alcatel.de (slsv0d.stgl.sel.alcatel.de [149.204.14.10]) by mailrelay1.alcatel.de (8.12.10/8.12.10) with ESMTP id i3QCn7i8000233; Mon, 26 Apr 2004 12:49:07 GMT Received: from slssiv ([149.204.245.89] helo=slsdtk.stgl.sel.alcatel.de) by ks.sel.alcatel.de with esmtp (Exim 3.31) id 1BI5Xn-0003Ce-00; Mon, 26 Apr 2004 14:49:07 +0200 Received: from slsufnt ([149.204.245.33] helo=alcatel.de) by slsdtk.stgl.sel.alcatel.de with esmtp (Exim 3.31) id 1BI5Xg-0003oc-00; Mon, 26 Apr 2004 14:49:00 +0200 Message-ID: <408D053E.2080405@alcatel.de> Date: Mon, 26 Apr 2004 14:49:02 +0200 From: Carsten Waitzmann User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Groves CC: Tom Taylor , Albrecht.Schwarz@alcatel.de, Zhao Bo , megaco@ietf.org Subject: Re: Signaling of UDI rsp Clearmode Bearer Service; Re: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversion References: <403E1760.2010903@nortelnetworks.com> <40427B92.3000707@ericsson.com> <406C2424.7050708@alcatel.de> <40720E2A.6070903@ericsson.com> In-Reply-To: <40720E2A.6070903@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed X-Alcanet-virus-scanned: i3QCn7i8000233 at mailrelay1.alcatel.de Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mailrelay1.alcatel.de id i3QCn7i8000233 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello Christian, thanks for the information. I am still missing one piece: In case of textual encoding, what should be used for the=20 media stream properties described in H.248.1 Annex C? a=3Dh248item:/TMR =3D 40 thanks. Carsten Christian Groves wrote: > Hello Carsten, > > Yes this is what I had in mind. The package ID for Annex C is 0. > > ie. H.248.1 Annex A > PkgdName ::=3D OCTET STRING(SIZE(4)) > -- represents Package Name (2 octets) plus Property, Event, > -- Signal Names or Statistics ID. (2 octets) > -- To wildcard a package use 0xFFFF for first two octets, choose > -- is not allowed. To reference native property tag specified in > -- Annex C, use 0x0000 as first two octets. > > Regards, Christian > > Carsten Waitzmann wrote: > >> Hello Christian, >> >> I took your suggestion as a basis for the following example: >> >> MGC -> MG: >> MEGACO / 1 [1.2.3.4] >> Transaction =3D 100 { >> Context =3D $ { Add =3D TDM1 { >> Media { >> LocalControl {Mode =3D=20 >> SendReceive}, >> Local {a=3Dh248item:TMR =3D= =20 >> 0000 0010}} >> }}} >> >> MG -> MGC >> MEGACO / 1 [1.2.3.5] >> Reply =3D 100 { >> Context =3D 1 { >> Add =3D TDM1 { >> Media { >> Local {a=3Dh248item:TMR= =20 >> =3D 00000010} >> }}}} >> >> Is this usage in line to what you have in mind? >> H.248.15 specifies: a=3Dh248item:/ =3D=20 >> . For H.248.1 C.9 I do not know which package applies to=20 >> property TMR. But H.248.15 states "To enable the carriage of package=20 >> defined properties in the local and remote descriptors of the text=20 >> encoded H.248.1 protocol the Package attribute shall be used" thus I=20 >> am wondering whether a package name isn't mandatory? >> >> Thanks a lot! >> >> Carsten >> >> Alcatel >> >> Christian Groves wrote: >> >>> Hello Tom and Albrecht, >>> >>> What peice of information do you want to signal explicitely? Doesn't=20 >>> TMR allow you to specify 64Kbit UDI? If so then its supported by=20 >>> H.248.1 Annex C.9. For H.248 text users this (or any element in=20 >>> Annex C) can be tranferred via H.248.15. Alternatively Q.1950 sect=20 >>> 5.7.1.2 specifies an equivalent encoding. >>> >>> Regards, Christian >>> >>> Tom Taylor wrote: >>> >>>> I intended a reference to draft-ietf-avt-rtp-clearmode-04.txt in my=20 >>>> intervention. My old draft has been allowed to expire because it=20 >>>> did not seem to be of much interest to the community. >>>> >>>> You are right: the draft just referred to doesn't apply to TDM,=20 >>>> only to the packet side. I wasn't thinking. I agree that in the=20 >>>> absence of the attributes provided in my old draft, TDM bearer=20 >>>> characteristics are assumed rather than signalled explicitly. >>>> >>>> Albrecht.Schwarz@alcatel.de wrote: >>>> >>>>> I think that the question is, whether this specific TDM bearer=20 >>>>> capability >>>>> should be (1) explicitly signalled, or whether (2) implicit=20 >>>>> assumption is >>>>> already sufficient. >>>>> >>>>> With regard to (1), Tom, I guess that your refer to >>>>> >>>>> * RTP/CLEARMODE >>>>> RTP payload format for a 64 kbit/s transparent call >>>>> =20 >>>>> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-clearmode-04= .txt=20 >>>>> >>>>> >>>>> But, this coming RFC may not be directly applied, e.g.,=20 >>>>> packetization time >>>>> parameter isn't applicable IMHO. Pls correct me if wrong. >>>>> >>>>> Or do you refer to your proposals in your expired draft wrt >>>>> * TDM/CLEARMODE >>>>> Conventions for the use of the Session Description Protocol (SDP) >>>>> for Digital Circuit Connections >>>>> =20 >>>>> http://www.watersprings.org/pub/id/draft-taylor-mmusic-sdp-tdm-01.t= xt >>>>> >>>>> My conclusion is, that an explicit signalling method doesn't exist=20 >>>>> today >>>>> ("exception might be Q.1950"). >>>>> Even though, an explicit TDM Media Descriptor for I.231.1 might=20 >>>>> be helpful >>>>> for unambigously specification in certain MG implementations. >>>>> >>>>> >>>>> With regard to (2): >>>>> Implicit signaling is in my understanding the situation of today.=20 >>>>> In case >>>>> of, (a) missing TDM Media Descriptors, or (b) "identical TDM Media >>>>> Descriptors with transparent channel indications", when a transpare= nt >>>>> 64-kbit/s bearer connection may be established. >>>>> Sometimes this is also called "native TDM switching", or "native TD= M >>>>> hairpinning", but technically it is exactly representing an ISDN B=20 >>>>> channel >>>>> with I.231.1 bearer service. [=3D> the channel may bypass the DSP,=20 >>>>> but in >>>>> case that a DSP is looped-in, then must be the DSP channel=20 >>>>> operation mode >>>>> configured for 'Clearmode'] >>>>> >>>>> Last comment: >>>>> Such kind of implicit signalling mechanism is often assumed in telc= o >>>>> industry, because this is the legacy signaling mechanism within a T= DM >>>>> switch ("if there aren't any signaled bearer capabilities then=20 >>>>> transparent >>>>> channel; any needed bearer capability in addition must be explicitl= y >>>>> signalled, like signal processing network equipment functions,=20 >>>>> e.g., EC"). >>>>> >>>>> TDM hairpinning means, an "H.248-controlled TDM switching=20 >>>>> function" from >>>>> H.248 Media Gateway perspective. Hence, this implicit signalling=20 >>>>> assumption >>>>> may be still valid, or do you see any needs for explicit signaling >>>>> codepoints in case of TDM-to-TDM ISDN I.231.1 calls? >>>>> >>>>> Regards >>>>> >>>>> Albrecht >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> = = =20 >>>>> Tom=20 >>>>> Taylor = =20 >>>>> >>>> = =20 >>>>> tworks.com> cc: Albrecht=20 >>>>> SCHWARZ/DE/ALCATEL@ALCATEL,=20 >>>>> megaco@ietf.org =20 >>>>> Subject: Re: TDM=20 >>>>> Hairpinning; Re: [Megaco] Hairpin case A/u Law=20 >>>>> conversion =20 >>>>> 26.02.2004=20 >>>>> 14:05 = =20 >>>>> = = =20 >>>>> = = =20 >>>>> >>>>> >>>>> >>>>> >>>>> I think you would do it by specifying the CLEARMODE codec in the=20 >>>>> Local and >>>>> Remote >>>>> descriptors. Unfortunately, CLEARMODE is still under=20 >>>>> consideration by the >>>>> IESG >>>>> and hasn't reached RFC status. >>>>> >>>>> Zhao Bo wrote: >>>>> >>>>>> Dear Albrecht: >>>>>> Is there any H.248 package defined to signal the UDI transparen= cy >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> properties in TDM hairping case? >>>>> >>>>>> Best regards >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: >>>>>> To: "Zhao Bo" >>>>>> Cc: ; >>>>>> Sent: Wednesday, February 25, 2004 10:24 PM >>>>>> Subject: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law=20 >>>>>> conversion >>>>>> >>>>>> >>>>>> >>>>>> Dear Zhao Bo, >>>>>> >>>>>> because there isn't any "hairpinning" definition in MEGACOP/H.248 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> standards >>>>> >>>>>> ("please correct if I'm wrong"), I'd like to use the following=20 >>>>>> one for >>>>>> responding your questions: >>>>>> >>>>>> >>>>> >>>>> *******************************************************************= ****************=20 >>>>> >>>>> >>>>> >>>>>> Definition: >>>>>> TDM Hairpinning >>>>>> ? is a scenario whereby a call is being made between two TDM=20 >>>>>> endpoints on >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> a >>>>> >>>>>> single media gateway. The media comes in on one TDM channel=20 >>>>>> and goes >>>>>> out on another TDM channel through the use of an internal loop=20 >>>>>> in the >>>>>> media gateway. >>>>>> >>>>>> Note 1: due to the fact that there are local call types at local >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> exchanges >>>>> >>>>>> (CLASS5), and transit exchanges (CLASS4) in legacy TDM networks=20 >>>>>> (PSTN, >>>>>> NISDN, etc), there is a variety of TDM-to-TDM connection types=20 >>>>>> behind the >>>>>> general "TDM hairpinning" capability (dependent on required type=20 >>>>>> of IWF, >>>>>> etc.) in corresponding H.248 MG types >>>>>> >>>>>> Note 2: H.248/MEGCOP perspective >>>>>> TDM Hairpinning =3D Single H.248 Context with 2 H.248 TDM Terminat= ions >>>>>> >>>>> >>>>> *******************************************************************= *****************=20 >>>>> >>>>> >>>>> >>>>>> Based on this hairpinning understanding, my answers are: >>>>>> >>>>>> (1) Speech telephony service: G.711 companding formats are a=20 >>>>>> property of >>>>>> the corresponding H.248 TDM termination >>>>>> >>>>>> [Note: dependent on MG architecture and implementation, property=20 >>>>>> might be >>>>>> signalled or preprovisioned. Of course, G.711 companding law is an >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> inherent >>>>> >>>>>> property of your DS0 channel at your PDH/SDH/SONET framer; the=20 >>>>>> way, how >>>>>> this DS0 property is associated with the corresponding H.248 TDM >>>>>> Termination property may only realized MG-internally for very=20 >>>>>> specific MG >>>>>> architectures. Generally it is up to the MGC, particularly if=20 >>>>>> some (or >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> all) >>>>> >>>>>> DS0's are ISDN B channels.] >>>>>> >>>>>> (2) Voiceband Data services: same as in (1) >>>>>> >>>>>> [Note: VBD according new ITU-T V.152 -> "... For purposes of >>>>>> interoperability, a V.152 compliant implementation shall support=20 >>>>>> at least >>>>>> both G.711 A-law and G.711 =C3=AC-law codecs as VBD codecs. "] >>>>>> >>>>>> (3) ISDN UDI =3D all ISDN Teleservices with ISDN I.231. bearer ser= vice >>>>>> requirement >>>>>> =3D> H.248 TDM Termination property must be signalled by MGC, if=20 >>>>>> not, MG >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> may >>>>> >>>>>> not guarantee UDI capability (i.e., fully transparent 64-kbit/s=20 >>>>>> bearer >>>>>> channel) in TDM hairpinning scenarios ... >>>>>> >>>>>> >>>>>> Conclusion: >>>>>> IF your MG is supporting >>>>>> PSTN lines (=3D H.248 ALN Termination), >>>>>> PSTN trunks (=3D H.248 TDM Termination), and >>>>>> ISDN B channels (=3D H.248 TDM Termination) >>>>>> >>>>>> AND IF you've such services and interworking requirements >>>>>> >>>>>> THEN you should generally signal the corresponding properties ... >>>>>> >>>>>> ... in case of >>>>>> TDM hairpinning, >>>>>> ALN hairpinning, or >>>>>> ALN-to-TDM connection types. >>>>>> >>>>>> Regards, >>>>>> Albrecht >>>>>> >>>>>> ALCATEL >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>>> Zhao Bo >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> To: =20 >>>>>> megaco@ietf.org >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> Sent by: cc: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> megaco-admin@iet Subject: [Megaco]=20 >>>>>> Hairpin >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> case A/u Law conversion >>>>> >>>>>> f.org >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> 25.02.2004 08:11 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>> In this case, the A/u law format of a TDM ciruit can be=20 >>>>>> provisioned, but >>>>>> the MG doesn't know the service type of a call, thus >>>>>> has no way to know if a conversion is needed. For speech service >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> conversion >>>>> >>>>>> may be needed; for data service like isdn UDI, conversion is not >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> permitted. >>>>> >>>>>> Is there any method to solve this problem? >>>>>> >>>>>> Zhao Bo >>>>>> >>>>>> ***************************************************************** >>>>>> This e-mail and its attachments contain confidential information=20 >>>>>> from >>>>>> HUAWEI, which is intended only for the person or entity whose=20 >>>>>> address is >>>>>> listed above. Any use of the information contained herein in any w= ay >>>>>> (including, but not limited to, total or partial disclosure, >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> reproduction, >>>>> >>>>>> or dissemination) by persons other than the intended recipient(s) = is >>>>>> prohibited. If you receive this e-mail in error, please notify=20 >>>>>> the sender >>>>>> by phone or email immediately and delete it! >>>>>> ***************************************************************** >>>>>> >>>>>> _______________________________________________ >>>>>> Megaco mailing list >>>>>> Megaco@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/megaco >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Megaco mailing list >>>>>> Megaco@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/megaco >>>>>> 1=C3=A8=1Ar=E2=80=B0=C5=A1=C5=A0X=C2=A7=E2=80=9AX=C2=AC=C2=B4=C3=87= i=C3=8A"z=C3=97=C3=A8=C2=AE=08m=C2=B6=E2=80=BA?=C3=BF=0C0=C3=96'=C2=AD~=C5= =A0=C3=A0=C3=BEf=C2=A2=E2=80=93f=C2=A7=C3=BEX=C2=AC=C2=B6)=C3=9F=C2=A3=C3= =B9=C5=BE=EF=A2=9D=C2=A7( >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Megaco mailing list >>>> Megaco@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/megaco >>>> >>> >>> >>> This communication is confidential and intended solely for the=20 >>> addressee(s). Any unauthorized review, use, disclosure or=20 >>> distribution is prohibited. If you believe this message has been=20 >>> sent to you in error, please notify the sender by replying to this=20 >>> transmission and delete the message without disclosing it. Thank you. >>> >>> E-mail including attachments is susceptible to data corruption,=20 >>> interruption, unauthorized amendment, tampering and viruses, and we=20 >>> only send and receive e-mails on the basis that we are not liable=20 >>> for any such corruption, interception, amendment, tampering or=20 >>> viruses or any consequences thereof. >>> >>> >>> _______________________________________________ >>> Megaco mailing list >>> Megaco@ietf.org >>> https://www1.ietf.org/mailman/listinfo/megaco >>> >> > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Mon Apr 26 09:28:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19331 for ; Mon, 26 Apr 2004 09:28:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI60e-0005Pi-DC for megaco-archive@odin.ietf.org; Mon, 26 Apr 2004 09:18:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QDIu5A020806 for megaco-archive@odin.ietf.org; Mon, 26 Apr 2004 09:18:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI5uu-0003qV-J6 for megaco-web-archive@optimus.ietf.org; Mon, 26 Apr 2004 09:13:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18500 for ; Mon, 26 Apr 2004 09:12:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI5us-0005kZ-W8 for megaco-web-archive@ietf.org; Mon, 26 Apr 2004 09:12:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI5ty-0005hu-00 for megaco-web-archive@ietf.org; Mon, 26 Apr 2004 09:12:03 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BI5tI-0005f2-00 for megaco-web-archive@ietf.org; Mon, 26 Apr 2004 09:11:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI5nG-0000rO-Bh; Mon, 26 Apr 2004 09:05:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI5bj-00070a-Fg for megaco@optimus.ietf.org; Mon, 26 Apr 2004 08:53:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16826 for ; Mon, 26 Apr 2004 08:53:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI5bh-0003zi-RX for megaco@ietf.org; Mon, 26 Apr 2004 08:53:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI5ae-0003nG-00 for megaco@ietf.org; Mon, 26 Apr 2004 08:52:08 -0400 Received: from mailrelay2.alcatel.de ([194.113.59.71] helo=mailrelay1.alcatel.de) by ietf-mx with esmtp (Exim 4.12) id 1BI5YP-0003LZ-00 for megaco@ietf.org; Mon, 26 Apr 2004 08:49:45 -0400 Received: from ks.sel.alcatel.de (slsv0d.stgl.sel.alcatel.de [149.204.14.10]) by mailrelay1.alcatel.de (8.12.10/8.12.10) with ESMTP id i3QCn7i8000233; Mon, 26 Apr 2004 12:49:07 GMT Received: from slssiv ([149.204.245.89] helo=slsdtk.stgl.sel.alcatel.de) by ks.sel.alcatel.de with esmtp (Exim 3.31) id 1BI5Xn-0003Ce-00; Mon, 26 Apr 2004 14:49:07 +0200 Received: from slsufnt ([149.204.245.33] helo=alcatel.de) by slsdtk.stgl.sel.alcatel.de with esmtp (Exim 3.31) id 1BI5Xg-0003oc-00; Mon, 26 Apr 2004 14:49:00 +0200 Message-ID: <408D053E.2080405@alcatel.de> Date: Mon, 26 Apr 2004 14:49:02 +0200 From: Carsten Waitzmann User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Groves CC: Tom Taylor , Albrecht.Schwarz@alcatel.de, Zhao Bo , megaco@ietf.org Subject: Re: Signaling of UDI rsp Clearmode Bearer Service; Re: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversion References: <403E1760.2010903@nortelnetworks.com> <40427B92.3000707@ericsson.com> <406C2424.7050708@alcatel.de> <40720E2A.6070903@ericsson.com> In-Reply-To: <40720E2A.6070903@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed X-Alcanet-virus-scanned: i3QCn7i8000233 at mailrelay1.alcatel.de Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mailrelay1.alcatel.de id i3QCn7i8000233 Content-Transfer-Encoding: quoted-printable Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello Christian, thanks for the information. I am still missing one piece: In case of textual encoding, what should be used for the=20 media stream properties described in H.248.1 Annex C? a=3Dh248item:/TMR =3D 40 thanks. Carsten Christian Groves wrote: > Hello Carsten, > > Yes this is what I had in mind. The package ID for Annex C is 0. > > ie. H.248.1 Annex A > PkgdName ::=3D OCTET STRING(SIZE(4)) > -- represents Package Name (2 octets) plus Property, Event, > -- Signal Names or Statistics ID. (2 octets) > -- To wildcard a package use 0xFFFF for first two octets, choose > -- is not allowed. To reference native property tag specified in > -- Annex C, use 0x0000 as first two octets. > > Regards, Christian > > Carsten Waitzmann wrote: > >> Hello Christian, >> >> I took your suggestion as a basis for the following example: >> >> MGC -> MG: >> MEGACO / 1 [1.2.3.4] >> Transaction =3D 100 { >> Context =3D $ { Add =3D TDM1 { >> Media { >> LocalControl {Mode =3D=20 >> SendReceive}, >> Local {a=3Dh248item:TMR =3D= =20 >> 0000 0010}} >> }}} >> >> MG -> MGC >> MEGACO / 1 [1.2.3.5] >> Reply =3D 100 { >> Context =3D 1 { >> Add =3D TDM1 { >> Media { >> Local {a=3Dh248item:TMR= =20 >> =3D 00000010} >> }}}} >> >> Is this usage in line to what you have in mind? >> H.248.15 specifies: a=3Dh248item:/ =3D=20 >> . For H.248.1 C.9 I do not know which package applies to=20 >> property TMR. But H.248.15 states "To enable the carriage of package=20 >> defined properties in the local and remote descriptors of the text=20 >> encoded H.248.1 protocol the Package attribute shall be used" thus I=20 >> am wondering whether a package name isn't mandatory? >> >> Thanks a lot! >> >> Carsten >> >> Alcatel >> >> Christian Groves wrote: >> >>> Hello Tom and Albrecht, >>> >>> What peice of information do you want to signal explicitely? Doesn't=20 >>> TMR allow you to specify 64Kbit UDI? If so then its supported by=20 >>> H.248.1 Annex C.9. For H.248 text users this (or any element in=20 >>> Annex C) can be tranferred via H.248.15. Alternatively Q.1950 sect=20 >>> 5.7.1.2 specifies an equivalent encoding. >>> >>> Regards, Christian >>> >>> Tom Taylor wrote: >>> >>>> I intended a reference to draft-ietf-avt-rtp-clearmode-04.txt in my=20 >>>> intervention. My old draft has been allowed to expire because it=20 >>>> did not seem to be of much interest to the community. >>>> >>>> You are right: the draft just referred to doesn't apply to TDM,=20 >>>> only to the packet side. I wasn't thinking. I agree that in the=20 >>>> absence of the attributes provided in my old draft, TDM bearer=20 >>>> characteristics are assumed rather than signalled explicitly. >>>> >>>> Albrecht.Schwarz@alcatel.de wrote: >>>> >>>>> I think that the question is, whether this specific TDM bearer=20 >>>>> capability >>>>> should be (1) explicitly signalled, or whether (2) implicit=20 >>>>> assumption is >>>>> already sufficient. >>>>> >>>>> With regard to (1), Tom, I guess that your refer to >>>>> >>>>> * RTP/CLEARMODE >>>>> RTP payload format for a 64 kbit/s transparent call >>>>> =20 >>>>> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-clearmode-04= .txt=20 >>>>> >>>>> >>>>> But, this coming RFC may not be directly applied, e.g.,=20 >>>>> packetization time >>>>> parameter isn't applicable IMHO. Pls correct me if wrong. >>>>> >>>>> Or do you refer to your proposals in your expired draft wrt >>>>> * TDM/CLEARMODE >>>>> Conventions for the use of the Session Description Protocol (SDP) >>>>> for Digital Circuit Connections >>>>> =20 >>>>> http://www.watersprings.org/pub/id/draft-taylor-mmusic-sdp-tdm-01.t= xt >>>>> >>>>> My conclusion is, that an explicit signalling method doesn't exist=20 >>>>> today >>>>> ("exception might be Q.1950"). >>>>> Even though, an explicit TDM Media Descriptor for I.231.1 might=20 >>>>> be helpful >>>>> for unambigously specification in certain MG implementations. >>>>> >>>>> >>>>> With regard to (2): >>>>> Implicit signaling is in my understanding the situation of today.=20 >>>>> In case >>>>> of, (a) missing TDM Media Descriptors, or (b) "identical TDM Media >>>>> Descriptors with transparent channel indications", when a transpare= nt >>>>> 64-kbit/s bearer connection may be established. >>>>> Sometimes this is also called "native TDM switching", or "native TD= M >>>>> hairpinning", but technically it is exactly representing an ISDN B=20 >>>>> channel >>>>> with I.231.1 bearer service. [=3D> the channel may bypass the DSP,=20 >>>>> but in >>>>> case that a DSP is looped-in, then must be the DSP channel=20 >>>>> operation mode >>>>> configured for 'Clearmode'] >>>>> >>>>> Last comment: >>>>> Such kind of implicit signalling mechanism is often assumed in telc= o >>>>> industry, because this is the legacy signaling mechanism within a T= DM >>>>> switch ("if there aren't any signaled bearer capabilities then=20 >>>>> transparent >>>>> channel; any needed bearer capability in addition must be explicitl= y >>>>> signalled, like signal processing network equipment functions,=20 >>>>> e.g., EC"). >>>>> >>>>> TDM hairpinning means, an "H.248-controlled TDM switching=20 >>>>> function" from >>>>> H.248 Media Gateway perspective. Hence, this implicit signalling=20 >>>>> assumption >>>>> may be still valid, or do you see any needs for explicit signaling >>>>> codepoints in case of TDM-to-TDM ISDN I.231.1 calls? >>>>> >>>>> Regards >>>>> >>>>> Albrecht >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> = = =20 >>>>> Tom=20 >>>>> Taylor = =20 >>>>> >>>> = =20 >>>>> tworks.com> cc: Albrecht=20 >>>>> SCHWARZ/DE/ALCATEL@ALCATEL,=20 >>>>> megaco@ietf.org =20 >>>>> Subject: Re: TDM=20 >>>>> Hairpinning; Re: [Megaco] Hairpin case A/u Law=20 >>>>> conversion =20 >>>>> 26.02.2004=20 >>>>> 14:05 = =20 >>>>> = = =20 >>>>> = = =20 >>>>> >>>>> >>>>> >>>>> >>>>> I think you would do it by specifying the CLEARMODE codec in the=20 >>>>> Local and >>>>> Remote >>>>> descriptors. Unfortunately, CLEARMODE is still under=20 >>>>> consideration by the >>>>> IESG >>>>> and hasn't reached RFC status. >>>>> >>>>> Zhao Bo wrote: >>>>> >>>>>> Dear Albrecht: >>>>>> Is there any H.248 package defined to signal the UDI transparen= cy >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> properties in TDM hairping case? >>>>> >>>>>> Best regards >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: >>>>>> To: "Zhao Bo" >>>>>> Cc: ; >>>>>> Sent: Wednesday, February 25, 2004 10:24 PM >>>>>> Subject: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law=20 >>>>>> conversion >>>>>> >>>>>> >>>>>> >>>>>> Dear Zhao Bo, >>>>>> >>>>>> because there isn't any "hairpinning" definition in MEGACOP/H.248 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> standards >>>>> >>>>>> ("please correct if I'm wrong"), I'd like to use the following=20 >>>>>> one for >>>>>> responding your questions: >>>>>> >>>>>> >>>>> >>>>> *******************************************************************= ****************=20 >>>>> >>>>> >>>>> >>>>>> Definition: >>>>>> TDM Hairpinning >>>>>> ? is a scenario whereby a call is being made between two TDM=20 >>>>>> endpoints on >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> a >>>>> >>>>>> single media gateway. The media comes in on one TDM channel=20 >>>>>> and goes >>>>>> out on another TDM channel through the use of an internal loop=20 >>>>>> in the >>>>>> media gateway. >>>>>> >>>>>> Note 1: due to the fact that there are local call types at local >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> exchanges >>>>> >>>>>> (CLASS5), and transit exchanges (CLASS4) in legacy TDM networks=20 >>>>>> (PSTN, >>>>>> NISDN, etc), there is a variety of TDM-to-TDM connection types=20 >>>>>> behind the >>>>>> general "TDM hairpinning" capability (dependent on required type=20 >>>>>> of IWF, >>>>>> etc.) in corresponding H.248 MG types >>>>>> >>>>>> Note 2: H.248/MEGCOP perspective >>>>>> TDM Hairpinning =3D Single H.248 Context with 2 H.248 TDM Terminat= ions >>>>>> >>>>> >>>>> *******************************************************************= *****************=20 >>>>> >>>>> >>>>> >>>>>> Based on this hairpinning understanding, my answers are: >>>>>> >>>>>> (1) Speech telephony service: G.711 companding formats are a=20 >>>>>> property of >>>>>> the corresponding H.248 TDM termination >>>>>> >>>>>> [Note: dependent on MG architecture and implementation, property=20 >>>>>> might be >>>>>> signalled or preprovisioned. Of course, G.711 companding law is an >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> inherent >>>>> >>>>>> property of your DS0 channel at your PDH/SDH/SONET framer; the=20 >>>>>> way, how >>>>>> this DS0 property is associated with the corresponding H.248 TDM >>>>>> Termination property may only realized MG-internally for very=20 >>>>>> specific MG >>>>>> architectures. Generally it is up to the MGC, particularly if=20 >>>>>> some (or >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> all) >>>>> >>>>>> DS0's are ISDN B channels.] >>>>>> >>>>>> (2) Voiceband Data services: same as in (1) >>>>>> >>>>>> [Note: VBD according new ITU-T V.152 -> "... For purposes of >>>>>> interoperability, a V.152 compliant implementation shall support=20 >>>>>> at least >>>>>> both G.711 A-law and G.711 =C3=AC-law codecs as VBD codecs. "] >>>>>> >>>>>> (3) ISDN UDI =3D all ISDN Teleservices with ISDN I.231. bearer ser= vice >>>>>> requirement >>>>>> =3D> H.248 TDM Termination property must be signalled by MGC, if=20 >>>>>> not, MG >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> may >>>>> >>>>>> not guarantee UDI capability (i.e., fully transparent 64-kbit/s=20 >>>>>> bearer >>>>>> channel) in TDM hairpinning scenarios ... >>>>>> >>>>>> >>>>>> Conclusion: >>>>>> IF your MG is supporting >>>>>> PSTN lines (=3D H.248 ALN Termination), >>>>>> PSTN trunks (=3D H.248 TDM Termination), and >>>>>> ISDN B channels (=3D H.248 TDM Termination) >>>>>> >>>>>> AND IF you've such services and interworking requirements >>>>>> >>>>>> THEN you should generally signal the corresponding properties ... >>>>>> >>>>>> ... in case of >>>>>> TDM hairpinning, >>>>>> ALN hairpinning, or >>>>>> ALN-to-TDM connection types. >>>>>> >>>>>> Regards, >>>>>> Albrecht >>>>>> >>>>>> ALCATEL >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>>> Zhao Bo >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> To: =20 >>>>>> megaco@ietf.org >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> Sent by: cc: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> megaco-admin@iet Subject: [Megaco]=20 >>>>>> Hairpin >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> case A/u Law conversion >>>>> >>>>>> f.org >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> 25.02.2004 08:11 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>> In this case, the A/u law format of a TDM ciruit can be=20 >>>>>> provisioned, but >>>>>> the MG doesn't know the service type of a call, thus >>>>>> has no way to know if a conversion is needed. For speech service >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> conversion >>>>> >>>>>> may be needed; for data service like isdn UDI, conversion is not >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> permitted. >>>>> >>>>>> Is there any method to solve this problem? >>>>>> >>>>>> Zhao Bo >>>>>> >>>>>> ***************************************************************** >>>>>> This e-mail and its attachments contain confidential information=20 >>>>>> from >>>>>> HUAWEI, which is intended only for the person or entity whose=20 >>>>>> address is >>>>>> listed above. Any use of the information contained herein in any w= ay >>>>>> (including, but not limited to, total or partial disclosure, >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> reproduction, >>>>> >>>>>> or dissemination) by persons other than the intended recipient(s) = is >>>>>> prohibited. If you receive this e-mail in error, please notify=20 >>>>>> the sender >>>>>> by phone or email immediately and delete it! >>>>>> ***************************************************************** >>>>>> >>>>>> _______________________________________________ >>>>>> Megaco mailing list >>>>>> Megaco@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/megaco >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Megaco mailing list >>>>>> Megaco@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/megaco >>>>>> 1=C3=A8=1Ar=E2=80=B0=C5=A1=C5=A0X=C2=A7=E2=80=9AX=C2=AC=C2=B4=C3=87= i=C3=8A"z=C3=97=C3=A8=C2=AE=08m=C2=B6=E2=80=BA?=C3=BF=0C0=C3=96'=C2=AD~=C5= =A0=C3=A0=C3=BEf=C2=A2=E2=80=93f=C2=A7=C3=BEX=C2=AC=C2=B6)=C3=9F=C2=A3=C3= =B9=C5=BE=EF=A2=9D=C2=A7( >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Megaco mailing list >>>> Megaco@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/megaco >>>> >>> >>> >>> This communication is confidential and intended solely for the=20 >>> addressee(s). Any unauthorized review, use, disclosure or=20 >>> distribution is prohibited. If you believe this message has been=20 >>> sent to you in error, please notify the sender by replying to this=20 >>> transmission and delete the message without disclosing it. Thank you. >>> >>> E-mail including attachments is susceptible to data corruption,=20 >>> interruption, unauthorized amendment, tampering and viruses, and we=20 >>> only send and receive e-mails on the basis that we are not liable=20 >>> for any such corruption, interception, amendment, tampering or=20 >>> viruses or any consequences thereof. >>> >>> >>> _______________________________________________ >>> Megaco mailing list >>> Megaco@ietf.org >>> https://www1.ietf.org/mailman/listinfo/megaco >>> >> > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Apr 27 05:36:27 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16762 for ; Tue, 27 Apr 2004 05:36:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIOpo-0006CR-Qm; Tue, 27 Apr 2004 05:25:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIOjq-0005QI-1M for megaco@optimus.ietf.org; Tue, 27 Apr 2004 05:18:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16104 for ; Tue, 27 Apr 2004 05:18:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIOjm-0005qN-NL for megaco@ietf.org; Tue, 27 Apr 2004 05:18:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIOis-0005fF-00 for megaco@ietf.org; Tue, 27 Apr 2004 05:17:51 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BIOhv-0005UK-00 for megaco@ietf.org; Tue, 27 Apr 2004 05:16:51 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3R9GqAh003746 for ; Tue, 27 Apr 2004 11:16:52 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 27 Apr 2004 11:16:52 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JSDTFZT7; Tue, 27 Apr 2004 11:17:00 +0200 Received: from ericsson.com (sealwa04-205.sw.ericsson.se [130.100.249.205]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JRYYX3XW; Tue, 27 Apr 2004 19:16:37 +1000 Message-ID: <408E24FA.2070303@ericsson.com> Date: Tue, 27 Apr 2004 19:16:42 +1000 X-Sybari-Trust: e257681b 1f7207db 8d4fd520 00000139 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Carsten Waitzmann CC: Tom Taylor , Albrecht.Schwarz@alcatel.de, Zhao Bo , megaco@ietf.org Subject: Re: Signaling of UDI rsp Clearmode Bearer Service; Re: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversion References: <403E1760.2010903@nortelnetworks.com> <40427B92.3000707@ericsson.com> <406C2424.7050708@alcatel.de> <40720E2A.6070903@ericsson.com> <408D053E.2080405@alcatel.de> In-Reply-To: <408D053E.2080405@alcatel.de> Content-Type: text/plain; charset=UTF-8; format=flowed X-OriginalArrivalTime: 27 Apr 2004 09:16:52.0116 (UTC) FILETIME=[60730D40:01C42C38] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by eagle.ericsson.se id i3R9GqAh003746 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello Carsten, Seems you have a very good point. The text name for Annex C is missing. I propose using "AnxC". Or is there another suggestion? I will put this in a contribution for the upcoming ITU SG16 meeting. Regards, Christian Carsten Waitzmann wrote: > Hello Christian, >=20 > thanks for the information. I am still missing one piece: >=20 > In case of textual encoding, what should be used for the= =20 > media stream properties described in H.248.1 Annex C? >=20 > a=3Dh248item:/TMR =3D 40 >=20 > thanks. > Carsten >=20 > Christian Groves wrote: >=20 >> Hello Carsten, >> >> Yes this is what I had in mind. The package ID for Annex C is 0. >> >> ie. H.248.1 Annex A >> PkgdName ::=3D OCTET STRING(SIZE(4)) >> -- represents Package Name (2 octets) plus Property, Event, >> -- Signal Names or Statistics ID. (2 octets) >> -- To wildcard a package use 0xFFFF for first two octets, choose >> -- is not allowed. To reference native property tag specified in >> -- Annex C, use 0x0000 as first two octets. >> >> Regards, Christian >> >> Carsten Waitzmann wrote: >> >>> Hello Christian, >>> >>> I took your suggestion as a basis for the following example: >>> >>> MGC -> MG: >>> MEGACO / 1 [1.2.3.4] >>> Transaction =3D 100 { >>> Context =3D $ { Add =3D TDM1 { >>> Media { >>> LocalControl {Mode =3D=20 >>> SendReceive}, >>> Local {a=3Dh248item:TMR = =3D=20 >>> 0000 0010}} >>> }}} >>> >>> MG -> MGC >>> MEGACO / 1 [1.2.3.5] >>> Reply =3D 100 { >>> Context =3D 1 { >>> Add =3D TDM1 { >>> Media { >>> Local {a=3Dh248item:TM= R=20 >>> =3D 00000010} >>> }}}} >>> >>> Is this usage in line to what you have in mind? >>> H.248.15 specifies: a=3Dh248item:/ =3D=20 >>> . For H.248.1 C.9 I do not know which package applies to=20 >>> property TMR. But H.248.15 states "To enable the carriage of package=20 >>> defined properties in the local and remote descriptors of the text=20 >>> encoded H.248.1 protocol the Package attribute shall be used" thus I=20 >>> am wondering whether a package name isn't mandatory? >>> >>> Thanks a lot! >>> >>> Carsten >>> >>> Alcatel >>> >>> Christian Groves wrote: >>> >>>> Hello Tom and Albrecht, >>>> >>>> What peice of information do you want to signal explicitely? Doesn't= =20 >>>> TMR allow you to specify 64Kbit UDI? If so then its supported by=20 >>>> H.248.1 Annex C.9. For H.248 text users this (or any element in=20 >>>> Annex C) can be tranferred via H.248.15. Alternatively Q.1950 sect=20 >>>> 5.7.1.2 specifies an equivalent encoding. >>>> >>>> Regards, Christian >>>> >>>> Tom Taylor wrote: >>>> >>>>> I intended a reference to draft-ietf-avt-rtp-clearmode-04.txt in my= =20 >>>>> intervention. My old draft has been allowed to expire because it=20 >>>>> did not seem to be of much interest to the community. >>>>> >>>>> You are right: the draft just referred to doesn't apply to TDM,=20 >>>>> only to the packet side. I wasn't thinking. I agree that in the=20 >>>>> absence of the attributes provided in my old draft, TDM bearer=20 >>>>> characteristics are assumed rather than signalled explicitly. >>>>> >>>>> Albrecht.Schwarz@alcatel.de wrote: >>>>> >>>>>> I think that the question is, whether this specific TDM bearer=20 >>>>>> capability >>>>>> should be (1) explicitly signalled, or whether (2) implicit=20 >>>>>> assumption is >>>>>> already sufficient. >>>>>> >>>>>> With regard to (1), Tom, I guess that your refer to >>>>>> >>>>>> * RTP/CLEARMODE >>>>>> RTP payload format for a 64 kbit/s transparent call >>>>>> =20 >>>>>> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-clearmode-0= 4.txt=20 >>>>>> >>>>>> >>>>>> But, this coming RFC may not be directly applied, e.g.,=20 >>>>>> packetization time >>>>>> parameter isn't applicable IMHO. Pls correct me if wrong. >>>>>> >>>>>> Or do you refer to your proposals in your expired draft wrt >>>>>> * TDM/CLEARMODE >>>>>> Conventions for the use of the Session Description Protocol (SDP= ) >>>>>> for Digital Circuit Connections >>>>>> =20 >>>>>> http://www.watersprings.org/pub/id/draft-taylor-mmusic-sdp-tdm-01.= txt >>>>>> >>>>>> My conclusion is, that an explicit signalling method doesn't exist= =20 >>>>>> today >>>>>> ("exception might be Q.1950"). >>>>>> Even though, an explicit TDM Media Descriptor for I.231.1 might=20 >>>>>> be helpful >>>>>> for unambigously specification in certain MG implementations. >>>>>> >>>>>> >>>>>> With regard to (2): >>>>>> Implicit signaling is in my understanding the situation of today.=20 >>>>>> In case >>>>>> of, (a) missing TDM Media Descriptors, or (b) "identical TDM Media >>>>>> Descriptors with transparent channel indications", when a transpar= ent >>>>>> 64-kbit/s bearer connection may be established. >>>>>> Sometimes this is also called "native TDM switching", or "native T= DM >>>>>> hairpinning", but technically it is exactly representing an ISDN B= =20 >>>>>> channel >>>>>> with I.231.1 bearer service. [=3D> the channel may bypass the DSP,= =20 >>>>>> but in >>>>>> case that a DSP is looped-in, then must be the DSP channel=20 >>>>>> operation mode >>>>>> configured for 'Clearmode'] >>>>>> >>>>>> Last comment: >>>>>> Such kind of implicit signalling mechanism is often assumed in tel= co >>>>>> industry, because this is the legacy signaling mechanism within a = TDM >>>>>> switch ("if there aren't any signaled bearer capabilities then=20 >>>>>> transparent >>>>>> channel; any needed bearer capability in addition must be explicit= ly >>>>>> signalled, like signal processing network equipment functions,=20 >>>>>> e.g., EC"). >>>>>> >>>>>> TDM hairpinning means, an "H.248-controlled TDM switching=20 >>>>>> function" from >>>>>> H.248 Media Gateway perspective. Hence, this implicit signalling=20 >>>>>> assumption >>>>>> may be still valid, or do you see any needs for explicit signaling >>>>>> codepoints in case of TDM-to-TDM ISDN I.231.1 calls? >>>>>> >>>>>> Regards >>>>>> >>>>>> Albrecht >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> = = =20 >>>>>> Tom=20 >>>>>> Taylor = =20 >>>>>> >>>>> = =20 >>>>>> tworks.com> cc: Albrecht=20 >>>>>> SCHWARZ/DE/ALCATEL@ALCATEL,=20 >>>>>> megaco@ietf.org =20 >>>>>> Subject: Re: TDM=20 >>>>>> Hairpinning; Re: [Megaco] Hairpin case A/u Law=20 >>>>>> conversion =20 >>>>>> 26.02.2004=20 >>>>>> 14:05 = =20 >>>>>> = = =20 >>>>>> = = =20 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I think you would do it by specifying the CLEARMODE codec in the=20 >>>>>> Local and >>>>>> Remote >>>>>> descriptors. Unfortunately, CLEARMODE is still under=20 >>>>>> consideration by the >>>>>> IESG >>>>>> and hasn't reached RFC status. >>>>>> >>>>>> Zhao Bo wrote: >>>>>> >>>>>>> Dear Albrecht: >>>>>>> Is there any H.248 package defined to signal the UDI transpare= ncy >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> properties in TDM hairping case? >>>>>> >>>>>>> Best regards >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>> From: >>>>>>> To: "Zhao Bo" >>>>>>> Cc: ; >>>>>>> Sent: Wednesday, February 25, 2004 10:24 PM >>>>>>> Subject: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law=20 >>>>>>> conversion >>>>>>> >>>>>>> >>>>>>> >>>>>>> Dear Zhao Bo, >>>>>>> >>>>>>> because there isn't any "hairpinning" definition in MEGACOP/H.248 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> standards >>>>>> >>>>>>> ("please correct if I'm wrong"), I'd like to use the following=20 >>>>>>> one for >>>>>>> responding your questions: >>>>>>> >>>>>>> >>>>>> >>>>>> ******************************************************************= *****************=20 >>>>>> >>>>>> >>>>>> >>>>>>> Definition: >>>>>>> TDM Hairpinning >>>>>>> ? is a scenario whereby a call is being made between two TDM=20 >>>>>>> endpoints on >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> a >>>>>> >>>>>>> single media gateway. The media comes in on one TDM channel=20 >>>>>>> and goes >>>>>>> out on another TDM channel through the use of an internal loop= =20 >>>>>>> in the >>>>>>> media gateway. >>>>>>> >>>>>>> Note 1: due to the fact that there are local call types at local >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> exchanges >>>>>> >>>>>>> (CLASS5), and transit exchanges (CLASS4) in legacy TDM networks=20 >>>>>>> (PSTN, >>>>>>> NISDN, etc), there is a variety of TDM-to-TDM connection types=20 >>>>>>> behind the >>>>>>> general "TDM hairpinning" capability (dependent on required type=20 >>>>>>> of IWF, >>>>>>> etc.) in corresponding H.248 MG types >>>>>>> >>>>>>> Note 2: H.248/MEGCOP perspective >>>>>>> TDM Hairpinning =3D Single H.248 Context with 2 H.248 TDM Termina= tions >>>>>>> >>>>>> >>>>>> ******************************************************************= ******************=20 >>>>>> >>>>>> >>>>>> >>>>>>> Based on this hairpinning understanding, my answers are: >>>>>>> >>>>>>> (1) Speech telephony service: G.711 companding formats are a=20 >>>>>>> property of >>>>>>> the corresponding H.248 TDM termination >>>>>>> >>>>>>> [Note: dependent on MG architecture and implementation, property=20 >>>>>>> might be >>>>>>> signalled or preprovisioned. Of course, G.711 companding law is a= n >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> inherent >>>>>> >>>>>>> property of your DS0 channel at your PDH/SDH/SONET framer; the=20 >>>>>>> way, how >>>>>>> this DS0 property is associated with the corresponding H.248 TDM >>>>>>> Termination property may only realized MG-internally for very=20 >>>>>>> specific MG >>>>>>> architectures. Generally it is up to the MGC, particularly if=20 >>>>>>> some (or >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> all) >>>>>> >>>>>>> DS0's are ISDN B channels.] >>>>>>> >>>>>>> (2) Voiceband Data services: same as in (1) >>>>>>> >>>>>>> [Note: VBD according new ITU-T V.152 -> "... For purposes of >>>>>>> interoperability, a V.152 compliant implementation shall support=20 >>>>>>> at least >>>>>>> both G.711 A-law and G.711 =C3=AC-law codecs as VBD codecs. "] >>>>>>> >>>>>>> (3) ISDN UDI =3D all ISDN Teleservices with ISDN I.231. bearer se= rvice >>>>>>> requirement >>>>>>> =3D> H.248 TDM Termination property must be signalled by MGC, if=20 >>>>>>> not, MG >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> may >>>>>> >>>>>>> not guarantee UDI capability (i.e., fully transparent 64-kbit/s=20 >>>>>>> bearer >>>>>>> channel) in TDM hairpinning scenarios ... >>>>>>> >>>>>>> >>>>>>> Conclusion: >>>>>>> IF your MG is supporting >>>>>>> PSTN lines (=3D H.248 ALN Termination), >>>>>>> PSTN trunks (=3D H.248 TDM Termination), and >>>>>>> ISDN B channels (=3D H.248 TDM Termination) >>>>>>> >>>>>>> AND IF you've such services and interworking requirements >>>>>>> >>>>>>> THEN you should generally signal the corresponding properties ... >>>>>>> >>>>>>> ... in case of >>>>>>> TDM hairpinning, >>>>>>> ALN hairpinning, or >>>>>>> ALN-to-TDM connection types. >>>>>>> >>>>>>> Regards, >>>>>>> Albrecht >>>>>>> >>>>>>> ALCATEL >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>>> Zhao Bo >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> To: =20 >>>>>>> megaco@ietf.org >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Sent by: cc: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> megaco-admin@iet Subject: [Megaco]=20 >>>>>>> Hairpin >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> case A/u Law conversion >>>>>> >>>>>>> f.org >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> 25.02.2004 08:11 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> In this case, the A/u law format of a TDM ciruit can be=20 >>>>>>> provisioned, but >>>>>>> the MG doesn't know the service type of a call, thus >>>>>>> has no way to know if a conversion is needed. For speech service >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> conversion >>>>>> >>>>>>> may be needed; for data service like isdn UDI, conversion is not >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> permitted. >>>>>> >>>>>>> Is there any method to solve this problem? >>>>>>> >>>>>>> Zhao Bo >>>>>>> >>>>>>> ***************************************************************** >>>>>>> This e-mail and its attachments contain confidential information=20 >>>>>>> from >>>>>>> HUAWEI, which is intended only for the person or entity whose=20 >>>>>>> address is >>>>>>> listed above. Any use of the information contained herein in any = way >>>>>>> (including, but not limited to, total or partial disclosure, >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> reproduction, >>>>>> >>>>>>> or dissemination) by persons other than the intended recipient(s)= is >>>>>>> prohibited. If you receive this e-mail in error, please notify=20 >>>>>>> the sender >>>>>>> by phone or email immediately and delete it! >>>>>>> ***************************************************************** >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Megaco mailing list >>>>>>> Megaco@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/megaco >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Megaco mailing list >>>>>>> Megaco@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/megaco >>>>>>> 1=C3=A8=1Ar=E2=80=B0=C5=A1=C5=A0X=C2=A7=E2=80=9AX=C2=AC=C2=B4=C3=87= i=C3=8A"z=C3=97=C3=A8=C2=AE=08m=C2=B6=E2=80=BA?=C3=BF=0C0=C3=96'=C2=AD~=C5= =A0=C3=A0=C3=BEf=C2=A2=E2=80=93f=C2=A7=C3=BEX=C2=AC=C2=B6)=C3=9F=C2=A3=C3= =B9=C5=BE=EF=A2=9D=C2=A7( >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Megaco mailing list >>>>> Megaco@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/megaco >>>>> >>>> >>>> >>>> This communication is confidential and intended solely for the=20 >>>> addressee(s). Any unauthorized review, use, disclosure or=20 >>>> distribution is prohibited. If you believe this message has been=20 >>>> sent to you in error, please notify the sender by replying to this=20 >>>> transmission and delete the message without disclosing it. Thank you. >>>> >>>> E-mail including attachments is susceptible to data corruption,=20 >>>> interruption, unauthorized amendment, tampering and viruses, and we=20 >>>> only send and receive e-mails on the basis that we are not liable=20 >>>> for any such corruption, interception, amendment, tampering or=20 >>>> viruses or any consequences thereof. >>>> >>>> >>>> _______________________________________________ >>>> Megaco mailing list >>>> Megaco@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/megaco >>>> >>> >> >> >=20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Tue Apr 27 05:52:59 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17520 for ; Tue, 27 Apr 2004 05:52:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIP8u-0000Qk-8B for megaco-archive@odin.ietf.org; Tue, 27 Apr 2004 05:44:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3R9iidC001650 for megaco-archive@odin.ietf.org; Tue, 27 Apr 2004 05:44:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIP2H-0007hs-M4 for megaco-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 05:37:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16848 for ; Tue, 27 Apr 2004 05:37:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIP2E-0001i7-Aa for megaco-web-archive@ietf.org; Tue, 27 Apr 2004 05:37:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIP1D-0001Wi-00 for megaco-web-archive@ietf.org; Tue, 27 Apr 2004 05:36:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIP0Q-0001Lp-00 for megaco-web-archive@ietf.org; Tue, 27 Apr 2004 05:35:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIOpo-0006CR-Qm; Tue, 27 Apr 2004 05:25:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIOjq-0005QI-1M for megaco@optimus.ietf.org; Tue, 27 Apr 2004 05:18:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16104 for ; Tue, 27 Apr 2004 05:18:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIOjm-0005qN-NL for megaco@ietf.org; Tue, 27 Apr 2004 05:18:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIOis-0005fF-00 for megaco@ietf.org; Tue, 27 Apr 2004 05:17:51 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BIOhv-0005UK-00 for megaco@ietf.org; Tue, 27 Apr 2004 05:16:51 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3R9GqAh003746 for ; Tue, 27 Apr 2004 11:16:52 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 27 Apr 2004 11:16:52 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JSDTFZT7; Tue, 27 Apr 2004 11:17:00 +0200 Received: from ericsson.com (sealwa04-205.sw.ericsson.se [130.100.249.205]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JRYYX3XW; Tue, 27 Apr 2004 19:16:37 +1000 Message-ID: <408E24FA.2070303@ericsson.com> Date: Tue, 27 Apr 2004 19:16:42 +1000 X-Sybari-Trust: e257681b 1f7207db 8d4fd520 00000139 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Carsten Waitzmann CC: Tom Taylor , Albrecht.Schwarz@alcatel.de, Zhao Bo , megaco@ietf.org Subject: Re: Signaling of UDI rsp Clearmode Bearer Service; Re: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversion References: <403E1760.2010903@nortelnetworks.com> <40427B92.3000707@ericsson.com> <406C2424.7050708@alcatel.de> <40720E2A.6070903@ericsson.com> <408D053E.2080405@alcatel.de> In-Reply-To: <408D053E.2080405@alcatel.de> Content-Type: text/plain; charset=UTF-8; format=flowed X-OriginalArrivalTime: 27 Apr 2004 09:16:52.0116 (UTC) FILETIME=[60730D40:01C42C38] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by eagle.ericsson.se id i3R9GqAh003746 Content-Transfer-Encoding: quoted-printable Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello Carsten, Seems you have a very good point. The text name for Annex C is missing. I propose using "AnxC". Or is there another suggestion? I will put this in a contribution for the upcoming ITU SG16 meeting. Regards, Christian Carsten Waitzmann wrote: > Hello Christian, >=20 > thanks for the information. I am still missing one piece: >=20 > In case of textual encoding, what should be used for the= =20 > media stream properties described in H.248.1 Annex C? >=20 > a=3Dh248item:/TMR =3D 40 >=20 > thanks. > Carsten >=20 > Christian Groves wrote: >=20 >> Hello Carsten, >> >> Yes this is what I had in mind. The package ID for Annex C is 0. >> >> ie. H.248.1 Annex A >> PkgdName ::=3D OCTET STRING(SIZE(4)) >> -- represents Package Name (2 octets) plus Property, Event, >> -- Signal Names or Statistics ID. (2 octets) >> -- To wildcard a package use 0xFFFF for first two octets, choose >> -- is not allowed. To reference native property tag specified in >> -- Annex C, use 0x0000 as first two octets. >> >> Regards, Christian >> >> Carsten Waitzmann wrote: >> >>> Hello Christian, >>> >>> I took your suggestion as a basis for the following example: >>> >>> MGC -> MG: >>> MEGACO / 1 [1.2.3.4] >>> Transaction =3D 100 { >>> Context =3D $ { Add =3D TDM1 { >>> Media { >>> LocalControl {Mode =3D=20 >>> SendReceive}, >>> Local {a=3Dh248item:TMR = =3D=20 >>> 0000 0010}} >>> }}} >>> >>> MG -> MGC >>> MEGACO / 1 [1.2.3.5] >>> Reply =3D 100 { >>> Context =3D 1 { >>> Add =3D TDM1 { >>> Media { >>> Local {a=3Dh248item:TM= R=20 >>> =3D 00000010} >>> }}}} >>> >>> Is this usage in line to what you have in mind? >>> H.248.15 specifies: a=3Dh248item:/ =3D=20 >>> . For H.248.1 C.9 I do not know which package applies to=20 >>> property TMR. But H.248.15 states "To enable the carriage of package=20 >>> defined properties in the local and remote descriptors of the text=20 >>> encoded H.248.1 protocol the Package attribute shall be used" thus I=20 >>> am wondering whether a package name isn't mandatory? >>> >>> Thanks a lot! >>> >>> Carsten >>> >>> Alcatel >>> >>> Christian Groves wrote: >>> >>>> Hello Tom and Albrecht, >>>> >>>> What peice of information do you want to signal explicitely? Doesn't= =20 >>>> TMR allow you to specify 64Kbit UDI? If so then its supported by=20 >>>> H.248.1 Annex C.9. For H.248 text users this (or any element in=20 >>>> Annex C) can be tranferred via H.248.15. Alternatively Q.1950 sect=20 >>>> 5.7.1.2 specifies an equivalent encoding. >>>> >>>> Regards, Christian >>>> >>>> Tom Taylor wrote: >>>> >>>>> I intended a reference to draft-ietf-avt-rtp-clearmode-04.txt in my= =20 >>>>> intervention. My old draft has been allowed to expire because it=20 >>>>> did not seem to be of much interest to the community. >>>>> >>>>> You are right: the draft just referred to doesn't apply to TDM,=20 >>>>> only to the packet side. I wasn't thinking. I agree that in the=20 >>>>> absence of the attributes provided in my old draft, TDM bearer=20 >>>>> characteristics are assumed rather than signalled explicitly. >>>>> >>>>> Albrecht.Schwarz@alcatel.de wrote: >>>>> >>>>>> I think that the question is, whether this specific TDM bearer=20 >>>>>> capability >>>>>> should be (1) explicitly signalled, or whether (2) implicit=20 >>>>>> assumption is >>>>>> already sufficient. >>>>>> >>>>>> With regard to (1), Tom, I guess that your refer to >>>>>> >>>>>> * RTP/CLEARMODE >>>>>> RTP payload format for a 64 kbit/s transparent call >>>>>> =20 >>>>>> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-clearmode-0= 4.txt=20 >>>>>> >>>>>> >>>>>> But, this coming RFC may not be directly applied, e.g.,=20 >>>>>> packetization time >>>>>> parameter isn't applicable IMHO. Pls correct me if wrong. >>>>>> >>>>>> Or do you refer to your proposals in your expired draft wrt >>>>>> * TDM/CLEARMODE >>>>>> Conventions for the use of the Session Description Protocol (SDP= ) >>>>>> for Digital Circuit Connections >>>>>> =20 >>>>>> http://www.watersprings.org/pub/id/draft-taylor-mmusic-sdp-tdm-01.= txt >>>>>> >>>>>> My conclusion is, that an explicit signalling method doesn't exist= =20 >>>>>> today >>>>>> ("exception might be Q.1950"). >>>>>> Even though, an explicit TDM Media Descriptor for I.231.1 might=20 >>>>>> be helpful >>>>>> for unambigously specification in certain MG implementations. >>>>>> >>>>>> >>>>>> With regard to (2): >>>>>> Implicit signaling is in my understanding the situation of today.=20 >>>>>> In case >>>>>> of, (a) missing TDM Media Descriptors, or (b) "identical TDM Media >>>>>> Descriptors with transparent channel indications", when a transpar= ent >>>>>> 64-kbit/s bearer connection may be established. >>>>>> Sometimes this is also called "native TDM switching", or "native T= DM >>>>>> hairpinning", but technically it is exactly representing an ISDN B= =20 >>>>>> channel >>>>>> with I.231.1 bearer service. [=3D> the channel may bypass the DSP,= =20 >>>>>> but in >>>>>> case that a DSP is looped-in, then must be the DSP channel=20 >>>>>> operation mode >>>>>> configured for 'Clearmode'] >>>>>> >>>>>> Last comment: >>>>>> Such kind of implicit signalling mechanism is often assumed in tel= co >>>>>> industry, because this is the legacy signaling mechanism within a = TDM >>>>>> switch ("if there aren't any signaled bearer capabilities then=20 >>>>>> transparent >>>>>> channel; any needed bearer capability in addition must be explicit= ly >>>>>> signalled, like signal processing network equipment functions,=20 >>>>>> e.g., EC"). >>>>>> >>>>>> TDM hairpinning means, an "H.248-controlled TDM switching=20 >>>>>> function" from >>>>>> H.248 Media Gateway perspective. Hence, this implicit signalling=20 >>>>>> assumption >>>>>> may be still valid, or do you see any needs for explicit signaling >>>>>> codepoints in case of TDM-to-TDM ISDN I.231.1 calls? >>>>>> >>>>>> Regards >>>>>> >>>>>> Albrecht >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> = = =20 >>>>>> Tom=20 >>>>>> Taylor = =20 >>>>>> >>>>> = =20 >>>>>> tworks.com> cc: Albrecht=20 >>>>>> SCHWARZ/DE/ALCATEL@ALCATEL,=20 >>>>>> megaco@ietf.org =20 >>>>>> Subject: Re: TDM=20 >>>>>> Hairpinning; Re: [Megaco] Hairpin case A/u Law=20 >>>>>> conversion =20 >>>>>> 26.02.2004=20 >>>>>> 14:05 = =20 >>>>>> = = =20 >>>>>> = = =20 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I think you would do it by specifying the CLEARMODE codec in the=20 >>>>>> Local and >>>>>> Remote >>>>>> descriptors. Unfortunately, CLEARMODE is still under=20 >>>>>> consideration by the >>>>>> IESG >>>>>> and hasn't reached RFC status. >>>>>> >>>>>> Zhao Bo wrote: >>>>>> >>>>>>> Dear Albrecht: >>>>>>> Is there any H.248 package defined to signal the UDI transpare= ncy >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> properties in TDM hairping case? >>>>>> >>>>>>> Best regards >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>> From: >>>>>>> To: "Zhao Bo" >>>>>>> Cc: ; >>>>>>> Sent: Wednesday, February 25, 2004 10:24 PM >>>>>>> Subject: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law=20 >>>>>>> conversion >>>>>>> >>>>>>> >>>>>>> >>>>>>> Dear Zhao Bo, >>>>>>> >>>>>>> because there isn't any "hairpinning" definition in MEGACOP/H.248 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> standards >>>>>> >>>>>>> ("please correct if I'm wrong"), I'd like to use the following=20 >>>>>>> one for >>>>>>> responding your questions: >>>>>>> >>>>>>> >>>>>> >>>>>> ******************************************************************= *****************=20 >>>>>> >>>>>> >>>>>> >>>>>>> Definition: >>>>>>> TDM Hairpinning >>>>>>> ? is a scenario whereby a call is being made between two TDM=20 >>>>>>> endpoints on >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> a >>>>>> >>>>>>> single media gateway. The media comes in on one TDM channel=20 >>>>>>> and goes >>>>>>> out on another TDM channel through the use of an internal loop= =20 >>>>>>> in the >>>>>>> media gateway. >>>>>>> >>>>>>> Note 1: due to the fact that there are local call types at local >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> exchanges >>>>>> >>>>>>> (CLASS5), and transit exchanges (CLASS4) in legacy TDM networks=20 >>>>>>> (PSTN, >>>>>>> NISDN, etc), there is a variety of TDM-to-TDM connection types=20 >>>>>>> behind the >>>>>>> general "TDM hairpinning" capability (dependent on required type=20 >>>>>>> of IWF, >>>>>>> etc.) in corresponding H.248 MG types >>>>>>> >>>>>>> Note 2: H.248/MEGCOP perspective >>>>>>> TDM Hairpinning =3D Single H.248 Context with 2 H.248 TDM Termina= tions >>>>>>> >>>>>> >>>>>> ******************************************************************= ******************=20 >>>>>> >>>>>> >>>>>> >>>>>>> Based on this hairpinning understanding, my answers are: >>>>>>> >>>>>>> (1) Speech telephony service: G.711 companding formats are a=20 >>>>>>> property of >>>>>>> the corresponding H.248 TDM termination >>>>>>> >>>>>>> [Note: dependent on MG architecture and implementation, property=20 >>>>>>> might be >>>>>>> signalled or preprovisioned. Of course, G.711 companding law is a= n >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> inherent >>>>>> >>>>>>> property of your DS0 channel at your PDH/SDH/SONET framer; the=20 >>>>>>> way, how >>>>>>> this DS0 property is associated with the corresponding H.248 TDM >>>>>>> Termination property may only realized MG-internally for very=20 >>>>>>> specific MG >>>>>>> architectures. Generally it is up to the MGC, particularly if=20 >>>>>>> some (or >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> all) >>>>>> >>>>>>> DS0's are ISDN B channels.] >>>>>>> >>>>>>> (2) Voiceband Data services: same as in (1) >>>>>>> >>>>>>> [Note: VBD according new ITU-T V.152 -> "... For purposes of >>>>>>> interoperability, a V.152 compliant implementation shall support=20 >>>>>>> at least >>>>>>> both G.711 A-law and G.711 =C3=AC-law codecs as VBD codecs. "] >>>>>>> >>>>>>> (3) ISDN UDI =3D all ISDN Teleservices with ISDN I.231. bearer se= rvice >>>>>>> requirement >>>>>>> =3D> H.248 TDM Termination property must be signalled by MGC, if=20 >>>>>>> not, MG >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> may >>>>>> >>>>>>> not guarantee UDI capability (i.e., fully transparent 64-kbit/s=20 >>>>>>> bearer >>>>>>> channel) in TDM hairpinning scenarios ... >>>>>>> >>>>>>> >>>>>>> Conclusion: >>>>>>> IF your MG is supporting >>>>>>> PSTN lines (=3D H.248 ALN Termination), >>>>>>> PSTN trunks (=3D H.248 TDM Termination), and >>>>>>> ISDN B channels (=3D H.248 TDM Termination) >>>>>>> >>>>>>> AND IF you've such services and interworking requirements >>>>>>> >>>>>>> THEN you should generally signal the corresponding properties ... >>>>>>> >>>>>>> ... in case of >>>>>>> TDM hairpinning, >>>>>>> ALN hairpinning, or >>>>>>> ALN-to-TDM connection types. >>>>>>> >>>>>>> Regards, >>>>>>> Albrecht >>>>>>> >>>>>>> ALCATEL >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>>> Zhao Bo >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> To: =20 >>>>>>> megaco@ietf.org >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Sent by: cc: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> megaco-admin@iet Subject: [Megaco]=20 >>>>>>> Hairpin >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> case A/u Law conversion >>>>>> >>>>>>> f.org >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> 25.02.2004 08:11 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> In this case, the A/u law format of a TDM ciruit can be=20 >>>>>>> provisioned, but >>>>>>> the MG doesn't know the service type of a call, thus >>>>>>> has no way to know if a conversion is needed. For speech service >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> conversion >>>>>> >>>>>>> may be needed; for data service like isdn UDI, conversion is not >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> permitted. >>>>>> >>>>>>> Is there any method to solve this problem? >>>>>>> >>>>>>> Zhao Bo >>>>>>> >>>>>>> ***************************************************************** >>>>>>> This e-mail and its attachments contain confidential information=20 >>>>>>> from >>>>>>> HUAWEI, which is intended only for the person or entity whose=20 >>>>>>> address is >>>>>>> listed above. Any use of the information contained herein in any = way >>>>>>> (including, but not limited to, total or partial disclosure, >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> reproduction, >>>>>> >>>>>>> or dissemination) by persons other than the intended recipient(s)= is >>>>>>> prohibited. If you receive this e-mail in error, please notify=20 >>>>>>> the sender >>>>>>> by phone or email immediately and delete it! >>>>>>> ***************************************************************** >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Megaco mailing list >>>>>>> Megaco@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/megaco >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Megaco mailing list >>>>>>> Megaco@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/megaco >>>>>>> 1=C3=A8=1Ar=E2=80=B0=C5=A1=C5=A0X=C2=A7=E2=80=9AX=C2=AC=C2=B4=C3=87= i=C3=8A"z=C3=97=C3=A8=C2=AE=08m=C2=B6=E2=80=BA?=C3=BF=0C0=C3=96'=C2=AD~=C5= =A0=C3=A0=C3=BEf=C2=A2=E2=80=93f=C2=A7=C3=BEX=C2=AC=C2=B6)=C3=9F=C2=A3=C3= =B9=C5=BE=EF=A2=9D=C2=A7( >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Megaco mailing list >>>>> Megaco@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/megaco >>>>> >>>> >>>> >>>> This communication is confidential and intended solely for the=20 >>>> addressee(s). Any unauthorized review, use, disclosure or=20 >>>> distribution is prohibited. If you believe this message has been=20 >>>> sent to you in error, please notify the sender by replying to this=20 >>>> transmission and delete the message without disclosing it. Thank you. >>>> >>>> E-mail including attachments is susceptible to data corruption,=20 >>>> interruption, unauthorized amendment, tampering and viruses, and we=20 >>>> only send and receive e-mails on the basis that we are not liable=20 >>>> for any such corruption, interception, amendment, tampering or=20 >>>> viruses or any consequences thereof. >>>> >>>> >>>> _______________________________________________ >>>> Megaco mailing list >>>> Megaco@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/megaco >>>> >>> >> >> >=20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Apr 27 08:12:37 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25496 for ; Tue, 27 Apr 2004 08:12:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIRLf-0007HH-6U; Tue, 27 Apr 2004 08:06:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIRDl-0005fb-Vr for megaco@optimus.ietf.org; Tue, 27 Apr 2004 07:57:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24528 for ; Tue, 27 Apr 2004 07:57:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIRDh-0000tx-6A for megaco@ietf.org; Tue, 27 Apr 2004 07:57:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIRCj-0000fd-00 for megaco@ietf.org; Tue, 27 Apr 2004 07:56:51 -0400 Received: from mailrelay1.alcatel.de ([194.113.59.75] helo=mailrelay2.alcatel.de) by ietf-mx with esmtp (Exim 4.12) id 1BIRBm-0000FA-00 for megaco@ietf.org; Tue, 27 Apr 2004 07:55:50 -0400 Received: from ks.sel.alcatel.de (slsv0d.stgl.sel.alcatel.de [149.204.14.10]) by mailrelay2.alcatel.de (8.12.10/8.12.10) with ESMTP id i3RBtDDn012591; Tue, 27 Apr 2004 11:55:13 GMT Received: from slssiv ([149.204.245.89] helo=slsdtk.stgl.sel.alcatel.de) by ks.sel.alcatel.de with esmtp (Exim 3.31) id 1BIRBB-0002Ar-00; Tue, 27 Apr 2004 13:55:13 +0200 Received: from slsufnt ([149.204.245.33] helo=alcatel.de) by slsdtk.stgl.sel.alcatel.de with esmtp (Exim 3.31) id 1BIRBA-0003t4-00; Tue, 27 Apr 2004 13:55:12 +0200 Message-ID: <408E4A20.1050206@alcatel.de> Date: Tue, 27 Apr 2004 13:55:12 +0200 From: Carsten Waitzmann User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Groves CC: Tom Taylor , Albrecht.Schwarz@alcatel.de, Zhao Bo , megaco@ietf.org Subject: Re: Signaling of UDI rsp Clearmode Bearer Service; Re: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversion References: <403E1760.2010903@nortelnetworks.com> <40427B92.3000707@ericsson.com> <406C2424.7050708@alcatel.de> <40720E2A.6070903@ericsson.com> <408D053E.2080405@alcatel.de> <408E24FA.2070303@ericsson.com> In-Reply-To: <408E24FA.2070303@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed X-Alcanet-virus-scanned: i3RBtDDn012591 at mailrelay2.alcatel.de Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mailrelay2.alcatel.de id i3RBtDDn012591 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Christian, Your suggestion is OK for us. We (Alcatel) will support your contribution. thanks. Carsten Christian Groves wrote: > Hello Carsten, > > Seems you have a very good point. The text name for Annex C is missing. > I propose using "AnxC". Or is there another suggestion? > > I will put this in a contribution for the upcoming ITU SG16 meeting. > > Regards, Christian > > Carsten Waitzmann wrote: > >> Hello Christian, >> >> thanks for the information. I am still missing one piece: >> >> In case of textual encoding, what should be used for=20 >> the media stream properties described in H.248.1 Annex C? >> >> a=3Dh248item:/TMR =3D 40 >> >> thanks. >> Carsten >> >> Christian Groves wrote: >> >>> Hello Carsten, >>> >>> Yes this is what I had in mind. The package ID for Annex C is 0. >>> >>> ie. H.248.1 Annex A >>> PkgdName ::=3D OCTET STRING(SIZE(4)) >>> -- represents Package Name (2 octets) plus Property, Event, >>> -- Signal Names or Statistics ID. (2 octets) >>> -- To wildcard a package use 0xFFFF for first two octets, choose >>> -- is not allowed. To reference native property tag specified in >>> -- Annex C, use 0x0000 as first two octets. >>> >>> Regards, Christian >>> >>> Carsten Waitzmann wrote: >>> >>>> Hello Christian, >>>> >>>> I took your suggestion as a basis for the following example: >>>> >>>> MGC -> MG: >>>> MEGACO / 1 [1.2.3.4] >>>> Transaction =3D 100 { >>>> Context =3D $ { Add =3D TDM1 { >>>> Media { >>>> LocalControl {Mode =3D=20 >>>> SendReceive}, >>>> Local {a=3Dh248item:TMR= =20 >>>> =3D 0000 0010}} >>>> }}} >>>> >>>> MG -> MGC >>>> MEGACO / 1 [1.2.3.5] >>>> Reply =3D 100 { >>>> Context =3D 1 { >>>> Add =3D TDM1 { >>>> Media { >>>> Local=20 >>>> {a=3Dh248item:TMR =3D 00000010} >>>> }}}} >>>> >>>> Is this usage in line to what you have in mind? >>>> H.248.15 specifies: a=3Dh248item:/ =3D=20 >>>> . For H.248.1 C.9 I do not know which package applies to=20 >>>> property TMR. But H.248.15 states "To enable the carriage of=20 >>>> package defined properties in the local and remote descriptors of=20 >>>> the text encoded H.248.1 protocol the Package attribute shall be=20 >>>> used" thus I am wondering whether a package name isn't mandatory? >>>> >>>> Thanks a lot! >>>> >>>> Carsten >>>> >>>> Alcatel >>>> >>>> Christian Groves wrote: >>>> >>>>> Hello Tom and Albrecht, >>>>> >>>>> What peice of information do you want to signal explicitely?=20 >>>>> Doesn't TMR allow you to specify 64Kbit UDI? If so then its=20 >>>>> supported by H.248.1 Annex C.9. For H.248 text users this (or any=20 >>>>> element in Annex C) can be tranferred via H.248.15. Alternatively=20 >>>>> Q.1950 sect 5.7.1.2 specifies an equivalent encoding. >>>>> >>>>> Regards, Christian >>>>> >>>>> Tom Taylor wrote: >>>>> >>>>>> I intended a reference to draft-ietf-avt-rtp-clearmode-04.txt in=20 >>>>>> my intervention. My old draft has been allowed to expire because=20 >>>>>> it did not seem to be of much interest to the community. >>>>>> >>>>>> You are right: the draft just referred to doesn't apply to TDM,=20 >>>>>> only to the packet side. I wasn't thinking. I agree that in the=20 >>>>>> absence of the attributes provided in my old draft, TDM bearer=20 >>>>>> characteristics are assumed rather than signalled explicitly. >>>>>> >>>>>> Albrecht.Schwarz@alcatel.de wrote: >>>>>> >>>>>>> I think that the question is, whether this specific TDM bearer=20 >>>>>>> capability >>>>>>> should be (1) explicitly signalled, or whether (2) implicit=20 >>>>>>> assumption is >>>>>>> already sufficient. >>>>>>> >>>>>>> With regard to (1), Tom, I guess that your refer to >>>>>>> >>>>>>> * RTP/CLEARMODE >>>>>>> RTP payload format for a 64 kbit/s transparent call >>>>>>> =20 >>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-clearmode-= 04.txt=20 >>>>>>> >>>>>>> >>>>>>> But, this coming RFC may not be directly applied, e.g.,=20 >>>>>>> packetization time >>>>>>> parameter isn't applicable IMHO. Pls correct me if wrong. >>>>>>> >>>>>>> Or do you refer to your proposals in your expired draft wrt >>>>>>> * TDM/CLEARMODE >>>>>>> Conventions for the use of the Session Description Protocol (SD= P) >>>>>>> for Digital Circuit Connections >>>>>>> =20 >>>>>>> http://www.watersprings.org/pub/id/draft-taylor-mmusic-sdp-tdm-01= .txt=20 >>>>>>> >>>>>>> >>>>>>> My conclusion is, that an explicit signalling method doesn't=20 >>>>>>> exist today >>>>>>> ("exception might be Q.1950"). >>>>>>> Even though, an explicit TDM Media Descriptor for I.231.1 might=20 >>>>>>> be helpful >>>>>>> for unambigously specification in certain MG implementations. >>>>>>> >>>>>>> >>>>>>> With regard to (2): >>>>>>> Implicit signaling is in my understanding the situation of=20 >>>>>>> today. In case >>>>>>> of, (a) missing TDM Media Descriptors, or (b) "identical TDM Medi= a >>>>>>> Descriptors with transparent channel indications", when a=20 >>>>>>> transparent >>>>>>> 64-kbit/s bearer connection may be established. >>>>>>> Sometimes this is also called "native TDM switching", or "native=20 >>>>>>> TDM >>>>>>> hairpinning", but technically it is exactly representing an ISDN=20 >>>>>>> B channel >>>>>>> with I.231.1 bearer service. [=3D> the channel may bypass the DSP= ,=20 >>>>>>> but in >>>>>>> case that a DSP is looped-in, then must be the DSP channel=20 >>>>>>> operation mode >>>>>>> configured for 'Clearmode'] >>>>>>> >>>>>>> Last comment: >>>>>>> Such kind of implicit signalling mechanism is often assumed in=20 >>>>>>> telco >>>>>>> industry, because this is the legacy signaling mechanism within=20 >>>>>>> a TDM >>>>>>> switch ("if there aren't any signaled bearer capabilities then=20 >>>>>>> transparent >>>>>>> channel; any needed bearer capability in addition must be=20 >>>>>>> explicitly >>>>>>> signalled, like signal processing network equipment functions,=20 >>>>>>> e.g., EC"). >>>>>>> >>>>>>> TDM hairpinning means, an "H.248-controlled TDM switching=20 >>>>>>> function" from >>>>>>> H.248 Media Gateway perspective. Hence, this implicit signalling=20 >>>>>>> assumption >>>>>>> may be still valid, or do you see any needs for explicit signalin= g >>>>>>> codepoints in case of TDM-to-TDM ISDN I.231.1 calls? >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Albrecht >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> = = =20 >>>>>>> Tom=20 >>>>>>> Taylor = =20 >>>>>>> >>>>>> = =20 >>>>>>> tworks.com> cc: Albrecht=20 >>>>>>> SCHWARZ/DE/ALCATEL@ALCATEL,=20 >>>>>>> megaco@ietf.org =20 >>>>>>> Subject: Re: TDM=20 >>>>>>> Hairpinning; Re: [Megaco] Hairpin case A/u Law=20 >>>>>>> conversion =20 >>>>>>> 26.02.2004=20 >>>>>>> 14:05 = =20 >>>>>>> = = =20 >>>>>>> = = =20 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I think you would do it by specifying the CLEARMODE codec in the=20 >>>>>>> Local and >>>>>>> Remote >>>>>>> descriptors. Unfortunately, CLEARMODE is still under=20 >>>>>>> consideration by the >>>>>>> IESG >>>>>>> and hasn't reached RFC status. >>>>>>> >>>>>>> Zhao Bo wrote: >>>>>>> >>>>>>>> Dear Albrecht: >>>>>>>> Is there any H.248 package defined to signal the UDI=20 >>>>>>>> transparency >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> properties in TDM hairping case? >>>>>>> >>>>>>>> Best regards >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>> From: >>>>>>>> To: "Zhao Bo" >>>>>>>> Cc: ; >>>>>>>> Sent: Wednesday, February 25, 2004 10:24 PM >>>>>>>> Subject: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law=20 >>>>>>>> conversion >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Dear Zhao Bo, >>>>>>>> >>>>>>>> because there isn't any "hairpinning" definition in MEGACOP/H.24= 8 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> standards >>>>>>> >>>>>>>> ("please correct if I'm wrong"), I'd like to use the following=20 >>>>>>>> one for >>>>>>>> responding your questions: >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> *****************************************************************= ******************=20 >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Definition: >>>>>>>> TDM Hairpinning >>>>>>>> ? is a scenario whereby a call is being made between two TDM=20 >>>>>>>> endpoints on >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> a >>>>>>> >>>>>>>> single media gateway. The media comes in on one TDM channel=20 >>>>>>>> and goes >>>>>>>> out on another TDM channel through the use of an internal=20 >>>>>>>> loop in the >>>>>>>> media gateway. >>>>>>>> >>>>>>>> Note 1: due to the fact that there are local call types at local >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> exchanges >>>>>>> >>>>>>>> (CLASS5), and transit exchanges (CLASS4) in legacy TDM networks=20 >>>>>>>> (PSTN, >>>>>>>> NISDN, etc), there is a variety of TDM-to-TDM connection types=20 >>>>>>>> behind the >>>>>>>> general "TDM hairpinning" capability (dependent on required=20 >>>>>>>> type of IWF, >>>>>>>> etc.) in corresponding H.248 MG types >>>>>>>> >>>>>>>> Note 2: H.248/MEGCOP perspective >>>>>>>> TDM Hairpinning =3D Single H.248 Context with 2 H.248 TDM=20 >>>>>>>> Terminations >>>>>>>> >>>>>>> >>>>>>> *****************************************************************= *******************=20 >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Based on this hairpinning understanding, my answers are: >>>>>>>> >>>>>>>> (1) Speech telephony service: G.711 companding formats are a=20 >>>>>>>> property of >>>>>>>> the corresponding H.248 TDM termination >>>>>>>> >>>>>>>> [Note: dependent on MG architecture and implementation,=20 >>>>>>>> property might be >>>>>>>> signalled or preprovisioned. Of course, G.711 companding law is = an >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> inherent >>>>>>> >>>>>>>> property of your DS0 channel at your PDH/SDH/SONET framer; the=20 >>>>>>>> way, how >>>>>>>> this DS0 property is associated with the corresponding H.248 TDM >>>>>>>> Termination property may only realized MG-internally for very=20 >>>>>>>> specific MG >>>>>>>> architectures. Generally it is up to the MGC, particularly if=20 >>>>>>>> some (or >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> all) >>>>>>> >>>>>>>> DS0's are ISDN B channels.] >>>>>>>> >>>>>>>> (2) Voiceband Data services: same as in (1) >>>>>>>> >>>>>>>> [Note: VBD according new ITU-T V.152 -> "... For purposes of >>>>>>>> interoperability, a V.152 compliant implementation shall=20 >>>>>>>> support at least >>>>>>>> both G.711 A-law and G.711 =C3=AC-law codecs as VBD codecs. "] >>>>>>>> >>>>>>>> (3) ISDN UDI =3D all ISDN Teleservices with ISDN I.231. bearer=20 >>>>>>>> service >>>>>>>> requirement >>>>>>>> =3D> H.248 TDM Termination property must be signalled by MGC, if= =20 >>>>>>>> not, MG >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> may >>>>>>> >>>>>>>> not guarantee UDI capability (i.e., fully transparent 64-kbit/s=20 >>>>>>>> bearer >>>>>>>> channel) in TDM hairpinning scenarios ... >>>>>>>> >>>>>>>> >>>>>>>> Conclusion: >>>>>>>> IF your MG is supporting >>>>>>>> PSTN lines (=3D H.248 ALN Termination), >>>>>>>> PSTN trunks (=3D H.248 TDM Termination), and >>>>>>>> ISDN B channels (=3D H.248 TDM Termination) >>>>>>>> >>>>>>>> AND IF you've such services and interworking requirements >>>>>>>> >>>>>>>> THEN you should generally signal the corresponding properties ... >>>>>>>> >>>>>>>> ... in case of >>>>>>>> TDM hairpinning, >>>>>>>> ALN hairpinning, or >>>>>>>> ALN-to-TDM connection types. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Albrecht >>>>>>>> >>>>>>>> ALCATEL >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>>> Zhao Bo >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> To: =20 >>>>>>>> megaco@ietf.org >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Sent by: cc: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> megaco-admin@iet Subject: [Megaco]=20 >>>>>>>> Hairpin >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> case A/u Law conversion >>>>>>> >>>>>>>> f.org >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> 25.02.2004 08:11 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> In this case, the A/u law format of a TDM ciruit can be=20 >>>>>>>> provisioned, but >>>>>>>> the MG doesn't know the service type of a call, thus >>>>>>>> has no way to know if a conversion is needed. For speech service >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> conversion >>>>>>> >>>>>>>> may be needed; for data service like isdn UDI, conversion is not >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> permitted. >>>>>>> >>>>>>>> Is there any method to solve this problem? >>>>>>>> >>>>>>>> Zhao Bo >>>>>>>> >>>>>>>> ****************************************************************= * >>>>>>>> This e-mail and its attachments contain confidential=20 >>>>>>>> information from >>>>>>>> HUAWEI, which is intended only for the person or entity whose=20 >>>>>>>> address is >>>>>>>> listed above. Any use of the information contained herein in=20 >>>>>>>> any way >>>>>>>> (including, but not limited to, total or partial disclosure, >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> reproduction, >>>>>>> >>>>>>>> or dissemination) by persons other than the intended=20 >>>>>>>> recipient(s) is >>>>>>>> prohibited. If you receive this e-mail in error, please notify=20 >>>>>>>> the sender >>>>>>>> by phone or email immediately and delete it! >>>>>>>> ****************************************************************= * >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Megaco mailing list >>>>>>>> Megaco@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/megaco >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Megaco mailing list >>>>>>>> Megaco@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/megaco >>>>>>>> 1=C3=A8=1Ar=E2=80=B0=C5=A1=C5=A0X=C2=A7=E2=80=9AX=C2=AC=C2=B4=C3= =87 i=C3=8A"z=C3=97=C3=A8=C2=AE=08m=C2=B6=E2=80=BA?=C3=BF=0C0=C3=96'=C2=AD= ~=C5=A0=C3=A0=C3=BEf=C2=A2=E2=80=93f=C2=A7=C3=BEX=C2=AC=C2=B6)=C3=9F=C2=A3= =C3=B9=C5=BE=EF=A2=9D=C2=A7( >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Megaco mailing list >>>>>> Megaco@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/megaco >>>>>> >>>>> >>>>> >>>>> This communication is confidential and intended solely for the=20 >>>>> addressee(s). Any unauthorized review, use, disclosure or=20 >>>>> distribution is prohibited. If you believe this message has been=20 >>>>> sent to you in error, please notify the sender by replying to this=20 >>>>> transmission and delete the message without disclosing it. Thank yo= u. >>>>> >>>>> E-mail including attachments is susceptible to data corruption,=20 >>>>> interruption, unauthorized amendment, tampering and viruses, and=20 >>>>> we only send and receive e-mails on the basis that we are not=20 >>>>> liable for any such corruption, interception, amendment, tampering=20 >>>>> or viruses or any consequences thereof. >>>>> >>>>> >>>>> _______________________________________________ >>>>> Megaco mailing list >>>>> Megaco@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/megaco >>>>> >>>> >>> >>> >> > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Tue Apr 27 08:30:22 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26983 for ; Tue, 27 Apr 2004 08:30:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIRac-0002i6-SW for megaco-archive@odin.ietf.org; Tue, 27 Apr 2004 08:21:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3RCLUbp010413 for megaco-archive@odin.ietf.org; Tue, 27 Apr 2004 08:21:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIRTZ-0000j8-RG for megaco-web-archive@optimus.ietf.org; Tue, 27 Apr 2004 08:14:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25628 for ; Tue, 27 Apr 2004 08:14:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIRTU-0004sR-Vg for megaco-web-archive@ietf.org; Tue, 27 Apr 2004 08:14:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIRSb-0004bP-00 for megaco-web-archive@ietf.org; Tue, 27 Apr 2004 08:13:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIRRW-0004Ki-00 for megaco-web-archive@ietf.org; Tue, 27 Apr 2004 08:12:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIRLf-0007HH-6U; Tue, 27 Apr 2004 08:06:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIRDl-0005fb-Vr for megaco@optimus.ietf.org; Tue, 27 Apr 2004 07:57:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24528 for ; Tue, 27 Apr 2004 07:57:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIRDh-0000tx-6A for megaco@ietf.org; Tue, 27 Apr 2004 07:57:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIRCj-0000fd-00 for megaco@ietf.org; Tue, 27 Apr 2004 07:56:51 -0400 Received: from mailrelay1.alcatel.de ([194.113.59.75] helo=mailrelay2.alcatel.de) by ietf-mx with esmtp (Exim 4.12) id 1BIRBm-0000FA-00 for megaco@ietf.org; Tue, 27 Apr 2004 07:55:50 -0400 Received: from ks.sel.alcatel.de (slsv0d.stgl.sel.alcatel.de [149.204.14.10]) by mailrelay2.alcatel.de (8.12.10/8.12.10) with ESMTP id i3RBtDDn012591; Tue, 27 Apr 2004 11:55:13 GMT Received: from slssiv ([149.204.245.89] helo=slsdtk.stgl.sel.alcatel.de) by ks.sel.alcatel.de with esmtp (Exim 3.31) id 1BIRBB-0002Ar-00; Tue, 27 Apr 2004 13:55:13 +0200 Received: from slsufnt ([149.204.245.33] helo=alcatel.de) by slsdtk.stgl.sel.alcatel.de with esmtp (Exim 3.31) id 1BIRBA-0003t4-00; Tue, 27 Apr 2004 13:55:12 +0200 Message-ID: <408E4A20.1050206@alcatel.de> Date: Tue, 27 Apr 2004 13:55:12 +0200 From: Carsten Waitzmann User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Groves CC: Tom Taylor , Albrecht.Schwarz@alcatel.de, Zhao Bo , megaco@ietf.org Subject: Re: Signaling of UDI rsp Clearmode Bearer Service; Re: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversion References: <403E1760.2010903@nortelnetworks.com> <40427B92.3000707@ericsson.com> <406C2424.7050708@alcatel.de> <40720E2A.6070903@ericsson.com> <408D053E.2080405@alcatel.de> <408E24FA.2070303@ericsson.com> In-Reply-To: <408E24FA.2070303@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed X-Alcanet-virus-scanned: i3RBtDDn012591 at mailrelay2.alcatel.de Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mailrelay2.alcatel.de id i3RBtDDn012591 Content-Transfer-Encoding: quoted-printable Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Christian, Your suggestion is OK for us. We (Alcatel) will support your contribution. thanks. Carsten Christian Groves wrote: > Hello Carsten, > > Seems you have a very good point. The text name for Annex C is missing. > I propose using "AnxC". Or is there another suggestion? > > I will put this in a contribution for the upcoming ITU SG16 meeting. > > Regards, Christian > > Carsten Waitzmann wrote: > >> Hello Christian, >> >> thanks for the information. I am still missing one piece: >> >> In case of textual encoding, what should be used for=20 >> the media stream properties described in H.248.1 Annex C? >> >> a=3Dh248item:/TMR =3D 40 >> >> thanks. >> Carsten >> >> Christian Groves wrote: >> >>> Hello Carsten, >>> >>> Yes this is what I had in mind. The package ID for Annex C is 0. >>> >>> ie. H.248.1 Annex A >>> PkgdName ::=3D OCTET STRING(SIZE(4)) >>> -- represents Package Name (2 octets) plus Property, Event, >>> -- Signal Names or Statistics ID. (2 octets) >>> -- To wildcard a package use 0xFFFF for first two octets, choose >>> -- is not allowed. To reference native property tag specified in >>> -- Annex C, use 0x0000 as first two octets. >>> >>> Regards, Christian >>> >>> Carsten Waitzmann wrote: >>> >>>> Hello Christian, >>>> >>>> I took your suggestion as a basis for the following example: >>>> >>>> MGC -> MG: >>>> MEGACO / 1 [1.2.3.4] >>>> Transaction =3D 100 { >>>> Context =3D $ { Add =3D TDM1 { >>>> Media { >>>> LocalControl {Mode =3D=20 >>>> SendReceive}, >>>> Local {a=3Dh248item:TMR= =20 >>>> =3D 0000 0010}} >>>> }}} >>>> >>>> MG -> MGC >>>> MEGACO / 1 [1.2.3.5] >>>> Reply =3D 100 { >>>> Context =3D 1 { >>>> Add =3D TDM1 { >>>> Media { >>>> Local=20 >>>> {a=3Dh248item:TMR =3D 00000010} >>>> }}}} >>>> >>>> Is this usage in line to what you have in mind? >>>> H.248.15 specifies: a=3Dh248item:/ =3D=20 >>>> . For H.248.1 C.9 I do not know which package applies to=20 >>>> property TMR. But H.248.15 states "To enable the carriage of=20 >>>> package defined properties in the local and remote descriptors of=20 >>>> the text encoded H.248.1 protocol the Package attribute shall be=20 >>>> used" thus I am wondering whether a package name isn't mandatory? >>>> >>>> Thanks a lot! >>>> >>>> Carsten >>>> >>>> Alcatel >>>> >>>> Christian Groves wrote: >>>> >>>>> Hello Tom and Albrecht, >>>>> >>>>> What peice of information do you want to signal explicitely?=20 >>>>> Doesn't TMR allow you to specify 64Kbit UDI? If so then its=20 >>>>> supported by H.248.1 Annex C.9. For H.248 text users this (or any=20 >>>>> element in Annex C) can be tranferred via H.248.15. Alternatively=20 >>>>> Q.1950 sect 5.7.1.2 specifies an equivalent encoding. >>>>> >>>>> Regards, Christian >>>>> >>>>> Tom Taylor wrote: >>>>> >>>>>> I intended a reference to draft-ietf-avt-rtp-clearmode-04.txt in=20 >>>>>> my intervention. My old draft has been allowed to expire because=20 >>>>>> it did not seem to be of much interest to the community. >>>>>> >>>>>> You are right: the draft just referred to doesn't apply to TDM,=20 >>>>>> only to the packet side. I wasn't thinking. I agree that in the=20 >>>>>> absence of the attributes provided in my old draft, TDM bearer=20 >>>>>> characteristics are assumed rather than signalled explicitly. >>>>>> >>>>>> Albrecht.Schwarz@alcatel.de wrote: >>>>>> >>>>>>> I think that the question is, whether this specific TDM bearer=20 >>>>>>> capability >>>>>>> should be (1) explicitly signalled, or whether (2) implicit=20 >>>>>>> assumption is >>>>>>> already sufficient. >>>>>>> >>>>>>> With regard to (1), Tom, I guess that your refer to >>>>>>> >>>>>>> * RTP/CLEARMODE >>>>>>> RTP payload format for a 64 kbit/s transparent call >>>>>>> =20 >>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-clearmode-= 04.txt=20 >>>>>>> >>>>>>> >>>>>>> But, this coming RFC may not be directly applied, e.g.,=20 >>>>>>> packetization time >>>>>>> parameter isn't applicable IMHO. Pls correct me if wrong. >>>>>>> >>>>>>> Or do you refer to your proposals in your expired draft wrt >>>>>>> * TDM/CLEARMODE >>>>>>> Conventions for the use of the Session Description Protocol (SD= P) >>>>>>> for Digital Circuit Connections >>>>>>> =20 >>>>>>> http://www.watersprings.org/pub/id/draft-taylor-mmusic-sdp-tdm-01= .txt=20 >>>>>>> >>>>>>> >>>>>>> My conclusion is, that an explicit signalling method doesn't=20 >>>>>>> exist today >>>>>>> ("exception might be Q.1950"). >>>>>>> Even though, an explicit TDM Media Descriptor for I.231.1 might=20 >>>>>>> be helpful >>>>>>> for unambigously specification in certain MG implementations. >>>>>>> >>>>>>> >>>>>>> With regard to (2): >>>>>>> Implicit signaling is in my understanding the situation of=20 >>>>>>> today. In case >>>>>>> of, (a) missing TDM Media Descriptors, or (b) "identical TDM Medi= a >>>>>>> Descriptors with transparent channel indications", when a=20 >>>>>>> transparent >>>>>>> 64-kbit/s bearer connection may be established. >>>>>>> Sometimes this is also called "native TDM switching", or "native=20 >>>>>>> TDM >>>>>>> hairpinning", but technically it is exactly representing an ISDN=20 >>>>>>> B channel >>>>>>> with I.231.1 bearer service. [=3D> the channel may bypass the DSP= ,=20 >>>>>>> but in >>>>>>> case that a DSP is looped-in, then must be the DSP channel=20 >>>>>>> operation mode >>>>>>> configured for 'Clearmode'] >>>>>>> >>>>>>> Last comment: >>>>>>> Such kind of implicit signalling mechanism is often assumed in=20 >>>>>>> telco >>>>>>> industry, because this is the legacy signaling mechanism within=20 >>>>>>> a TDM >>>>>>> switch ("if there aren't any signaled bearer capabilities then=20 >>>>>>> transparent >>>>>>> channel; any needed bearer capability in addition must be=20 >>>>>>> explicitly >>>>>>> signalled, like signal processing network equipment functions,=20 >>>>>>> e.g., EC"). >>>>>>> >>>>>>> TDM hairpinning means, an "H.248-controlled TDM switching=20 >>>>>>> function" from >>>>>>> H.248 Media Gateway perspective. Hence, this implicit signalling=20 >>>>>>> assumption >>>>>>> may be still valid, or do you see any needs for explicit signalin= g >>>>>>> codepoints in case of TDM-to-TDM ISDN I.231.1 calls? >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Albrecht >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> = = =20 >>>>>>> Tom=20 >>>>>>> Taylor = =20 >>>>>>> >>>>>> = =20 >>>>>>> tworks.com> cc: Albrecht=20 >>>>>>> SCHWARZ/DE/ALCATEL@ALCATEL,=20 >>>>>>> megaco@ietf.org =20 >>>>>>> Subject: Re: TDM=20 >>>>>>> Hairpinning; Re: [Megaco] Hairpin case A/u Law=20 >>>>>>> conversion =20 >>>>>>> 26.02.2004=20 >>>>>>> 14:05 = =20 >>>>>>> = = =20 >>>>>>> = = =20 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I think you would do it by specifying the CLEARMODE codec in the=20 >>>>>>> Local and >>>>>>> Remote >>>>>>> descriptors. Unfortunately, CLEARMODE is still under=20 >>>>>>> consideration by the >>>>>>> IESG >>>>>>> and hasn't reached RFC status. >>>>>>> >>>>>>> Zhao Bo wrote: >>>>>>> >>>>>>>> Dear Albrecht: >>>>>>>> Is there any H.248 package defined to signal the UDI=20 >>>>>>>> transparency >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> properties in TDM hairping case? >>>>>>> >>>>>>>> Best regards >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>> From: >>>>>>>> To: "Zhao Bo" >>>>>>>> Cc: ; >>>>>>>> Sent: Wednesday, February 25, 2004 10:24 PM >>>>>>>> Subject: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law=20 >>>>>>>> conversion >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Dear Zhao Bo, >>>>>>>> >>>>>>>> because there isn't any "hairpinning" definition in MEGACOP/H.24= 8 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> standards >>>>>>> >>>>>>>> ("please correct if I'm wrong"), I'd like to use the following=20 >>>>>>>> one for >>>>>>>> responding your questions: >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> *****************************************************************= ******************=20 >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Definition: >>>>>>>> TDM Hairpinning >>>>>>>> ? is a scenario whereby a call is being made between two TDM=20 >>>>>>>> endpoints on >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> a >>>>>>> >>>>>>>> single media gateway. The media comes in on one TDM channel=20 >>>>>>>> and goes >>>>>>>> out on another TDM channel through the use of an internal=20 >>>>>>>> loop in the >>>>>>>> media gateway. >>>>>>>> >>>>>>>> Note 1: due to the fact that there are local call types at local >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> exchanges >>>>>>> >>>>>>>> (CLASS5), and transit exchanges (CLASS4) in legacy TDM networks=20 >>>>>>>> (PSTN, >>>>>>>> NISDN, etc), there is a variety of TDM-to-TDM connection types=20 >>>>>>>> behind the >>>>>>>> general "TDM hairpinning" capability (dependent on required=20 >>>>>>>> type of IWF, >>>>>>>> etc.) in corresponding H.248 MG types >>>>>>>> >>>>>>>> Note 2: H.248/MEGCOP perspective >>>>>>>> TDM Hairpinning =3D Single H.248 Context with 2 H.248 TDM=20 >>>>>>>> Terminations >>>>>>>> >>>>>>> >>>>>>> *****************************************************************= *******************=20 >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Based on this hairpinning understanding, my answers are: >>>>>>>> >>>>>>>> (1) Speech telephony service: G.711 companding formats are a=20 >>>>>>>> property of >>>>>>>> the corresponding H.248 TDM termination >>>>>>>> >>>>>>>> [Note: dependent on MG architecture and implementation,=20 >>>>>>>> property might be >>>>>>>> signalled or preprovisioned. Of course, G.711 companding law is = an >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> inherent >>>>>>> >>>>>>>> property of your DS0 channel at your PDH/SDH/SONET framer; the=20 >>>>>>>> way, how >>>>>>>> this DS0 property is associated with the corresponding H.248 TDM >>>>>>>> Termination property may only realized MG-internally for very=20 >>>>>>>> specific MG >>>>>>>> architectures. Generally it is up to the MGC, particularly if=20 >>>>>>>> some (or >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> all) >>>>>>> >>>>>>>> DS0's are ISDN B channels.] >>>>>>>> >>>>>>>> (2) Voiceband Data services: same as in (1) >>>>>>>> >>>>>>>> [Note: VBD according new ITU-T V.152 -> "... For purposes of >>>>>>>> interoperability, a V.152 compliant implementation shall=20 >>>>>>>> support at least >>>>>>>> both G.711 A-law and G.711 =C3=AC-law codecs as VBD codecs. "] >>>>>>>> >>>>>>>> (3) ISDN UDI =3D all ISDN Teleservices with ISDN I.231. bearer=20 >>>>>>>> service >>>>>>>> requirement >>>>>>>> =3D> H.248 TDM Termination property must be signalled by MGC, if= =20 >>>>>>>> not, MG >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> may >>>>>>> >>>>>>>> not guarantee UDI capability (i.e., fully transparent 64-kbit/s=20 >>>>>>>> bearer >>>>>>>> channel) in TDM hairpinning scenarios ... >>>>>>>> >>>>>>>> >>>>>>>> Conclusion: >>>>>>>> IF your MG is supporting >>>>>>>> PSTN lines (=3D H.248 ALN Termination), >>>>>>>> PSTN trunks (=3D H.248 TDM Termination), and >>>>>>>> ISDN B channels (=3D H.248 TDM Termination) >>>>>>>> >>>>>>>> AND IF you've such services and interworking requirements >>>>>>>> >>>>>>>> THEN you should generally signal the corresponding properties ... >>>>>>>> >>>>>>>> ... in case of >>>>>>>> TDM hairpinning, >>>>>>>> ALN hairpinning, or >>>>>>>> ALN-to-TDM connection types. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Albrecht >>>>>>>> >>>>>>>> ALCATEL >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>>> Zhao Bo >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> To: =20 >>>>>>>> megaco@ietf.org >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Sent by: cc: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> megaco-admin@iet Subject: [Megaco]=20 >>>>>>>> Hairpin >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> case A/u Law conversion >>>>>>> >>>>>>>> f.org >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> 25.02.2004 08:11 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> In this case, the A/u law format of a TDM ciruit can be=20 >>>>>>>> provisioned, but >>>>>>>> the MG doesn't know the service type of a call, thus >>>>>>>> has no way to know if a conversion is needed. For speech service >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> conversion >>>>>>> >>>>>>>> may be needed; for data service like isdn UDI, conversion is not >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> permitted. >>>>>>> >>>>>>>> Is there any method to solve this problem? >>>>>>>> >>>>>>>> Zhao Bo >>>>>>>> >>>>>>>> ****************************************************************= * >>>>>>>> This e-mail and its attachments contain confidential=20 >>>>>>>> information from >>>>>>>> HUAWEI, which is intended only for the person or entity whose=20 >>>>>>>> address is >>>>>>>> listed above. Any use of the information contained herein in=20 >>>>>>>> any way >>>>>>>> (including, but not limited to, total or partial disclosure, >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> reproduction, >>>>>>> >>>>>>>> or dissemination) by persons other than the intended=20 >>>>>>>> recipient(s) is >>>>>>>> prohibited. If you receive this e-mail in error, please notify=20 >>>>>>>> the sender >>>>>>>> by phone or email immediately and delete it! >>>>>>>> ****************************************************************= * >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Megaco mailing list >>>>>>>> Megaco@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/megaco >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Megaco mailing list >>>>>>>> Megaco@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/megaco >>>>>>>> 1=C3=A8=1Ar=E2=80=B0=C5=A1=C5=A0X=C2=A7=E2=80=9AX=C2=AC=C2=B4=C3= =87 i=C3=8A"z=C3=97=C3=A8=C2=AE=08m=C2=B6=E2=80=BA?=C3=BF=0C0=C3=96'=C2=AD= ~=C5=A0=C3=A0=C3=BEf=C2=A2=E2=80=93f=C2=A7=C3=BEX=C2=AC=C2=B6)=C3=9F=C2=A3= =C3=B9=C5=BE=EF=A2=9D=C2=A7( >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Megaco mailing list >>>>>> Megaco@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/megaco >>>>>> >>>>> >>>>> >>>>> This communication is confidential and intended solely for the=20 >>>>> addressee(s). Any unauthorized review, use, disclosure or=20 >>>>> distribution is prohibited. If you believe this message has been=20 >>>>> sent to you in error, please notify the sender by replying to this=20 >>>>> transmission and delete the message without disclosing it. Thank yo= u. >>>>> >>>>> E-mail including attachments is susceptible to data corruption,=20 >>>>> interruption, unauthorized amendment, tampering and viruses, and=20 >>>>> we only send and receive e-mails on the basis that we are not=20 >>>>> liable for any such corruption, interception, amendment, tampering=20 >>>>> or viruses or any consequences thereof. >>>>> >>>>> >>>>> _______________________________________________ >>>>> Megaco mailing list >>>>> Megaco@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/megaco >>>>> >>>> >>> >>> >> > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Apr 28 11:41:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22487 for ; Wed, 28 Apr 2004 11:41:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIqmY-0007gL-EY; Wed, 28 Apr 2004 11:15:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIqQR-0004yw-Hb for megaco@optimus.ietf.org; Wed, 28 Apr 2004 10:52:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19836 for ; Wed, 28 Apr 2004 10:52:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIqQ1-00040c-Kc for megaco@ietf.org; Wed, 28 Apr 2004 10:52:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIqP6-0003xU-00 for megaco@ietf.org; Wed, 28 Apr 2004 10:51:17 -0400 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1BIqOG-0003ri-00 for megaco@ietf.org; Wed, 28 Apr 2004 10:50:24 -0400 Received: from wink.ho.lucent.com (h135-112-126-3.lucent.com [135.112.126.3]) by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3SEnnn03526 for ; Wed, 28 Apr 2004 09:49:50 -0500 (CDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id KAA23159; Wed, 28 Apr 2004 10:49:48 -0400 (EDT) Cc: Carsten Waitzmann , Tom Taylor , Albrecht.Schwarz@alcatel.de, Zhao Bo , megaco@ietf.org Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id KAA23135; Wed, 28 Apr 2004 10:49:45 -0400 (EDT) Message-ID: <408FC501.9040407@bell-labs.com> Date: Wed, 28 Apr 2004 10:51:45 -0400 From: Troy Cauble User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Groves Original-CC: Carsten Waitzmann , Tom Taylor , Albrecht.Schwarz@alcatel.de, Zhao Bo , megaco@ietf.org Subject: Re: Signaling of UDI rsp Clearmode Bearer Service; Re: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversion References: <403E1760.2010903@nortelnetworks.com> <40427B92.3000707@ericsson.com> <406C2424.7050708@alcatel.de> <40720E2A.6070903@ericsson.com> <408D053E.2080405@alcatel.de> <408E24FA.2070303@ericsson.com> In-Reply-To: <408E24FA.2070303@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by hoemail2.firewall.lucent.com id i3SEnnn03526 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Christian, The text name for Annex C is not missing. Annex C is *EXPLICITLY* for=20 the binary encoding only. "The protocol syntax for the binary format of the protocol is defined in Annex A. Annex C specifies the encoding of the Local and Remote descriptors for use with the binary format. A complete ABNF of the text encoding of the protocol per RFC 2234 is given in Annex B. SDP is used as the encoding of the =09 Local and Remote descriptors for use with the text encoding as modified in 7.1.8." H.248.15 is designed to allow Packages to add parameters to the text=20 encoding of the Local and Remote descriptors. Annex C is not a Package. Isn't the real solution here to make a proper Package that handles TMR=20 and related parameters for both text and binary encoding??? This mod would allow recursion in both encodings: a=3Dh248:AnxC/SDP_A=3Dh248:AnxC/SDP_A=3Dh248:AnxC/SDP_A=3D...... Now I'm going to go too far and really alienate people: On an as needed basis, portions of Annex C should be deprecated and=20 replaced with proper packages. The package writers could even tell us=20 which descriptors to use the parameters in, something Annex C never did. -troy Christian Groves wrote: > Hello Carsten, >=20 > Seems you have a very good point. The text name for Annex C is missing. > I propose using "AnxC". Or is there another suggestion? >=20 > I will put this in a contribution for the upcoming ITU SG16 meeting. >=20 > Regards, Christian >=20 > Carsten Waitzmann wrote: >=20 >> Hello Christian, >> >> thanks for the information. I am still missing one piece: >> >> In case of textual encoding, what should be used for=20 >> the media stream properties described in H.248.1 Annex C? >> >> a=3Dh248item:/TMR =3D 40 >> >> thanks. >> Carsten >> >> Christian Groves wrote: >> >>> Hello Carsten, >>> >>> Yes this is what I had in mind. The package ID for Annex C is 0. >>> >>> ie. H.248.1 Annex A >>> PkgdName ::=3D OCTET STRING(SIZE(4)) >>> -- represents Package Name (2 octets) plus Property, Event, >>> -- Signal Names or Statistics ID. (2 octets) >>> -- To wildcard a package use 0xFFFF for first two octets, choose >>> -- is not allowed. To reference native property tag specified in >>> -- Annex C, use 0x0000 as first two octets. >>> >>> Regards, Christian >>> >>> Carsten Waitzmann wrote: >>> >>>> Hello Christian, >>>> >>>> I took your suggestion as a basis for the following example: >>>> >>>> MGC -> MG: >>>> MEGACO / 1 [1.2.3.4] >>>> Transaction =3D 100 { >>>> Context =3D $ { Add =3D TDM1 { >>>> Media { >>>> LocalControl {Mode =3D=20 >>>> SendReceive}, >>>> Local {a=3Dh248item:TMR= =3D=20 >>>> 0000 0010}} >>>> }}} >>>> >>>> MG -> MGC >>>> MEGACO / 1 [1.2.3.5] >>>> Reply =3D 100 { >>>> Context =3D 1 { >>>> Add =3D TDM1 { >>>> Media { >>>> Local {a=3Dh248item:T= MR=20 >>>> =3D 00000010} >>>> }}}} >>>> >>>> Is this usage in line to what you have in mind? >>>> H.248.15 specifies: a=3Dh248item:/ =3D=20 >>>> . For H.248.1 C.9 I do not know which package applies to=20 >>>> property TMR. But H.248.15 states "To enable the carriage of package= =20 >>>> defined properties in the local and remote descriptors of the text=20 >>>> encoded H.248.1 protocol the Package attribute shall be used" thus I= =20 >>>> am wondering whether a package name isn't mandatory? >>>> >>>> Thanks a lot! >>>> >>>> Carsten >>>> >>>> Alcatel >>>> >>>> Christian Groves wrote: >>>> >>>>> Hello Tom and Albrecht, >>>>> >>>>> What peice of information do you want to signal explicitely?=20 >>>>> Doesn't TMR allow you to specify 64Kbit UDI? If so then its=20 >>>>> supported by H.248.1 Annex C.9. For H.248 text users this (or any=20 >>>>> element in Annex C) can be tranferred via H.248.15. Alternatively=20 >>>>> Q.1950 sect 5.7.1.2 specifies an equivalent encoding. >>>>> >>>>> Regards, Christian >>>>> >>>>> Tom Taylor wrote: >>>>> >>>>>> I intended a reference to draft-ietf-avt-rtp-clearmode-04.txt in=20 >>>>>> my intervention. My old draft has been allowed to expire because=20 >>>>>> it did not seem to be of much interest to the community. >>>>>> >>>>>> You are right: the draft just referred to doesn't apply to TDM,=20 >>>>>> only to the packet side. I wasn't thinking. I agree that in the=20 >>>>>> absence of the attributes provided in my old draft, TDM bearer=20 >>>>>> characteristics are assumed rather than signalled explicitly. >>>>>> >>>>>> Albrecht.Schwarz@alcatel.de wrote: >>>>>> >>>>>>> I think that the question is, whether this specific TDM bearer=20 >>>>>>> capability >>>>>>> should be (1) explicitly signalled, or whether (2) implicit=20 >>>>>>> assumption is >>>>>>> already sufficient. >>>>>>> >>>>>>> With regard to (1), Tom, I guess that your refer to >>>>>>> >>>>>>> * RTP/CLEARMODE >>>>>>> RTP payload format for a 64 kbit/s transparent call >>>>>>> =20 >>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-clearmode-= 04.txt=20 >>>>>>> >>>>>>> >>>>>>> But, this coming RFC may not be directly applied, e.g.,=20 >>>>>>> packetization time >>>>>>> parameter isn't applicable IMHO. Pls correct me if wrong. >>>>>>> >>>>>>> Or do you refer to your proposals in your expired draft wrt >>>>>>> * TDM/CLEARMODE >>>>>>> Conventions for the use of the Session Description Protocol (SD= P) >>>>>>> for Digital Circuit Connections >>>>>>> =20 >>>>>>> http://www.watersprings.org/pub/id/draft-taylor-mmusic-sdp-tdm-01= .txt=20 >>>>>>> >>>>>>> >>>>>>> My conclusion is, that an explicit signalling method doesn't=20 >>>>>>> exist today >>>>>>> ("exception might be Q.1950"). >>>>>>> Even though, an explicit TDM Media Descriptor for I.231.1 might=20 >>>>>>> be helpful >>>>>>> for unambigously specification in certain MG implementations. >>>>>>> >>>>>>> >>>>>>> With regard to (2): >>>>>>> Implicit signaling is in my understanding the situation of today.= =20 >>>>>>> In case >>>>>>> of, (a) missing TDM Media Descriptors, or (b) "identical TDM Medi= a >>>>>>> Descriptors with transparent channel indications", when a=20 >>>>>>> transparent >>>>>>> 64-kbit/s bearer connection may be established. >>>>>>> Sometimes this is also called "native TDM switching", or "native = TDM >>>>>>> hairpinning", but technically it is exactly representing an ISDN=20 >>>>>>> B channel >>>>>>> with I.231.1 bearer service. [=3D> the channel may bypass the DSP= ,=20 >>>>>>> but in >>>>>>> case that a DSP is looped-in, then must be the DSP channel=20 >>>>>>> operation mode >>>>>>> configured for 'Clearmode'] >>>>>>> >>>>>>> Last comment: >>>>>>> Such kind of implicit signalling mechanism is often assumed in te= lco >>>>>>> industry, because this is the legacy signaling mechanism within a= =20 >>>>>>> TDM >>>>>>> switch ("if there aren't any signaled bearer capabilities then=20 >>>>>>> transparent >>>>>>> channel; any needed bearer capability in addition must be explici= tly >>>>>>> signalled, like signal processing network equipment functions,=20 >>>>>>> e.g., EC"). >>>>>>> >>>>>>> TDM hairpinning means, an "H.248-controlled TDM switching=20 >>>>>>> function" from >>>>>>> H.248 Media Gateway perspective. Hence, this implicit signalling=20 >>>>>>> assumption >>>>>>> may be still valid, or do you see any needs for explicit signalin= g >>>>>>> codepoints in case of TDM-to-TDM ISDN I.231.1 calls? >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Albrecht >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> = = =20 >>>>>>> Tom=20 >>>>>>> Taylor = =20 >>>>>>> >>>>>> = =20 >>>>>>> tworks.com> cc: Albrecht=20 >>>>>>> SCHWARZ/DE/ALCATEL@ALCATEL,=20 >>>>>>> megaco@ietf.org =20 >>>>>>> Subject: Re: TDM=20 >>>>>>> Hairpinning; Re: [Megaco] Hairpin case A/u Law=20 >>>>>>> conversion =20 >>>>>>> 26.02.2004=20 >>>>>>> 14:05 = =20 >>>>>>> = = =20 >>>>>>> = = =20 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I think you would do it by specifying the CLEARMODE codec in the=20 >>>>>>> Local and >>>>>>> Remote >>>>>>> descriptors. Unfortunately, CLEARMODE is still under=20 >>>>>>> consideration by the >>>>>>> IESG >>>>>>> and hasn't reached RFC status. >>>>>>> >>>>>>> Zhao Bo wrote: >>>>>>> >>>>>>>> Dear Albrecht: >>>>>>>> Is there any H.248 package defined to signal the UDI=20 >>>>>>>> transparency >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> properties in TDM hairping case? >>>>>>> >>>>>>>> Best regards >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>> From: >>>>>>>> To: "Zhao Bo" >>>>>>>> Cc: ; >>>>>>>> Sent: Wednesday, February 25, 2004 10:24 PM >>>>>>>> Subject: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law=20 >>>>>>>> conversion >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Dear Zhao Bo, >>>>>>>> >>>>>>>> because there isn't any "hairpinning" definition in MEGACOP/H.24= 8 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> standards >>>>>>> >>>>>>>> ("please correct if I'm wrong"), I'd like to use the following=20 >>>>>>>> one for >>>>>>>> responding your questions: >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> *****************************************************************= ******************=20 >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Definition: >>>>>>>> TDM Hairpinning >>>>>>>> ? is a scenario whereby a call is being made between two TDM=20 >>>>>>>> endpoints on >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> a >>>>>>> >>>>>>>> single media gateway. The media comes in on one TDM channel=20 >>>>>>>> and goes >>>>>>>> out on another TDM channel through the use of an internal=20 >>>>>>>> loop in the >>>>>>>> media gateway. >>>>>>>> >>>>>>>> Note 1: due to the fact that there are local call types at local >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> exchanges >>>>>>> >>>>>>>> (CLASS5), and transit exchanges (CLASS4) in legacy TDM networks=20 >>>>>>>> (PSTN, >>>>>>>> NISDN, etc), there is a variety of TDM-to-TDM connection types=20 >>>>>>>> behind the >>>>>>>> general "TDM hairpinning" capability (dependent on required type= =20 >>>>>>>> of IWF, >>>>>>>> etc.) in corresponding H.248 MG types >>>>>>>> >>>>>>>> Note 2: H.248/MEGCOP perspective >>>>>>>> TDM Hairpinning =3D Single H.248 Context with 2 H.248 TDM=20 >>>>>>>> Terminations >>>>>>>> >>>>>>> >>>>>>> *****************************************************************= *******************=20 >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Based on this hairpinning understanding, my answers are: >>>>>>>> >>>>>>>> (1) Speech telephony service: G.711 companding formats are a=20 >>>>>>>> property of >>>>>>>> the corresponding H.248 TDM termination >>>>>>>> >>>>>>>> [Note: dependent on MG architecture and implementation, property= =20 >>>>>>>> might be >>>>>>>> signalled or preprovisioned. Of course, G.711 companding law is = an >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> inherent >>>>>>> >>>>>>>> property of your DS0 channel at your PDH/SDH/SONET framer; the=20 >>>>>>>> way, how >>>>>>>> this DS0 property is associated with the corresponding H.248 TDM >>>>>>>> Termination property may only realized MG-internally for very=20 >>>>>>>> specific MG >>>>>>>> architectures. Generally it is up to the MGC, particularly if=20 >>>>>>>> some (or >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> all) >>>>>>> >>>>>>>> DS0's are ISDN B channels.] >>>>>>>> >>>>>>>> (2) Voiceband Data services: same as in (1) >>>>>>>> >>>>>>>> [Note: VBD according new ITU-T V.152 -> "... For purposes of >>>>>>>> interoperability, a V.152 compliant implementation shall support= =20 >>>>>>>> at least >>>>>>>> both G.711 A-law and G.711 =C3=AC-law codecs as VBD codecs. "] >>>>>>>> >>>>>>>> (3) ISDN UDI =3D all ISDN Teleservices with ISDN I.231. bearer=20 >>>>>>>> service >>>>>>>> requirement >>>>>>>> =3D> H.248 TDM Termination property must be signalled by MGC, if= =20 >>>>>>>> not, MG >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> may >>>>>>> >>>>>>>> not guarantee UDI capability (i.e., fully transparent 64-kbit/s=20 >>>>>>>> bearer >>>>>>>> channel) in TDM hairpinning scenarios ... >>>>>>>> >>>>>>>> >>>>>>>> Conclusion: >>>>>>>> IF your MG is supporting >>>>>>>> PSTN lines (=3D H.248 ALN Termination), >>>>>>>> PSTN trunks (=3D H.248 TDM Termination), and >>>>>>>> ISDN B channels (=3D H.248 TDM Termination) >>>>>>>> >>>>>>>> AND IF you've such services and interworking requirements >>>>>>>> >>>>>>>> THEN you should generally signal the corresponding properties ... >>>>>>>> >>>>>>>> ... in case of >>>>>>>> TDM hairpinning, >>>>>>>> ALN hairpinning, or >>>>>>>> ALN-to-TDM connection types. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Albrecht >>>>>>>> >>>>>>>> ALCATEL >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>>> Zhao Bo >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> To: =20 >>>>>>>> megaco@ietf.org >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Sent by: cc: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> megaco-admin@iet Subject: [Megaco]=20 >>>>>>>> Hairpin >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> case A/u Law conversion >>>>>>> >>>>>>>> f.org >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> 25.02.2004 08:11 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> In this case, the A/u law format of a TDM ciruit can be=20 >>>>>>>> provisioned, but >>>>>>>> the MG doesn't know the service type of a call, thus >>>>>>>> has no way to know if a conversion is needed. For speech service >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> conversion >>>>>>> >>>>>>>> may be needed; for data service like isdn UDI, conversion is not >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> permitted. >>>>>>> >>>>>>>> Is there any method to solve this problem? >>>>>>>> >>>>>>>> Zhao Bo >>>>>>>> >>>>>>>> ****************************************************************= * >>>>>>>> This e-mail and its attachments contain confidential information= =20 >>>>>>>> from >>>>>>>> HUAWEI, which is intended only for the person or entity whose=20 >>>>>>>> address is >>>>>>>> listed above. Any use of the information contained herein in any= =20 >>>>>>>> way >>>>>>>> (including, but not limited to, total or partial disclosure, >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> reproduction, >>>>>>> >>>>>>>> or dissemination) by persons other than the intended=20 >>>>>>>> recipient(s) is >>>>>>>> prohibited. If you receive this e-mail in error, please notify=20 >>>>>>>> the sender >>>>>>>> by phone or email immediately and delete it! >>>>>>>> ****************************************************************= * >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Megaco mailing list >>>>>>>> Megaco@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/megaco >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Megaco mailing list >>>>>>>> Megaco@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/megaco >>>>>>>> 1=C3=A8=1Ar=E2=80=B0=C5=A1=C5=A0X=C2=A7=E2=80=9AX=C2=AC=C2=B4=C3= =87 i=C3=8A"z=C3=97=C3=A8=C2=AE=08m=C2=B6=E2=80=BA?=C3=BF=0C0=C3=96'=C2=AD= ~=C5=A0=C3=A0=C3=BEf=C2=A2=E2=80=93f=C2=A7=C3=BEX=C2=AC=C2=B6)=C3=9F=C2=A3= =C3=B9=C5=BE=EF=A2=9D=C2=A7( >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Megaco mailing list >>>>>> Megaco@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/megaco >>>>>> >>>>> >>>>> >>>>> This communication is confidential and intended solely for the=20 >>>>> addressee(s). Any unauthorized review, use, disclosure or=20 >>>>> distribution is prohibited. If you believe this message has been=20 >>>>> sent to you in error, please notify the sender by replying to this=20 >>>>> transmission and delete the message without disclosing it. Thank yo= u. >>>>> >>>>> E-mail including attachments is susceptible to data corruption,=20 >>>>> interruption, unauthorized amendment, tampering and viruses, and we= =20 >>>>> only send and receive e-mails on the basis that we are not liable=20 >>>>> for any such corruption, interception, amendment, tampering or=20 >>>>> viruses or any consequences thereof. >>>>> >>>>> >>>>> _______________________________________________ >>>>> Megaco mailing list >>>>> Megaco@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/megaco >>>>> >>>> >>> >>> >> >=20 >=20 > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Apr 28 12:23:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25815 for ; Wed, 28 Apr 2004 12:23:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIrdA-0004so-I9 for megaco-archive@odin.ietf.org; Wed, 28 Apr 2004 12:09:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SG9qDk018766 for megaco-archive@odin.ietf.org; Wed, 28 Apr 2004 12:09:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIrRF-0001lq-Kg for megaco-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 11:57:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24003 for ; Wed, 28 Apr 2004 11:57:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIrRD-0002ON-2D for megaco-web-archive@ietf.org; Wed, 28 Apr 2004 11:57:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIrOu-0001t4-00 for megaco-web-archive@ietf.org; Wed, 28 Apr 2004 11:55:10 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIrMW-0001JL-01 for megaco-web-archive@ietf.org; Wed, 28 Apr 2004 11:52:40 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIrBb-0002SY-6K for megaco-web-archive@ietf.org; Wed, 28 Apr 2004 11:41:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIqmY-0007gL-EY; Wed, 28 Apr 2004 11:15:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIqQR-0004yw-Hb for megaco@optimus.ietf.org; Wed, 28 Apr 2004 10:52:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19836 for ; Wed, 28 Apr 2004 10:52:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIqQ1-00040c-Kc for megaco@ietf.org; Wed, 28 Apr 2004 10:52:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIqP6-0003xU-00 for megaco@ietf.org; Wed, 28 Apr 2004 10:51:17 -0400 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1BIqOG-0003ri-00 for megaco@ietf.org; Wed, 28 Apr 2004 10:50:24 -0400 Received: from wink.ho.lucent.com (h135-112-126-3.lucent.com [135.112.126.3]) by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3SEnnn03526 for ; Wed, 28 Apr 2004 09:49:50 -0500 (CDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id KAA23159; Wed, 28 Apr 2004 10:49:48 -0400 (EDT) Cc: Carsten Waitzmann , Tom Taylor , Albrecht.Schwarz@alcatel.de, Zhao Bo , megaco@ietf.org Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id KAA23135; Wed, 28 Apr 2004 10:49:45 -0400 (EDT) Message-ID: <408FC501.9040407@bell-labs.com> Date: Wed, 28 Apr 2004 10:51:45 -0400 From: Troy Cauble User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Groves Original-CC: Carsten Waitzmann , Tom Taylor , Albrecht.Schwarz@alcatel.de, Zhao Bo , megaco@ietf.org Subject: Re: Signaling of UDI rsp Clearmode Bearer Service; Re: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversion References: <403E1760.2010903@nortelnetworks.com> <40427B92.3000707@ericsson.com> <406C2424.7050708@alcatel.de> <40720E2A.6070903@ericsson.com> <408D053E.2080405@alcatel.de> <408E24FA.2070303@ericsson.com> In-Reply-To: <408E24FA.2070303@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by hoemail2.firewall.lucent.com id i3SEnnn03526 Content-Transfer-Encoding: quoted-printable Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Christian, The text name for Annex C is not missing. Annex C is *EXPLICITLY* for=20 the binary encoding only. "The protocol syntax for the binary format of the protocol is defined in Annex A. Annex C specifies the encoding of the Local and Remote descriptors for use with the binary format. A complete ABNF of the text encoding of the protocol per RFC 2234 is given in Annex B. SDP is used as the encoding of the =09 Local and Remote descriptors for use with the text encoding as modified in 7.1.8." H.248.15 is designed to allow Packages to add parameters to the text=20 encoding of the Local and Remote descriptors. Annex C is not a Package. Isn't the real solution here to make a proper Package that handles TMR=20 and related parameters for both text and binary encoding??? This mod would allow recursion in both encodings: a=3Dh248:AnxC/SDP_A=3Dh248:AnxC/SDP_A=3Dh248:AnxC/SDP_A=3D...... Now I'm going to go too far and really alienate people: On an as needed basis, portions of Annex C should be deprecated and=20 replaced with proper packages. The package writers could even tell us=20 which descriptors to use the parameters in, something Annex C never did. -troy Christian Groves wrote: > Hello Carsten, >=20 > Seems you have a very good point. The text name for Annex C is missing. > I propose using "AnxC". Or is there another suggestion? >=20 > I will put this in a contribution for the upcoming ITU SG16 meeting. >=20 > Regards, Christian >=20 > Carsten Waitzmann wrote: >=20 >> Hello Christian, >> >> thanks for the information. I am still missing one piece: >> >> In case of textual encoding, what should be used for=20 >> the media stream properties described in H.248.1 Annex C? >> >> a=3Dh248item:/TMR =3D 40 >> >> thanks. >> Carsten >> >> Christian Groves wrote: >> >>> Hello Carsten, >>> >>> Yes this is what I had in mind. The package ID for Annex C is 0. >>> >>> ie. H.248.1 Annex A >>> PkgdName ::=3D OCTET STRING(SIZE(4)) >>> -- represents Package Name (2 octets) plus Property, Event, >>> -- Signal Names or Statistics ID. (2 octets) >>> -- To wildcard a package use 0xFFFF for first two octets, choose >>> -- is not allowed. To reference native property tag specified in >>> -- Annex C, use 0x0000 as first two octets. >>> >>> Regards, Christian >>> >>> Carsten Waitzmann wrote: >>> >>>> Hello Christian, >>>> >>>> I took your suggestion as a basis for the following example: >>>> >>>> MGC -> MG: >>>> MEGACO / 1 [1.2.3.4] >>>> Transaction =3D 100 { >>>> Context =3D $ { Add =3D TDM1 { >>>> Media { >>>> LocalControl {Mode =3D=20 >>>> SendReceive}, >>>> Local {a=3Dh248item:TMR= =3D=20 >>>> 0000 0010}} >>>> }}} >>>> >>>> MG -> MGC >>>> MEGACO / 1 [1.2.3.5] >>>> Reply =3D 100 { >>>> Context =3D 1 { >>>> Add =3D TDM1 { >>>> Media { >>>> Local {a=3Dh248item:T= MR=20 >>>> =3D 00000010} >>>> }}}} >>>> >>>> Is this usage in line to what you have in mind? >>>> H.248.15 specifies: a=3Dh248item:/ =3D=20 >>>> . For H.248.1 C.9 I do not know which package applies to=20 >>>> property TMR. But H.248.15 states "To enable the carriage of package= =20 >>>> defined properties in the local and remote descriptors of the text=20 >>>> encoded H.248.1 protocol the Package attribute shall be used" thus I= =20 >>>> am wondering whether a package name isn't mandatory? >>>> >>>> Thanks a lot! >>>> >>>> Carsten >>>> >>>> Alcatel >>>> >>>> Christian Groves wrote: >>>> >>>>> Hello Tom and Albrecht, >>>>> >>>>> What peice of information do you want to signal explicitely?=20 >>>>> Doesn't TMR allow you to specify 64Kbit UDI? If so then its=20 >>>>> supported by H.248.1 Annex C.9. For H.248 text users this (or any=20 >>>>> element in Annex C) can be tranferred via H.248.15. Alternatively=20 >>>>> Q.1950 sect 5.7.1.2 specifies an equivalent encoding. >>>>> >>>>> Regards, Christian >>>>> >>>>> Tom Taylor wrote: >>>>> >>>>>> I intended a reference to draft-ietf-avt-rtp-clearmode-04.txt in=20 >>>>>> my intervention. My old draft has been allowed to expire because=20 >>>>>> it did not seem to be of much interest to the community. >>>>>> >>>>>> You are right: the draft just referred to doesn't apply to TDM,=20 >>>>>> only to the packet side. I wasn't thinking. I agree that in the=20 >>>>>> absence of the attributes provided in my old draft, TDM bearer=20 >>>>>> characteristics are assumed rather than signalled explicitly. >>>>>> >>>>>> Albrecht.Schwarz@alcatel.de wrote: >>>>>> >>>>>>> I think that the question is, whether this specific TDM bearer=20 >>>>>>> capability >>>>>>> should be (1) explicitly signalled, or whether (2) implicit=20 >>>>>>> assumption is >>>>>>> already sufficient. >>>>>>> >>>>>>> With regard to (1), Tom, I guess that your refer to >>>>>>> >>>>>>> * RTP/CLEARMODE >>>>>>> RTP payload format for a 64 kbit/s transparent call >>>>>>> =20 >>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-clearmode-= 04.txt=20 >>>>>>> >>>>>>> >>>>>>> But, this coming RFC may not be directly applied, e.g.,=20 >>>>>>> packetization time >>>>>>> parameter isn't applicable IMHO. Pls correct me if wrong. >>>>>>> >>>>>>> Or do you refer to your proposals in your expired draft wrt >>>>>>> * TDM/CLEARMODE >>>>>>> Conventions for the use of the Session Description Protocol (SD= P) >>>>>>> for Digital Circuit Connections >>>>>>> =20 >>>>>>> http://www.watersprings.org/pub/id/draft-taylor-mmusic-sdp-tdm-01= .txt=20 >>>>>>> >>>>>>> >>>>>>> My conclusion is, that an explicit signalling method doesn't=20 >>>>>>> exist today >>>>>>> ("exception might be Q.1950"). >>>>>>> Even though, an explicit TDM Media Descriptor for I.231.1 might=20 >>>>>>> be helpful >>>>>>> for unambigously specification in certain MG implementations. >>>>>>> >>>>>>> >>>>>>> With regard to (2): >>>>>>> Implicit signaling is in my understanding the situation of today.= =20 >>>>>>> In case >>>>>>> of, (a) missing TDM Media Descriptors, or (b) "identical TDM Medi= a >>>>>>> Descriptors with transparent channel indications", when a=20 >>>>>>> transparent >>>>>>> 64-kbit/s bearer connection may be established. >>>>>>> Sometimes this is also called "native TDM switching", or "native = TDM >>>>>>> hairpinning", but technically it is exactly representing an ISDN=20 >>>>>>> B channel >>>>>>> with I.231.1 bearer service. [=3D> the channel may bypass the DSP= ,=20 >>>>>>> but in >>>>>>> case that a DSP is looped-in, then must be the DSP channel=20 >>>>>>> operation mode >>>>>>> configured for 'Clearmode'] >>>>>>> >>>>>>> Last comment: >>>>>>> Such kind of implicit signalling mechanism is often assumed in te= lco >>>>>>> industry, because this is the legacy signaling mechanism within a= =20 >>>>>>> TDM >>>>>>> switch ("if there aren't any signaled bearer capabilities then=20 >>>>>>> transparent >>>>>>> channel; any needed bearer capability in addition must be explici= tly >>>>>>> signalled, like signal processing network equipment functions,=20 >>>>>>> e.g., EC"). >>>>>>> >>>>>>> TDM hairpinning means, an "H.248-controlled TDM switching=20 >>>>>>> function" from >>>>>>> H.248 Media Gateway perspective. Hence, this implicit signalling=20 >>>>>>> assumption >>>>>>> may be still valid, or do you see any needs for explicit signalin= g >>>>>>> codepoints in case of TDM-to-TDM ISDN I.231.1 calls? >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Albrecht >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> = = =20 >>>>>>> Tom=20 >>>>>>> Taylor = =20 >>>>>>> >>>>>> = =20 >>>>>>> tworks.com> cc: Albrecht=20 >>>>>>> SCHWARZ/DE/ALCATEL@ALCATEL,=20 >>>>>>> megaco@ietf.org =20 >>>>>>> Subject: Re: TDM=20 >>>>>>> Hairpinning; Re: [Megaco] Hairpin case A/u Law=20 >>>>>>> conversion =20 >>>>>>> 26.02.2004=20 >>>>>>> 14:05 = =20 >>>>>>> = = =20 >>>>>>> = = =20 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I think you would do it by specifying the CLEARMODE codec in the=20 >>>>>>> Local and >>>>>>> Remote >>>>>>> descriptors. Unfortunately, CLEARMODE is still under=20 >>>>>>> consideration by the >>>>>>> IESG >>>>>>> and hasn't reached RFC status. >>>>>>> >>>>>>> Zhao Bo wrote: >>>>>>> >>>>>>>> Dear Albrecht: >>>>>>>> Is there any H.248 package defined to signal the UDI=20 >>>>>>>> transparency >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> properties in TDM hairping case? >>>>>>> >>>>>>>> Best regards >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>> From: >>>>>>>> To: "Zhao Bo" >>>>>>>> Cc: ; >>>>>>>> Sent: Wednesday, February 25, 2004 10:24 PM >>>>>>>> Subject: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law=20 >>>>>>>> conversion >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Dear Zhao Bo, >>>>>>>> >>>>>>>> because there isn't any "hairpinning" definition in MEGACOP/H.24= 8 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> standards >>>>>>> >>>>>>>> ("please correct if I'm wrong"), I'd like to use the following=20 >>>>>>>> one for >>>>>>>> responding your questions: >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> *****************************************************************= ******************=20 >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Definition: >>>>>>>> TDM Hairpinning >>>>>>>> ? is a scenario whereby a call is being made between two TDM=20 >>>>>>>> endpoints on >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> a >>>>>>> >>>>>>>> single media gateway. The media comes in on one TDM channel=20 >>>>>>>> and goes >>>>>>>> out on another TDM channel through the use of an internal=20 >>>>>>>> loop in the >>>>>>>> media gateway. >>>>>>>> >>>>>>>> Note 1: due to the fact that there are local call types at local >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> exchanges >>>>>>> >>>>>>>> (CLASS5), and transit exchanges (CLASS4) in legacy TDM networks=20 >>>>>>>> (PSTN, >>>>>>>> NISDN, etc), there is a variety of TDM-to-TDM connection types=20 >>>>>>>> behind the >>>>>>>> general "TDM hairpinning" capability (dependent on required type= =20 >>>>>>>> of IWF, >>>>>>>> etc.) in corresponding H.248 MG types >>>>>>>> >>>>>>>> Note 2: H.248/MEGCOP perspective >>>>>>>> TDM Hairpinning =3D Single H.248 Context with 2 H.248 TDM=20 >>>>>>>> Terminations >>>>>>>> >>>>>>> >>>>>>> *****************************************************************= *******************=20 >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Based on this hairpinning understanding, my answers are: >>>>>>>> >>>>>>>> (1) Speech telephony service: G.711 companding formats are a=20 >>>>>>>> property of >>>>>>>> the corresponding H.248 TDM termination >>>>>>>> >>>>>>>> [Note: dependent on MG architecture and implementation, property= =20 >>>>>>>> might be >>>>>>>> signalled or preprovisioned. Of course, G.711 companding law is = an >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> inherent >>>>>>> >>>>>>>> property of your DS0 channel at your PDH/SDH/SONET framer; the=20 >>>>>>>> way, how >>>>>>>> this DS0 property is associated with the corresponding H.248 TDM >>>>>>>> Termination property may only realized MG-internally for very=20 >>>>>>>> specific MG >>>>>>>> architectures. Generally it is up to the MGC, particularly if=20 >>>>>>>> some (or >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> all) >>>>>>> >>>>>>>> DS0's are ISDN B channels.] >>>>>>>> >>>>>>>> (2) Voiceband Data services: same as in (1) >>>>>>>> >>>>>>>> [Note: VBD according new ITU-T V.152 -> "... For purposes of >>>>>>>> interoperability, a V.152 compliant implementation shall support= =20 >>>>>>>> at least >>>>>>>> both G.711 A-law and G.711 =C3=AC-law codecs as VBD codecs. "] >>>>>>>> >>>>>>>> (3) ISDN UDI =3D all ISDN Teleservices with ISDN I.231. bearer=20 >>>>>>>> service >>>>>>>> requirement >>>>>>>> =3D> H.248 TDM Termination property must be signalled by MGC, if= =20 >>>>>>>> not, MG >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> may >>>>>>> >>>>>>>> not guarantee UDI capability (i.e., fully transparent 64-kbit/s=20 >>>>>>>> bearer >>>>>>>> channel) in TDM hairpinning scenarios ... >>>>>>>> >>>>>>>> >>>>>>>> Conclusion: >>>>>>>> IF your MG is supporting >>>>>>>> PSTN lines (=3D H.248 ALN Termination), >>>>>>>> PSTN trunks (=3D H.248 TDM Termination), and >>>>>>>> ISDN B channels (=3D H.248 TDM Termination) >>>>>>>> >>>>>>>> AND IF you've such services and interworking requirements >>>>>>>> >>>>>>>> THEN you should generally signal the corresponding properties ... >>>>>>>> >>>>>>>> ... in case of >>>>>>>> TDM hairpinning, >>>>>>>> ALN hairpinning, or >>>>>>>> ALN-to-TDM connection types. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Albrecht >>>>>>>> >>>>>>>> ALCATEL >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>>> Zhao Bo >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> To: =20 >>>>>>>> megaco@ietf.org >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Sent by: cc: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> megaco-admin@iet Subject: [Megaco]=20 >>>>>>>> Hairpin >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> case A/u Law conversion >>>>>>> >>>>>>>> f.org >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> 25.02.2004 08:11 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> In this case, the A/u law format of a TDM ciruit can be=20 >>>>>>>> provisioned, but >>>>>>>> the MG doesn't know the service type of a call, thus >>>>>>>> has no way to know if a conversion is needed. For speech service >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> conversion >>>>>>> >>>>>>>> may be needed; for data service like isdn UDI, conversion is not >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> permitted. >>>>>>> >>>>>>>> Is there any method to solve this problem? >>>>>>>> >>>>>>>> Zhao Bo >>>>>>>> >>>>>>>> ****************************************************************= * >>>>>>>> This e-mail and its attachments contain confidential information= =20 >>>>>>>> from >>>>>>>> HUAWEI, which is intended only for the person or entity whose=20 >>>>>>>> address is >>>>>>>> listed above. Any use of the information contained herein in any= =20 >>>>>>>> way >>>>>>>> (including, but not limited to, total or partial disclosure, >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> reproduction, >>>>>>> >>>>>>>> or dissemination) by persons other than the intended=20 >>>>>>>> recipient(s) is >>>>>>>> prohibited. If you receive this e-mail in error, please notify=20 >>>>>>>> the sender >>>>>>>> by phone or email immediately and delete it! >>>>>>>> ****************************************************************= * >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Megaco mailing list >>>>>>>> Megaco@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/megaco >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Megaco mailing list >>>>>>>> Megaco@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/megaco >>>>>>>> 1=C3=A8=1Ar=E2=80=B0=C5=A1=C5=A0X=C2=A7=E2=80=9AX=C2=AC=C2=B4=C3= =87 i=C3=8A"z=C3=97=C3=A8=C2=AE=08m=C2=B6=E2=80=BA?=C3=BF=0C0=C3=96'=C2=AD= ~=C5=A0=C3=A0=C3=BEf=C2=A2=E2=80=93f=C2=A7=C3=BEX=C2=AC=C2=B6)=C3=9F=C2=A3= =C3=B9=C5=BE=EF=A2=9D=C2=A7( >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Megaco mailing list >>>>>> Megaco@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/megaco >>>>>> >>>>> >>>>> >>>>> This communication is confidential and intended solely for the=20 >>>>> addressee(s). Any unauthorized review, use, disclosure or=20 >>>>> distribution is prohibited. If you believe this message has been=20 >>>>> sent to you in error, please notify the sender by replying to this=20 >>>>> transmission and delete the message without disclosing it. Thank yo= u. >>>>> >>>>> E-mail including attachments is susceptible to data corruption,=20 >>>>> interruption, unauthorized amendment, tampering and viruses, and we= =20 >>>>> only send and receive e-mails on the basis that we are not liable=20 >>>>> for any such corruption, interception, amendment, tampering or=20 >>>>> viruses or any consequences thereof. >>>>> >>>>> >>>>> _______________________________________________ >>>>> Megaco mailing list >>>>> Megaco@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/megaco >>>>> >>>> >>> >>> >> >=20 >=20 > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Apr 28 13:46:37 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02831 for ; Wed, 28 Apr 2004 13:46:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsxc-0000ek-O6; Wed, 28 Apr 2004 13:35:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsqA-000785-7Z for megaco@optimus.ietf.org; Wed, 28 Apr 2004 13:27:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01041 for ; Wed, 28 Apr 2004 13:27:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIsq6-00017D-QC for megaco@ietf.org; Wed, 28 Apr 2004 13:27:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIspA-00011U-00 for megaco@ietf.org; Wed, 28 Apr 2004 13:26:20 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 1BIsoB-0000tS-00 for megaco@ietf.org; Wed, 28 Apr 2004 13:25:19 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id i3SHPIbP028389 for ; Wed, 28 Apr 2004 10:25:18 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id i3SHNl40000852 for ; Wed, 28 Apr 2004 12:23:59 -0500 Message-Id: <5.2.1.1.0.20040428130357.01e5ceb0@IL06EXM13.corp.mot.com> X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 28 Apr 2004 13:20:59 -0400 To: megaco@ietf.org From: Aleksandr Ryabin Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Megaco] Continuity tests Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi, There are several continuity test types (i.e 2-wire, 4-wire, etc) While provisioning of physical test parameters (i.e. frequencies, sequence, timeouts, etc) in MG makes sense, IMHO choosing a type of continuity test seem logical to be left to MGC. Basic Continuity Package (ct) does not allow to choose the type of a test. It implies that type of a test is provisioned on MG (per termination?) Is there another (extended) continuity test package which allows MGC to choose the type of a continuity test to be performed? If not, does anyone see a need to have such a package? Comments? Thanks Aleks _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Apr 28 14:10:07 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04713 for ; Wed, 28 Apr 2004 14:10:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItL1-0005uZ-CM for megaco-archive@odin.ietf.org; Wed, 28 Apr 2004 13:59:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SHxFkl022715 for megaco-archive@odin.ietf.org; Wed, 28 Apr 2004 13:59:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIt9v-0003Yk-Gf for megaco-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 13:47:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02939 for ; Wed, 28 Apr 2004 13:47:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIt9s-0002pd-2C for megaco-web-archive@ietf.org; Wed, 28 Apr 2004 13:47:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIt8z-0002km-00 for megaco-web-archive@ietf.org; Wed, 28 Apr 2004 13:46:50 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIt8I-0002fB-00 for megaco-web-archive@ietf.org; Wed, 28 Apr 2004 13:46:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsxc-0000ek-O6; Wed, 28 Apr 2004 13:35:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIsqA-000785-7Z for megaco@optimus.ietf.org; Wed, 28 Apr 2004 13:27:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01041 for ; Wed, 28 Apr 2004 13:27:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIsq6-00017D-QC for megaco@ietf.org; Wed, 28 Apr 2004 13:27:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIspA-00011U-00 for megaco@ietf.org; Wed, 28 Apr 2004 13:26:20 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 1BIsoB-0000tS-00 for megaco@ietf.org; Wed, 28 Apr 2004 13:25:19 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id i3SHPIbP028389 for ; Wed, 28 Apr 2004 10:25:18 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id i3SHNl40000852 for ; Wed, 28 Apr 2004 12:23:59 -0500 Message-Id: <5.2.1.1.0.20040428130357.01e5ceb0@IL06EXM13.corp.mot.com> X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 28 Apr 2004 13:20:59 -0400 To: megaco@ietf.org From: Aleksandr Ryabin Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Megaco] Continuity tests Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hi, There are several continuity test types (i.e 2-wire, 4-wire, etc) While provisioning of physical test parameters (i.e. frequencies, sequence, timeouts, etc) in MG makes sense, IMHO choosing a type of continuity test seem logical to be left to MGC. Basic Continuity Package (ct) does not allow to choose the type of a test. It implies that type of a test is provisioned on MG (per termination?) Is there another (extended) continuity test package which allows MGC to choose the type of a continuity test to be performed? If not, does anyone see a need to have such a package? Comments? Thanks Aleks _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Apr 28 14:40:57 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06576 for ; Wed, 28 Apr 2004 14:40:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItsg-0005CK-ME; Wed, 28 Apr 2004 14:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItpE-0004Na-IL for megaco@optimus.ietf.org; Wed, 28 Apr 2004 14:30:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05849 for ; Wed, 28 Apr 2004 14:30:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BItpA-0005TJ-KP for megaco@ietf.org; Wed, 28 Apr 2004 14:30:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BItoI-0005Qu-00 for megaco@ietf.org; Wed, 28 Apr 2004 14:29:30 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1BItnR-0005K1-00 for megaco@ietf.org; Wed, 28 Apr 2004 14:28:37 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3SIS4H01213; Wed, 28 Apr 2004 14:28:04 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JCT8MAZQ; Wed, 28 Apr 2004 14:28:03 -0400 Received: from nortelnetworks.com (abrw0049.ca.nortel.com [47.9.16.142]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JCVF1L1D; Wed, 28 Apr 2004 14:28:03 -0400 Message-ID: <408FF7B3.1070404@nortelnetworks.com> Date: Wed, 28 Apr 2004 14:28:03 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Troy Cauble CC: megaco@ietf.org Subject: Re: Signaling of UDI rsp Clearmode Bearer Service; Re: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversion References: <403E1760.2010903@nortelnetworks.com> <40427B92.3000707@ericsson.com> <406C2424.7050708@alcatel.de> <40720E2A.6070903@ericsson.com> <408D053E.2080405@alcatel.de> <408E24FA.2070303@ericsson.com> <408FC501.9040407@bell-labs.com> In-Reply-To: <408FC501.9040407@bell-labs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I was always of a similar opinion: that Annex C would gradually be eroded away through migration of the material to other packages. So: what would be the principle of the text packages: would they still capture the Q.x signalling as (hex-encoded) binary, or would we define enumerations where applicable? Troy Cauble wrote: > Christian, > > The text name for Annex C is not missing. Annex C is *EXPLICITLY* for > the binary encoding only. > > "The protocol syntax for the binary format of the protocol is > defined in Annex A. Annex C specifies the encoding of the Local > and Remote descriptors for use with the binary format. > > A complete ABNF of the text encoding of the protocol per RFC > 2234 is given in Annex B. SDP is used as the encoding of the > Local and Remote descriptors for use with the text encoding as > modified in 7.1.8." > > H.248.15 is designed to allow Packages to add parameters to the text > encoding of the Local and Remote descriptors. Annex C is not a Package. > > Isn't the real solution here to make a proper Package that handles TMR > and related parameters for both text and binary encoding??? > > > > This mod would allow recursion in both encodings: > > a=h248:AnxC/SDP_A=h248:AnxC/SDP_A=h248:AnxC/SDP_A=...... > > > Now I'm going to go too far and really alienate people: > > On an as needed basis, portions of Annex C should be deprecated and > replaced with proper packages. The package writers could even tell us > which descriptors to use the parameters in, something Annex C never did. > > > -troy > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Apr 28 14:47:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06860 for ; Wed, 28 Apr 2004 14:47:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItyV-0007BL-Qj; Wed, 28 Apr 2004 14:40:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIts7-00058z-EM for megaco@optimus.ietf.org; Wed, 28 Apr 2004 14:33:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05937 for ; Wed, 28 Apr 2004 14:33:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIts3-0005cL-He for megaco@ietf.org; Wed, 28 Apr 2004 14:33:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BItr5-0005ZA-00 for megaco@ietf.org; Wed, 28 Apr 2004 14:32:24 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1BItq8-0005U2-00 for megaco@ietf.org; Wed, 28 Apr 2004 14:31:24 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3SIUsH12197 for ; Wed, 28 Apr 2004 14:30:54 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Apr 2004 14:30:54 -0400 Message-ID: From: "Kevin Boyle" To: Aleksandr Ryabin , megaco@ietf.org Subject: RE: [Megaco] Continuity tests Date: Wed, 28 Apr 2004 14:30:51 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Is it possible to run more than one kind of continuity test on a particular circuit? If no, then the provisioning model holds and there is no need for a change. If yes, then we may need to add something to the package to allow selection of a ct test type. Kevin -----Original Message----- From: Aleksandr Ryabin [mailto:kengr@motorola.com] Sent: Wednesday, April 28, 2004 1:21 PM To: megaco@ietf.org Subject: [Megaco] Continuity tests Hi, There are several continuity test types (i.e 2-wire, 4-wire, etc) While provisioning of physical test parameters (i.e. frequencies, sequence, timeouts, etc) in MG makes sense, IMHO choosing a type of continuity test seem logical to be left to MGC. Basic Continuity Package (ct) does not allow to choose the type of a test. It implies that type of a test is provisioned on MG (per termination?) Is there another (extended) continuity test package which allows MGC to choose the type of a continuity test to be performed? If not, does anyone see a need to have such a package? Comments? Thanks Aleks _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Apr 28 14:58:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07592 for ; Wed, 28 Apr 2004 14:58:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIu89-0000I2-JK; Wed, 28 Apr 2004 14:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItyp-0007Ix-Ld for megaco@optimus.ietf.org; Wed, 28 Apr 2004 14:40:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06541 for ; Wed, 28 Apr 2004 14:40:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BItyl-00069O-Kk for megaco@ietf.org; Wed, 28 Apr 2004 14:40:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BItxo-000666-00 for megaco@ietf.org; Wed, 28 Apr 2004 14:39:21 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1BItwv-000618-00 for megaco@ietf.org; Wed, 28 Apr 2004 14:38:26 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3SIbtH04208 for ; Wed, 28 Apr 2004 14:37:55 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JCT8MBCW; Wed, 28 Apr 2004 14:37:55 -0400 Received: from nortelnetworks.com (abrw0049.ca.nortel.com [47.9.16.142]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JCVF1L13; Wed, 28 Apr 2004 14:37:55 -0400 Message-ID: <408FFA01.5080905@nortelnetworks.com> Date: Wed, 28 Apr 2004 14:37:53 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: megaco@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Megaco] Meaning of "support" for signals and events Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I'm at an MSF meeting at the moment, and discussion of a proposed Interoperability Agreement has added urgency to the question: what does it mean to "support" a signal or event in Megaco/H.248? This relates to the requirement to support all signals and events in a supported package. Would it be a fair statement of consensus to say that a Media Gateway supports an event or signal if it does not return an error and fail the rest of the transaction when the MGC identifies that event or signal in a descriptor? I actually see at least one requirement beyond that for signals that are in a supported package but not implemented physically for the specified termination. Suppose the signal completion event has been enabled for such a signal. Something should be reported, but what and when? Tom Taylor _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Apr 28 14:59:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07684 for ; Wed, 28 Apr 2004 14:59:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIuEi-0001tB-QR for megaco-archive@odin.ietf.org; Wed, 28 Apr 2004 14:56:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SIumqa007257 for megaco-archive@odin.ietf.org; Wed, 28 Apr 2004 14:56:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIu6f-00006S-LV for megaco-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 14:48:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06919 for ; Wed, 28 Apr 2004 14:48:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIu6b-0006cL-LZ for megaco-web-archive@ietf.org; Wed, 28 Apr 2004 14:48:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIu5e-0006Yu-00 for megaco-web-archive@ietf.org; Wed, 28 Apr 2004 14:47:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIu5Q-0006WA-00 for megaco-web-archive@ietf.org; Wed, 28 Apr 2004 14:47:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItyV-0007BL-Qj; Wed, 28 Apr 2004 14:40:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIts7-00058z-EM for megaco@optimus.ietf.org; Wed, 28 Apr 2004 14:33:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05937 for ; Wed, 28 Apr 2004 14:33:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIts3-0005cL-He for megaco@ietf.org; Wed, 28 Apr 2004 14:33:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BItr5-0005ZA-00 for megaco@ietf.org; Wed, 28 Apr 2004 14:32:24 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1BItq8-0005U2-00 for megaco@ietf.org; Wed, 28 Apr 2004 14:31:24 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3SIUsH12197 for ; Wed, 28 Apr 2004 14:30:54 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Apr 2004 14:30:54 -0400 Message-ID: From: "Kevin Boyle" To: Aleksandr Ryabin , megaco@ietf.org Subject: RE: [Megaco] Continuity tests Date: Wed, 28 Apr 2004 14:30:51 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Is it possible to run more than one kind of continuity test on a particular circuit? If no, then the provisioning model holds and there is no need for a change. If yes, then we may need to add something to the package to allow selection of a ct test type. Kevin -----Original Message----- From: Aleksandr Ryabin [mailto:kengr@motorola.com] Sent: Wednesday, April 28, 2004 1:21 PM To: megaco@ietf.org Subject: [Megaco] Continuity tests Hi, There are several continuity test types (i.e 2-wire, 4-wire, etc) While provisioning of physical test parameters (i.e. frequencies, sequence, timeouts, etc) in MG makes sense, IMHO choosing a type of continuity test seem logical to be left to MGC. Basic Continuity Package (ct) does not allow to choose the type of a test. It implies that type of a test is provisioned on MG (per termination?) Is there another (extended) continuity test package which allows MGC to choose the type of a continuity test to be performed? If not, does anyone see a need to have such a package? Comments? Thanks Aleks _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Apr 28 15:06:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08401 for ; Wed, 28 Apr 2004 15:06:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIuG8-0002IX-KK for megaco-archive@odin.ietf.org; Wed, 28 Apr 2004 14:58:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SIwGWp008826 for megaco-archive@odin.ietf.org; Wed, 28 Apr 2004 14:58:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIuAl-0000kd-Dc for megaco-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 14:52:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07223 for ; Wed, 28 Apr 2004 14:52:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIuAh-0006xf-FR for megaco-web-archive@ietf.org; Wed, 28 Apr 2004 14:52:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIu9j-0006pL-00 for megaco-web-archive@ietf.org; Wed, 28 Apr 2004 14:51:39 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIu99-0006kt-03 for megaco-web-archive@ietf.org; Wed, 28 Apr 2004 14:51:04 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BItyv-000629-WF for megaco-web-archive@ietf.org; Wed, 28 Apr 2004 14:40:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItsg-0005CK-ME; Wed, 28 Apr 2004 14:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItpE-0004Na-IL for megaco@optimus.ietf.org; Wed, 28 Apr 2004 14:30:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05849 for ; Wed, 28 Apr 2004 14:30:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BItpA-0005TJ-KP for megaco@ietf.org; Wed, 28 Apr 2004 14:30:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BItoI-0005Qu-00 for megaco@ietf.org; Wed, 28 Apr 2004 14:29:30 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1BItnR-0005K1-00 for megaco@ietf.org; Wed, 28 Apr 2004 14:28:37 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3SIS4H01213; Wed, 28 Apr 2004 14:28:04 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JCT8MAZQ; Wed, 28 Apr 2004 14:28:03 -0400 Received: from nortelnetworks.com (abrw0049.ca.nortel.com [47.9.16.142]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JCVF1L1D; Wed, 28 Apr 2004 14:28:03 -0400 Message-ID: <408FF7B3.1070404@nortelnetworks.com> Date: Wed, 28 Apr 2004 14:28:03 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Troy Cauble CC: megaco@ietf.org Subject: Re: Signaling of UDI rsp Clearmode Bearer Service; Re: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversion References: <403E1760.2010903@nortelnetworks.com> <40427B92.3000707@ericsson.com> <406C2424.7050708@alcatel.de> <40720E2A.6070903@ericsson.com> <408D053E.2080405@alcatel.de> <408E24FA.2070303@ericsson.com> <408FC501.9040407@bell-labs.com> In-Reply-To: <408FC501.9040407@bell-labs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I was always of a similar opinion: that Annex C would gradually be eroded away through migration of the material to other packages. So: what would be the principle of the text packages: would they still capture the Q.x signalling as (hex-encoded) binary, or would we define enumerations where applicable? Troy Cauble wrote: > Christian, > > The text name for Annex C is not missing. Annex C is *EXPLICITLY* for > the binary encoding only. > > "The protocol syntax for the binary format of the protocol is > defined in Annex A. Annex C specifies the encoding of the Local > and Remote descriptors for use with the binary format. > > A complete ABNF of the text encoding of the protocol per RFC > 2234 is given in Annex B. SDP is used as the encoding of the > Local and Remote descriptors for use with the text encoding as > modified in 7.1.8." > > H.248.15 is designed to allow Packages to add parameters to the text > encoding of the Local and Remote descriptors. Annex C is not a Package. > > Isn't the real solution here to make a proper Package that handles TMR > and related parameters for both text and binary encoding??? > > > > This mod would allow recursion in both encodings: > > a=h248:AnxC/SDP_A=h248:AnxC/SDP_A=h248:AnxC/SDP_A=...... > > > Now I'm going to go too far and really alienate people: > > On an as needed basis, portions of Annex C should be deprecated and > replaced with proper packages. The package writers could even tell us > which descriptors to use the parameters in, something Annex C never did. > > > -troy > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Apr 28 15:17:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09690 for ; Wed, 28 Apr 2004 15:17:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIuS5-0003kO-HT for megaco-archive@odin.ietf.org; Wed, 28 Apr 2004 15:10:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SJAbPO014397 for megaco-archive@odin.ietf.org; Wed, 28 Apr 2004 15:10:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIuHF-0002XH-5r for megaco-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 14:59:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07705 for ; Wed, 28 Apr 2004 14:59:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIuHB-0007bf-1B for megaco-web-archive@ietf.org; Wed, 28 Apr 2004 14:59:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIuGF-0007WZ-00 for megaco-web-archive@ietf.org; Wed, 28 Apr 2004 14:58:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIuFO-0007R1-00 for megaco-web-archive@ietf.org; Wed, 28 Apr 2004 14:57:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIu89-0000I2-JK; Wed, 28 Apr 2004 14:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItyp-0007Ix-Ld for megaco@optimus.ietf.org; Wed, 28 Apr 2004 14:40:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06541 for ; Wed, 28 Apr 2004 14:40:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BItyl-00069O-Kk for megaco@ietf.org; Wed, 28 Apr 2004 14:40:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BItxo-000666-00 for megaco@ietf.org; Wed, 28 Apr 2004 14:39:21 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1BItwv-000618-00 for megaco@ietf.org; Wed, 28 Apr 2004 14:38:26 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3SIbtH04208 for ; Wed, 28 Apr 2004 14:37:55 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JCT8MBCW; Wed, 28 Apr 2004 14:37:55 -0400 Received: from nortelnetworks.com (abrw0049.ca.nortel.com [47.9.16.142]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JCVF1L13; Wed, 28 Apr 2004 14:37:55 -0400 Message-ID: <408FFA01.5080905@nortelnetworks.com> Date: Wed, 28 Apr 2004 14:37:53 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: megaco@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Megaco] Meaning of "support" for signals and events Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I'm at an MSF meeting at the moment, and discussion of a proposed Interoperability Agreement has added urgency to the question: what does it mean to "support" a signal or event in Megaco/H.248? This relates to the requirement to support all signals and events in a supported package. Would it be a fair statement of consensus to say that a Media Gateway supports an event or signal if it does not return an error and fail the rest of the transaction when the MGC identifies that event or signal in a descriptor? I actually see at least one requirement beyond that for signals that are in a supported package but not implemented physically for the specified termination. Suppose the signal completion event has been enabled for such a signal. Something should be reported, but what and when? Tom Taylor _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Apr 28 15:20:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10008 for ; Wed, 28 Apr 2004 15:20:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIuSW-0003ye-68; Wed, 28 Apr 2004 15:11:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIuLO-0008HO-J7 for megaco@optimus.ietf.org; Wed, 28 Apr 2004 15:03:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07970 for ; Wed, 28 Apr 2004 15:03:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIuLK-0000AI-Ak for megaco@ietf.org; Wed, 28 Apr 2004 15:03:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIuKU-00006I-00 for megaco@ietf.org; Wed, 28 Apr 2004 15:02:46 -0400 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1BIuJu-0007nC-00 for megaco@ietf.org; Wed, 28 Apr 2004 15:02:11 -0400 Received: from wink.ho.lucent.com (h135-112-126-3.lucent.com [135.112.126.3]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3SJ1c121446 for ; Wed, 28 Apr 2004 14:01:38 -0500 (CDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id PAA24339; Wed, 28 Apr 2004 15:01:35 -0400 (EDT) Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id PAA24335; Wed, 28 Apr 2004 15:01:35 -0400 (EDT) Message-ID: <40900008.2050703@bell-labs.com> Date: Wed, 28 Apr 2004 15:03:36 -0400 From: Troy Cauble User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: megaco@ietf.org Subject: Re: Signaling of UDI rsp Clearmode Bearer Service; Re: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversion References: <403E1760.2010903@nortelnetworks.com> <40427B92.3000707@ericsson.com> <406C2424.7050708@alcatel.de> <40720E2A.6070903@ericsson.com> <408D053E.2080405@alcatel.de> <408E24FA.2070303@ericsson.com> <408FC501.9040407@bell-labs.com> <408FF7B3.1070404@nortelnetworks.com> In-Reply-To: <408FF7B3.1070404@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Minor nit: They wouldn't be "text packages". They'd just be packages. Packages inherently support both text and binary encoding. -troy Tom Taylor wrote: > I was always of a similar opinion: that Annex C would gradually be > eroded away through migration of the material to other packages. > > So: what would be the principle of the text packages: would they still > capture the Q.x signalling as (hex-encoded) binary, or would we define > enumerations where applicable? > > Troy Cauble wrote: > >> Christian, >> >> The text name for Annex C is not missing. Annex C is *EXPLICITLY* for >> the binary encoding only. >> >> "The protocol syntax for the binary format of the protocol is >> defined in Annex A. Annex C specifies the encoding of the Local >> and Remote descriptors for use with the binary format. >> >> A complete ABNF of the text encoding of the protocol per RFC >> 2234 is given in Annex B. SDP is used as the encoding of the >> Local and Remote descriptors for use with the text encoding as >> modified in 7.1.8." >> >> H.248.15 is designed to allow Packages to add parameters to the text >> encoding of the Local and Remote descriptors. Annex C is not a Package. >> >> Isn't the real solution here to make a proper Package that handles TMR >> and related parameters for both text and binary encoding??? >> >> >> >> This mod would allow recursion in both encodings: >> >> a=h248:AnxC/SDP_A=h248:AnxC/SDP_A=h248:AnxC/SDP_A=...... >> >> >> Now I'm going to go too far and really alienate people: >> >> On an as needed basis, portions of Annex C should be deprecated and >> replaced with proper packages. The package writers could even tell us >> which descriptors to use the parameters in, something Annex C never did. >> >> >> -troy >> >> _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Apr 28 15:38:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11603 for ; Wed, 28 Apr 2004 15:38:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIumU-0001vA-LA for megaco-archive@odin.ietf.org; Wed, 28 Apr 2004 15:31:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SJVg6U007385 for megaco-archive@odin.ietf.org; Wed, 28 Apr 2004 15:31:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIuce-0007dA-FG for megaco-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 15:21:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10150 for ; Wed, 28 Apr 2004 15:21:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIucb-0001I2-Tw for megaco-web-archive@ietf.org; Wed, 28 Apr 2004 15:21:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIubn-0001Ff-00 for megaco-web-archive@ietf.org; Wed, 28 Apr 2004 15:20:40 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIub1-0001Cn-00 for megaco-web-archive@ietf.org; Wed, 28 Apr 2004 15:19:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIuSW-0003ye-68; Wed, 28 Apr 2004 15:11:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIuLO-0008HO-J7 for megaco@optimus.ietf.org; Wed, 28 Apr 2004 15:03:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07970 for ; Wed, 28 Apr 2004 15:03:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIuLK-0000AI-Ak for megaco@ietf.org; Wed, 28 Apr 2004 15:03:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIuKU-00006I-00 for megaco@ietf.org; Wed, 28 Apr 2004 15:02:46 -0400 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1BIuJu-0007nC-00 for megaco@ietf.org; Wed, 28 Apr 2004 15:02:11 -0400 Received: from wink.ho.lucent.com (h135-112-126-3.lucent.com [135.112.126.3]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3SJ1c121446 for ; Wed, 28 Apr 2004 14:01:38 -0500 (CDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id PAA24339; Wed, 28 Apr 2004 15:01:35 -0400 (EDT) Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id PAA24335; Wed, 28 Apr 2004 15:01:35 -0400 (EDT) Message-ID: <40900008.2050703@bell-labs.com> Date: Wed, 28 Apr 2004 15:03:36 -0400 From: Troy Cauble User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: megaco@ietf.org Subject: Re: Signaling of UDI rsp Clearmode Bearer Service; Re: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversion References: <403E1760.2010903@nortelnetworks.com> <40427B92.3000707@ericsson.com> <406C2424.7050708@alcatel.de> <40720E2A.6070903@ericsson.com> <408D053E.2080405@alcatel.de> <408E24FA.2070303@ericsson.com> <408FC501.9040407@bell-labs.com> <408FF7B3.1070404@nortelnetworks.com> In-Reply-To: <408FF7B3.1070404@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Minor nit: They wouldn't be "text packages". They'd just be packages. Packages inherently support both text and binary encoding. -troy Tom Taylor wrote: > I was always of a similar opinion: that Annex C would gradually be > eroded away through migration of the material to other packages. > > So: what would be the principle of the text packages: would they still > capture the Q.x signalling as (hex-encoded) binary, or would we define > enumerations where applicable? > > Troy Cauble wrote: > >> Christian, >> >> The text name for Annex C is not missing. Annex C is *EXPLICITLY* for >> the binary encoding only. >> >> "The protocol syntax for the binary format of the protocol is >> defined in Annex A. Annex C specifies the encoding of the Local >> and Remote descriptors for use with the binary format. >> >> A complete ABNF of the text encoding of the protocol per RFC >> 2234 is given in Annex B. SDP is used as the encoding of the >> Local and Remote descriptors for use with the text encoding as >> modified in 7.1.8." >> >> H.248.15 is designed to allow Packages to add parameters to the text >> encoding of the Local and Remote descriptors. Annex C is not a Package. >> >> Isn't the real solution here to make a proper Package that handles TMR >> and related parameters for both text and binary encoding??? >> >> >> >> This mod would allow recursion in both encodings: >> >> a=h248:AnxC/SDP_A=h248:AnxC/SDP_A=h248:AnxC/SDP_A=...... >> >> >> Now I'm going to go too far and really alienate people: >> >> On an as needed basis, portions of Annex C should be deprecated and >> replaced with proper packages. The package writers could even tell us >> which descriptors to use the parameters in, something Annex C never did. >> >> >> -troy >> >> _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Apr 28 15:43:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11861 for ; Wed, 28 Apr 2004 15:43:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIuoj-0002qb-SO; Wed, 28 Apr 2004 15:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIufU-00005Y-0L for megaco@optimus.ietf.org; Wed, 28 Apr 2004 15:24:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10449 for ; Wed, 28 Apr 2004 15:24:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIufR-0001Rs-Bq for megaco@ietf.org; Wed, 28 Apr 2004 15:24:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIueb-0001QF-00 for megaco@ietf.org; Wed, 28 Apr 2004 15:23:34 -0400 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1BIudx-0001LP-00 for megaco@ietf.org; Wed, 28 Apr 2004 15:22:53 -0400 Received: from wink.ho.lucent.com (h135-112-126-3.lucent.com [135.112.126.3]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3SJMKB26957 for ; Wed, 28 Apr 2004 14:22:21 -0500 (CDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id PAA24557; Wed, 28 Apr 2004 15:22:17 -0400 (EDT) Cc: megaco@ietf.org Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id PAA24548; Wed, 28 Apr 2004 15:22:16 -0400 (EDT) Message-ID: <409004E2.60700@bell-labs.com> Date: Wed, 28 Apr 2004 15:24:18 -0400 From: Troy Cauble User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Taylor Original-CC: megaco@ietf.org Subject: Re: [Megaco] Meaning of "support" for signals and events References: <408FFA01.5080905@nortelnetworks.com> In-Reply-To: <408FFA01.5080905@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Tom Taylor wrote: > I'm at an MSF meeting at the moment, and discussion of a proposed > Interoperability Agreement has added urgency to the question: what does > it mean to "support" a signal or event in Megaco/H.248? This relates to > the requirement to support all signals and events in a supported package. > > Would it be a fair statement of consensus to say that a Media Gateway > supports an event or signal if it does not return an error and fail the > rest of the transaction when the MGC identifies that event or signal in > a descriptor? > > I actually see at least one requirement beyond that for signals that are > in a supported package but not implemented physically for the specified > termination. Suppose the signal completion event has been enabled for > such a signal. Something should be reported, but what and when? > > Tom Taylor There a discussion relatively recently that established that supporting a package didn't mean you had to support ALL of a packege. (I remember being pleasantly surprised and asking for a supporting IG entry.) Given that, what is the benefit of pretending to support a signal or event that you don't really implement? Wouldn't it be more "honest" to return the error? But assuming you have a reason ("Interoperability Agreement"?), it seems that a pretend signal completion event would be like any other pretend event. The MG wouldn't choke on the request; but it can't ever send the event because it's just pretending. Yeah, this could cause problems with an MGC's expectations, but that's true for any pretend event. I'm not sure it's possible to generalize the best pretend behavior. -troy _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Apr 28 17:26:33 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23543 for ; Wed, 28 Apr 2004 17:26:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwKH-0001t0-Ky for megaco-archive@odin.ietf.org; Wed, 28 Apr 2004 17:10:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SLAfpP007245 for megaco-archive@odin.ietf.org; Wed, 28 Apr 2004 17:10:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIuyr-000503-Oi for megaco-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 15:44:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11992 for ; Wed, 28 Apr 2004 15:44:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIuyp-0002RW-3W for megaco-web-archive@ietf.org; Wed, 28 Apr 2004 15:44:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIuxr-0002N2-00 for megaco-web-archive@ietf.org; Wed, 28 Apr 2004 15:43:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIuwx-0002JK-00 for megaco-web-archive@ietf.org; Wed, 28 Apr 2004 15:42:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIuoj-0002qb-SO; Wed, 28 Apr 2004 15:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIufU-00005Y-0L for megaco@optimus.ietf.org; Wed, 28 Apr 2004 15:24:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10449 for ; Wed, 28 Apr 2004 15:24:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIufR-0001Rs-Bq for megaco@ietf.org; Wed, 28 Apr 2004 15:24:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIueb-0001QF-00 for megaco@ietf.org; Wed, 28 Apr 2004 15:23:34 -0400 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1BIudx-0001LP-00 for megaco@ietf.org; Wed, 28 Apr 2004 15:22:53 -0400 Received: from wink.ho.lucent.com (h135-112-126-3.lucent.com [135.112.126.3]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3SJMKB26957 for ; Wed, 28 Apr 2004 14:22:21 -0500 (CDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id PAA24557; Wed, 28 Apr 2004 15:22:17 -0400 (EDT) Cc: megaco@ietf.org Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id PAA24548; Wed, 28 Apr 2004 15:22:16 -0400 (EDT) Message-ID: <409004E2.60700@bell-labs.com> Date: Wed, 28 Apr 2004 15:24:18 -0400 From: Troy Cauble User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Taylor Original-CC: megaco@ietf.org Subject: Re: [Megaco] Meaning of "support" for signals and events References: <408FFA01.5080905@nortelnetworks.com> In-Reply-To: <408FFA01.5080905@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Tom Taylor wrote: > I'm at an MSF meeting at the moment, and discussion of a proposed > Interoperability Agreement has added urgency to the question: what does > it mean to "support" a signal or event in Megaco/H.248? This relates to > the requirement to support all signals and events in a supported package. > > Would it be a fair statement of consensus to say that a Media Gateway > supports an event or signal if it does not return an error and fail the > rest of the transaction when the MGC identifies that event or signal in > a descriptor? > > I actually see at least one requirement beyond that for signals that are > in a supported package but not implemented physically for the specified > termination. Suppose the signal completion event has been enabled for > such a signal. Something should be reported, but what and when? > > Tom Taylor There a discussion relatively recently that established that supporting a package didn't mean you had to support ALL of a packege. (I remember being pleasantly surprised and asking for a supporting IG entry.) Given that, what is the benefit of pretending to support a signal or event that you don't really implement? Wouldn't it be more "honest" to return the error? But assuming you have a reason ("Interoperability Agreement"?), it seems that a pretend signal completion event would be like any other pretend event. The MG wouldn't choke on the request; but it can't ever send the event because it's just pretending. Yeah, this could cause problems with an MGC's expectations, but that's true for any pretend event. I'm not sure it's possible to generalize the best pretend behavior. -troy _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Apr 28 18:28:05 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29540 for ; Wed, 28 Apr 2004 18:28:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxKa-00040P-IR; Wed, 28 Apr 2004 18:15:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIx22-0008Iv-GE for megaco@optimus.ietf.org; Wed, 28 Apr 2004 17:55:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26377 for ; Wed, 28 Apr 2004 17:55:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIx1y-0003dA-JY for megaco@ietf.org; Wed, 28 Apr 2004 17:55:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIwzs-0003ET-00 for megaco@ietf.org; Wed, 28 Apr 2004 17:53:42 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIwxG-0002jp-00 for megaco@ietf.org; Wed, 28 Apr 2004 17:50:58 -0400 Received: from motgate.mot.com ([129.188.136.100]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIwhb-0001eR-TI for megaco@ietf.org; Wed, 28 Apr 2004 17:34:47 -0400 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (Motorola/Motgate) with ESMTP id i3SLYjWp020845; Wed, 28 Apr 2004 14:34:46 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i3SLYg03007817; Wed, 28 Apr 2004 16:34:43 -0500 Message-Id: <5.2.1.1.0.20040428135759.051e1498@IL06EXM13.corp.mot.com> X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 28 Apr 2004 14:11:44 -0400 To: "Kevin Boyle", From: Aleksandr Ryabin Subject: RE: [Megaco] Continuity tests In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1684050897==.ALT" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,DATE_IN_PAST_03_06, HTML_MESSAGE autolearn=no version=2.60 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --=====================_1684050897==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Yes, the type of test depends on what a circuit is connected to. But, I was actually coming from the view that MGC "controls" MG and as such only MGC should have knowledge on what test to execute (i.e. what is connected to the other side of a circuit). If this information is left in MG, then each circuit has to be provisioned with that information such that MG can make intelligent decision on what type of test to execute. Thus every time a circuit connection is changed, directly or indirectly, MG circuit needs to be re-provisioned. I think that configuration should be kept on MGC and the decision should come from MGC instead. Aleks At 02:30 PM 4/28/2004, Kevin Boyle wrote: >Is it possible to run more than one kind of continuity test on a >particular circuit? If no, then the provisioning model holds and there is >no need for a change. If yes, then we may need to add something to the >package to allow selection of a ct test type. > >Kevin > >-----Original Message----- >From: Aleksandr Ryabin [mailto:kengr@motorola.com] >Sent: Wednesday, April 28, 2004 1:21 PM >To: megaco@ietf.org >Subject: [Megaco] Continuity tests > >Hi, > >There are several continuity test types (i.e 2-wire, 4-wire, etc) While >provisioning of physical test parameters (i.e. frequencies, sequence, >timeouts, etc) in MG makes sense, IMHO choosing a type of continuity test >seem logical to be left to MGC. > >Basic Continuity Package (ct) does not allow to choose the type of a test. >It implies that type of a test is provisioned on MG (per termination?) > >Is there another (extended) continuity test package which allows MGC to >choose the type of a continuity test to be performed? > >If not, does anyone see a need to have such a package? >Comments? > >Thanks > Aleks > >_______________________________________________ >Megaco mailing list >Megaco@ietf.org >https://www1.ietf.org/mailman/listinfo/megaco > --=====================_1684050897==.ALT Content-Type: text/html; charset="us-ascii" Yes, the type of test depends on what a circuit is connected to.

But, I was actually coming from the view that MGC "controls" MG
and as such only MGC should have knowledge on what test to execute
(i.e. what is connected to the other side of a circuit).

If this information is left in MG, then each circuit has to be provisioned
with that information such that MG can make intelligent decision on what
type of test to execute. Thus every time a circuit connection is changed,
directly or indirectly, MG circuit needs to be re-provisioned.

I think that configuration should  be kept on MGC and the decision should
come from MGC instead.

        Aleks

At 02:30 PM 4/28/2004, Kevin Boyle wrote:

Is it possible to run more than one kind of continuity test on a particular circuit?  If no, then the provisioning model holds and there is no need for a change.  If yes, then we may need to add something to the package to allow selection of a ct test type.

Kevin

-----Original Message-----
From: Aleksandr Ryabin [mailto:kengr@motorola.com]
Sent: Wednesday, April 28, 2004 1:21 PM
To: megaco@ietf.org
Subject: [Megaco] Continuity tests

Hi,

There are several continuity test types (i.e 2-wire, 4-wire, etc) While provisioning of physical test parameters (i.e. frequencies, sequence, timeouts, etc) in MG makes sense, IMHO choosing a type of continuity test seem logical to be left to MGC.

Basic Continuity Package (ct) does not allow to choose the type of a test.
It implies that type of a test is provisioned on MG (per termination?)

Is there another (extended) continuity test package which allows MGC to choose the type of a continuity test to be performed?

If not, does anyone see a need to have such a package?
Comments?

Thanks
        Aleks

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
--=====================_1684050897==.ALT-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Apr 28 18:49:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00844 for ; Wed, 28 Apr 2004 18:49:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxdU-00042s-Nt for megaco-archive@odin.ietf.org; Wed, 28 Apr 2004 18:34:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SMYawg015550 for megaco-archive@odin.ietf.org; Wed, 28 Apr 2004 18:34:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxYe-0001M0-BU for megaco-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 18:29:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29665 for ; Wed, 28 Apr 2004 18:29:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIxYZ-0006K6-UC for megaco-web-archive@ietf.org; Wed, 28 Apr 2004 18:29:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIxXc-0006ES-00 for megaco-web-archive@ietf.org; Wed, 28 Apr 2004 18:28:33 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIxWh-000693-00 for megaco-web-archive@ietf.org; Wed, 28 Apr 2004 18:27:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIxKa-00040P-IR; Wed, 28 Apr 2004 18:15:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIx22-0008Iv-GE for megaco@optimus.ietf.org; Wed, 28 Apr 2004 17:55:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26377 for ; Wed, 28 Apr 2004 17:55:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIx1y-0003dA-JY for megaco@ietf.org; Wed, 28 Apr 2004 17:55:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIwzs-0003ET-00 for megaco@ietf.org; Wed, 28 Apr 2004 17:53:42 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BIwxG-0002jp-00 for megaco@ietf.org; Wed, 28 Apr 2004 17:50:58 -0400 Received: from motgate.mot.com ([129.188.136.100]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BIwhb-0001eR-TI for megaco@ietf.org; Wed, 28 Apr 2004 17:34:47 -0400 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (Motorola/Motgate) with ESMTP id i3SLYjWp020845; Wed, 28 Apr 2004 14:34:46 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i3SLYg03007817; Wed, 28 Apr 2004 16:34:43 -0500 Message-Id: <5.2.1.1.0.20040428135759.051e1498@IL06EXM13.corp.mot.com> X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 28 Apr 2004 14:11:44 -0400 To: "Kevin Boyle", From: Aleksandr Ryabin Subject: RE: [Megaco] Continuity tests In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1684050897==.ALT" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,DATE_IN_PAST_03_06, HTML_MESSAGE autolearn=no version=2.60 --=====================_1684050897==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Yes, the type of test depends on what a circuit is connected to. But, I was actually coming from the view that MGC "controls" MG and as such only MGC should have knowledge on what test to execute (i.e. what is connected to the other side of a circuit). If this information is left in MG, then each circuit has to be provisioned with that information such that MG can make intelligent decision on what type of test to execute. Thus every time a circuit connection is changed, directly or indirectly, MG circuit needs to be re-provisioned. I think that configuration should be kept on MGC and the decision should come from MGC instead. Aleks At 02:30 PM 4/28/2004, Kevin Boyle wrote: >Is it possible to run more than one kind of continuity test on a >particular circuit? If no, then the provisioning model holds and there is >no need for a change. If yes, then we may need to add something to the >package to allow selection of a ct test type. > >Kevin > >-----Original Message----- >From: Aleksandr Ryabin [mailto:kengr@motorola.com] >Sent: Wednesday, April 28, 2004 1:21 PM >To: megaco@ietf.org >Subject: [Megaco] Continuity tests > >Hi, > >There are several continuity test types (i.e 2-wire, 4-wire, etc) While >provisioning of physical test parameters (i.e. frequencies, sequence, >timeouts, etc) in MG makes sense, IMHO choosing a type of continuity test >seem logical to be left to MGC. > >Basic Continuity Package (ct) does not allow to choose the type of a test. >It implies that type of a test is provisioned on MG (per termination?) > >Is there another (extended) continuity test package which allows MGC to >choose the type of a continuity test to be performed? > >If not, does anyone see a need to have such a package? >Comments? > >Thanks > Aleks > >_______________________________________________ >Megaco mailing list >Megaco@ietf.org >https://www1.ietf.org/mailman/listinfo/megaco > --=====================_1684050897==.ALT Content-Type: text/html; charset="us-ascii" Yes, the type of test depends on what a circuit is connected to.

But, I was actually coming from the view that MGC "controls" MG
and as such only MGC should have knowledge on what test to execute
(i.e. what is connected to the other side of a circuit).

If this information is left in MG, then each circuit has to be provisioned
with that information such that MG can make intelligent decision on what
type of test to execute. Thus every time a circuit connection is changed,
directly or indirectly, MG circuit needs to be re-provisioned.

I think that configuration should  be kept on MGC and the decision should
come from MGC instead.

        Aleks

At 02:30 PM 4/28/2004, Kevin Boyle wrote:

Is it possible to run more than one kind of continuity test on a particular circuit?  If no, then the provisioning model holds and there is no need for a change.  If yes, then we may need to add something to the package to allow selection of a ct test type.

Kevin

-----Original Message-----
From: Aleksandr Ryabin [mailto:kengr@motorola.com]
Sent: Wednesday, April 28, 2004 1:21 PM
To: megaco@ietf.org
Subject: [Megaco] Continuity tests

Hi,

There are several continuity test types (i.e 2-wire, 4-wire, etc) While provisioning of physical test parameters (i.e. frequencies, sequence, timeouts, etc) in MG makes sense, IMHO choosing a type of continuity test seem logical to be left to MGC.

Basic Continuity Package (ct) does not allow to choose the type of a test.
It implies that type of a test is provisioned on MG (per termination?)

Is there another (extended) continuity test package which allows MGC to choose the type of a continuity test to be performed?

If not, does anyone see a need to have such a package?
Comments?

Thanks
        Aleks

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
--=====================_1684050897==.ALT-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Apr 28 19:23:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02848 for ; Wed, 28 Apr 2004 19:23:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIy90-0004tQ-JX; Wed, 28 Apr 2004 19:07:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIy1n-0002aO-CE for megaco@optimus.ietf.org; Wed, 28 Apr 2004 18:59:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01471 for ; Wed, 28 Apr 2004 18:59:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIy1i-0000pr-Rh for megaco@ietf.org; Wed, 28 Apr 2004 18:59:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIy0x-0000m0-00 for megaco@ietf.org; Wed, 28 Apr 2004 18:58:52 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BIy0D-0000gm-00 for megaco@ietf.org; Wed, 28 Apr 2004 18:58:05 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3SMw0Ah013263 for ; Thu, 29 Apr 2004 00:58:00 +0200 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 29 Apr 2004 00:58:00 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JWBDT1ZN; Thu, 29 Apr 2004 00:58:00 +0200 Received: from ericsson.com (sealwa04-221.sw.ericsson.se [130.100.249.221]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JRYYYVH2; Thu, 29 Apr 2004 08:57:48 +1000 Message-ID: <409036F7.60107@ericsson.com> Date: Thu, 29 Apr 2004 08:57:59 +1000 X-Sybari-Trust: dfe012d8 c38aee8b 08a16856 00000138 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Taylor CC: megaco@ietf.org Subject: Re: [Megaco] Meaning of "support" for signals and events References: <408FFA01.5080905@nortelnetworks.com> In-Reply-To: <408FFA01.5080905@nortelnetworks.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-OriginalArrivalTime: 28 Apr 2004 22:58:00.0619 (UTC) FILETIME=[412DBFB0:01C42D74] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by eagle.ericsson.se id i3SMw0Ah013263 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello Tom, I didn't realise the MSF was on at the moment... As Troy said we discussed this recently on the list and it was agreed to = add=20 something to the IG. Below is the text which I propose to clarify the issue: 6.2.3 Packages =85 To support a particular package the MG must support all properties, signa= ls,=20 events and statistics defined in a package. It must also support all Sign= al and=20 Event parameters. If the functionality behind these properties, signals, = events=20 and statistics is not implemented the MG shall not return a syntax error = or=20 unknown ID for any of these elements but should return response 501 =93No= t=20 implemented=94. The MG may support a subset of the values listed in a pac= kage for=20 a particular Property or Parameter. Regards, Christian Tom Taylor wrote: > I'm at an MSF meeting at the moment, and discussion of a proposed=20 > Interoperability Agreement has added urgency to the question: what does= =20 > it mean to "support" a signal or event in Megaco/H.248? This relates t= o=20 > the requirement to support all signals and events in a supported packag= e. >=20 > Would it be a fair statement of consensus to say that a Media Gateway=20 > supports an event or signal if it does not return an error and fail the= =20 > rest of the transaction when the MGC identifies that event or signal in= =20 > a descriptor? >=20 > I actually see at least one requirement beyond that for signals that ar= e=20 > in a supported package but not implemented physically for the specified= =20 > termination. Suppose the signal completion event has been enabled for=20 > such a signal. Something should be reported, but what and when? >=20 > Tom Taylor >=20 > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco >=20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Apr 28 19:32:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03536 for ; Wed, 28 Apr 2004 19:32:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIyUA-0002PR-St for megaco-archive@odin.ietf.org; Wed, 28 Apr 2004 19:29:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SNT2qA009256 for megaco-archive@odin.ietf.org; Wed, 28 Apr 2004 19:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIyPt-0008I0-FD for megaco-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 19:24:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02887 for ; Wed, 28 Apr 2004 19:24:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIyPq-00032A-OH for megaco-web-archive@ietf.org; Wed, 28 Apr 2004 19:24:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIyOu-0002yv-00 for megaco-web-archive@ietf.org; Wed, 28 Apr 2004 19:23:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIyOK-0002vT-00 for megaco-web-archive@ietf.org; Wed, 28 Apr 2004 19:23:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIy90-0004tQ-JX; Wed, 28 Apr 2004 19:07:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIy1n-0002aO-CE for megaco@optimus.ietf.org; Wed, 28 Apr 2004 18:59:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01471 for ; Wed, 28 Apr 2004 18:59:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIy1i-0000pr-Rh for megaco@ietf.org; Wed, 28 Apr 2004 18:59:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIy0x-0000m0-00 for megaco@ietf.org; Wed, 28 Apr 2004 18:58:52 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BIy0D-0000gm-00 for megaco@ietf.org; Wed, 28 Apr 2004 18:58:05 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3SMw0Ah013263 for ; Thu, 29 Apr 2004 00:58:00 +0200 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 29 Apr 2004 00:58:00 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JWBDT1ZN; Thu, 29 Apr 2004 00:58:00 +0200 Received: from ericsson.com (sealwa04-221.sw.ericsson.se [130.100.249.221]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JRYYYVH2; Thu, 29 Apr 2004 08:57:48 +1000 Message-ID: <409036F7.60107@ericsson.com> Date: Thu, 29 Apr 2004 08:57:59 +1000 X-Sybari-Trust: dfe012d8 c38aee8b 08a16856 00000138 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Taylor CC: megaco@ietf.org Subject: Re: [Megaco] Meaning of "support" for signals and events References: <408FFA01.5080905@nortelnetworks.com> In-Reply-To: <408FFA01.5080905@nortelnetworks.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-OriginalArrivalTime: 28 Apr 2004 22:58:00.0619 (UTC) FILETIME=[412DBFB0:01C42D74] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by eagle.ericsson.se id i3SMw0Ah013263 Content-Transfer-Encoding: quoted-printable Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello Tom, I didn't realise the MSF was on at the moment... As Troy said we discussed this recently on the list and it was agreed to = add=20 something to the IG. Below is the text which I propose to clarify the issue: 6.2.3 Packages =85 To support a particular package the MG must support all properties, signa= ls,=20 events and statistics defined in a package. It must also support all Sign= al and=20 Event parameters. If the functionality behind these properties, signals, = events=20 and statistics is not implemented the MG shall not return a syntax error = or=20 unknown ID for any of these elements but should return response 501 =93No= t=20 implemented=94. The MG may support a subset of the values listed in a pac= kage for=20 a particular Property or Parameter. Regards, Christian Tom Taylor wrote: > I'm at an MSF meeting at the moment, and discussion of a proposed=20 > Interoperability Agreement has added urgency to the question: what does= =20 > it mean to "support" a signal or event in Megaco/H.248? This relates t= o=20 > the requirement to support all signals and events in a supported packag= e. >=20 > Would it be a fair statement of consensus to say that a Media Gateway=20 > supports an event or signal if it does not return an error and fail the= =20 > rest of the transaction when the MGC identifies that event or signal in= =20 > a descriptor? >=20 > I actually see at least one requirement beyond that for signals that ar= e=20 > in a supported package but not implemented physically for the specified= =20 > termination. Suppose the signal completion event has been enabled for=20 > such a signal. Something should be reported, but what and when? >=20 > Tom Taylor >=20 > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco >=20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Apr 28 19:34:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03672 for ; Wed, 28 Apr 2004 19:34:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIyUF-0002Sg-Si; Wed, 28 Apr 2004 19:29:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIyHA-0006h0-Lt for megaco@optimus.ietf.org; Wed, 28 Apr 2004 19:15:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02535 for ; Wed, 28 Apr 2004 19:15:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIyH7-0002LU-Oa for megaco@ietf.org; Wed, 28 Apr 2004 19:15:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIyG1-0002A7-00 for megaco@ietf.org; Wed, 28 Apr 2004 19:14:25 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BIyEu-0001ym-00 for megaco@ietf.org; Wed, 28 Apr 2004 19:13:16 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3SNDHAh014469 for ; Thu, 29 Apr 2004 01:13:17 +0200 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 29 Apr 2004 01:13:17 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JWBDTHXK; Thu, 29 Apr 2004 01:13:17 +0200 Received: from ericsson.com (sealwa04-221.sw.ericsson.se [130.100.249.221]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JRYYYVRC; Thu, 29 Apr 2004 09:13:04 +1000 Message-ID: <40903A8F.6050907@ericsson.com> Date: Thu, 29 Apr 2004 09:13:19 +1000 X-Sybari-Trust: 7098aa90 c38aee8b 08a16856 00000138 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Troy Cauble CC: megaco@ietf.org Subject: Re: Signaling of UDI rsp Clearmode Bearer Service; Re: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversion References: <403E1760.2010903@nortelnetworks.com> <40427B92.3000707@ericsson.com> <406C2424.7050708@alcatel.de> <40720E2A.6070903@ericsson.com> <408D053E.2080405@alcatel.de> <408E24FA.2070303@ericsson.com> <408FC501.9040407@bell-labs.com> <408FF7B3.1070404@nortelnetworks.com> <40900008.2050703@bell-labs.com> In-Reply-To: <40900008.2050703@bell-labs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Apr 2004 23:13:17.0584 (UTC) FILETIME=[63BB8100:01C42D76] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Troy, Tom and Kevin, I agree Annex C is not a package however it does use the same method of referencing the properties ie. packageId/propertyID where in the binary case the packageId is 0000. However USI and TMR is being used by implementations so we can't simply deprecate Annex C as some seem to indicate. We have seen a case where TMR/USI would be useful for text implementations. There are several options here. As USI/TMR are already being used by binary implementations it isn't appropriate to make changes to this, which essentially a new package would be. This leaves modifications for the text encoding. I thought the easiest way would be to use the H.248.15 to carry the property, the side effect being a "packageID" would be needed. This seemed to be simplest method, keeps it in the H.248 domain and is in the WGs control. The other method would be to define SDP to carry the octets for USI/TMR. This will muddy the water has people will think this relates to SIP in some way. This will probably take some time to sort out. If we had our time again I would have prefered the use of packages only (no Annex C/no SDP) ;). Regards, Christian Troy Cauble wrote: > > Minor nit: They wouldn't be "text packages". They'd just be packages. > Packages inherently support both text and binary encoding. > > -troy > > > > Tom Taylor wrote: > >> I was always of a similar opinion: that Annex C would gradually be >> eroded away through migration of the material to other packages. >> >> So: what would be the principle of the text packages: would they still >> capture the Q.x signalling as (hex-encoded) binary, or would we define >> enumerations where applicable? >> >> Troy Cauble wrote: >> >>> Christian, >>> >>> The text name for Annex C is not missing. Annex C is *EXPLICITLY* >>> for the binary encoding only. >>> >>> "The protocol syntax for the binary format of the protocol is >>> defined in Annex A. Annex C specifies the encoding of the Local >>> and Remote descriptors for use with the binary format. >>> >>> A complete ABNF of the text encoding of the protocol per RFC >>> 2234 is given in Annex B. SDP is used as the encoding of the >>> Local and Remote descriptors for use with the text encoding as >>> modified in 7.1.8." >>> >>> H.248.15 is designed to allow Packages to add parameters to the text >>> encoding of the Local and Remote descriptors. Annex C is not a Package. >>> >>> Isn't the real solution here to make a proper Package that handles >>> TMR and related parameters for both text and binary encoding??? >>> >>> >>> >>> This mod would allow recursion in both encodings: >>> >>> a=h248:AnxC/SDP_A=h248:AnxC/SDP_A=h248:AnxC/SDP_A=...... >>> >>> >>> Now I'm going to go too far and really alienate people: >>> >>> On an as needed basis, portions of Annex C should be deprecated and >>> replaced with proper packages. The package writers could even tell >>> us which descriptors to use the parameters in, something Annex C >>> never did. >>> >>> >>> -troy >>> >>> > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Apr 28 19:51:34 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04628 for ; Wed, 28 Apr 2004 19:51:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIycj-00067B-2h for megaco-archive@odin.ietf.org; Wed, 28 Apr 2004 19:37:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SNbqwH023493 for megaco-archive@odin.ietf.org; Wed, 28 Apr 2004 19:37:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIyah-00057p-DG for megaco-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 19:35:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03760 for ; Wed, 28 Apr 2004 19:35:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIyae-0004DA-G2 for megaco-web-archive@ietf.org; Wed, 28 Apr 2004 19:35:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIyZs-000486-00 for megaco-web-archive@ietf.org; Wed, 28 Apr 2004 19:34:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIyZ8-00042N-00 for megaco-web-archive@ietf.org; Wed, 28 Apr 2004 19:34:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIyUF-0002Sg-Si; Wed, 28 Apr 2004 19:29:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIyHA-0006h0-Lt for megaco@optimus.ietf.org; Wed, 28 Apr 2004 19:15:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02535 for ; Wed, 28 Apr 2004 19:15:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIyH7-0002LU-Oa for megaco@ietf.org; Wed, 28 Apr 2004 19:15:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIyG1-0002A7-00 for megaco@ietf.org; Wed, 28 Apr 2004 19:14:25 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BIyEu-0001ym-00 for megaco@ietf.org; Wed, 28 Apr 2004 19:13:16 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3SNDHAh014469 for ; Thu, 29 Apr 2004 01:13:17 +0200 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 29 Apr 2004 01:13:17 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JWBDTHXK; Thu, 29 Apr 2004 01:13:17 +0200 Received: from ericsson.com (sealwa04-221.sw.ericsson.se [130.100.249.221]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JRYYYVRC; Thu, 29 Apr 2004 09:13:04 +1000 Message-ID: <40903A8F.6050907@ericsson.com> Date: Thu, 29 Apr 2004 09:13:19 +1000 X-Sybari-Trust: 7098aa90 c38aee8b 08a16856 00000138 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Troy Cauble CC: megaco@ietf.org Subject: Re: Signaling of UDI rsp Clearmode Bearer Service; Re: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversion References: <403E1760.2010903@nortelnetworks.com> <40427B92.3000707@ericsson.com> <406C2424.7050708@alcatel.de> <40720E2A.6070903@ericsson.com> <408D053E.2080405@alcatel.de> <408E24FA.2070303@ericsson.com> <408FC501.9040407@bell-labs.com> <408FF7B3.1070404@nortelnetworks.com> <40900008.2050703@bell-labs.com> In-Reply-To: <40900008.2050703@bell-labs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Apr 2004 23:13:17.0584 (UTC) FILETIME=[63BB8100:01C42D76] Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Troy, Tom and Kevin, I agree Annex C is not a package however it does use the same method of referencing the properties ie. packageId/propertyID where in the binary case the packageId is 0000. However USI and TMR is being used by implementations so we can't simply deprecate Annex C as some seem to indicate. We have seen a case where TMR/USI would be useful for text implementations. There are several options here. As USI/TMR are already being used by binary implementations it isn't appropriate to make changes to this, which essentially a new package would be. This leaves modifications for the text encoding. I thought the easiest way would be to use the H.248.15 to carry the property, the side effect being a "packageID" would be needed. This seemed to be simplest method, keeps it in the H.248 domain and is in the WGs control. The other method would be to define SDP to carry the octets for USI/TMR. This will muddy the water has people will think this relates to SIP in some way. This will probably take some time to sort out. If we had our time again I would have prefered the use of packages only (no Annex C/no SDP) ;). Regards, Christian Troy Cauble wrote: > > Minor nit: They wouldn't be "text packages". They'd just be packages. > Packages inherently support both text and binary encoding. > > -troy > > > > Tom Taylor wrote: > >> I was always of a similar opinion: that Annex C would gradually be >> eroded away through migration of the material to other packages. >> >> So: what would be the principle of the text packages: would they still >> capture the Q.x signalling as (hex-encoded) binary, or would we define >> enumerations where applicable? >> >> Troy Cauble wrote: >> >>> Christian, >>> >>> The text name for Annex C is not missing. Annex C is *EXPLICITLY* >>> for the binary encoding only. >>> >>> "The protocol syntax for the binary format of the protocol is >>> defined in Annex A. Annex C specifies the encoding of the Local >>> and Remote descriptors for use with the binary format. >>> >>> A complete ABNF of the text encoding of the protocol per RFC >>> 2234 is given in Annex B. SDP is used as the encoding of the >>> Local and Remote descriptors for use with the text encoding as >>> modified in 7.1.8." >>> >>> H.248.15 is designed to allow Packages to add parameters to the text >>> encoding of the Local and Remote descriptors. Annex C is not a Package. >>> >>> Isn't the real solution here to make a proper Package that handles >>> TMR and related parameters for both text and binary encoding??? >>> >>> >>> >>> This mod would allow recursion in both encodings: >>> >>> a=h248:AnxC/SDP_A=h248:AnxC/SDP_A=h248:AnxC/SDP_A=...... >>> >>> >>> Now I'm going to go too far and really alienate people: >>> >>> On an as needed basis, portions of Annex C should be deprecated and >>> replaced with proper packages. The package writers could even tell >>> us which descriptors to use the parameters in, something Annex C >>> never did. >>> >>> >>> -troy >>> >>> > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Apr 29 01:28:36 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20115 for ; Thu, 29 Apr 2004 01:28:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ40k-0002Lc-E7; Thu, 29 Apr 2004 01:23:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ3tp-0000a8-N5 for megaco@optimus.ietf.org; Thu, 29 Apr 2004 01:15:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19416 for ; Thu, 29 Apr 2004 01:15:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ3tj-0000zm-L0 for megaco@ietf.org; Thu, 29 Apr 2004 01:15:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ3sn-0000pe-00 for megaco@ietf.org; Thu, 29 Apr 2004 01:14:50 -0400 Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1BJ3rq-0000bI-00 for megaco@ietf.org; Thu, 29 Apr 2004 01:13:55 -0400 Received: from z14593 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HWX005452GCZ7@mta0.huawei.com> for megaco@ietf.org; Thu, 29 Apr 2004 13:12:13 +0800 (CST) Date: Thu, 29 Apr 2004 13:14:00 +0800 From: Zhao Bo Subject: Re: [Megaco] Continuity tests To: Aleksandr Ryabin , Kevin Boyle , megaco@ietf.org Message-id: <001201c42da8$c8678680$e4496e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 X-Mailer: Microsoft Outlook Express 5.50.4922.1500 Content-type: multipart/alternative; boundary="Boundary_(ID_kB5r6zNxXKbUIH6KXU2jcA)" X-Priority: 3 X-MSMail-priority: Normal References: <5.2.1.1.0.20040428135759.051e1498@IL06EXM13.corp.mot.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_kB5r6zNxXKbUIH6KXU2jcA) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Can H.248.17 "line test packages" be used to test these circuits? ----- Original Message ----- From: Aleksandr Ryabin To: Kevin Boyle ; megaco@ietf.org Sent: Thursday, April 29, 2004 2:11 AM Subject: RE: [Megaco] Continuity tests Yes, the type of test depends on what a circuit is connected to. But, I was actually coming from the view that MGC "controls" MG and as such only MGC should have knowledge on what test to execute (i.e. what is connected to the other side of a circuit). If this information is left in MG, then each circuit has to be provisioned with that information such that MG can make intelligent decision on what type of test to execute. Thus every time a circuit connection is changed, directly or indirectly, MG circuit needs to be re-provisioned. I think that configuration should be kept on MGC and the decision should come from MGC instead. Aleks At 02:30 PM 4/28/2004, Kevin Boyle wrote: Is it possible to run more than one kind of continuity test on a particular circuit? If no, then the provisioning model holds and there is no need for a change. If yes, then we may need to add something to the package to allow selection of a ct test type. Kevin -----Original Message----- From: Aleksandr Ryabin [mailto:kengr@motorola.com] Sent: Wednesday, April 28, 2004 1:21 PM To: megaco@ietf.org Subject: [Megaco] Continuity tests Hi, There are several continuity test types (i.e 2-wire, 4-wire, etc) While provisioning of physical test parameters (i.e. frequencies, sequence, timeouts, etc) in MG makes sense, IMHO choosing a type of continuity test seem logical to be left to MGC. Basic Continuity Package (ct) does not allow to choose the type of a test. It implies that type of a test is provisioned on MG (per termination?) Is there another (extended) continuity test package which allows MGC to choose the type of a continuity test to be performed? If not, does anyone see a need to have such a package? Comments? Thanks Aleks _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --Boundary_(ID_kB5r6zNxXKbUIH6KXU2jcA) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Can H.248.17 "line test packages"  be used to test these circuits?
----- Original Message -----
Sent: Thursday, April 29, 2004 2:11 AM
Subject: RE: [Megaco] Continuity tests

Yes, the type of test depends on what a circuit is connected to.

But, I was actually coming from the view that MGC "controls" MG
and as such only MGC should have knowledge on what test to execute
(i.e. what is connected to the other side of a circuit).

If this information is left in MG, then each circuit has to be provisioned
with that information such that MG can make intelligent decision on what
type of test to execute. Thus every time a circuit connection is changed,
directly or indirectly, MG circuit needs to be re-provisioned.

I think that configuration should  be kept on MGC and the decision should
come from MGC instead.

        Aleks

At 02:30 PM 4/28/2004, Kevin Boyle wrote:

Is it possible to run more than one kind of continuity test on a particular circuit?  If no, then the provisioning model holds and there is no need for a change.  If yes, then we may need to add something to the package to allow selection of a ct test type.

Kevin

-----Original Message-----
From: Aleksandr Ryabin [mailto:kengr@motorola.com]
Sent: Wednesday, April 28, 2004 1:21 PM
To: megaco@ietf.org
Subject: [Megaco] Continuity tests

Hi,

There are several continuity test types (i.e 2-wire, 4-wire, etc) While provisioning of physical test parameters (i.e. frequencies, sequence, timeouts, etc) in MG makes sense, IMHO choosing a type of continuity test seem logical to be left to MGC.

Basic Continuity Package (ct) does not allow to choose the type of a test.
It implies that type of a test is provisioned on MG (per termination?)

Is there another (extended) continuity test package which allows MGC to choose the type of a continuity test to be performed?

If not, does anyone see a need to have such a package?
Comments?

Thanks
        Aleks

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
--Boundary_(ID_kB5r6zNxXKbUIH6KXU2jcA)-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Apr 29 01:35:51 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20531 for ; Thu, 29 Apr 2004 01:35:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ43c-00033O-AY; Thu, 29 Apr 2004 01:26:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ3wi-0000yg-EJ for megaco@optimus.ietf.org; Thu, 29 Apr 2004 01:18:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19633 for ; Thu, 29 Apr 2004 01:18:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ3wc-0001MS-CG for megaco@ietf.org; Thu, 29 Apr 2004 01:18:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ3vi-0001G2-00 for megaco@ietf.org; Thu, 29 Apr 2004 01:17:51 -0400 Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1BJ3vF-00019B-00 for megaco@ietf.org; Thu, 29 Apr 2004 01:17:25 -0400 Received: from z14593 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HWX007GM2MBJY@mta0.huawei.com> for megaco@ietf.org; Thu, 29 Apr 2004 13:15:48 +0800 (CST) Date: Thu, 29 Apr 2004 13:17:36 +0800 From: Zhao Bo To: megaco@ietf.org Message-id: <001a01c42da9$48decb20$e4496e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 X-Mailer: Microsoft Outlook Express 5.50.4922.1500 Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Subject: [Megaco] Virtual Media Gateway and IPsec Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hello List: I have a question about IPSec and virtual media gateway. Suppose I have a phisical gateway divided into two virtual gateway (VMGW-A, VMGW-B), controlled by two MGCs (MGC-A, MGC-B), respectively. Is there a danger MGC-A can controlled both MGC-A and MGC-B? Although MGC-A has a security asscociation wtih VMGW-A, so does MGC-B with VMGW-B, but the H.248 layer is above the IP layer. Zhao Bo ***************************************************************** This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ***************************************************************** _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Apr 29 01:48:44 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21127 for ; Thu, 29 Apr 2004 01:48:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ4F3-0005AG-MI for megaco-archive@odin.ietf.org; Thu, 29 Apr 2004 01:37:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T5bnx8019852 for megaco-archive@odin.ietf.org; Thu, 29 Apr 2004 01:37:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ47N-00043k-Oy for megaco-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 01:29:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20195 for ; Thu, 29 Apr 2004 01:29:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ47H-0002rx-IK for megaco-web-archive@ietf.org; Thu, 29 Apr 2004 01:29:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ46O-0002ke-00 for megaco-web-archive@ietf.org; Thu, 29 Apr 2004 01:28:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJ45c-0002cj-00 for megaco-web-archive@ietf.org; Thu, 29 Apr 2004 01:28:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ40k-0002Lc-E7; Thu, 29 Apr 2004 01:23:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ3tp-0000a8-N5 for megaco@optimus.ietf.org; Thu, 29 Apr 2004 01:15:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19416 for ; Thu, 29 Apr 2004 01:15:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ3tj-0000zm-L0 for megaco@ietf.org; Thu, 29 Apr 2004 01:15:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ3sn-0000pe-00 for megaco@ietf.org; Thu, 29 Apr 2004 01:14:50 -0400 Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1BJ3rq-0000bI-00 for megaco@ietf.org; Thu, 29 Apr 2004 01:13:55 -0400 Received: from z14593 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HWX005452GCZ7@mta0.huawei.com> for megaco@ietf.org; Thu, 29 Apr 2004 13:12:13 +0800 (CST) Date: Thu, 29 Apr 2004 13:14:00 +0800 From: Zhao Bo Subject: Re: [Megaco] Continuity tests To: Aleksandr Ryabin , Kevin Boyle , megaco@ietf.org Message-id: <001201c42da8$c8678680$e4496e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 X-Mailer: Microsoft Outlook Express 5.50.4922.1500 Content-type: multipart/alternative; boundary="Boundary_(ID_kB5r6zNxXKbUIH6KXU2jcA)" X-Priority: 3 X-MSMail-priority: Normal References: <5.2.1.1.0.20040428135759.051e1498@IL06EXM13.corp.mot.com> Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. --Boundary_(ID_kB5r6zNxXKbUIH6KXU2jcA) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Can H.248.17 "line test packages" be used to test these circuits? ----- Original Message ----- From: Aleksandr Ryabin To: Kevin Boyle ; megaco@ietf.org Sent: Thursday, April 29, 2004 2:11 AM Subject: RE: [Megaco] Continuity tests Yes, the type of test depends on what a circuit is connected to. But, I was actually coming from the view that MGC "controls" MG and as such only MGC should have knowledge on what test to execute (i.e. what is connected to the other side of a circuit). If this information is left in MG, then each circuit has to be provisioned with that information such that MG can make intelligent decision on what type of test to execute. Thus every time a circuit connection is changed, directly or indirectly, MG circuit needs to be re-provisioned. I think that configuration should be kept on MGC and the decision should come from MGC instead. Aleks At 02:30 PM 4/28/2004, Kevin Boyle wrote: Is it possible to run more than one kind of continuity test on a particular circuit? If no, then the provisioning model holds and there is no need for a change. If yes, then we may need to add something to the package to allow selection of a ct test type. Kevin -----Original Message----- From: Aleksandr Ryabin [mailto:kengr@motorola.com] Sent: Wednesday, April 28, 2004 1:21 PM To: megaco@ietf.org Subject: [Megaco] Continuity tests Hi, There are several continuity test types (i.e 2-wire, 4-wire, etc) While provisioning of physical test parameters (i.e. frequencies, sequence, timeouts, etc) in MG makes sense, IMHO choosing a type of continuity test seem logical to be left to MGC. Basic Continuity Package (ct) does not allow to choose the type of a test. It implies that type of a test is provisioned on MG (per termination?) Is there another (extended) continuity test package which allows MGC to choose the type of a continuity test to be performed? If not, does anyone see a need to have such a package? Comments? Thanks Aleks _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --Boundary_(ID_kB5r6zNxXKbUIH6KXU2jcA) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Can H.248.17 "line test packages"  be used to test these circuits?
----- Original Message -----
Sent: Thursday, April 29, 2004 2:11 AM
Subject: RE: [Megaco] Continuity tests

Yes, the type of test depends on what a circuit is connected to.

But, I was actually coming from the view that MGC "controls" MG
and as such only MGC should have knowledge on what test to execute
(i.e. what is connected to the other side of a circuit).

If this information is left in MG, then each circuit has to be provisioned
with that information such that MG can make intelligent decision on what
type of test to execute. Thus every time a circuit connection is changed,
directly or indirectly, MG circuit needs to be re-provisioned.

I think that configuration should  be kept on MGC and the decision should
come from MGC instead.

        Aleks

At 02:30 PM 4/28/2004, Kevin Boyle wrote:

Is it possible to run more than one kind of continuity test on a particular circuit?  If no, then the provisioning model holds and there is no need for a change.  If yes, then we may need to add something to the package to allow selection of a ct test type.

Kevin

-----Original Message-----
From: Aleksandr Ryabin [mailto:kengr@motorola.com]
Sent: Wednesday, April 28, 2004 1:21 PM
To: megaco@ietf.org
Subject: [Megaco] Continuity tests

Hi,

There are several continuity test types (i.e 2-wire, 4-wire, etc) While provisioning of physical test parameters (i.e. frequencies, sequence, timeouts, etc) in MG makes sense, IMHO choosing a type of continuity test seem logical to be left to MGC.

Basic Continuity Package (ct) does not allow to choose the type of a test.
It implies that type of a test is provisioned on MG (per termination?)

Is there another (extended) continuity test package which allows MGC to choose the type of a continuity test to be performed?

If not, does anyone see a need to have such a package?
Comments?

Thanks
        Aleks

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
--Boundary_(ID_kB5r6zNxXKbUIH6KXU2jcA)-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Apr 29 01:50:08 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21303 for ; Thu, 29 Apr 2004 01:50:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ4P5-0006wO-Eh for megaco-archive@odin.ietf.org; Thu, 29 Apr 2004 01:48:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T5mBEK026681 for megaco-archive@odin.ietf.org; Thu, 29 Apr 2004 01:48:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ4ED-0004w2-H4 for megaco-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 01:36:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20594 for ; Thu, 29 Apr 2004 01:36:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ4E7-0003r0-AZ for megaco-web-archive@ietf.org; Thu, 29 Apr 2004 01:36:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ4D9-0003ju-00 for megaco-web-archive@ietf.org; Thu, 29 Apr 2004 01:35:51 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJ4Cd-0003cv-00 for megaco-web-archive@ietf.org; Thu, 29 Apr 2004 01:35:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ43c-00033O-AY; Thu, 29 Apr 2004 01:26:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ3wi-0000yg-EJ for megaco@optimus.ietf.org; Thu, 29 Apr 2004 01:18:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19633 for ; Thu, 29 Apr 2004 01:18:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ3wc-0001MS-CG for megaco@ietf.org; Thu, 29 Apr 2004 01:18:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ3vi-0001G2-00 for megaco@ietf.org; Thu, 29 Apr 2004 01:17:51 -0400 Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1BJ3vF-00019B-00 for megaco@ietf.org; Thu, 29 Apr 2004 01:17:25 -0400 Received: from z14593 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HWX007GM2MBJY@mta0.huawei.com> for megaco@ietf.org; Thu, 29 Apr 2004 13:15:48 +0800 (CST) Date: Thu, 29 Apr 2004 13:17:36 +0800 From: Zhao Bo To: megaco@ietf.org Message-id: <001a01c42da9$48decb20$e4496e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 X-Mailer: Microsoft Outlook Express 5.50.4922.1500 Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [Megaco] Virtual Media Gateway and IPsec Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hello List: I have a question about IPSec and virtual media gateway. Suppose I have a phisical gateway divided into two virtual gateway (VMGW-A, VMGW-B), controlled by two MGCs (MGC-A, MGC-B), respectively. Is there a danger MGC-A can controlled both MGC-A and MGC-B? Although MGC-A has a security asscociation wtih VMGW-A, so does MGC-B with VMGW-B, but the H.248 layer is above the IP layer. Zhao Bo ***************************************************************** This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ***************************************************************** _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Apr 29 02:56:43 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09081 for ; Thu, 29 Apr 2004 02:56:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ5M2-0004j5-M5; Thu, 29 Apr 2004 02:49:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ5FC-0002qL-V5 for megaco@optimus.ietf.org; Thu, 29 Apr 2004 02:42:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08478 for ; Thu, 29 Apr 2004 02:41:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ5F5-000623-R4 for megaco@ietf.org; Thu, 29 Apr 2004 02:41:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ5ED-0005u8-00 for megaco@ietf.org; Thu, 29 Apr 2004 02:41:01 -0400 Received: from web10704.mail.yahoo.com ([216.136.130.212]) by ietf-mx with smtp (Exim 4.12) id 1BJ5Do-0005lc-00 for megaco@ietf.org; Thu, 29 Apr 2004 02:40:36 -0400 Message-ID: <20040429064038.11675.qmail@web10704.mail.yahoo.com> Received: from [128.107.253.42] by web10704.mail.yahoo.com via HTTP; Thu, 29 Apr 2004 16:40:38 EST Date: Thu, 29 Apr 2004 16:40:38 +1000 (EST) From: =?iso-8859-1?q?petric=20john?= To: megaco@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Subject: [Megaco] Virtual MGs controlled by MGCs. Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hello, Here is one basic question. When a physical MG is split into two virtual MGs (MG1 and MG2), each controlled by seperate MGCs (MGC1 and MGC2). In this case, the IP side is shared between both the virtual MGs. i.e. the message would contain the IP address and the port number (tcp/udp), which is shared. When MGC1 is sending a message targetted to the MG1, how it actually processed by the MG1 only and not by the MG2? On what basis the commands are segregated at the physical MG level? The spec doesn't really talk about it. ===== Cheers! PJ. Find local movie times and trailers on Yahoo! Movies. http://au.movies.yahoo.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Apr 29 03:06:37 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09659 for ; Thu, 29 Apr 2004 03:06:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ5Xd-0007Rg-Gc for megaco-archive@odin.ietf.org; Thu, 29 Apr 2004 03:01:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T715Mc028612 for megaco-archive@odin.ietf.org; Thu, 29 Apr 2004 03:01:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ5Uj-00070G-Gw for megaco-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 02:58:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09185 for ; Thu, 29 Apr 2004 02:58:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ5Uc-0000U7-J7 for megaco-web-archive@ietf.org; Thu, 29 Apr 2004 02:57:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ5Td-0000K5-00 for megaco-web-archive@ietf.org; Thu, 29 Apr 2004 02:56:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJ5St-0000BS-00 for megaco-web-archive@ietf.org; Thu, 29 Apr 2004 02:56:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ5M2-0004j5-M5; Thu, 29 Apr 2004 02:49:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ5FC-0002qL-V5 for megaco@optimus.ietf.org; Thu, 29 Apr 2004 02:42:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08478 for ; Thu, 29 Apr 2004 02:41:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ5F5-000623-R4 for megaco@ietf.org; Thu, 29 Apr 2004 02:41:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ5ED-0005u8-00 for megaco@ietf.org; Thu, 29 Apr 2004 02:41:01 -0400 Received: from web10704.mail.yahoo.com ([216.136.130.212]) by ietf-mx with smtp (Exim 4.12) id 1BJ5Do-0005lc-00 for megaco@ietf.org; Thu, 29 Apr 2004 02:40:36 -0400 Message-ID: <20040429064038.11675.qmail@web10704.mail.yahoo.com> Received: from [128.107.253.42] by web10704.mail.yahoo.com via HTTP; Thu, 29 Apr 2004 16:40:38 EST Date: Thu, 29 Apr 2004 16:40:38 +1000 (EST) From: =?iso-8859-1?q?petric=20john?= To: megaco@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Megaco] Virtual MGs controlled by MGCs. Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hello, Here is one basic question. When a physical MG is split into two virtual MGs (MG1 and MG2), each controlled by seperate MGCs (MGC1 and MGC2). In this case, the IP side is shared between both the virtual MGs. i.e. the message would contain the IP address and the port number (tcp/udp), which is shared. When MGC1 is sending a message targetted to the MG1, how it actually processed by the MG1 only and not by the MG2? On what basis the commands are segregated at the physical MG level? The spec doesn't really talk about it. ===== Cheers! PJ. Find local movie times and trailers on Yahoo! Movies. http://au.movies.yahoo.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Apr 29 09:56:09 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02247 for ; Thu, 29 Apr 2004 09:56:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBgs-0004Pd-3w; Thu, 29 Apr 2004 09:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIu3g-0008BX-6b for megaco@optimus.ietf.org; Wed, 28 Apr 2004 14:45:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06792 for ; Wed, 28 Apr 2004 14:45:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIu3c-0006RJ-3l for megaco@ietf.org; Wed, 28 Apr 2004 14:45:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIu2d-0006NA-00 for megaco@ietf.org; Wed, 28 Apr 2004 14:44:25 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1BIu1f-0006IW-00 for megaco@ietf.org; Wed, 28 Apr 2004 14:43:19 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3SIgZH13542; Wed, 28 Apr 2004 14:42:35 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Apr 2004 14:42:35 -0400 Message-ID: From: "Kevin Boyle" To: Troy Cauble , Christian Groves Cc: Carsten Waitzmann , "Tom-PT Taylor" , Albrecht.Schwarz@alcatel.de, Zhao Bo , megaco@ietf.org Subject: RE: Signaling of UDI rsp Clearmode Bearer Service; Re: TDM Hairpi nning; Re: [Megaco] Hairpin case A/u Law conversion Date: Wed, 28 Apr 2004 14:42:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42D50.90DDD14A" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , 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_01C42D50.90DDD14A Content-Type: text/plain; charset="utf-8" X-MIME-Autoconverted: from 8bit to quoted-printable by zrtps06s.nortelnetworks.com id i3SIgZH13542 Content-Transfer-Encoding: quoted-printable I have to agree with Troy on this. Annex C is definitively for the binar= y encoding. Text encoding should use packages, or an appropriate SDP construct for communicating the information. Using .15 to allow SDP transport of Annex C is dodging the problem (and creating its own as Troy has pointed out), rather than solving it. We should define a package tha= t then could make use of .15 if need be. Kevin=20 -----Original Message----- From: Troy Cauble [mailto:troy@bell-labs.com]=20 Sent: Wednesday, April 28, 2004 10:52 AM To: Christian Groves Cc: Carsten Waitzmann; Taylor, Tom-PT [CAR:5N00:EXCH]; Albrecht.Schwarz@alcatel.de; Zhao Bo; megaco@ietf.org Subject: Re: Signaling of UDI rsp Clearmode Bearer Service; Re: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversion Christian, The text name for Annex C is not missing. Annex C is *EXPLICITLY* for th= e binary encoding only. "The protocol syntax for the binary format of the protocol is defined in Annex A. Annex C specifies the encoding of the Local and Remote descriptors for use with the binary format. A complete ABNF of the text encoding of the protocol per RFC 2234 is given in Annex B. SDP is used as the encoding of the =09 Local and Remote descriptors for use with the text encoding as modified in 7.1.8." H.248.15 is designed to allow Packages to add parameters to the text encoding of the Local and Remote descriptors. Annex C is not a Package. Isn't the real solution here to make a proper Package that handles TMR an= d related parameters for both text and binary encoding??? This mod would allow recursion in both encodings: a=3Dh248:AnxC/SDP_A=3Dh248:AnxC/SDP_A=3Dh248:AnxC/SDP_A=3D...... Now I'm going to go too far and really alienate people: On an as needed basis, portions of Annex C should be deprecated and=20 replaced with proper packages. The package writers could even tell us=20 which descriptors to use the parameters in, something Annex C never did. -troy Christian Groves wrote: > Hello Carsten, >=20 > Seems you have a very good point. The text name for Annex C is missing. > I propose using "AnxC". Or is there another suggestion? >=20 > I will put this in a contribution for the upcoming ITU SG16 meeting. >=20 > Regards, Christian >=20 > Carsten Waitzmann wrote: >=20 >> Hello Christian, >> >> thanks for the information. I am still missing one piece: >> >> In case of textual encoding, what should be used for=20 >> the media stream properties described in H.248.1 Annex C? >> >> a=3Dh248item:/TMR =3D 40 >> >> thanks. >> Carsten >> >> Christian Groves wrote: >> >>> Hello Carsten, >>> >>> Yes this is what I had in mind. The package ID for Annex C is 0. >>> >>> ie. H.248.1 Annex A >>> PkgdName ::=3D OCTET STRING(SIZE(4)) >>> -- represents Package Name (2 octets) plus Property, Event, >>> -- Signal Names or Statistics ID. (2 octets) >>> -- To wildcard a package use 0xFFFF for first two octets, choose >>> -- is not allowed. To reference native property tag specified in >>> -- Annex C, use 0x0000 as first two octets. >>> >>> Regards, Christian >>> >>> Carsten Waitzmann wrote: >>> >>>> Hello Christian, >>>> >>>> I took your suggestion as a basis for the following example: >>>> >>>> MGC -> MG: >>>> MEGACO / 1 [1.2.3.4] >>>> Transaction =3D 100 { >>>> Context =3D $ { Add =3D TDM1 { >>>> Media { >>>> LocalControl {Mode =3D=20 >>>> SendReceive}, >>>> Local {a=3Dh248item:TMR= =3D=20 >>>> 0000 0010}} >>>> }}} >>>> >>>> MG -> MGC >>>> MEGACO / 1 [1.2.3.5] >>>> Reply =3D 100 { >>>> Context =3D 1 { >>>> Add =3D TDM1 { >>>> Media { >>>> Local {a=3Dh248item:T= MR=20 >>>> =3D 00000010} >>>> }}}} >>>> >>>> Is this usage in line to what you have in mind? >>>> H.248.15 specifies: a=3Dh248item:/ =3D=20 >>>> . For H.248.1 C.9 I do not know which package applies to=20 >>>> property TMR. But H.248.15 states "To enable the carriage of package= =20 >>>> defined properties in the local and remote descriptors of the text=20 >>>> encoded H.248.1 protocol the Package attribute shall be used" thus I= =20 >>>> am wondering whether a package name isn't mandatory? >>>> >>>> Thanks a lot! >>>> >>>> Carsten >>>> >>>> Alcatel >>>> >>>> Christian Groves wrote: >>>> >>>>> Hello Tom and Albrecht, >>>>> >>>>> What peice of information do you want to signal explicitely?=20 >>>>> Doesn't TMR allow you to specify 64Kbit UDI? If so then its=20 >>>>> supported by H.248.1 Annex C.9. For H.248 text users this (or any=20 >>>>> element in Annex C) can be tranferred via H.248.15. Alternatively=20 >>>>> Q.1950 sect 5.7.1.2 specifies an equivalent encoding. >>>>> >>>>> Regards, Christian >>>>> >>>>> Tom Taylor wrote: >>>>> >>>>>> I intended a reference to draft-ietf-avt-rtp-clearmode-04.txt in=20 >>>>>> my intervention. My old draft has been allowed to expire because=20 >>>>>> it did not seem to be of much interest to the community. >>>>>> >>>>>> You are right: the draft just referred to doesn't apply to TDM,=20 >>>>>> only to the packet side. I wasn't thinking. I agree that in the=20 >>>>>> absence of the attributes provided in my old draft, TDM bearer=20 >>>>>> characteristics are assumed rather than signalled explicitly. >>>>>> >>>>>> Albrecht.Schwarz@alcatel.de wrote: >>>>>> >>>>>>> I think that the question is, whether this specific TDM bearer=20 >>>>>>> capability >>>>>>> should be (1) explicitly signalled, or whether (2) implicit=20 >>>>>>> assumption is >>>>>>> already sufficient. >>>>>>> >>>>>>> With regard to (1), Tom, I guess that your refer to >>>>>>> >>>>>>> * RTP/CLEARMODE >>>>>>> RTP payload format for a 64 kbit/s transparent call >>>>>>> =20 >>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-clearmode-04.txt=20 >>>>>>> >>>>>>> >>>>>>> But, this coming RFC may not be directly applied, e.g.,=20 >>>>>>> packetization time >>>>>>> parameter isn't applicable IMHO. Pls correct me if wrong. >>>>>>> >>>>>>> Or do you refer to your proposals in your expired draft wrt >>>>>>> * TDM/CLEARMODE >>>>>>> Conventions for the use of the Session Description Protocol (SD= P) >>>>>>> for Digital Circuit Connections >>>>>>> =20 >>>>>>> http://www.watersprings.org/pub/id/draft-taylor-mmusic-sdp-tdm-01.txt=20 >>>>>>> >>>>>>> >>>>>>> My conclusion is, that an explicit signalling method doesn't=20 >>>>>>> exist today >>>>>>> ("exception might be Q.1950"). >>>>>>> Even though, an explicit TDM Media Descriptor for I.231.1 might=20 >>>>>>> be helpful >>>>>>> for unambigously specification in certain MG implementations. >>>>>>> >>>>>>> >>>>>>> With regard to (2): >>>>>>> Implicit signaling is in my understanding the situation of today.= =20 >>>>>>> In case >>>>>>> of, (a) missing TDM Media Descriptors, or (b) "identical TDM Medi= a >>>>>>> Descriptors with transparent channel indications", when a=20 >>>>>>> transparent >>>>>>> 64-kbit/s bearer connection may be established. >>>>>>> Sometimes this is also called "native TDM switching", or "native = TDM >>>>>>> hairpinning", but technically it is exactly representing an ISDN=20 >>>>>>> B channel >>>>>>> with I.231.1 bearer service. [=3D> the channel may bypass the DSP= ,=20 >>>>>>> but in >>>>>>> case that a DSP is looped-in, then must be the DSP channel=20 >>>>>>> operation mode >>>>>>> configured for 'Clearmode'] >>>>>>> >>>>>>> Last comment: >>>>>>> Such kind of implicit signalling mechanism is often assumed in te= lco >>>>>>> industry, because this is the legacy signaling mechanism within a= =20 >>>>>>> TDM >>>>>>> switch ("if there aren't any signaled bearer capabilities then=20 >>>>>>> transparent >>>>>>> channel; any needed bearer capability in addition must be explici= tly >>>>>>> signalled, like signal processing network equipment functions,=20 >>>>>>> e.g., EC"). >>>>>>> >>>>>>> TDM hairpinning means, an "H.248-controlled TDM switching=20 >>>>>>> function" from >>>>>>> H.248 Media Gateway perspective. Hence, this implicit signalling=20 >>>>>>> assumption >>>>>>> may be still valid, or do you see any needs for explicit signalin= g >>>>>>> codepoints in case of TDM-to-TDM ISDN I.231.1 calls? >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Albrecht >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Tom=20 >>>>>>> Taylor >>>>>>> >>>>>> >>>>>>> tworks.com> cc: Albrecht=20 >>>>>>> SCHWARZ/DE/ALCATEL@ALCATEL,=20 >>>>>>> megaco@ietf.org =20 >>>>>>> Subject: Re: TDM=20 >>>>>>> Hairpinning; Re: [Megaco] Hairpin case A/u Law=20 >>>>>>> conversion =20 >>>>>>> 26.02.2004=20 >>>>>>> 14:05 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I think you would do it by specifying the CLEARMODE codec in the=20 >>>>>>> Local and >>>>>>> Remote >>>>>>> descriptors. Unfortunately, CLEARMODE is still under=20 >>>>>>> consideration by the >>>>>>> IESG >>>>>>> and hasn't reached RFC status. >>>>>>> >>>>>>> Zhao Bo wrote: >>>>>>> >>>>>>>> Dear Albrecht: >>>>>>>> Is there any H.248 package defined to signal the UDI=20 >>>>>>>> transparency >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> properties in TDM hairping case? >>>>>>> >>>>>>>> Best regards >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>> From: >>>>>>>> To: "Zhao Bo" >>>>>>>> Cc: ; >>>>>>>> Sent: Wednesday, February 25, 2004 10:24 PM >>>>>>>> Subject: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law=20 >>>>>>>> conversion >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Dear Zhao Bo, >>>>>>>> >>>>>>>> because there isn't any "hairpinning" definition in MEGACOP/H.24= 8 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> standards >>>>>>> >>>>>>>> ("please correct if I'm wrong"), I'd like to use the following=20 >>>>>>>> one for >>>>>>>> responding your questions: >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> *************************************************************************= *** *******=20 >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Definition: >>>>>>>> TDM Hairpinning >>>>>>>> ? is a scenario whereby a call is being made between two TDM=20 >>>>>>>> endpoints on >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> a >>>>>>> >>>>>>>> single media gateway. The media comes in on one TDM channel=20 >>>>>>>> and goes >>>>>>>> out on another TDM channel through the use of an internal=20 >>>>>>>> loop in the >>>>>>>> media gateway. >>>>>>>> >>>>>>>> Note 1: due to the fact that there are local call types at local >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> exchanges >>>>>>> >>>>>>>> (CLASS5), and transit exchanges (CLASS4) in legacy TDM networks=20 >>>>>>>> (PSTN, >>>>>>>> NISDN, etc), there is a variety of TDM-to-TDM connection types=20 >>>>>>>> behind the >>>>>>>> general "TDM hairpinning" capability (dependent on required type= =20 >>>>>>>> of IWF, >>>>>>>> etc.) in corresponding H.248 MG types >>>>>>>> >>>>>>>> Note 2: H.248/MEGCOP perspective >>>>>>>> TDM Hairpinning =3D Single H.248 Context with 2 H.248 TDM=20 >>>>>>>> Terminations >>>>>>>> >>>>>>> >>>>>>> *************************************************************************= *** ********=20 >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Based on this hairpinning understanding, my answers are: >>>>>>>> >>>>>>>> (1) Speech telephony service: G.711 companding formats are a=20 >>>>>>>> property of >>>>>>>> the corresponding H.248 TDM termination >>>>>>>> >>>>>>>> [Note: dependent on MG architecture and implementation, property= =20 >>>>>>>> might be >>>>>>>> signalled or preprovisioned. Of course, G.711 companding law is = an >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> inherent >>>>>>> >>>>>>>> property of your DS0 channel at your PDH/SDH/SONET framer; the=20 >>>>>>>> way, how >>>>>>>> this DS0 property is associated with the corresponding H.248 TDM >>>>>>>> Termination property may only realized MG-internally for very=20 >>>>>>>> specific MG >>>>>>>> architectures. Generally it is up to the MGC, particularly if=20 >>>>>>>> some (or >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> all) >>>>>>> >>>>>>>> DS0's are ISDN B channels.] >>>>>>>> >>>>>>>> (2) Voiceband Data services: same as in (1) >>>>>>>> >>>>>>>> [Note: VBD according new ITU-T V.152 -> "... For purposes of >>>>>>>> interoperability, a V.152 compliant implementation shall support= =20 >>>>>>>> at least >>>>>>>> both G.711 A-law and G.711 =C3=AC-law codecs as VBD codecs. "] >>>>>>>> >>>>>>>> (3) ISDN UDI =3D all ISDN Teleservices with ISDN I.231. bearer=20 >>>>>>>> service >>>>>>>> requirement >>>>>>>> =3D> H.248 TDM Termination property must be signalled by MGC, if= =20 >>>>>>>> not, MG >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> may >>>>>>> >>>>>>>> not guarantee UDI capability (i.e., fully transparent 64-kbit/s=20 >>>>>>>> bearer >>>>>>>> channel) in TDM hairpinning scenarios ... >>>>>>>> >>>>>>>> >>>>>>>> Conclusion: >>>>>>>> IF your MG is supporting >>>>>>>> PSTN lines (=3D H.248 ALN Termination), >>>>>>>> PSTN trunks (=3D H.248 TDM Termination), and >>>>>>>> ISDN B channels (=3D H.248 TDM Termination) >>>>>>>> >>>>>>>> AND IF you've such services and interworking requirements >>>>>>>> >>>>>>>> THEN you should generally signal the corresponding properties ... >>>>>>>> >>>>>>>> ... in case of >>>>>>>> TDM hairpinning, >>>>>>>> ALN hairpinning, or >>>>>>>> ALN-to-TDM connection types. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Albrecht >>>>>>>> >>>>>>>> ALCATEL >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>>> Zhao Bo >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> To: =20 >>>>>>>> megaco@ietf.org >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Sent by: cc: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> megaco-admin@iet Subject: [Megaco]=20 >>>>>>>> Hairpin >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> case A/u Law conversion >>>>>>> >>>>>>>> f.org >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> 25.02.2004 08:11 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> In this case, the A/u law format of a TDM ciruit can be=20 >>>>>>>> provisioned, but >>>>>>>> the MG doesn't know the service type of a call, thus >>>>>>>> has no way to know if a conversion is needed. For speech service >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> conversion >>>>>>> >>>>>>>> may be needed; for data service like isdn UDI, conversion is not >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> permitted. >>>>>>> >>>>>>>> Is there any method to solve this problem? >>>>>>>> >>>>>>>> Zhao Bo >>>>>>>> >>>>>>>> ****************************************************************= * >>>>>>>> This e-mail and its attachments contain confidential information= =20 >>>>>>>> from >>>>>>>> HUAWEI, which is intended only for the person or entity whose=20 >>>>>>>> address is >>>>>>>> listed above. Any use of the information contained herein in any= =20 >>>>>>>> way >>>>>>>> (including, but not limited to, total or partial disclosure, >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> reproduction, >>>>>>> >>>>>>>> or dissemination) by persons other than the intended=20 >>>>>>>> recipient(s) is >>>>>>>> prohibited. If you receive this e-mail in error, please notify=20 >>>>>>>> the sender >>>>>>>> by phone or email immediately and delete it! >>>>>>>> ****************************************************************= * >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Megaco mailing list >>>>>>>> Megaco@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/megaco >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Megaco mailing list >>>>>>>> Megaco@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/megaco >>>>>>>> 1=C3=A8=1Ar=E2=80=B0=C5=A1=C5=A0X=C2=A7=E2=80=9AX=C2=AC=C2=B4=C3= =87 i=C3=8A"z=C3=97=C3=A8=C2=AE=08m=C2=B6=E2=80=BA?=C3=BF=0C0=C3=96'=C2=AD= ~=C5=A0=C3=A0=C3=BEf=C2=A2=E2=80=93f=C2=A7=C3=BEX=C2=AC=C2=B6)=C3=9F=C2=A3= =C3=B9=C5=BE=EF=A2=9D=C2=A7( >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Megaco mailing list >>>>>> Megaco@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/megaco >>>>>> >>>>> >>>>> >>>>> This communication is confidential and intended solely for the=20 >>>>> addressee(s). Any unauthorized review, use, disclosure or=20 >>>>> distribution is prohibited. If you believe this message has been=20 >>>>> sent to you in error, please notify the sender by replying to this=20 >>>>> transmission and delete the message without disclosing it. Thank yo= u. >>>>> >>>>> E-mail including attachments is susceptible to data corruption,=20 >>>>> interruption, unauthorized amendment, tampering and viruses, and we= =20 >>>>> only send and receive e-mails on the basis that we are not liable=20 >>>>> for any such corruption, interception, amendment, tampering or=20 >>>>> viruses or any consequences thereof. >>>>> >>>>> >>>>> _______________________________________________ >>>>> Megaco mailing list >>>>> Megaco@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/megaco >>>>> >>>> >>> >>> >> >=20 >=20 > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco ------_=_NextPart_001_01C42D50.90DDD14A Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable RE: Signaling of UDI rsp Clearmode Bearer Service; Re: TDM = Hairpinning; Re: [Megaco] Hairpin case A/u Law conversion

I have to agree with Troy on this.  Annex C is = definitively for the binary encoding.  Text encoding should use = packages, or an appropriate SDP construct for communicating the = information.  Using .15 to allow SDP transport of Annex C is = dodging the problem (and creating its own as Troy has pointed out), = rather than solving it.  We should define a package that then = could make use of .15 if need be.

Kevin

-----Original Message-----
From: Troy Cauble [mailto:troy@bell-labs.com] =
Sent: Wednesday, April 28, 2004 10:52 AM
To: Christian Groves
Cc: Carsten Waitzmann; Taylor, Tom-PT = [CAR:5N00:EXCH]; Albrecht.Schwarz@alcatel.de; Zhao Bo; = megaco@ietf.org
Subject: Re: Signaling of UDI rsp Clearmode Bearer = Service; Re: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law = conversion

Christian,

The text name for Annex C is not missing.  Annex = C is *EXPLICITLY* for the binary encoding only.

        "The = protocol syntax for the binary format of the protocol is
        defined = in Annex A. Annex C specifies the encoding of the Local
        and = Remote descriptors for use with the binary format.

        A complete = ABNF of the text encoding of the protocol per RFC
        2234 is = given in Annex B. SDP is used as the encoding of the    =
        Local and = Remote descriptors for use with the text encoding as
        modified = in 7.1.8."

H.248.15 is designed to allow Packages to add = parameters to the text encoding of the Local and Remote = descriptors.  Annex C is not a Package.

Isn't the real solution here to make a proper Package = that handles TMR and related parameters for both text and binary = encoding???



This mod would allow recursion in both = encodings:

        a=3Dh248:AnxC/SDP_A=3Dh248:AnxC/SDP_A=3Dh248:AnxC/SDP_A=3D.....= .


Now I'm going to go too far and really alienate = people:

On an as needed basis, portions of Annex C should be = deprecated and
replaced with proper packages.  The package = writers could even tell us
which descriptors to use the parameters in, = something Annex C never did.


-troy




Christian Groves wrote:

> Hello Carsten,
>
> Seems you have a very good point. The text name = for Annex C is missing.
> I propose using "AnxC". Or is there = another suggestion?
>
> I will put this in a contribution for the = upcoming ITU SG16 meeting.
>
> Regards, Christian
>
> Carsten Waitzmann wrote:
>
>> Hello Christian,
>>
>> thanks for the information. I am still = missing one piece:
>>
>> In case of textual encoding, what = <package name> should be used for
>> the media stream properties described in = H.248.1 Annex C?
>>
>> a=3Dh248item:<??>/TMR =3D 40
>>
>> thanks.
>> Carsten
>>
>> Christian Groves wrote:
>>
>>> Hello Carsten,
>>>
>>> Yes this is what I had in mind. The = package ID for Annex C is 0.
>>>
>>> ie. H.248.1 Annex A
>>> PkgdName ::=3D OCTET = STRING(SIZE(4))
>>> -- represents Package Name (2 octets) = plus Property, Event,
>>> -- Signal Names or Statistics ID. (2 = octets)
>>> -- To wildcard a package use 0xFFFF for = first two octets, choose
>>> -- is not allowed. To reference native = property tag specified in
>>> -- Annex C, use 0x0000 as first two = octets.
>>>
>>> Regards, Christian
>>>
>>> Carsten Waitzmann wrote:
>>>
>>>> Hello Christian,
>>>>
>>>> I took your suggestion as a basis = for the following example:
>>>>
>>>> MGC -> MG:
>>>> MEGACO / 1 [1.2.3.4]
>>>> Transaction =3D 100 {
>>>>    Context =3D = $  { Add =3D TDM1 {
>>>>        = ;            = ;            = ;       Media  {
>>>>        = ;            = ;            = ;            = ;  LocalControl {Mode =3D
>>>> SendReceive},
>>>>        = ;            = ;            = ;            = ;  Local {a=3Dh248item:TMR =3D
>>>> 0000 0010}}
>>>>        = ;            = ;            = ; }}}
>>>>
>>>> MG -> MGC
>>>> MEGACO / 1 [1.2.3.5]
>>>> Reply =3D 100 {
>>>>    Context =3D 1 = {
>>>>        = ;            = ;          Add =3D TDM1 = {
>>>>        = ;            = ;            = ;           = Media  {
>>>>        = ;            = ;            = ;            = ;    Local {a=3Dh248item:TMR
>>>> =3D 00000010}
>>>>        = ;            = ;            = ;            = ;           = }}}}
>>>>
>>>> Is this usage in line to what you = have in mind?
>>>> H.248.15 specifies: = a=3Dh248item:<package name>/<property name> =3D
>>>> <value>. For H.248.1 C.9 I do = not know which package applies to
>>>> property TMR. But H.248.15 states = "To enable the carriage of package
>>>> defined properties in the local and = remote descriptors of the text
>>>> encoded H.248.1 protocol the = Package attribute shall be used" thus I
>>>> am wondering whether a package name = isn't mandatory?
>>>>
>>>> Thanks  a lot!
>>>>
>>>> Carsten
>>>>
>>>> Alcatel
>>>>
>>>> Christian Groves wrote:
>>>>
>>>>> Hello Tom and Albrecht,
>>>>>
>>>>> What peice of information do = you want to signal explicitely?
>>>>> Doesn't TMR allow you to = specify 64Kbit UDI? If so then its
>>>>> supported by H.248.1 Annex C.9. = For H.248 text users this (or any
>>>>> element in Annex C) can be = tranferred via H.248.15. Alternatively
>>>>> Q.1950 sect 5.7.1.2 specifies = an equivalent encoding.
>>>>>
>>>>> Regards, Christian
>>>>>
>>>>> Tom Taylor wrote:
>>>>>
>>>>>> I intended a reference to = draft-ietf-avt-rtp-clearmode-04.txt in
>>>>>> my intervention.  My = old draft has been allowed to expire because
>>>>>> it did not seem to be of = much interest to the community.
>>>>>>
>>>>>> You are right: the draft = just referred to doesn't apply to TDM,
>>>>>> only to the packet = side.  I wasn't thinking.  I agree that in the
>>>>>> absence of the attributes = provided in my old draft, TDM bearer
>>>>>> characteristics are assumed = rather than signalled explicitly.
>>>>>>
>>>>>> Albrecht.Schwarz@alcatel.de = wrote:
>>>>>>
>>>>>>> I think that the = question is, whether this specific TDM bearer
>>>>>>> capability
>>>>>>> should be (1) = explicitly signalled, or whether (2) implicit
>>>>>>> assumption is
>>>>>>> already = sufficient.
>>>>>>>
>>>>>>> With regard to (1), = Tom, I guess that your refer to
>>>>>>>
>>>>>>> * RTP/CLEARMODE
>>>>>>>   RTP payload = format for a 64 kbit/s transparent call
>>>>>>>  
>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp= -clearmode-04.txt
>>>>>>>
>>>>>>>
>>>>>>> But, this coming RFC = may not be directly applied, e.g.,
>>>>>>> packetization = time
>>>>>>> parameter isn't = applicable IMHO. Pls correct me if wrong.
>>>>>>>
>>>>>>> Or do you refer to your = proposals in your expired draft wrt
>>>>>>> * TDM/CLEARMODE
>>>>>>>   Conventions = for the use of the Session Description Protocol (SDP)
>>>>>>>   for Digital = Circuit Connections
>>>>>>>  
>>>>>>> http://www.watersprings.org/pub/id/draft-taylor-mmusic= -sdp-tdm-01.txt
>>>>>>>
>>>>>>>
>>>>>>> My conclusion is, that = an explicit signalling method doesn't
>>>>>>> exist today
>>>>>>> ("exception might = be Q.1950").
>>>>>>> Even though, an = explicit TDM Media Descriptor for I.231.1  might
>>>>>>> be helpful
>>>>>>> for unambigously = specification in certain MG implementations.
>>>>>>>
>>>>>>>
>>>>>>> With regard to = (2):
>>>>>>> Implicit signaling is = in my understanding the situation of today.
>>>>>>> In case
>>>>>>> of, (a) missing TDM = Media Descriptors, or (b) "identical TDM Media
>>>>>>> Descriptors with = transparent channel indications", when a
>>>>>>> transparent
>>>>>>> 64-kbit/s bearer = connection may be established.
>>>>>>> Sometimes this is also = called "native TDM switching", or "native TDM
>>>>>>> hairpinning", but = technically it is exactly representing an ISDN
>>>>>>> B channel
>>>>>>> with I.231.1 bearer = service. [=3D> the channel may bypass the DSP,
>>>>>>> but in
>>>>>>> case that a DSP is = looped-in, then must be the DSP channel
>>>>>>> operation mode
>>>>>>> configured for = 'Clearmode']
>>>>>>>
>>>>>>> Last comment:
>>>>>>> Such kind of implicit = signalling mechanism is often assumed in telco
>>>>>>> industry, because this = is the legacy signaling mechanism within a
>>>>>>> TDM
>>>>>>> switch ("if there = aren't any signaled bearer capabilities then
>>>>>>> transparent
>>>>>>> channel; any needed = bearer capability in addition must be explicitly
>>>>>>> signalled, like signal = processing network equipment functions,
>>>>>>> e.g., EC").
>>>>>>>
>>>>>>> TDM hairpinning means, = an "H.248-controlled TDM switching
>>>>>>> function" = from
>>>>>>> H.248 Media Gateway = perspective. Hence, this implicit signalling
>>>>>>> assumption
>>>>>>> may be still valid, or = do you see any needs for explicit signaling
>>>>>>> codepoints in case of = TDM-to-TDM ISDN I.231.1 calls?
>>>>>>>
>>>>>>> Regards
>>>>>>>
>>>>>>> Albrecht
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>      = ;            = ;            = ;            = ;            = ;            = ;            = ;            = ;            = ;            = ;            = ;            = ;           =

>>>>>>>      = ;            = ;     Tom
>>>>>>> = Taylor           =             =             =             =             =             =             =             =             =         

>>>>>>>      = ;            = ;     = <taylor@nortelne         = To:      Zhao Bo
>>>>>>> = <zbo@huawei.com>        &n= bsp;           &n= bsp;           &n= bsp;           &n= bsp;           &n= bsp;           =
>>>>>>>      = ;            = ;     = tworks.com>         &nbs= p;    cc:      Albrecht
>>>>>>> = SCHWARZ/DE/ALCATEL@ALCATEL,
>>>>>>> = megaco@ietf.org         &nb= sp;           &nb= sp;           &nb= sp;     
>>>>>>>      = ;            = ;            = ;            = ;      Subject: Re: TDM
>>>>>>> Hairpinning; Re: = [Megaco] Hairpin case A/u Law
>>>>>>> = conversion          &n= bsp;           &n= bsp;           &n= bsp;           &n= bsp; 
>>>>>>> 26.02.2004
>>>>>>> = 14:05           &= nbsp;           &= nbsp;           &= nbsp;           &= nbsp;           &= nbsp;           &= nbsp;           &= nbsp;           &= nbsp;           &= nbsp; 

>>>>>>>      = ;            = ;            = ;            = ;            = ;            = ;            = ;            = ;            = ;            = ;            = ;            = ;           =

>>>>>>>      = ;            = ;            = ;            = ;            = ;            = ;            = ;            = ;            = ;            = ;            = ;            = ;           =

>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I think you would do it = by specifying the CLEARMODE codec in the
>>>>>>> Local and
>>>>>>> Remote
>>>>>>> descriptors.  = Unfortunately, CLEARMODE is still under
>>>>>>> consideration by = the
>>>>>>> IESG
>>>>>>> and hasn't reached RFC = status.
>>>>>>>
>>>>>>> Zhao Bo wrote:
>>>>>>>
>>>>>>>> Dear = Albrecht:
>>>>>>>>    = Is there any H.248 package defined to signal the UDI
>>>>>>>> transparency
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> properties in TDM = hairping case?
>>>>>>>
>>>>>>>>    = Best regards
>>>>>>>>
>>>>>>>> ----- Original = Message -----
>>>>>>>> From: = <Albrecht.Schwarz@alcatel.de>
>>>>>>>> To: "Zhao = Bo" <zbo@huawei.com>
>>>>>>>> Cc: = <megaco@ietf.org>; <megaco-admin@ietf.org>
>>>>>>>> Sent: Wednesday, = February 25, 2004 10:24 PM
>>>>>>>> Subject: TDM = Hairpinning; Re: [Megaco] Hairpin case A/u Law
>>>>>>>> conversion
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Dear Zhao = Bo,
>>>>>>>>
>>>>>>>> because there isn't = any "hairpinning" definition in MEGACOP/H.248
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> standards
>>>>>>>
>>>>>>>> ("please = correct if I'm wrong"), I'd like to use the following
>>>>>>>> one for
>>>>>>>> responding your = questions:
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> = ************************************************************************= ***********
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Definition:
>>>>>>>> TDM = Hairpinning
>>>>>>>> ? is a scenario = whereby a call is being made between two TDM
>>>>>>>> endpoints on
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> a
>>>>>>>
>>>>>>>>    = single media gateway. The media comes in on one TDM channel
>>>>>>>> and goes
>>>>>>>>    = out on another TDM channel through the use of an internal
>>>>>>>> loop in the
>>>>>>>>    = media gateway.
>>>>>>>>
>>>>>>>> Note 1: due to the = fact that there are local call types at local
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> exchanges
>>>>>>>
>>>>>>>> (CLASS5), and = transit exchanges (CLASS4) in legacy TDM networks
>>>>>>>> (PSTN,
>>>>>>>> NISDN, etc), there = is a variety of TDM-to-TDM connection types
>>>>>>>> behind the
>>>>>>>> general "TDM = hairpinning" capability (dependent on required type
>>>>>>>> of IWF,
>>>>>>>> etc.) in = corresponding H.248 MG types
>>>>>>>>
>>>>>>>> Note 2: = H.248/MEGCOP perspective
>>>>>>>> TDM Hairpinning =3D = Single H.248 Context with 2 H.248 TDM
>>>>>>>> Terminations
>>>>>>>>
>>>>>>>
>>>>>>> = ************************************************************************= ************
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Based on this = hairpinning understanding, my answers are:
>>>>>>>>
>>>>>>>> (1) Speech = telephony service: G.711 companding formats are a
>>>>>>>> property of
>>>>>>>> the corresponding = H.248 TDM termination
>>>>>>>>
>>>>>>>> [Note: dependent on = MG architecture and implementation, property
>>>>>>>> might be
>>>>>>>> signalled or = preprovisioned. Of course, G.711 companding law is an
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> inherent
>>>>>>>
>>>>>>>> property of your = DS0 channel at your PDH/SDH/SONET framer; the
>>>>>>>> way, how
>>>>>>>> this DS0 property = is associated with the corresponding H.248 TDM
>>>>>>>> Termination = property may only realized MG-internally for very
>>>>>>>> specific MG
>>>>>>>> architectures. = Generally it is up to the MGC, particularly if
>>>>>>>> some (or
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> all)
>>>>>>>
>>>>>>>> DS0's are ISDN B = channels.]
>>>>>>>>
>>>>>>>> (2) Voiceband Data = services: same as in (1)
>>>>>>>>
>>>>>>>> [Note: VBD = according new ITU-T V.152 -> "... For purposes of
>>>>>>>> interoperability, a = V.152 compliant implementation shall support
>>>>>>>> at least
>>>>>>>> both G.711 A-law = and G.711 =C3=AC-law codecs as VBD codecs. "]
>>>>>>>>
>>>>>>>> (3) ISDN UDI =3D = all ISDN Teleservices with ISDN I.231. bearer
>>>>>>>> service
>>>>>>>> requirement
>>>>>>>> =3D> H.248 TDM = Termination property must be signalled by MGC, if
>>>>>>>> not, MG
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> may
>>>>>>>
>>>>>>>> not guarantee UDI = capability (i.e., fully transparent 64-kbit/s
>>>>>>>> bearer
>>>>>>>> channel) in TDM = hairpinning scenarios ...
>>>>>>>>
>>>>>>>>
>>>>>>>> Conclusion:
>>>>>>>> IF your MG is = supporting
>>>>>>>> PSTN lines (=3D = H.248 ALN Termination),
>>>>>>>> PSTN trunks (=3D = H.248 TDM Termination), and
>>>>>>>> ISDN B channels = (=3D H.248 TDM Termination)
>>>>>>>>
>>>>>>>> AND IF you've such = services and interworking requirements
>>>>>>>>
>>>>>>>> THEN you should = generally signal the corresponding properties ...
>>>>>>>>
>>>>>>>> ... in case = of
>>>>>>>> TDM = hairpinning,
>>>>>>>> ALN hairpinning, = or
>>>>>>>> ALN-to-TDM = connection types.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Albrecht
>>>>>>>>
>>>>>>>> ALCATEL
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>     &= nbsp;           &= nbsp;    Zhao Bo
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>     &= nbsp;           &= nbsp;    = <zbo@huawei.com>         = To:     
>>>>>>>> = megaco@ietf.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>     &= nbsp;           &= nbsp;    Sent = by:           &nb= sp;     cc:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>     &= nbsp;           &= nbsp;    = megaco-admin@iet         = Subject: [Megaco]
>>>>>>>> Hairpin
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> case A/u Law = conversion
>>>>>>>
>>>>>>>>     &= nbsp;           &= nbsp;    f.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>     &= nbsp;           &= nbsp;    25.02.2004 08:11
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> In this case, the = A/u law format of a TDM ciruit can be
>>>>>>>> provisioned,  = but
>>>>>>>> the MG doesn't know = the service type of a call, thus
>>>>>>>> has no way to know = if a conversion is needed. For speech service
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> conversion
>>>>>>>
>>>>>>>> may be needed; for = data service like isdn UDI, conversion is not
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> permitted.
>>>>>>>
>>>>>>>> Is there any method = to solve this problem?
>>>>>>>>
>>>>>>>> Zhao Bo
>>>>>>>>
>>>>>>>> = *****************************************************************=
>>>>>>>> This e-mail and its = attachments contain confidential information
>>>>>>>> from
>>>>>>>> HUAWEI, which is = intended only for the person or entity whose
>>>>>>>> address is
>>>>>>>> listed above. Any = use of the information contained herein in any
>>>>>>>> way
>>>>>>>> (including, but not = limited to, total or partial disclosure,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> reproduction,
>>>>>>>
>>>>>>>> or dissemination) = by persons other than the intended
>>>>>>>> recipient(s) = is
>>>>>>>> prohibited. If you = receive this e-mail in error, please notify
>>>>>>>> the sender
>>>>>>>> by phone or email = immediately and delete it!
>>>>>>>> = *****************************************************************=
>>>>>>>>
>>>>>>>> = _______________________________________________
>>>>>>>> Megaco mailing = list
>>>>>>>> = Megaco@ietf.org
>>>>>>>> https://www1.ietf.org/mailman/listinfo/megaco
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> = _______________________________________________
>>>>>>>> Megaco mailing = list
>>>>>>>> = Megaco@ietf.org
>>>>>>>> https://www1.ietf.org/mailman/listinfo/megaco
>>>>>>>> = 1=C3=A8=1Ar=E2=80=B0=C5=A1=C5=A0X=C2=A7=E2=80=9AX=C2=AC=C2=B4=C3=87 = i=C3=8A"z=C3=97=C3=A8=C2=AE=08m=C2=B6=E2=80=BA?=C3=BF=0C0=C3=96'=C2= =AD~=C5=A0=C3=A0=C3=BEf=C2=A2=E2=80=93f=C2=A7=C3=BEX=C2=AC=C2=B6)=C3=9F=C2= =A3=C3=B9=C5=BE=EF=A2=9D=C2=A7(
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> = _______________________________________________
>>>>>> Megaco mailing list
>>>>>> Megaco@ietf.org
>>>>>> https://www1.ietf.org/mailman/listinfo/megaco
>>>>>>
>>>>>
>>>>>
>>>>> This communication is = confidential and intended solely for the
>>>>> addressee(s). Any unauthorized = review, use, disclosure or
>>>>> distribution is prohibited. If = you believe this message has been
>>>>> sent to you in error, please = notify the sender by replying to this
>>>>> transmission and delete the = message without disclosing it. Thank you.
>>>>>
>>>>> E-mail including attachments is = susceptible to data corruption,
>>>>> interruption, unauthorized = amendment, tampering and viruses, and we
>>>>> only send and receive e-mails = on the basis that we are not liable
>>>>> for any such corruption, = interception, amendment, tampering or
>>>>> viruses or any consequences = thereof.
>>>>>
>>>>>
>>>>> = _______________________________________________
>>>>> Megaco mailing list
>>>>> Megaco@ietf.org
>>>>> https://www1.ietf.org/mailman/listinfo/megaco
>>>>>
>>>>
>>>
>>>
>>
>
>
> = _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

------_=_NextPart_001_01C42D50.90DDD14A-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Apr 29 10:06:34 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03171 for ; Thu, 29 Apr 2004 10:06:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJC2D-0001sm-KJ; Thu, 29 Apr 2004 09:57:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBmz-0006E3-GK for megaco@optimus.ietf.org; Thu, 29 Apr 2004 09:41:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01550 for ; Thu, 29 Apr 2004 09:41:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJBmo-0002Aa-R8 for megaco@ietf.org; Thu, 29 Apr 2004 09:41:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJBlx-0001xk-00 for megaco@ietf.org; Thu, 29 Apr 2004 09:40:18 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1BJBlY-0001it-00 for megaco@ietf.org; Thu, 29 Apr 2004 09:39:52 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3TDdKd15825; Thu, 29 Apr 2004 09:39:20 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JCT8MKVA; Thu, 29 Apr 2004 09:39:21 -0400 Received: from nortelnetworks.com (abrw005n.ca.nortel.com [47.9.16.187]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JCVF1LLR; Thu, 29 Apr 2004 09:39:20 -0400 Message-ID: <40910582.1040007@nortelnetworks.com> Date: Thu, 29 Apr 2004 09:39:14 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Groves CC: megaco@ietf.org Subject: Re: [Megaco] Meaning of "support" for signals and events References: <408FFA01.5080905@nortelnetworks.com> <409036F7.60107@ericsson.com> In-Reply-To: <409036F7.60107@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by zcars0m9.nortelnetworks.com id i3TDdKd15825 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi. I assume this 501 error response means that the transaction fails, as usu= al. Christian Groves wrote: > Hello Tom, >=20 > I didn't realise the MSF was on at the moment... >=20 > As Troy said we discussed this recently on the list and it was agreed t= o=20 > add something to the IG. >=20 > Below is the text which I propose to clarify the issue: > 6.2.3 Packages > =85 > To support a particular package the MG must support all properties,=20 > signals, events and statistics defined in a package. It must also=20 > support all Signal and Event parameters. If the functionality behind=20 > these properties, signals, events and statistics is not implemented the= =20 > MG shall not return a syntax error or unknown ID for any of these=20 > elements but should return response 501 =93Not implemented=94. The MG m= ay=20 > support a subset of the values listed in a package for a particular=20 > Property or Parameter. >=20 >=20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Apr 29 10:10:28 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03644 for ; Thu, 29 Apr 2004 10:10:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJC2H-0001tC-1E; Thu, 29 Apr 2004 09:57:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBqq-0007HW-OB for megaco@optimus.ietf.org; Thu, 29 Apr 2004 09:45:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01614 for ; Thu, 29 Apr 2004 09:45:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJBqg-000332-26 for megaco@ietf.org; Thu, 29 Apr 2004 09:45:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJBpg-0002oV-00 for megaco@ietf.org; Thu, 29 Apr 2004 09:44:08 -0400 Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx with esmtp (Exim 4.12) id 1BJBoh-0002OA-00 for megaco@ietf.org; Thu, 29 Apr 2004 09:43:08 -0400 Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3TDgQ414371; Thu, 29 Apr 2004 09:42:26 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id J6N3YSCQ; Thu, 29 Apr 2004 09:42:26 -0400 Received: from nortelnetworks.com (abrw005n.ca.nortel.com [47.9.16.187]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JCVF1LLY; Thu, 29 Apr 2004 09:42:26 -0400 Message-ID: <4091063A.7010003@nortelnetworks.com> Date: Thu, 29 Apr 2004 09:42:18 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Groves CC: Troy Cauble , megaco@ietf.org Subject: Re: Signaling of UDI rsp Clearmode Bearer Service; Re: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversion References: <403E1760.2010903@nortelnetworks.com> <40427B92.3000707@ericsson.com> <406C2424.7050708@alcatel.de> <40720E2A.6070903@ericsson.com> <408D053E.2080405@alcatel.de> <408E24FA.2070303@ericsson.com> <408FC501.9040407@bell-labs.com> <408FF7B3.1070404@nortelnetworks.com> <40900008.2050703@bell-labs.com> <40903A8F.6050907@ericsson.com> In-Reply-To: <40903A8F.6050907@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit We can replicate the binary values for the TMR and USI, and reassign the packageId for them. However, if necessary, I can revive my I-D on SDP encoding of TMR/USI. I dropped it for lack of apparent interest. Christian Groves wrote: > Hello Troy, Tom and Kevin, > > I agree Annex C is not a package however it does use the same method of > referencing the properties ie. packageId/propertyID where in the binary > case the packageId is 0000. > > However USI and TMR is being used by implementations so we can't simply > deprecate Annex C as some seem to indicate. We have seen a case where > TMR/USI would be useful for text implementations. There are several > options here. As USI/TMR are already being used by binary > implementations it isn't appropriate to make changes to this, which > essentially a new package would be. This leaves modifications for the > text encoding. I thought the easiest way would be to use the H.248.15 to > carry the property, the side effect being a "packageID" would be needed. > This seemed to be simplest method, keeps it in the H.248 domain and is > in the WGs control. The other method would be to define SDP to carry the > octets for USI/TMR. This will muddy the water has people will think this > relates to SIP in some way. This will probably take some time to sort out. > > If we had our time again I would have prefered the use of packages only > (no Annex C/no SDP) ;). > > Regards, Christian > ... _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Apr 29 10:20:45 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04754 for ; Thu, 29 Apr 2004 10:20:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJCGz-0001ZQ-90 for megaco-archive@odin.ietf.org; Thu, 29 Apr 2004 10:12:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TECLR5006032 for megaco-archive@odin.ietf.org; Thu, 29 Apr 2004 10:12:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJC2c-0001xq-Bc for megaco-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 09:57:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02325 for ; Thu, 29 Apr 2004 09:57:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJC2R-00064l-Bu for megaco-web-archive@ietf.org; Thu, 29 Apr 2004 09:57:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJC1W-0005pD-00 for megaco-web-archive@ietf.org; Thu, 29 Apr 2004 09:56:27 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJC0m-0005aT-00 for megaco-web-archive@ietf.org; Thu, 29 Apr 2004 09:55:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBgs-0004Pd-3w; Thu, 29 Apr 2004 09:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIu3g-0008BX-6b for megaco@optimus.ietf.org; Wed, 28 Apr 2004 14:45:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06792 for ; Wed, 28 Apr 2004 14:45:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIu3c-0006RJ-3l for megaco@ietf.org; Wed, 28 Apr 2004 14:45:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIu2d-0006NA-00 for megaco@ietf.org; Wed, 28 Apr 2004 14:44:25 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1BIu1f-0006IW-00 for megaco@ietf.org; Wed, 28 Apr 2004 14:43:19 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3SIgZH13542; Wed, 28 Apr 2004 14:42:35 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Apr 2004 14:42:35 -0400 Message-ID: From: "Kevin Boyle" To: Troy Cauble , Christian Groves Cc: Carsten Waitzmann , "Tom-PT Taylor" , Albrecht.Schwarz@alcatel.de, Zhao Bo , megaco@ietf.org Subject: RE: Signaling of UDI rsp Clearmode Bearer Service; Re: TDM Hairpi nning; Re: [Megaco] Hairpin case A/u Law conversion Date: Wed, 28 Apr 2004 14:42:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42D50.90DDD14A" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 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_01C42D50.90DDD14A Content-Type: text/plain; charset="utf-8" X-MIME-Autoconverted: from 8bit to quoted-printable by zrtps06s.nortelnetworks.com id i3SIgZH13542 Content-Transfer-Encoding: quoted-printable I have to agree with Troy on this. Annex C is definitively for the binar= y encoding. Text encoding should use packages, or an appropriate SDP construct for communicating the information. Using .15 to allow SDP transport of Annex C is dodging the problem (and creating its own as Troy has pointed out), rather than solving it. We should define a package tha= t then could make use of .15 if need be. Kevin=20 -----Original Message----- From: Troy Cauble [mailto:troy@bell-labs.com]=20 Sent: Wednesday, April 28, 2004 10:52 AM To: Christian Groves Cc: Carsten Waitzmann; Taylor, Tom-PT [CAR:5N00:EXCH]; Albrecht.Schwarz@alcatel.de; Zhao Bo; megaco@ietf.org Subject: Re: Signaling of UDI rsp Clearmode Bearer Service; Re: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversion Christian, The text name for Annex C is not missing. Annex C is *EXPLICITLY* for th= e binary encoding only. "The protocol syntax for the binary format of the protocol is defined in Annex A. Annex C specifies the encoding of the Local and Remote descriptors for use with the binary format. A complete ABNF of the text encoding of the protocol per RFC 2234 is given in Annex B. SDP is used as the encoding of the =09 Local and Remote descriptors for use with the text encoding as modified in 7.1.8." H.248.15 is designed to allow Packages to add parameters to the text encoding of the Local and Remote descriptors. Annex C is not a Package. Isn't the real solution here to make a proper Package that handles TMR an= d related parameters for both text and binary encoding??? This mod would allow recursion in both encodings: a=3Dh248:AnxC/SDP_A=3Dh248:AnxC/SDP_A=3Dh248:AnxC/SDP_A=3D...... Now I'm going to go too far and really alienate people: On an as needed basis, portions of Annex C should be deprecated and=20 replaced with proper packages. The package writers could even tell us=20 which descriptors to use the parameters in, something Annex C never did. -troy Christian Groves wrote: > Hello Carsten, >=20 > Seems you have a very good point. The text name for Annex C is missing. > I propose using "AnxC". Or is there another suggestion? >=20 > I will put this in a contribution for the upcoming ITU SG16 meeting. >=20 > Regards, Christian >=20 > Carsten Waitzmann wrote: >=20 >> Hello Christian, >> >> thanks for the information. I am still missing one piece: >> >> In case of textual encoding, what should be used for=20 >> the media stream properties described in H.248.1 Annex C? >> >> a=3Dh248item:/TMR =3D 40 >> >> thanks. >> Carsten >> >> Christian Groves wrote: >> >>> Hello Carsten, >>> >>> Yes this is what I had in mind. The package ID for Annex C is 0. >>> >>> ie. H.248.1 Annex A >>> PkgdName ::=3D OCTET STRING(SIZE(4)) >>> -- represents Package Name (2 octets) plus Property, Event, >>> -- Signal Names or Statistics ID. (2 octets) >>> -- To wildcard a package use 0xFFFF for first two octets, choose >>> -- is not allowed. To reference native property tag specified in >>> -- Annex C, use 0x0000 as first two octets. >>> >>> Regards, Christian >>> >>> Carsten Waitzmann wrote: >>> >>>> Hello Christian, >>>> >>>> I took your suggestion as a basis for the following example: >>>> >>>> MGC -> MG: >>>> MEGACO / 1 [1.2.3.4] >>>> Transaction =3D 100 { >>>> Context =3D $ { Add =3D TDM1 { >>>> Media { >>>> LocalControl {Mode =3D=20 >>>> SendReceive}, >>>> Local {a=3Dh248item:TMR= =3D=20 >>>> 0000 0010}} >>>> }}} >>>> >>>> MG -> MGC >>>> MEGACO / 1 [1.2.3.5] >>>> Reply =3D 100 { >>>> Context =3D 1 { >>>> Add =3D TDM1 { >>>> Media { >>>> Local {a=3Dh248item:T= MR=20 >>>> =3D 00000010} >>>> }}}} >>>> >>>> Is this usage in line to what you have in mind? >>>> H.248.15 specifies: a=3Dh248item:/ =3D=20 >>>> . For H.248.1 C.9 I do not know which package applies to=20 >>>> property TMR. But H.248.15 states "To enable the carriage of package= =20 >>>> defined properties in the local and remote descriptors of the text=20 >>>> encoded H.248.1 protocol the Package attribute shall be used" thus I= =20 >>>> am wondering whether a package name isn't mandatory? >>>> >>>> Thanks a lot! >>>> >>>> Carsten >>>> >>>> Alcatel >>>> >>>> Christian Groves wrote: >>>> >>>>> Hello Tom and Albrecht, >>>>> >>>>> What peice of information do you want to signal explicitely?=20 >>>>> Doesn't TMR allow you to specify 64Kbit UDI? If so then its=20 >>>>> supported by H.248.1 Annex C.9. For H.248 text users this (or any=20 >>>>> element in Annex C) can be tranferred via H.248.15. Alternatively=20 >>>>> Q.1950 sect 5.7.1.2 specifies an equivalent encoding. >>>>> >>>>> Regards, Christian >>>>> >>>>> Tom Taylor wrote: >>>>> >>>>>> I intended a reference to draft-ietf-avt-rtp-clearmode-04.txt in=20 >>>>>> my intervention. My old draft has been allowed to expire because=20 >>>>>> it did not seem to be of much interest to the community. >>>>>> >>>>>> You are right: the draft just referred to doesn't apply to TDM,=20 >>>>>> only to the packet side. I wasn't thinking. I agree that in the=20 >>>>>> absence of the attributes provided in my old draft, TDM bearer=20 >>>>>> characteristics are assumed rather than signalled explicitly. >>>>>> >>>>>> Albrecht.Schwarz@alcatel.de wrote: >>>>>> >>>>>>> I think that the question is, whether this specific TDM bearer=20 >>>>>>> capability >>>>>>> should be (1) explicitly signalled, or whether (2) implicit=20 >>>>>>> assumption is >>>>>>> already sufficient. >>>>>>> >>>>>>> With regard to (1), Tom, I guess that your refer to >>>>>>> >>>>>>> * RTP/CLEARMODE >>>>>>> RTP payload format for a 64 kbit/s transparent call >>>>>>> =20 >>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-clearmode-04.txt=20 >>>>>>> >>>>>>> >>>>>>> But, this coming RFC may not be directly applied, e.g.,=20 >>>>>>> packetization time >>>>>>> parameter isn't applicable IMHO. Pls correct me if wrong. >>>>>>> >>>>>>> Or do you refer to your proposals in your expired draft wrt >>>>>>> * TDM/CLEARMODE >>>>>>> Conventions for the use of the Session Description Protocol (SD= P) >>>>>>> for Digital Circuit Connections >>>>>>> =20 >>>>>>> http://www.watersprings.org/pub/id/draft-taylor-mmusic-sdp-tdm-01.txt=20 >>>>>>> >>>>>>> >>>>>>> My conclusion is, that an explicit signalling method doesn't=20 >>>>>>> exist today >>>>>>> ("exception might be Q.1950"). >>>>>>> Even though, an explicit TDM Media Descriptor for I.231.1 might=20 >>>>>>> be helpful >>>>>>> for unambigously specification in certain MG implementations. >>>>>>> >>>>>>> >>>>>>> With regard to (2): >>>>>>> Implicit signaling is in my understanding the situation of today.= =20 >>>>>>> In case >>>>>>> of, (a) missing TDM Media Descriptors, or (b) "identical TDM Medi= a >>>>>>> Descriptors with transparent channel indications", when a=20 >>>>>>> transparent >>>>>>> 64-kbit/s bearer connection may be established. >>>>>>> Sometimes this is also called "native TDM switching", or "native = TDM >>>>>>> hairpinning", but technically it is exactly representing an ISDN=20 >>>>>>> B channel >>>>>>> with I.231.1 bearer service. [=3D> the channel may bypass the DSP= ,=20 >>>>>>> but in >>>>>>> case that a DSP is looped-in, then must be the DSP channel=20 >>>>>>> operation mode >>>>>>> configured for 'Clearmode'] >>>>>>> >>>>>>> Last comment: >>>>>>> Such kind of implicit signalling mechanism is often assumed in te= lco >>>>>>> industry, because this is the legacy signaling mechanism within a= =20 >>>>>>> TDM >>>>>>> switch ("if there aren't any signaled bearer capabilities then=20 >>>>>>> transparent >>>>>>> channel; any needed bearer capability in addition must be explici= tly >>>>>>> signalled, like signal processing network equipment functions,=20 >>>>>>> e.g., EC"). >>>>>>> >>>>>>> TDM hairpinning means, an "H.248-controlled TDM switching=20 >>>>>>> function" from >>>>>>> H.248 Media Gateway perspective. Hence, this implicit signalling=20 >>>>>>> assumption >>>>>>> may be still valid, or do you see any needs for explicit signalin= g >>>>>>> codepoints in case of TDM-to-TDM ISDN I.231.1 calls? >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Albrecht >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Tom=20 >>>>>>> Taylor >>>>>>> >>>>>> >>>>>>> tworks.com> cc: Albrecht=20 >>>>>>> SCHWARZ/DE/ALCATEL@ALCATEL,=20 >>>>>>> megaco@ietf.org =20 >>>>>>> Subject: Re: TDM=20 >>>>>>> Hairpinning; Re: [Megaco] Hairpin case A/u Law=20 >>>>>>> conversion =20 >>>>>>> 26.02.2004=20 >>>>>>> 14:05 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I think you would do it by specifying the CLEARMODE codec in the=20 >>>>>>> Local and >>>>>>> Remote >>>>>>> descriptors. Unfortunately, CLEARMODE is still under=20 >>>>>>> consideration by the >>>>>>> IESG >>>>>>> and hasn't reached RFC status. >>>>>>> >>>>>>> Zhao Bo wrote: >>>>>>> >>>>>>>> Dear Albrecht: >>>>>>>> Is there any H.248 package defined to signal the UDI=20 >>>>>>>> transparency >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> properties in TDM hairping case? >>>>>>> >>>>>>>> Best regards >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>> From: >>>>>>>> To: "Zhao Bo" >>>>>>>> Cc: ; >>>>>>>> Sent: Wednesday, February 25, 2004 10:24 PM >>>>>>>> Subject: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law=20 >>>>>>>> conversion >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Dear Zhao Bo, >>>>>>>> >>>>>>>> because there isn't any "hairpinning" definition in MEGACOP/H.24= 8 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> standards >>>>>>> >>>>>>>> ("please correct if I'm wrong"), I'd like to use the following=20 >>>>>>>> one for >>>>>>>> responding your questions: >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> *************************************************************************= *** *******=20 >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Definition: >>>>>>>> TDM Hairpinning >>>>>>>> ? is a scenario whereby a call is being made between two TDM=20 >>>>>>>> endpoints on >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> a >>>>>>> >>>>>>>> single media gateway. The media comes in on one TDM channel=20 >>>>>>>> and goes >>>>>>>> out on another TDM channel through the use of an internal=20 >>>>>>>> loop in the >>>>>>>> media gateway. >>>>>>>> >>>>>>>> Note 1: due to the fact that there are local call types at local >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> exchanges >>>>>>> >>>>>>>> (CLASS5), and transit exchanges (CLASS4) in legacy TDM networks=20 >>>>>>>> (PSTN, >>>>>>>> NISDN, etc), there is a variety of TDM-to-TDM connection types=20 >>>>>>>> behind the >>>>>>>> general "TDM hairpinning" capability (dependent on required type= =20 >>>>>>>> of IWF, >>>>>>>> etc.) in corresponding H.248 MG types >>>>>>>> >>>>>>>> Note 2: H.248/MEGCOP perspective >>>>>>>> TDM Hairpinning =3D Single H.248 Context with 2 H.248 TDM=20 >>>>>>>> Terminations >>>>>>>> >>>>>>> >>>>>>> *************************************************************************= *** ********=20 >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Based on this hairpinning understanding, my answers are: >>>>>>>> >>>>>>>> (1) Speech telephony service: G.711 companding formats are a=20 >>>>>>>> property of >>>>>>>> the corresponding H.248 TDM termination >>>>>>>> >>>>>>>> [Note: dependent on MG architecture and implementation, property= =20 >>>>>>>> might be >>>>>>>> signalled or preprovisioned. Of course, G.711 companding law is = an >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> inherent >>>>>>> >>>>>>>> property of your DS0 channel at your PDH/SDH/SONET framer; the=20 >>>>>>>> way, how >>>>>>>> this DS0 property is associated with the corresponding H.248 TDM >>>>>>>> Termination property may only realized MG-internally for very=20 >>>>>>>> specific MG >>>>>>>> architectures. Generally it is up to the MGC, particularly if=20 >>>>>>>> some (or >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> all) >>>>>>> >>>>>>>> DS0's are ISDN B channels.] >>>>>>>> >>>>>>>> (2) Voiceband Data services: same as in (1) >>>>>>>> >>>>>>>> [Note: VBD according new ITU-T V.152 -> "... For purposes of >>>>>>>> interoperability, a V.152 compliant implementation shall support= =20 >>>>>>>> at least >>>>>>>> both G.711 A-law and G.711 =C3=AC-law codecs as VBD codecs. "] >>>>>>>> >>>>>>>> (3) ISDN UDI =3D all ISDN Teleservices with ISDN I.231. bearer=20 >>>>>>>> service >>>>>>>> requirement >>>>>>>> =3D> H.248 TDM Termination property must be signalled by MGC, if= =20 >>>>>>>> not, MG >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> may >>>>>>> >>>>>>>> not guarantee UDI capability (i.e., fully transparent 64-kbit/s=20 >>>>>>>> bearer >>>>>>>> channel) in TDM hairpinning scenarios ... >>>>>>>> >>>>>>>> >>>>>>>> Conclusion: >>>>>>>> IF your MG is supporting >>>>>>>> PSTN lines (=3D H.248 ALN Termination), >>>>>>>> PSTN trunks (=3D H.248 TDM Termination), and >>>>>>>> ISDN B channels (=3D H.248 TDM Termination) >>>>>>>> >>>>>>>> AND IF you've such services and interworking requirements >>>>>>>> >>>>>>>> THEN you should generally signal the corresponding properties ... >>>>>>>> >>>>>>>> ... in case of >>>>>>>> TDM hairpinning, >>>>>>>> ALN hairpinning, or >>>>>>>> ALN-to-TDM connection types. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Albrecht >>>>>>>> >>>>>>>> ALCATEL >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>>> Zhao Bo >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> To: =20 >>>>>>>> megaco@ietf.org >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Sent by: cc: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> megaco-admin@iet Subject: [Megaco]=20 >>>>>>>> Hairpin >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> case A/u Law conversion >>>>>>> >>>>>>>> f.org >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> 25.02.2004 08:11 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> In this case, the A/u law format of a TDM ciruit can be=20 >>>>>>>> provisioned, but >>>>>>>> the MG doesn't know the service type of a call, thus >>>>>>>> has no way to know if a conversion is needed. For speech service >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> conversion >>>>>>> >>>>>>>> may be needed; for data service like isdn UDI, conversion is not >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> permitted. >>>>>>> >>>>>>>> Is there any method to solve this problem? >>>>>>>> >>>>>>>> Zhao Bo >>>>>>>> >>>>>>>> ****************************************************************= * >>>>>>>> This e-mail and its attachments contain confidential information= =20 >>>>>>>> from >>>>>>>> HUAWEI, which is intended only for the person or entity whose=20 >>>>>>>> address is >>>>>>>> listed above. Any use of the information contained herein in any= =20 >>>>>>>> way >>>>>>>> (including, but not limited to, total or partial disclosure, >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> reproduction, >>>>>>> >>>>>>>> or dissemination) by persons other than the intended=20 >>>>>>>> recipient(s) is >>>>>>>> prohibited. If you receive this e-mail in error, please notify=20 >>>>>>>> the sender >>>>>>>> by phone or email immediately and delete it! >>>>>>>> ****************************************************************= * >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Megaco mailing list >>>>>>>> Megaco@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/megaco >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Megaco mailing list >>>>>>>> Megaco@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/megaco >>>>>>>> 1=C3=A8=1Ar=E2=80=B0=C5=A1=C5=A0X=C2=A7=E2=80=9AX=C2=AC=C2=B4=C3= =87 i=C3=8A"z=C3=97=C3=A8=C2=AE=08m=C2=B6=E2=80=BA?=C3=BF=0C0=C3=96'=C2=AD= ~=C5=A0=C3=A0=C3=BEf=C2=A2=E2=80=93f=C2=A7=C3=BEX=C2=AC=C2=B6)=C3=9F=C2=A3= =C3=B9=C5=BE=EF=A2=9D=C2=A7( >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Megaco mailing list >>>>>> Megaco@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/megaco >>>>>> >>>>> >>>>> >>>>> This communication is confidential and intended solely for the=20 >>>>> addressee(s). Any unauthorized review, use, disclosure or=20 >>>>> distribution is prohibited. If you believe this message has been=20 >>>>> sent to you in error, please notify the sender by replying to this=20 >>>>> transmission and delete the message without disclosing it. Thank yo= u. >>>>> >>>>> E-mail including attachments is susceptible to data corruption,=20 >>>>> interruption, unauthorized amendment, tampering and viruses, and we= =20 >>>>> only send and receive e-mails on the basis that we are not liable=20 >>>>> for any such corruption, interception, amendment, tampering or=20 >>>>> viruses or any consequences thereof. >>>>> >>>>> >>>>> _______________________________________________ >>>>> Megaco mailing list >>>>> Megaco@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/megaco >>>>> >>>> >>> >>> >> >=20 >=20 > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco ------_=_NextPart_001_01C42D50.90DDD14A Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable RE: Signaling of UDI rsp Clearmode Bearer Service; Re: TDM = Hairpinning; Re: [Megaco] Hairpin case A/u Law conversion

I have to agree with Troy on this.  Annex C is = definitively for the binary encoding.  Text encoding should use = packages, or an appropriate SDP construct for communicating the = information.  Using .15 to allow SDP transport of Annex C is = dodging the problem (and creating its own as Troy has pointed out), = rather than solving it.  We should define a package that then = could make use of .15 if need be.

Kevin

-----Original Message-----
From: Troy Cauble [mailto:troy@bell-labs.com] =
Sent: Wednesday, April 28, 2004 10:52 AM
To: Christian Groves
Cc: Carsten Waitzmann; Taylor, Tom-PT = [CAR:5N00:EXCH]; Albrecht.Schwarz@alcatel.de; Zhao Bo; = megaco@ietf.org
Subject: Re: Signaling of UDI rsp Clearmode Bearer = Service; Re: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law = conversion

Christian,

The text name for Annex C is not missing.  Annex = C is *EXPLICITLY* for the binary encoding only.

        "The = protocol syntax for the binary format of the protocol is
        defined = in Annex A. Annex C specifies the encoding of the Local
        and = Remote descriptors for use with the binary format.

        A complete = ABNF of the text encoding of the protocol per RFC
        2234 is = given in Annex B. SDP is used as the encoding of the    =
        Local and = Remote descriptors for use with the text encoding as
        modified = in 7.1.8."

H.248.15 is designed to allow Packages to add = parameters to the text encoding of the Local and Remote = descriptors.  Annex C is not a Package.

Isn't the real solution here to make a proper Package = that handles TMR and related parameters for both text and binary = encoding???



This mod would allow recursion in both = encodings:

        a=3Dh248:AnxC/SDP_A=3Dh248:AnxC/SDP_A=3Dh248:AnxC/SDP_A=3D.....= .


Now I'm going to go too far and really alienate = people:

On an as needed basis, portions of Annex C should be = deprecated and
replaced with proper packages.  The package = writers could even tell us
which descriptors to use the parameters in, = something Annex C never did.


-troy




Christian Groves wrote:

> Hello Carsten,
>
> Seems you have a very good point. The text name = for Annex C is missing.
> I propose using "AnxC". Or is there = another suggestion?
>
> I will put this in a contribution for the = upcoming ITU SG16 meeting.
>
> Regards, Christian
>
> Carsten Waitzmann wrote:
>
>> Hello Christian,
>>
>> thanks for the information. I am still = missing one piece:
>>
>> In case of textual encoding, what = <package name> should be used for
>> the media stream properties described in = H.248.1 Annex C?
>>
>> a=3Dh248item:<??>/TMR =3D 40
>>
>> thanks.
>> Carsten
>>
>> Christian Groves wrote:
>>
>>> Hello Carsten,
>>>
>>> Yes this is what I had in mind. The = package ID for Annex C is 0.
>>>
>>> ie. H.248.1 Annex A
>>> PkgdName ::=3D OCTET = STRING(SIZE(4))
>>> -- represents Package Name (2 octets) = plus Property, Event,
>>> -- Signal Names or Statistics ID. (2 = octets)
>>> -- To wildcard a package use 0xFFFF for = first two octets, choose
>>> -- is not allowed. To reference native = property tag specified in
>>> -- Annex C, use 0x0000 as first two = octets.
>>>
>>> Regards, Christian
>>>
>>> Carsten Waitzmann wrote:
>>>
>>>> Hello Christian,
>>>>
>>>> I took your suggestion as a basis = for the following example:
>>>>
>>>> MGC -> MG:
>>>> MEGACO / 1 [1.2.3.4]
>>>> Transaction =3D 100 {
>>>>    Context =3D = $  { Add =3D TDM1 {
>>>>        = ;            = ;            = ;       Media  {
>>>>        = ;            = ;            = ;            = ;  LocalControl {Mode =3D
>>>> SendReceive},
>>>>        = ;            = ;            = ;            = ;  Local {a=3Dh248item:TMR =3D
>>>> 0000 0010}}
>>>>        = ;            = ;            = ; }}}
>>>>
>>>> MG -> MGC
>>>> MEGACO / 1 [1.2.3.5]
>>>> Reply =3D 100 {
>>>>    Context =3D 1 = {
>>>>        = ;            = ;          Add =3D TDM1 = {
>>>>        = ;            = ;            = ;           = Media  {
>>>>        = ;            = ;            = ;            = ;    Local {a=3Dh248item:TMR
>>>> =3D 00000010}
>>>>        = ;            = ;            = ;            = ;           = }}}}
>>>>
>>>> Is this usage in line to what you = have in mind?
>>>> H.248.15 specifies: = a=3Dh248item:<package name>/<property name> =3D
>>>> <value>. For H.248.1 C.9 I do = not know which package applies to
>>>> property TMR. But H.248.15 states = "To enable the carriage of package
>>>> defined properties in the local and = remote descriptors of the text
>>>> encoded H.248.1 protocol the = Package attribute shall be used" thus I
>>>> am wondering whether a package name = isn't mandatory?
>>>>
>>>> Thanks  a lot!
>>>>
>>>> Carsten
>>>>
>>>> Alcatel
>>>>
>>>> Christian Groves wrote:
>>>>
>>>>> Hello Tom and Albrecht,
>>>>>
>>>>> What peice of information do = you want to signal explicitely?
>>>>> Doesn't TMR allow you to = specify 64Kbit UDI? If so then its
>>>>> supported by H.248.1 Annex C.9. = For H.248 text users this (or any
>>>>> element in Annex C) can be = tranferred via H.248.15. Alternatively
>>>>> Q.1950 sect 5.7.1.2 specifies = an equivalent encoding.
>>>>>
>>>>> Regards, Christian
>>>>>
>>>>> Tom Taylor wrote:
>>>>>
>>>>>> I intended a reference to = draft-ietf-avt-rtp-clearmode-04.txt in
>>>>>> my intervention.  My = old draft has been allowed to expire because
>>>>>> it did not seem to be of = much interest to the community.
>>>>>>
>>>>>> You are right: the draft = just referred to doesn't apply to TDM,
>>>>>> only to the packet = side.  I wasn't thinking.  I agree that in the
>>>>>> absence of the attributes = provided in my old draft, TDM bearer
>>>>>> characteristics are assumed = rather than signalled explicitly.
>>>>>>
>>>>>> Albrecht.Schwarz@alcatel.de = wrote:
>>>>>>
>>>>>>> I think that the = question is, whether this specific TDM bearer
>>>>>>> capability
>>>>>>> should be (1) = explicitly signalled, or whether (2) implicit
>>>>>>> assumption is
>>>>>>> already = sufficient.
>>>>>>>
>>>>>>> With regard to (1), = Tom, I guess that your refer to
>>>>>>>
>>>>>>> * RTP/CLEARMODE
>>>>>>>   RTP payload = format for a 64 kbit/s transparent call
>>>>>>>  
>>>>>>> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp= -clearmode-04.txt
>>>>>>>
>>>>>>>
>>>>>>> But, this coming RFC = may not be directly applied, e.g.,
>>>>>>> packetization = time
>>>>>>> parameter isn't = applicable IMHO. Pls correct me if wrong.
>>>>>>>
>>>>>>> Or do you refer to your = proposals in your expired draft wrt
>>>>>>> * TDM/CLEARMODE
>>>>>>>   Conventions = for the use of the Session Description Protocol (SDP)
>>>>>>>   for Digital = Circuit Connections
>>>>>>>  
>>>>>>> http://www.watersprings.org/pub/id/draft-taylor-mmusic= -sdp-tdm-01.txt
>>>>>>>
>>>>>>>
>>>>>>> My conclusion is, that = an explicit signalling method doesn't
>>>>>>> exist today
>>>>>>> ("exception might = be Q.1950").
>>>>>>> Even though, an = explicit TDM Media Descriptor for I.231.1  might
>>>>>>> be helpful
>>>>>>> for unambigously = specification in certain MG implementations.
>>>>>>>
>>>>>>>
>>>>>>> With regard to = (2):
>>>>>>> Implicit signaling is = in my understanding the situation of today.
>>>>>>> In case
>>>>>>> of, (a) missing TDM = Media Descriptors, or (b) "identical TDM Media
>>>>>>> Descriptors with = transparent channel indications", when a
>>>>>>> transparent
>>>>>>> 64-kbit/s bearer = connection may be established.
>>>>>>> Sometimes this is also = called "native TDM switching", or "native TDM
>>>>>>> hairpinning", but = technically it is exactly representing an ISDN
>>>>>>> B channel
>>>>>>> with I.231.1 bearer = service. [=3D> the channel may bypass the DSP,
>>>>>>> but in
>>>>>>> case that a DSP is = looped-in, then must be the DSP channel
>>>>>>> operation mode
>>>>>>> configured for = 'Clearmode']
>>>>>>>
>>>>>>> Last comment:
>>>>>>> Such kind of implicit = signalling mechanism is often assumed in telco
>>>>>>> industry, because this = is the legacy signaling mechanism within a
>>>>>>> TDM
>>>>>>> switch ("if there = aren't any signaled bearer capabilities then
>>>>>>> transparent
>>>>>>> channel; any needed = bearer capability in addition must be explicitly
>>>>>>> signalled, like signal = processing network equipment functions,
>>>>>>> e.g., EC").
>>>>>>>
>>>>>>> TDM hairpinning means, = an "H.248-controlled TDM switching
>>>>>>> function" = from
>>>>>>> H.248 Media Gateway = perspective. Hence, this implicit signalling
>>>>>>> assumption
>>>>>>> may be still valid, or = do you see any needs for explicit signaling
>>>>>>> codepoints in case of = TDM-to-TDM ISDN I.231.1 calls?
>>>>>>>
>>>>>>> Regards
>>>>>>>
>>>>>>> Albrecht
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>      = ;            = ;            = ;            = ;            = ;            = ;            = ;            = ;            = ;            = ;            = ;            = ;           =

>>>>>>>      = ;            = ;     Tom
>>>>>>> = Taylor           =             =             =             =             =             =             =             =             =         

>>>>>>>      = ;            = ;     = <taylor@nortelne         = To:      Zhao Bo
>>>>>>> = <zbo@huawei.com>        &n= bsp;           &n= bsp;           &n= bsp;           &n= bsp;           &n= bsp;           =
>>>>>>>      = ;            = ;     = tworks.com>         &nbs= p;    cc:      Albrecht
>>>>>>> = SCHWARZ/DE/ALCATEL@ALCATEL,
>>>>>>> = megaco@ietf.org         &nb= sp;           &nb= sp;           &nb= sp;     
>>>>>>>      = ;            = ;            = ;            = ;      Subject: Re: TDM
>>>>>>> Hairpinning; Re: = [Megaco] Hairpin case A/u Law
>>>>>>> = conversion          &n= bsp;           &n= bsp;           &n= bsp;           &n= bsp; 
>>>>>>> 26.02.2004
>>>>>>> = 14:05           &= nbsp;           &= nbsp;           &= nbsp;           &= nbsp;           &= nbsp;           &= nbsp;           &= nbsp;           &= nbsp;           &= nbsp; 

>>>>>>>      = ;            = ;            = ;            = ;            = ;            = ;            = ;            = ;            = ;            = ;            = ;            = ;           =

>>>>>>>      = ;            = ;            = ;            = ;            = ;            = ;            = ;            = ;            = ;            = ;            = ;            = ;           =

>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I think you would do it = by specifying the CLEARMODE codec in the
>>>>>>> Local and
>>>>>>> Remote
>>>>>>> descriptors.  = Unfortunately, CLEARMODE is still under
>>>>>>> consideration by = the
>>>>>>> IESG
>>>>>>> and hasn't reached RFC = status.
>>>>>>>
>>>>>>> Zhao Bo wrote:
>>>>>>>
>>>>>>>> Dear = Albrecht:
>>>>>>>>    = Is there any H.248 package defined to signal the UDI
>>>>>>>> transparency
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> properties in TDM = hairping case?
>>>>>>>
>>>>>>>>    = Best regards
>>>>>>>>
>>>>>>>> ----- Original = Message -----
>>>>>>>> From: = <Albrecht.Schwarz@alcatel.de>
>>>>>>>> To: "Zhao = Bo" <zbo@huawei.com>
>>>>>>>> Cc: = <megaco@ietf.org>; <megaco-admin@ietf.org>
>>>>>>>> Sent: Wednesday, = February 25, 2004 10:24 PM
>>>>>>>> Subject: TDM = Hairpinning; Re: [Megaco] Hairpin case A/u Law
>>>>>>>> conversion
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Dear Zhao = Bo,
>>>>>>>>
>>>>>>>> because there isn't = any "hairpinning" definition in MEGACOP/H.248
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> standards
>>>>>>>
>>>>>>>> ("please = correct if I'm wrong"), I'd like to use the following
>>>>>>>> one for
>>>>>>>> responding your = questions:
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> = ************************************************************************= ***********
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Definition:
>>>>>>>> TDM = Hairpinning
>>>>>>>> ? is a scenario = whereby a call is being made between two TDM
>>>>>>>> endpoints on
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> a
>>>>>>>
>>>>>>>>    = single media gateway. The media comes in on one TDM channel
>>>>>>>> and goes
>>>>>>>>    = out on another TDM channel through the use of an internal
>>>>>>>> loop in the
>>>>>>>>    = media gateway.
>>>>>>>>
>>>>>>>> Note 1: due to the = fact that there are local call types at local
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> exchanges
>>>>>>>
>>>>>>>> (CLASS5), and = transit exchanges (CLASS4) in legacy TDM networks
>>>>>>>> (PSTN,
>>>>>>>> NISDN, etc), there = is a variety of TDM-to-TDM connection types
>>>>>>>> behind the
>>>>>>>> general "TDM = hairpinning" capability (dependent on required type
>>>>>>>> of IWF,
>>>>>>>> etc.) in = corresponding H.248 MG types
>>>>>>>>
>>>>>>>> Note 2: = H.248/MEGCOP perspective
>>>>>>>> TDM Hairpinning =3D = Single H.248 Context with 2 H.248 TDM
>>>>>>>> Terminations
>>>>>>>>
>>>>>>>
>>>>>>> = ************************************************************************= ************
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Based on this = hairpinning understanding, my answers are:
>>>>>>>>
>>>>>>>> (1) Speech = telephony service: G.711 companding formats are a
>>>>>>>> property of
>>>>>>>> the corresponding = H.248 TDM termination
>>>>>>>>
>>>>>>>> [Note: dependent on = MG architecture and implementation, property
>>>>>>>> might be
>>>>>>>> signalled or = preprovisioned. Of course, G.711 companding law is an
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> inherent
>>>>>>>
>>>>>>>> property of your = DS0 channel at your PDH/SDH/SONET framer; the
>>>>>>>> way, how
>>>>>>>> this DS0 property = is associated with the corresponding H.248 TDM
>>>>>>>> Termination = property may only realized MG-internally for very
>>>>>>>> specific MG
>>>>>>>> architectures. = Generally it is up to the MGC, particularly if
>>>>>>>> some (or
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> all)
>>>>>>>
>>>>>>>> DS0's are ISDN B = channels.]
>>>>>>>>
>>>>>>>> (2) Voiceband Data = services: same as in (1)
>>>>>>>>
>>>>>>>> [Note: VBD = according new ITU-T V.152 -> "... For purposes of
>>>>>>>> interoperability, a = V.152 compliant implementation shall support
>>>>>>>> at least
>>>>>>>> both G.711 A-law = and G.711 =C3=AC-law codecs as VBD codecs. "]
>>>>>>>>
>>>>>>>> (3) ISDN UDI =3D = all ISDN Teleservices with ISDN I.231. bearer
>>>>>>>> service
>>>>>>>> requirement
>>>>>>>> =3D> H.248 TDM = Termination property must be signalled by MGC, if
>>>>>>>> not, MG
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> may
>>>>>>>
>>>>>>>> not guarantee UDI = capability (i.e., fully transparent 64-kbit/s
>>>>>>>> bearer
>>>>>>>> channel) in TDM = hairpinning scenarios ...
>>>>>>>>
>>>>>>>>
>>>>>>>> Conclusion:
>>>>>>>> IF your MG is = supporting
>>>>>>>> PSTN lines (=3D = H.248 ALN Termination),
>>>>>>>> PSTN trunks (=3D = H.248 TDM Termination), and
>>>>>>>> ISDN B channels = (=3D H.248 TDM Termination)
>>>>>>>>
>>>>>>>> AND IF you've such = services and interworking requirements
>>>>>>>>
>>>>>>>> THEN you should = generally signal the corresponding properties ...
>>>>>>>>
>>>>>>>> ... in case = of
>>>>>>>> TDM = hairpinning,
>>>>>>>> ALN hairpinning, = or
>>>>>>>> ALN-to-TDM = connection types.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Albrecht
>>>>>>>>
>>>>>>>> ALCATEL
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>     &= nbsp;           &= nbsp;    Zhao Bo
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>     &= nbsp;           &= nbsp;    = <zbo@huawei.com>         = To:     
>>>>>>>> = megaco@ietf.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>     &= nbsp;           &= nbsp;    Sent = by:           &nb= sp;     cc:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>     &= nbsp;           &= nbsp;    = megaco-admin@iet         = Subject: [Megaco]
>>>>>>>> Hairpin
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> case A/u Law = conversion
>>>>>>>
>>>>>>>>     &= nbsp;           &= nbsp;    f.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>     &= nbsp;           &= nbsp;    25.02.2004 08:11
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> In this case, the = A/u law format of a TDM ciruit can be
>>>>>>>> provisioned,  = but
>>>>>>>> the MG doesn't know = the service type of a call, thus
>>>>>>>> has no way to know = if a conversion is needed. For speech service
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> conversion
>>>>>>>
>>>>>>>> may be needed; for = data service like isdn UDI, conversion is not
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> permitted.
>>>>>>>
>>>>>>>> Is there any method = to solve this problem?
>>>>>>>>
>>>>>>>> Zhao Bo
>>>>>>>>
>>>>>>>> = *****************************************************************=
>>>>>>>> This e-mail and its = attachments contain confidential information
>>>>>>>> from
>>>>>>>> HUAWEI, which is = intended only for the person or entity whose
>>>>>>>> address is
>>>>>>>> listed above. Any = use of the information contained herein in any
>>>>>>>> way
>>>>>>>> (including, but not = limited to, total or partial disclosure,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> reproduction,
>>>>>>>
>>>>>>>> or dissemination) = by persons other than the intended
>>>>>>>> recipient(s) = is
>>>>>>>> prohibited. If you = receive this e-mail in error, please notify
>>>>>>>> the sender
>>>>>>>> by phone or email = immediately and delete it!
>>>>>>>> = *****************************************************************=
>>>>>>>>
>>>>>>>> = _______________________________________________
>>>>>>>> Megaco mailing = list
>>>>>>>> = Megaco@ietf.org
>>>>>>>> https://www1.ietf.org/mailman/listinfo/megaco
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> = _______________________________________________
>>>>>>>> Megaco mailing = list
>>>>>>>> = Megaco@ietf.org
>>>>>>>> https://www1.ietf.org/mailman/listinfo/megaco
>>>>>>>> = 1=C3=A8=1Ar=E2=80=B0=C5=A1=C5=A0X=C2=A7=E2=80=9AX=C2=AC=C2=B4=C3=87 = i=C3=8A"z=C3=97=C3=A8=C2=AE=08m=C2=B6=E2=80=BA?=C3=BF=0C0=C3=96'=C2= =AD~=C5=A0=C3=A0=C3=BEf=C2=A2=E2=80=93f=C2=A7=C3=BEX=C2=AC=C2=B6)=C3=9F=C2= =A3=C3=B9=C5=BE=EF=A2=9D=C2=A7(
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> = _______________________________________________
>>>>>> Megaco mailing list
>>>>>> Megaco@ietf.org
>>>>>> https://www1.ietf.org/mailman/listinfo/megaco
>>>>>>
>>>>>
>>>>>
>>>>> This communication is = confidential and intended solely for the
>>>>> addressee(s). Any unauthorized = review, use, disclosure or
>>>>> distribution is prohibited. If = you believe this message has been
>>>>> sent to you in error, please = notify the sender by replying to this
>>>>> transmission and delete the = message without disclosing it. Thank you.
>>>>>
>>>>> E-mail including attachments is = susceptible to data corruption,
>>>>> interruption, unauthorized = amendment, tampering and viruses, and we
>>>>> only send and receive e-mails = on the basis that we are not liable
>>>>> for any such corruption, = interception, amendment, tampering or
>>>>> viruses or any consequences = thereof.
>>>>>
>>>>>
>>>>> = _______________________________________________
>>>>> Megaco mailing list
>>>>> Megaco@ietf.org
>>>>> https://www1.ietf.org/mailman/listinfo/megaco
>>>>>
>>>>
>>>
>>>
>>
>
>
> = _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco


_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

------_=_NextPart_001_01C42D50.90DDD14A-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Apr 29 10:30:17 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05376 for ; Thu, 29 Apr 2004 10:30:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJCOj-0005yO-8Z for megaco-archive@odin.ietf.org; Thu, 29 Apr 2004 10:20:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TEKLrb022955 for megaco-archive@odin.ietf.org; Thu, 29 Apr 2004 10:20:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJCDF-0008FP-86 for megaco-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 10:08:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03358 for ; Thu, 29 Apr 2004 10:08:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJCD4-000137-CF for megaco-web-archive@ietf.org; Thu, 29 Apr 2004 10:08:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJCBy-0000nL-00 for megaco-web-archive@ietf.org; Thu, 29 Apr 2004 10:07:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJCAs-0000L9-00 for megaco-web-archive@ietf.org; Thu, 29 Apr 2004 10:06:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJC2D-0001sm-KJ; Thu, 29 Apr 2004 09:57:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBmz-0006E3-GK for megaco@optimus.ietf.org; Thu, 29 Apr 2004 09:41:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01550 for ; Thu, 29 Apr 2004 09:41:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJBmo-0002Aa-R8 for megaco@ietf.org; Thu, 29 Apr 2004 09:41:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJBlx-0001xk-00 for megaco@ietf.org; Thu, 29 Apr 2004 09:40:18 -0400 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1BJBlY-0001it-00 for megaco@ietf.org; Thu, 29 Apr 2004 09:39:52 -0400 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3TDdKd15825; Thu, 29 Apr 2004 09:39:20 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JCT8MKVA; Thu, 29 Apr 2004 09:39:21 -0400 Received: from nortelnetworks.com (abrw005n.ca.nortel.com [47.9.16.187]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JCVF1LLR; Thu, 29 Apr 2004 09:39:20 -0400 Message-ID: <40910582.1040007@nortelnetworks.com> Date: Thu, 29 Apr 2004 09:39:14 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Groves CC: megaco@ietf.org Subject: Re: [Megaco] Meaning of "support" for signals and events References: <408FFA01.5080905@nortelnetworks.com> <409036F7.60107@ericsson.com> In-Reply-To: <409036F7.60107@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by zcars0m9.nortelnetworks.com id i3TDdKd15825 Content-Transfer-Encoding: quoted-printable Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi. I assume this 501 error response means that the transaction fails, as usu= al. Christian Groves wrote: > Hello Tom, >=20 > I didn't realise the MSF was on at the moment... >=20 > As Troy said we discussed this recently on the list and it was agreed t= o=20 > add something to the IG. >=20 > Below is the text which I propose to clarify the issue: > 6.2.3 Packages > =85 > To support a particular package the MG must support all properties,=20 > signals, events and statistics defined in a package. It must also=20 > support all Signal and Event parameters. If the functionality behind=20 > these properties, signals, events and statistics is not implemented the= =20 > MG shall not return a syntax error or unknown ID for any of these=20 > elements but should return response 501 =93Not implemented=94. The MG m= ay=20 > support a subset of the values listed in a package for a particular=20 > Property or Parameter. >=20 >=20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Apr 29 10:30:42 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05473 for ; Thu, 29 Apr 2004 10:30:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJCOl-00060e-Bs for megaco-archive@odin.ietf.org; Thu, 29 Apr 2004 10:20:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TEKNxW023096 for megaco-archive@odin.ietf.org; Thu, 29 Apr 2004 10:20:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJCGE-00019t-RN for megaco-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 10:11:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03776 for ; Thu, 29 Apr 2004 10:11:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJCG3-0001q7-VP for megaco-web-archive@ietf.org; Thu, 29 Apr 2004 10:11:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJCFG-0001bV-00 for megaco-web-archive@ietf.org; Thu, 29 Apr 2004 10:10:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJCEe-0001LJ-00 for megaco-web-archive@ietf.org; Thu, 29 Apr 2004 10:09:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJC2H-0001tC-1E; Thu, 29 Apr 2004 09:57:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBqq-0007HW-OB for megaco@optimus.ietf.org; Thu, 29 Apr 2004 09:45:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01614 for ; Thu, 29 Apr 2004 09:45:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJBqg-000332-26 for megaco@ietf.org; Thu, 29 Apr 2004 09:45:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJBpg-0002oV-00 for megaco@ietf.org; Thu, 29 Apr 2004 09:44:08 -0400 Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx with esmtp (Exim 4.12) id 1BJBoh-0002OA-00 for megaco@ietf.org; Thu, 29 Apr 2004 09:43:08 -0400 Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3TDgQ414371; Thu, 29 Apr 2004 09:42:26 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id J6N3YSCQ; Thu, 29 Apr 2004 09:42:26 -0400 Received: from nortelnetworks.com (abrw005n.ca.nortel.com [47.9.16.187]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JCVF1LLY; Thu, 29 Apr 2004 09:42:26 -0400 Message-ID: <4091063A.7010003@nortelnetworks.com> Date: Thu, 29 Apr 2004 09:42:18 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Groves CC: Troy Cauble , megaco@ietf.org Subject: Re: Signaling of UDI rsp Clearmode Bearer Service; Re: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversion References: <403E1760.2010903@nortelnetworks.com> <40427B92.3000707@ericsson.com> <406C2424.7050708@alcatel.de> <40720E2A.6070903@ericsson.com> <408D053E.2080405@alcatel.de> <408E24FA.2070303@ericsson.com> <408FC501.9040407@bell-labs.com> <408FF7B3.1070404@nortelnetworks.com> <40900008.2050703@bell-labs.com> <40903A8F.6050907@ericsson.com> In-Reply-To: <40903A8F.6050907@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit We can replicate the binary values for the TMR and USI, and reassign the packageId for them. However, if necessary, I can revive my I-D on SDP encoding of TMR/USI. I dropped it for lack of apparent interest. Christian Groves wrote: > Hello Troy, Tom and Kevin, > > I agree Annex C is not a package however it does use the same method of > referencing the properties ie. packageId/propertyID where in the binary > case the packageId is 0000. > > However USI and TMR is being used by implementations so we can't simply > deprecate Annex C as some seem to indicate. We have seen a case where > TMR/USI would be useful for text implementations. There are several > options here. As USI/TMR are already being used by binary > implementations it isn't appropriate to make changes to this, which > essentially a new package would be. This leaves modifications for the > text encoding. I thought the easiest way would be to use the H.248.15 to > carry the property, the side effect being a "packageID" would be needed. > This seemed to be simplest method, keeps it in the H.248 domain and is > in the WGs control. The other method would be to define SDP to carry the > octets for USI/TMR. This will muddy the water has people will think this > relates to SIP in some way. This will probably take some time to sort out. > > If we had our time again I would have prefered the use of packages only > (no Annex C/no SDP) ;). > > Regards, Christian > ... _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Apr 29 11:03:13 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07768 for ; Thu, 29 Apr 2004 11:03:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJCoZ-0004xp-BG; Thu, 29 Apr 2004 10:47:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJCbW-0001BF-BK for megaco@optimus.ietf.org; Thu, 29 Apr 2004 10:33:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05737 for ; Thu, 29 Apr 2004 10:33:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJCbL-0007V0-5K for megaco@ietf.org; Thu, 29 Apr 2004 10:33:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJCaL-0007Du-00 for megaco@ietf.org; Thu, 29 Apr 2004 10:32:22 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1BJCZS-0006y0-00 for megaco@ietf.org; Thu, 29 Apr 2004 10:31:26 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i3TEVilI012746; Thu, 29 Apr 2004 07:31:44 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id i3TEVLk7032393; Thu, 29 Apr 2004 09:31:22 -0500 Message-Id: <5.2.1.1.0.20040429102420.04a84978@IL06EXM13.corp.mot.com> X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 29 Apr 2004 10:30:47 -0400 To: Kevin Boyle, Zhao Bo, From: Aleksandr Ryabin Subject: Re: [Megaco] Continuity tests In-Reply-To: <001201c42da8$c8678680$e4496e0a@HUAWEI.COM> References: <5.2.1.1.0.20040428135759.051e1498@IL06EXM13.corp.mot.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1739269607==.ALT" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --=====================_1739269607==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Packages defined in H.248.17 do not cover continuity tests. If the experts agree that MGC should be able to control type of continuity test then ether basic ct package needs to be amended to include new functionality, or H.248.17 needs to be amended to include new "extended" continuity package Commends? Suggestions? Aleks At 01:14 AM 4/29/2004, Zhao Bo wrote: >Can H.248.17 "line test packages" be used to test these circuits? >----- Original Message ----- >From: Aleksandr Ryabin >To: Kevin Boyle ; >megaco@ietf.org >Sent: Thursday, April 29, 2004 2:11 AM >Subject: RE: [Megaco] Continuity tests > >Yes, the type of test depends on what a circuit is connected to. > >But, I was actually coming from the view that MGC "controls" MG >and as such only MGC should have knowledge on what test to execute >(i.e. what is connected to the other side of a circuit). > >If this information is left in MG, then each circuit has to be provisioned >with that information such that MG can make intelligent decision on what >type of test to execute. Thus every time a circuit connection is changed, >directly or indirectly, MG circuit needs to be re-provisioned. > >I think that configuration should be kept on MGC and the decision should >come from MGC instead. > > Aleks > >At 02:30 PM 4/28/2004, Kevin Boyle wrote: > >>Is it possible to run more than one kind of continuity test on a >>particular circuit? If no, then the provisioning model holds and there >>is no need for a change. If yes, then we may need to add something to >>the package to allow selection of a ct test type. >> >>Kevin >> >>-----Original Message----- >>From: Aleksandr Ryabin >>[mailto:kengr@motorola.com] >>Sent: Wednesday, April 28, 2004 1:21 PM >>To: megaco@ietf.org >>Subject: [Megaco] Continuity tests >> >>Hi, >> >>There are several continuity test types (i.e 2-wire, 4-wire, etc) While >>provisioning of physical test parameters (i.e. frequencies, sequence, >>timeouts, etc) in MG makes sense, IMHO choosing a type of continuity test >>seem logical to be left to MGC. >> >>Basic Continuity Package (ct) does not allow to choose the type of a test. >>It implies that type of a test is provisioned on MG (per termination?) >> >>Is there another (extended) continuity test package which allows MGC to >>choose the type of a continuity test to be performed? >> >>If not, does anyone see a need to have such a package? >>Comments? >> >>Thanks >> Aleks >> >>_______________________________________________ >>Megaco mailing list >>Megaco@ietf.org >>https://www1.ietf.org/mailman/listinfo/megaco >> --=====================_1739269607==.ALT Content-Type: text/html; charset="us-ascii" Packages defined in H.248.17 do not cover continuity tests.

If the experts agree that MGC should be able to control type of continuity test
then ether basic ct package needs to be amended to include new functionality,
or H.248.17 needs to be amended to include new "extended" continuity package
Commends? Suggestions?

        Aleks

At 01:14 AM 4/29/2004, Zhao Bo wrote:
Can H.248.17 "line test packages"  be used to test these circuits?
----- Original Message -----
From: Aleksandr Ryabin
To: Kevin Boyle ; megaco@ietf.org
Sent: Thursday, April 29, 2004 2:11 AM
Subject: RE: [Megaco] Continuity tests

Yes, the type of test depends on what a circuit is connected to.

But, I was actually coming from the view that MGC "controls" MG
and as such only MGC should have knowledge on what test to execute
(i.e. what is connected to the other side of a circuit).

If this information is left in MG, then each circuit has to be provisioned
with that information such that MG can make intelligent decision on what
type of test to execute. Thus every time a circuit connection is changed,
directly or indirectly, MG circuit needs to be re-provisioned.

I think that configuration should  be kept on MGC and the decision should
come from MGC instead.

        Aleks

At 02:30 PM 4/28/2004, Kevin Boyle wrote:

Is it possible to run more than one kind of continuity test on a particular circuit?  If no, then the provisioning model holds and there is no need for a change.  If yes, then we may need to add something to the package to allow selection of a ct test type.

Kevin

-----Original Message-----
From: Aleksandr Ryabin [mailto:kengr@motorola.com]
Sent: Wednesday, April 28, 2004 1:21 PM
To: megaco@ietf.org
Subject: [Megaco] Continuity tests

Hi,

There are several continuity test types (i.e 2-wire, 4-wire, etc) While provisioning of physical test parameters (i.e. frequencies, sequence, timeouts, etc) in MG makes sense, IMHO choosing a type of continuity test seem logical to be left to MGC.

Basic Continuity Package (ct) does not allow to choose the type of a test.
It implies that type of a test is provisioned on MG (per termination?)

Is there another (extended) continuity test package which allows MGC to choose the type of a continuity test to be performed?

If not, does anyone see a need to have such a package?
Comments?

Thanks
        Aleks

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
--=====================_1739269607==.ALT-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Apr 29 11:29:48 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09130 for ; Thu, 29 Apr 2004 11:29:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDFx-0004RA-E1 for megaco-archive@odin.ietf.org; Thu, 29 Apr 2004 11:15:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TFFL4p017052 for megaco-archive@odin.ietf.org; Thu, 29 Apr 2004 11:15:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJD5d-0000rg-A1 for megaco-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 11:04:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07856 for ; Thu, 29 Apr 2004 11:04:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJD5S-0000YA-1P for megaco-web-archive@ietf.org; Thu, 29 Apr 2004 11:04:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJD4d-0000I2-00 for megaco-web-archive@ietf.org; Thu, 29 Apr 2004 11:03:40 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJD3h-00000o-00 for megaco-web-archive@ietf.org; Thu, 29 Apr 2004 11:02:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJCoZ-0004xp-BG; Thu, 29 Apr 2004 10:47:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJCbW-0001BF-BK for megaco@optimus.ietf.org; Thu, 29 Apr 2004 10:33:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05737 for ; Thu, 29 Apr 2004 10:33:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJCbL-0007V0-5K for megaco@ietf.org; Thu, 29 Apr 2004 10:33:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJCaL-0007Du-00 for megaco@ietf.org; Thu, 29 Apr 2004 10:32:22 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1BJCZS-0006y0-00 for megaco@ietf.org; Thu, 29 Apr 2004 10:31:26 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i3TEVilI012746; Thu, 29 Apr 2004 07:31:44 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id i3TEVLk7032393; Thu, 29 Apr 2004 09:31:22 -0500 Message-Id: <5.2.1.1.0.20040429102420.04a84978@IL06EXM13.corp.mot.com> X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 29 Apr 2004 10:30:47 -0400 To: Kevin Boyle, Zhao Bo, From: Aleksandr Ryabin Subject: Re: [Megaco] Continuity tests In-Reply-To: <001201c42da8$c8678680$e4496e0a@HUAWEI.COM> References: <5.2.1.1.0.20040428135759.051e1498@IL06EXM13.corp.mot.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1739269607==.ALT" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 --=====================_1739269607==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Packages defined in H.248.17 do not cover continuity tests. If the experts agree that MGC should be able to control type of continuity test then ether basic ct package needs to be amended to include new functionality, or H.248.17 needs to be amended to include new "extended" continuity package Commends? Suggestions? Aleks At 01:14 AM 4/29/2004, Zhao Bo wrote: >Can H.248.17 "line test packages" be used to test these circuits? >----- Original Message ----- >From: Aleksandr Ryabin >To: Kevin Boyle ; >megaco@ietf.org >Sent: Thursday, April 29, 2004 2:11 AM >Subject: RE: [Megaco] Continuity tests > >Yes, the type of test depends on what a circuit is connected to. > >But, I was actually coming from the view that MGC "controls" MG >and as such only MGC should have knowledge on what test to execute >(i.e. what is connected to the other side of a circuit). > >If this information is left in MG, then each circuit has to be provisioned >with that information such that MG can make intelligent decision on what >type of test to execute. Thus every time a circuit connection is changed, >directly or indirectly, MG circuit needs to be re-provisioned. > >I think that configuration should be kept on MGC and the decision should >come from MGC instead. > > Aleks > >At 02:30 PM 4/28/2004, Kevin Boyle wrote: > >>Is it possible to run more than one kind of continuity test on a >>particular circuit? If no, then the provisioning model holds and there >>is no need for a change. If yes, then we may need to add something to >>the package to allow selection of a ct test type. >> >>Kevin >> >>-----Original Message----- >>From: Aleksandr Ryabin >>[mailto:kengr@motorola.com] >>Sent: Wednesday, April 28, 2004 1:21 PM >>To: megaco@ietf.org >>Subject: [Megaco] Continuity tests >> >>Hi, >> >>There are several continuity test types (i.e 2-wire, 4-wire, etc) While >>provisioning of physical test parameters (i.e. frequencies, sequence, >>timeouts, etc) in MG makes sense, IMHO choosing a type of continuity test >>seem logical to be left to MGC. >> >>Basic Continuity Package (ct) does not allow to choose the type of a test. >>It implies that type of a test is provisioned on MG (per termination?) >> >>Is there another (extended) continuity test package which allows MGC to >>choose the type of a continuity test to be performed? >> >>If not, does anyone see a need to have such a package? >>Comments? >> >>Thanks >> Aleks >> >>_______________________________________________ >>Megaco mailing list >>Megaco@ietf.org >>https://www1.ietf.org/mailman/listinfo/megaco >> --=====================_1739269607==.ALT Content-Type: text/html; charset="us-ascii" Packages defined in H.248.17 do not cover continuity tests.

If the experts agree that MGC should be able to control type of continuity test
then ether basic ct package needs to be amended to include new functionality,
or H.248.17 needs to be amended to include new "extended" continuity package
Commends? Suggestions?

        Aleks

At 01:14 AM 4/29/2004, Zhao Bo wrote:
Can H.248.17 "line test packages"  be used to test these circuits?
----- Original Message -----
From: Aleksandr Ryabin
To: Kevin Boyle ; megaco@ietf.org
Sent: Thursday, April 29, 2004 2:11 AM
Subject: RE: [Megaco] Continuity tests

Yes, the type of test depends on what a circuit is connected to.

But, I was actually coming from the view that MGC "controls" MG
and as such only MGC should have knowledge on what test to execute
(i.e. what is connected to the other side of a circuit).

If this information is left in MG, then each circuit has to be provisioned
with that information such that MG can make intelligent decision on what
type of test to execute. Thus every time a circuit connection is changed,
directly or indirectly, MG circuit needs to be re-provisioned.

I think that configuration should  be kept on MGC and the decision should
come from MGC instead.

        Aleks

At 02:30 PM 4/28/2004, Kevin Boyle wrote:

Is it possible to run more than one kind of continuity test on a particular circuit?  If no, then the provisioning model holds and there is no need for a change.  If yes, then we may need to add something to the package to allow selection of a ct test type.

Kevin

-----Original Message-----
From: Aleksandr Ryabin [mailto:kengr@motorola.com]
Sent: Wednesday, April 28, 2004 1:21 PM
To: megaco@ietf.org
Subject: [Megaco] Continuity tests

Hi,

There are several continuity test types (i.e 2-wire, 4-wire, etc) While provisioning of physical test parameters (i.e. frequencies, sequence, timeouts, etc) in MG makes sense, IMHO choosing a type of continuity test seem logical to be left to MGC.

Basic Continuity Package (ct) does not allow to choose the type of a test.
It implies that type of a test is provisioned on MG (per termination?)

Is there another (extended) continuity test package which allows MGC to choose the type of a continuity test to be performed?

If not, does anyone see a need to have such a package?
Comments?

Thanks
        Aleks

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
--=====================_1739269607==.ALT-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Apr 29 11:45:17 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10025 for ; Thu, 29 Apr 2004 11:45:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDY2-0000RL-Jb; Thu, 29 Apr 2004 11:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDLi-0005rA-EP for megaco@optimus.ietf.org; Thu, 29 Apr 2004 11:21:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08830 for ; Thu, 29 Apr 2004 11:21:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJDLe-000576-69 for megaco@ietf.org; Thu, 29 Apr 2004 11:21:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJDKj-0004rx-00 for megaco@ietf.org; Thu, 29 Apr 2004 11:20:17 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1BJDJx-0004OT-00 for megaco@ietf.org; Thu, 29 Apr 2004 11:19:30 -0400 Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3TFIt012801; Thu, 29 Apr 2004 11:18:56 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id J6N3ZC3K; Thu, 29 Apr 2004 11:18:56 -0400 Received: from nortelnetworks.com (abrw005n.ca.nortel.com [47.9.16.187]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JCVF1L3X; Thu, 29 Apr 2004 11:18:56 -0400 Message-ID: <40911CDE.4060107@nortelnetworks.com> Date: Thu, 29 Apr 2004 11:18:54 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aleksandr Ryabin CC: Boyle Kevin , megaco@ietf.org Subject: Re: [Megaco] Continuity tests References: <5.2.1.1.0.20040428135759.051e1498@IL06EXM13.corp.mot.com> <5.2.1.1.0.20040429102420.04a84978@IL06EXM13.corp.mot.com> In-Reply-To: <5.2.1.1.0.20040429102420.04a84978@IL06EXM13.corp.mot.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I for one disagree with your philosophy. I think the physical details of the termination should be provisioned in the MG rather than the the MGC. However, I have no direct implementation responsibility, so I should let those who do speak up. Aleksandr Ryabin wrote: > Packages defined in H.248.17 do not cover continuity tests. > > If the experts agree that MGC should be able to control type of > continuity test > then ether basic ct package needs to be amended to include new > functionality, > or H.248.17 needs to be amended to include new "extended" continuity package > Commends? Suggestions? > > Aleks > > At 01:14 AM 4/29/2004, Zhao Bo wrote: > >> Can H.248.17 "line test packages" be used to test these circuits? >> >> ----- Original Message ----- >> From: Aleksandr Ryabin >> To: Kevin Boyle ; >> megaco@ietf.org >> Sent: Thursday, April 29, 2004 2:11 AM >> Subject: RE: [Megaco] Continuity tests >> >> Yes, the type of test depends on what a circuit is connected to. >> >> But, I was actually coming from the view that MGC "controls" MG >> and as such only MGC should have knowledge on what test to execute >> (i.e. what is connected to the other side of a circuit). >> >> If this information is left in MG, then each circuit has to be >> provisioned >> with that information such that MG can make intelligent decision >> on what >> type of test to execute. Thus every time a circuit connection is >> changed, >> directly or indirectly, MG circuit needs to be re-provisioned. >> >> I think that configuration should be kept on MGC and the decision >> should >> come from MGC instead. >> >> Aleks >> >> At 02:30 PM 4/28/2004, Kevin Boyle wrote: >> >>> Is it possible to run more than one kind of continuity test >>> on a particular circuit? If no, then the provisioning model >>> holds and there is no need for a change. If yes, then we may >>> need to add something to the package to allow selection of a >>> ct test type. >>> >>> Kevin >>> >>> -----Original Message----- >>> From: Aleksandr Ryabin [mailto:kengr@motorola.com] >>> Sent: Wednesday, April 28, 2004 1:21 PM >>> To: megaco@ietf.org >>> Subject: [Megaco] Continuity tests >>> >>> Hi, >>> >>> There are several continuity test types (i.e 2-wire, 4-wire, >>> etc) While provisioning of physical test parameters (i.e. >>> frequencies, sequence, timeouts, etc) in MG makes sense, IMHO >>> choosing a type of continuity test seem logical to be left to >>> MGC. >>> >>> Basic Continuity Package (ct) does not allow to choose the >>> type of a test. >>> It implies that type of a test is provisioned on MG (per >>> termination?) >>> >>> Is there another (extended) continuity test package which >>> allows MGC to choose the type of a continuity test to be >>> performed? >>> >>> If not, does anyone see a need to have such a package? >>> Comments? >>> >>> Thanks >>> Aleks >>> >>> _______________________________________________ >>> Megaco mailing list >>> Megaco@ietf.org >>> https://www1.ietf.org/mailman/listinfo/megaco >> _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Apr 29 11:52:56 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10494 for ; Thu, 29 Apr 2004 11:52:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDlD-000504-2a for megaco-archive@odin.ietf.org; Thu, 29 Apr 2004 11:47:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TFldBb019220 for megaco-archive@odin.ietf.org; Thu, 29 Apr 2004 11:47:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDjz-0004PF-QN for megaco-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 11:46:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10061 for ; Thu, 29 Apr 2004 11:46:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJDjv-0003yb-Ca for megaco-web-archive@ietf.org; Thu, 29 Apr 2004 11:46:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJDix-0003ii-00 for megaco-web-archive@ietf.org; Thu, 29 Apr 2004 11:45:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJDiP-0003TN-00 for megaco-web-archive@ietf.org; Thu, 29 Apr 2004 11:44:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDY2-0000RL-Jb; Thu, 29 Apr 2004 11:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDLi-0005rA-EP for megaco@optimus.ietf.org; Thu, 29 Apr 2004 11:21:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08830 for ; Thu, 29 Apr 2004 11:21:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJDLe-000576-69 for megaco@ietf.org; Thu, 29 Apr 2004 11:21:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJDKj-0004rx-00 for megaco@ietf.org; Thu, 29 Apr 2004 11:20:17 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1BJDJx-0004OT-00 for megaco@ietf.org; Thu, 29 Apr 2004 11:19:30 -0400 Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3TFIt012801; Thu, 29 Apr 2004 11:18:56 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id J6N3ZC3K; Thu, 29 Apr 2004 11:18:56 -0400 Received: from nortelnetworks.com (abrw005n.ca.nortel.com [47.9.16.187]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JCVF1L3X; Thu, 29 Apr 2004 11:18:56 -0400 Message-ID: <40911CDE.4060107@nortelnetworks.com> Date: Thu, 29 Apr 2004 11:18:54 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aleksandr Ryabin CC: Boyle Kevin , megaco@ietf.org Subject: Re: [Megaco] Continuity tests References: <5.2.1.1.0.20040428135759.051e1498@IL06EXM13.corp.mot.com> <5.2.1.1.0.20040429102420.04a84978@IL06EXM13.corp.mot.com> In-Reply-To: <5.2.1.1.0.20040429102420.04a84978@IL06EXM13.corp.mot.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I for one disagree with your philosophy. I think the physical details of the termination should be provisioned in the MG rather than the the MGC. However, I have no direct implementation responsibility, so I should let those who do speak up. Aleksandr Ryabin wrote: > Packages defined in H.248.17 do not cover continuity tests. > > If the experts agree that MGC should be able to control type of > continuity test > then ether basic ct package needs to be amended to include new > functionality, > or H.248.17 needs to be amended to include new "extended" continuity package > Commends? Suggestions? > > Aleks > > At 01:14 AM 4/29/2004, Zhao Bo wrote: > >> Can H.248.17 "line test packages" be used to test these circuits? >> >> ----- Original Message ----- >> From: Aleksandr Ryabin >> To: Kevin Boyle ; >> megaco@ietf.org >> Sent: Thursday, April 29, 2004 2:11 AM >> Subject: RE: [Megaco] Continuity tests >> >> Yes, the type of test depends on what a circuit is connected to. >> >> But, I was actually coming from the view that MGC "controls" MG >> and as such only MGC should have knowledge on what test to execute >> (i.e. what is connected to the other side of a circuit). >> >> If this information is left in MG, then each circuit has to be >> provisioned >> with that information such that MG can make intelligent decision >> on what >> type of test to execute. Thus every time a circuit connection is >> changed, >> directly or indirectly, MG circuit needs to be re-provisioned. >> >> I think that configuration should be kept on MGC and the decision >> should >> come from MGC instead. >> >> Aleks >> >> At 02:30 PM 4/28/2004, Kevin Boyle wrote: >> >>> Is it possible to run more than one kind of continuity test >>> on a particular circuit? If no, then the provisioning model >>> holds and there is no need for a change. If yes, then we may >>> need to add something to the package to allow selection of a >>> ct test type. >>> >>> Kevin >>> >>> -----Original Message----- >>> From: Aleksandr Ryabin [mailto:kengr@motorola.com] >>> Sent: Wednesday, April 28, 2004 1:21 PM >>> To: megaco@ietf.org >>> Subject: [Megaco] Continuity tests >>> >>> Hi, >>> >>> There are several continuity test types (i.e 2-wire, 4-wire, >>> etc) While provisioning of physical test parameters (i.e. >>> frequencies, sequence, timeouts, etc) in MG makes sense, IMHO >>> choosing a type of continuity test seem logical to be left to >>> MGC. >>> >>> Basic Continuity Package (ct) does not allow to choose the >>> type of a test. >>> It implies that type of a test is provisioned on MG (per >>> termination?) >>> >>> Is there another (extended) continuity test package which >>> allows MGC to choose the type of a continuity test to be >>> performed? >>> >>> If not, does anyone see a need to have such a package? >>> Comments? >>> >>> Thanks >>> Aleks >>> >>> _______________________________________________ >>> Megaco mailing list >>> Megaco@ietf.org >>> https://www1.ietf.org/mailman/listinfo/megaco >> _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Apr 29 12:03:26 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10950 for ; Thu, 29 Apr 2004 12:03:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDpk-0005rF-7S; Thu, 29 Apr 2004 11:52:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDQZ-0007GA-Ez for megaco@optimus.ietf.org; Thu, 29 Apr 2004 11:26:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09014 for ; Thu, 29 Apr 2004 11:26:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJDQV-0006QG-6H for megaco@ietf.org; Thu, 29 Apr 2004 11:26:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJDPU-00069R-00 for megaco@ietf.org; Thu, 29 Apr 2004 11:25:14 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1BJDOQ-0005eu-00 for megaco@ietf.org; Thu, 29 Apr 2004 11:24:06 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3TFNb029844; Thu, 29 Apr 2004 11:23:37 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 29 Apr 2004 11:23:38 -0400 Message-ID: From: "Kevin Boyle" To: "Tom-PT Taylor" , Aleksandr Ryabin Cc: megaco@ietf.org Subject: RE: [Megaco] Continuity tests Date: Thu, 29 Apr 2004 11:23:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42DFD.F04C18D2" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , 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_01C42DFD.F04C18D2 Content-Type: text/plain I agree with Tom. The fact that the circuit is connected to a single entity means that only a single type of continuity test is actually valid. MGs are expected to know how to handle their terminations. Who the termination is connected to is certainly part of that handling. Because the far-end connection changes the nature of the termination, this becomes an MG-knowledge problem. I believe the package is fine as it stands, and the MG should know what "run a continuity test" means for its terminations. Kevin -----Original Message----- From: Taylor, Tom-PT [CAR:5N00:EXCH] Sent: Thursday, April 29, 2004 11:19 AM To: Aleksandr Ryabin Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org Subject: Re: [Megaco] Continuity tests I for one disagree with your philosophy. I think the physical details of the termination should be provisioned in the MG rather than the the MGC. However, I have no direct implementation responsibility, so I should let those who do speak up. Aleksandr Ryabin wrote: > Packages defined in H.248.17 do not cover continuity tests. > > If the experts agree that MGC should be able to control type of > continuity test then ether basic ct package needs to be amended to > include new functionality, or H.248.17 needs to be amended to include > new "extended" continuity package Commends? Suggestions? > > Aleks > > At 01:14 AM 4/29/2004, Zhao Bo wrote: > >> Can H.248.17 "line test packages" be used to test these circuits? >> >> ----- Original Message ----- >> From: Aleksandr Ryabin >> To: Kevin Boyle ; >> megaco@ietf.org >> Sent: Thursday, April 29, 2004 2:11 AM >> Subject: RE: [Megaco] Continuity tests >> >> Yes, the type of test depends on what a circuit is connected to. >> >> But, I was actually coming from the view that MGC "controls" MG >> and as such only MGC should have knowledge on what test to execute >> (i.e. what is connected to the other side of a circuit). >> >> If this information is left in MG, then each circuit has to be >> provisioned >> with that information such that MG can make intelligent decision >> on what >> type of test to execute. Thus every time a circuit connection is >> changed, >> directly or indirectly, MG circuit needs to be re-provisioned. >> >> I think that configuration should be kept on MGC and the decision >> should >> come from MGC instead. >> >> Aleks >> >> At 02:30 PM 4/28/2004, Kevin Boyle wrote: >> >>> Is it possible to run more than one kind of continuity test >>> on a particular circuit? If no, then the provisioning model >>> holds and there is no need for a change. If yes, then we may >>> need to add something to the package to allow selection of a >>> ct test type. >>> >>> Kevin >>> >>> -----Original Message----- >>> From: Aleksandr Ryabin [mailto:kengr@motorola.com] >>> Sent: Wednesday, April 28, 2004 1:21 PM >>> To: megaco@ietf.org >>> Subject: [Megaco] Continuity tests >>> >>> Hi, >>> >>> There are several continuity test types (i.e 2-wire, 4-wire, >>> etc) While provisioning of physical test parameters (i.e. >>> frequencies, sequence, timeouts, etc) in MG makes sense, IMHO >>> choosing a type of continuity test seem logical to be left to >>> MGC. >>> >>> Basic Continuity Package (ct) does not allow to choose the >>> type of a test. >>> It implies that type of a test is provisioned on MG (per >>> termination?) >>> >>> Is there another (extended) continuity test package which >>> allows MGC to choose the type of a continuity test to be >>> performed? >>> >>> If not, does anyone see a need to have such a package? >>> Comments? >>> >>> Thanks >>> Aleks >>> >>> _______________________________________________ >>> Megaco mailing list >>> Megaco@ietf.org >>> https://www1.ietf.org/mailman/listinfo/megaco >> ------_=_NextPart_001_01C42DFD.F04C18D2 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Megaco] Continuity tests

I agree with Tom.  The fact that the circuit is = connected to a single entity means that only a single type of = continuity test is actually valid.  MGs are expected to know how = to handle their terminations.  Who the termination is connected to = is certainly part of that handling.  Because the far-end = connection changes the nature of the termination, this becomes an = MG-knowledge problem.

I believe the package is fine as it stands, and the = MG should know what "run a continuity test" means for its = terminations.

Kevin

-----Original Message-----
From: Taylor, Tom-PT [CAR:5N00:EXCH]
Sent: Thursday, April 29, 2004 11:19 AM
To: Aleksandr Ryabin
Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; = megaco@ietf.org
Subject: Re: [Megaco] Continuity tests

I for one disagree with your philosophy.  I = think the physical details of the termination should be provisioned in = the MG rather than the the MGC.  However, I have no direct = implementation responsibility, so I should let those who do speak = up.

Aleksandr Ryabin wrote:

> Packages defined in H.248.17 do not cover = continuity tests.
>
> If the experts agree that MGC should be able to = control type of
> continuity test then ether basic ct package = needs to be amended to
> include new functionality, or H.248.17 needs to = be amended to include
> new "extended" continuity package = Commends? Suggestions?
>
>         = Aleks
>
> At 01:14 AM 4/29/2004, Zhao Bo wrote:
>
>> Can H.248.17 "line test = packages"  be used to test these circuits?
>>
>>     ----- Original = Message -----
>>     From: Aleksandr = Ryabin <mailto:kengr@motorola.com>
>>     To: Kevin Boyle = <mailto:kboyle@nortelnetworks.c= om> ;
>>     megaco@ietf.org = <mailto:megaco@ietf.org>
>>     Sent: Thursday, = April 29, 2004 2:11 AM
>>     Subject: RE: = [Megaco] Continuity tests
>>
>>     Yes, the type of = test depends on what a circuit is connected to.
>>
>>     But, I was actually = coming from the view that MGC "controls" MG
>>     and as such only = MGC should have knowledge on what test to execute
>>     (i.e. what is = connected to the other side of a circuit).
>>
>>     If this information = is left in MG, then each circuit has to be
>>     provisioned
>>     with that = information such that MG can make intelligent decision
>>     on what
>>     type of test to = execute. Thus every time a circuit connection is
>>     changed,
>>     directly or = indirectly, MG circuit needs to be re-provisioned.
>>
>>     I think that = configuration should  be kept on MGC and the decision
>>     should
>>     come from MGC = instead.
>>
>>         &= nbsp;   Aleks
>>
>>     At 02:30 PM = 4/28/2004, Kevin Boyle wrote:
>>
>>>         = Is it possible to run more than one kind of continuity test
>>>         = on a particular circuit?  If no, then the provisioning = model
>>>         = holds and there is no need for a change.  If yes, then we = may
>>>         = need to add something to the package to allow selection of a
>>>         = ct test type.
>>>
>>>         = Kevin
>>>
>>>         = -----Original Message-----
>>>         = From: Aleksandr Ryabin [mailto:kengr@motorola.com]=
>>>         = Sent: Wednesday, April 28, 2004 1:21 PM
>>>         = To: megaco@ietf.org
>>>         = Subject: [Megaco] Continuity tests
>>>
>>>         = Hi,
>>>
>>>         = There are several continuity test types (i.e 2-wire, 4-wire,
>>>         = etc) While provisioning of physical test parameters (i.e.
>>>         = frequencies, sequence, timeouts, etc) in MG makes sense, IMHO
>>>         = choosing a type of continuity test seem logical to be left to
>>>         = MGC.
>>>
>>>         = Basic Continuity Package (ct) does not allow to choose the
>>>         = type of a test.
>>>       = ;  It implies that type of a test is provisioned on MG (per
>>>         = termination?)
>>>
>>>         = Is there another (extended) continuity test package which
>>>         = allows MGC to choose the type of a continuity test to be
>>>         = performed?
>>>
>>>         = If not, does anyone see a need to have such a package?
>>>         = Comments?
>>>
>>>         = Thanks
>>>        &nb= sp;        Aleks
>>>
>>>         = _______________________________________________
>>>         = Megaco mailing list
>>>         = Megaco@ietf.org
>>>         = https://www1.ietf.org/mailman/listinfo/megaco
>>

------_=_NextPart_001_01C42DFD.F04C18D2-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Apr 29 12:41:26 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13089 for ; Thu, 29 Apr 2004 12:41:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJETG-0002t3-51 for megaco-archive@odin.ietf.org; Thu, 29 Apr 2004 12:33:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TGXAv7011096 for megaco-archive@odin.ietf.org; Thu, 29 Apr 2004 12:33:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJE1T-0000kQ-Ge for megaco-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 12:04:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11023 for ; Thu, 29 Apr 2004 12:04:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJE1O-00014O-Rl for megaco-web-archive@ietf.org; Thu, 29 Apr 2004 12:04:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJE0c-0000op-00 for megaco-web-archive@ietf.org; Thu, 29 Apr 2004 12:03:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJDzz-0000YH-00 for megaco-web-archive@ietf.org; Thu, 29 Apr 2004 12:02:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDpk-0005rF-7S; Thu, 29 Apr 2004 11:52:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDQZ-0007GA-Ez for megaco@optimus.ietf.org; Thu, 29 Apr 2004 11:26:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09014 for ; Thu, 29 Apr 2004 11:26:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJDQV-0006QG-6H for megaco@ietf.org; Thu, 29 Apr 2004 11:26:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJDPU-00069R-00 for megaco@ietf.org; Thu, 29 Apr 2004 11:25:14 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1BJDOQ-0005eu-00 for megaco@ietf.org; Thu, 29 Apr 2004 11:24:06 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3TFNb029844; Thu, 29 Apr 2004 11:23:37 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 29 Apr 2004 11:23:38 -0400 Message-ID: From: "Kevin Boyle" To: "Tom-PT Taylor" , Aleksandr Ryabin Cc: megaco@ietf.org Subject: RE: [Megaco] Continuity tests Date: Thu, 29 Apr 2004 11:23:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42DFD.F04C18D2" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 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_01C42DFD.F04C18D2 Content-Type: text/plain I agree with Tom. The fact that the circuit is connected to a single entity means that only a single type of continuity test is actually valid. MGs are expected to know how to handle their terminations. Who the termination is connected to is certainly part of that handling. Because the far-end connection changes the nature of the termination, this becomes an MG-knowledge problem. I believe the package is fine as it stands, and the MG should know what "run a continuity test" means for its terminations. Kevin -----Original Message----- From: Taylor, Tom-PT [CAR:5N00:EXCH] Sent: Thursday, April 29, 2004 11:19 AM To: Aleksandr Ryabin Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org Subject: Re: [Megaco] Continuity tests I for one disagree with your philosophy. I think the physical details of the termination should be provisioned in the MG rather than the the MGC. However, I have no direct implementation responsibility, so I should let those who do speak up. Aleksandr Ryabin wrote: > Packages defined in H.248.17 do not cover continuity tests. > > If the experts agree that MGC should be able to control type of > continuity test then ether basic ct package needs to be amended to > include new functionality, or H.248.17 needs to be amended to include > new "extended" continuity package Commends? Suggestions? > > Aleks > > At 01:14 AM 4/29/2004, Zhao Bo wrote: > >> Can H.248.17 "line test packages" be used to test these circuits? >> >> ----- Original Message ----- >> From: Aleksandr Ryabin >> To: Kevin Boyle ; >> megaco@ietf.org >> Sent: Thursday, April 29, 2004 2:11 AM >> Subject: RE: [Megaco] Continuity tests >> >> Yes, the type of test depends on what a circuit is connected to. >> >> But, I was actually coming from the view that MGC "controls" MG >> and as such only MGC should have knowledge on what test to execute >> (i.e. what is connected to the other side of a circuit). >> >> If this information is left in MG, then each circuit has to be >> provisioned >> with that information such that MG can make intelligent decision >> on what >> type of test to execute. Thus every time a circuit connection is >> changed, >> directly or indirectly, MG circuit needs to be re-provisioned. >> >> I think that configuration should be kept on MGC and the decision >> should >> come from MGC instead. >> >> Aleks >> >> At 02:30 PM 4/28/2004, Kevin Boyle wrote: >> >>> Is it possible to run more than one kind of continuity test >>> on a particular circuit? If no, then the provisioning model >>> holds and there is no need for a change. If yes, then we may >>> need to add something to the package to allow selection of a >>> ct test type. >>> >>> Kevin >>> >>> -----Original Message----- >>> From: Aleksandr Ryabin [mailto:kengr@motorola.com] >>> Sent: Wednesday, April 28, 2004 1:21 PM >>> To: megaco@ietf.org >>> Subject: [Megaco] Continuity tests >>> >>> Hi, >>> >>> There are several continuity test types (i.e 2-wire, 4-wire, >>> etc) While provisioning of physical test parameters (i.e. >>> frequencies, sequence, timeouts, etc) in MG makes sense, IMHO >>> choosing a type of continuity test seem logical to be left to >>> MGC. >>> >>> Basic Continuity Package (ct) does not allow to choose the >>> type of a test. >>> It implies that type of a test is provisioned on MG (per >>> termination?) >>> >>> Is there another (extended) continuity test package which >>> allows MGC to choose the type of a continuity test to be >>> performed? >>> >>> If not, does anyone see a need to have such a package? >>> Comments? >>> >>> Thanks >>> Aleks >>> >>> _______________________________________________ >>> Megaco mailing list >>> Megaco@ietf.org >>> https://www1.ietf.org/mailman/listinfo/megaco >> ------_=_NextPart_001_01C42DFD.F04C18D2 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Megaco] Continuity tests

I agree with Tom.  The fact that the circuit is = connected to a single entity means that only a single type of = continuity test is actually valid.  MGs are expected to know how = to handle their terminations.  Who the termination is connected to = is certainly part of that handling.  Because the far-end = connection changes the nature of the termination, this becomes an = MG-knowledge problem.

I believe the package is fine as it stands, and the = MG should know what "run a continuity test" means for its = terminations.

Kevin

-----Original Message-----
From: Taylor, Tom-PT [CAR:5N00:EXCH]
Sent: Thursday, April 29, 2004 11:19 AM
To: Aleksandr Ryabin
Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; = megaco@ietf.org
Subject: Re: [Megaco] Continuity tests

I for one disagree with your philosophy.  I = think the physical details of the termination should be provisioned in = the MG rather than the the MGC.  However, I have no direct = implementation responsibility, so I should let those who do speak = up.

Aleksandr Ryabin wrote:

> Packages defined in H.248.17 do not cover = continuity tests.
>
> If the experts agree that MGC should be able to = control type of
> continuity test then ether basic ct package = needs to be amended to
> include new functionality, or H.248.17 needs to = be amended to include
> new "extended" continuity package = Commends? Suggestions?
>
>         = Aleks
>
> At 01:14 AM 4/29/2004, Zhao Bo wrote:
>
>> Can H.248.17 "line test = packages"  be used to test these circuits?
>>
>>     ----- Original = Message -----
>>     From: Aleksandr = Ryabin <mailto:kengr@motorola.com>
>>     To: Kevin Boyle = <mailto:kboyle@nortelnetworks.c= om> ;
>>     megaco@ietf.org = <mailto:megaco@ietf.org>
>>     Sent: Thursday, = April 29, 2004 2:11 AM
>>     Subject: RE: = [Megaco] Continuity tests
>>
>>     Yes, the type of = test depends on what a circuit is connected to.
>>
>>     But, I was actually = coming from the view that MGC "controls" MG
>>     and as such only = MGC should have knowledge on what test to execute
>>     (i.e. what is = connected to the other side of a circuit).
>>
>>     If this information = is left in MG, then each circuit has to be
>>     provisioned
>>     with that = information such that MG can make intelligent decision
>>     on what
>>     type of test to = execute. Thus every time a circuit connection is
>>     changed,
>>     directly or = indirectly, MG circuit needs to be re-provisioned.
>>
>>     I think that = configuration should  be kept on MGC and the decision
>>     should
>>     come from MGC = instead.
>>
>>         &= nbsp;   Aleks
>>
>>     At 02:30 PM = 4/28/2004, Kevin Boyle wrote:
>>
>>>         = Is it possible to run more than one kind of continuity test
>>>         = on a particular circuit?  If no, then the provisioning = model
>>>         = holds and there is no need for a change.  If yes, then we = may
>>>         = need to add something to the package to allow selection of a
>>>         = ct test type.
>>>
>>>         = Kevin
>>>
>>>         = -----Original Message-----
>>>         = From: Aleksandr Ryabin [mailto:kengr@motorola.com]=
>>>         = Sent: Wednesday, April 28, 2004 1:21 PM
>>>         = To: megaco@ietf.org
>>>         = Subject: [Megaco] Continuity tests
>>>
>>>         = Hi,
>>>
>>>         = There are several continuity test types (i.e 2-wire, 4-wire,
>>>         = etc) While provisioning of physical test parameters (i.e.
>>>         = frequencies, sequence, timeouts, etc) in MG makes sense, IMHO
>>>         = choosing a type of continuity test seem logical to be left to
>>>         = MGC.
>>>
>>>         = Basic Continuity Package (ct) does not allow to choose the
>>>         = type of a test.
>>>       = ;  It implies that type of a test is provisioned on MG (per
>>>         = termination?)
>>>
>>>         = Is there another (extended) continuity test package which
>>>         = allows MGC to choose the type of a continuity test to be
>>>         = performed?
>>>
>>>         = If not, does anyone see a need to have such a package?
>>>         = Comments?
>>>
>>>         = Thanks
>>>        &nb= sp;        Aleks
>>>
>>>         = _______________________________________________
>>>         = Megaco mailing list
>>>         = Megaco@ietf.org
>>>         = https://www1.ietf.org/mailman/listinfo/megaco
>>

------_=_NextPart_001_01C42DFD.F04C18D2-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Apr 29 13:39:33 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15574 for ; Thu, 29 Apr 2004 13:39:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJFF5-0006kR-Jn; Thu, 29 Apr 2004 13:22:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJERX-0002Os-8z for megaco@optimus.ietf.org; Thu, 29 Apr 2004 12:31:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12400 for ; Thu, 29 Apr 2004 12:31:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJERS-0000ob-9L for megaco@ietf.org; Thu, 29 Apr 2004 12:31:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJEQQ-0000Xr-00 for megaco@ietf.org; Thu, 29 Apr 2004 12:30:16 -0400 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 1BJEPO-00002v-00 for megaco@ietf.org; Thu, 29 Apr 2004 12:29:10 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id i3TGT70n018212; Thu, 29 Apr 2004 09:29:08 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i3TGNxJS022554; Thu, 29 Apr 2004 11:24:04 -0500 Message-Id: <5.2.1.1.0.20040429114553.01e149b8@IL06EXM13.corp.mot.com> X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 29 Apr 2004 12:25:51 -0400 To: "Kevin Boyle", "Tom-PT Taylor", From: Aleksandr Ryabin Subject: RE: [Megaco] Continuity tests In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1746002038==.ALT" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --=====================_1746002038==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Kevin, exactly, the type of COT test does not only depend on the physical details of a termination the MGC controls, but also on physical details of circuit which *eventually* is connected to that termination. My point is that the final far-end *final* connection can change without a change to immediate connection to MG termination and only MGC would know about it. For example, if MG is digital trunking gateway, it does not mean that only pure 4-wire tests will be used all the time. If the other side connected trough set of intermediate switches and finally lands at the time of the test say on analog 2-wire circuit then the test to be executed is 2-wire test. I guess it is possible to somehow tie up configuration of MG termination dynamically to changes which happens to those intermediate switches, but it does not seem right. On the contrary, that information would come to MGC naturally, since it is a controlling element. Also putting a burden of configuring of a test type per every single termination seems to be too much for MG, especially if we are talking about high density MGs which handle hundred thousands terminations. BTW This is a real problem we run into in our MGC implementation and are trying to solve. I thought that instead of having a proprietary package I might as well give it a shot to see if there is any interest to make the solution public instead. Thanks. Aleks At 11:23 AM 4/29/2004, Kevin Boyle wrote: >I agree with Tom. The fact that the circuit is connected to a single >entity means that only a single type of continuity test is actually >valid. MGs are expected to know how to handle their terminations. Who >the termination is connected to is certainly part of that >handling. Because the far-end connection changes the nature of the >termination, this becomes an MG-knowledge problem. > >I believe the package is fine as it stands, and the MG should know what >"run a continuity test" means for its terminations. > >Kevin > >-----Original Message----- >From: Taylor, Tom-PT [CAR:5N00:EXCH] >Sent: Thursday, April 29, 2004 11:19 AM >To: Aleksandr Ryabin >Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org >Subject: Re: [Megaco] Continuity tests > >I for one disagree with your philosophy. I think the physical details of >the termination should be provisioned in the MG rather than the the >MGC. However, I have no direct implementation responsibility, so I should >let those who do speak up. > >Aleksandr Ryabin wrote: > > > Packages defined in H.248.17 do not cover continuity tests. > > > > If the experts agree that MGC should be able to control type of > > continuity test then ether basic ct package needs to be amended to > > include new functionality, or H.248.17 needs to be amended to include > > new "extended" continuity package Commends? Suggestions? > > > > Aleks > > > > At 01:14 AM 4/29/2004, Zhao Bo wrote: > > > >> Can H.248.17 "line test packages" be used to test these circuits? > >> > >> ----- Original Message ----- > >> From: Aleksandr Ryabin > <mailto:kengr@motorola.com> > >> To: Kevin Boyle > <mailto:kboyle@nortelnetworks.com> ; > >> megaco@ietf.org <mailto:megaco@ietf.org> > >> Sent: Thursday, April 29, 2004 2:11 AM > >> Subject: RE: [Megaco] Continuity tests > >> > >> Yes, the type of test depends on what a circuit is connected to. > >> > >> But, I was actually coming from the view that MGC "controls" MG > >> and as such only MGC should have knowledge on what test to execute > >> (i.e. what is connected to the other side of a circuit). > >> > >> If this information is left in MG, then each circuit has to be > >> provisioned > >> with that information such that MG can make intelligent decision > >> on what > >> type of test to execute. Thus every time a circuit connection is > >> changed, > >> directly or indirectly, MG circuit needs to be re-provisioned. > >> > >> I think that configuration should be kept on MGC and the decision > >> should > >> come from MGC instead. > >> > >> Aleks > >> > >> At 02:30 PM 4/28/2004, Kevin Boyle wrote: > >> > >>> Is it possible to run more than one kind of continuity test > >>> on a particular circuit? If no, then the provisioning model > >>> holds and there is no need for a change. If yes, then we may > >>> need to add something to the package to allow selection of a > >>> ct test type. > >>> > >>> Kevin > >>> > >>> -----Original Message----- > >>> From: Aleksandr Ryabin > [mailto:kengr@motorola.com] > >>> Sent: Wednesday, April 28, 2004 1:21 PM > >>> To: megaco@ietf.org > >>> Subject: [Megaco] Continuity tests > >>> > >>> Hi, > >>> > >>> There are several continuity test types (i.e 2-wire, 4-wire, > >>> etc) While provisioning of physical test parameters (i.e. > >>> frequencies, sequence, timeouts, etc) in MG makes sense, IMHO > >>> choosing a type of continuity test seem logical to be left to > >>> MGC. > >>> > >>> Basic Continuity Package (ct) does not allow to choose the > >>> type of a test. > >>> It implies that type of a test is provisioned on MG (per > >>> termination?) > >>> > >>> Is there another (extended) continuity test package which > >>> allows MGC to choose the type of a continuity test to be > >>> performed? > >>> > >>> If not, does anyone see a need to have such a package? > >>> Comments? > >>> > >>> Thanks > >>> Aleks > >>> > >>> _______________________________________________ > >>> Megaco mailing list > >>> Megaco@ietf.org > >>> > https://www1.ietf.org/mailman/listinfo/megaco > > >> --=====================_1746002038==.ALT Content-Type: text/html; charset="us-ascii" Kevin, exactly, the type of COT test does not only depend on the physical
details of a termination the MGC controls, but also on physical
details of circuit which *eventually* is connected to that termination.

My point is that the final far-end *final* connection can change without
a change to immediate connection to MG termination and only MGC
would know about it.

For example, if MG is digital trunking gateway, it does not mean that
only pure 4-wire tests will be used all the time. If the other side connected
trough set of intermediate switches and finally lands at the time of the test
say on analog 2-wire circuit then the test to be executed is 2-wire test.

I guess it is possible to somehow tie up configuration of MG termination
dynamically to changes which happens to those intermediate switches,
but it does not seem right. On the contrary, that information would come to
MGC naturally, since it is a controlling element.

Also putting a burden of configuring of a test type per every single
termination seems to be too much for MG, especially if we are talking
about high density MGs which handle hundred thousands terminations.

BTW This is a real problem we run into in our MGC implementation and
are trying to solve. I thought that instead of having a proprietary package
I might as well give it a shot to see if there is any interest to make the
solution public instead.

Thanks.
        Aleks

At 11:23 AM 4/29/2004, Kevin Boyle wrote:

I agree with Tom.  The fact that the circuit is connected to a single entity means that only a single type of continuity test is actually valid.  MGs are expected to know how to handle their terminations.  Who the termination is connected to is certainly part of that handling.  Because the far-end connection changes the nature of the termination, this becomes an MG-knowledge problem.

I believe the package is fine as it stands, and the MG should know what "run a continuity test" means for its terminations.

Kevin

-----Original Message-----
From: Taylor, Tom-PT [CAR:5N00:EXCH]
Sent: Thursday, April 29, 2004 11:19 AM
To: Aleksandr Ryabin
Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org
Subject: Re: [Megaco] Continuity tests

I for one disagree with your philosophy.  I think the physical details of the termination should be provisioned in the MG rather than the the MGC.  However, I have no direct implementation responsibility, so I should let those who do speak up.

Aleksandr Ryabin wrote:

> Packages defined in H.248.17 do not cover continuity tests.
>
> If the experts agree that MGC should be able to control type of
> continuity test then ether basic ct package needs to be amended to
> include new functionality, or H.248.17 needs to be amended to include
> new "extended" continuity package Commends? Suggestions?
>
>         Aleks
>
> At 01:14 AM 4/29/2004, Zhao Bo wrote:
>
>> Can H.248.17 "line test packages"  be used to test these circuits?
>>
>>     ----- Original Message -----
>>     From: Aleksandr Ryabin <mailto:kengr@motorola.com>
>>     To: Kevin Boyle <mailto:kboyle@nortelnetworks.com> ;
>>     megaco@ietf.org <mailto:megaco@ietf.org>
>>     Sent: Thursday, April 29, 2004 2:11 AM
>>     Subject: RE: [Megaco] Continuity tests
>>
>>     Yes, the type of test depends on what a circuit is connected to.
>>
>>     But, I was actually coming from the view that MGC "controls" MG
>>     and as such only MGC should have knowledge on what test to execute
>>     (i.e. what is connected to the other side of a circuit).
>>
>>     If this information is left in MG, then each circuit has to be
>>     provisioned
>>     with that information such that MG can make intelligent decision
>>     on what
>>     type of test to execute. Thus every time a circuit connection is
>>     changed,
>>     directly or indirectly, MG circuit needs to be re-provisioned.
>>
>>     I think that configuration should  be kept on MGC and the decision
>>     should
>>     come from MGC instead.
>>
>>             Aleks
>>
>>     At 02:30 PM 4/28/2004, Kevin Boyle wrote:
>>
>>>         Is it possible to run more than one kind of continuity test
>>>         on a particular circuit?  If no, then the provisioning model
>>>         holds and there is no need for a change.  If yes, then we may
>>>         need to add something to the package to allow selection of a
>>>         ct test type.
>>>
>>>         Kevin
>>>
>>>         -----Original Message-----
>>>         From: Aleksandr Ryabin [mailto:kengr@motorola.com]
>>>         Sent: Wednesday, April 28, 2004 1:21 PM
>>>         To: megaco@ietf.org
>>>         Subject: [Megaco] Continuity tests
>>>
>>>         Hi,
>>>
>>>         There are several continuity test types (i.e 2-wire, 4-wire,
>>>         etc) While provisioning of physical test parameters (i.e.
>>>         frequencies, sequence, timeouts, etc) in MG makes sense, IMHO
>>>         choosing a type of continuity test seem logical to be left to
>>>         MGC.
>>>
>>>         Basic Continuity Package (ct) does not allow to choose the
>>>         type of a test.
>>>         It implies that type of a test is provisioned on MG (per
>>>         termination?)
>>>
>>>         Is there another (extended) continuity test package which
>>>         allows MGC to choose the type of a continuity test to be
>>>         performed?
>>>
>>>         If not, does anyone see a need to have such a package?
>>>         Comments?
>>>
>>>         Thanks
>>>                 Aleks
>>>
>>>         _______________________________________________
>>>         Megaco mailing list
>>>         Megaco@ietf.org
>>>         https://www1.ietf.org/mailman/listinfo/megaco
>>
--=====================_1746002038==.ALT-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Apr 29 13:51:37 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16793 for ; Thu, 29 Apr 2004 13:51:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJFeC-0006Eo-Iq for megaco-archive@odin.ietf.org; Thu, 29 Apr 2004 13:48:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3THmW9f023978 for megaco-archive@odin.ietf.org; Thu, 29 Apr 2004 13:48:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJFWU-0002bZ-7c for megaco-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 13:40:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15651 for ; Thu, 29 Apr 2004 13:40:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJFWO-0003vN-Sj for megaco-web-archive@ietf.org; Thu, 29 Apr 2004 13:40:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJFVO-0003es-00 for megaco-web-archive@ietf.org; Thu, 29 Apr 2004 13:39:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJFUy-0003Ob-00 for megaco-web-archive@ietf.org; Thu, 29 Apr 2004 13:39:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJFF5-0006kR-Jn; Thu, 29 Apr 2004 13:22:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJERX-0002Os-8z for megaco@optimus.ietf.org; Thu, 29 Apr 2004 12:31:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12400 for ; Thu, 29 Apr 2004 12:31:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJERS-0000ob-9L for megaco@ietf.org; Thu, 29 Apr 2004 12:31:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJEQQ-0000Xr-00 for megaco@ietf.org; Thu, 29 Apr 2004 12:30:16 -0400 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 1BJEPO-00002v-00 for megaco@ietf.org; Thu, 29 Apr 2004 12:29:10 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id i3TGT70n018212; Thu, 29 Apr 2004 09:29:08 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i3TGNxJS022554; Thu, 29 Apr 2004 11:24:04 -0500 Message-Id: <5.2.1.1.0.20040429114553.01e149b8@IL06EXM13.corp.mot.com> X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 29 Apr 2004 12:25:51 -0400 To: "Kevin Boyle", "Tom-PT Taylor", From: Aleksandr Ryabin Subject: RE: [Megaco] Continuity tests In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1746002038==.ALT" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 --=====================_1746002038==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Kevin, exactly, the type of COT test does not only depend on the physical details of a termination the MGC controls, but also on physical details of circuit which *eventually* is connected to that termination. My point is that the final far-end *final* connection can change without a change to immediate connection to MG termination and only MGC would know about it. For example, if MG is digital trunking gateway, it does not mean that only pure 4-wire tests will be used all the time. If the other side connected trough set of intermediate switches and finally lands at the time of the test say on analog 2-wire circuit then the test to be executed is 2-wire test. I guess it is possible to somehow tie up configuration of MG termination dynamically to changes which happens to those intermediate switches, but it does not seem right. On the contrary, that information would come to MGC naturally, since it is a controlling element. Also putting a burden of configuring of a test type per every single termination seems to be too much for MG, especially if we are talking about high density MGs which handle hundred thousands terminations. BTW This is a real problem we run into in our MGC implementation and are trying to solve. I thought that instead of having a proprietary package I might as well give it a shot to see if there is any interest to make the solution public instead. Thanks. Aleks At 11:23 AM 4/29/2004, Kevin Boyle wrote: >I agree with Tom. The fact that the circuit is connected to a single >entity means that only a single type of continuity test is actually >valid. MGs are expected to know how to handle their terminations. Who >the termination is connected to is certainly part of that >handling. Because the far-end connection changes the nature of the >termination, this becomes an MG-knowledge problem. > >I believe the package is fine as it stands, and the MG should know what >"run a continuity test" means for its terminations. > >Kevin > >-----Original Message----- >From: Taylor, Tom-PT [CAR:5N00:EXCH] >Sent: Thursday, April 29, 2004 11:19 AM >To: Aleksandr Ryabin >Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org >Subject: Re: [Megaco] Continuity tests > >I for one disagree with your philosophy. I think the physical details of >the termination should be provisioned in the MG rather than the the >MGC. However, I have no direct implementation responsibility, so I should >let those who do speak up. > >Aleksandr Ryabin wrote: > > > Packages defined in H.248.17 do not cover continuity tests. > > > > If the experts agree that MGC should be able to control type of > > continuity test then ether basic ct package needs to be amended to > > include new functionality, or H.248.17 needs to be amended to include > > new "extended" continuity package Commends? Suggestions? > > > > Aleks > > > > At 01:14 AM 4/29/2004, Zhao Bo wrote: > > > >> Can H.248.17 "line test packages" be used to test these circuits? > >> > >> ----- Original Message ----- > >> From: Aleksandr Ryabin > <mailto:kengr@motorola.com> > >> To: Kevin Boyle > <mailto:kboyle@nortelnetworks.com> ; > >> megaco@ietf.org <mailto:megaco@ietf.org> > >> Sent: Thursday, April 29, 2004 2:11 AM > >> Subject: RE: [Megaco] Continuity tests > >> > >> Yes, the type of test depends on what a circuit is connected to. > >> > >> But, I was actually coming from the view that MGC "controls" MG > >> and as such only MGC should have knowledge on what test to execute > >> (i.e. what is connected to the other side of a circuit). > >> > >> If this information is left in MG, then each circuit has to be > >> provisioned > >> with that information such that MG can make intelligent decision > >> on what > >> type of test to execute. Thus every time a circuit connection is > >> changed, > >> directly or indirectly, MG circuit needs to be re-provisioned. > >> > >> I think that configuration should be kept on MGC and the decision > >> should > >> come from MGC instead. > >> > >> Aleks > >> > >> At 02:30 PM 4/28/2004, Kevin Boyle wrote: > >> > >>> Is it possible to run more than one kind of continuity test > >>> on a particular circuit? If no, then the provisioning model > >>> holds and there is no need for a change. If yes, then we may > >>> need to add something to the package to allow selection of a > >>> ct test type. > >>> > >>> Kevin > >>> > >>> -----Original Message----- > >>> From: Aleksandr Ryabin > [mailto:kengr@motorola.com] > >>> Sent: Wednesday, April 28, 2004 1:21 PM > >>> To: megaco@ietf.org > >>> Subject: [Megaco] Continuity tests > >>> > >>> Hi, > >>> > >>> There are several continuity test types (i.e 2-wire, 4-wire, > >>> etc) While provisioning of physical test parameters (i.e. > >>> frequencies, sequence, timeouts, etc) in MG makes sense, IMHO > >>> choosing a type of continuity test seem logical to be left to > >>> MGC. > >>> > >>> Basic Continuity Package (ct) does not allow to choose the > >>> type of a test. > >>> It implies that type of a test is provisioned on MG (per > >>> termination?) > >>> > >>> Is there another (extended) continuity test package which > >>> allows MGC to choose the type of a continuity test to be > >>> performed? > >>> > >>> If not, does anyone see a need to have such a package? > >>> Comments? > >>> > >>> Thanks > >>> Aleks > >>> > >>> _______________________________________________ > >>> Megaco mailing list > >>> Megaco@ietf.org > >>> > https://www1.ietf.org/mailman/listinfo/megaco > > >> --=====================_1746002038==.ALT Content-Type: text/html; charset="us-ascii" Kevin, exactly, the type of COT test does not only depend on the physical
details of a termination the MGC controls, but also on physical
details of circuit which *eventually* is connected to that termination.

My point is that the final far-end *final* connection can change without
a change to immediate connection to MG termination and only MGC
would know about it.

For example, if MG is digital trunking gateway, it does not mean that
only pure 4-wire tests will be used all the time. If the other side connected
trough set of intermediate switches and finally lands at the time of the test
say on analog 2-wire circuit then the test to be executed is 2-wire test.

I guess it is possible to somehow tie up configuration of MG termination
dynamically to changes which happens to those intermediate switches,
but it does not seem right. On the contrary, that information would come to
MGC naturally, since it is a controlling element.

Also putting a burden of configuring of a test type per every single
termination seems to be too much for MG, especially if we are talking
about high density MGs which handle hundred thousands terminations.

BTW This is a real problem we run into in our MGC implementation and
are trying to solve. I thought that instead of having a proprietary package
I might as well give it a shot to see if there is any interest to make the
solution public instead.

Thanks.
        Aleks

At 11:23 AM 4/29/2004, Kevin Boyle wrote:

I agree with Tom.  The fact that the circuit is connected to a single entity means that only a single type of continuity test is actually valid.  MGs are expected to know how to handle their terminations.  Who the termination is connected to is certainly part of that handling.  Because the far-end connection changes the nature of the termination, this becomes an MG-knowledge problem.

I believe the package is fine as it stands, and the MG should know what "run a continuity test" means for its terminations.

Kevin

-----Original Message-----
From: Taylor, Tom-PT [CAR:5N00:EXCH]
Sent: Thursday, April 29, 2004 11:19 AM
To: Aleksandr Ryabin
Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org
Subject: Re: [Megaco] Continuity tests

I for one disagree with your philosophy.  I think the physical details of the termination should be provisioned in the MG rather than the the MGC.  However, I have no direct implementation responsibility, so I should let those who do speak up.

Aleksandr Ryabin wrote:

> Packages defined in H.248.17 do not cover continuity tests.
>
> If the experts agree that MGC should be able to control type of
> continuity test then ether basic ct package needs to be amended to
> include new functionality, or H.248.17 needs to be amended to include
> new "extended" continuity package Commends? Suggestions?
>
>         Aleks
>
> At 01:14 AM 4/29/2004, Zhao Bo wrote:
>
>> Can H.248.17 "line test packages"  be used to test these circuits?
>>
>>     ----- Original Message -----
>>     From: Aleksandr Ryabin <mailto:kengr@motorola.com>
>>     To: Kevin Boyle <mailto:kboyle@nortelnetworks.com> ;
>>     megaco@ietf.org <mailto:megaco@ietf.org>
>>     Sent: Thursday, April 29, 2004 2:11 AM
>>     Subject: RE: [Megaco] Continuity tests
>>
>>     Yes, the type of test depends on what a circuit is connected to.
>>
>>     But, I was actually coming from the view that MGC "controls" MG
>>     and as such only MGC should have knowledge on what test to execute
>>     (i.e. what is connected to the other side of a circuit).
>>
>>     If this information is left in MG, then each circuit has to be
>>     provisioned
>>     with that information such that MG can make intelligent decision
>>     on what
>>     type of test to execute. Thus every time a circuit connection is
>>     changed,
>>     directly or indirectly, MG circuit needs to be re-provisioned.
>>
>>     I think that configuration should  be kept on MGC and the decision
>>     should
>>     come from MGC instead.
>>
>>             Aleks
>>
>>     At 02:30 PM 4/28/2004, Kevin Boyle wrote:
>>
>>>         Is it possible to run more than one kind of continuity test
>>>         on a particular circuit?  If no, then the provisioning model
>>>         holds and there is no need for a change.  If yes, then we may
>>>         need to add something to the package to allow selection of a
>>>         ct test type.
>>>
>>>         Kevin
>>>
>>>         -----Original Message-----
>>>         From: Aleksandr Ryabin [mailto:kengr@motorola.com]
>>>         Sent: Wednesday, April 28, 2004 1:21 PM
>>>         To: megaco@ietf.org
>>>         Subject: [Megaco] Continuity tests
>>>
>>>         Hi,
>>>
>>>         There are several continuity test types (i.e 2-wire, 4-wire,
>>>         etc) While provisioning of physical test parameters (i.e.
>>>         frequencies, sequence, timeouts, etc) in MG makes sense, IMHO
>>>         choosing a type of continuity test seem logical to be left to
>>>         MGC.
>>>
>>>         Basic Continuity Package (ct) does not allow to choose the
>>>         type of a test.
>>>         It implies that type of a test is provisioned on MG (per
>>>         termination?)
>>>
>>>         Is there another (extended) continuity test package which
>>>         allows MGC to choose the type of a continuity test to be
>>>         performed?
>>>
>>>         If not, does anyone see a need to have such a package?
>>>         Comments?
>>>
>>>         Thanks
>>>                 Aleks
>>>
>>>         _______________________________________________
>>>         Megaco mailing list
>>>         Megaco@ietf.org
>>>         https://www1.ietf.org/mailman/listinfo/megaco
>>
--=====================_1746002038==.ALT-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Apr 29 19:06:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09470 for ; Thu, 29 Apr 2004 19:06:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKPs-0003F0-Tm; Thu, 29 Apr 2004 18:54:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKKX-0001d9-Dq for megaco@optimus.ietf.org; Thu, 29 Apr 2004 18:48:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08621 for ; Thu, 29 Apr 2004 18:48:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJKKP-0005HO-5O for megaco@ietf.org; Thu, 29 Apr 2004 18:48:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJKJQ-0005F5-00 for megaco@ietf.org; Thu, 29 Apr 2004 18:47:25 -0400 Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1BJKIi-0005DC-00 for megaco@ietf.org; Thu, 29 Apr 2004 18:46:40 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3TMkhWR013573 for ; Fri, 30 Apr 2004 00:46:43 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 30 Apr 2004 00:46:42 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JQ35QWFV; Fri, 30 Apr 2004 00:46:42 +0200 Received: from ericsson.com (sealwa04-247.sw.ericsson.se [130.100.249.247]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JRYYZNX6; Fri, 30 Apr 2004 08:46:27 +1000 Message-ID: <409185C2.9020409@ericsson.com> Date: Fri, 30 Apr 2004 08:46:26 +1000 X-Sybari-Trust: 9c3a2ae2 c38aee8b 00db2f9f 00000138 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Taylor CC: megaco@ietf.org Subject: Re: [Megaco] Meaning of "support" for signals and events References: <408FFA01.5080905@nortelnetworks.com> <409036F7.60107@ericsson.com> <40910582.1040007@nortelnetworks.com> In-Reply-To: <40910582.1040007@nortelnetworks.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-OriginalArrivalTime: 29 Apr 2004 22:46:42.0933 (UTC) FILETIME=[D7A8D250:01C42E3B] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by albatross.ericsson.se id i3TMkhWR013573 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hello Tom, Yes 501 is subject to the usual error handling procedures. Regards, Christian Tom Taylor wrote: > Hi. >=20 > I assume this 501 error response means that the transaction fails, as=20 > usual. >=20 > Christian Groves wrote: >=20 >> Hello Tom, >> >> I didn't realise the MSF was on at the moment... >> >> As Troy said we discussed this recently on the list and it was agreed=20 >> to add something to the IG. >> >> Below is the text which I propose to clarify the issue: >> 6.2.3 Packages >> =85 >> To support a particular package the MG must support all properties,=20 >> signals, events and statistics defined in a package. It must also=20 >> support all Signal and Event parameters. If the functionality behind=20 >> these properties, signals, events and statistics is not implemented=20 >> the MG shall not return a syntax error or unknown ID for any of these=20 >> elements but should return response 501 =93Not implemented=94. The MG = may=20 >> support a subset of the values listed in a package for a particular=20 >> Property or Parameter. >> >> >=20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Apr 29 19:15:30 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09899 for ; Thu, 29 Apr 2004 19:15:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKeL-0005y9-Kb; Thu, 29 Apr 2004 19:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKQP-0003Hv-8D for megaco@optimus.ietf.org; Thu, 29 Apr 2004 18:54:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08883 for ; Thu, 29 Apr 2004 18:54:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJKQG-0005bE-Ut for megaco@ietf.org; Thu, 29 Apr 2004 18:54:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJKPM-0005Xa-00 for megaco@ietf.org; Thu, 29 Apr 2004 18:53:33 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BJKOi-0005UJ-00 for megaco@ietf.org; Thu, 29 Apr 2004 18:52:52 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3TMqtPA003754 for ; Fri, 30 Apr 2004 00:52:55 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 30 Apr 2004 00:52:55 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JWBD9TLN; Fri, 30 Apr 2004 00:52:54 +0200 Received: from ericsson.com (sealwa04-247.sw.ericsson.se [130.100.249.247]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JRYYZN78; Fri, 30 Apr 2004 08:52:40 +1000 Message-ID: <40918739.6020002@ericsson.com> Date: Fri, 30 Apr 2004 08:52:41 +1000 X-Sybari-Trust: 4d515c38 c38aee8b 00db2f9f 00000138 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Taylor CC: Troy Cauble , megaco@ietf.org Subject: Re: Signaling of UDI rsp Clearmode Bearer Service; Re: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversion References: <403E1760.2010903@nortelnetworks.com> <40427B92.3000707@ericsson.com> <406C2424.7050708@alcatel.de> <40720E2A.6070903@ericsson.com> <408D053E.2080405@alcatel.de> <408E24FA.2070303@ericsson.com> <408FC501.9040407@bell-labs.com> <408FF7B3.1070404@nortelnetworks.com> <40900008.2050703@bell-labs.com> <40903A8F.6050907@ericsson.com> <4091063A.7010003@nortelnetworks.com> In-Reply-To: <4091063A.7010003@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Apr 2004 22:52:55.0232 (UTC) FILETIME=[B5912400:01C42E3C] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Tom, Kevin, Troy, It's not about replicating the values it's about the packageid/property ID itself. You can't simply remove it if it's in use. If you want to progress down the path of defining TMR and USI for SDP then it's OK by me. I didn't raise the need for TMR/USI in text in the first place. Those wanting it should speak up about their preference. If we do go down the way of putting TMR and USI in SDP then I think all we should do is simply carry the TMR/USI in SDP. I don't think there's any point in exploding the octets to individual text descriptions as you have done in the draft. Regards, Christian Tom Taylor wrote: > We can replicate the binary values for the TMR and USI, and reassign the > packageId for them. > > However, if necessary, I can revive my I-D on SDP encoding of TMR/USI. > I dropped it for lack of apparent interest. > > Christian Groves wrote: > >> Hello Troy, Tom and Kevin, >> >> I agree Annex C is not a package however it does use the same method >> of referencing the properties ie. packageId/propertyID where in the >> binary case the packageId is 0000. >> >> However USI and TMR is being used by implementations so we can't >> simply deprecate Annex C as some seem to indicate. We have seen a case >> where TMR/USI would be useful for text implementations. There are >> several options here. As USI/TMR are already being used by binary >> implementations it isn't appropriate to make changes to this, which >> essentially a new package would be. This leaves modifications for the >> text encoding. I thought the easiest way would be to use the H.248.15 >> to carry the property, the side effect being a "packageID" would be >> needed. This seemed to be simplest method, keeps it in the H.248 >> domain and is in the WGs control. The other method would be to define >> SDP to carry the octets for USI/TMR. This will muddy the water has >> people will think this relates to SIP in some way. This will probably >> take some time to sort out. >> >> If we had our time again I would have prefered the use of packages >> only (no Annex C/no SDP) ;). >> >> Regards, Christian >> > ... > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Apr 29 19:22:03 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10357 for ; Thu, 29 Apr 2004 19:22:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKeg-00062S-7N for megaco-archive@odin.ietf.org; Thu, 29 Apr 2004 19:09:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TN9Mlc023212 for megaco-archive@odin.ietf.org; Thu, 29 Apr 2004 19:09:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKdm-0005lP-Hm for megaco-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 19:08:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09583 for ; Thu, 29 Apr 2004 19:08:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJKde-0006b9-3O for megaco-web-archive@ietf.org; Thu, 29 Apr 2004 19:08:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJKcZ-0006W2-00 for megaco-web-archive@ietf.org; Thu, 29 Apr 2004 19:07:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJKbd-0006Nt-00 for megaco-web-archive@ietf.org; Thu, 29 Apr 2004 19:06:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKPs-0003F0-Tm; Thu, 29 Apr 2004 18:54:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKKX-0001d9-Dq for megaco@optimus.ietf.org; Thu, 29 Apr 2004 18:48:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08621 for ; Thu, 29 Apr 2004 18:48:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJKKP-0005HO-5O for megaco@ietf.org; Thu, 29 Apr 2004 18:48:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJKJQ-0005F5-00 for megaco@ietf.org; Thu, 29 Apr 2004 18:47:25 -0400 Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1BJKIi-0005DC-00 for megaco@ietf.org; Thu, 29 Apr 2004 18:46:40 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3TMkhWR013573 for ; Fri, 30 Apr 2004 00:46:43 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 30 Apr 2004 00:46:42 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JQ35QWFV; Fri, 30 Apr 2004 00:46:42 +0200 Received: from ericsson.com (sealwa04-247.sw.ericsson.se [130.100.249.247]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JRYYZNX6; Fri, 30 Apr 2004 08:46:27 +1000 Message-ID: <409185C2.9020409@ericsson.com> Date: Fri, 30 Apr 2004 08:46:26 +1000 X-Sybari-Trust: 9c3a2ae2 c38aee8b 00db2f9f 00000138 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Taylor CC: megaco@ietf.org Subject: Re: [Megaco] Meaning of "support" for signals and events References: <408FFA01.5080905@nortelnetworks.com> <409036F7.60107@ericsson.com> <40910582.1040007@nortelnetworks.com> In-Reply-To: <40910582.1040007@nortelnetworks.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-OriginalArrivalTime: 29 Apr 2004 22:46:42.0933 (UTC) FILETIME=[D7A8D250:01C42E3B] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by albatross.ericsson.se id i3TMkhWR013573 Content-Transfer-Encoding: quoted-printable Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello Tom, Yes 501 is subject to the usual error handling procedures. Regards, Christian Tom Taylor wrote: > Hi. >=20 > I assume this 501 error response means that the transaction fails, as=20 > usual. >=20 > Christian Groves wrote: >=20 >> Hello Tom, >> >> I didn't realise the MSF was on at the moment... >> >> As Troy said we discussed this recently on the list and it was agreed=20 >> to add something to the IG. >> >> Below is the text which I propose to clarify the issue: >> 6.2.3 Packages >> =85 >> To support a particular package the MG must support all properties,=20 >> signals, events and statistics defined in a package. It must also=20 >> support all Signal and Event parameters. If the functionality behind=20 >> these properties, signals, events and statistics is not implemented=20 >> the MG shall not return a syntax error or unknown ID for any of these=20 >> elements but should return response 501 =93Not implemented=94. The MG = may=20 >> support a subset of the values listed in a package for a particular=20 >> Property or Parameter. >> >> >=20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Apr 29 19:34:18 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10826 for ; Thu, 29 Apr 2004 19:34:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKtC-0008WK-NU for megaco-archive@odin.ietf.org; Thu, 29 Apr 2004 19:24:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TNOM5J032743 for megaco-archive@odin.ietf.org; Thu, 29 Apr 2004 19:24:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKlk-0006qX-6P for megaco-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 19:16:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09946 for ; Thu, 29 Apr 2004 19:16:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJKlf-0007Gj-B6 for megaco-web-archive@ietf.org; Thu, 29 Apr 2004 19:16:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJKkb-00078z-00 for megaco-web-archive@ietf.org; Thu, 29 Apr 2004 19:15:29 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJKk7-000767-00 for megaco-web-archive@ietf.org; Thu, 29 Apr 2004 19:14:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKeL-0005y9-Kb; Thu, 29 Apr 2004 19:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJKQP-0003Hv-8D for megaco@optimus.ietf.org; Thu, 29 Apr 2004 18:54:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08883 for ; Thu, 29 Apr 2004 18:54:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJKQG-0005bE-Ut for megaco@ietf.org; Thu, 29 Apr 2004 18:54:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJKPM-0005Xa-00 for megaco@ietf.org; Thu, 29 Apr 2004 18:53:33 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BJKOi-0005UJ-00 for megaco@ietf.org; Thu, 29 Apr 2004 18:52:52 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3TMqtPA003754 for ; Fri, 30 Apr 2004 00:52:55 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 30 Apr 2004 00:52:55 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JWBD9TLN; Fri, 30 Apr 2004 00:52:54 +0200 Received: from ericsson.com (sealwa04-247.sw.ericsson.se [130.100.249.247]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JRYYZN78; Fri, 30 Apr 2004 08:52:40 +1000 Message-ID: <40918739.6020002@ericsson.com> Date: Fri, 30 Apr 2004 08:52:41 +1000 X-Sybari-Trust: 4d515c38 c38aee8b 00db2f9f 00000138 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Taylor CC: Troy Cauble , megaco@ietf.org Subject: Re: Signaling of UDI rsp Clearmode Bearer Service; Re: TDM Hairpinning; Re: [Megaco] Hairpin case A/u Law conversion References: <403E1760.2010903@nortelnetworks.com> <40427B92.3000707@ericsson.com> <406C2424.7050708@alcatel.de> <40720E2A.6070903@ericsson.com> <408D053E.2080405@alcatel.de> <408E24FA.2070303@ericsson.com> <408FC501.9040407@bell-labs.com> <408FF7B3.1070404@nortelnetworks.com> <40900008.2050703@bell-labs.com> <40903A8F.6050907@ericsson.com> <4091063A.7010003@nortelnetworks.com> In-Reply-To: <4091063A.7010003@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Apr 2004 22:52:55.0232 (UTC) FILETIME=[B5912400:01C42E3C] Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Tom, Kevin, Troy, It's not about replicating the values it's about the packageid/property ID itself. You can't simply remove it if it's in use. If you want to progress down the path of defining TMR and USI for SDP then it's OK by me. I didn't raise the need for TMR/USI in text in the first place. Those wanting it should speak up about their preference. If we do go down the way of putting TMR and USI in SDP then I think all we should do is simply carry the TMR/USI in SDP. I don't think there's any point in exploding the octets to individual text descriptions as you have done in the draft. Regards, Christian Tom Taylor wrote: > We can replicate the binary values for the TMR and USI, and reassign the > packageId for them. > > However, if necessary, I can revive my I-D on SDP encoding of TMR/USI. > I dropped it for lack of apparent interest. > > Christian Groves wrote: > >> Hello Troy, Tom and Kevin, >> >> I agree Annex C is not a package however it does use the same method >> of referencing the properties ie. packageId/propertyID where in the >> binary case the packageId is 0000. >> >> However USI and TMR is being used by implementations so we can't >> simply deprecate Annex C as some seem to indicate. We have seen a case >> where TMR/USI would be useful for text implementations. There are >> several options here. As USI/TMR are already being used by binary >> implementations it isn't appropriate to make changes to this, which >> essentially a new package would be. This leaves modifications for the >> text encoding. I thought the easiest way would be to use the H.248.15 >> to carry the property, the side effect being a "packageID" would be >> needed. This seemed to be simplest method, keeps it in the H.248 >> domain and is in the WGs control. The other method would be to define >> SDP to carry the octets for USI/TMR. This will muddy the water has >> people will think this relates to SIP in some way. This will probably >> take some time to sort out. >> >> If we had our time again I would have prefered the use of packages >> only (no Annex C/no SDP) ;). >> >> Regards, Christian >> > ... > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Apr 29 20:32:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13227 for ; Thu, 29 Apr 2004 20:32:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJLo1-0000KD-5v; Thu, 29 Apr 2004 20:23:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJLka-00086u-JH for megaco@optimus.ietf.org; Thu, 29 Apr 2004 20:19:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12821 for ; Thu, 29 Apr 2004 20:19:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJLkV-0003nX-4L for megaco@ietf.org; Thu, 29 Apr 2004 20:19:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJLjY-0003hs-00 for megaco@ietf.org; Thu, 29 Apr 2004 20:18:29 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BJLib-0003dW-00 for megaco@ietf.org; Thu, 29 Apr 2004 20:17:29 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3U0HWPA009361 for ; Fri, 30 Apr 2004 02:17:32 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 30 Apr 2004 02:17:32 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id J73SFGXV; Fri, 30 Apr 2004 02:17:33 +0200 Received: from ericsson.com (sealwa04-247.sw.ericsson.se [130.100.249.247]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JRYYZPZT; Fri, 30 Apr 2004 10:17:16 +1000 Message-ID: <40919B0C.3010205@ericsson.com> Date: Fri, 30 Apr 2004 10:17:16 +1000 X-Sybari-Trust: 5b6f32b2 f0b06ce5 33e1adf1 00000139 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aleksandr Ryabin CC: Kevin Boyle , Tom-PT Taylor , megaco@ietf.org Subject: Re: [Megaco] Continuity tests References: <5.2.1.1.0.20040429114553.01e149b8@IL06EXM13.corp.mot.com> In-Reply-To: <5.2.1.1.0.20040429114553.01e149b8@IL06EXM13.corp.mot.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Apr 2004 00:17:32.0597 (UTC) FILETIME=[87E98E50:01C42E48] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Aleksandr, Is this really a problem? The Continuity test is a link by link procedure not an end to end procedure. I tend to support Kevin and Tom on this one. Regards, Christian Aleksandr Ryabin wrote: > Kevin, exactly, the type of COT test does not only depend on the physical > details of a termination the MGC controls, but also on physical > details of circuit which *eventually* is connected to that termination. > > My point is that the final far-end *final* connection can change without > a change to immediate connection to MG termination and only MGC > would know about it. > > For example, if MG is digital trunking gateway, it does not mean that > only pure 4-wire tests will be used all the time. If the other side > connected > trough set of intermediate switches and finally lands at the time of the > test > say on analog 2-wire circuit then the test to be executed is 2-wire test. > > I guess it is possible to somehow tie up configuration of MG termination > dynamically to changes which happens to those intermediate switches, > but it does not seem right. On the contrary, that information would come to > MGC naturally, since it is a controlling element. > > Also putting a burden of configuring of a test type per every single > termination seems to be too much for MG, especially if we are talking > about high density MGs which handle hundred thousands terminations. > > BTW This is a real problem we run into in our MGC implementation and > are trying to solve. I thought that instead of having a proprietary package > I might as well give it a shot to see if there is any interest to make the > solution public instead. > > Thanks. > Aleks > > At 11:23 AM 4/29/2004, Kevin Boyle wrote: > >> I agree with Tom. The fact that the circuit is connected to a single >> entity means that only a single type of continuity test is actually >> valid. MGs are expected to know how to handle their terminations. >> Who the termination is connected to is certainly part of that >> handling. Because the far-end connection changes the nature of the >> termination, this becomes an MG-knowledge problem. >> >> I believe the package is fine as it stands, and the MG should know >> what "run a continuity test" means for its terminations. >> >> Kevin >> >> -----Original Message----- >> From: Taylor, Tom-PT [CAR:5N00:EXCH] >> Sent: Thursday, April 29, 2004 11:19 AM >> To: Aleksandr Ryabin >> Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org >> Subject: Re: [Megaco] Continuity tests >> >> I for one disagree with your philosophy. I think the physical details >> of the termination should be provisioned in the MG rather than the the >> MGC. However, I have no direct implementation responsibility, so I >> should let those who do speak up. >> >> Aleksandr Ryabin wrote: >> >> > Packages defined in H.248.17 do not cover continuity tests. >> > >> > If the experts agree that MGC should be able to control type of >> > continuity test then ether basic ct package needs to be amended to >> > include new functionality, or H.248.17 needs to be amended to include >> > new "extended" continuity package Commends? Suggestions? >> > >> > Aleks >> > >> > At 01:14 AM 4/29/2004, Zhao Bo wrote: >> > >> >> Can H.248.17 "line test packages" be used to test these circuits? >> >> >> >> ----- Original Message ----- >> >> From: Aleksandr Ryabin >> >> To: Kevin Boyle ; >> >> megaco@ietf.org >> >> Sent: Thursday, April 29, 2004 2:11 AM >> >> Subject: RE: [Megaco] Continuity tests >> >> >> >> Yes, the type of test depends on what a circuit is connected to. >> >> >> >> But, I was actually coming from the view that MGC "controls" MG >> >> and as such only MGC should have knowledge on what test to execute >> >> (i.e. what is connected to the other side of a circuit). >> >> >> >> If this information is left in MG, then each circuit has to be >> >> provisioned >> >> with that information such that MG can make intelligent decision >> >> on what >> >> type of test to execute. Thus every time a circuit connection is >> >> changed, >> >> directly or indirectly, MG circuit needs to be re-provisioned. >> >> >> >> I think that configuration should be kept on MGC and the decision >> >> should >> >> come from MGC instead. >> >> >> >> Aleks >> >> >> >> At 02:30 PM 4/28/2004, Kevin Boyle wrote: >> >> >> >>> Is it possible to run more than one kind of continuity test >> >>> on a particular circuit? If no, then the provisioning model >> >>> holds and there is no need for a change. If yes, then we may >> >>> need to add something to the package to allow selection of a >> >>> ct test type. >> >>> >> >>> Kevin >> >>> >> >>> -----Original Message----- >> >>> From: Aleksandr Ryabin [mailto:kengr@motorola.com] >> >>> Sent: Wednesday, April 28, 2004 1:21 PM >> >>> To: megaco@ietf.org >> >>> Subject: [Megaco] Continuity tests >> >>> >> >>> Hi, >> >>> >> >>> There are several continuity test types (i.e 2-wire, 4-wire, >> >>> etc) While provisioning of physical test parameters (i.e. >> >>> frequencies, sequence, timeouts, etc) in MG makes sense, IMHO >> >>> choosing a type of continuity test seem logical to be left to >> >>> MGC. >> >>> >> >>> Basic Continuity Package (ct) does not allow to choose the >> >>> type of a test. >> >>> It implies that type of a test is provisioned on MG (per >> >>> termination?) >> >>> >> >>> Is there another (extended) continuity test package which >> >>> allows MGC to choose the type of a continuity test to be >> >>> performed? >> >>> >> >>> If not, does anyone see a need to have such a package? >> >>> Comments? >> >>> >> >>> Thanks >> >>> Aleks >> >>> >> >>> _______________________________________________ >> >>> Megaco mailing list >> >>> Megaco@ietf.org >> >>> https://www1.ietf.org/mailman/listinfo/megaco >> >> _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Apr 29 20:45:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14625 for ; Thu, 29 Apr 2004 20:45:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJM2N-0002ZU-Ir for megaco-archive@odin.ietf.org; Thu, 29 Apr 2004 20:37:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3U0btYd009875 for megaco-archive@odin.ietf.org; Thu, 29 Apr 2004 20:37:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJLyH-0001dG-3h for megaco-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 20:33:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13353 for ; Thu, 29 Apr 2004 20:33:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJLyB-0004kH-Kb for megaco-web-archive@ietf.org; Thu, 29 Apr 2004 20:33:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJLxI-0004ff-00 for megaco-web-archive@ietf.org; Thu, 29 Apr 2004 20:32:41 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJLwS-0004b4-00 for megaco-web-archive@ietf.org; Thu, 29 Apr 2004 20:31:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJLo1-0000KD-5v; Thu, 29 Apr 2004 20:23:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJLka-00086u-JH for megaco@optimus.ietf.org; Thu, 29 Apr 2004 20:19:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12821 for ; Thu, 29 Apr 2004 20:19:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJLkV-0003nX-4L for megaco@ietf.org; Thu, 29 Apr 2004 20:19:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJLjY-0003hs-00 for megaco@ietf.org; Thu, 29 Apr 2004 20:18:29 -0400 Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1BJLib-0003dW-00 for megaco@ietf.org; Thu, 29 Apr 2004 20:17:29 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3U0HWPA009361 for ; Fri, 30 Apr 2004 02:17:32 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 30 Apr 2004 02:17:32 +0200 Received: from eaubrnt019.epa.ericsson.se ([146.11.9.165]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id J73SFGXV; Fri, 30 Apr 2004 02:17:33 +0200 Received: from ericsson.com (sealwa04-247.sw.ericsson.se [130.100.249.247]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id JRYYZPZT; Fri, 30 Apr 2004 10:17:16 +1000 Message-ID: <40919B0C.3010205@ericsson.com> Date: Fri, 30 Apr 2004 10:17:16 +1000 X-Sybari-Trust: 5b6f32b2 f0b06ce5 33e1adf1 00000139 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aleksandr Ryabin CC: Kevin Boyle , Tom-PT Taylor , megaco@ietf.org Subject: Re: [Megaco] Continuity tests References: <5.2.1.1.0.20040429114553.01e149b8@IL06EXM13.corp.mot.com> In-Reply-To: <5.2.1.1.0.20040429114553.01e149b8@IL06EXM13.corp.mot.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Apr 2004 00:17:32.0597 (UTC) FILETIME=[87E98E50:01C42E48] Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Aleksandr, Is this really a problem? The Continuity test is a link by link procedure not an end to end procedure. I tend to support Kevin and Tom on this one. Regards, Christian Aleksandr Ryabin wrote: > Kevin, exactly, the type of COT test does not only depend on the physical > details of a termination the MGC controls, but also on physical > details of circuit which *eventually* is connected to that termination. > > My point is that the final far-end *final* connection can change without > a change to immediate connection to MG termination and only MGC > would know about it. > > For example, if MG is digital trunking gateway, it does not mean that > only pure 4-wire tests will be used all the time. If the other side > connected > trough set of intermediate switches and finally lands at the time of the > test > say on analog 2-wire circuit then the test to be executed is 2-wire test. > > I guess it is possible to somehow tie up configuration of MG termination > dynamically to changes which happens to those intermediate switches, > but it does not seem right. On the contrary, that information would come to > MGC naturally, since it is a controlling element. > > Also putting a burden of configuring of a test type per every single > termination seems to be too much for MG, especially if we are talking > about high density MGs which handle hundred thousands terminations. > > BTW This is a real problem we run into in our MGC implementation and > are trying to solve. I thought that instead of having a proprietary package > I might as well give it a shot to see if there is any interest to make the > solution public instead. > > Thanks. > Aleks > > At 11:23 AM 4/29/2004, Kevin Boyle wrote: > >> I agree with Tom. The fact that the circuit is connected to a single >> entity means that only a single type of continuity test is actually >> valid. MGs are expected to know how to handle their terminations. >> Who the termination is connected to is certainly part of that >> handling. Because the far-end connection changes the nature of the >> termination, this becomes an MG-knowledge problem. >> >> I believe the package is fine as it stands, and the MG should know >> what "run a continuity test" means for its terminations. >> >> Kevin >> >> -----Original Message----- >> From: Taylor, Tom-PT [CAR:5N00:EXCH] >> Sent: Thursday, April 29, 2004 11:19 AM >> To: Aleksandr Ryabin >> Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org >> Subject: Re: [Megaco] Continuity tests >> >> I for one disagree with your philosophy. I think the physical details >> of the termination should be provisioned in the MG rather than the the >> MGC. However, I have no direct implementation responsibility, so I >> should let those who do speak up. >> >> Aleksandr Ryabin wrote: >> >> > Packages defined in H.248.17 do not cover continuity tests. >> > >> > If the experts agree that MGC should be able to control type of >> > continuity test then ether basic ct package needs to be amended to >> > include new functionality, or H.248.17 needs to be amended to include >> > new "extended" continuity package Commends? Suggestions? >> > >> > Aleks >> > >> > At 01:14 AM 4/29/2004, Zhao Bo wrote: >> > >> >> Can H.248.17 "line test packages" be used to test these circuits? >> >> >> >> ----- Original Message ----- >> >> From: Aleksandr Ryabin >> >> To: Kevin Boyle ; >> >> megaco@ietf.org >> >> Sent: Thursday, April 29, 2004 2:11 AM >> >> Subject: RE: [Megaco] Continuity tests >> >> >> >> Yes, the type of test depends on what a circuit is connected to. >> >> >> >> But, I was actually coming from the view that MGC "controls" MG >> >> and as such only MGC should have knowledge on what test to execute >> >> (i.e. what is connected to the other side of a circuit). >> >> >> >> If this information is left in MG, then each circuit has to be >> >> provisioned >> >> with that information such that MG can make intelligent decision >> >> on what >> >> type of test to execute. Thus every time a circuit connection is >> >> changed, >> >> directly or indirectly, MG circuit needs to be re-provisioned. >> >> >> >> I think that configuration should be kept on MGC and the decision >> >> should >> >> come from MGC instead. >> >> >> >> Aleks >> >> >> >> At 02:30 PM 4/28/2004, Kevin Boyle wrote: >> >> >> >>> Is it possible to run more than one kind of continuity test >> >>> on a particular circuit? If no, then the provisioning model >> >>> holds and there is no need for a change. If yes, then we may >> >>> need to add something to the package to allow selection of a >> >>> ct test type. >> >>> >> >>> Kevin >> >>> >> >>> -----Original Message----- >> >>> From: Aleksandr Ryabin [mailto:kengr@motorola.com] >> >>> Sent: Wednesday, April 28, 2004 1:21 PM >> >>> To: megaco@ietf.org >> >>> Subject: [Megaco] Continuity tests >> >>> >> >>> Hi, >> >>> >> >>> There are several continuity test types (i.e 2-wire, 4-wire, >> >>> etc) While provisioning of physical test parameters (i.e. >> >>> frequencies, sequence, timeouts, etc) in MG makes sense, IMHO >> >>> choosing a type of continuity test seem logical to be left to >> >>> MGC. >> >>> >> >>> Basic Continuity Package (ct) does not allow to choose the >> >>> type of a test. >> >>> It implies that type of a test is provisioned on MG (per >> >>> termination?) >> >>> >> >>> Is there another (extended) continuity test package which >> >>> allows MGC to choose the type of a continuity test to be >> >>> performed? >> >>> >> >>> If not, does anyone see a need to have such a package? >> >>> Comments? >> >>> >> >>> Thanks >> >>> Aleks >> >>> >> >>> _______________________________________________ >> >>> Megaco mailing list >> >>> Megaco@ietf.org >> >>> https://www1.ietf.org/mailman/listinfo/megaco >> >> _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Apr 30 05:15:18 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04671 for ; Fri, 30 Apr 2004 05:15:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJU0y-0001Hr-Up; Fri, 30 Apr 2004 05:09:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJTzs-00011N-Eu for megaco@optimus.ietf.org; Fri, 30 Apr 2004 05:07:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04395 for ; Fri, 30 Apr 2004 05:07:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJTzl-0002yN-Os for megaco@ietf.org; Fri, 30 Apr 2004 05:07:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJTyo-0002qq-00 for megaco@ietf.org; Fri, 30 Apr 2004 05:06:48 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BJTxr-0002cQ-00 for megaco@ietf.org; Fri, 30 Apr 2004 05:05:47 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3U95KW9011772; Fri, 30 Apr 2004 02:05:20 -0700 (PDT) Received: from dea-w2k02.cisco.com (sjc-vpn4-348.cisco.com [10.21.81.92]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASO74002; Fri, 30 Apr 2004 02:04:29 -0700 (PDT) Message-Id: <4.3.2.7.2.20040430020325.02435940@vtg-um-e2k1.cisco.com> X-Sender: dea@vtg-um-e2k1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 30 Apr 2004 02:05:34 -0700 To: Aleksandr Ryabin , From: David Auerbach Subject: RE: [Megaco] Continuity tests In-Reply-To: <5.2.1.1.0.20040429114553.01e149b8@IL06EXM13.corp.mot.com> References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_11306057==_.ALT" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --=====================_11306057==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed COT is not an end to end test. COT is a test between two adjacent switches. Each subsequent switch makes an independent decision to apply COT to the next step of the routing path. David At 12:25 PM 4/29/2004 -0400, Aleksandr Ryabin wrote: >Kevin, exactly, the type of COT test does not only depend on the physical >details of a termination the MGC controls, but also on physical >details of circuit which *eventually* is connected to that termination. > >My point is that the final far-end *final* connection can change without >a change to immediate connection to MG termination and only MGC >would know about it. > >For example, if MG is digital trunking gateway, it does not mean that >only pure 4-wire tests will be used all the time. If the other side connected >trough set of intermediate switches and finally lands at the time of the test >say on analog 2-wire circuit then the test to be executed is 2-wire test. > >I guess it is possible to somehow tie up configuration of MG termination >dynamically to changes which happens to those intermediate switches, >but it does not seem right. On the contrary, that information would come to >MGC naturally, since it is a controlling element. > >Also putting a burden of configuring of a test type per every single >termination seems to be too much for MG, especially if we are talking >about high density MGs which handle hundred thousands terminations. > >BTW This is a real problem we run into in our MGC implementation and >are trying to solve. I thought that instead of having a proprietary package >I might as well give it a shot to see if there is any interest to make the >solution public instead. > >Thanks. > Aleks > >At 11:23 AM 4/29/2004, Kevin Boyle wrote: > >>I agree with Tom. The fact that the circuit is connected to a single >>entity means that only a single type of continuity test is actually >>valid. MGs are expected to know how to handle their terminations. Who >>the termination is connected to is certainly part of that >>handling. Because the far-end connection changes the nature of the >>termination, this becomes an MG-knowledge problem. >> >>I believe the package is fine as it stands, and the MG should know what >>"run a continuity test" means for its terminations. >> >>Kevin >> >>-----Original Message----- >>From: Taylor, Tom-PT [CAR:5N00:EXCH] >>Sent: Thursday, April 29, 2004 11:19 AM >>To: Aleksandr Ryabin >>Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org >>Subject: Re: [Megaco] Continuity tests >> >>I for one disagree with your philosophy. I think the physical details of >>the termination should be provisioned in the MG rather than the the >>MGC. However, I have no direct implementation responsibility, so I >>should let those who do speak up. >> >>Aleksandr Ryabin wrote: >> >> > Packages defined in H.248.17 do not cover continuity tests. >> > >> > If the experts agree that MGC should be able to control type of >> > continuity test then ether basic ct package needs to be amended to >> > include new functionality, or H.248.17 needs to be amended to include >> > new "extended" continuity package Commends? Suggestions? >> > >> > Aleks >> > >> > At 01:14 AM 4/29/2004, Zhao Bo wrote: >> > >> >> Can H.248.17 "line test packages" be used to test these circuits? >> >> >> >> ----- Original Message ----- >> >> From: Aleksandr Ryabin >> <mailto:kengr@motorola.com> >> >> To: Kevin Boyle >> <mailto:kboyle@nortelnetworks.com> ; >> >> megaco@ietf.org <mailto:megaco@ietf.org> >> >> Sent: Thursday, April 29, 2004 2:11 AM >> >> Subject: RE: [Megaco] Continuity tests >> >> >> >> Yes, the type of test depends on what a circuit is connected to. >> >> >> >> But, I was actually coming from the view that MGC "controls" MG >> >> and as such only MGC should have knowledge on what test to execute >> >> (i.e. what is connected to the other side of a circuit). >> >> >> >> If this information is left in MG, then each circuit has to be >> >> provisioned >> >> with that information such that MG can make intelligent decision >> >> on what >> >> type of test to execute. Thus every time a circuit connection is >> >> changed, >> >> directly or indirectly, MG circuit needs to be re-provisioned. >> >> >> >> I think that configuration should be kept on MGC and the decision >> >> should >> >> come from MGC instead. >> >> >> >> Aleks >> >> >> >> At 02:30 PM 4/28/2004, Kevin Boyle wrote: >> >> >> >>> Is it possible to run more than one kind of continuity test >> >>> on a particular circuit? If no, then the provisioning model >> >>> holds and there is no need for a change. If yes, then we may >> >>> need to add something to the package to allow selection of a >> >>> ct test type. >> >>> >> >>> Kevin >> >>> >> >>> -----Original Message----- >> >>> From: Aleksandr Ryabin >> [mailto:kengr@motorola.com] >> >>> Sent: Wednesday, April 28, 2004 1:21 PM >> >>> To: megaco@ietf.org >> >>> Subject: [Megaco] Continuity tests >> >>> >> >>> Hi, >> >>> >> >>> There are several continuity test types (i.e 2-wire, 4-wire, >> >>> etc) While provisioning of physical test parameters (i.e. >> >>> frequencies, sequence, timeouts, etc) in MG makes sense, IMHO >> >>> choosing a type of continuity test seem logical to be left to >> >>> MGC. >> >>> >> >>> Basic Continuity Package (ct) does not allow to choose the >> >>> type of a test. >> >>> It implies that type of a test is provisioned on MG (per >> >>> termination?) >> >>> >> >>> Is there another (extended) continuity test package which >> >>> allows MGC to choose the type of a continuity test to be >> >>> performed? >> >>> >> >>> If not, does anyone see a need to have such a package? >> >>> Comments? >> >>> >> >>> Thanks >> >>> Aleks >> >>> >> >>> _______________________________________________ >> >>> Megaco mailing list >> >>> Megaco@ietf.org >> >>> >> https://www1.ietf.org/mailman/listinfo/megaco >> >> >> --=====================_11306057==_.ALT Content-Type: text/html; charset="us-ascii" COT is not an end to end test.  COT is a test between two adjacent switches.  Each subsequent
switch makes an independent decision to apply COT to the next step of the routing path. 

David

At 12:25 PM 4/29/2004 -0400, Aleksandr Ryabin wrote:
Kevin, exactly, the type of COT test does not only depend on the physical
details of a termination the MGC controls, but also on physical
details of circuit which *eventually* is connected to that termination.

My point is that the final far-end *final* connection can change without
a change to immediate connection to MG termination and only MGC
would know about it.

For example, if MG is digital trunking gateway, it does not mean that
only pure 4-wire tests will be used all the time. If the other side connected
trough set of intermediate switches and finally lands at the time of the test
say on analog 2-wire circuit then the test to be executed is 2-wire test.

I guess it is possible to somehow tie up configuration of MG termination
dynamically to changes which happens to those intermediate switches,
but it does not seem right. On the contrary, that information would come to
MGC naturally, since it is a controlling element.

Also putting a burden of configuring of a test type per every single
termination seems to be too much for MG, especially if we are talking
about high density MGs which handle hundred thousands terminations.

BTW This is a real problem we run into in our MGC implementation and
are trying to solve. I thought that instead of having a proprietary package
I might as well give it a shot to see if there is any interest to make the
solution public instead.

Thanks.
        Aleks

At 11:23 AM 4/29/2004, Kevin Boyle wrote:

I agree with Tom.  The fact that the circuit is connected to a single entity means that only a single type of continuity test is actually valid.  MGs are expected to know how to handle their terminations.  Who the termination is connected to is certainly part of that handling.  Because the far-end connection changes the nature of the termination, this becomes an MG-knowledge problem.

I believe the package is fine as it stands, and the MG should know what "run a continuity test" means for its terminations.

Kevin

-----Original Message-----
From: Taylor, Tom-PT [CAR:5N00:EXCH]
Sent: Thursday, April 29, 2004 11:19 AM
To: Aleksandr Ryabin
Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org
Subject: Re: [Megaco] Continuity tests

I for one disagree with your philosophy.  I think the physical details of the termination should be provisioned in the MG rather than the the MGC.  However, I have no direct implementation responsibility, so I should let those who do speak up.

Aleksandr Ryabin wrote:

> Packages defined in H.248.17 do not cover continuity tests.
>
> If the experts agree that MGC should be able to control type of
> continuity test then ether basic ct package needs to be amended to
> include new functionality, or H.248.17 needs to be amended to include
> new "extended" continuity package Commends? Suggestions?
>
>         Aleks
>
> At 01:14 AM 4/29/2004, Zhao Bo wrote:
>
>> Can H.248.17 "line test packages"  be used to test these circuits?
>>
>>     ----- Original Message -----
>>     From: Aleksandr Ryabin <mailto:kengr@motorola.com>
>>     To: Kevin Boyle <mailto:kboyle@nortelnetworks.com> ;
>>     megaco@ietf.org <mailto:megaco@ietf.org>
>>     Sent: Thursday, April 29, 2004 2:11 AM
>>     Subject: RE: [Megaco] Continuity tests
>>
>>     Yes, the type of test depends on what a circuit is connected to.
>>
>>     But, I was actually coming from the view that MGC "controls" MG
>>     and as such only MGC should have knowledge on what test to execute
>>     (i.e. what is connected to the other side of a circuit).
>>
>>     If this information is left in MG, then each circuit has to be
>>     provisioned
>>     with that information such that MG can make intelligent decision
>>     on what
>>     type of test to execute. Thus every time a circuit connection is
>>     changed,
>>     directly or indirectly, MG circuit needs to be re-provisioned.
>>
>>     I think that configuration should  be kept on MGC and the decision
>>     should
>>     come from MGC instead.
>>
>>             Aleks
>>
>>     At 02:30 PM 4/28/2004, Kevin Boyle wrote:
>>
>>>         Is it possible to run more than one kind of continuity test
>>>         on a particular circuit?  If no, then the provisioning model
>>>         holds and there is no need for a change.  If yes, then we may
>>>         need to add something to the package to allow selection of a
>>>         ct test type.
>>>
>>>         Kevin
>>>
>>>         -----Original Message-----
>>>         From: Aleksandr Ryabin [mailto:kengr@motorola.com]
>>>         Sent: Wednesday, April 28, 2004 1:21 PM
>>>         To: megaco@ietf.org
>>>         Subject: [Megaco] Continuity tests
>>>
>>>         Hi,
>>>
>>>         There are several continuity test types (i.e 2-wire, 4-wire,
>>>         etc) While provisioning of physical test parameters (i.e.
>>>         frequencies, sequence, timeouts, etc) in MG makes sense, IMHO
>>>         choosing a type of continuity test seem logical to be left to
>>>         MGC.
>>>
>>>         Basic Continuity Package (ct) does not allow to choose the
>>>         type of a test.
>>>         It implies that type of a test is provisioned on MG (per
>>>         termination?)
>>>
>>>         Is there another (extended) continuity test package which
>>>         allows MGC to choose the type of a continuity test to be
>>>         performed?
>>>
>>>         If not, does anyone see a need to have such a package?
>>>         Comments?
>>>
>>>         Thanks
>>>                 Aleks
>>>
>>>         _______________________________________________
>>>         Megaco mailing list
>>>         Megaco@ietf.org
>>>         https://www1.ietf.org/mailman/listinfo/megaco
>>
--=====================_11306057==_.ALT-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri Apr 30 05:20:30 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04866 for ; Fri, 30 Apr 2004 05:20:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJUAl-0002R4-N4 for megaco-archive@odin.ietf.org; Fri, 30 Apr 2004 05:19:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3U9J7Pk009362 for megaco-archive@odin.ietf.org; Fri, 30 Apr 2004 05:19:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJU8a-0002DE-1I for megaco-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 05:16:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04730 for ; Fri, 30 Apr 2004 05:16:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJU8T-00048Y-9b for megaco-web-archive@ietf.org; Fri, 30 Apr 2004 05:16:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJU7V-00040a-00 for megaco-web-archive@ietf.org; Fri, 30 Apr 2004 05:15:47 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJU6W-0003sc-00 for megaco-web-archive@ietf.org; Fri, 30 Apr 2004 05:14:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJU0y-0001Hr-Up; Fri, 30 Apr 2004 05:09:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJTzs-00011N-Eu for megaco@optimus.ietf.org; Fri, 30 Apr 2004 05:07:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04395 for ; Fri, 30 Apr 2004 05:07:49 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJTzl-0002yN-Os for megaco@ietf.org; Fri, 30 Apr 2004 05:07:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJTyo-0002qq-00 for megaco@ietf.org; Fri, 30 Apr 2004 05:06:48 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BJTxr-0002cQ-00 for megaco@ietf.org; Fri, 30 Apr 2004 05:05:47 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3U95KW9011772; Fri, 30 Apr 2004 02:05:20 -0700 (PDT) Received: from dea-w2k02.cisco.com (sjc-vpn4-348.cisco.com [10.21.81.92]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id ASO74002; Fri, 30 Apr 2004 02:04:29 -0700 (PDT) Message-Id: <4.3.2.7.2.20040430020325.02435940@vtg-um-e2k1.cisco.com> X-Sender: dea@vtg-um-e2k1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 30 Apr 2004 02:05:34 -0700 To: Aleksandr Ryabin , From: David Auerbach Subject: RE: [Megaco] Continuity tests In-Reply-To: <5.2.1.1.0.20040429114553.01e149b8@IL06EXM13.corp.mot.com> References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_11306057==_.ALT" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 --=====================_11306057==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed COT is not an end to end test. COT is a test between two adjacent switches. Each subsequent switch makes an independent decision to apply COT to the next step of the routing path. David At 12:25 PM 4/29/2004 -0400, Aleksandr Ryabin wrote: >Kevin, exactly, the type of COT test does not only depend on the physical >details of a termination the MGC controls, but also on physical >details of circuit which *eventually* is connected to that termination. > >My point is that the final far-end *final* connection can change without >a change to immediate connection to MG termination and only MGC >would know about it. > >For example, if MG is digital trunking gateway, it does not mean that >only pure 4-wire tests will be used all the time. If the other side connected >trough set of intermediate switches and finally lands at the time of the test >say on analog 2-wire circuit then the test to be executed is 2-wire test. > >I guess it is possible to somehow tie up configuration of MG termination >dynamically to changes which happens to those intermediate switches, >but it does not seem right. On the contrary, that information would come to >MGC naturally, since it is a controlling element. > >Also putting a burden of configuring of a test type per every single >termination seems to be too much for MG, especially if we are talking >about high density MGs which handle hundred thousands terminations. > >BTW This is a real problem we run into in our MGC implementation and >are trying to solve. I thought that instead of having a proprietary package >I might as well give it a shot to see if there is any interest to make the >solution public instead. > >Thanks. > Aleks > >At 11:23 AM 4/29/2004, Kevin Boyle wrote: > >>I agree with Tom. The fact that the circuit is connected to a single >>entity means that only a single type of continuity test is actually >>valid. MGs are expected to know how to handle their terminations. Who >>the termination is connected to is certainly part of that >>handling. Because the far-end connection changes the nature of the >>termination, this becomes an MG-knowledge problem. >> >>I believe the package is fine as it stands, and the MG should know what >>"run a continuity test" means for its terminations. >> >>Kevin >> >>-----Original Message----- >>From: Taylor, Tom-PT [CAR:5N00:EXCH] >>Sent: Thursday, April 29, 2004 11:19 AM >>To: Aleksandr Ryabin >>Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org >>Subject: Re: [Megaco] Continuity tests >> >>I for one disagree with your philosophy. I think the physical details of >>the termination should be provisioned in the MG rather than the the >>MGC. However, I have no direct implementation responsibility, so I >>should let those who do speak up. >> >>Aleksandr Ryabin wrote: >> >> > Packages defined in H.248.17 do not cover continuity tests. >> > >> > If the experts agree that MGC should be able to control type of >> > continuity test then ether basic ct package needs to be amended to >> > include new functionality, or H.248.17 needs to be amended to include >> > new "extended" continuity package Commends? Suggestions? >> > >> > Aleks >> > >> > At 01:14 AM 4/29/2004, Zhao Bo wrote: >> > >> >> Can H.248.17 "line test packages" be used to test these circuits? >> >> >> >> ----- Original Message ----- >> >> From: Aleksandr Ryabin >> <mailto:kengr@motorola.com> >> >> To: Kevin Boyle >> <mailto:kboyle@nortelnetworks.com> ; >> >> megaco@ietf.org <mailto:megaco@ietf.org> >> >> Sent: Thursday, April 29, 2004 2:11 AM >> >> Subject: RE: [Megaco] Continuity tests >> >> >> >> Yes, the type of test depends on what a circuit is connected to. >> >> >> >> But, I was actually coming from the view that MGC "controls" MG >> >> and as such only MGC should have knowledge on what test to execute >> >> (i.e. what is connected to the other side of a circuit). >> >> >> >> If this information is left in MG, then each circuit has to be >> >> provisioned >> >> with that information such that MG can make intelligent decision >> >> on what >> >> type of test to execute. Thus every time a circuit connection is >> >> changed, >> >> directly or indirectly, MG circuit needs to be re-provisioned. >> >> >> >> I think that configuration should be kept on MGC and the decision >> >> should >> >> come from MGC instead. >> >> >> >> Aleks >> >> >> >> At 02:30 PM 4/28/2004, Kevin Boyle wrote: >> >> >> >>> Is it possible to run more than one kind of continuity test >> >>> on a particular circuit? If no, then the provisioning model >> >>> holds and there is no need for a change. If yes, then we may >> >>> need to add something to the package to allow selection of a >> >>> ct test type. >> >>> >> >>> Kevin >> >>> >> >>> -----Original Message----- >> >>> From: Aleksandr Ryabin >> [mailto:kengr@motorola.com] >> >>> Sent: Wednesday, April 28, 2004 1:21 PM >> >>> To: megaco@ietf.org >> >>> Subject: [Megaco] Continuity tests >> >>> >> >>> Hi, >> >>> >> >>> There are several continuity test types (i.e 2-wire, 4-wire, >> >>> etc) While provisioning of physical test parameters (i.e. >> >>> frequencies, sequence, timeouts, etc) in MG makes sense, IMHO >> >>> choosing a type of continuity test seem logical to be left to >> >>> MGC. >> >>> >> >>> Basic Continuity Package (ct) does not allow to choose the >> >>> type of a test. >> >>> It implies that type of a test is provisioned on MG (per >> >>> termination?) >> >>> >> >>> Is there another (extended) continuity test package which >> >>> allows MGC to choose the type of a continuity test to be >> >>> performed? >> >>> >> >>> If not, does anyone see a need to have such a package? >> >>> Comments? >> >>> >> >>> Thanks >> >>> Aleks >> >>> >> >>> _______________________________________________ >> >>> Megaco mailing list >> >>> Megaco@ietf.org >> >>> >> https://www1.ietf.org/mailman/listinfo/megaco >> >> >> --=====================_11306057==_.ALT Content-Type: text/html; charset="us-ascii" COT is not an end to end test.  COT is a test between two adjacent switches.  Each subsequent
switch makes an independent decision to apply COT to the next step of the routing path. 

David

At 12:25 PM 4/29/2004 -0400, Aleksandr Ryabin wrote:
Kevin, exactly, the type of COT test does not only depend on the physical
details of a termination the MGC controls, but also on physical
details of circuit which *eventually* is connected to that termination.

My point is that the final far-end *final* connection can change without
a change to immediate connection to MG termination and only MGC
would know about it.

For example, if MG is digital trunking gateway, it does not mean that
only pure 4-wire tests will be used all the time. If the other side connected
trough set of intermediate switches and finally lands at the time of the test
say on analog 2-wire circuit then the test to be executed is 2-wire test.

I guess it is possible to somehow tie up configuration of MG termination
dynamically to changes which happens to those intermediate switches,
but it does not seem right. On the contrary, that information would come to
MGC naturally, since it is a controlling element.

Also putting a burden of configuring of a test type per every single
termination seems to be too much for MG, especially if we are talking
about high density MGs which handle hundred thousands terminations.

BTW This is a real problem we run into in our MGC implementation and
are trying to solve. I thought that instead of having a proprietary package
I might as well give it a shot to see if there is any interest to make the
solution public instead.

Thanks.
        Aleks

At 11:23 AM 4/29/2004, Kevin Boyle wrote:

I agree with Tom.  The fact that the circuit is connected to a single entity means that only a single type of continuity test is actually valid.  MGs are expected to know how to handle their terminations.  Who the termination is connected to is certainly part of that handling.  Because the far-end connection changes the nature of the termination, this becomes an MG-knowledge problem.

I believe the package is fine as it stands, and the MG should know what "run a continuity test" means for its terminations.

Kevin

-----Original Message-----
From: Taylor, Tom-PT [CAR:5N00:EXCH]
Sent: Thursday, April 29, 2004 11:19 AM
To: Aleksandr Ryabin
Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org
Subject: Re: [Megaco] Continuity tests

I for one disagree with your philosophy.  I think the physical details of the termination should be provisioned in the MG rather than the the MGC.  However, I have no direct implementation responsibility, so I should let those who do speak up.

Aleksandr Ryabin wrote:

> Packages defined in H.248.17 do not cover continuity tests.
>
> If the experts agree that MGC should be able to control type of
> continuity test then ether basic ct package needs to be amended to
> include new functionality, or H.248.17 needs to be amended to include
> new "extended" continuity package Commends? Suggestions?
>
>         Aleks
>
> At 01:14 AM 4/29/2004, Zhao Bo wrote:
>
>> Can H.248.17 "line test packages"  be used to test these circuits?
>>
>>     ----- Original Message -----
>>     From: Aleksandr Ryabin <mailto:kengr@motorola.com>
>>     To: Kevin Boyle <mailto:kboyle@nortelnetworks.com> ;
>>     megaco@ietf.org <mailto:megaco@ietf.org>
>>     Sent: Thursday, April 29, 2004 2:11 AM
>>     Subject: RE: [Megaco] Continuity tests
>>
>>     Yes, the type of test depends on what a circuit is connected to.
>>
>>     But, I was actually coming from the view that MGC "controls" MG
>>     and as such only MGC should have knowledge on what test to execute
>>     (i.e. what is connected to the other side of a circuit).
>>
>>     If this information is left in MG, then each circuit has to be
>>     provisioned
>>     with that information such that MG can make intelligent decision
>>     on what
>>     type of test to execute. Thus every time a circuit connection is
>>     changed,
>>     directly or indirectly, MG circuit needs to be re-provisioned.
>>
>>     I think that configuration should  be kept on MGC and the decision
>>     should
>>     come from MGC instead.
>>
>>             Aleks
>>
>>     At 02:30 PM 4/28/2004, Kevin Boyle wrote:
>>
>>>         Is it possible to run more than one kind of continuity test
>>>         on a particular circuit?  If no, then the provisioning model
>>>         holds and there is no need for a change.  If yes, then we may
>>>         need to add something to the package to allow selection of a
>>>         ct test type.
>>>
>>>         Kevin
>>>
>>>         -----Original Message-----
>>>         From: Aleksandr Ryabin [mailto:kengr@motorola.com]
>>>         Sent: Wednesday, April 28, 2004 1:21 PM
>>>         To: megaco@ietf.org
>>>         Subject: [Megaco] Continuity tests
>>>
>>>         Hi,
>>>
>>>         There are several continuity test types (i.e 2-wire, 4-wire,
>>>         etc) While provisioning of physical test parameters (i.e.
>>>         frequencies, sequence, timeouts, etc) in MG makes sense, IMHO
>>>         choosing a type of continuity test seem logical to be left to
>>>         MGC.
>>>
>>>         Basic Continuity Package (ct) does not allow to choose the
>>>         type of a test.
>>>         It implies that type of a test is provisioned on MG (per
>>>         termination?)
>>>
>>>         Is there another (extended) continuity test package which
>>>         allows MGC to choose the type of a continuity test to be
>>>         performed?
>>>
>>>         If not, does anyone see a need to have such a package?
>>>         Comments?
>>>
>>>         Thanks
>>>                 Aleks
>>>
>>>         _______________________________________________
>>>         Megaco mailing list
>>>         Megaco@ietf.org
>>>         https://www1.ietf.org/mailman/listinfo/megaco
>>
--=====================_11306057==_.ALT-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Apr 30 09:37:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01192 for ; Fri, 30 Apr 2004 09:37:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJY5e-0001Jw-Fw; Fri, 30 Apr 2004 09:30:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJD00-0007wN-JU for megaco@optimus.ietf.org; Thu, 29 Apr 2004 10:58:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07487 for ; Thu, 29 Apr 2004 10:58:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJCzp-0006iN-6n for megaco@ietf.org; Thu, 29 Apr 2004 10:58:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJCyt-0006QU-00 for megaco@ietf.org; Thu, 29 Apr 2004 10:57:43 -0400 Received: from webmail.brixnet.com ([63.122.27.38] helo=brixcorp2.brixnet.com) by ietf-mx with esmtp (Exim 4.12) id 1BJCy5-00066U-00 for megaco@ietf.org; Thu, 29 Apr 2004 10:56:53 -0400 Received: by mail.brixnet.com with Internet Mail Service (5.5.2657.72) id <2CSJGDSL>; Thu, 29 Apr 2004 10:56:25 -0400 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB0302D345@mail.brixnet.com> From: "Naylor, Bob" To: "'megaco@ietf.org'" Date: Thu, 29 Apr 2004 10:56:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Megaco] caller ID? Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hello, Can anyone tell me if caller id is supported in any way within H.248? Thanks. Bob Naylor _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri Apr 30 09:47:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01546 for ; Fri, 30 Apr 2004 09:47:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJYGB-0003U0-NG for megaco-archive@odin.ietf.org; Fri, 30 Apr 2004 09:40:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UDexAp013378 for megaco-archive@odin.ietf.org; Fri, 30 Apr 2004 09:40:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJYDT-0002jJ-5R for megaco-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 09:38:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01253 for ; Fri, 30 Apr 2004 09:38:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJYDR-0002Us-AU for megaco-web-archive@ietf.org; Fri, 30 Apr 2004 09:38:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJYCS-0002Ke-00 for megaco-web-archive@ietf.org; Fri, 30 Apr 2004 09:37:09 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJYBy-0002AK-00 for megaco-web-archive@ietf.org; Fri, 30 Apr 2004 09:36:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJY5e-0001Jw-Fw; Fri, 30 Apr 2004 09:30:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJD00-0007wN-JU for megaco@optimus.ietf.org; Thu, 29 Apr 2004 10:58:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07487 for ; Thu, 29 Apr 2004 10:58:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJCzp-0006iN-6n for megaco@ietf.org; Thu, 29 Apr 2004 10:58:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJCyt-0006QU-00 for megaco@ietf.org; Thu, 29 Apr 2004 10:57:43 -0400 Received: from webmail.brixnet.com ([63.122.27.38] helo=brixcorp2.brixnet.com) by ietf-mx with esmtp (Exim 4.12) id 1BJCy5-00066U-00 for megaco@ietf.org; Thu, 29 Apr 2004 10:56:53 -0400 Received: by mail.brixnet.com with Internet Mail Service (5.5.2657.72) id <2CSJGDSL>; Thu, 29 Apr 2004 10:56:25 -0400 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB0302D345@mail.brixnet.com> From: "Naylor, Bob" To: "'megaco@ietf.org'" Date: Thu, 29 Apr 2004 10:56:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: [Megaco] caller ID? Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hello, Can anyone tell me if caller id is supported in any way within H.248? Thanks. Bob Naylor _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Apr 30 10:01:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02125 for ; Fri, 30 Apr 2004 10:01:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJYTl-0005Aw-LM; Fri, 30 Apr 2004 09:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJYS2-0004nG-AD for megaco@optimus.ietf.org; Fri, 30 Apr 2004 09:53:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01792 for ; Fri, 30 Apr 2004 09:53:09 -0400 (EDT) From: Albrecht.Schwarz@alcatel.de Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJYS0-0003oe-Fl for megaco@ietf.org; Fri, 30 Apr 2004 09:53:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJYQx-0003lS-00 for megaco@ietf.org; Fri, 30 Apr 2004 09:52:07 -0400 Received: from mailrelay1.alcatel.de ([194.113.59.75] helo=mailrelay2.alcatel.de) by ietf-mx with esmtp (Exim 4.12) id 1BJYQ2-0003gw-00; Fri, 30 Apr 2004 09:51:10 -0400 Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr [155.132.182.205]) by mailrelay2.alcatel.de (8.12.10/8.12.10) with ESMTP id i3UDoKV1021474; Fri, 30 Apr 2004 13:50:20 GMT To: Christian Groves Cc: megaco@ietf.org, megaco-admin@ietf.org, Tom Taylor , Troy Cauble X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Fri, 30 Apr 2004 15:50:20 +0200 X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/30/2004 15:50:20 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-virus-scanned: i3UDoKV1021474 at mailrelay2.alcatel.de X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Subject: [Megaco] Textual Coding of H.248.1 Annex C; Re: Signaling of UDI rsp Clearmode Bearer Service; Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hello All! Thread was originating from us. ALCATEL's preference is still the proposed solution of a textual codepoint for Annex C, indicated in http://www1.ietf.org/mail-archive/working-groups/megaco/current/msg05068.html http://www1.ietf.org/mail-archive/working-groups/megaco/current/msg05069.html Of course, we didn't made a comprehensive analysis up to now by investigating all potential impacts. I'll formulate at least our current view in an contribution for the next Rapporteurs meeting. Best regards, Albrecht ALCATEL |---------+-------------------------------> | | Christian Groves | | | | | | Sent by: | | | megaco-admin@ietf.or| | | g | | | | | | | | | 30.04.2004 00:52 | | | | |---------+-------------------------------> >------------------------------------------------------------------------------------------------------------| | | | To: Tom Taylor | | cc: Troy Cauble , megaco@ietf.org | | Subject: Re: Signaling of UDI rsp Clearmode Bearer Service; Re: TDM Hairpinning; Re: [Megaco] | | Hairpin case A/u Law conversion | >------------------------------------------------------------------------------------------------------------| Hello Tom, Kevin, Troy, It's not about replicating the values it's about the packageid/property ID itself. You can't simply remove it if it's in use. If you want to progress down the path of defining TMR and USI for SDP then it's OK by me. I didn't raise the need for TMR/USI in text in the first place. Those wanting it should speak up about their preference. If we do go down the way of putting TMR and USI in SDP then I think all we should do is simply carry the TMR/USI in SDP. I don't think there's any point in exploding the octets to individual text descriptions as you have done in the draft. Regards, Christian Tom Taylor wrote: > We can replicate the binary values for the TMR and USI, and reassign the > packageId for them. > > However, if necessary, I can revive my I-D on SDP encoding of TMR/USI. > I dropped it for lack of apparent interest. > > Christian Groves wrote: > >> Hello Troy, Tom and Kevin, >> >> I agree Annex C is not a package however it does use the same method >> of referencing the properties ie. packageId/propertyID where in the >> binary case the packageId is 0000. >> >> However USI and TMR is being used by implementations so we can't >> simply deprecate Annex C as some seem to indicate. We have seen a case >> where TMR/USI would be useful for text implementations. There are >> several options here. As USI/TMR are already being used by binary >> implementations it isn't appropriate to make changes to this, which >> essentially a new package would be. This leaves modifications for the >> text encoding. I thought the easiest way would be to use the H.248.15 >> to carry the property, the side effect being a "packageID" would be >> needed. This seemed to be simplest method, keeps it in the H.248 >> domain and is in the WGs control. The other method would be to define >> SDP to carry the octets for USI/TMR. This will muddy the water has >> people will think this relates to SIP in some way. This will probably >> take some time to sort out. >> >> If we had our time again I would have prefered the use of packages >> only (no Annex C/no SDP) ;). >> >> Regards, Christian >> > ... > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri Apr 30 10:08:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02899 for ; Fri, 30 Apr 2004 10:08:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJYfg-0001uq-Nn for megaco-archive@odin.ietf.org; Fri, 30 Apr 2004 10:07:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UE7Kp9007362 for megaco-archive@odin.ietf.org; Fri, 30 Apr 2004 10:07:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJYag-0007lL-9D for megaco-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 10:02:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02176 for ; Fri, 30 Apr 2004 10:02:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJYae-0004EO-8u for megaco-web-archive@ietf.org; Fri, 30 Apr 2004 10:02:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJYZn-0004Bb-00 for megaco-web-archive@ietf.org; Fri, 30 Apr 2004 10:01:16 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJYZQ-00049K-00 for megaco-web-archive@ietf.org; Fri, 30 Apr 2004 10:00:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJYTl-0005Aw-LM; Fri, 30 Apr 2004 09:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJYS2-0004nG-AD for megaco@optimus.ietf.org; Fri, 30 Apr 2004 09:53:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01792 for ; Fri, 30 Apr 2004 09:53:09 -0400 (EDT) From: Albrecht.Schwarz@alcatel.de Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJYS0-0003oe-Fl for megaco@ietf.org; Fri, 30 Apr 2004 09:53:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJYQx-0003lS-00 for megaco@ietf.org; Fri, 30 Apr 2004 09:52:07 -0400 Received: from mailrelay1.alcatel.de ([194.113.59.75] helo=mailrelay2.alcatel.de) by ietf-mx with esmtp (Exim 4.12) id 1BJYQ2-0003gw-00; Fri, 30 Apr 2004 09:51:10 -0400 Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr [155.132.182.205]) by mailrelay2.alcatel.de (8.12.10/8.12.10) with ESMTP id i3UDoKV1021474; Fri, 30 Apr 2004 13:50:20 GMT To: Christian Groves Cc: megaco@ietf.org, megaco-admin@ietf.org, Tom Taylor , Troy Cauble X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Fri, 30 Apr 2004 15:50:20 +0200 X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.11 |July 24, 2002) at 04/30/2004 15:50:20 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-virus-scanned: i3UDoKV1021474 at mailrelay2.alcatel.de Subject: [Megaco] Textual Coding of H.248.1 Annex C; Re: Signaling of UDI rsp Clearmode Bearer Service; Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Hello All! Thread was originating from us. ALCATEL's preference is still the proposed solution of a textual codepoint for Annex C, indicated in http://www1.ietf.org/mail-archive/working-groups/megaco/current/msg05068.html http://www1.ietf.org/mail-archive/working-groups/megaco/current/msg05069.html Of course, we didn't made a comprehensive analysis up to now by investigating all potential impacts. I'll formulate at least our current view in an contribution for the next Rapporteurs meeting. Best regards, Albrecht ALCATEL |---------+-------------------------------> | | Christian Groves | | | | | | Sent by: | | | megaco-admin@ietf.or| | | g | | | | | | | | | 30.04.2004 00:52 | | | | |---------+-------------------------------> >------------------------------------------------------------------------------------------------------------| | | | To: Tom Taylor | | cc: Troy Cauble , megaco@ietf.org | | Subject: Re: Signaling of UDI rsp Clearmode Bearer Service; Re: TDM Hairpinning; Re: [Megaco] | | Hairpin case A/u Law conversion | >------------------------------------------------------------------------------------------------------------| Hello Tom, Kevin, Troy, It's not about replicating the values it's about the packageid/property ID itself. You can't simply remove it if it's in use. If you want to progress down the path of defining TMR and USI for SDP then it's OK by me. I didn't raise the need for TMR/USI in text in the first place. Those wanting it should speak up about their preference. If we do go down the way of putting TMR and USI in SDP then I think all we should do is simply carry the TMR/USI in SDP. I don't think there's any point in exploding the octets to individual text descriptions as you have done in the draft. Regards, Christian Tom Taylor wrote: > We can replicate the binary values for the TMR and USI, and reassign the > packageId for them. > > However, if necessary, I can revive my I-D on SDP encoding of TMR/USI. > I dropped it for lack of apparent interest. > > Christian Groves wrote: > >> Hello Troy, Tom and Kevin, >> >> I agree Annex C is not a package however it does use the same method >> of referencing the properties ie. packageId/propertyID where in the >> binary case the packageId is 0000. >> >> However USI and TMR is being used by implementations so we can't >> simply deprecate Annex C as some seem to indicate. We have seen a case >> where TMR/USI would be useful for text implementations. There are >> several options here. As USI/TMR are already being used by binary >> implementations it isn't appropriate to make changes to this, which >> essentially a new package would be. This leaves modifications for the >> text encoding. I thought the easiest way would be to use the H.248.15 >> to carry the property, the side effect being a "packageID" would be >> needed. This seemed to be simplest method, keeps it in the H.248 >> domain and is in the WGs control. The other method would be to define >> SDP to carry the octets for USI/TMR. This will muddy the water has >> people will think this relates to SIP in some way. This will probably >> take some time to sort out. >> >> If we had our time again I would have prefered the use of packages >> only (no Annex C/no SDP) ;). >> >> Regards, Christian >> > ... > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Apr 30 11:06:47 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06563 for ; Fri, 30 Apr 2004 11:06:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZNx-0003an-KD; Fri, 30 Apr 2004 10:53:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZDB-0001hc-AI for megaco@optimus.ietf.org; Fri, 30 Apr 2004 10:41:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05209 for ; Fri, 30 Apr 2004 10:41:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJZD8-00062C-UQ for megaco@ietf.org; Fri, 30 Apr 2004 10:41:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJZC7-0005ur-00 for megaco@ietf.org; Fri, 30 Apr 2004 10:40:52 -0400 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 1BJZBB-0005mL-00 for megaco@ietf.org; Fri, 30 Apr 2004 10:39:53 -0400 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id i3UEdp0n015054; Fri, 30 Apr 2004 07:39:52 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i3UEdm03005284; Fri, 30 Apr 2004 09:39:49 -0500 Message-Id: <5.2.1.1.0.20040430103240.04d9b250@IL06EXM13.corp.mot.com> X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 30 Apr 2004 10:39:14 -0400 To: Christian Groves, From: Aleksandr Ryabin Subject: Re: [Megaco] Continuity tests Cc: Kevin Boyle, Tom-PT Taylor In-Reply-To: <40919B0C.3010205@ericsson.com> References: <5.2.1.1.0.20040429114553.01e149b8@IL06EXM13.corp.mot.com> <5.2.1.1.0.20040429114553.01e149b8@IL06EXM13.corp.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL autolearn=no version=2.60 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi Christian, There could be "dumb" switches in the middle of the path (for example DACS) which are not capable of any testing/signalling. Their only role is to split/redirect links and as such the nature of a circuit can change, and thus the type of COT test. Regards, Aleks At 08:17 PM 4/29/2004, Christian Groves wrote: >Hello Aleksandr, > >Is this really a problem? The Continuity test is a link by link procedure >not an end to end procedure. I tend to support Kevin and Tom on this one. > >Regards, Christian > >Aleksandr Ryabin wrote: >>Kevin, exactly, the type of COT test does not only depend on the physical >>details of a termination the MGC controls, but also on physical >>details of circuit which *eventually* is connected to that termination. >>My point is that the final far-end *final* connection can change without >>a change to immediate connection to MG termination and only MGC >>would know about it. >>For example, if MG is digital trunking gateway, it does not mean that >>only pure 4-wire tests will be used all the time. If the other side connected >>trough set of intermediate switches and finally lands at the time of the test >>say on analog 2-wire circuit then the test to be executed is 2-wire test. >>I guess it is possible to somehow tie up configuration of MG termination >>dynamically to changes which happens to those intermediate switches, >>but it does not seem right. On the contrary, that information would come to >>MGC naturally, since it is a controlling element. >>Also putting a burden of configuring of a test type per every single >>termination seems to be too much for MG, especially if we are talking >>about high density MGs which handle hundred thousands terminations. >>BTW This is a real problem we run into in our MGC implementation and >>are trying to solve. I thought that instead of having a proprietary package >>I might as well give it a shot to see if there is any interest to make the >>solution public instead. >>Thanks. >> Aleks >>At 11:23 AM 4/29/2004, Kevin Boyle wrote: >> >>>I agree with Tom. The fact that the circuit is connected to a single >>>entity means that only a single type of continuity test is actually >>>valid. MGs are expected to know how to handle their terminations. >>>Who the termination is connected to is certainly part of that >>>handling. Because the far-end connection changes the nature of the >>>termination, this becomes an MG-knowledge problem. >>> >>>I believe the package is fine as it stands, and the MG should know what >>>"run a continuity test" means for its terminations. >>> >>>Kevin >>> >>>-----Original Message----- >>>From: Taylor, Tom-PT [CAR:5N00:EXCH] >>>Sent: Thursday, April 29, 2004 11:19 AM >>>To: Aleksandr Ryabin >>>Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org >>>Subject: Re: [Megaco] Continuity tests >>> >>>I for one disagree with your philosophy. I think the physical details >>>of the termination should be provisioned in the MG rather than the the >>>MGC. However, I have no direct implementation responsibility, so I >>>should let those who do speak up. >>> >>>Aleksandr Ryabin wrote: >>> >>> > Packages defined in H.248.17 do not cover continuity tests. >>> > >>> > If the experts agree that MGC should be able to control type of >>> > continuity test then ether basic ct package needs to be amended to >>> > include new functionality, or H.248.17 needs to be amended to include >>> > new "extended" continuity package Commends? Suggestions? >>> > >>> > Aleks >>> > >>> > At 01:14 AM 4/29/2004, Zhao Bo wrote: >>> > >>> >> Can H.248.17 "line test packages" be used to test these circuits? >>> >> >>> >> ----- Original Message ----- >>> >> From: Aleksandr Ryabin >>> >> To: Kevin Boyle ; >>> >> megaco@ietf.org >>> >> Sent: Thursday, April 29, 2004 2:11 AM >>> >> Subject: RE: [Megaco] Continuity tests >>> >> >>> >> Yes, the type of test depends on what a circuit is connected to. >>> >> >>> >> But, I was actually coming from the view that MGC "controls" MG >>> >> and as such only MGC should have knowledge on what test to execute >>> >> (i.e. what is connected to the other side of a circuit). >>> >> >>> >> If this information is left in MG, then each circuit has to be >>> >> provisioned >>> >> with that information such that MG can make intelligent decision >>> >> on what >>> >> type of test to execute. Thus every time a circuit connection is >>> >> changed, >>> >> directly or indirectly, MG circuit needs to be re-provisioned. >>> >> >>> >> I think that configuration should be kept on MGC and the decision >>> >> should >>> >> come from MGC instead. >>> >> >>> >> Aleks >>> >> >>> >> At 02:30 PM 4/28/2004, Kevin Boyle wrote: >>> >> >>> >>> Is it possible to run more than one kind of continuity test >>> >>> on a particular circuit? If no, then the provisioning model >>> >>> holds and there is no need for a change. If yes, then we may >>> >>> need to add something to the package to allow selection of a >>> >>> ct test type. >>> >>> >>> >>> Kevin >>> >>> >>> >>> -----Original Message----- >>> >>> From: Aleksandr Ryabin [mailto:kengr@motorola.com] >>> >>> Sent: Wednesday, April 28, 2004 1:21 PM >>> >>> To: megaco@ietf.org >>> >>> Subject: [Megaco] Continuity tests >>> >>> >>> >>> Hi, >>> >>> >>> >>> There are several continuity test types (i.e 2-wire, 4-wire, >>> >>> etc) While provisioning of physical test parameters (i.e. >>> >>> frequencies, sequence, timeouts, etc) in MG makes sense, IMHO >>> >>> choosing a type of continuity test seem logical to be left to >>> >>> MGC. >>> >>> >>> >>> Basic Continuity Package (ct) does not allow to choose the >>> >>> type of a test. >>> >>> It implies that type of a test is provisioned on MG (per >>> >>> termination?) >>> >>> >>> >>> Is there another (extended) continuity test package which >>> >>> allows MGC to choose the type of a continuity test to be >>> >>> performed? >>> >>> >>> >>> If not, does anyone see a need to have such a package? >>> >>> Comments? >>> >>> >>> >>> Thanks >>> >>> Aleks >>> >>> >>> >>> _______________________________________________ >>> >>> Megaco mailing list >>> >>> Megaco@ietf.org >>> >>> https://www1.ietf.org/mailman/listinfo/megaco >>> >> _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri Apr 30 11:27:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08281 for ; Fri, 30 Apr 2004 11:27:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZpQ-0000U3-A5 for megaco-archive@odin.ietf.org; Fri, 30 Apr 2004 11:21:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UFLS4Y001860 for megaco-archive@odin.ietf.org; Fri, 30 Apr 2004 11:21:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZcV-0006ik-SX for megaco-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 11:08:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06623 for ; Fri, 30 Apr 2004 11:08:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJZcT-0007TC-9V for megaco-web-archive@ietf.org; Fri, 30 Apr 2004 11:08:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJZba-0007RH-00 for megaco-web-archive@ietf.org; Fri, 30 Apr 2004 11:07:11 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJZal-0007Nw-00 for megaco-web-archive@ietf.org; Fri, 30 Apr 2004 11:06:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZNx-0003an-KD; Fri, 30 Apr 2004 10:53:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJZDB-0001hc-AI for megaco@optimus.ietf.org; Fri, 30 Apr 2004 10:41:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05209 for ; Fri, 30 Apr 2004 10:41:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJZD8-00062C-UQ for megaco@ietf.org; Fri, 30 Apr 2004 10:41:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJZC7-0005ur-00 for megaco@ietf.org; Fri, 30 Apr 2004 10:40:52 -0400 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 1BJZBB-0005mL-00 for megaco@ietf.org; Fri, 30 Apr 2004 10:39:53 -0400 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id i3UEdp0n015054; Fri, 30 Apr 2004 07:39:52 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i3UEdm03005284; Fri, 30 Apr 2004 09:39:49 -0500 Message-Id: <5.2.1.1.0.20040430103240.04d9b250@IL06EXM13.corp.mot.com> X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 30 Apr 2004 10:39:14 -0400 To: Christian Groves, From: Aleksandr Ryabin Subject: Re: [Megaco] Continuity tests Cc: Kevin Boyle, Tom-PT Taylor In-Reply-To: <40919B0C.3010205@ericsson.com> References: <5.2.1.1.0.20040429114553.01e149b8@IL06EXM13.corp.mot.com> <5.2.1.1.0.20040429114553.01e149b8@IL06EXM13.corp.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL autolearn=no version=2.60 Hi Christian, There could be "dumb" switches in the middle of the path (for example DACS) which are not capable of any testing/signalling. Their only role is to split/redirect links and as such the nature of a circuit can change, and thus the type of COT test. Regards, Aleks At 08:17 PM 4/29/2004, Christian Groves wrote: >Hello Aleksandr, > >Is this really a problem? The Continuity test is a link by link procedure >not an end to end procedure. I tend to support Kevin and Tom on this one. > >Regards, Christian > >Aleksandr Ryabin wrote: >>Kevin, exactly, the type of COT test does not only depend on the physical >>details of a termination the MGC controls, but also on physical >>details of circuit which *eventually* is connected to that termination. >>My point is that the final far-end *final* connection can change without >>a change to immediate connection to MG termination and only MGC >>would know about it. >>For example, if MG is digital trunking gateway, it does not mean that >>only pure 4-wire tests will be used all the time. If the other side connected >>trough set of intermediate switches and finally lands at the time of the test >>say on analog 2-wire circuit then the test to be executed is 2-wire test. >>I guess it is possible to somehow tie up configuration of MG termination >>dynamically to changes which happens to those intermediate switches, >>but it does not seem right. On the contrary, that information would come to >>MGC naturally, since it is a controlling element. >>Also putting a burden of configuring of a test type per every single >>termination seems to be too much for MG, especially if we are talking >>about high density MGs which handle hundred thousands terminations. >>BTW This is a real problem we run into in our MGC implementation and >>are trying to solve. I thought that instead of having a proprietary package >>I might as well give it a shot to see if there is any interest to make the >>solution public instead. >>Thanks. >> Aleks >>At 11:23 AM 4/29/2004, Kevin Boyle wrote: >> >>>I agree with Tom. The fact that the circuit is connected to a single >>>entity means that only a single type of continuity test is actually >>>valid. MGs are expected to know how to handle their terminations. >>>Who the termination is connected to is certainly part of that >>>handling. Because the far-end connection changes the nature of the >>>termination, this becomes an MG-knowledge problem. >>> >>>I believe the package is fine as it stands, and the MG should know what >>>"run a continuity test" means for its terminations. >>> >>>Kevin >>> >>>-----Original Message----- >>>From: Taylor, Tom-PT [CAR:5N00:EXCH] >>>Sent: Thursday, April 29, 2004 11:19 AM >>>To: Aleksandr Ryabin >>>Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org >>>Subject: Re: [Megaco] Continuity tests >>> >>>I for one disagree with your philosophy. I think the physical details >>>of the termination should be provisioned in the MG rather than the the >>>MGC. However, I have no direct implementation responsibility, so I >>>should let those who do speak up. >>> >>>Aleksandr Ryabin wrote: >>> >>> > Packages defined in H.248.17 do not cover continuity tests. >>> > >>> > If the experts agree that MGC should be able to control type of >>> > continuity test then ether basic ct package needs to be amended to >>> > include new functionality, or H.248.17 needs to be amended to include >>> > new "extended" continuity package Commends? Suggestions? >>> > >>> > Aleks >>> > >>> > At 01:14 AM 4/29/2004, Zhao Bo wrote: >>> > >>> >> Can H.248.17 "line test packages" be used to test these circuits? >>> >> >>> >> ----- Original Message ----- >>> >> From: Aleksandr Ryabin >>> >> To: Kevin Boyle ; >>> >> megaco@ietf.org >>> >> Sent: Thursday, April 29, 2004 2:11 AM >>> >> Subject: RE: [Megaco] Continuity tests >>> >> >>> >> Yes, the type of test depends on what a circuit is connected to. >>> >> >>> >> But, I was actually coming from the view that MGC "controls" MG >>> >> and as such only MGC should have knowledge on what test to execute >>> >> (i.e. what is connected to the other side of a circuit). >>> >> >>> >> If this information is left in MG, then each circuit has to be >>> >> provisioned >>> >> with that information such that MG can make intelligent decision >>> >> on what >>> >> type of test to execute. Thus every time a circuit connection is >>> >> changed, >>> >> directly or indirectly, MG circuit needs to be re-provisioned. >>> >> >>> >> I think that configuration should be kept on MGC and the decision >>> >> should >>> >> come from MGC instead. >>> >> >>> >> Aleks >>> >> >>> >> At 02:30 PM 4/28/2004, Kevin Boyle wrote: >>> >> >>> >>> Is it possible to run more than one kind of continuity test >>> >>> on a particular circuit? If no, then the provisioning model >>> >>> holds and there is no need for a change. If yes, then we may >>> >>> need to add something to the package to allow selection of a >>> >>> ct test type. >>> >>> >>> >>> Kevin >>> >>> >>> >>> -----Original Message----- >>> >>> From: Aleksandr Ryabin [mailto:kengr@motorola.com] >>> >>> Sent: Wednesday, April 28, 2004 1:21 PM >>> >>> To: megaco@ietf.org >>> >>> Subject: [Megaco] Continuity tests >>> >>> >>> >>> Hi, >>> >>> >>> >>> There are several continuity test types (i.e 2-wire, 4-wire, >>> >>> etc) While provisioning of physical test parameters (i.e. >>> >>> frequencies, sequence, timeouts, etc) in MG makes sense, IMHO >>> >>> choosing a type of continuity test seem logical to be left to >>> >>> MGC. >>> >>> >>> >>> Basic Continuity Package (ct) does not allow to choose the >>> >>> type of a test. >>> >>> It implies that type of a test is provisioned on MG (per >>> >>> termination?) >>> >>> >>> >>> Is there another (extended) continuity test package which >>> >>> allows MGC to choose the type of a continuity test to be >>> >>> performed? >>> >>> >>> >>> If not, does anyone see a need to have such a package? >>> >>> Comments? >>> >>> >>> >>> Thanks >>> >>> Aleks >>> >>> >>> >>> _______________________________________________ >>> >>> Megaco mailing list >>> >>> Megaco@ietf.org >>> >>> https://www1.ietf.org/mailman/listinfo/megaco >>> >> _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Apr 30 11:50:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10519 for ; Fri, 30 Apr 2004 11:50:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJa8M-00056b-TS; Fri, 30 Apr 2004 11:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJa2t-0003Fl-LQ for megaco@optimus.ietf.org; Fri, 30 Apr 2004 11:35:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08971 for ; Fri, 30 Apr 2004 11:35:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJa2s-00023y-DG for megaco@ietf.org; Fri, 30 Apr 2004 11:35:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJa1v-0001xx-00 for megaco@ietf.org; Fri, 30 Apr 2004 11:34:23 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1BJa1C-0001nk-00 for megaco@ietf.org; Fri, 30 Apr 2004 11:33:38 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3UFX5a16934 for ; Fri, 30 Apr 2004 11:33:05 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Apr 2004 11:33:06 -0400 Message-ID: From: "Kevin Boyle" To: "Naylor, Bob" , "'megaco@ietf.org'" Subject: RE: [Megaco] caller ID? Date: Fri, 30 Apr 2004 11:32:58 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Yes, I can tell you. Yes, it is. See H.248.23. Kevin -----Original Message----- From: Naylor, Bob [mailto:bnaylor@brixnet.com] Sent: Thursday, April 29, 2004 10:56 AM To: 'megaco@ietf.org' Subject: [Megaco] caller ID? Hello, Can anyone tell me if caller id is supported in any way within H.248? Thanks. Bob Naylor _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Apr 30 12:00:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11236 for ; Fri, 30 Apr 2004 12:00:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJaLw-00079j-Sr; Fri, 30 Apr 2004 11:55:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJaAV-0005Ly-UT for megaco@optimus.ietf.org; Fri, 30 Apr 2004 11:43:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10060 for ; Fri, 30 Apr 2004 11:43:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJaAU-0002w3-Q8 for megaco@ietf.org; Fri, 30 Apr 2004 11:43:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJa9k-0002tC-00 for megaco@ietf.org; Fri, 30 Apr 2004 11:42:29 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1BJa94-0002lq-00 for megaco@ietf.org; Fri, 30 Apr 2004 11:41:46 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3UFfFa17737 for ; Fri, 30 Apr 2004 11:41:15 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Apr 2004 11:41:16 -0400 Message-ID: From: "Kevin Boyle" To: Aleksandr Ryabin , Christian Groves , megaco@ietf.org Cc: "Tom-PT Taylor" Subject: RE: [Megaco] Continuity tests Date: Fri, 30 Apr 2004 11:41:09 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Wait a minute. You are saying that the type of test would change from 2-wire to 4-wire because some intermediary is forking the links? I find that very hard to believe, especially since the termination where the test is originating (and is, presumably, under test) would be unchanged. The termination wouldn't magically grow (or lose) two wires just because an interim box is splitting or redirecting the link. As pointed out earlier, COT is a link by link test. Splitting or redirecting the link means that those are new links, not "continuations". It would seem to me that the interim box would be responsible for continuing the COT test across the redirected or split link. If it doesn't, for whatever reason including "being dumb", then that is the problem of the interim box, not the original termination. Kevin -----Original Message----- From: Aleksandr Ryabin [mailto:kengr@motorola.com] Sent: Friday, April 30, 2004 10:39 AM To: Christian Groves; megaco@ietf.org Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; Taylor, Tom-PT [CAR:5N00:EXCH] Subject: Re: [Megaco] Continuity tests Hi Christian, There could be "dumb" switches in the middle of the path (for example DACS) which are not capable of any testing/signalling. Their only role is to split/redirect links and as such the nature of a circuit can change, and thus the type of COT test. Regards, Aleks At 08:17 PM 4/29/2004, Christian Groves wrote: >Hello Aleksandr, > >Is this really a problem? The Continuity test is a link by link >procedure not an end to end procedure. I tend to support Kevin and Tom on this one. > >Regards, Christian > >Aleksandr Ryabin wrote: >>Kevin, exactly, the type of COT test does not only depend on the >>physical details of a termination the MGC controls, but also on >>physical details of circuit which *eventually* is connected to that termination. >>My point is that the final far-end *final* connection can change >>without a change to immediate connection to MG termination and only >>MGC would know about it. >>For example, if MG is digital trunking gateway, it does not mean that >>only pure 4-wire tests will be used all the time. If the other side >>connected trough set of intermediate switches and finally lands at the >>time of the test say on analog 2-wire circuit then the test to be executed is 2-wire test. >>I guess it is possible to somehow tie up configuration of MG >>termination dynamically to changes which happens to those intermediate >>switches, but it does not seem right. On the contrary, that >>information would come to MGC naturally, since it is a controlling element. >>Also putting a burden of configuring of a test type per every single >>termination seems to be too much for MG, especially if we are talking >>about high density MGs which handle hundred thousands terminations. >>BTW This is a real problem we run into in our MGC implementation and >>are trying to solve. I thought that instead of having a proprietary >>package I might as well give it a shot to see if there is any interest >>to make the solution public instead. >>Thanks. >> Aleks >>At 11:23 AM 4/29/2004, Kevin Boyle wrote: >> >>>I agree with Tom. The fact that the circuit is connected to a single >>>entity means that only a single type of continuity test is actually >>>valid. MGs are expected to know how to handle their terminations. >>>Who the termination is connected to is certainly part of that >>>handling. Because the far-end connection changes the nature of the >>>termination, this becomes an MG-knowledge problem. >>> >>>I believe the package is fine as it stands, and the MG should know >>>what "run a continuity test" means for its terminations. >>> >>>Kevin >>> >>>-----Original Message----- >>>From: Taylor, Tom-PT [CAR:5N00:EXCH] >>>Sent: Thursday, April 29, 2004 11:19 AM >>>To: Aleksandr Ryabin >>>Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org >>>Subject: Re: [Megaco] Continuity tests >>> >>>I for one disagree with your philosophy. I think the physical >>>details of the termination should be provisioned in the MG rather >>>than the the MGC. However, I have no direct implementation >>>responsibility, so I should let those who do speak up. >>> >>>Aleksandr Ryabin wrote: >>> >>> > Packages defined in H.248.17 do not cover continuity tests. >>> > >>> > If the experts agree that MGC should be able to control type of >>> > continuity test then ether basic ct package needs to be amended to >>> > include new functionality, or H.248.17 needs to be amended to >>> > include new "extended" continuity package Commends? Suggestions? >>> > >>> > Aleks >>> > >>> > At 01:14 AM 4/29/2004, Zhao Bo wrote: >>> > >>> >> Can H.248.17 "line test packages" be used to test these circuits? >>> >> >>> >> ----- Original Message ----- >>> >> From: Aleksandr Ryabin >>> >> To: Kevin Boyle ; >>> >> megaco@ietf.org >>> >> Sent: Thursday, April 29, 2004 2:11 AM >>> >> Subject: RE: [Megaco] Continuity tests >>> >> >>> >> Yes, the type of test depends on what a circuit is connected to. >>> >> >>> >> But, I was actually coming from the view that MGC "controls" MG >>> >> and as such only MGC should have knowledge on what test to execute >>> >> (i.e. what is connected to the other side of a circuit). >>> >> >>> >> If this information is left in MG, then each circuit has to be >>> >> provisioned >>> >> with that information such that MG can make intelligent decision >>> >> on what >>> >> type of test to execute. Thus every time a circuit connection is >>> >> changed, >>> >> directly or indirectly, MG circuit needs to be re-provisioned. >>> >> >>> >> I think that configuration should be kept on MGC and the decision >>> >> should >>> >> come from MGC instead. >>> >> >>> >> Aleks >>> >> >>> >> At 02:30 PM 4/28/2004, Kevin Boyle wrote: >>> >> >>> >>> Is it possible to run more than one kind of continuity test >>> >>> on a particular circuit? If no, then the provisioning model >>> >>> holds and there is no need for a change. If yes, then we may >>> >>> need to add something to the package to allow selection of a >>> >>> ct test type. >>> >>> >>> >>> Kevin >>> >>> >>> >>> -----Original Message----- >>> >>> From: Aleksandr Ryabin [mailto:kengr@motorola.com] >>> >>> Sent: Wednesday, April 28, 2004 1:21 PM >>> >>> To: megaco@ietf.org >>> >>> Subject: [Megaco] Continuity tests >>> >>> >>> >>> Hi, >>> >>> >>> >>> There are several continuity test types (i.e 2-wire, 4-wire, >>> >>> etc) While provisioning of physical test parameters (i.e. >>> >>> frequencies, sequence, timeouts, etc) in MG makes sense, IMHO >>> >>> choosing a type of continuity test seem logical to be left to >>> >>> MGC. >>> >>> >>> >>> Basic Continuity Package (ct) does not allow to choose the >>> >>> type of a test. >>> >>> It implies that type of a test is provisioned on MG (per >>> >>> termination?) >>> >>> >>> >>> Is there another (extended) continuity test package which >>> >>> allows MGC to choose the type of a continuity test to be >>> >>> performed? >>> >>> >>> >>> If not, does anyone see a need to have such a package? >>> >>> Comments? >>> >>> >>> >>> Thanks >>> >>> Aleks >>> >>> >>> >>> _______________________________________________ >>> >>> Megaco mailing list >>> >>> Megaco@ietf.org >>> >>> https://www1.ietf.org/mailman/listinfo/megaco >>> >> _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri Apr 30 12:07:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11610 for ; Fri, 30 Apr 2004 12:07:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJaN2-0007Mi-2A for megaco-archive@odin.ietf.org; Fri, 30 Apr 2004 11:56:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UFuCgE028306 for megaco-archive@odin.ietf.org; Fri, 30 Apr 2004 11:56:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJaIB-0006W9-U4 for megaco-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 11:51:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10568 for ; Fri, 30 Apr 2004 11:51:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJaIA-0003OH-PY for megaco-web-archive@ietf.org; Fri, 30 Apr 2004 11:51:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJaHG-0003Lz-00 for megaco-web-archive@ietf.org; Fri, 30 Apr 2004 11:50:15 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJaGv-0003JN-00 for megaco-web-archive@ietf.org; Fri, 30 Apr 2004 11:49:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJa8M-00056b-TS; Fri, 30 Apr 2004 11:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJa2t-0003Fl-LQ for megaco@optimus.ietf.org; Fri, 30 Apr 2004 11:35:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08971 for ; Fri, 30 Apr 2004 11:35:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJa2s-00023y-DG for megaco@ietf.org; Fri, 30 Apr 2004 11:35:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJa1v-0001xx-00 for megaco@ietf.org; Fri, 30 Apr 2004 11:34:23 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1BJa1C-0001nk-00 for megaco@ietf.org; Fri, 30 Apr 2004 11:33:38 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3UFX5a16934 for ; Fri, 30 Apr 2004 11:33:05 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Apr 2004 11:33:06 -0400 Message-ID: From: "Kevin Boyle" To: "Naylor, Bob" , "'megaco@ietf.org'" Subject: RE: [Megaco] caller ID? Date: Fri, 30 Apr 2004 11:32:58 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Yes, I can tell you. Yes, it is. See H.248.23. Kevin -----Original Message----- From: Naylor, Bob [mailto:bnaylor@brixnet.com] Sent: Thursday, April 29, 2004 10:56 AM To: 'megaco@ietf.org' Subject: [Megaco] caller ID? Hello, Can anyone tell me if caller id is supported in any way within H.248? Thanks. Bob Naylor _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri Apr 30 12:28:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12683 for ; Fri, 30 Apr 2004 12:28:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJamJ-0004Zh-V9 for megaco-archive@odin.ietf.org; Fri, 30 Apr 2004 12:22:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UGMJ2c017581 for megaco-archive@odin.ietf.org; Fri, 30 Apr 2004 12:22:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJaRt-0008IC-2M for megaco-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 12:01:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11317 for ; Fri, 30 Apr 2004 12:01:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJaRr-0004H4-RH for megaco-web-archive@ietf.org; Fri, 30 Apr 2004 12:01:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJaR5-0004Eb-00 for megaco-web-archive@ietf.org; Fri, 30 Apr 2004 12:00:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJaQR-0004Ao-00 for megaco-web-archive@ietf.org; Fri, 30 Apr 2004 11:59:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJaLw-00079j-Sr; Fri, 30 Apr 2004 11:55:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJaAV-0005Ly-UT for megaco@optimus.ietf.org; Fri, 30 Apr 2004 11:43:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10060 for ; Fri, 30 Apr 2004 11:43:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJaAU-0002w3-Q8 for megaco@ietf.org; Fri, 30 Apr 2004 11:43:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJa9k-0002tC-00 for megaco@ietf.org; Fri, 30 Apr 2004 11:42:29 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1BJa94-0002lq-00 for megaco@ietf.org; Fri, 30 Apr 2004 11:41:46 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i3UFfFa17737 for ; Fri, 30 Apr 2004 11:41:15 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Apr 2004 11:41:16 -0400 Message-ID: From: "Kevin Boyle" To: Aleksandr Ryabin , Christian Groves , megaco@ietf.org Cc: "Tom-PT Taylor" Subject: RE: [Megaco] Continuity tests Date: Fri, 30 Apr 2004 11:41:09 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Wait a minute. You are saying that the type of test would change from 2-wire to 4-wire because some intermediary is forking the links? I find that very hard to believe, especially since the termination where the test is originating (and is, presumably, under test) would be unchanged. The termination wouldn't magically grow (or lose) two wires just because an interim box is splitting or redirecting the link. As pointed out earlier, COT is a link by link test. Splitting or redirecting the link means that those are new links, not "continuations". It would seem to me that the interim box would be responsible for continuing the COT test across the redirected or split link. If it doesn't, for whatever reason including "being dumb", then that is the problem of the interim box, not the original termination. Kevin -----Original Message----- From: Aleksandr Ryabin [mailto:kengr@motorola.com] Sent: Friday, April 30, 2004 10:39 AM To: Christian Groves; megaco@ietf.org Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; Taylor, Tom-PT [CAR:5N00:EXCH] Subject: Re: [Megaco] Continuity tests Hi Christian, There could be "dumb" switches in the middle of the path (for example DACS) which are not capable of any testing/signalling. Their only role is to split/redirect links and as such the nature of a circuit can change, and thus the type of COT test. Regards, Aleks At 08:17 PM 4/29/2004, Christian Groves wrote: >Hello Aleksandr, > >Is this really a problem? The Continuity test is a link by link >procedure not an end to end procedure. I tend to support Kevin and Tom on this one. > >Regards, Christian > >Aleksandr Ryabin wrote: >>Kevin, exactly, the type of COT test does not only depend on the >>physical details of a termination the MGC controls, but also on >>physical details of circuit which *eventually* is connected to that termination. >>My point is that the final far-end *final* connection can change >>without a change to immediate connection to MG termination and only >>MGC would know about it. >>For example, if MG is digital trunking gateway, it does not mean that >>only pure 4-wire tests will be used all the time. If the other side >>connected trough set of intermediate switches and finally lands at the >>time of the test say on analog 2-wire circuit then the test to be executed is 2-wire test. >>I guess it is possible to somehow tie up configuration of MG >>termination dynamically to changes which happens to those intermediate >>switches, but it does not seem right. On the contrary, that >>information would come to MGC naturally, since it is a controlling element. >>Also putting a burden of configuring of a test type per every single >>termination seems to be too much for MG, especially if we are talking >>about high density MGs which handle hundred thousands terminations. >>BTW This is a real problem we run into in our MGC implementation and >>are trying to solve. I thought that instead of having a proprietary >>package I might as well give it a shot to see if there is any interest >>to make the solution public instead. >>Thanks. >> Aleks >>At 11:23 AM 4/29/2004, Kevin Boyle wrote: >> >>>I agree with Tom. The fact that the circuit is connected to a single >>>entity means that only a single type of continuity test is actually >>>valid. MGs are expected to know how to handle their terminations. >>>Who the termination is connected to is certainly part of that >>>handling. Because the far-end connection changes the nature of the >>>termination, this becomes an MG-knowledge problem. >>> >>>I believe the package is fine as it stands, and the MG should know >>>what "run a continuity test" means for its terminations. >>> >>>Kevin >>> >>>-----Original Message----- >>>From: Taylor, Tom-PT [CAR:5N00:EXCH] >>>Sent: Thursday, April 29, 2004 11:19 AM >>>To: Aleksandr Ryabin >>>Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org >>>Subject: Re: [Megaco] Continuity tests >>> >>>I for one disagree with your philosophy. I think the physical >>>details of the termination should be provisioned in the MG rather >>>than the the MGC. However, I have no direct implementation >>>responsibility, so I should let those who do speak up. >>> >>>Aleksandr Ryabin wrote: >>> >>> > Packages defined in H.248.17 do not cover continuity tests. >>> > >>> > If the experts agree that MGC should be able to control type of >>> > continuity test then ether basic ct package needs to be amended to >>> > include new functionality, or H.248.17 needs to be amended to >>> > include new "extended" continuity package Commends? Suggestions? >>> > >>> > Aleks >>> > >>> > At 01:14 AM 4/29/2004, Zhao Bo wrote: >>> > >>> >> Can H.248.17 "line test packages" be used to test these circuits? >>> >> >>> >> ----- Original Message ----- >>> >> From: Aleksandr Ryabin >>> >> To: Kevin Boyle ; >>> >> megaco@ietf.org >>> >> Sent: Thursday, April 29, 2004 2:11 AM >>> >> Subject: RE: [Megaco] Continuity tests >>> >> >>> >> Yes, the type of test depends on what a circuit is connected to. >>> >> >>> >> But, I was actually coming from the view that MGC "controls" MG >>> >> and as such only MGC should have knowledge on what test to execute >>> >> (i.e. what is connected to the other side of a circuit). >>> >> >>> >> If this information is left in MG, then each circuit has to be >>> >> provisioned >>> >> with that information such that MG can make intelligent decision >>> >> on what >>> >> type of test to execute. Thus every time a circuit connection is >>> >> changed, >>> >> directly or indirectly, MG circuit needs to be re-provisioned. >>> >> >>> >> I think that configuration should be kept on MGC and the decision >>> >> should >>> >> come from MGC instead. >>> >> >>> >> Aleks >>> >> >>> >> At 02:30 PM 4/28/2004, Kevin Boyle wrote: >>> >> >>> >>> Is it possible to run more than one kind of continuity test >>> >>> on a particular circuit? If no, then the provisioning model >>> >>> holds and there is no need for a change. If yes, then we may >>> >>> need to add something to the package to allow selection of a >>> >>> ct test type. >>> >>> >>> >>> Kevin >>> >>> >>> >>> -----Original Message----- >>> >>> From: Aleksandr Ryabin [mailto:kengr@motorola.com] >>> >>> Sent: Wednesday, April 28, 2004 1:21 PM >>> >>> To: megaco@ietf.org >>> >>> Subject: [Megaco] Continuity tests >>> >>> >>> >>> Hi, >>> >>> >>> >>> There are several continuity test types (i.e 2-wire, 4-wire, >>> >>> etc) While provisioning of physical test parameters (i.e. >>> >>> frequencies, sequence, timeouts, etc) in MG makes sense, IMHO >>> >>> choosing a type of continuity test seem logical to be left to >>> >>> MGC. >>> >>> >>> >>> Basic Continuity Package (ct) does not allow to choose the >>> >>> type of a test. >>> >>> It implies that type of a test is provisioned on MG (per >>> >>> termination?) >>> >>> >>> >>> Is there another (extended) continuity test package which >>> >>> allows MGC to choose the type of a continuity test to be >>> >>> performed? >>> >>> >>> >>> If not, does anyone see a need to have such a package? >>> >>> Comments? >>> >>> >>> >>> Thanks >>> >>> Aleks >>> >>> >>> >>> _______________________________________________ >>> >>> Megaco mailing list >>> >>> Megaco@ietf.org >>> >>> https://www1.ietf.org/mailman/listinfo/megaco >>> >> _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Apr 30 12:56:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14347 for ; Fri, 30 Apr 2004 12:56:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJb8H-0001Yj-Pn; Fri, 30 Apr 2004 12:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJayj-00073i-JH for megaco@optimus.ietf.org; Fri, 30 Apr 2004 12:35:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13094 for ; Fri, 30 Apr 2004 12:35:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJayh-0006Uc-VN for megaco@ietf.org; Fri, 30 Apr 2004 12:35:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJaxm-0006Pt-00 for megaco@ietf.org; Fri, 30 Apr 2004 12:34:12 -0400 Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx with esmtp (Exim 4.12) id 1BJawq-0006MI-00 for megaco@ietf.org; Fri, 30 Apr 2004 12:33:12 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id i3UGTCcJ027777; Fri, 30 Apr 2004 09:29:12 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i3UGWV6S023075; Fri, 30 Apr 2004 11:32:42 -0500 Message-Id: <5.2.1.1.0.20040430114335.04db31b8@IL06EXM13.corp.mot.com> X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 30 Apr 2004 12:29:29 -0400 To: "Kevin Boyle", From: Aleksandr Ryabin Subject: RE: [Megaco] Continuity tests Cc: Christian Groves, "Tom-PT Taylor" In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1828569133==.ALT" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --=====================_1828569133==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Kevin, Yes, an intermediate box can also convert from one type of line to another, for example, take a single ds0 from a digital T1 and patch it to an analog phone line. So COT test would originate on ds0 on T1 and terminate on the analog line. I agree that this technically looks like a problem of interim box, but since interim box is dumb and there is nothing we can do about it ends up being our problem. So no matter how we put it we have to solve it on our MGC and for this we need to specify which test to run. This problem will came up for any softswitch implementations in networks/installations which utilize any kind of intermediate dumb switch. Regards, Aleks At 11:41 AM 4/30/2004, Kevin Boyle wrote: >Wait a minute. You are saying that the type of test would change from >2-wire to 4-wire because some intermediary is forking the links? I find >that very hard to believe, especially since the termination where the test >is originating (and is, presumably, under test) would be unchanged. The >termination wouldn't magically grow (or lose) two wires just because an >interim box is splitting or redirecting the link. > >As pointed out earlier, COT is a link by link test. Splitting or >redirecting the link means that those are new links, not >"continuations". It would seem to me that the interim box would be >responsible for continuing the COT test across the redirected or split >link. If it doesn't, for whatever reason including "being dumb", then >that is the problem of the interim box, not the original termination. > >Kevin > >-----Original Message----- >From: Aleksandr Ryabin [mailto:kengr@motorola.com] >Sent: Friday, April 30, 2004 10:39 AM >To: Christian Groves; megaco@ietf.org >Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; Taylor, Tom-PT [CAR:5N00:EXCH] >Subject: Re: [Megaco] Continuity tests > >Hi Christian, > >There could be "dumb" switches in the middle of the path (for example >DACS) which are not capable of any testing/signalling. > >Their only role is to split/redirect links and as such the nature of a >circuit can change, and thus the type of COT test. > >Regards, > Aleks > >At 08:17 PM 4/29/2004, Christian Groves wrote: > >Hello Aleksandr, > > > >Is this really a problem? The Continuity test is a link by link > >procedure not an end to end procedure. I tend to support Kevin and Tom > on this one. > > > >Regards, Christian > > > >Aleksandr Ryabin wrote: > >>Kevin, exactly, the type of COT test does not only depend on the > >>physical details of a termination the MGC controls, but also on > >>physical details of circuit which *eventually* is connected to that > termination. > >>My point is that the final far-end *final* connection can change > >>without a change to immediate connection to MG termination and only > >>MGC would know about it. > >>For example, if MG is digital trunking gateway, it does not mean that > >>only pure 4-wire tests will be used all the time. If the other side > >>connected trough set of intermediate switches and finally lands at the > >>time of the test say on analog 2-wire circuit then the test to be > executed is 2-wire test. > >>I guess it is possible to somehow tie up configuration of MG > >>termination dynamically to changes which happens to those intermediate > >>switches, but it does not seem right. On the contrary, that > >>information would come to MGC naturally, since it is a controlling > element. > >>Also putting a burden of configuring of a test type per every single > >>termination seems to be too much for MG, especially if we are talking > >>about high density MGs which handle hundred thousands terminations. > >>BTW This is a real problem we run into in our MGC implementation and > >>are trying to solve. I thought that instead of having a proprietary > >>package I might as well give it a shot to see if there is any interest > >>to make the solution public instead. > >>Thanks. > >> Aleks > >>At 11:23 AM 4/29/2004, Kevin Boyle wrote: > >> > >>>I agree with Tom. The fact that the circuit is connected to a single > >>>entity means that only a single type of continuity test is actually > >>>valid. MGs are expected to know how to handle their terminations. > >>>Who the termination is connected to is certainly part of that > >>>handling. Because the far-end connection changes the nature of the > >>>termination, this becomes an MG-knowledge problem. > >>> > >>>I believe the package is fine as it stands, and the MG should know > >>>what "run a continuity test" means for its terminations. > >>> > >>>Kevin > >>> > >>>-----Original Message----- > >>>From: Taylor, Tom-PT [CAR:5N00:EXCH] > >>>Sent: Thursday, April 29, 2004 11:19 AM > >>>To: Aleksandr Ryabin > >>>Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org > >>>Subject: Re: [Megaco] Continuity tests > >>> > >>>I for one disagree with your philosophy. I think the physical > >>>details of the termination should be provisioned in the MG rather > >>>than the the MGC. However, I have no direct implementation > >>>responsibility, so I should let those who do speak up. > >>> > >>>Aleksandr Ryabin wrote: > >>> > >>> > Packages defined in H.248.17 do not cover continuity tests. > >>> > > >>> > If the experts agree that MGC should be able to control type of > >>> > continuity test then ether basic ct package needs to be amended to > >>> > include new functionality, or H.248.17 needs to be amended to > >>> > include new "extended" continuity package Commends? Suggestions? > >>> > > >>> > Aleks > >>> > > >>> > At 01:14 AM 4/29/2004, Zhao Bo wrote: > >>> > > >>> >> Can H.248.17 "line test packages" be used to test these circuits? > >>> >> > >>> >> ----- Original Message ----- > >>> >> From: Aleksandr Ryabin > <mailto:kengr@motorola.com> > >>> >> To: Kevin Boyle > <mailto:kboyle@nortelnetworks.com> ; > >>> >> megaco@ietf.org <mailto:megaco@ietf.org> > >>> >> Sent: Thursday, April 29, 2004 2:11 AM > >>> >> Subject: RE: [Megaco] Continuity tests > >>> >> > >>> >> Yes, the type of test depends on what a circuit is connected to. > >>> >> > >>> >> But, I was actually coming from the view that MGC "controls" MG > >>> >> and as such only MGC should have knowledge on what test to > execute > >>> >> (i.e. what is connected to the other side of a circuit). > >>> >> > >>> >> If this information is left in MG, then each circuit has to be > >>> >> provisioned > >>> >> with that information such that MG can make intelligent decision > >>> >> on what > >>> >> type of test to execute. Thus every time a circuit connection is > >>> >> changed, > >>> >> directly or indirectly, MG circuit needs to be re-provisioned. > >>> >> > >>> >> I think that configuration should be kept on MGC and the > decision > >>> >> should > >>> >> come from MGC instead. > >>> >> > >>> >> Aleks > >>> >> > >>> >> At 02:30 PM 4/28/2004, Kevin Boyle wrote: > >>> >> > >>> >>> Is it possible to run more than one kind of continuity test > >>> >>> on a particular circuit? If no, then the provisioning model > >>> >>> holds and there is no need for a change. If yes, then we > may > >>> >>> need to add something to the package to allow selection of a > >>> >>> ct test type. > >>> >>> > >>> >>> Kevin > >>> >>> > >>> >>> -----Original Message----- > >>> >>> From: Aleksandr Ryabin > [mailto:kengr@motorola.com] > >>> >>> Sent: Wednesday, April 28, 2004 1:21 PM > >>> >>> To: megaco@ietf.org > >>> >>> Subject: [Megaco] Continuity tests > >>> >>> > >>> >>> Hi, > >>> >>> > >>> >>> There are several continuity test types (i.e 2-wire, 4-wire, > >>> >>> etc) While provisioning of physical test parameters (i.e. > >>> >>> frequencies, sequence, timeouts, etc) in MG makes sense, > IMHO > >>> >>> choosing a type of continuity test seem logical to be > left to > >>> >>> MGC. > >>> >>> > >>> >>> Basic Continuity Package (ct) does not allow to choose the > >>> >>> type of a test. > >>> >>> It implies that type of a test is provisioned on MG (per > >>> >>> termination?) > >>> >>> > >>> >>> Is there another (extended) continuity test package which > >>> >>> allows MGC to choose the type of a continuity test to be > >>> >>> performed? > >>> >>> > >>> >>> If not, does anyone see a need to have such a package? > >>> >>> Comments? > >>> >>> > >>> >>> Thanks > >>> >>> Aleks > >>> >>> > >>> >>> _______________________________________________ > >>> >>> Megaco mailing list > >>> >>> Megaco@ietf.org > >>> >>> > https://www1.ietf.org/mailman/listinfo/megaco > > >>> >> --=====================_1828569133==.ALT Content-Type: text/html; charset="us-ascii" Kevin,

Yes, an intermediate box can also convert from one type of line to another,
for example, take a single ds0 from a digital T1 and patch it to an analog phone line.
So COT test would originate on ds0 on T1 and terminate on the analog line.

I agree that this technically looks like a problem of interim box, but since interim
box is dumb and there is nothing we can do about it ends up being our problem.

So no matter how we put it we have to solve it on our MGC
and for this we need to specify which test to run.

This problem will came up for any softswitch implementations
in networks/installations which utilize any kind of intermediate dumb switch.

Regards,
        Aleks

At 11:41 AM 4/30/2004, Kevin Boyle wrote:

Wait a minute.  You are saying that the type of test would change from 2-wire to 4-wire because some intermediary is forking the links?  I find that very hard to believe, especially since the termination where the test is originating (and is, presumably, under test) would be unchanged.  The termination wouldn't magically grow (or lose) two wires just because an interim box is splitting or redirecting the link.

As pointed out earlier, COT is a link by link test.  Splitting or redirecting the link means that those are new links, not "continuations".  It would seem to me that the interim box would be responsible for continuing the COT test across the redirected or split link.  If it doesn't, for whatever reason including "being dumb", then that is the problem of the interim box, not the original termination.

Kevin

-----Original Message-----
From: Aleksandr Ryabin [mailto:kengr@motorola.com]
Sent: Friday, April 30, 2004 10:39 AM
To: Christian Groves; megaco@ietf.org
Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; Taylor, Tom-PT [CAR:5N00:EXCH]
Subject: Re: [Megaco] Continuity tests

Hi Christian,

There could be "dumb" switches in the middle of the path (for example DACS) which are not capable of any testing/signalling.

Their only role is to split/redirect links and as such the nature of a circuit can change, and thus the type of COT test.

Regards,
         Aleks

At 08:17 PM 4/29/2004, Christian Groves wrote:
>Hello Aleksandr,
>
>Is this really a problem? The Continuity test is a link by link
>procedure not an end to end procedure. I tend to support Kevin and Tom on this one.
>
>Regards, Christian
>
>Aleksandr Ryabin wrote:
>>Kevin, exactly, the type of COT test does not only depend on the
>>physical details of a termination the MGC controls, but also on
>>physical details of circuit which *eventually* is connected to that termination.
>>My point is that the final far-end *final* connection can change
>>without a change to immediate connection to MG termination and only
>>MGC would know about it.
>>For example, if MG is digital trunking gateway, it does not mean that
>>only pure 4-wire tests will be used all the time. If the other side
>>connected trough set of intermediate switches and finally lands at the
>>time of the test say on analog 2-wire circuit then the test to be executed is 2-wire test.
>>I guess it is possible to somehow tie up configuration of MG
>>termination dynamically to changes which happens to those intermediate
>>switches, but it does not seem right. On the contrary, that
>>information would come to MGC naturally, since it is a controlling element.
>>Also putting a burden of configuring of a test type per every single
>>termination seems to be too much for MG, especially if we are talking
>>about high density MGs which handle hundred thousands terminations.
>>BTW This is a real problem we run into in our MGC implementation and
>>are trying to solve. I thought that instead of having a proprietary
>>package I might as well give it a shot to see if there is any interest
>>to make the solution public instead.
>>Thanks.
>>         Aleks
>>At 11:23 AM 4/29/2004, Kevin Boyle wrote:
>>
>>>I agree with Tom.  The fact that the circuit is connected to a single
>>>entity means that only a single type of continuity test is actually
>>>valid.  MGs are expected to know how to handle their terminations.
>>>Who the termination is connected to is certainly part of that
>>>handling.  Because the far-end connection changes the nature of the
>>>termination, this becomes an MG-knowledge problem.
>>>
>>>I believe the package is fine as it stands, and the MG should know
>>>what "run a continuity test" means for its terminations.
>>>
>>>Kevin
>>>
>>>-----Original Message-----
>>>From: Taylor, Tom-PT [CAR:5N00:EXCH]
>>>Sent: Thursday, April 29, 2004 11:19 AM
>>>To: Aleksandr Ryabin
>>>Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org
>>>Subject: Re: [Megaco] Continuity tests
>>>
>>>I for one disagree with your philosophy.  I think the physical
>>>details of the termination should be provisioned in the MG rather
>>>than the the MGC.  However, I have no direct implementation
>>>responsibility, so I should let those who do speak up.
>>>
>>>Aleksandr Ryabin wrote:
>>>
>>> > Packages defined in H.248.17 do not cover continuity tests.
>>> >
>>> > If the experts agree that MGC should be able to control type of
>>> > continuity test then ether basic ct package needs to be amended to
>>> > include new functionality, or H.248.17 needs to be amended to
>>> > include new "extended" continuity package Commends? Suggestions?
>>> >
>>> >         Aleks
>>> >
>>> > At 01:14 AM 4/29/2004, Zhao Bo wrote:
>>> >
>>> >> Can H.248.17 "line test packages"  be used to test these circuits?
>>> >>
>>> >>     ----- Original Message -----
>>> >>     From: Aleksandr Ryabin <mailto:kengr@motorola.com>
>>> >>     To: Kevin Boyle <mailto:kboyle@nortelnetworks.com> ;
>>> >>     megaco@ietf.org <mailto:megaco@ietf.org>
>>> >>     Sent: Thursday, April 29, 2004 2:11 AM
>>> >>     Subject: RE: [Megaco] Continuity tests
>>> >>
>>> >>     Yes, the type of test depends on what a circuit is connected to.
>>> >>
>>> >>     But, I was actually coming from the view that MGC "controls" MG
>>> >>     and as such only MGC should have knowledge on what test to execute
>>> >>     (i.e. what is connected to the other side of a circuit).
>>> >>
>>> >>     If this information is left in MG, then each circuit has to be
>>> >>     provisioned
>>> >>     with that information such that MG can make intelligent decision
>>> >>     on what
>>> >>     type of test to execute. Thus every time a circuit connection is
>>> >>     changed,
>>> >>     directly or indirectly, MG circuit needs to be re-provisioned.
>>> >>
>>> >>     I think that configuration should  be kept on MGC and the decision
>>> >>     should
>>> >>     come from MGC instead.
>>> >>
>>> >>             Aleks
>>> >>
>>> >>     At 02:30 PM 4/28/2004, Kevin Boyle wrote:
>>> >>
>>> >>>         Is it possible to run more than one kind of continuity test
>>> >>>         on a particular circuit?  If no, then the provisioning model
>>> >>>         holds and there is no need for a change.  If yes, then we may
>>> >>>         need to add something to the package to allow selection of a
>>> >>>         ct test type.
>>> >>>
>>> >>>         Kevin
>>> >>>
>>> >>>         -----Original Message-----
>>> >>>         From: Aleksandr Ryabin [mailto:kengr@motorola.com]
>>> >>>         Sent: Wednesday, April 28, 2004 1:21 PM
>>> >>>         To: megaco@ietf.org
>>> >>>         Subject: [Megaco] Continuity tests
>>> >>>
>>> >>>         Hi,
>>> >>>
>>> >>>         There are several continuity test types (i.e 2-wire, 4-wire,
>>> >>>         etc) While provisioning of physical test parameters (i.e.
>>> >>>         frequencies, sequence, timeouts, etc) in MG makes sense, IMHO
>>> >>>         choosing a type of continuity test seem logical to be left to
>>> >>>         MGC.
>>> >>>
>>> >>>         Basic Continuity Package (ct) does not allow to choose the
>>> >>>         type of a test.
>>> >>>         It implies that type of a test is provisioned on MG (per
>>> >>>         termination?)
>>> >>>
>>> >>>         Is there another (extended) continuity test package which
>>> >>>         allows MGC to choose the type of a continuity test to be
>>> >>>         performed?
>>> >>>
>>> >>>         If not, does anyone see a need to have such a package?
>>> >>>         Comments?
>>> >>>
>>> >>>         Thanks
>>> >>>                 Aleks
>>> >>>
>>> >>>         _______________________________________________
>>> >>>         Megaco mailing list
>>> >>>         Megaco@ietf.org
>>> >>>         https://www1.ietf.org/mailman/listinfo/megaco
>>> >>
--=====================_1828569133==.ALT-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri Apr 30 13:11:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15273 for ; Fri, 30 Apr 2004 13:11:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbMx-0004KM-5a for megaco-archive@odin.ietf.org; Fri, 30 Apr 2004 13:00:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UH0B5M016635 for megaco-archive@odin.ietf.org; Fri, 30 Apr 2004 13:00:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJbKy-0003hP-Uw for megaco-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 12:58:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14424 for ; Fri, 30 Apr 2004 12:58:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJbKx-0000Pe-2R for megaco-web-archive@ietf.org; Fri, 30 Apr 2004 12:58:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJbJy-0000M5-00 for megaco-web-archive@ietf.org; Fri, 30 Apr 2004 12:57:08 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJbJ4-0000JI-00 for megaco-web-archive@ietf.org; Fri, 30 Apr 2004 12:56:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJb8H-0001Yj-Pn; Fri, 30 Apr 2004 12:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJayj-00073i-JH for megaco@optimus.ietf.org; Fri, 30 Apr 2004 12:35:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13094 for ; Fri, 30 Apr 2004 12:35:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJayh-0006Uc-VN for megaco@ietf.org; Fri, 30 Apr 2004 12:35:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJaxm-0006Pt-00 for megaco@ietf.org; Fri, 30 Apr 2004 12:34:12 -0400 Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx with esmtp (Exim 4.12) id 1BJawq-0006MI-00 for megaco@ietf.org; Fri, 30 Apr 2004 12:33:12 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id i3UGTCcJ027777; Fri, 30 Apr 2004 09:29:12 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i3UGWV6S023075; Fri, 30 Apr 2004 11:32:42 -0500 Message-Id: <5.2.1.1.0.20040430114335.04db31b8@IL06EXM13.corp.mot.com> X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 30 Apr 2004 12:29:29 -0400 To: "Kevin Boyle", From: Aleksandr Ryabin Subject: RE: [Megaco] Continuity tests Cc: Christian Groves, "Tom-PT Taylor" In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1828569133==.ALT" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 --=====================_1828569133==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Kevin, Yes, an intermediate box can also convert from one type of line to another, for example, take a single ds0 from a digital T1 and patch it to an analog phone line. So COT test would originate on ds0 on T1 and terminate on the analog line. I agree that this technically looks like a problem of interim box, but since interim box is dumb and there is nothing we can do about it ends up being our problem. So no matter how we put it we have to solve it on our MGC and for this we need to specify which test to run. This problem will came up for any softswitch implementations in networks/installations which utilize any kind of intermediate dumb switch. Regards, Aleks At 11:41 AM 4/30/2004, Kevin Boyle wrote: >Wait a minute. You are saying that the type of test would change from >2-wire to 4-wire because some intermediary is forking the links? I find >that very hard to believe, especially since the termination where the test >is originating (and is, presumably, under test) would be unchanged. The >termination wouldn't magically grow (or lose) two wires just because an >interim box is splitting or redirecting the link. > >As pointed out earlier, COT is a link by link test. Splitting or >redirecting the link means that those are new links, not >"continuations". It would seem to me that the interim box would be >responsible for continuing the COT test across the redirected or split >link. If it doesn't, for whatever reason including "being dumb", then >that is the problem of the interim box, not the original termination. > >Kevin > >-----Original Message----- >From: Aleksandr Ryabin [mailto:kengr@motorola.com] >Sent: Friday, April 30, 2004 10:39 AM >To: Christian Groves; megaco@ietf.org >Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; Taylor, Tom-PT [CAR:5N00:EXCH] >Subject: Re: [Megaco] Continuity tests > >Hi Christian, > >There could be "dumb" switches in the middle of the path (for example >DACS) which are not capable of any testing/signalling. > >Their only role is to split/redirect links and as such the nature of a >circuit can change, and thus the type of COT test. > >Regards, > Aleks > >At 08:17 PM 4/29/2004, Christian Groves wrote: > >Hello Aleksandr, > > > >Is this really a problem? The Continuity test is a link by link > >procedure not an end to end procedure. I tend to support Kevin and Tom > on this one. > > > >Regards, Christian > > > >Aleksandr Ryabin wrote: > >>Kevin, exactly, the type of COT test does not only depend on the > >>physical details of a termination the MGC controls, but also on > >>physical details of circuit which *eventually* is connected to that > termination. > >>My point is that the final far-end *final* connection can change > >>without a change to immediate connection to MG termination and only > >>MGC would know about it. > >>For example, if MG is digital trunking gateway, it does not mean that > >>only pure 4-wire tests will be used all the time. If the other side > >>connected trough set of intermediate switches and finally lands at the > >>time of the test say on analog 2-wire circuit then the test to be > executed is 2-wire test. > >>I guess it is possible to somehow tie up configuration of MG > >>termination dynamically to changes which happens to those intermediate > >>switches, but it does not seem right. On the contrary, that > >>information would come to MGC naturally, since it is a controlling > element. > >>Also putting a burden of configuring of a test type per every single > >>termination seems to be too much for MG, especially if we are talking > >>about high density MGs which handle hundred thousands terminations. > >>BTW This is a real problem we run into in our MGC implementation and > >>are trying to solve. I thought that instead of having a proprietary > >>package I might as well give it a shot to see if there is any interest > >>to make the solution public instead. > >>Thanks. > >> Aleks > >>At 11:23 AM 4/29/2004, Kevin Boyle wrote: > >> > >>>I agree with Tom. The fact that the circuit is connected to a single > >>>entity means that only a single type of continuity test is actually > >>>valid. MGs are expected to know how to handle their terminations. > >>>Who the termination is connected to is certainly part of that > >>>handling. Because the far-end connection changes the nature of the > >>>termination, this becomes an MG-knowledge problem. > >>> > >>>I believe the package is fine as it stands, and the MG should know > >>>what "run a continuity test" means for its terminations. > >>> > >>>Kevin > >>> > >>>-----Original Message----- > >>>From: Taylor, Tom-PT [CAR:5N00:EXCH] > >>>Sent: Thursday, April 29, 2004 11:19 AM > >>>To: Aleksandr Ryabin > >>>Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org > >>>Subject: Re: [Megaco] Continuity tests > >>> > >>>I for one disagree with your philosophy. I think the physical > >>>details of the termination should be provisioned in the MG rather > >>>than the the MGC. However, I have no direct implementation > >>>responsibility, so I should let those who do speak up. > >>> > >>>Aleksandr Ryabin wrote: > >>> > >>> > Packages defined in H.248.17 do not cover continuity tests. > >>> > > >>> > If the experts agree that MGC should be able to control type of > >>> > continuity test then ether basic ct package needs to be amended to > >>> > include new functionality, or H.248.17 needs to be amended to > >>> > include new "extended" continuity package Commends? Suggestions? > >>> > > >>> > Aleks > >>> > > >>> > At 01:14 AM 4/29/2004, Zhao Bo wrote: > >>> > > >>> >> Can H.248.17 "line test packages" be used to test these circuits? > >>> >> > >>> >> ----- Original Message ----- > >>> >> From: Aleksandr Ryabin > <mailto:kengr@motorola.com> > >>> >> To: Kevin Boyle > <mailto:kboyle@nortelnetworks.com> ; > >>> >> megaco@ietf.org <mailto:megaco@ietf.org> > >>> >> Sent: Thursday, April 29, 2004 2:11 AM > >>> >> Subject: RE: [Megaco] Continuity tests > >>> >> > >>> >> Yes, the type of test depends on what a circuit is connected to. > >>> >> > >>> >> But, I was actually coming from the view that MGC "controls" MG > >>> >> and as such only MGC should have knowledge on what test to > execute > >>> >> (i.e. what is connected to the other side of a circuit). > >>> >> > >>> >> If this information is left in MG, then each circuit has to be > >>> >> provisioned > >>> >> with that information such that MG can make intelligent decision > >>> >> on what > >>> >> type of test to execute. Thus every time a circuit connection is > >>> >> changed, > >>> >> directly or indirectly, MG circuit needs to be re-provisioned. > >>> >> > >>> >> I think that configuration should be kept on MGC and the > decision > >>> >> should > >>> >> come from MGC instead. > >>> >> > >>> >> Aleks > >>> >> > >>> >> At 02:30 PM 4/28/2004, Kevin Boyle wrote: > >>> >> > >>> >>> Is it possible to run more than one kind of continuity test > >>> >>> on a particular circuit? If no, then the provisioning model > >>> >>> holds and there is no need for a change. If yes, then we > may > >>> >>> need to add something to the package to allow selection of a > >>> >>> ct test type. > >>> >>> > >>> >>> Kevin > >>> >>> > >>> >>> -----Original Message----- > >>> >>> From: Aleksandr Ryabin > [mailto:kengr@motorola.com] > >>> >>> Sent: Wednesday, April 28, 2004 1:21 PM > >>> >>> To: megaco@ietf.org > >>> >>> Subject: [Megaco] Continuity tests > >>> >>> > >>> >>> Hi, > >>> >>> > >>> >>> There are several continuity test types (i.e 2-wire, 4-wire, > >>> >>> etc) While provisioning of physical test parameters (i.e. > >>> >>> frequencies, sequence, timeouts, etc) in MG makes sense, > IMHO > >>> >>> choosing a type of continuity test seem logical to be > left to > >>> >>> MGC. > >>> >>> > >>> >>> Basic Continuity Package (ct) does not allow to choose the > >>> >>> type of a test. > >>> >>> It implies that type of a test is provisioned on MG (per > >>> >>> termination?) > >>> >>> > >>> >>> Is there another (extended) continuity test package which > >>> >>> allows MGC to choose the type of a continuity test to be > >>> >>> performed? > >>> >>> > >>> >>> If not, does anyone see a need to have such a package? > >>> >>> Comments? > >>> >>> > >>> >>> Thanks > >>> >>> Aleks > >>> >>> > >>> >>> _______________________________________________ > >>> >>> Megaco mailing list > >>> >>> Megaco@ietf.org > >>> >>> > https://www1.ietf.org/mailman/listinfo/megaco > > >>> >> --=====================_1828569133==.ALT Content-Type: text/html; charset="us-ascii" Kevin,

Yes, an intermediate box can also convert from one type of line to another,
for example, take a single ds0 from a digital T1 and patch it to an analog phone line.
So COT test would originate on ds0 on T1 and terminate on the analog line.

I agree that this technically looks like a problem of interim box, but since interim
box is dumb and there is nothing we can do about it ends up being our problem.

So no matter how we put it we have to solve it on our MGC
and for this we need to specify which test to run.

This problem will came up for any softswitch implementations
in networks/installations which utilize any kind of intermediate dumb switch.

Regards,
        Aleks

At 11:41 AM 4/30/2004, Kevin Boyle wrote:

Wait a minute.  You are saying that the type of test would change from 2-wire to 4-wire because some intermediary is forking the links?  I find that very hard to believe, especially since the termination where the test is originating (and is, presumably, under test) would be unchanged.  The termination wouldn't magically grow (or lose) two wires just because an interim box is splitting or redirecting the link.

As pointed out earlier, COT is a link by link test.  Splitting or redirecting the link means that those are new links, not "continuations".  It would seem to me that the interim box would be responsible for continuing the COT test across the redirected or split link.  If it doesn't, for whatever reason including "being dumb", then that is the problem of the interim box, not the original termination.

Kevin

-----Original Message-----
From: Aleksandr Ryabin [mailto:kengr@motorola.com]
Sent: Friday, April 30, 2004 10:39 AM
To: Christian Groves; megaco@ietf.org
Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; Taylor, Tom-PT [CAR:5N00:EXCH]
Subject: Re: [Megaco] Continuity tests

Hi Christian,

There could be "dumb" switches in the middle of the path (for example DACS) which are not capable of any testing/signalling.

Their only role is to split/redirect links and as such the nature of a circuit can change, and thus the type of COT test.

Regards,
         Aleks

At 08:17 PM 4/29/2004, Christian Groves wrote:
>Hello Aleksandr,
>
>Is this really a problem? The Continuity test is a link by link
>procedure not an end to end procedure. I tend to support Kevin and Tom on this one.
>
>Regards, Christian
>
>Aleksandr Ryabin wrote:
>>Kevin, exactly, the type of COT test does not only depend on the
>>physical details of a termination the MGC controls, but also on
>>physical details of circuit which *eventually* is connected to that termination.
>>My point is that the final far-end *final* connection can change
>>without a change to immediate connection to MG termination and only
>>MGC would know about it.
>>For example, if MG is digital trunking gateway, it does not mean that
>>only pure 4-wire tests will be used all the time. If the other side
>>connected trough set of intermediate switches and finally lands at the
>>time of the test say on analog 2-wire circuit then the test to be executed is 2-wire test.
>>I guess it is possible to somehow tie up configuration of MG
>>termination dynamically to changes which happens to those intermediate
>>switches, but it does not seem right. On the contrary, that
>>information would come to MGC naturally, since it is a controlling element.
>>Also putting a burden of configuring of a test type per every single
>>termination seems to be too much for MG, especially if we are talking
>>about high density MGs which handle hundred thousands terminations.
>>BTW This is a real problem we run into in our MGC implementation and
>>are trying to solve. I thought that instead of having a proprietary
>>package I might as well give it a shot to see if there is any interest
>>to make the solution public instead.
>>Thanks.
>>         Aleks
>>At 11:23 AM 4/29/2004, Kevin Boyle wrote:
>>
>>>I agree with Tom.  The fact that the circuit is connected to a single
>>>entity means that only a single type of continuity test is actually
>>>valid.  MGs are expected to know how to handle their terminations.
>>>Who the termination is connected to is certainly part of that
>>>handling.  Because the far-end connection changes the nature of the
>>>termination, this becomes an MG-knowledge problem.
>>>
>>>I believe the package is fine as it stands, and the MG should know
>>>what "run a continuity test" means for its terminations.
>>>
>>>Kevin
>>>
>>>-----Original Message-----
>>>From: Taylor, Tom-PT [CAR:5N00:EXCH]
>>>Sent: Thursday, April 29, 2004 11:19 AM
>>>To: Aleksandr Ryabin
>>>Cc: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org
>>>Subject: Re: [Megaco] Continuity tests
>>>
>>>I for one disagree with your philosophy.  I think the physical
>>>details of the termination should be provisioned in the MG rather
>>>than the the MGC.  However, I have no direct implementation
>>>responsibility, so I should let those who do speak up.
>>>
>>>Aleksandr Ryabin wrote:
>>>
>>> > Packages defined in H.248.17 do not cover continuity tests.
>>> >
>>> > If the experts agree that MGC should be able to control type of
>>> > continuity test then ether basic ct package needs to be amended to
>>> > include new functionality, or H.248.17 needs to be amended to
>>> > include new "extended" continuity package Commends? Suggestions?
>>> >
>>> >         Aleks
>>> >
>>> > At 01:14 AM 4/29/2004, Zhao Bo wrote:
>>> >
>>> >> Can H.248.17 "line test packages"  be used to test these circuits?
>>> >>
>>> >>     ----- Original Message -----
>>> >>     From: Aleksandr Ryabin <mailto:kengr@motorola.com>
>>> >>     To: Kevin Boyle <mailto:kboyle@nortelnetworks.com> ;
>>> >>     megaco@ietf.org <mailto:megaco@ietf.org>
>>> >>     Sent: Thursday, April 29, 2004 2:11 AM
>>> >>     Subject: RE: [Megaco] Continuity tests
>>> >>
>>> >>     Yes, the type of test depends on what a circuit is connected to.
>>> >>
>>> >>     But, I was actually coming from the view that MGC "controls" MG
>>> >>     and as such only MGC should have knowledge on what test to execute
>>> >>     (i.e. what is connected to the other side of a circuit).
>>> >>
>>> >>     If this information is left in MG, then each circuit has to be
>>> >>     provisioned
>>> >>     with that information such that MG can make intelligent decision
>>> >>     on what
>>> >>     type of test to execute. Thus every time a circuit connection is
>>> >>     changed,
>>> >>     directly or indirectly, MG circuit needs to be re-provisioned.
>>> >>
>>> >>     I think that configuration should  be kept on MGC and the decision
>>> >>     should
>>> >>     come from MGC instead.
>>> >>
>>> >>             Aleks
>>> >>
>>> >>     At 02:30 PM 4/28/2004, Kevin Boyle wrote:
>>> >>
>>> >>>         Is it possible to run more than one kind of continuity test
>>> >>>         on a particular circuit?  If no, then the provisioning model
>>> >>>         holds and there is no need for a change.  If yes, then we may
>>> >>>         need to add something to the package to allow selection of a
>>> >>>         ct test type.
>>> >>>
>>> >>>         Kevin
>>> >>>
>>> >>>         -----Original Message-----
>>> >>>         From: Aleksandr Ryabin [mailto:kengr@motorola.com]
>>> >>>         Sent: Wednesday, April 28, 2004 1:21 PM
>>> >>>         To: megaco@ietf.org
>>> >>>         Subject: [Megaco] Continuity tests
>>> >>>
>>> >>>         Hi,
>>> >>>
>>> >>>         There are several continuity test types (i.e 2-wire, 4-wire,
>>> >>>         etc) While provisioning of physical test parameters (i.e.
>>> >>>         frequencies, sequence, timeouts, etc) in MG makes sense, IMHO
>>> >>>         choosing a type of continuity test seem logical to be left to
>>> >>>         MGC.
>>> >>>
>>> >>>         Basic Continuity Package (ct) does not allow to choose the
>>> >>>         type of a test.
>>> >>>         It implies that type of a test is provisioned on MG (per
>>> >>>         termination?)
>>> >>>
>>> >>>         Is there another (extended) continuity test package which
>>> >>>         allows MGC to choose the type of a continuity test to be
>>> >>>         performed?
>>> >>>
>>> >>>         If not, does anyone see a need to have such a package?
>>> >>>         Comments?
>>> >>>
>>> >>>         Thanks
>>> >>>                 Aleks
>>> >>>
>>> >>>         _______________________________________________
>>> >>>         Megaco mailing list
>>> >>>         Megaco@ietf.org
>>> >>>         https://www1.ietf.org/mailman/listinfo/megaco
>>> >>
--=====================_1828569133==.ALT-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco