Responding to COT (ct/rsp)

From megaco-bounces@ietf.org Fri Jun 01 01:00:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtzFo-0004ev-T0; Fri, 01 Jun 2007 01:00:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtzFn-0004eq-2v for megaco@ietf.org; Fri, 01 Jun 2007 01:00:47 -0400 Received: from [61.95.244.212] (helo=in-smtp.ccpu.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtzFl-0002Or-AY for megaco@ietf.org; Fri, 01 Jun 2007 01:00:47 -0400 Received: from in-smtp.ccpu.com (localhost.localdomain [127.0.0.1]) by localhost.ccpu.com (Postfix) with ESMTP id BFE7BB3EA2 for ; Fri, 1 Jun 2007 10:24:23 +0530 (IST) Received: from IN-EXCHANGE.ccin.ccpu.com (in-exchange.ccpu.com [172.25.0.16]) by in-smtp.ccpu.com (Postfix) with ESMTP id B1B8FB3EA1 for ; Fri, 1 Jun 2007 10:24:23 +0530 (IST) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 1 Jun 2007 10:22:20 +0530 Message-ID: <22F058C3ED9D784E90CE473F2A9847F00161B03C@in-exchange> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Query regarding ServiceChangeIncomplete Flag Thread-Index: AcekCKNOZ4GYTkHiRjmwG3A5nDqtxQ== From: "Syed Mohd Mujahid" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Subject: [Megaco] Query regarding ServiceChangeIncomplete Flag X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0006747306==" Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============0006747306== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A408.A3FCBC90" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A408.A3FCBC90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I have the below mentioned concerns related to the usage of ServiceChangeIncomplete (SIC) Flag. =20 1.) Is the SIC flag only applicable to servicechange with method =3D RESTART or is it also applicable to SC with methods =3D HO, FO and Disconnect. ? 2.) Can SIC be used for SC message on termination ID other than ROOT? =20 Awaiting your ideas on these issues. =20 Thanks Syed Mohd Mujahid, Engineer, Continuous Computing, Bangalore. =20 ------_=_NextPart_001_01C7A408.A3FCBC90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

I have the = below mentioned concerns related to the usage of ServiceChangeIncomplete (SIC) = Flag.

1.) Is the = SIC flag only applicable to servicechange with method =3D RESTART or is it also applicable to SC with methods =3D = HO, FO and Disconnect. ?

2.) Can = SIC be used for SC message on termination ID other than ROOT?

Awaiting your ideas on these = issues.

Thanks

Syed Mohd Mujahid,

Engineer,

Continuous Computing,

Bangalore.

------_=_NextPart_001_01C7A408.A3FCBC90-- --===============0006747306== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0006747306==-- From megaco-bounces@ietf.org Fri Jun 01 07:29:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu5Jk-0004Kf-CI; Fri, 01 Jun 2007 07:29:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu5Ji-0004DE-BT for megaco@ietf.org; Fri, 01 Jun 2007 07:29:14 -0400 Received: from mailrelay2.alcatel.de ([194.113.59.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hu5Jg-0002ab-Rj for megaco@ietf.org; Fri, 01 Jun 2007 07:29:14 -0400 Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr [155.132.182.205]) by mailrelay2.alcatel.de (8.13.4/8.13.4/ICT) with ESMTP id l51BT9G1011665; Fri, 1 Jun 2007 13:29:09 +0200 In-Reply-To: <0E48B768805E4D44A70709C8AE0920908B8063@EMAILEMEA3.jnpr.net> Subject: RE: [Megaco] H.248.37 Amendment 1 - Address Reporting (adr) package: ObservedEventsDescriptor parameters: typeof nrsa To: "Miri Epstein" X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Albrecht.Schwarz@alcatel-lucent.de Date: Fri, 1 Jun 2007 13:29:08 +0200 X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 06/01/2007 13:29:09 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.51 on 149.204.45.73 X-Spam-Score: 0.2 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: Elad Chomsky , megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Miri, no objections from my side concerning the proposal for changing the data types. Make sense ... -Albrecht "Miri Epstein" r.net> cc: Elad Chomsky , megaco@ietf.org, Albrecht.Schwarz@alcatel-lucent.de 30.05.2007 09:23 Subject: RE: [Megaco] H.248.37 Amendment 1 - Address Reporting (adr) package: ObservedEventsDescriptor parameters: typeof nrsa Hi Jisu, Thanks for your comment. I also was surprised to find that nsrp was fixed in the last meeting (Shenzhen). Regards, Miri From: Jisu Bhattacharya [mailto:jisu72@gmail.com] Sent: Wednesday, May 30, 2007 2:48 AM To: Miri Epstein Cc: Albrecht.Schwarz@alcatel-lucent.de; Elad Chomsky; megaco@ietf.org Subject: Re: [Megaco] H.248.37 Amendment 1 - Address Reporting (adr) package: ObservedEventsDescriptor parameters: typeof nrsa Miri, Two comments: 1. It is probably better to further refine the type-definition of nsra as follows: Type: String Possible Values: Encoded as DomainAddress, as defined in ITU-T recommendation H.248.1 Annex B. 2. The same problem is there in nsrp as well (unless it has been fixed in one of the earlier sessions that I have missed). If nsrp is still defined as OctetString, it should be changed to Type: Integer Possible Values: 1 to 65535. Thanks, Jisu Bhattacharya Cisco Systems On 5/28/07, Miri Epstein < mepstein@juniper.net > wrote: Dear Mr. Schwarz, As the next meeting in Geneva is approaching, we would like to raise this item for discussion. Please see the attached file (based on TD-35 Shenzhen's meeting output). Thank you very much, Miri --------------------------- Miri Epstein System Architect VoIP Engineering Juniper Networks Direct +972.9.9717315 Fax +972.9.9717334 mepstein@juniper.net www.juniper.net _______________________________________________ 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 ptjjjfuvsae@einsundeins.de Fri Jun 01 14:03:05 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuBSr-0005I2-Hd for megaco-archive@lists.ietf.org; Fri, 01 Jun 2007 14:03:05 -0400 Received: from gssn-590d76c3.pool.einsundeins.de ([89.13.118.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HuBSe-0000Jq-5s for megaco-archive@lists.ietf.org; Fri, 01 Jun 2007 14:03:05 -0400 From: "FVD" To: megaco-archive@lists.ietf.org Subject: Date: Fri, 1 Jun 2007 20:02:47 -0200 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0005_01C7A487.D34B5BE0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acekh9NLxaJQAFIPRjaPCaEPdBJJzw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <1525E1DCBD2DE47.CBD1AD4637@einsundeins.de> X-Spam-Score: 4.5 (++++) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 ------=_NextPart_000_0005_01C7A487.D34B5BE0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0006_01C7A487.D34B5BE0" ------=_NextPart_001_0006_01C7A487.D34B5BE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit strongly related product. Tags will Toll Free: Advertise Tagged ------=_NextPart_001_0006_01C7A487.D34B5BE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

strongly related product. = Tags will

Toll Free: Advertise = Tagged

------=_NextPart_001_0006_01C7A487.D34B5BE0-- ------=_NextPart_000_0005_01C7A487.D34B5BE0 Content-Type: image/gif; name="pic01.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdh9AASAYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDgQKDgQMDgQODgQAAAgCAAgEAAgGAAgIAAgKAAgMAAgOAAgAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////ywAAAAA9AASAQcI/gDtCRxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bNmzhz6lQIAMBO hD0/Qvo5cYvNnkgFBk25tGLQpg6hEp0KEapPqSWxRtTakCvVrwQvDLRq72lTpD7HLjWbtmxS pWvRGkSbNmiRuG7zvnV7ti3YvwmxvjULV2nhwVfrJjacd25btocXI26MF7Dlg4IfL26sljNh vX45E+zrWfJm0IVFX16duTNdxUlJv4arGXNt2aZd0029+qGam2RxF8Qr3Dbv0beTo47cuzlQ v6c/l6UcPfp06saZM5fO/bhzwLtL/tPWHDs8X/LIQ59XrHs5ddLf41/0Kr++fe/38+vfz7+/ f4+p/CfggAQWaOCBCCao4IIMNujggxBGKKE98/xHx4QYZqjhhhx26OGHIFqkSIgklmjiiSim iKI1KhJ4yCEXwRiSehIh8BCN9l0ykIw72sOjRi++qBCPP+4YZJAHFdkRjiCph6Nc41FVpJIY /UilQEQOqeWMJ+2112hgQidljz5iKaSZSMIoI5IFUXkkmkdeOeWZap7po522oQfmeYxd56da eob5J41iijlVlmUSpKaidxo0paOMJippkgjV2eOVQP0p6Fh+PhaYppvuOVyooOaE6KNWTkqm omymKimm/6peyiisc5U6naFX3cqTrfgRuieUY56a5qys4gmpq4hW2uawZBrrWGWk1qUroZM9 N2qtnBpq0xmUZuktsViu2m2kyVK66qLiYuopp9EalquT7PY5qrai6hovUeiW+a2Zr4o7ab6J lgvpuf9Gitm9oeUa77rXDlqrwvJKm229+JLbqpAAv7msnRr/K+fGdV5Mq1xfMgZsp89Blieg a7HsMn+0qsgkgx23mKnNOOes88489+wzYHhwhEfQFhHd38z3DT20PUYTFHTTBykNdUFGT820 1EsbZPV90JUc5dc/bU01Q02LXbVCYjPt32AUF0rxTVMTrbRAT9Od9UBWS2031v5bQz232n9f nfZXubqALcKH5xT32HX3rbXTdOONNkJPnz34XxA3HHHiOC0OeeMJ6a225KOXHjXlptddn1Re a+s13I8LDvrVC6keeelp+z132Xav7utwJ8vb+eOWpz4577hPTjrgkC/vXObCax497J9Lbrvp xiN/dujNM+982gyHv/D4fYpf/sHv/ootvTrpLffugN/tdOCip+74/EtjvfdC5qN8/v/+CyDD gEee8FnldT/jWgI9hLQFOvCB+nkDBCdIwQpaUCQNjA+qLsg5W0FpNjt5FAcJCKiDTQwsp0KT kYa1JmdB5BcPSt+9EJcWMIwpXKrKWKPa1CLolapQwf4zVbN4mCo32UwwKfvdT/LVQoyBC044 Y50Jo5fBmDCxX0Uk2BEdljh4VWxf+jJSv3B4MwGSz4wA7J8az7jGNKKPiyZr16EsRicnWolN ZWwjGveoxz6y8Y/T4wvLJMYnsN0nZj2cUM1+VsUROvKRkIykJCepksvtrJHxcd/pLBnF9Dyp L/SpiSU5GcWWzVBT7Bve2AQXufeRkkQybFsXieI563mPkR4koCkDKcrY2fJ6PtOKF931Nuo1 T5PvW+ABp3gd87SPeL/sXs8UxqRUYtIlfkve9cAHSD52049uDKc3xdmIifmwmbKkiiZlx7zA 5fGb8BQnOMdJz/6RcD2EBP8WAlGyC0pO5Jr+jA9AA0rQghr0oAhNaIgG2pxFjrBr9CngV1zl SLadMjWpFKKjRBayFW4xlj8M6Rx5KCsyijBFELPm9BjKEo1l0aQkldkAE3ZKlsJEh8lqIiIZ oo0G7RKV5gllCAuW0zEmMnPVvOgSnxhGmAqsYfOMajzrOdUBmpOLXrTpSzrmUi06VFRSlWdV xypWAN6zkKCCzT4VChOtsvUnbn2rXOdK17pCRAl2zetH4voV/UlymLp8GS2l+VBQMhOpU+Gd 6kTH2LvVD5b2Wqkcw/Y5uUkzm6/MkA+VGFle9dKWtwvt4jKrWcDSsJhwY+z3QstO0pZWeoMc D1/+SVJL7S0PmChCLP86qMruKda32PtUWak63LASN6S6pSJve/u9vzU2a489nHGnS9bjWrWE si3fAWer1/l09zvc/a54x0ve8poXoeEdakTWlECIOsmZ6Q3JTs01zZ/ODDY3LBZ7wxWyRTUx t53lJU1Hmi4smlRJ85XQOXk14IoZLGAQNuqDdeIHnAhTuKi9yZy6ut9yfRVEy8SwUjUcU3Dt 16gJnhA1d7tcEj+4qCj2F1SrS93i0vii6eMsZ0PoUjyiOGM+lu6NbUxk657xniC8rjPPS5L4 MnkkTn6ylKdM5Spb+cpYlo9YVvkR15rEy3gDc0tIiTzaHsQHRWNtRKr+xuaMXM5slQyznHun 5uByz7IlETPq7NwQ6LayzhJ5M/dQ4mfvLdbOZB6dnmnHzr2VLX9stmwy59doRkf3dpJmrWpd Geb8kW53lXt0qP982/1pM7h4PnSmtUa/Nsev0hSxnayPSepXK5rWmk7eKldd5sqJ9tS1vvWu rTfaX1sub5gWtqflB+zf4pnPZPN0rW17S1m789mc3h6uD11qbc+6eKXG9S2rB+xxb1vYpO51 o+GH7YmsutrnBjeijT3t2PEauN4u9zYvS29o6pvPqUa3ofFNa24LvM/SVjQeHkBtTtsPs59O uO4mzehOP5uVjs44xkd920L7EuOtjRp0XS3/2mxieuSq/rSEFm1mKrNcJC/PssxnnpEoi5iX LL5RzYHDEnpd07SHzXBN4Rhgz75RItdtMZc80kCfb+Wf9Wr6w6Jexqg4ZcRYb9Jeu0LMTr0u NoKc1oXtJdFpZRedElOrWvP0FLJ7qTxtt+oHW8euDwqKpj35wstIBsqkrw+dRB+Up6xzrRU7 rGW46rq03DZDt9k3rSeE/ObAevgwvTfykR28+hiy+Dg2nurJrTvgGd/ZtI++8p+/qmFgWPR1 nXOmU0d91zWHWPElnvMoU/vlK69SzctetylFu+WD5/hBblb0Suz95kgP+lANPjxVhI/RZ292 HNdm+Zi/vmdkH/Tg/sPW9SINPNnbpePfYz7r9qAFKhF3dGJmtMGkT6ncI9/21OslgK0/MuVx fNrDdN/52fd0Udc6j5cYCNRgheR69bd+JlN/QSRIIKVPb4d/wGNIA2hYr/crFuU/+hQTNidQ O6dZGxJXH0hzJniCAxIHKLiCLIhzFYh+S4Z73lV4KJFULlh1V7d1VXEjGUV7O7h0beWB/RSE VqeASKSBfZeAbAN/zRR3JWOAivd2a5djYUcyXwOFhSdFUrh2myKBYHdVXLgeOud7woN3pGJW pzE+wJcdt0JIpfeChEeGbfh5nxSAP+SGtXd3eCh+wtV59kd9x4d9R7eGswR77COH+cR9/2b4 f6InZAFYfIJ4g2oYeItIfWiYS2lneoVofBg1Y7f3hofYK3KUfLvBfLE0Gz04RREoPXk4Y+d3 QoxXfn4XYIh4Pqbog83XiK6Yi+43dOiHMMkFDlh1hvi3YMUIeJ43e07HhJ/YimWYToAoWZG4 gHHXf5QhgxhFgF/ihddnd++0gaYEfZ5EGy7zfNtITRu4fnRXd+dIe1LYhFQoWF9Ygjnhhkyn H/S4Nr+YgwrUH+TQgmwlAQA5kHX1AzrBD/zQEgipEAtZZQ3JEQ/JkAkZkQNBkQlhkRKJEBiZ QBtpER1JEB/5kR6ZkAchkhExBRmCkCpJkitJkiA5kQ/ZkgIhk/8FsZL2sJANaZM56ZIGoZI3 6ZI7yZI2+ZI+uZM/+ZNA6ZMdEpMwWZE8iZQz2ZRROZU9yZM4KZVTKZJX6ZRHeZNUWZVceZRK uZVduSFMWZYUeZZnWZYv2ZZkGZUm+ZZv+ZU1mZRZaZdGySFqaZdteZdhiZERuZWBaZJiyZdK yZZ9CZdCyZUt+ZQKIZAIspdhOZlyuZhgyZhYiZSOCZZrSZUbOZh5WZghEpRo+ZSS6ZmbOZii iZmTyZpQaZmfaZp8uZpeuZRkSZOJGZSgWZWCKZS3aZl9WZS+SZQl2ZmN6ZSE+V0WmZwSoZoK dQMh4ZjM2ZxWuZkEeZ3YmZ01kQ/5cBL/3WkQ31kS3GkP4zmeC2GeBYGeKqKeBKGe7CkR4dme 3tmd5RmfCPGe5GmfKIKf+dme+gkR//mfJFGfDIGf/Fki9Wme3Lmg+cmgCeqfBxGgApGg8bmg 34me4UmgDDqh9NmhHPqeFMqhA3GgHbKh/XmiIvqhKYqiIxqhI4qhFxqjJ7qhDzqjHkqgE5qe MGqjKeKeMvqiQBqkIOqiK9qfO2qkOOqjSLqk91mhNyqgIKKkLHqkRQqeRDqlHWqhMkqfPAqk GpqlIOqkDQqlUSqmWBqkVSqfVoqmTKqj5PmmCiqmX/qh7KmkFtoiUiqlZ8qib7qmRYqjOhqi ZzqnENqmS0qi/x6Sp2aKolTap+nppkKaoWhKpXF6qJE6qD96Inpqog6qpYWao376pxlqoow6 qncqoknKqR7qpaNqQYgKqo8qEgc6B+T1qo6qpiFhq9+lqyvBqw7iC9oZrB+xCsJarMZ6rMia rMq6rDvjnBcxnRcJrQwhrR1BrXUZrStBrc46khhhrQvhrdyKmBMxl3QJEeBKEdtaEecqrhmx ruMKnOpqnezaEN56lcvJlLoplnCJnPuKnEm5mLI5nK45lk2Jk0QJsP3amwlrlNUJk/iqmLy5 msJZrgRLmlCprxpZsKmpsaKpkxxbrrRZmKpJrgpbsofZsRNrsqUpstXplypLmR8bst0oK7Ea 25EKe7AzW5kE25o0S64z65Yce7NAu7Ivq5uZiZosG7NEi5VDebBB65s+e61zqbJCe6+tSbXS qbQLm7NZS5u/2bQhe5pCG7Z4ybRHO7JSma6cebYVC7Vs6bEC669yC5ihmZv4erSaSZeHmZd7 O7FI+7Vam7LDWbd5+5sQ667fgbgnobgh4gDRKa84AbnMOrlTwQWUe7mYm7mWUQ2a27klsgZ6 1QeeO7qkS5DZULqom7oj0QCq27quyx9M8LqyO7vCCgu0a1DdcLsLxAe627u++7vAG7zCmyAB AQA7 ------=_NextPart_000_0005_01C7A487.D34B5BE0-- From megaco-bounces@ietf.org Sun Jun 03 02:47:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HujsS-0004Zr-AR; Sun, 03 Jun 2007 02:47:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HujsR-0004Zm-AZ for megaco@ietf.org; Sun, 03 Jun 2007 02:47:47 -0400 Received: from kremlin.juniper.net ([207.17.137.120] helo=smtpa.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HujsP-0004zT-Lv for megaco@ietf.org; Sun, 03 Jun 2007 02:47:47 -0400 Received: from unknown (HELO emailfeemea1.jnpr.net) ([172.26.192.140]) by smtpa.juniper.net with ESMTP; 02 Jun 2007 23:47:45 -0700 X-IronPort-AV: i="4.16,377,1175497200"; d="scan'208"; a="13123051:sNHT52971360" Received: from EMAILEMEA3.jnpr.net ([172.26.192.136]) by emailfeemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 3 Jun 2007 07:47:43 +0100 x-mimeole: Produced By Microsoft Exchange V6.5.7235.2 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 3 Jun 2007 07:47:42 +0100 Message-ID: <0E48B768805E4D44A70709C8AE09209097DFA0@EMAILEMEA3.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: "IP NAPT traversal package: Update of the Remote Descriptor with the latched address information as a result of latch/relatch signal completion " Thread-Index: AcelqOIR/NxBK/ayTZW/VnWHBE4tAg== From: "Miri Epstein" To: X-OriginalArrivalTime: 03 Jun 2007 06:47:43.0833 (UTC) FILETIME=[16786C90:01C7A5AB] X-Spam-Score: 0.0 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 Cc: Elad Chomsky Subject: [Megaco] "IP NAPT traversal package: Update of the Remote Descriptor with the latched address information as a result of latch/relatch signal completion " X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Hi, Please see below. Sorry, but sending it as an attachment (.doc) is not possible. As a = result, the change proposals became not clear enough. Thx, Miri --------------------------- Miri Epstein System Architect VoIP Engineering Juniper Networks Direct +972.9.9717315 Fax +972.9.9717334 mepstein@juniper.net www.juniper.net ___________________ TELECOMMUNICATION STANDARDIZATION SECTOR STUDY PERIOD 2005-2008 STUDY GROUP 16 Original: English Question(s): Source: Juniper Networks Title: H.248.37 Amendment 1 - IP NAPT traversal package: Update of the Remote = Descriptor with the latched address information as a result of = latch/relatch signal completion.=20 Purpose: Proposal / Discussion=20 Problem: The IP NAPT traversal package does not provide the MGC with a method to = obtain the latched address information, resulting with a possible = ambiguity about "the address towards which packets are sent".=20 Problem Description:=20 The existing way for an MGC to learn about a remote destination address = change is by the reporting of the new address and port as defined by the = Address Reporting package (adr). This method is based on a Notify = command being sent from the MG. There is a significant drawback on using only this method. The latched = address information is not always available for MGC, for example, if the = Notify command was lost due to a network disconnection or an MGC = failover. In any such case, the MGC cannot retrieve this important = information. In addition, following a latch/relatch event, the customary method of = using an AuditValue command to synchronize between states of the MGC and = the MG may result in an error. Based on the reply of the AuditValue, the = MGC has no way of knowing whether the MG is still sending packets to the = address appearing in the Remote descriptor or to the new (latched) = address. In fact, the MGC might not even know that an ipnapt/latch = signal was ever applied to the stream. Following, we analyze the possible states for a stream regarding the = ipnapt/latch signal:=20 a) When the ipnapt/latch signal is not activated, the Remote Descriptor = represents the destination of the media packets. b) When the ipnapt/latch signal is activated, but no latching/relatching = has occurred yet, the Remote Descriptor still represents the destination = of the media packets.=20 c) After the stream has latched/relatched, the destination of the media = packets is the latched address (and port) and not the no-longer-valid = Remote Descriptor. The ipnapt/latch signal has completed, so an attempt = to audit the Signals Descriptor will not show it. This case is a new = state, different from both (a) and (b). However, the MGC cannot = distinguish (using AuditValue) between (a) and (c). This analysis demonstrates that the current approach creates a kind of = "hysteresis" - the result of a termination's AuditValue does not = encompass the complete gate state - but must be merged with past = information; the previous existence of an ipnapt/latch signal and a = received adr Notify. Also, this approach creates a deviation from the = semantic meaning of the Remote descriptor as "the address towards which = packets are sent". Suggested Solution: We suggest updating the Remote Descriptor with the latched address = information. The SDP connection data field will = hold the new address and the media field will hold the new port. = Both are updated as a result of latching/relatching. This permits the ordinary use of the AuditValue command with the Remote = Descriptor, at any time, in order to get the actual destination of the = media packets. This also makes state (c) above identical to state (a), eliminating the = AuditValue ambiguity. Further Incentives, the KeepActive flag: Because states (a) and (c) above are indistinguishable by the MGC, = clause 5.6.5 suggests the use of the KeepActive flag in order to avoid = the state (a, b or c) changing following a Modify of the Signals = Descriptor. This use appears inconsistent with clause 7.11 of H.248.1: "Signals = present in the replacement descriptor and containing the KeepActive flag = shall be continued if they are currently playing and have not already = completed. If a replacement Signals Descriptor contains a signal that is = not currently playing and contains the KeepActive flag, that signal = shall be ignored." Therefore it would seem that even if the KeepActive = flag is used, a Modify of the Signals Descriptor should cause state (c) = above to revert to (a). This issue is avoided by having the latch completion update the Remote = Descriptor. As the MG always sends media towards the address appearing = in the Remote Descriptor, there is no need for a special mechanism for = maintaining state (c). Conclusion: By updating the Remote Descriptor with the latched address information, = we achieve a simple and standardized way to facilitate tracking and = tracing changes of the destination of media packets. Also, this update makes the specialized use of the KeepActive signal = flag redundant. Correspondent changes are proposed below. Change proposal against TD-35: =A0[Begin Proposal] 5.6.2=A0=A0=A0=A0 NAPT traversal processing: 'LATCH' mode When the NAPT processing signal latch with parameter napt on a = termination/stream is set to LATCH, then this results in the MG updating = the addresses received in the RemoteDescriptor. The MG will use the = source address and source port from the incoming media stream (i.e., = from the other terminations) as the destination address and destination = port of the outgoing application data. The RemoteDescriptor is updated = with these new source address and source port. Figure 2/H.248.37 = illustrates this behaviour.=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0 To the figure: an additional rectangle = containing "Remote Address=3DCPE1"should be inserted under the existing = one (marked with "x") =A0=A0=A0=A0=A0=A0=A0=A0 Latching is limited on the very first IP packet = arrival event. Source address information of = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0afterwards received = IP packets will not be used for latching. [End Change Proposal] [Begin Proposal] 5.6.2.1.2=A0=A0=A0=A0=A0 RecvOnly or Inactive before latching In all cases here, the initial StreamMode is supposed to be "RecvOnly" = or "Inactive.=20 There are following possibilities: * Underspecified RD without initial remote destination address = information, but all other descriptor elements are available:=20 Initially no packets will be sent because the destination address = information is not available and because restricted by StreamMode = settings. The first packet arrival event after enabling 'LATCH' will = allow packet sending (dependent on StreamMode settings). * Still missing RD:=A0=A0=A0=A0=A0=20 There could be theoretically already IP packets sent after the first = packet arrival event after enabling 'LATCH' (given that StreamMode = settings have changed for sending). But this is questionable in practice = due to potentially "meaningless IP packets" (e.g. still missing correct = media field, format list, etc.).=A0=A0=A0=A0=A0=A0=20 The packet sending process should be therefore tightly coupled with RD, = i.e. the availability of all required information elements. Initial signaled remote destination address information (in RD):=A0=20 The packet sending process will not be started as long as the initial = StreamMode settings will not be changed to a value of SendOnly or = SendReceive. Nevertheless, the first packet arrival event after enabling = 'LATCH' will overwrite the remote destination address in the = RemoteDescriptor with the latched address, independent of whether the = H.248 signalled address information is equal to or unequal to the = latched address information.=A0=A0=A0=A0=A0=20 [End Change Proposal] [Begin Proposal]=20 5.6.3=A0=A0=A0=A0 NAPT traversal processing: 'RELATCH' mode When the NAT traversal processing signal latch with parameter napt on a = termination/stream is set to RELATCH, then the MG will perform a similar = process to the latching process described above. The difference is that = the MG will check for a change of source IP address/port on the incoming = media stream. If/when a new source IP address and/or port are detected, = then they will be updated in the Remote Descriptor and used as the = destination address and port for future outgoing packets. After = re-latching, any packets received on the old source address and port = combination will be considered as malicious and will be treated = accordingly (discarded and possibly counted; see sub-clause=A05.6.6). = This is an implicit filter rule related to source filtering. This = implicit filter conditions may be overruled by other, explicit filter = rules as defined by other H.248 packages, see clause 7. The packet sending process in 'RELATCH' mode, before and after = successful re-latching, has again the two dependencies on * available destination address information (IP DA, IP DP), and NOTE: Information is implicitly available after re-latching and may be = available before the re-latching event dependent on RD settings. * StreamMode settings. Application of 'RELATCH' mode does not imply a previous 'LATCH' mode. = New IP terminations may be therefore initially enabled for the 'RELATCH' = mode by the ADD.request command. [End Change Proposal] =A0[Begin Proposal]=20 5.6.4.1=A0=A0=A0=A0=A0 Recommendations for 'LATCH' and 'RELATCH' mode The generic event g/sc, associated to signal latch,=20 * could be useful for MGCs which are interested in successful (or = unsuccessful) latching occurrences, * but is basically not required for the application of ipnapt package. * If requested by the MGC, the signal completion event would be returned = when packets are received according to the latching process (e.g. MG = detects a packet coming from a different address for the particular = stream).=A0=20 The signal completion event would be returned irrespective of the = address in the RD. The MGC may ask for the address information the MG is using as a result = of the latch process by usage of the adr package (see clause=A06), or by = issuing an AuditValue command with the RemoteDescriptor. * If requested by the MGC, the signal completion event would be returned = when packets are received according to the latching process (e.g. MG = detects a packet coming from a different address for the particular = stream).=A0=20 The signal completion event would be returned irrespective of the = address in the RD. ME: this last sentence can be removed.=20 [End Change Proposal] [Begin Proposal]=20 5.6.5=A0=A0=A0=A0 Usage of signal 'latch' together with signal parameter = 'KeepActive' The KeepActive flag could be principally combined with signal latch (in = new Signals Descriptor), see clause=A07.1.11/H.248.1. The KeepActive = flag is required to support the following use case: The MGC starts the (re)latching process; and does not know whether the = process has completed. If, later on, the MGC modifies the ephemeral = termination signals descriptor, the MGC adds the KeepActive flag to = avoid either turning the signal on (if it has already completed) or off = (if it was not completed yet). =A0[End Change Proposal] ___________________ _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Sun Jun 03 07:41:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuoSL-0007Qc-3n; Sun, 03 Jun 2007 07:41:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuoSJ-0007QX-IM for megaco@ietf.org; Sun, 03 Jun 2007 07:41:07 -0400 Received: from mx2-n.rad.co.il ([62.0.23.221] helo=antivir2.rad.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuoSI-00062B-Rd for megaco@ietf.org; Sun, 03 Jun 2007 07:41:07 -0400 Received: from exrad3.rad.co.il (HELO exrad3.ad.rad.co.il) ([192.114.24.112]) by antivir2.rad.co.il with ESMTP; 03 Jun 2007 14:41:03 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 3 Jun 2007 14:41:03 +0300 Message-ID: <457D36D9D89B5B47BC06DA869B1C815D036261E5@exrad3.ad.rad.co.il> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Responding to COT (ct/rsp) Thread-Index: AceWVbFwutlU2pw2Qoa5H/IVVsU/GA== From: "Ron Gilaad" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: Asaf Vadai Subject: [Megaco] Responding to COT (ct/rsp) X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0266530403==" Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============0266530403== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A5D4.106E7E2C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A5D4.106E7E2C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, According to H.248: Upon reception of a command with the rsp Signal, the MG either applies a loopback or (for 2-wire circuits) awaits reception of a continuity test tone. According to Megaco/H.248 Call flow examples draft (page 122): http://tools.ietf.org/html/draft-ietf-megaco-callflows-04, There can be two possible cases for responding to the continuity test originated from the PSTN network. In the first case the Trunking Gateway generates a signal whose frequency is different from the frequency of the received signal and in the second case it loops back the received signal to the switch that originated it. In this example we assume the case of Loopback. The mode of the termination is also set to loopback to facilitate this. Here is the example from the draft: MGC to TGW: MEGACO/1 [216.33.33.61 <> ]: 27000 Transaction =3D 1234 { Context =3D '-' { Modify =3D Trunk1/line1 {Media { TerminationState {ServiceState =3D test} LocalControl { mode =3D loopback} } Signals =3D = { ct/rsp } } } }=20 My questions is: How shall the MG react when receiving the ct/rsp signal? H.248 assumes that for 4 wires circuits the MG shall apply a loopback and there are no other choices. The draft, on the other hand, claims that the loopback indication is set using the LocalControl { mode =3D loopback}. Since LocalControl is part of the media stream, when receiving such a command from the MGC, our MG tries to create a new stream and fails because the termination is under test). Thanks in advance, Ron=20 Ron Gilaad RAD Data Communications. 24 Raoul Wallenberg St. Tel Aviv 69719 Tel: 972-3-6455411=20 mailto:ron_g@rad.com ------_=_NextPart_001_01C7A5D4.106E7E2C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Responding to COT (ct/rsp)

Hi = all,

According = to H.248: Upon reception of a command with the rsp Signal, the MG either = applies a loopback or (for 2-wire circuits) awaits reception of a = continuity

test = tone.

According to Megaco/H.248 Call flow examples draft (page 122): http://tools.ietf.org/html/draft-ietf-megaco-callflows-04<= /FONT>, There can be two = possible cases for responding to the continuity test originated from the = PSTN network. In the first case the Trunking Gateway generates a signal = whose frequency is different from the frequency of the received signal = and in the second case it loops back the received signal to the switch = that originated it. In this example we assume the case of Loopback. The = mode of the termination is also set to loopback to facilitate this. Here = is the example from the draft:

MGC to = TGW: MEGACO/1 [216.33.33.61]: 27000 Transaction =3D 1234 { Context =3D '-' = { Modify =3D Trunk1/line1 {Media { TerminationState {ServiceState =3D = test} LocalControl { mode =3D loopback} } Signals =3D { ct/rsp } } } } =

My = questions is: How shall the MG react when receiving the ct/rsp signal? = H.248 assumes that for 4 wires circuits the MG shall apply a loopback = and there are no other choices. The draft, on the other hand, claims = that the loopback indication is set using the LocalControl { mode =3D = loopback}. Since LocalControl is part of the media stream, when = receiving such a command from the MGC, our MG tries to create a new = stream and fails because the termination is under test).

Thanks = in advance,

Ron =

Ron = Gilaad

RAD Data = Communications.

24 Raoul = Wallenberg St.

Tel Aviv = 69719

Tel: = 972-3-6455411

mailto:ron_g@rad.com

------_=_NextPart_001_01C7A5D4.106E7E2C-- --===============0266530403== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0266530403==-- From megaco-bounces@ietf.org Sun Jun 03 11:46:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HusHK-0008LF-5i; Sun, 03 Jun 2007 11:46:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HusHI-0008JE-UW for megaco@ietf.org; Sun, 03 Jun 2007 11:46:00 -0400 Received: from mx2-n.rad.co.il ([62.0.23.221] helo=antivir2.rad.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HusHH-0006HP-IK for megaco@ietf.org; Sun, 03 Jun 2007 11:46:00 -0400 Received: from exrad3.rad.co.il (HELO exrad3.ad.rad.co.il) ([192.114.24.112]) by antivir2.rad.co.il with ESMTP; 03 Jun 2007 18:45:54 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 3 Jun 2007 18:45:54 +0300 Message-ID: <457D36D9D89B5B47BC06DA869B1C815D036261E7@exrad3.ad.rad.co.il> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Stop responding to COT (ct/rsp) Thread-Index: AceWVbFwutlU2pw2Qoa5H/IVVsU/GA== From: "Ron Gilaad" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Subject: [Megaco] Stop responding to COT (ct/rsp) X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0837549297==" Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============0837549297== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A5F6.44F0C4A9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A5F6.44F0C4A9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, How does the MGC tells the MG to stop responding to COT?=20 I.e. in case the MG set a loop, how does the MGC tells the MG to stop the loop? Thanks in advance, Ron Gilaad RAD Data Communications. 24 Raoul Wallenberg St. Tel Aviv 69719 Tel: 972-3-6455411=20 mailto:ron_g@rad.com ------_=_NextPart_001_01C7A5F6.44F0C4A9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stop responding to COT (ct/rsp)

Hi = all,

How does = the MGC tells the MG to stop responding to COT?

I.e. in = case the MG set a loop, how does the MGC tells the MG to stop the = loop?

Thanks = in advance,

Ron = Gilaad

RAD Data = Communications.

24 Raoul = Wallenberg St.

Tel Aviv = 69719

Tel: = 972-3-6455411

mailto:ron_g@rad.com

------_=_NextPart_001_01C7A5F6.44F0C4A9-- --===============0837549297== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0837549297==-- From megaco-bounces@ietf.org Mon Jun 04 00:41:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv4NC-0002VA-Vg; Mon, 04 Jun 2007 00:40:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv4NB-0002SM-Gu for megaco@ietf.org; Mon, 04 Jun 2007 00:40:53 -0400 Received: from wa-out-1112.google.com ([209.85.146.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hv4N9-0000CZ-4u for megaco@ietf.org; Mon, 04 Jun 2007 00:40:53 -0400 Received: by wa-out-1112.google.com with SMTP id j5so243964wah for ; Sun, 03 Jun 2007 21:40:50 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=ZnDXCSAiGjJaXmfLWEsK79bM31F+xhbgz4aD2NddL8FpIglZRaH6ceDUOjhEGa279Pf9PqLTZmT1QqiLjf67Dc/vQR4tH3xU3pRk8FlvGAC0/x0Y/02h+OFFqix4fjTozbSM9efHzMCo7iOlJVI3BlbBQvbbeBbVvPEDbgmTo+M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=sQe1+fyBrCTijxWgsZN+t/sdsOVT9xxEFfVSDz6n4OEk4Hv3YRD2L6sTne7riCmKyTJkZjFVpdQBjRYx1YNK1TqhFldzCHfRY6uCPoKieUhjo1sT3YvaYvywCH32+c5ViqjrL1nKljG0ae3D/pmFnF0lQZzlNOmXFk2HnDUKXJw= Received: by 10.114.25.3 with SMTP id 3mr4464879way.1180932049149; Sun, 03 Jun 2007 21:40:49 -0700 (PDT) Received: by 10.114.171.11 with HTTP; Sun, 3 Jun 2007 21:40:49 -0700 (PDT) Message-ID: <2ef41d6d0706032140o477b23efq8473cc5c3af7330f@mail.gmail.com> Date: Sun, 3 Jun 2007 21:40:49 -0700 From: "Jisu Bhattacharya" To: "Miri Epstein" Subject: Re: [Megaco] "IP NAPT traversal package: Update of the Remote Descriptor with the latched address information as a result of latch/relatch signal completion " In-Reply-To: <0E48B768805E4D44A70709C8AE09209097DFA0@EMAILEMEA3.jnpr.net> MIME-Version: 1.0 References: <0E48B768805E4D44A70709C8AE09209097DFA0@EMAILEMEA3.jnpr.net> X-Spam-Score: 1.1 (+) X-Scan-Signature: d11a451997816a91a305dcb5ab1b85dd Cc: Elad Chomsky , megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1689639864==" Errors-To: megaco-bounces@ietf.org --===============1689639864== Content-Type: multipart/alternative; boundary="----=_Part_31962_31935207.1180932049096" ------=_Part_31962_31935207.1180932049096 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Miri, There is a small problem with your proposal. The KeepActive in Signals is not available in the ETSI_BGF profile (I've checked until version 1.1.4) . Table 27: KeepActive KeepActive used on signals: No So, KeepActive will not be usable with ETSI_BGF profile, one of the primary candidates for this package. Thanks, Jisu Bhattacharya Cisco Systems On 6/2/07, Miri Epstein wrote: > > Hi, > > Please see below. > Sorry, but sending it as an attachment (.doc) is not possible. As a > result, the change proposals became not clear enough. > > Thx, > Miri > --------------------------- > Miri Epstein > System Architect > VoIP Engineering > Juniper Networks > Direct +972.9.9717315 > Fax +972.9.9717334 > mepstein@juniper.net > www.juniper.net > > ___________________ > > TELECOMMUNICATION > STANDARDIZATION SECTOR > STUDY PERIOD 2005-2008 > STUDY GROUP 16 > > Original: English > Question(s): > Source: > Juniper Networks > Title: > H.248.37 Amendment 1 - IP NAPT traversal package: Update of the Remote > Descriptor with the latched address information as a result of latch/relatch > signal completion. > > Purpose: > Proposal / Discussion > > Problem: > The IP NAPT traversal package does not provide the MGC with a method to > obtain the latched address information, resulting with a possible ambiguity > about "the address towards which packets are sent". > > Problem Description: > The existing way for an MGC to learn about a remote destination address > change is by the reporting of the new address and port as defined by the > Address Reporting package (adr). This method is based on a Notify command > being sent from the MG. > There is a significant drawback on using only this method. The latched > address information is not always available for MGC, for example, if the > Notify command was lost due to a network disconnection or an MGC failover. > In any such case, the MGC cannot retrieve this important information. > In addition, following a latch/relatch event, the customary method of > using an AuditValue command to synchronize between states of the MGC and the > MG may result in an error. Based on the reply of the AuditValue, the MGC has > no way of knowing whether the MG is still sending packets to the address > appearing in the Remote descriptor or to the new (latched) address. In fact, > the MGC might not even know that an ipnapt/latch signal was ever applied to > the stream. > Following, we analyze the possible states for a stream regarding the > ipnapt/latch signal: > a) When the ipnapt/latch signal is not activated, the Remote Descriptor > represents the destination of the media packets. > b) When the ipnapt/latch signal is activated, but no latching/relatching > has occurred yet, the Remote Descriptor still represents the destination of > the media packets. > c) After the stream has latched/relatched, the destination of the media > packets is the latched address (and port) and not the no-longer-valid Remote > Descriptor. The ipnapt/latch signal has completed, so an attempt to audit > the Signals Descriptor will not show it. This case is a new state, different > from both (a) and (b). However, the MGC cannot distinguish (using > AuditValue) between (a) and (c). > This analysis demonstrates that the current approach creates a kind of > "hysteresis" - the result of a termination's AuditValue does not encompass > the complete gate state - but must be merged with past information; the > previous existence of an ipnapt/latch signal and a received adr Notify. > Also, this approach creates a deviation from the semantic meaning of the > Remote descriptor as "the address towards which packets are sent". > > Suggested Solution: > We suggest updating the Remote Descriptor with the latched address > information. The SDP connection data field will hold > the new address and the media field will hold the new port. Both are > updated as a result of latching/relatching. > This permits the ordinary use of the AuditValue command with the Remote > Descriptor, at any time, in order to get the actual destination of the media > packets. > This also makes state (c) above identical to state (a), eliminating the > AuditValue ambiguity. > > Further Incentives, the KeepActive flag: > Because states (a) and (c) above are indistinguishable by the MGC, clause > 5.6.5 suggests the use of the KeepActive flag in order to avoid the state > (a, b or c) changing following a Modify of the Signals Descriptor. > This use appears inconsistent with clause 7.11 of H.248.1: "Signals > present in the replacement descriptor and containing the KeepActive flag > shall be continued if they are currently playing and have not already > completed. If a replacement Signals Descriptor contains a signal that is not > currently playing and contains the KeepActive flag, that signal shall be > ignored." Therefore it would seem that even if the KeepActive flag is used, > a Modify of the Signals Descriptor should cause state (c) above to revert to > (a). > This issue is avoided by having the latch completion update the Remote > Descriptor. As the MG always sends media towards the address appearing in > the Remote Descriptor, there is no need for a special mechanism for > maintaining state (c). > > Conclusion: > By updating the Remote Descriptor with the latched address information, we > achieve a simple and standardized way to facilitate tracking and tracing > changes of the destination of media packets. > Also, this update makes the specialized use of the KeepActive signal flag > redundant. > Correspondent changes are proposed below. > > Change proposal against TD-35: > [Begin Proposal] > 5.6.2 NAPT traversal processing: 'LATCH' mode > When the NAPT processing signal latch with parameter napt on a > termination/stream is set to LATCH, then this results in the MG updating the > addresses received in the RemoteDescriptor. The MG will use the source > address and source port from the incoming media stream (i.e., from the > other terminations) as the destination address and destination port of the > outgoing application data. The RemoteDescriptor is updated with these new > source address and source port. Figure 2/H.248.37 illustrates this > behaviour. > To the figure: an additional rectangle containing "Remote > Address=CPE1"should be inserted under the existing one (marked with "x") > Latching is limited on the very first IP packet arrival event. Source > address information of afterwards received IP packets will not be used for > latching. > [End Change Proposal] > > [Begin Proposal] > 5.6.2.1.2 RecvOnly or Inactive before latching > In all cases here, the initial StreamMode is supposed to be "RecvOnly" or > "Inactive. > There are following possibilities: > * Underspecified RD without initial remote destination address > information, but all other descriptor elements are available: > Initially no packets will be sent because the destination address > information is not available and because restricted by StreamMode settings. > The first packet arrival event after enabling 'LATCH' will allow packet > sending (dependent on StreamMode settings). > * Still missing RD: > There could be theoretically already IP packets sent after the first > packet arrival event after enabling 'LATCH' (given that StreamMode settings > have changed for sending). But this is questionable in practice due to > potentially "meaningless IP packets" (e.g. still missing correct media > field, format list, etc.). > The packet sending process should be therefore tightly coupled with RD, > i.e. the availability of all required information elements. > Initial signaled remote destination address information (in RD): > The packet sending process will not be started as long as the initial > StreamMode settings will not be changed to a value of SendOnly or > SendReceive. Nevertheless, the first packet arrival event after enabling > 'LATCH' will overwrite the remote destination address in the > RemoteDescriptor with the latched address, independent of whether the > H.248 signalled address information is equal to or unequal to the latched > address information. > [End Change Proposal] > > [Begin Proposal] > 5.6.3 NAPT traversal processing: 'RELATCH' mode > When the NAT traversal processing signal latch with parameter napt on a > termination/stream is set to RELATCH, then the MG will perform a similar > process to the latching process described above. The difference is that the > MG will check for a change of source IP address/port on the incoming media > stream. If/when a new source IP address and/or port are detected, then they > will be updated in the Remote Descriptor and used as the destination address > and port for future outgoing packets. After re-latching, any packets > received on the old source address and port combination will be considered > as malicious and will be treated accordingly (discarded and possibly > counted; see sub-clause5.6.6). This is an implicit filter rule related to > source filtering. This implicit filter conditions may be overruled by other, > explicit filter rules as defined by other H.248 packages, see clause 7. > The packet sending process in 'RELATCH' mode, before and after successful > re-latching, has again the two dependencies on > * available destination address information (IP DA, IP DP), and > NOTE: Information is implicitly available after re-latching and may be > available before the re-latching event dependent on RD settings. > * StreamMode settings. > Application of 'RELATCH' mode does not imply a previous 'LATCH' mode. New > IP terminations may be therefore initially enabled for the 'RELATCH' mode by > the ADD.request command. > [End Change Proposal] > > [Begin Proposal] > 5.6.4.1 Recommendations for 'LATCH' and 'RELATCH' mode > The generic event g/sc, associated to signal latch, > * could be useful for MGCs which are interested in successful (or > unsuccessful) latching occurrences, > * but is basically not required for the application of ipnapt package. > * If requested by the MGC, the signal completion event would be returned > when packets are received according to the latching process (e.g. MG > detects a packet coming from a different address for the particular stream). > The signal completion event would be returned irrespective of the address > in the RD. > The MGC may ask for the address information the MG is using as a result of > the latch process by usage of the adr package (see clause6), or by issuing > an AuditValue command with the RemoteDescriptor. > > * If requested by the MGC, the signal completion event would be returned > when packets are received according to the latching process (e.g. MG > detects a packet coming from a different address for the particular stream). > The signal completion event would be returned irrespective of the address > in the RD. ME: this last sentence can be removed. > [End Change Proposal] > > [Begin Proposal] > 5.6.5 Usage of signal 'latch' together with signal parameter 'KeepActive' > The KeepActive flag could be principally combined with signal latch (in > new Signals Descriptor), see clause7.1.11/H.248.1. The KeepActive flag is > required to support the following use case: > The MGC starts the (re)latching process; and does not know whether the > process has completed. If, later on, the MGC modifies the ephemeral > termination signals descriptor, the MGC adds the KeepActive flag to avoid > either turning the signal on (if it has already completed) or off (if it was > not completed yet). > > [End Change Proposal] > > > ___________________ > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > ------=_Part_31962_31935207.1180932049096 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Miri,

There is a small problem with your proposal. The KeepActive in Signals is not available in the ETSI_BGF profile (I've checked until version 1.1.4) .

Table 27: KeepActive

KeepActive used on signals:

So, KeepActive will not be usable with ETSI_BGF profile, one of the primary candidates for this package.

Thanks,
Jisu Bhattacharya
Cisco Systems

On 6/2/07, Miri Epstein <mepstein@juniper.net> wrote:

Hi,

Please see below.
Sorry, but sending it as an attachment (.doc) is not possible. As a result, the change proposals became not clear enough.

Thx,
Miri
---------------------------
Miri Epstein
System Architect
VoIP Engineering
Juniper Networks
Direct +972.9.9717315
Fax +972.9.9717334
mepstein@juniper.net
www.juniper.net

___________________

TELECOMMUNICATION
STANDARDIZATION SECTOR
STUDY PERIOD 2005-2008
STUDY GROUP 16

Original: English
Question(s):
Source:
Juniper Networks
Title:
H.248.37 Amendment 1 - IP NAPT traversal package: Update of the Remote Descriptor with the latched address information as a result of latch/relatch signal completion.

Purpose:
Proposal / Discussion

Problem:
The IP NAPT traversal package does not provide the MGC with a method to obtain the latched address information, resulting with a possible ambiguity about "the address towards which packets are sent".

Problem Description:
The existing way for an MGC to learn about a remote destination address change is by the reporting of the new address and port as defined by the Address Reporting package (adr). This method is based on a Notify command being sent from the MG.
There is a significant drawback on using only this method. The latched address information is not always available for MGC, for example, if the Notify command was lost due to a network disconnection or an MGC failover. In any such case, the MGC cannot retrieve this important information.
In addition, following a latch/relatch event, the customary method of using an AuditValue command to synchronize between states of the MGC and the MG may result in an error. Based on the reply of the AuditValue, the MGC has no way of knowing whether the MG is still sending packets to the address appearing in the Remote descriptor or to the new (latched) address. In fact, the MGC might not even know that an ipnapt/latch signal was ever applied to the stream.
Following, we analyze the possible states for a stream regarding the ipnapt/latch signal:
a) When the ipnapt/latch signal is not activated, the Remote Descriptor represents the destination of the media packets.
b) When the ipnapt/latch signal is activated, but no latching/relatching has occurred yet, the Remote Descriptor still represents the destination of the media packets.
c) After the stream has latched/relatched, the destination of the media packets is the latched address (and port) and not the no-longer-valid Remote Descriptor. The ipnapt/latch signal has completed, so an attempt to audit the Signals Descriptor will not show it. This case is a new state, different from both (a) and (b). However, the MGC cannot distinguish (using AuditValue) between (a) and (c).
This analysis demonstrates that the current approach creates a kind of "hysteresis" - the result of a termination's AuditValue does not encompass the complete gate state - but must be merged with past information; the previous existence of an ipnapt/latch signal and a received adr Notify. Also, this approach creates a deviation from the semantic meaning of the Remote descriptor as "the address towards which packets are sent".

Suggested Solution:
We suggest updating the Remote Descriptor with the latched address information. The SDP connection data field <connection-address> will hold the new address and the media field <port> will hold the new port. Both are updated as a result of latching/relatching.
This permits the ordinary use of the AuditValue command with the Remote Descriptor, at any time, in order to get the actual destination of the media packets.
This also makes state (c) above identical to state (a), eliminating the AuditValue ambiguity.

Further Incentives, the KeepActive flag:
Because states (a) and (c) above are indistinguishable by the MGC, clause 5.6.5 suggests the use of the KeepActive flag in order to avoid the state (a, b or c) changing following a Modify of the Signals Descriptor.
This use appears inconsistent with clause 7.11 of H.248.1: "Signals present in the replacement descriptor and containing the KeepActive flag shall be continued if they are currently playing and have not already completed. If a replacement Signals Descriptor contains a signal that is not currently playing and contains the KeepActive flag, that signal shall be ignored." Therefore it would seem that even if the KeepActive flag is used, a Modify of the Signals Descriptor should cause state (c) above to revert to (a).
This issue is avoided by having the latch completion update the Remote Descriptor. As the MG always sends media towards the address appearing in the Remote Descriptor, there is no need for a special mechanism for maintaining state (c).

Conclusion:
By updating the Remote Descriptor with the latched address information, we achieve a simple and standardized way to facilitate tracking and tracing changes of the destination of media packets.
Also, this update makes the specialized use of the KeepActive signal flag redundant.
Correspondent changes are proposed below.

Change proposal against TD-35:
[Begin Proposal]
5.6.2 NAPT traversal processing: 'LATCH' mode
When the NAPT processing signal latch with parameter napt on a termination/stream is set to LATCH, then this results in the MG updating the addresses received in the RemoteDescriptor. The MG will use the source address and source port from the incoming media stream ( i.e., from the other terminations) as the destination address and destination port of the outgoing application data. The RemoteDescriptor is updated with these new source address and source port. Figure 2/H.248.37 illustrates this behaviour.
To the figure: an additional rectangle containing "Remote Address=CPE1"should be inserted under the existing one (marked with "x")
Latching is limited on the very first IP packet arrival event. Source address information of afterwards received IP packets will not be used for latching.
[End Change Proposal]

[Begin Proposal]
5.6.2.1.2 RecvOnly or Inactive before latching
In all cases here, the initial StreamMode is supposed to be "RecvOnly" or "Inactive.
There are following possibilities:
* Underspecified RD without initial remote destination address information, but all other descriptor elements are available:
Initially no packets will be sent because the destination address information is not available and because restricted by StreamMode settings. The first packet arrival event after enabling 'LATCH' will allow packet sending (dependent on StreamMode settings).
* Still missing RD:
There could be theoretically already IP packets sent after the first packet arrival event after enabling 'LATCH' (given that StreamMode settings have changed for sending). But this is questionable in practice due to potentially "meaningless IP packets" ( e.g. still missing correct media field, format list, etc.).
The packet sending process should be therefore tightly coupled with RD, i.e. the availability of all required information elements.
Initial signaled remote destination address information (in RD):
The packet sending process will not be started as long as the initial StreamMode settings will not be changed to a value of SendOnly or SendReceive. Nevertheless, the first packet arrival event after enabling 'LATCH' will overwrite the remote destination address in the RemoteDescriptor with the latched address, independent of whether the H.248 signalled address information is equal to or unequal to the latched address information.
[End Change Proposal]

[Begin Proposal]
5.6.3 NAPT traversal processing: 'RELATCH' mode
When the NAT traversal processing signal latch with parameter napt on a termination/stream is set to RELATCH, then the MG will perform a similar process to the latching process described above. The difference is that the MG will check for a change of source IP address/port on the incoming media stream. If/when a new source IP address and/or port are detected, then they will be updated in the Remote Descriptor and used as the destination address and port for future outgoing packets. After re-latching, any packets received on the old source address and port combination will be considered as malicious and will be treated accordingly (discarded and possibly counted; see sub-clause5.6.6). This is an implicit filter rule related to source filtering. This implicit filter conditions may be overruled by other, explicit filter rules as defined by other H.248 packages, see clause 7.
The packet sending process in 'RELATCH' mode, before and after successful re-latching, has again the two dependencies on
* available destination address information (IP DA, IP DP), and
NOTE: Information is implicitly available after re-latching and may be available before the re-latching event dependent on RD settings.
* StreamMode settings.
Application of 'RELATCH' mode does not imply a previous 'LATCH' mode. New IP terminations may be therefore initially enabled for the 'RELATCH' mode by the ADD.request command.
[End Change Proposal]

[Begin Proposal]
5.6.4.1 Recommendations for 'LATCH' and 'RELATCH' mode
The generic event g/sc, associated to signal latch,
* could be useful for MGCs which are interested in successful (or unsuccessful) latching occurrences,
* but is basically not required for the application of ipnapt package.
* If requested by the MGC, the signal completion event would be returned when packets are received according to the latching process (e.g. MG detects a packet coming from a different address for the particular stream).
The signal completion event would be returned irrespective of the address in the RD.
The MGC may ask for the address information the MG is using as a result of the latch process by usage of the adr package (see clause6), or by issuing an AuditValue command with the RemoteDescriptor.

* If requested by the MGC, the signal completion event would be returned when packets are received according to the latching process (e.g. MG detects a packet coming from a different address for the particular stream).
The signal completion event would be returned irrespective of the address in the RD. ME: this last sentence can be removed.
[End Change Proposal]

[Begin Proposal]
5.6.5 Usage of signal 'latch' together with signal parameter 'KeepActive'
The KeepActive flag could be principally combined with signal latch (in new Signals Descriptor), see clause7.1.11/H.248.1. The KeepActive flag is required to support the following use case:
The MGC starts the (re)latching process; and does not know whether the process has completed. If, later on, the MGC modifies the ephemeral termination signals descriptor, the MGC adds the KeepActive flag to avoid either turning the signal on (if it has already completed) or off (if it was not completed yet).

[End Change Proposal]

___________________

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

------=_Part_31962_31935207.1180932049096-- --===============1689639864== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1689639864==-- From megaco-bounces@ietf.org Mon Jun 04 00:45:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv4RS-0007tD-Eu; Mon, 04 Jun 2007 00:45:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv4RQ-0007kG-QV for megaco@ietf.org; Mon, 04 Jun 2007 00:45:16 -0400 Received: from ipmail02.adl2.internode.on.net ([203.16.214.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hv4RN-0000rS-5K for megaco@ietf.org; Mon, 04 Jun 2007 00:45:16 -0400 X-IronPort-AV: E=Sophos;i="4.16,378,1175437800"; d="scan'208";a="133588458" Received: from ppp205-253.lns3.mel4.internode.on.net (HELO [127.0.0.1]) ([121.44.205.253]) by ipmail02.adl2.internode.on.net with ESMTP; 04 Jun 2007 14:15:05 +0930 Message-ID: <466398CF.20108@nteczone.com> Date: Mon, 04 Jun 2007 14:45:03 +1000 From: Christian Groves User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Jisu Bhattacharya Subject: Re: [Megaco] "IP NAPT traversal package: Update of the Remote Descriptor with the latched address information as a result of latch/relatch signal completion " References: <0E48B768805E4D44A70709C8AE09209097DFA0@EMAILEMEA3.jnpr.net> <2ef41d6d0706032140o477b23efq8473cc5c3af7330f@mail.gmail.com> In-Reply-To: <2ef41d6d0706032140o477b23efq8473cc5c3af7330f@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478 Cc: Elad Chomsky , megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Hello Jisu, I can't see why this is a problem. The profile itself would have to be updated to meet the new proposal. Keepactive could be changed then. Regards, Christian Jisu Bhattacharya wrote: > Miri, > > There is a small problem with your proposal. The KeepActive in Signals > is not available in the ETSI_BGF profile (I've checked until version > 1.1.4) . > > Table 27: KeepActive > > KeepActive used on signals: > > > > No > > > So, KeepActive will not be usable with ETSI_BGF profile, one of the > primary candidates for this package. > > Thanks, > Jisu Bhattacharya > Cisco Systems > > On 6/2/07, * Miri Epstein* > wrote: > > Hi, > > Please see below. > Sorry, but sending it as an attachment (.doc) is not possible. As > a result, the change proposals became not clear enough. > > Thx, > Miri > --------------------------- > Miri Epstein > System Architect > VoIP Engineering > Juniper Networks > Direct +972.9.9717315 > Fax +972.9.9717334 > mepstein@juniper.net > www.juniper.net > > ___________________ > > TELECOMMUNICATION > STANDARDIZATION SECTOR > STUDY PERIOD 2005-2008 > STUDY GROUP 16 > > Original: English > Question(s): > Source: > Juniper Networks > Title: > H.248.37 Amendment 1 - IP NAPT traversal package: Update of the > Remote Descriptor with the latched address information as a result > of latch/relatch signal completion. > > Purpose: > Proposal / Discussion > > Problem: > The IP NAPT traversal package does not provide the MGC with a > method to obtain the latched address information, resulting with a > possible ambiguity about "the address towards which packets are > sent". > > Problem Description: > The existing way for an MGC to learn about a remote destination > address change is by the reporting of the new address and port as > defined by the Address Reporting package (adr). This method is > based on a Notify command being sent from the MG. > There is a significant drawback on using only this method. The > latched address information is not always available for MGC, for > example, if the Notify command was lost due to a network > disconnection or an MGC failover. In any such case, the MGC cannot > retrieve this important information. > In addition, following a latch/relatch event, the customary method > of using an AuditValue command to synchronize between states of > the MGC and the MG may result in an error. Based on the reply of > the AuditValue, the MGC has no way of knowing whether the MG is > still sending packets to the address appearing in the Remote > descriptor or to the new (latched) address. In fact, the MGC might > not even know that an ipnapt/latch signal was ever applied to the > stream. > Following, we analyze the possible states for a stream regarding > the ipnapt/latch signal: > a) When the ipnapt/latch signal is not activated, the Remote > Descriptor represents the destination of the media packets. > b) When the ipnapt/latch signal is activated, but no > latching/relatching has occurred yet, the Remote Descriptor still > represents the destination of the media packets. > c) After the stream has latched/relatched, the destination of the > media packets is the latched address (and port) and not the > no-longer-valid Remote Descriptor. The ipnapt/latch signal has > completed, so an attempt to audit the Signals Descriptor will not > show it. This case is a new state, different from both (a) and > (b). However, the MGC cannot distinguish (using AuditValue) > between (a) and (c). > This analysis demonstrates that the current approach creates a > kind of "hysteresis" - the result of a termination's AuditValue > does not encompass the complete gate state - but must be merged > with past information; the previous existence of an ipnapt/latch > signal and a received adr Notify. Also, this approach creates a > deviation from the semantic meaning of the Remote descriptor as > "the address towards which packets are sent". > > Suggested Solution: > We suggest updating the Remote Descriptor with the latched address > information. The SDP connection data field > will hold the new address and the media field will hold the > new port. Both are updated as a result of latching/relatching. > This permits the ordinary use of the AuditValue command with the > Remote Descriptor, at any time, in order to get the actual > destination of the media packets. > This also makes state (c) above identical to state (a), > eliminating the AuditValue ambiguity. > > Further Incentives, the KeepActive flag: > Because states (a) and (c) above are indistinguishable by the MGC, > clause 5.6.5 suggests the use of the KeepActive flag in order to > avoid the state (a, b or c) changing following a Modify of the > Signals Descriptor. > This use appears inconsistent with clause 7.11 of H.248.1: > "Signals present in the replacement descriptor and containing the > KeepActive flag shall be continued if they are currently playing > and have not already completed. If a replacement Signals > Descriptor contains a signal that is not currently playing and > contains the KeepActive flag, that signal shall be ignored." > Therefore it would seem that even if the KeepActive flag is used, > a Modify of the Signals Descriptor should cause state (c) above to > revert to (a). > This issue is avoided by having the latch completion update the > Remote Descriptor. As the MG always sends media towards the > address appearing in the Remote Descriptor, there is no need for a > special mechanism for maintaining state (c). > > Conclusion: > By updating the Remote Descriptor with the latched address > information, we achieve a simple and standardized way to > facilitate tracking and tracing changes of the destination of > media packets. > Also, this update makes the specialized use of the KeepActive > signal flag redundant. > Correspondent changes are proposed below. > > Change proposal against TD-35: > [Begin Proposal] > 5.6.2 NAPT traversal processing: 'LATCH' mode > When the NAPT processing signal latch with parameter napt on a > termination/stream is set to LATCH, then this results in the MG > updating the addresses received in the RemoteDescriptor. The MG > will use the source address and source port from the incoming > media stream ( i.e., from the other terminations) as the > destination address and destination port of the outgoing > application data. The RemoteDescriptor is updated with these new > source address and source port. Figure 2/H.248.37 illustrates this > behaviour. > To the figure: an additional rectangle containing "Remote > Address=CPE1"should be inserted under the existing one (marked > with "x") > Latching is limited on the very first IP packet arrival event. > Source address information of afterwards received IP packets will > not be used for latching. > [End Change Proposal] > > [Begin Proposal] > 5.6.2.1.2 RecvOnly or Inactive before latching > In all cases here, the initial StreamMode is supposed to be > "RecvOnly" or "Inactive. > There are following possibilities: > * Underspecified RD without initial remote destination address > information, but all other descriptor elements are available: > Initially no packets will be sent because the destination address > information is not available and because restricted by StreamMode > settings. The first packet arrival event after enabling 'LATCH' > will allow packet sending (dependent on StreamMode settings). > * Still missing RD: > There could be theoretically already IP packets sent after the > first packet arrival event after enabling 'LATCH' (given that > StreamMode settings have changed for sending). But this is > questionable in practice due to potentially "meaningless IP > packets" ( e.g. still missing correct media field, format list, etc.). > The packet sending process should be therefore tightly coupled > with RD, i.e. the availability of all required information elements. > Initial signaled remote destination address information (in RD): > The packet sending process will not be started as long as the > initial StreamMode settings will not be changed to a value of > SendOnly or SendReceive. Nevertheless, the first packet arrival > event after enabling 'LATCH' will overwrite the remote destination > address in the RemoteDescriptor with the latched address, > independent of whether the H.248 signalled address information is > equal to or unequal to the latched address information. > [End Change Proposal] > > [Begin Proposal] > 5.6.3 NAPT traversal processing: 'RELATCH' mode > When the NAT traversal processing signal latch with parameter napt > on a termination/stream is set to RELATCH, then the MG will > perform a similar process to the latching process described above. > The difference is that the MG will check for a change of source IP > address/port on the incoming media stream. If/when a new source IP > address and/or port are detected, then they will be updated in the > Remote Descriptor and used as the destination address and port for > future outgoing packets. After re-latching, any packets received > on the old source address and port combination will be considered > as malicious and will be treated accordingly (discarded and > possibly counted; see sub-clause5.6.6). This is an implicit filter > rule related to source filtering. This implicit filter conditions > may be overruled by other, explicit filter rules as defined by > other H.248 packages, see clause 7. > The packet sending process in 'RELATCH' mode, before and after > successful re-latching, has again the two dependencies on > * available destination address information (IP DA, IP DP), and > NOTE: Information is implicitly available after re-latching and > may be available before the re-latching event dependent on RD > settings. > * StreamMode settings. > Application of 'RELATCH' mode does not imply a previous 'LATCH' > mode. New IP terminations may be therefore initially enabled for > the 'RELATCH' mode by the ADD.request command. > [End Change Proposal] > > [Begin Proposal] > 5.6.4.1 Recommendations for 'LATCH' and 'RELATCH' > mode > The generic event g/sc, associated to signal latch, > * could be useful for MGCs which are interested in successful (or > unsuccessful) latching occurrences, > * but is basically not required for the application of ipnapt package. > * If requested by the MGC, the signal completion event would be > returned when packets are received according to the latching > process (e.g. MG detects a packet coming from a different address > for the particular stream). > The signal completion event would be returned irrespective of the > address in the RD. > The MGC may ask for the address information the MG is using as a > result of the latch process by usage of the adr package (see > clause6), or by issuing an AuditValue command with the > RemoteDescriptor. > > * If requested by the MGC, the signal completion event would be > returned when packets are received according to the latching > process (e.g. MG detects a packet coming from a different address > for the particular stream). > The signal completion event would be returned irrespective of the > address in the RD. ME: this last sentence can be removed. > [End Change Proposal] > > [Begin Proposal] > 5.6.5 Usage of signal 'latch' together with signal parameter > 'KeepActive' > The KeepActive flag could be principally combined with signal > latch (in new Signals Descriptor), see clause7.1.11/H.248.1. The > KeepActive flag is required to support the following use case: > The MGC starts the (re)latching process; and does not know whether > the process has completed. If, later on, the MGC modifies the > ephemeral termination signals descriptor, the MGC adds the > KeepActive flag to avoid either turning the signal on (if it has > already completed) or off (if it was not completed yet). > > [End Change Proposal] > > > ___________________ > > _______________________________________________ > 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-bounces@ietf.org Mon Jun 04 11:30:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvEVa-0007zq-Ut; Mon, 04 Jun 2007 11:30:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuwHg-0006yJ-7t for megaco@ietf.org; Sun, 03 Jun 2007 16:02:40 -0400 Received: from wr-out-0506.google.com ([64.233.184.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuwHf-00025F-0q for megaco@ietf.org; Sun, 03 Jun 2007 16:02:40 -0400 Received: by wr-out-0506.google.com with SMTP id m59so713242wrm for ; Sun, 03 Jun 2007 13:02:38 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=JdnDLTeUOHtlsy6Z2e2QmRzXrYB9lu3gifzcKjSwjSYLrsivkZP0+TtR2BwnHqswlwu+2nlmGfuRCM5n4O+3kZqGLkSiBBOi6tyYoa35tXFdJQoX3qft8t3qJsjl3o56QBoidRf3SYfiYi+cewa/JR5h7E3O8QFM4sQDlVQQSD4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=IMrsIPC2PiJzv0Fz3xEwBBnYXKwuzOHjn+owlWx+42gMOswllkvsj63cgFjQ3sD6RJ5a6VvqAXzBOBUjy77XM2kodkMg0Oem3Jh+2QloyFywKVVzfE237KxBIvai0UJ5CVhQ8D9CtpdctEllXdw/ACgyajsjtsks3ZripgMcFRs= Received: by 10.100.112.19 with SMTP id k19mr2195000anc.1180900958479; Sun, 03 Jun 2007 13:02:38 -0700 (PDT) Received: by 10.100.153.1 with HTTP; Sun, 3 Jun 2007 13:02:38 -0700 (PDT) Message-ID: <2c04dc350706031302v37955e09n99a33b24f2388421@mail.gmail.com> Date: Sun, 3 Jun 2007 22:02:38 +0200 From: "Claudio Fontana" To: megaco@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-Mailman-Approved-At: Mon, 04 Jun 2007 11:30:13 -0400 Subject: [Megaco] Megaco, SCTP and IP addresses X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Hello all, I am monitoring some megaco [ver 1, BER, IPv4/SCTP/M3UA] traffic, and I see something that should _not_ be ok if I read the involved standards correctly. I see the equivalent (data changed, but meaning preserved) of these two messages on the wire, delta_t=3 milliseconds. No ServiceChange or Notify between the two. [message 1, Transaction REQUEST, tid=0x155d3327 ctxid=CHOOSE] mid: 10.5.100.22/2945 ADD REQUEST ip/sctp src: 10.5.100.22/2945 dest: 10.5.100.1/8009 [message 2, Transaction REPLY, tid=0x155d3327 ctxid = 0x0220c197] mid: 10.5.100.1/8009 ADD REPLY ip/sctp src:10.5.101.1/8009 dest: 10.5.101.22/2945 Now, H.248.4 says in the overview that for SCTP "Responses must be sent to the address and port from which the corresponding commands were sent, except if the response is to a handoff or failover, in which case the procedures of 11.5/H.248.1 apply." This is not the case with the traffic I am seeing here. Is there some exception I should know of, or is this simply wrong? Thank you for your kind advice, Claudio Fontana _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Tue Jun 05 01:03:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvRCm-0006dv-BB; Tue, 05 Jun 2007 01:03:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvRCl-0006dp-Bl for megaco@ietf.org; Tue, 05 Jun 2007 01:03:39 -0400 Received: from wa-out-1112.google.com ([209.85.146.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvRCh-0001SF-TP for megaco@ietf.org; Tue, 05 Jun 2007 01:03:39 -0400 Received: by wa-out-1112.google.com with SMTP id j5so749327wah for ; Mon, 04 Jun 2007 22:03:35 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=pvj+H85uViKJr48cxhj37EsH2tr9axt+4kL5AduKKzQAaRXZ7hH4kEwHEWK+hoQ6wK38aU3eSSEWAOzKRBQAcRownRfybndaCmXMhV01CSuWP3/vGQn4iybEd3iV2OwVeqCrD+6HizVJUZm6d1buSPynNY7tOs7yMSYBrjz38g8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=g2LSdw9XrE1B13vJwfDsne6Y11euLpvTNZzpRTGeTSitQ06zxp+C3SKF9fEQK8xF1jeqXK2V+EnPZwYSfjTsW9FsSWGQ15cbNBcTvhtSOWvJNxXzltAHAbYWDAbUHCMHUm6qXzsRCs2OcR1UB5lpalXDIUsRCgoQZvp5rf1B85s= Received: by 10.115.54.1 with SMTP id g1mr5533353wak.1181019815038; Mon, 04 Jun 2007 22:03:35 -0700 (PDT) Received: by 10.114.171.11 with HTTP; Mon, 4 Jun 2007 22:03:34 -0700 (PDT) Message-ID: <2ef41d6d0706042203y406ce62ek35e7c774781076cb@mail.gmail.com> Date: Mon, 4 Jun 2007 22:03:34 -0700 From: "Jisu Bhattacharya" To: "Christian Groves" Subject: Re: [Megaco] "IP NAPT traversal package: Update of the Remote Descriptor with the latched address information as a result of latch/relatch signal completion " In-Reply-To: <466398CF.20108@nteczone.com> MIME-Version: 1.0 References: <0E48B768805E4D44A70709C8AE09209097DFA0@EMAILEMEA3.jnpr.net> <2ef41d6d0706032140o477b23efq8473cc5c3af7330f@mail.gmail.com> <466398CF.20108@nteczone.com> X-Spam-Score: 0.7 (/) X-Scan-Signature: 509eeaf340e89c687918a6101c6def35 Cc: Elad Chomsky , megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1367263634==" Errors-To: megaco-bounces@ietf.org --===============1367263634== Content-Type: multipart/alternative; boundary="----=_Part_17312_17239820.1181019814991" ------=_Part_17312_17239820.1181019814991 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Christian, How do we ensure that the profile update is being done to keep it in sync with the package modifications? Thanks, Jisu Bhattacharya Cisco Systems On 6/3/07, Christian Groves wrote: > > Hello Jisu, > > I can't see why this is a problem. The profile itself would have to be > updated to meet the new proposal. Keepactive could be changed then. > > Regards, Christian > > Jisu Bhattacharya wrote: > > Miri, > > > > There is a small problem with your proposal. The KeepActive in Signals > > is not available in the ETSI_BGF profile (I've checked until version > > 1.1.4) . > > > > Table 27: KeepActive > > > > KeepActive used on signals: > > > > > > > > No > > > > > > So, KeepActive will not be usable with ETSI_BGF profile, one of the > > primary candidates for this package. > > > > Thanks, > > Jisu Bhattacharya > > Cisco Systems > > > > On 6/2/07, * Miri Epstein* > > wrote: > > > > Hi, > > > > Please see below. > > Sorry, but sending it as an attachment (.doc) is not possible. As > > a result, the change proposals became not clear enough. > > > > Thx, > > Miri > > --------------------------- > > Miri Epstein > > System Architect > > VoIP Engineering > > Juniper Networks > > Direct +972.9.9717315 > > Fax +972.9.9717334 > > mepstein@juniper.net > > www.juniper.net > > > > ___________________ > > > > TELECOMMUNICATION > > STANDARDIZATION SECTOR > > STUDY PERIOD 2005-2008 > > STUDY GROUP 16 > > > > Original: English > > Question(s): > > Source: > > Juniper Networks > > Title: > > H.248.37 Amendment 1 - IP NAPT traversal package: Update of the > > Remote Descriptor with the latched address information as a result > > of latch/relatch signal completion. > > > > Purpose: > > Proposal / Discussion > > > > Problem: > > The IP NAPT traversal package does not provide the MGC with a > > method to obtain the latched address information, resulting with a > > possible ambiguity about "the address towards which packets are > > sent". > > > > Problem Description: > > The existing way for an MGC to learn about a remote destination > > address change is by the reporting of the new address and port as > > defined by the Address Reporting package (adr). This method is > > based on a Notify command being sent from the MG. > > There is a significant drawback on using only this method. The > > latched address information is not always available for MGC, for > > example, if the Notify command was lost due to a network > > disconnection or an MGC failover. In any such case, the MGC cannot > > retrieve this important information. > > In addition, following a latch/relatch event, the customary method > > of using an AuditValue command to synchronize between states of > > the MGC and the MG may result in an error. Based on the reply of > > the AuditValue, the MGC has no way of knowing whether the MG is > > still sending packets to the address appearing in the Remote > > descriptor or to the new (latched) address. In fact, the MGC might > > not even know that an ipnapt/latch signal was ever applied to the > > stream. > > Following, we analyze the possible states for a stream regarding > > the ipnapt/latch signal: > > a) When the ipnapt/latch signal is not activated, the Remote > > Descriptor represents the destination of the media packets. > > b) When the ipnapt/latch signal is activated, but no > > latching/relatching has occurred yet, the Remote Descriptor still > > represents the destination of the media packets. > > c) After the stream has latched/relatched, the destination of the > > media packets is the latched address (and port) and not the > > no-longer-valid Remote Descriptor. The ipnapt/latch signal has > > completed, so an attempt to audit the Signals Descriptor will not > > show it. This case is a new state, different from both (a) and > > (b). However, the MGC cannot distinguish (using AuditValue) > > between (a) and (c). > > This analysis demonstrates that the current approach creates a > > kind of "hysteresis" - the result of a termination's AuditValue > > does not encompass the complete gate state - but must be merged > > with past information; the previous existence of an ipnapt/latch > > signal and a received adr Notify. Also, this approach creates a > > deviation from the semantic meaning of the Remote descriptor as > > "the address towards which packets are sent". > > > > Suggested Solution: > > We suggest updating the Remote Descriptor with the latched address > > information. The SDP connection data field > > will hold the new address and the media field will hold the > > new port. Both are updated as a result of latching/relatching. > > This permits the ordinary use of the AuditValue command with the > > Remote Descriptor, at any time, in order to get the actual > > destination of the media packets. > > This also makes state (c) above identical to state (a), > > eliminating the AuditValue ambiguity. > > > > Further Incentives, the KeepActive flag: > > Because states (a) and (c) above are indistinguishable by the MGC, > > clause 5.6.5 suggests the use of the KeepActive flag in order to > > avoid the state (a, b or c) changing following a Modify of the > > Signals Descriptor. > > This use appears inconsistent with clause 7.11 of H.248.1: > > "Signals present in the replacement descriptor and containing the > > KeepActive flag shall be continued if they are currently playing > > and have not already completed. If a replacement Signals > > Descriptor contains a signal that is not currently playing and > > contains the KeepActive flag, that signal shall be ignored." > > Therefore it would seem that even if the KeepActive flag is used, > > a Modify of the Signals Descriptor should cause state (c) above to > > revert to (a). > > This issue is avoided by having the latch completion update the > > Remote Descriptor. As the MG always sends media towards the > > address appearing in the Remote Descriptor, there is no need for a > > special mechanism for maintaining state (c). > > > > Conclusion: > > By updating the Remote Descriptor with the latched address > > information, we achieve a simple and standardized way to > > facilitate tracking and tracing changes of the destination of > > media packets. > > Also, this update makes the specialized use of the KeepActive > > signal flag redundant. > > Correspondent changes are proposed below. > > > > Change proposal against TD-35: > > [Begin Proposal] > > 5.6.2 NAPT traversal processing: 'LATCH' mode > > When the NAPT processing signal latch with parameter napt on a > > termination/stream is set to LATCH, then this results in the MG > > updating the addresses received in the RemoteDescriptor. The MG > > will use the source address and source port from the incoming > > media stream ( i.e., from the other terminations) as the > > destination address and destination port of the outgoing > > application data. The RemoteDescriptor is updated with these new > > source address and source port. Figure 2/H.248.37 illustrates this > > behaviour. > > To the figure: an additional rectangle containing "Remote > > Address=CPE1"should be inserted under the existing one (marked > > with "x") > > Latching is limited on the very first IP packet arrival event. > > Source address information of afterwards received IP packets will > > not be used for latching. > > [End Change Proposal] > > > > [Begin Proposal] > > 5.6.2.1.2 RecvOnly or Inactive before latching > > In all cases here, the initial StreamMode is supposed to be > > "RecvOnly" or "Inactive. > > There are following possibilities: > > * Underspecified RD without initial remote destination address > > information, but all other descriptor elements are available: > > Initially no packets will be sent because the destination address > > information is not available and because restricted by StreamMode > > settings. The first packet arrival event after enabling 'LATCH' > > will allow packet sending (dependent on StreamMode settings). > > * Still missing RD: > > There could be theoretically already IP packets sent after the > > first packet arrival event after enabling 'LATCH' (given that > > StreamMode settings have changed for sending). But this is > > questionable in practice due to potentially "meaningless IP > > packets" ( e.g. still missing correct media field, format list, > etc.). > > The packet sending process should be therefore tightly coupled > > with RD, i.e. the availability of all required information elements. > > Initial signaled remote destination address information (in RD): > > The packet sending process will not be started as long as the > > initial StreamMode settings will not be changed to a value of > > SendOnly or SendReceive. Nevertheless, the first packet arrival > > event after enabling 'LATCH' will overwrite the remote destination > > address in the RemoteDescriptor with the latched address, > > independent of whether the H.248 signalled address information is > > equal to or unequal to the latched address information. > > [End Change Proposal] > > > > [Begin Proposal] > > 5.6.3 NAPT traversal processing: 'RELATCH' mode > > When the NAT traversal processing signal latch with parameter napt > > on a termination/stream is set to RELATCH, then the MG will > > perform a similar process to the latching process described above. > > The difference is that the MG will check for a change of source IP > > address/port on the incoming media stream. If/when a new source IP > > address and/or port are detected, then they will be updated in the > > Remote Descriptor and used as the destination address and port for > > future outgoing packets. After re-latching, any packets received > > on the old source address and port combination will be considered > > as malicious and will be treated accordingly (discarded and > > possibly counted; see sub-clause5.6.6). This is an implicit filter > > rule related to source filtering. This implicit filter conditions > > may be overruled by other, explicit filter rules as defined by > > other H.248 packages, see clause 7. > > The packet sending process in 'RELATCH' mode, before and after > > successful re-latching, has again the two dependencies on > > * available destination address information (IP DA, IP DP), and > > NOTE: Information is implicitly available after re-latching and > > may be available before the re-latching event dependent on RD > > settings. > > * StreamMode settings. > > Application of 'RELATCH' mode does not imply a previous 'LATCH' > > mode. New IP terminations may be therefore initially enabled for > > the 'RELATCH' mode by the ADD.request command. > > [End Change Proposal] > > > > [Begin Proposal] > > 5.6.4.1 Recommendations for 'LATCH' and 'RELATCH' > > mode > > The generic event g/sc, associated to signal latch, > > * could be useful for MGCs which are interested in successful (or > > unsuccessful) latching occurrences, > > * but is basically not required for the application of ipnapt > package. > > * If requested by the MGC, the signal completion event would be > > returned when packets are received according to the latching > > process (e.g. MG detects a packet coming from a different address > > for the particular stream). > > The signal completion event would be returned irrespective of the > > address in the RD. > > The MGC may ask for the address information the MG is using as a > > result of the latch process by usage of the adr package (see > > clause6), or by issuing an AuditValue command with the > > RemoteDescriptor. > > > > * If requested by the MGC, the signal completion event would be > > returned when packets are received according to the latching > > process (e.g. MG detects a packet coming from a different address > > for the particular stream). > > The signal completion event would be returned irrespective of the > > address in the RD. ME: this last sentence can be removed. > > [End Change Proposal] > > > > [Begin Proposal] > > 5.6.5 Usage of signal 'latch' together with signal parameter > > 'KeepActive' > > The KeepActive flag could be principally combined with signal > > latch (in new Signals Descriptor), see clause7.1.11/H.248.1. The > > KeepActive flag is required to support the following use case: > > The MGC starts the (re)latching process; and does not know whether > > the process has completed. If, later on, the MGC modifies the > > ephemeral termination signals descriptor, the MGC adds the > > KeepActive flag to avoid either turning the signal on (if it has > > already completed) or off (if it was not completed yet). > > > > [End Change Proposal] > > > > > > ___________________ > > > > _______________________________________________ > > 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 > > > ------=_Part_17312_17239820.1181019814991 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Christian,

How do we ensure that the profile update is being done to keep it in sync with the package modifications?

Thanks,
Jisu Bhattacharya
Cisco Systems

On 6/3/07, Christian Groves <Christian.Groves@nteczone.com> wrote:

Hello Jisu,

I can't see why this is a problem. The profile itself would have to be
updated to meet the new proposal. Keepactive could be changed then.

Regards, Christian

Jisu Bhattacharya wrote:
> Miri,
>
> There is a small problem with your proposal. The KeepActive in Signals
> is not available in the ETSI_BGF profile (I've checked until version
> 1.1.4) .
>
> Table 27: KeepActive
>
> KeepActive used on signals:
>
>
>
> No
>
>
> So, KeepActive will not be usable with ETSI_BGF profile, one of the
> primary candidates for this package.
>
> Thanks,
> Jisu Bhattacharya
> Cisco Systems
>
> On 6/2/07, * Miri Epstein* <mepstein@juniper.net
> <mailto: mepstein@juniper.net>> wrote:
>
>     Hi,
>
>     Please see below.
>     Sorry, but sending it as an attachment (.doc) is not possible. As
>     a result, the change proposals became not clear enough.
>
>     Thx,
>     Miri
>     ---------------------------
>     Miri Epstein
>     System Architect
>     VoIP Engineering
>     Juniper Networks
>     Direct +972.9.9717315
>     Fax +972.9.9717334
>     mepstein@juniper.net <mailto:mepstein@juniper.net>
>     www.juniper.net <http://www.juniper.net>
>
>     ___________________
>
>     TELECOMMUNICATION
>     STANDARDIZATION SECTOR
>     STUDY PERIOD 2005-2008
>     STUDY GROUP 16
>
>     Original: English
>     Question(s):
>     Source:
>     Juniper Networks
>     Title:
>     H.248.37 Amendment 1 - IP NAPT traversal package: Update of the
>     Remote Descriptor with the latched address information as a result
>     of latch/relatch signal completion.
>
>     Purpose:
>     Proposal / Discussion
>
>     Problem:
>     The IP NAPT traversal package does not provide the MGC with a
>     method to obtain the latched address information, resulting with a
>     possible ambiguity about "the address towards which packets are
>     sent".
>
>     Problem Description:
>     The existing way for an MGC to learn about a remote destination
>     address change is by the reporting of the new address and port as
>     defined by the Address Reporting package (adr). This method is
>     based on a Notify command being sent from the MG.
>     There is a significant drawback on using only this method. The
>     latched address information is not always available for MGC, for
>     example, if the Notify command was lost due to a network
>     disconnection or an MGC failover. In any such case, the MGC cannot
>     retrieve this important information.
>     In addition, following a latch/relatch event, the customary method
>     of using an AuditValue command to synchronize between states of
>     the MGC and the MG may result in an error. Based on the reply of
>     the AuditValue, the MGC has no way of knowing whether the MG is
>     still sending packets to the address appearing in the Remote
>     descriptor or to the new (latched) address. In fact, the MGC might
>     not even know that an ipnapt/latch signal was ever applied to the
>     stream.
>     Following, we analyze the possible states for a stream regarding
>     the ipnapt/latch signal:
>     a) When the ipnapt/latch signal is not activated, the Remote
>     Descriptor represents the destination of the media packets.
>     b) When the ipnapt/latch signal is activated, but no
>     latching/relatching has occurred yet, the Remote Descriptor still
>     represents the destination of the media packets.
>     c) After the stream has latched/relatched, the destination of the
>     media packets is the latched address (and port) and not the
>     no-longer-valid Remote Descriptor. The ipnapt/latch signal has
>     completed, so an attempt to audit the Signals Descriptor will not
>     show it. This case is a new state, different from both (a) and
>     (b). However, the MGC cannot distinguish (using AuditValue)
>     between (a) and (c).
>     This analysis demonstrates that the current approach creates a
>     kind of "hysteresis" - the result of a termination's AuditValue
>     does not encompass the complete gate state - but must be merged
>     with past information; the previous existence of an ipnapt/latch
>     signal and a received adr Notify. Also, this approach creates a
>     deviation from the semantic meaning of the Remote descriptor as
>     "the address towards which packets are sent".
>
>     Suggested Solution:
>     We suggest updating the Remote Descriptor with the latched address
>     information. The SDP connection data field <connection-address>
>     will hold the new address and the media field <port> will hold the
>     new port. Both are updated as a result of latching/relatching.
>     This permits the ordinary use of the AuditValue command with the
>     Remote Descriptor, at any time, in order to get the actual
>     destination of the media packets.
>     This also makes state (c) above identical to state (a),
>     eliminating the AuditValue ambiguity.
>
>     Further Incentives, the KeepActive flag:
>     Because states (a) and (c) above are indistinguishable by the MGC,
>     clause 5.6.5 suggests the use of the KeepActive flag in order to
>     avoid the state (a, b or c) changing following a Modify of the
>     Signals Descriptor.
>     This use appears inconsistent with clause 7.11 of H.248.1:
>     "Signals present in the replacement descriptor and containing the
>     KeepActive flag shall be continued if they are currently playing
>     and have not already completed. If a replacement Signals
>     Descriptor contains a signal that is not currently playing and
>     contains the KeepActive flag, that signal shall be ignored."
>     Therefore it would seem that even if the KeepActive flag is used,
>     a Modify of the Signals Descriptor should cause state (c) above to
>     revert to (a).
>     This issue is avoided by having the latch completion update the
>     Remote Descriptor. As the MG always sends media towards the
>     address appearing in the Remote Descriptor, there is no need for a
>     special mechanism for maintaining state (c).
>
>     Conclusion:
>     By updating the Remote Descriptor with the latched address
>     information, we achieve a simple and standardized way to
>     facilitate tracking and tracing changes of the destination of
>     media packets.
>     Also, this update makes the specialized use of the KeepActive
>     signal flag redundant.
>     Correspondent changes are proposed below.
>
>     Change proposal against TD-35:
>     [Begin Proposal]
>     5.6.2 NAPT traversal processing: 'LATCH' mode
>     When the NAPT processing signal latch with parameter napt on a
>     termination/stream is set to LATCH, then this results in the MG
>     updating the addresses received in the RemoteDescriptor. The MG
>     will use the source address and source port from the incoming
>     media stream ( i.e., from the other terminations) as the
>     destination address and destination port of the outgoing
>     application data. The RemoteDescriptor is updated with these new
>     source address and source port. Figure 2/H.248.37 illustrates this
>     behaviour.
>     To the figure: an additional rectangle containing "Remote
>     Address=CPE1"should be inserted under the existing one (marked
>     with "x")
>     Latching is limited on the very first IP packet arrival event.
>     Source address information of afterwards received IP packets will
>     not be used for latching.
>     [End Change Proposal]
>
>     [Begin Proposal]
>     5.6.2.1.2 RecvOnly or Inactive before latching
>     In all cases here, the initial StreamMode is supposed to be
>     "RecvOnly" or "Inactive.
>     There are following possibilities:
>     * Underspecified RD without initial remote destination address
>     information, but all other descriptor elements are available:
>     Initially no packets will be sent because the destination address
>     information is not available and because restricted by StreamMode
>     settings. The first packet arrival event after enabling 'LATCH'
>     will allow packet sending (dependent on StreamMode settings).
>     * Still missing RD:
>     There could be theoretically already IP packets sent after the
>     first packet arrival event after enabling 'LATCH' (given that
>     StreamMode settings have changed for sending). But this is
>     questionable in practice due to potentially "meaningless IP
>     packets" ( e.g. still missing correct media field, format list, etc.).
>     The packet sending process should be therefore tightly coupled
>     with RD, i.e. the availability of all required information elements.
>     Initial signaled remote destination address information (in RD):
>     The packet sending process will not be started as long as the
>     initial StreamMode settings will not be changed to a value of
>     SendOnly or SendReceive. Nevertheless, the first packet arrival
>     event after enabling 'LATCH' will overwrite the remote destination
>     address in the RemoteDescriptor with the latched address,
>     independent of whether the H.248 signalled address information is
>     equal to or unequal to the latched address information.
>     [End Change Proposal]
>
>     [Begin Proposal]
>     5.6.3 NAPT traversal processing: 'RELATCH' mode
>     When the NAT traversal processing signal latch with parameter napt
>     on a termination/stream is set to RELATCH, then the MG will
>     perform a similar process to the latching process described above.
>     The difference is that the MG will check for a change of source IP
>     address/port on the incoming media stream. If/when a new source IP
>     address and/or port are detected, then they will be updated in the
>     Remote Descriptor and used as the destination address and port for
>     future outgoing packets. After re-latching, any packets received
>     on the old source address and port combination will be considered
>     as malicious and will be treated accordingly (discarded and
>     possibly counted; see sub-clause5.6.6). This is an implicit filter
>     rule related to source filtering. This implicit filter conditions
>     may be overruled by other, explicit filter rules as defined by
>     other H.248 packages, see clause 7.
>     The packet sending process in 'RELATCH' mode, before and after
>     successful re-latching, has again the two dependencies on
>     * available destination address information (IP DA, IP DP), and
>     NOTE: Information is implicitly available after re-latching and
>     may be available before the re-latching event dependent on RD
>     settings.
>     * StreamMode settings.
>     Application of 'RELATCH' mode does not imply a previous 'LATCH'
>     mode. New IP terminations may be therefore initially enabled for
>     the 'RELATCH' mode by the ADD.request command.
>     [End Change Proposal]
>
>     [Begin Proposal]
>     5.6.4.1 <http://5.6.4.1> Recommendations for 'LATCH' and 'RELATCH'
>     mode
>     The generic event g/sc, associated to signal latch,
>     * could be useful for MGCs which are interested in successful (or
>     unsuccessful) latching occurrences,
>     * but is basically not required for the application of ipnapt package.
>     * If requested by the MGC, the signal completion event would be
>     returned when packets are received according to the latching
>     process (e.g. MG detects a packet coming from a different address
>     for the particular stream).
>     The signal completion event would be returned irrespective of the
>     address in the RD.
>     The MGC may ask for the address information the MG is using as a
>     result of the latch process by usage of the adr package (see
>     clause6), or by issuing an AuditValue command with the
>     RemoteDescriptor.
>
>     * If requested by the MGC, the signal completion event would be
>     returned when packets are received according to the latching
>     process (e.g. MG detects a packet coming from a different address
>     for the particular stream).
>     The signal completion event would be returned irrespective of the
>     address in the RD. ME: this last sentence can be removed.
>     [End Change Proposal]
>
>     [Begin Proposal]
>     5.6.5 Usage of signal 'latch' together with signal parameter
>     'KeepActive'
>     The KeepActive flag could be principally combined with signal
>     latch (in new Signals Descriptor), see clause7.1.11/H.248.1. The
>     KeepActive flag is required to support the following use case:
>     The MGC starts the (re)latching process; and does not know whether
>     the process has completed. If, later on, the MGC modifies the
>     ephemeral termination signals descriptor, the MGC adds the
>     KeepActive flag to avoid either turning the signal on (if it has
>     already completed) or off (if it was not completed yet).
>
>     [End Change Proposal]
>
>
>     ___________________
>
>     _______________________________________________
>     Megaco mailing list
>     Megaco@ietf.org <mailto:Megaco@ietf.org>
>     https://www1.ietf.org/mailman/listinfo/megaco
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Megaco mailing list
> Megaco@ietf.org
> https://www1.ietf.org/mailman/listinfo/megaco
>

------=_Part_17312_17239820.1181019814991-- --===============1367263634== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1367263634==-- From megaco-bounces@ietf.org Tue Jun 05 01:12:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvRLQ-0004o5-OA; Tue, 05 Jun 2007 01:12:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvRLP-0004g8-4F for megaco@ietf.org; Tue, 05 Jun 2007 01:12:35 -0400 Received: from ipmail01.adl2.internode.on.net ([203.16.214.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvRLN-0003hK-6U for megaco@ietf.org; Tue, 05 Jun 2007 01:12:35 -0400 X-IronPort-AV: E=Sophos;i="4.16,383,1175437800"; d="scan'208";a="138932510" Received: from ppp195-197.lns3.mel4.internode.on.net (HELO [127.0.0.1]) ([121.44.195.197]) by ipmail01.adl2.internode.on.net with ESMTP; 05 Jun 2007 14:42:15 +0930 Message-ID: <4664F0AE.9000407@nteczone.com> Date: Tue, 05 Jun 2007 15:12:14 +1000 From: Christian Groves User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Jisu Bhattacharya Subject: Re: [Megaco] "IP NAPT traversal package: Update of the Remote Descriptor with the latched address information as a result of latch/relatch signal completion " References: <0E48B768805E4D44A70709C8AE09209097DFA0@EMAILEMEA3.jnpr.net> <2ef41d6d0706032140o477b23efq8473cc5c3af7330f@mail.gmail.com> <466398CF.20108@nteczone.com> <2ef41d6d0706042203y406ce62ek35e7c774781076cb@mail.gmail.com> In-Reply-To: <2ef41d6d0706042203y406ce62ek35e7c774781076cb@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: f0ea5880a0890be2408609376fa519aa Cc: Elad Chomsky , megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Hello Jisu, As the profile is owned by ETSI Tispan interested companies should contribute there to ensure they adopt the changes and keep in sync. Also Q.3/16 will most likely send a liaison to Tispan WG3 informing them of the progress on H.248.37 Amm1. If Miri's proposal is accepted then it would be contained in the liaison. Tispan as a result of the liaison could then decide to include it in their profile. Regards, Christian Jisu Bhattacharya wrote: > Christian, > > How do we ensure that the profile update is being done to keep it in > sync with the package modifications? > > Thanks, > Jisu Bhattacharya > Cisco Systems > > On 6/3/07, *Christian Groves* > wrote: > > Hello Jisu, > > I can't see why this is a problem. The profile itself would have to be > updated to meet the new proposal. Keepactive could be changed then. > > Regards, Christian > > Jisu Bhattacharya wrote: > > Miri, > > > > There is a small problem with your proposal. The KeepActive in > Signals > > is not available in the ETSI_BGF profile (I've checked until version > > 1.1.4) . > > > > Table 27: KeepActive > > > > KeepActive used on signals: > > > > > > > > No > > > > > > So, KeepActive will not be usable with ETSI_BGF profile, one of the > > primary candidates for this package. > > > > Thanks, > > Jisu Bhattacharya > > Cisco Systems > > > > On 6/2/07, * Miri Epstein* > > >> wrote: > > > > Hi, > > > > Please see below. > > Sorry, but sending it as an attachment (.doc) is not > possible. As > > a result, the change proposals became not clear enough. > > > > Thx, > > Miri > > --------------------------- > > Miri Epstein > > System Architect > > VoIP Engineering > > Juniper Networks > > Direct +972.9.9717315 > > Fax +972.9.9717334 > > mepstein@juniper.net > > > > www.juniper.net > > > > > ___________________ > > > > TELECOMMUNICATION > > STANDARDIZATION SECTOR > > STUDY PERIOD 2005-2008 > > STUDY GROUP 16 > > > > Original: English > > Question(s): > > Source: > > Juniper Networks > > Title: > > H.248.37 Amendment 1 - IP NAPT traversal package: Update of the > > Remote Descriptor with the latched address information as a > result > > of latch/relatch signal completion. > > > > Purpose: > > Proposal / Discussion > > > > Problem: > > The IP NAPT traversal package does not provide the MGC with a > > method to obtain the latched address information, resulting > with a > > possible ambiguity about "the address towards which packets are > > sent". > > > > Problem Description: > > The existing way for an MGC to learn about a remote destination > > address change is by the reporting of the new address and > port as > > defined by the Address Reporting package (adr). This method is > > based on a Notify command being sent from the MG. > > There is a significant drawback on using only this method. The > > latched address information is not always available for MGC, > for > > example, if the Notify command was lost due to a network > > disconnection or an MGC failover. In any such case, the MGC > cannot > > retrieve this important information. > > In addition, following a latch/relatch event, the customary > method > > of using an AuditValue command to synchronize between states of > > the MGC and the MG may result in an error. Based on the reply of > > the AuditValue, the MGC has no way of knowing whether the MG is > > still sending packets to the address appearing in the Remote > > descriptor or to the new (latched) address. In fact, the MGC > might > > not even know that an ipnapt/latch signal was ever applied > to the > > stream. > > Following, we analyze the possible states for a stream regarding > > the ipnapt/latch signal: > > a) When the ipnapt/latch signal is not activated, the Remote > > Descriptor represents the destination of the media packets. > > b) When the ipnapt/latch signal is activated, but no > > latching/relatching has occurred yet, the Remote Descriptor > still > > represents the destination of the media packets. > > c) After the stream has latched/relatched, the destination > of the > > media packets is the latched address (and port) and not the > > no-longer-valid Remote Descriptor. The ipnapt/latch signal has > > completed, so an attempt to audit the Signals Descriptor > will not > > show it. This case is a new state, different from both (a) and > > (b). However, the MGC cannot distinguish (using AuditValue) > > between (a) and (c). > > This analysis demonstrates that the current approach creates a > > kind of "hysteresis" - the result of a termination's AuditValue > > does not encompass the complete gate state - but must be merged > > with past information; the previous existence of an > ipnapt/latch > > signal and a received adr Notify. Also, this approach creates a > > deviation from the semantic meaning of the Remote descriptor as > > "the address towards which packets are sent". > > > > Suggested Solution: > > We suggest updating the Remote Descriptor with the latched > address > > information. The SDP connection data field > > will hold the new address and the media field will > hold the > > new port. Both are updated as a result of latching/relatching. > > This permits the ordinary use of the AuditValue command with the > > Remote Descriptor, at any time, in order to get the actual > > destination of the media packets. > > This also makes state (c) above identical to state (a), > > eliminating the AuditValue ambiguity. > > > > Further Incentives, the KeepActive flag: > > Because states (a) and (c) above are indistinguishable by > the MGC, > > clause 5.6.5 suggests the use of the KeepActive flag in order to > > avoid the state (a, b or c) changing following a Modify of the > > Signals Descriptor. > > This use appears inconsistent with clause 7.11 of H.248.1: > > "Signals present in the replacement descriptor and > containing the > > KeepActive flag shall be continued if they are currently > playing > > and have not already completed. If a replacement Signals > > Descriptor contains a signal that is not currently playing and > > contains the KeepActive flag, that signal shall be ignored." > > Therefore it would seem that even if the KeepActive flag is > used, > > a Modify of the Signals Descriptor should cause state (c) > above to > > revert to (a). > > This issue is avoided by having the latch completion update the > > Remote Descriptor. As the MG always sends media towards the > > address appearing in the Remote Descriptor, there is no need > for a > > special mechanism for maintaining state (c). > > > > Conclusion: > > By updating the Remote Descriptor with the latched address > > information, we achieve a simple and standardized way to > > facilitate tracking and tracing changes of the destination of > > media packets. > > Also, this update makes the specialized use of the KeepActive > > signal flag redundant. > > Correspondent changes are proposed below. > > > > Change proposal against TD-35: > > [Begin Proposal] > > 5.6.2 NAPT traversal processing: 'LATCH' mode > > When the NAPT processing signal latch with parameter napt on a > > termination/stream is set to LATCH, then this results in the MG > > updating the addresses received in the RemoteDescriptor. The MG > > will use the source address and source port from the incoming > > media stream ( i.e., from the other terminations) as the > > destination address and destination port of the outgoing > > application data. The RemoteDescriptor is updated with these new > > source address and source port. Figure 2/H.248.37 > illustrates this > > behaviour. > > To the figure: an additional rectangle containing "Remote > > Address=CPE1"should be inserted under the existing one (marked > > with "x") > > Latching is limited on the very first IP packet arrival event. > > Source address information of afterwards received IP packets > will > > not be used for latching. > > [End Change Proposal] > > > > [Begin Proposal] > > 5.6.2.1.2 RecvOnly or Inactive before latching > > In all cases here, the initial StreamMode is supposed to be > > "RecvOnly" or "Inactive. > > There are following possibilities: > > * Underspecified RD without initial remote destination address > > information, but all other descriptor elements are available: > > Initially no packets will be sent because the destination > address > > information is not available and because restricted by > StreamMode > > settings. The first packet arrival event after enabling 'LATCH' > > will allow packet sending (dependent on StreamMode settings). > > * Still missing RD: > > There could be theoretically already IP packets sent after the > > first packet arrival event after enabling 'LATCH' (given that > > StreamMode settings have changed for sending). But this is > > questionable in practice due to potentially "meaningless IP > > packets" ( e.g. still missing correct media field, format > list, etc.). > > The packet sending process should be therefore tightly coupled > > with RD, i.e. the availability of all required information > elements. > > Initial signaled remote destination address information (in > RD): > > The packet sending process will not be started as long as the > > initial StreamMode settings will not be changed to a value of > > SendOnly or SendReceive. Nevertheless, the first packet arrival > > event after enabling 'LATCH' will overwrite the remote > destination > > address in the RemoteDescriptor with the latched address, > > independent of whether the H.248 signalled address > information is > > equal to or unequal to the latched address information. > > [End Change Proposal] > > > > [Begin Proposal] > > 5.6.3 NAPT traversal processing: 'RELATCH' mode > > When the NAT traversal processing signal latch with > parameter napt > > on a termination/stream is set to RELATCH, then the MG will > > perform a similar process to the latching process described > above. > > The difference is that the MG will check for a change of > source IP > > address/port on the incoming media stream. If/when a new > source IP > > address and/or port are detected, then they will be updated > in the > > Remote Descriptor and used as the destination address and > port for > > future outgoing packets. After re-latching, any packets received > > on the old source address and port combination will be > considered > > as malicious and will be treated accordingly (discarded and > > possibly counted; see sub-clause5.6.6). This is an implicit > filter > > rule related to source filtering. This implicit filter > conditions > > may be overruled by other, explicit filter rules as defined by > > other H.248 packages, see clause 7. > > The packet sending process in 'RELATCH' mode, before and after > > successful re-latching, has again the two dependencies on > > * available destination address information (IP DA, IP DP), and > > NOTE: Information is implicitly available after re-latching and > > may be available before the re-latching event dependent on RD > > settings. > > * StreamMode settings. > > Application of 'RELATCH' mode does not imply a previous 'LATCH' > > mode. New IP terminations may be therefore initially enabled for > > the 'RELATCH' mode by the ADD.request command. > > [End Change Proposal] > > > > [Begin Proposal] > > 5.6.4.1 Recommendations > for 'LATCH' and 'RELATCH' > > mode > > The generic event g/sc, associated to signal latch, > > * could be useful for MGCs which are interested in > successful (or > > unsuccessful) latching occurrences, > > * but is basically not required for the application of > ipnapt package. > > * If requested by the MGC, the signal completion event would be > > returned when packets are received according to the latching > > process (e.g. MG detects a packet coming from a different > address > > for the particular stream). > > The signal completion event would be returned irrespective > of the > > address in the RD. > > The MGC may ask for the address information the MG is using as a > > result of the latch process by usage of the adr package (see > > clause6), or by issuing an AuditValue command with the > > RemoteDescriptor. > > > > * If requested by the MGC, the signal completion event would be > > returned when packets are received according to the latching > > process (e.g. MG detects a packet coming from a different > address > > for the particular stream). > > The signal completion event would be returned irrespective > of the > > address in the RD. ME: this last sentence can be removed. > > [End Change Proposal] > > > > [Begin Proposal] > > 5.6.5 Usage of signal 'latch' together with signal parameter > > 'KeepActive' > > The KeepActive flag could be principally combined with signal > > latch (in new Signals Descriptor), see clause7.1.11/H.248.1. The > > KeepActive flag is required to support the following use case: > > The MGC starts the (re)latching process; and does not know > whether > > the process has completed. If, later on, the MGC modifies the > > ephemeral termination signals descriptor, the MGC adds the > > KeepActive flag to avoid either turning the signal on (if it > has > > already completed) or off (if it was not completed yet). > > > > [End Change Proposal] > > > > > > ___________________ > > > > _______________________________________________ > > 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-bounces@ietf.org Tue Jun 05 02:02:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvS7Z-0001Ot-Nh; Tue, 05 Jun 2007 02:02:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvS7Y-0001Od-Fj for megaco@ietf.org; Tue, 05 Jun 2007 02:02:20 -0400 Received: from [61.95.244.212] (helo=in-smtp.ccpu.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvS7W-0006r0-LJ for megaco@ietf.org; Tue, 05 Jun 2007 02:02:20 -0400 Received: from in-smtp.ccpu.com (localhost.localdomain [127.0.0.1]) by localhost.ccpu.com (Postfix) with ESMTP id 67CE8B3E7C; Tue, 5 Jun 2007 11:25:50 +0530 (IST) Received: from IN-EXCHANGE.ccin.ccpu.com (in-exchange.ccpu.com [172.25.0.16]) by in-smtp.ccpu.com (Postfix) with ESMTP id 5C854B3E76; Tue, 5 Jun 2007 11:25:50 +0530 (IST) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Megaco] Reg contextAttrDescriptor Structure Difference between TEXT and ASN Modes Date: Tue, 5 Jun 2007 11:26:26 +0530 Message-ID: <22F058C3ED9D784E90CE473F2A9847F00169236F@in-exchange> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] Reg contextAttrDescriptor Structure Difference between TEXT and ASN Modes Thread-Index: Acei55PweohYI6wWQriN3wZTrBCrWAETfTIA From: "Arvind Charanyan" To: "Jisu Bhattacharya" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b21264b25b2584da3ddf2bd579ca48f Cc: Arvind Charanyan X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0799686417==" Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============0799686417== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A736.411D8038" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A736.411D8038 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 In the case you have mentioned below, if we can have "0 to one contextIdList AND 0 to infinite number of propertyParm (covered by the *(COMMA propertyParm))", then what would be the SEPARATOR between the two when both are present. =20 Looking forward to some inputs in this regard. =20 Thanks and Regards, Arvind =20 ________________________________ From: Jisu Bhattacharya [mailto:jisu72@gmail.com]=20 Sent: Wednesday, May 30, 2007 11:46 PM To: Arvind Charanyan Cc: megaco@ietf.org Subject: Re: [Megaco] Reg contextAttrDescriptor Structure Difference between TEXT and ASN Modes =20 Arvind, contextIdList / propertyParm *(COMMA propertyParm) does not mean a choice between contextIdList and propertyParm. It means that you can have 0 to one contextIdList AND 0 to infinite number of propertyParm (covered by the *(COMMA propertyParm)). However, it requires at least one contextIdList or propertParm to be present.=20 Hope this helps. Thanks, Jisu On 5/30/07, Arvind Charanyan wrote: Hi, =20 I have a doubt regarding the implementation of the contextAttrDescriptor in TEXT Mode.=20 =20 The ABNF definition for contextAttrDescriptor is as follows -=20 =20 contextAttrDescriptor =3D ContextAttrToken LBRKT (contextIdList / propertyParm *(COMMA propertyParm)) RBRKT =20 which means it is a choice between contextIDList and propertyparm. =20 But according to ASN Grammar, the ContextRequest is defined as follows - =20 ContextRequest ::=3D SEQUENCE { priority INTEGER(0..15) OPTIONAL, emergency BOOLEAN OPTIONAL, topologyReq SEQUENCE OF TopologyRequest OPTIONAL, ..., iepscallind BOOLEAN OPTIONAL, contextProp SEQUENCE OF PropertyParm OPTIONAL, contextList SEQUENCE OF ContextID OPTIONAL } =20 In this PropertyParm and ContextIDList are part of the sequence. =20 Can you please help me out by clarifying this ambiguity between ABNF and ASN Grammar? =20 Thanks, Arvind =20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco =20 ------_=_NextPart_001_01C7A736.411D8038 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

In the case you have mentioned = below, if we can have “0 to one contextIdList AND 0 to infinite number of propertyParm = (covered by the *(COMMA propertyParm))”, then what would be the SEPARATOR between the two when both = are present.

Looking forward to some inputs in = this regard.

Thanks and = Regards,

Arvind =

From: Jisu Bhattacharya [mailto:jisu72@gmail.com]
Sent: Wednesday, May 30, = 2007 11:46 PM
To: Arvind Charanyan
Cc: megaco@ietf.org
Subject: Re: [Megaco] Reg contextAttrDescriptor Structure Difference between TEXT and ASN = Modes

Arvind,

contextIdList / propertyParm = *(COMMA propertyParm)

does not mean a choice between contextIdList and propertyParm. It means = that you can have 0 to one contextIdList AND 0 to infinite number of = propertyParm (covered by the *(COMMA propertyParm)). However, it requires at least = one contextIdList or propertParm to be present.

Hope this helps.

Thanks,
Jisu

On 5/30/07, Arvind Charanyan <arvind.charanyan@ccpu.com > wrote:

Hi,=

I have a doubt regarding the implementation of the contextAttrDescriptor = in TEXT Mode.

The ABNF definition for contextAttrDescriptor is as follows – =

contextAttrDescriptor =3D ContextAttrToken LBRKT = (contextIdList / propertyParm *(COMMA propertyParm)) = RBRKT

which means it is a choice between contextIDList and = propertyparm.

But according to ASN Grammar, the ContextRequest is defined as follows = –

ContextRequest &nbs= p; = ; ::=3D SEQUENCE

{

= priority = ; = &= nbsp; &n= bsp; INTEGER(0..15) OPTIONAL,

= emergency &nbs= p; = ; = BOOLEAN OPTIONAL,

= topologyReq &n= bsp; &nb= sp; SEQUENCE OF TopologyRequest OPTIONAL,

&= nbsp; …,

&= nbsp; iepscallind &n= bsp; &nb= sp; &nbs= p; BOOLEAN OPTIONAL,

&= nbsp; contextProp &n= bsp; &nb= sp; &nbs= p; SEQUENCE OF PropertyParm OPTIONAL,

&= nbsp; contextList &n= bsp; &nb= sp; &nbs= p; SEQUENCE OF ContextID OPTIONAL

}

In this PropertyParm and ContextIDList are part of the = sequence.

Can you please help me out by clarifying this ambiguity between ABNF and ASN Grammar?

Thanks,

Arvind

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco<= /o:p>

------_=_NextPart_001_01C7A736.411D8038-- --===============0799686417== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0799686417==-- From within@allaroundthehome.com Tue Jun 05 12:00:17 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvbSC-0006Rz-51 for megaco-archive@lists.ietf.org; Tue, 05 Jun 2007 12:00:16 -0400 Received: from [151.63.34.52] (helo=[151.63.67.203]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HvbS5-0005q2-27 for megaco-archive@lists.ietf.org; Tue, 05 Jun 2007 12:00:16 -0400 Received: from big-217140d2117 by allaroundthehome.com with ASMTP id 10DBF4BC for ; Tue, 5 Jun 2007 18:00:07 +0200 Received: from big-217140d2117 ([199.173.96.29]) by allaroundthehome.com with ESMTP id 4C70689EF0BA for ; Tue, 5 Jun 2007 18:00:06 +0200 Message-ID: <000801c7a78a$94ac6540$cb433f97@big217140d2117> From: "eula awesome" To: megaco-archive@lists.ietf.org Subject: Date: Tue, 5 Jun 2007 18:00:04 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0004_01C7A79B.58353540" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.4 (+++) X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e ------=_NextPart_000_0004_01C7A79B.58353540 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0005_01C7A79B.58353540" ------=_NextPart_001_0005_01C7A79B.58353540 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Messages thanks mobile service. Labs adobe acrobat pdf open contains ud. = Tags associate tag next popular enter. Messaging improved protection, junk. Home usa message, activation ie vista, outlook politic. Located main reason upgraded belcher, update voice let something. Youd = got camera, recently, guide joseph albanese? Latest enjoy once youve? Much ms known know some disagree ol years farthing? Where say screen pops? Gifts day price teens occasion see guides. Trend, micro antivirus plus = modest nowhere. Others instant minimizes, takes locate redesigned = interface. Added colorcode blogs directly reading saving viewing may interested. = Compliance managed, folders offers approach document retention archiving = regulatory. Frontpage, baltimore smtp viruses stop writing trust, purports contain. = Check boxes selected below, eligible upgrade dvd premium full. Cannot = viewed, otherwise acted upon requires. Caveat emptor february, pallen tap. Is required by debian etch gnusamba beryl? Listgift ecardsyour media exclusive amazon with your stuffbuy corporate. = Policyneed helpforgot hereredeem musicmusic carepet scientific = directory. Ecardsyour media exclusive, amazon with. Redesigned interface = makes composing, formatting acting email an. Sets fathers beauty battery dewalt xrp volt valued. Probably productive = less bug ridden, stick what, cant. June searches contact management operating system exchange cdromitem? = Hereredeem musicmusic carepet scientific directory canada. Who bought = step joan, preppernau dummies bill dyszel. ------=_NextPart_001_0005_01C7A79B.58353540 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Messages thanks mobile service. Labs = adobe acrobat=20 pdf open contains ud. Tags associate tag next popular = enter.

Messaging improved protection, = junk.

Home usa message, activation ie vista, = outlook politic.

Located main reason upgraded belcher, = update voice=20 let something. Youd got camera, recently, guide joseph = albanese?

Latest enjoy once youve?

Much ms known know some disagree ol = years farthing?

Where say screen pops?

Gifts day price teens occasion see = guides. Trend,=20 micro antivirus plus modest nowhere. Others instant minimizes, takes = locate=20 redesigned interface.

Added colorcode blogs directly reading = saving=20 viewing may interested. Compliance managed, folders offers approach = document=20 retention archiving regulatory.

Frontpage, baltimore smtp viruses stop = writing=20 trust, purports contain. Check boxes selected below, eligible upgrade = dvd=20 premium full. Cannot viewed, otherwise acted upon requires.

Caveat emptor february, pallen = tap.

Is required by debian etch gnusamba = beryl?

Listgift ecardsyour media exclusive = amazon with=20 your stuffbuy corporate. Policyneed helpforgot hereredeem musicmusic = carepet=20 scientific directory. Ecardsyour media exclusive, amazon with. = Redesigned=20 interface makes composing, formatting acting email an.

Sets fathers beauty battery dewalt xrp = volt valued.=20 Probably productive less bug ridden, stick what, cant.

June searches contact management = operating system=20 exchange cdromitem? Hereredeem musicmusic carepet scientific directory = canada.=20 Who bought step joan, preppernau dummies bill dyszel.

------=_NextPart_001_0005_01C7A79B.58353540-- ------=_NextPart_000_0004_01C7A79B.58353540 Content-Type: image/gif; name="vista.gif" Content-Transfer-Encoding: base64 Content-ID: <000301c7a78a$94ac6540$cb433f97@big217140d2117> R0lGODlh9AE8AYebAAABC34AAAZ/AotyAAUGgoYGeAB3h7TFwc3ouqjX50AWBGgVAIcoAKYVALoR Ct0iAABCABI7AEpGAFgzAHtNDKBIALYzDdY2DA5gARReADplAFpmAIxUAJplDMxgAOVcDAB2AC56 DUiCCVaDAIGEBqSGAM5+At1zDACeBRKgADaYCW6XAHSgAKyTAMmsANKuAAHEABK2DkfDAlzDDIHI Cp7DAc25AOO+AAblCiTSAD3ZA2HdAIDqDZPoAMDWANzUAAAASyEAMkYAOWcASHYOQpwHPMQOMtQA PQApPxUTREoWR2IYRYcoS5orRcwROdYaQgs7Qiw3MzM5QWU4PIhJNqU/SLgzM+s8PgBaRRlRSEFU MmxiQXdWAKpRSMpnP+dfSwB3MSh9QzZ9QFyMSX54Ppl7TrJ0NO16SQCRShukMTiqOmekRo2bNJ+l QcKUTOScOQDJOSLGM0m8Q1i4Qo3INqC5Q7e+RuPDOQDZNy3RRk3eOFXiR4fcSJnVNb/TQenYTgAA hR4BckoAi1IGe4oLjZEAcrUAhuwNhgQcfyYqg0EZg1kSiHUehqMfdL8ihtQbewtMdi5Oh0k/iVxD hoE4f585f7c/cuhIdQBlexdXdDpmeGVqfYZUgahpgcVfiN5hhACKchWBdDt/gmqCcn11eZ+OgLd4 jd9yfgCXjSasgz+sdGObeoqle6mUgc2YgteqcQm0ehK+e0vHjl+0fYXHeJuyesu1jOm/cgPlgxLb ikflfV7Vdo3de5/ffrzpdd/udAUNvSUDsjUAw24AtoYAs6oEzsQJzN8AsgASux0ktTIaw2ohw4Iu vqsVtM4ezt4tzQA/xyhEwUk3ylQ0zY5EsZZAyM5Bud42xQljuxNnx0pcwFZax3ply5xfvbdftOJk yQCMuSZyu0qGy2t6vXF9u6J1w7R1y9WIvAGgwxqdtkueuGattnGow5uTuL2VztaZzgDJzRa1uzrF y27HsYS5y5nKtf//5aucpImNgPgAAAPyAPP/BwcH//ML9QH7//rx/yH5BAD+7AUALAAAAAD0ATwB Bwj/AO0JHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePBP+JHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fJEEKHUq0qNGjSDUCXcq0qdOnUKNKnUp1ZNKrWLNq3ZqxqtevYMMG 5Uq2rNmzaNOqXcu2rdu3cOPKndtWrN27ePPq3cu3r9+/gAMLHky4sOHDKukqXsy4seOhiCNLnizy sWW5lDNr3pz4sufPoEOLHk26tOnTqFOrXs36LefXsGP/bU27tu3buHPr3i1Qtu/fwIMLH06cJe/j yJMrX868Ocji0O06n069uvXe0bMXvs69u3fXT69q/x9Pvjze7+ibm+d89F/69/C/Q7VX0/T6+/gl t69IM/7q/ADGRlF/9gVo4IF3YTffRPUViOCDEDYo0VQDznRahBgGqGBM/EVVoUxzIebfiB9JGJFU HYIYV4YsCpgUgROiyKCFK9JI4o0NwWiUjid6qFyLQAJ1EY9FEekQhT8GqWRKLxoplJMMtYQQlLgt KZh4NraXZZFUetTlbV/iqKV7M25JVJgcobmRmqxZaeZzN33IIVImcqkinW+SdVKTeYqJEgCA/gMo AIIOaiibIfUJ551jztmoozsqWqKkSZ5EqEiXCorpSJmS1Gmhg9qUIqR2MmoneKaeieiQlKrmKaew av+q0qeyympooCWFSiupD63Kaqq7+WqRsHLyqlhJBAEwkLL2MNusQMqaROinmVYb67W4FopptrVu u6uUZQL7ZKujWgVXnaqKO25kBeWq6bSchmqQss5Cu2xv31J7bbf8vksrtdaSexCx4Rqbo8BcEVzw S3zmVRC9zzrLbLTudntoZRM/nFCnHPMb8L6bxgvqobdOyy1MxTLcMMoLq4yqwevCjFFYuHL76cOD JmsvvqG+Gu+l9Qb9rM4hbwpwrECHHLDJTPfsqdMyL6Rwj+pGifBWU0OErkHhteuzxV+DrbRVGets drNhJx3vzvbWGzG0FYNcq9pFI/1zzySfzHKMVU//2ndCWZe696N7kiXxsrfSt+/HH8ddtNCIA2q2 vmJPq/Hk9zruMbawWgs01Ld6q7fLVP+d5tUDba2W6rbl3Kzkrr8udt2N1440zpLfG7HmFxc69O9s s914v2N/Tffn1Qba9Ojgttx8pKhvOLhbX3atVcnzxr6h7cXTjq3b4Asve90eG6r74fP+affj37M/ 8tO9M28c36YfvFTKLmG2knPmQ5t7zjmbm/HCtrmKoU93CLzU63Lnv8vN63zLWp8E3cc5WyUPaiJy npDw9zwxnSVxCwyhvQjYsX/xjmw7cxvwVOg/BvYvhQgp27cKWEHiBYeD99Pg/jy4lthh72LwklvH /2xosRg+UFYwPMgLWTi0sinOVnJDULmagsP5Aa4qJIIdCJNFMtpxT1pgrJz6kPi67P3vgb+boZuQ pcOfVJFM6bJU6HrnuxFNLHEvXKClwijAAs6QcnQ7n/YGhpNeAWiKTJHaV2rGyFwBzGZ442ELuSgx Cn6RhuSDIhEr00YmdTI7bwycIqXFsc/Bj5So1BYGrRifJboQjyAzoc/oxpNQepJ+93mjVrQlR/gd zZHbCmYvSVmy94nMO7Ni4CRx18dNIgmXpNPaIdmiTC5a85dPE1ky/2RKYWrTkUAM3XJoIrFXTikw tizcJ10Ux6fFMGh5rGYZI7jNYWYLkidjZPK8yf9PcDIxN8RCZzpNMtDxbCybvEwoPLOHRkpu0X/e xGcpEcrLfKpRV8jD4EORI6wrrZOgH3XKVv5XTsQh7pso3dY7N6Y9ZWpRcfJr5N1SIlOZKjSjAMTe PJPTUYFCM5qGrOVIfZhTLZa0gSSF6DDl6FJ4EjVyd3TdTLkpzJr+0qrBVB5Ji3pUnvYUMAUdy0/N BRmUUMSo5kvrRk36Tkh+M6lsLWM1X6rE0FW0m9rUm0Wz2s17Mi1yLVxo9EI0WI+OlZVco+I5B1uR uXbVpjdNaGCZKM8tOpavIvMrRfM60YgCDHeUld8OSxNQsOJQcGw87Ggl0lS0inCn5pxnZFMJR7r/ 7rSBC3xlS3HG251WFbKrFO1DLUvHqFnmq7NZC3KnNxHibhW2LGRgZvfpTrmWtLKUZKtjA3vb4gq3 r9S9a8l+aNf6NWa5v/ESY4WlVsduF7om7WdCSdlbuGqXXi2FmDVZilmEYvWuVYXqe6UH1NCwbpQ6 aRN689dY1zk4nirU7R2BCWBOJhXC+VVITm87T5L+NpWanS+3BIxf1z7RuI9Z8IJSXFj25hePMMZt bD8MqrV195/WxW1cY4zUo4bYr3utcYU5qdrOkJaxM7slaUpr3suB0JX43fFju1rX3kq5mKK74FOh 21T/miwnYRXraJSMlQNfRsWIhUg54dpeKVtZ/8c65qpJzSm5u03Ur21VoYxCKmZJeq3Ji0Fzmh3C 1UHmEb7XbCpDFW3GV3JzV2GOE5/J6uc/o9gxZr4ioFk6yA4vtMdxjrCP87XKTC/WeqW79FlWSz0k n6vFfVqJhOWcRlHfd7+2JbBii+yTSMPR0hvUtKoT5uqXMTeoT9Epd/tnX/sSOdW75rVQx3peUcZs 2IGG9XygXGJnCdqNkxZVVliNWga/etN0+Xavw/1raCeS3V6xGroR2cG6FLvV2hapr33NZIexG0vz Bji2j5VvfUtbne5+9+oKXuBrN3zhdxr4uNfro4MjXJpgrnbArS1vYNW7rBU39sMRbHCLp9bdtf9R t1lX1m5hHxvkqMa3xE8cc2QfO9rHpXjA8XRvm5fc3gzP4cIqbWpC7pznM6d3sEVu7oQLnXAr9+q8 i07so5u8kDXauE9JPnIw6TzpLG96uRXO9I/bb8V+A7uDZv5sA/fc52SX+csdHnWomx2gFkLy28+u dqcvHeiUTvu6kT73Ku3Z70a2+6DpHneBg7vjNYd538cccoxXLfGWL7zgce51tENv8qJ5JuJ7onRy S/7nnDeL6Me+eN0cPvM/h/vdF5UZ/Xme9aZ3PUi5LnbYN/5IHCf5qvfO+L/jHvMQtz3bXy/71iuY +JtPffGdr16rf17zLo898K3f/N0rPvcQj/z/6Xs/fvKHf/m3R3Y7H3/9rg+/8us3//SRzxaVT5sr sWN+/GffkZZ3f/Dt536nw337R30KkVxK1BAvljurV4Dgx3vyB4HG54D0V34GqHpBFxV6dTYOVGKv 9YFoMxNqVIG0h34mKH7wxn/9B33Rp4JGAT6bxTlp1FAphGPZo38W+IAH+HXax3c9WILYVxZ30TQ0 KD4h2C+UAzwLEWW4VlkNmIMkCHkCaHTp54O/B4VkRnhTUUo240+cgkBgOEIwYTkHdEAR41RSeIXz l4Xbl3Q4mIZq2IIX6BZBs0cE1ExRZINmlDaLgzHBI4fsF4AuSIUnKH1W+HSCOIdDET5FGGFC/zRG Y3gvZxQ8zGJBEVh9VQiEU5hYU/eGEhiIx5dgdaWHSliKZviHqTOCfFQzeKhAkPOJUahrbfd/pBd2 g8iJbgh/bYiCj9FpGUaJK2SGRfVAQWRBe0U5sZh9hgiLABiKdTd6z0iLtXh1kvYZaHWN3UaKbfM2 wFhXmnN/vlcejreJwEaOiaKLh5hBbZFWCbRSDrSDmciM0TGOl6iM9XhqPwiH6kgUaMhhTPiOmJiP 8ggdtniL5XiPhKhvcWiPE1gUnYaB6KiPBlWQOsiQFWmRihhu/BZ8Z8aGqZOB5EGRyYiRHmk1OciF VHeQC8kdKXmO+CGSI5mQCPkRLkRPkChkLf/5kfGITCCpHfRokIlyPe0IhjW5M1nmLTiZk7KIiO/R b7mkhQzmFYzDgTP4h+hzihpVarMSkzLJlJQXhPhojjr5ki8ilOITSxU0lKeohGspi6BzhzOpkl75 GUpJcxf3K/mhXBujlk82lDA1SyDDls3FjTUJZMRUjdAIjqHHggG5HieZloJphFDllzYZRd7HjWG4 jd3YRMElZFoZly4pkHKnmPWXXppYQ0OEmuYSYZkZXTYITt+Ima/oRB04OfGjTxlHjYgJeLyIFuL4 aD9zQhSUScMjKHupZq+Yiq2ILQkIQZG5QqCVmkgpWgRUes3Im8vom564S4eJlN9oO390SvL/JJsJ KIxEeULW4mRUaZ4duDyPBJdAOZaiCZE7SZ8JchWgo1V5Q1EXBUbDQyiT6VDvGD6HY0B3WJ61KZlv M2HB6Uw9eZ2lWZ+V9hB5Q53uUozSaZk3k5yb6ZyoaELICKClqJl+SZty2ZBdKYo5J6EDiKKeAZve WV75YofE+SrqmZndZZVD0z3e+YVGqI3SyC5r15sk2SAc6ZAKOF/+4kvfKZwZamEBKokCylD0VJUj Wma+cSERWXWgF6Fpk081REO0VEK1hYrkKZlAqlxZOqRiiRFElaZFepdyQYpZqVdqk6GZYqZSiqY4 mhqm6R+H05bLBIJwKp9t2hGFSmjI06OY/+Q5AsSn1/GnozmNCLqZgRqGzGZU2QVvp4FlDeqZYXpy 8CGpzggjNNWKlfqcTsSaoBUR2nik+Gl0TqOKBBgsa5qY4paq3bZH/+mhrEqZDPGmRRikl3mi/ocV OPaE6HGrjHc8vqQzWClBstSnS7igRBlVZrRfKViriZqOoBiOF4lp4thQwhhG/+lDrbk9LqNftcmu s5lE0PpcHEasuakn5/FvbDqXXTFGGOopCcqWqxhGb6ZppeY5VlqV48medwRYhNqtyrqUxyqR96qb EfuitYqPdvWZUNSr/6o7NEpm2NVER5iaHTOg8KqgjOhSuAOCRpSiE0ux2wmPXZoW+hpUGf8bZAPU ObMYjB54oYBpNESJqSTUTB6qqlRppRslrBu5pTLrF/tWdlg3cdM5R/uZSVHnriSWW49ELetppRM0 rXtaokELMVc5ns+Jq2CxtCyKizOLpYFXF8Ula+/Co2REWUdUo/tysq75RMVoSUYUXQebrpOkbPtq WjAbs2EJmmsYnxOHN941tx8bMoL7h5qEKccpstCaLOTTmcb5oWxZhkfLjlqbjQ67deDqb9R4mmvL EWmqL/jER2iJQtDZsrmlMU61t9r1iPoCrMlZlIRJiTD2kGgbb2o7n26LgKiCkr50SUhEm0IDOYBL oIL7vMMJNmdjt0aLtO1laGYrsfd5uMb/i0ubyrIQ+72xanNxeygderbEaLutuVtnGrT8GjcAibS+ er0iNIxrtYt9UbyMOyOO6j1korRQZViNdSaOK53ouo3Sq6NqGbi9u1WMSHPO+jjqSqPOy7uZ+o/C 673SwWdCyZ4C9J+WG0IvZqh8MacWlVFkNcHai6lde7JXym2a20ey1Id+i7BBC1hXWbjI662KibU4 KsQeW8HVeWg7SKtfYRY4VqdTK6LsyYGCir09HKVIPD6zwzjuE15QvGPUWqpYBIhG0zlJC8H3C5DF ySQn/FpKHBb2eaojwzygC6zTy7c/epzKtmYUszQ6W7mW1GfY+a2CZ8R+3K/Lq6AO7KqQ/0uy/pKt DGuXe/GTLDGrMoor9VuGsPsnlvq+vpsx0RKelgmWXPq/FjHHbCOtTYq3sqtmwdiOlcjI/SKJ8mo+ BgzGNPW6opO5JSrAeOi5MOS8kxg8iLsanrzDYns2oUo8Fgo/aHSpm8xhwzmmyyRVojMYcGidt6yf +Rkozww8qkxdE8yh29q2iVuvDoWteGzGHUu5oUxVPjvG7vGuk4u5esbL0QybGCXHtQdvCVxjTuPL sxuiYQOTlHoZT+ZeHcuusJVdgwS5SOO4WUy/DWyK61vPN7w074nDH1zOGRmaY/i6s+qHfVovsMrR O9Gp2Di6gathmFnRW+s4ritE60vR4f9cxK8SRPd0UzMaxjC7kXQ0PPxG0NlJh927l707sPN8w0ho z9/U0vabqkbo0LuCTfmssSsZp8XKvzeZq8P7to1ZswYtrzd2uTBssg/D1Dkb03ezsvhLoqzpbRGd h8qTZV82zGwrgCxk18bKlRNYl+d7Vjf2q2WNspyoZe9Mt/wUMPGLL7USZ2XdPuzDwna2PHrt0Yda 2ZbNtBSLGv0YpbOrlnz4pDetmsU5ppWbhNmbPmJKnFQbt5pt0ly51wXdtCo6yof616zliw/GoRPM q6QtRG8p1TANx1zbnNdbQdUSEhX6xEo61LBdkh7M1cdR0sZ9FPA7WYX51GhDwsiNh7P/45kaNb8W DNDk2s3h1M/LPNv0CshaLRZaerFEvWaTiZXHHVHD7a8yTGpANkR8nCtm/dRVXGsXZMM83dU7+9yx xphvfNsjhZzg81wqW9Fxky8tW8XVfOFbqZrwuqqm3MmQHMnjLN0+LMqMQd34V7ZXLM/Cs9WatOFm ut85XVVbrLOYe8z+69yqW7FfTcpZRyokfuKzJt/DWqBL7UkZLD773d20NNxC/bDDot6LG41ut7po scY13tJEbtrsc8kQNKas2M7huiZgfeO7acvsDRqYnRXjpdLaZd4XnLN1VNOZk+bYLEVQyePnRuVm udsmPFflTU8CDSt1ftJRjiGSHOYl//7aVd5abGzMGlOXdE6BPnnnHU1wFVgfCl7d8fTFQAzdtD0Z ZK4ZTZ7V2SannU6aHtGtePnjmS2qSgGhp06Qo37m53fZdq3q3Gk6wDHoxZGIiiu1uajn6VbpSWa4 Br7rIc7qwK7sH+6iPFTL6y0cvG7Ogfy/Tr7stS2Exn7sDXntWJ3tXlqIV62dnv5+PxztZd7ezv7p Y77g1h7pTw7rtQ7i4NuJOM7u6+7uxF6+L/vtUQu1qMvtPMjg9U7OO/7uehHq+z7rxFvwzG7isk3o eY598t7qiB7x4B7uKazwsW3xF7/q4Ys19M7tHF/u+h7wpyvI0U3qOa7y2P7v/k7rA//J8jOf8fDI 8AWe8hWP7x8P8uPu8DJf7OJOyqZr5g1PNcc+7UG/goou5guPr1Av8D5i7/Bu9F4d6zQvxubL8x0v 9A//oPrh8Uvc41+f6Xd971Hv613P7ybvsmv064e+9mxv6vNO9y3f9q8O9nbP9W//9JTe880O+KVn 1YKf9lav4zF/4Fjf91lv7mUv5T7/ODjlnm2M9yPO7E/bMoXO+I2v7YoCFYG+yF7kXZQM8WIP+fLR eBpC9lUBypms0SS7qJVc+XvP9AbfeXCPwuN68jzRWX5sQ2r9s3+8ueUVx3UN3zW/9BNa8mHPGA+O 4Va7ObIEy97t3Rhd1dqc3pbv9QT/v/wILuvfjxPFfeUjKv3mCuelDcdpjcrTafy+j/yJr/g6f/Wp z/mwm8bA777q+T0hbaD+DxD/APwjWHBgQYIHDSIEMPDgQ4QCDTacSDEhRYURNWq019HjR5AhRY4E udFkRJIp7Z1k+U/lS5gxZc6kWTNkS5w5de5EadNnw4YdEzJcuDGjxKMSJXoEwPRjU3tQhQoEqhGo QoxFsQ5VWpSr1a1fu2J1aJEow6Q7ffrkiXBt24Jr5c6lW/cmXLw47f68KvVqSLNjz3YVrNVt1I5S nSJOHJWs2atirZrMCDGi5cKXJ18sG/ly2px7Y+Zli1f0adSpP+Zl3VY1yL9PgcLG/1xZrMOTSR8u 9tuYMWXghjVnTosbrVfbn6tCtliV9euRpG0+h17duszW2Vlef8q0b+LvgZMP1b256EjF3aMqLU8e qVHC7zNLDjt+rGeqD5mDdsn9JfWapPNvwNO0M9C1Ab/z7q/ZBvNKvtuCcwmq9BhDrCnjhrMvrAfj o+pBzL6y7z799kuIO4LeMm26FQl0saQDY5SxJwJnW9BGx+IDjSzJ7juxQseC4m0+HTM0Lrn22IOP q/Eq6yywigZSEa7SqKwSwRfpmpGmGbtMMUHaKrRxvqM4dLA+C9NTMzHDkDQvQw17DJHDMrWKzLnl LLqSpz35ZNHKLIUqsKW+gITJy/8ua5RNSPXWM484M3U80TcM1YNqMDiJilRJ5DpMck7kxFPusAAF 5LLFU1HVElGjSszPyf0M/Y/VGMEMEzwMhSTzURHd7M83YEUiklMROxQItiU3HM5BtPBzVlaVTJ0J wFSxzJLRoC4CayLOXsWPM2ijpdVAFylUcFGI3Ix0xMsa5W2lXqHkdlI11xTKtjolBBXcUZ9ktFo/ /7R22nF/BczQf8HzbkFt5dX2VW9L1FPggqm1LigczUWWPpbY3ZfYZJ0jyl3FKnV3KknjLPbh+gYm GFCA1RK2YocdO1hhkTBGWKoPG+axub5Co7hiVS+ud+dld2Wy46WPO9PSk6G2cMj/poVjltU+dcqa 6J63/ezhw2LL2S+yb7bZZ1q35lpr/452G14iW95M2SivvjFYSt/NubEe19ZraJlhLNjhruclXORW z9V5YZsbf7litf1uqVxsyRZS1CYx1Ty4EJnMGL3PY5Zc6FJJ3avjn+UFmjLCwY71MT0Xh27tKUdn 26OAaWLw8spFzhzEpJvetOmpZ7c9d9y5DhpP/Zzu+duvXUf826Bvv87vyI8/cC4bZysU5SQLW1dO mK/XPtAbn2x29cLnzc/9uuNPG/3Riq5fe6xRVgvHu3FdeVf+JMo/+GtLoc6lOwPCqjOGa97zWkfA L9FPXPY7FAQt+CveWa5BFzzJ/4A4sqWaJFCEYtNdxPhVKLBx0GISjA4FZ6XC84WrhTA0HQuTVz6Z jHCEfHkgDRFlwwkOzIdDrCF2iBhB/R1xIzzU4feyp0QBAnGGUKRi4ERHu9MpcS3QmxzgsPdCyElx ilUkYxdL1xrUlBF5RsTh/Yj2xBWKkSRqpGMHKQa37XmxjjS6Iun66KXarTFQdtTjHqtYkkG10Y2G 5Agcl1hIQEKSkChyYRAZeclJPs5li8RkXCRpkkCOy5GPpKQiwdjJWiWykimRFhtR6clPkvKPVlRN K423yjm+UpaiweIZBclJVI6Sj5r8ZS1xqcpiWhKKvDQYMecXy0b68pVJRGNqbP/5mjhi85hjfKM1 t3kXrgmziMDUpSm9ac5zbvKW6jyllWQkl2tWsJvSpKUr65hLdKbxm3WJpzHzOUNqaodA/WRlL2eZ SXv+U3DsVKb1zKfQLEKUn9IRYDb9ydCChhOaw3SmHzv6t42OU5v7XJVEJxrQ7ITSodWxaEPzF1JY HpSj9PRoQlfKUpLOpaWDzClKQVpKjOJznjLdpRx9akaiFnWdyUynn5BIP4IKNajMNCkeNUrTmspx p1Kt51KZOqijVnWiPbVqV70aTK4K1KgL/So3b3rWrNo0pWudmVjLataLlvOqdL1rXOU51YhS6ak6 HSxfkzpTcv7UOnodnWH76lf/lyp2sfqspmNhWti/tpWqjB0qXaPq1re66HiWFWdMPypZuHLwsao1 7FZBi1rCHpK0WIVtO0ObV1F60bbP5OtnhRVW5HF2trTdzmWbudi9PjSMrSUrTvU63MOK9KXKXS51 C+bY3A6QsS8CbF2HONDkIrezzg1sZa2LVqB2l60+9KBBxTvezJJrvbx9LxXX6ltwKnU14XVudeub 3VSW1L//pSF2m1ta8553ugr+YpYazGDWMteuCE5wfwc8UugiM7tAPa1pgQtKA0+Ywvi1i3sdjNgM e/fCKc6vek98YOJGEcIgXK3LXJviB7M4rZAFIonHumLcaja+KuWxjmtMYyO//xapnoVxjN9ZytQu Wa61TfKRkVzl+RaZhT6OLXwTK18n63e3WmaxibH8YTFLkctdfiYMR0zhM6t4w3FGc5pteOMSuzi+ koOzcemc5QXTec2ibfKXbblMP/f5z3UGM3m1K+JH67m3RyQylTNq6TjneMpStjBe1VxolLaX0okm 2KIFfF3jHjfKxTX1plk9YwuOeNCttnKAwxxNWCO0qWotr6d37WZZQ3rRmja0rldt7PSKNMi3pSwR gy3sP5t5z8zWMLWLLWl4gtrV+Js2n2md6kHPGtzKJvZIsV3pSI4byN+ObLqj62FR4/rdFe60tXs9 521DkN23bvS886jkV3dYxv8EJvO9A31tAu7b33hWNlTJWu5lF/zH6770dxWe7wg7/OH8PTaII41q fo/24ghH8R8tG25pR5zTHbf1wjk+ckAzVNwf93XF8V1viZ8a5C5/eYYHnmdoExzTAH9yvIUMdIrv WIUSpi/Ohy5BlGvb3OdWN7YRjeWZLzzEds16ru1c7aaT/HzcDTjG5S30lYsx6lR3es3B/sNna9Hm 9m7x0XVOd/TNuutm/7fXW873UYe84XPP+d0LT3a8E93jyQ47y/sucCQ+vu5ul3Pibxh0sQ8e5owu ebOTvtnP7/fmmYd3t9M+5tMjHc9JZnvb3Y12XtfadooWPGZRX3bAzzWzJ5f/+tRH7/vUk/73t0d2 u3Fv+uArPuGe17zyvw71lAuY8cCuvaqRf/wx/5r6/kY39j/t5Zj3XvTOTjXtmVz0yh+e86Un/uLP /3M2ux/2+jZ/7m3//XOv3e7j3z+hKW983fO7sau+7iu+O9O//ws/7yO8p0O8aTK6Ais/Ups0rkNA y1s/9su2DLS/CKS5dFs9/qO8v9MqC1Q/vVslzpo9D7xA2es8pcs4MAKvCpywEjStfnvBFDRA5mPB E3yuFWzAyTNBFLyyt8vBBSzCI8RBHXQ+NYLABAxBHgy4ntM+I1xCgxPCGSwnGbS6foI/Jmy+K6zC 5wO9J7w8LvTB6QPCmFNA//XjwC0Uw+QLwzgMQjU0wwf8wTmcuCSUwz1Uvfy5ujTMQyhsQ+HCQxck QxYsQPlzvLPjJOGjtzOrwUvaQfADQCv0w0SsP9cjwkzbODRsv+UjQEPsQz3MRMC5vkWMREmEw8Dj PidsQ00kQUWqQwfsvxacwkdkr1hUOVIsRVgcRfR7P1u8RVa8oF3kxUtMv9czKojrsRpEwmLMwtaD vDFUxmVkRlzcMhfiRAaMRkhExWr0RSwMPY2rxAOkRf/zxmC0Rsx7RFAcvnM0R+syvGQUR3UExPnb I96TR2KiR25Exnu0OGhENnzERv5qRJ6DR0oMSCtqxm7sRTvsQArcvlyMvv+FVMe4s8UeFMiJ3ECY ykiFRESGBElC9ETy27xBREdi9DZgjKkBfMdDZEcvhEkwpEMY1ECRm0Bq5DamI0c2DMeflLxcJMmD C8p6XMn7e8ijxECW7MiQ/EKPhMpvpMmolEl8i71NTEWqrEqbNEacHEefTElBjMjG20rrA8d2NEhp LEOmdEgl1EqzXEWIbMvmkkus7MS1TES5k0p0PEulhEtLBEqyLEqz7Ep+LLO6NEmGTMqLnEukVMQR REsQbMtWm0ymJMrDc0uRVEm7/LuZpMKxnK3OFEy6zMuyBM3QfMyqOy4VDETH7Mn8U8yd28kbzErS REq/rLiBXEdGjMm8s8g1t7xN3JTNp8TEkiyfaHxDtkzHnUvLv4xMybxL20TIUzLMe3xFlTROOvpK iuRAy4RM6uyIgAAAOw== ------=_NextPart_000_0004_01C7A79B.58353540-- From megaco-bounces@ietf.org Tue Jun 05 14:23:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvdhB-0004bG-Us; Tue, 05 Jun 2007 14:23:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvdhA-0004bB-UG for megaco@ietf.org; Tue, 05 Jun 2007 14:23:52 -0400 Received: from wa-out-1112.google.com ([209.85.146.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvdhA-0004ZT-6j for megaco@ietf.org; Tue, 05 Jun 2007 14:23:52 -0400 Received: by wa-out-1112.google.com with SMTP id j5so1049550wah for ; Tue, 05 Jun 2007 11:23:51 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=T0s77CrSY+ZXIhcmfCxD2fZduVV5a4+SEdbVZHjx82eaKZItjCxPU49xF5lwAPrKbDaszjxrRRn4rLIHIgZUGiAjuGE8bhlkO7U1Y9M0mAsNxpE7+6zZJmUhWaDZVOOc8cvOYzRA/OokACSr2s9jIuCXXoEXpfeLavXhnZIr3Gw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Vnk3CUmHENgoXrx/Fn8QX3H96vBYmFqmi25myLwM9prnkzBeLFhjksDjb7vJAZMBsXpXVxQvKJjOjUjz1+ZxfXaGqS/RPY+qoolEdRGh4Pk11V3wKgeYWLMJO5awNt8radqYBDL4jw/otDBML63DFxqExlP/LeIUaCuuiNktNb4= Received: by 10.115.106.7 with SMTP id i7mr6257245wam.1181067828529; Tue, 05 Jun 2007 11:23:48 -0700 (PDT) Received: by 10.114.171.11 with HTTP; Tue, 5 Jun 2007 11:23:48 -0700 (PDT) Message-ID: <2ef41d6d0706051123v1d949426x3fc0b41735cdd220@mail.gmail.com> Date: Tue, 5 Jun 2007 11:23:48 -0700 From: "Jisu Bhattacharya" To: "Arvind Charanyan" Subject: Re: [Megaco] Reg contextAttrDescriptor Structure Difference between TEXT and ASN Modes In-Reply-To: <22F058C3ED9D784E90CE473F2A9847F00169236F@in-exchange> MIME-Version: 1.0 References: <22F058C3ED9D784E90CE473F2A9847F00169236F@in-exchange> X-Spam-Score: 0.5 (/) X-Scan-Signature: 231d7929942febf3be8fd5be2903302f Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0467761381==" Errors-To: megaco-bounces@ietf.org --===============0467761381== Content-Type: multipart/alternative; boundary="----=_Part_29023_10655211.1181067828488" ------=_Part_29023_10655211.1181067828488 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Arvind, COMMA(,) is the separator between the two. The ContextIdList begins with ContextListToken (CLT or "ContextList"), so it will be easy to distinguish it from propertyParm. Thanks, Jisu On 6/4/07, Arvind Charanyan wrote: > > Hi, > > > > In the case you have mentioned below, if we can have *"**0 to one > contextIdList AND 0 to infinite number of propertyParm (covered by the > *(COMMA propertyParm))", *then what would be the SEPARATOR between the tw= o > when both are present. > > > > Looking forward to some inputs in this regard. > > > > Thanks and Regards, > > Arvind > ------------------------------ > > *From:* Jisu Bhattacharya [mailto:jisu72@gmail.com] > *Sent:* Wednesday, May 30, 2007 11:46 PM > *To:* Arvind Charanyan > *Cc:* megaco@ietf.org > *Subject:* Re: [Megaco] Reg contextAttrDescriptor Structure Difference > between TEXT and ASN Modes > > > > Arvind, > > *contextIdList / propertyParm *(COMMA propertyParm) > * > does not mean a choice between contextIdList and propertyParm. It means > that you can have 0 to one contextIdList AND 0 to infinite number of > propertyParm (covered by the *(COMMA propertyParm)). However, it requires= at > least one contextIdList or propertParm to be present. > > Hope this helps. > > Thanks, > Jisu > > On 5/30/07, *Arvind Charanyan* wrote: > > Hi, > > > > I have a doubt regarding the implementation of the contextAttrDescriptor > in TEXT Mode. > > > > The ABNF definition for contextAttrDescriptor is as follows =96 > > > > *contextAttrDescriptor =3D ContextAttrToken LBRKT (contextIdList / > propertyParm *(COMMA propertyParm)) RBRKT* > > > > which means it is a choice between contextIDList and propertyparm. > > > > But according to ASN Grammar, the ContextRequest is defined as follows = =96 > > > > *ContextRequest ::=3D SEQUENCE* > > *{* > > * priority > INTEGER(0..15) OPTIONAL,* > > * emergency BOOLEAN > OPTIONAL,* > > * *topologyReq > SEQUENCE OF TopologyRequest OPTIONAL, > > * =85,* > > * iepscallind > BOOLEAN OPTIONAL,* > > * contextProp SEQUENC= E > OF PropertyParm OPTIONAL,* > > * contextList > SEQUENCE OF ContextID OPTIONAL* > > *}* > > > > In this PropertyParm and ContextIDList are part of the sequence. > > > > Can you please help me out by clarifying this ambiguity between ABNF and > ASN Grammar? > > > > Thanks, > > Arvind > > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > > > ------=_Part_29023_10655211.1181067828488 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Arvind,

COMMA(,) is the separator between the two. The ContextIdList= begins with ContextListToken (CLT or "ContextList"), so it will = be easy to distinguish it from propertyParm.

Thanks,
Jisu

On 6/4/07, A= rvind Charanyan <arvind= .charanyan@ccpu.com> wrote:

Hi,

In the case you have mentioned bel= ow, if we can have "0 to one contextIdList AND 0 to infinite n= umber of propertyParm (covered by the *(COMMA propertyParm))", then what would be the SEPARATOR between the two when both are present.

Looking forward to some inputs in = this regard.

Thanks and Regards,<= font color=3D"navy">

Arvind

From: Ji= su Bhattacharya [mailto:jisu72@gmail.com]
Sent: Wednesday, May 30, 2= 007 11:46 PM
To: Arvind Charanyan
Cc: megaco@ietf.org
Subject: Re: [Megaco] Reg contextAttrDescriptor Structure Difference between TEXT and ASN Modes

Arvind,

contextIdList / propertyP= arm *(COMMA propertyParm)

does not mean a choice between contextIdList and propertyParm. It means tha= t you can have 0 to one contextIdList AND 0 to infinite number of propertyPar= m (covered by the *(COMMA propertyParm)). However, it requires at least one contextIdList or propertParm to be present.

Hope this helps.

Thanks,
Jisu

On 5/30/07, Arvind Charanyan <arvin= d.charanyan@ccpu.com > wrote:

Hi,

I have a doubt regarding the implementation of the contextAttrDescriptor in T= EXT Mode.

The ABNF definition for contextAttrDescriptor is as follows =96 <= /p>

contextAttrDescriptor =3D ContextAtt= rToken LBRKT (contextIdList / propertyParm *(COMMA propertyParm)) RBRKT

which means it is a choice between contextIDList and propertyparm.<= /p>

But according to ASN Grammar, the ContextRequest is defined as follows =96

ContextRequest   &nb= sp;            =       ::=3D SEQUENCE

{

      = ;       priority           &= nbsp;           &nbs= p;            &= nbsp;            INTEGER(0..15) OPTIONAL,

      = ;       emergency           =             &nb= sp;            =        BOOLEAN OPTIONAL,

      = ;       topologyReq       &nbs= p;            &= nbsp;                    SEQUENCE OF TopologyRequest OPTIONAL,

        &n= bsp;    =85,

        &n= bsp;    iepscallind          &nbs= p;            &= nbsp;           &nbs= p;       BOOLEAN OPTIONAL,

        &n= bsp;    contextProp          &nbs= p;            &= nbsp;           &nbs= p;     SEQUENCE OF PropertyParm OPTIONAL,

        &n= bsp;    contextList          &nbs= p;            &= nbsp;           &nbs= p;       SEQUENCE OF ContextID OPTIONAL

}

In this PropertyParm and ContextIDList are part of the sequence.=

Can you please help me out by clarifying this ambiguity between ABNF and ASN Grammar?

Thanks,

Arvind

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

------=_Part_29023_10655211.1181067828488-- --===============0467761381== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0467761381==-- From megaco-bounces@ietf.org Wed Jun 06 05:23:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvrjP-0003J8-KX; Wed, 06 Jun 2007 05:23:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvrgt-0002Ml-FI for megaco@ietf.org; Wed, 06 Jun 2007 05:20:31 -0400 Received: from msgbas1x.net.europe.agilent.com ([192.25.19.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvrfd-0006kz-8w for megaco@ietf.org; Wed, 06 Jun 2007 05:19:15 -0400 Received: from relbbn1.germany.agilent.com (relbbn1.germany.agilent.com [134.40.2.32]) by msgbas1x.net.europe.agilent.com (Postfix) with ESMTP id 231F33E9 for ; Wed, 6 Jun 2007 11:19:12 +0200 (METDST) Received: from wbbnvs01.germany.agilent.com (wbbnvs01.germany.agilent.com [134.40.35.39]) by relbbn1.germany.agilent.com (Postfix) with ESMTP id 1414C7FCC for ; Wed, 6 Jun 2007 11:19:11 +0200 (CEST) Received: from wbbnbh03.germany.agilent.com ([134.40.35.50]) by wbbnvs01.germany.agilent.com with InterScan Messaging Security Suite; Wed, 06 Jun 2007 11:19:11 +0200 Received: from wsqfmb01.britain.agilent.com ([156.141.51.43]) by wbbnbh03.germany.agilent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 11:19:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Megaco] Reg contextAttrDescriptor Structure Difference betweenTEXT and ASN Modes Date: Wed, 6 Jun 2007 10:19:10 +0100 Message-ID: <77207087078AEF438EC0B4B3A757FFC4022A2294@wsqfmb01.britain.agilent.com> In-Reply-To: <2ef41d6d0706051123v1d949426x3fc0b41735cdd220@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] Reg contextAttrDescriptor Structure Difference betweenTEXT and ASN Modes Thread-Index: Acennr3iavW+oJQ0QceB42qpqzzCjQAe31fw From: To: X-OriginalArrivalTime: 06 Jun 2007 09:19:11.0556 (UTC) FILETIME=[BE6A2840:01C7A81B] X-Spam-Score: 0.2 (/) X-Scan-Signature: c021adebe99b05433d94f84a85f41df2 X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1620778769==" Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============1620778769== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A81B.BDEFD3C4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A81B.BDEFD3C4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hmm, if the separator is COMMA where is the syntactic definition that = defines that? I think you are slightly misreading the definition of = contextAttrDescriptor. =20 A single instance of a contextAttrDescriptor can only contain either a = single contextIdLIst or a (comma separated) list of one or more = propertyParm. If any higher level construct should allow more than one = contextAttrDescriptor then that construct would define the separator at = that level between those multiple instances of contextAttrDescriptor. =20 Referring to the original question, possibly the ambiguity is to whether = the contextRequest allows multiple instances of contextAttrDescriptor. =20 The ASN suggests that syntactically a ContextRequest can contain both a = list of PropertyParm and a list of ContextID (both are optional.) =20 However, in the ABNF definition of contextRequest it is implied (if I = understand correctly) that when there is a list of contextProperty then = each possible property can only appear in the list at most once. So = contextAttrDescriptor (being a contextProperty) can only appear once in = which case it is not valid (although still syntactically correct) for a = contextRequest to contain both a contextIdList and a list of = propertyParm (as this would imply multiple instances of = contextAttrDescriptor). =20 For the two definitions to be consistent the ASN definition should also = mention that contextProp and contextList are mutually exclusive. =20 Regards...jeremy ________________________________ From: Jisu Bhattacharya [mailto:jisu72@gmail.com]=20 Sent: 05 June 2007 19:24 To: Arvind Charanyan Cc: megaco@ietf.org Subject: Re: [Megaco] Reg contextAttrDescriptor Structure Difference = betweenTEXT and ASN Modes =09 =09 Arvind, =09 COMMA(,) is the separator between the two. The ContextIdList begins = with ContextListToken (CLT or "ContextList"), so it will be easy to = distinguish it from propertyParm. =09 Thanks, Jisu =09 =09 On 6/4/07, Arvind Charanyan wrote:=20 Hi, =20 In the case you have mentioned below, if we can have "0 to one = contextIdList AND 0 to infinite number of propertyParm (covered by the = *(COMMA propertyParm))", then what would be the SEPARATOR between the = two when both are present. =20 Looking forward to some inputs in this regard. =20 Thanks and Regards, Arvind =20 =09 ________________________________ From: Jisu Bhattacharya [mailto:jisu72@gmail.com]=20 Sent: Wednesday, May 30, 2007 11:46 PM To: Arvind Charanyan Cc: megaco@ietf.org Subject: Re: [Megaco] Reg contextAttrDescriptor Structure Difference = between TEXT and ASN Modes =20 Arvind, =09 contextIdList / propertyParm *(COMMA propertyParm) =09 does not mean a choice between contextIdList and propertyParm. It = means that you can have 0 to one contextIdList AND 0 to infinite number = of propertyParm (covered by the *(COMMA propertyParm)). However, it = requires at least one contextIdList or propertParm to be present.=20 =09 Hope this helps. =09 Thanks, Jisu =09 =09 On 5/30/07, Arvind Charanyan wrote: =09 Hi, =20 I have a doubt regarding the implementation of the = contextAttrDescriptor in TEXT Mode.=20 =20 The ABNF definition for contextAttrDescriptor is as follows -=20 =20 contextAttrDescriptor =3D ContextAttrToken LBRKT (contextIdList / = propertyParm *(COMMA propertyParm)) RBRKT =20 which means it is a choice between contextIDList and propertyparm. =20 But according to ASN Grammar, the ContextRequest is defined as follows = -=20 =20 ContextRequest ::=3D SEQUENCE { priority = INTEGER(0..15) OPTIONAL, emergency = BOOLEAN OPTIONAL, topologyReq = SEQUENCE OF TopologyRequest OPTIONAL, ..., iepscallind = BOOLEAN OPTIONAL, contextProp = SEQUENCE OF PropertyParm OPTIONAL, contextList = SEQUENCE OF ContextID OPTIONAL } =20 In this PropertyParm and ContextIDList are part of the sequence. =20 Can you please help me out by clarifying this ambiguity between ABNF = and ASN Grammar? =20 Thanks, Arvind =20 =09 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco =20 ------_=_NextPart_001_01C7A81B.BDEFD3C4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hmm, if the=20 separator is COMMA where is the syntactic definition that defines that? = I think=20 you are slightly misreading the definition of=20 contextAttrDescriptor.

A single instance of a contextAttrDescriptor = can only=20 contain either a single contextIdLIst or a (comma = separated) list of=20 one or more propertyParm. If any higher level construct should allow = more than=20 one contextAttrDescriptor then that construct would define the separator = at that=20 level between those multiple instances of=20 contextAttrDescriptor.

Referring to the=20 original question, possibly the ambiguity is to whether the=20 contextRequest allows multiple instances of=20 contextAttrDescriptor.

The ASN suggests that syntactically a = ContextRequest=20 can contain both a list of PropertyParm and a list of = ContextID (both are=20 optional.)

However, in the ABNF definition of = contextRequest it is=20 implied (if I understand correctly) that when there is a list of = contextProperty=20 then each possible property can only appear in the list at most = once. So=20 contextAttrDescriptor (being a contextProperty) can only appear once in = which=20 case it is not valid (although still syntactically correct) for a=20 contextRequest to contain both a contextIdList and a list of = propertyParm (as=20 this would imply multiple instances of=20 contextAttrDescriptor).

For the two definitions to be consistent the = ASN=20 definition should also mention that contextProp and contextList are = mutually=20 exclusive.

Regards...jeremy

From: Jisu Bhattacharya=20 [mailto:jisu72@gmail.com]
Sent: 05 June 2007 = 19:24
To:=20 Arvind Charanyan
Cc: megaco@ietf.org
Subject: Re: = [Megaco]=20 Reg contextAttrDescriptor Structure Difference betweenTEXT and ASN=20 Modes

Arvind,

COMMA(,) is the separator between the two. = The=20 ContextIdList begins with ContextListToken (CLT or "ContextList"), so = it will=20 be easy to distinguish it from = propertyParm.

Thanks,
Jisu

On 6/4/07, Arvind=20 Charanyan <arvind.charanyan@ccpu.com&g= t;=20 wrote:

Hi,

In the = case you=20 have mentioned below, if we can have "0 = to one=20 contextIdList AND 0 to infinite number of propertyParm (covered by = the=20 *(COMMA propertyParm))", then=20 what would be the SEPARATOR between the two when both are=20 present.

Looking = forward to=20 some inputs in this regard.

Thanks = and=20 Regards,

Arvind =20

From: Jisu=20 Bhattacharya [mailto:jisu72@gmail.com]=20
Sent: Wednesday, = May 30,=20 2007 11:46 PM
To: = Arvind=20 Charanyan
Cc: megaco@ietf.org
Subject: Re: [Megaco] Reg=20 contextAttrDescriptor Structure Difference between TEXT and ASN=20 Modes

Arvind,

contextIdList=20 / propertyParm *(COMMA propertyParm)

does not mean=20 a choice between contextIdList and propertyParm. It means that you = can have=20 0 to one contextIdList AND 0 to infinite number of propertyParm = (covered by=20 the *(COMMA propertyParm)). However, it requires at least one = contextIdList=20 or propertParm to be present.

Hope this=20 helps.

Thanks,
Jisu

On 5/30/07, Arvind Charanyan <arvind.charanyan@ccpu.com >=20 wrote:

Hi,

I have a doubt = regarding the=20 implementation of the contextAttrDescriptor in TEXT Mode. =

The ABNF definition = for=20 contextAttrDescriptor is as follows –

contextAttrDescriptor=20 =3D ContextAttrToken LBRKT (contextIdList / propertyParm *(COMMA=20 propertyParm)) RBRKT

which means it is a = choice=20 between contextIDList and propertyparm.

But according to ASN = Grammar,=20 the ContextRequest is defined as follows –

ContextRequest         = ;            = =20 ::=3D SEQUENCE

{

           &= nbsp;=20 = priority           = ;            =             &= nbsp;           &n= bsp;=20 INTEGER(0..15) OPTIONAL,

           &= nbsp;=20 = emergency          &nbs= p;            = ;            =        =20 BOOLEAN OPTIONAL,

           &= nbsp;=20 = topologyReq       &n= bsp;           &nb= sp;       =20 =              = SEQUENCE OF TopologyRequest OPTIONAL,

           &= nbsp;=20 …,

           &= nbsp;=20 = iepscallind          &n= bsp;           &nb= sp;           &nbs= p;       =20 BOOLEAN OPTIONAL,

           &= nbsp;=20 = contextProp          &n= bsp;           &nb= sp;           &nbs= p;     =20 SEQUENCE OF PropertyParm OPTIONAL,

           &= nbsp;=20 = contextList          &n= bsp;           &nb= sp;           &nbs= p;       =20 SEQUENCE OF ContextID OPTIONAL

}

In this PropertyParm = and=20 ContextIDList are part of the sequence.

Can you please help me = out by=20 clarifying this ambiguity between ABNF and ASN = Grammar?

Thanks,

Arvind

_______________________________________________
Megaco=20 mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco<= /FONT>

------_=_NextPart_001_01C7A81B.BDEFD3C4-- --===============1620778769== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1620778769==-- From megaco-bounces@ietf.org Wed Jun 06 10:31:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvwXj-0007Tm-Uy; Wed, 06 Jun 2007 10:31:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvwXi-0007Sz-EW for megaco@ietf.org; Wed, 06 Jun 2007 10:31:22 -0400 Received: from nz-out-0506.google.com ([64.233.162.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvwXg-0006Vp-JM for megaco@ietf.org; Wed, 06 Jun 2007 10:31:22 -0400 Received: by nz-out-0506.google.com with SMTP id z31so159790nzd for ; Wed, 06 Jun 2007 07:31:20 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=qMzOq/h6V7kR4cYRRh5fAw+7OLncMcdDEaDH0Oto4MJFhzAWpGzjJCspwVc6rSBQgx2sWOYCpxtuWL1GBauBNOYQjB+PfoouKRN6ssbmC+UUhMrfE0G7PXrCvQE29/7UMn8mhh4vBRc/OriZ/yPr9+aGqx20jgFYMlNOcrJqAlA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=H1obAGSnQ4O+scPpthNYMt8ZYRnWY2xF28Ox8pDjsAuXREqwO3K9Y5m6pon0If6Fb5r79hOHxrXQlxmy66RynyR1swJvq3/d1gER8jHuw/lVd5t7Hl+JeGGOfCnA5XaLuoB7fOEg4YP1ghDIEWyoqtTpELbYFwoDe9UVvOksGMM= Received: by 10.114.137.2 with SMTP id k2mr465727wad.1181140279317; Wed, 06 Jun 2007 07:31:19 -0700 (PDT) Received: by 10.114.171.11 with HTTP; Wed, 6 Jun 2007 07:31:16 -0700 (PDT) Message-ID: <2ef41d6d0706060731v293e592eg91024171d7b1dec2@mail.gmail.com> Date: Wed, 6 Jun 2007 07:31:16 -0700 From: "Jisu Bhattacharya" To: "jeremy_trask@agilent.com" Subject: Re: [Megaco] Reg contextAttrDescriptor Structure Difference betweenTEXT and ASN Modes In-Reply-To: <77207087078AEF438EC0B4B3A757FFC4022A2294@wsqfmb01.britain.agilent.com> MIME-Version: 1.0 References: <2ef41d6d0706051123v1d949426x3fc0b41735cdd220@mail.gmail.com> <77207087078AEF438EC0B4B3A757FFC4022A2294@wsqfmb01.britain.agilent.com> X-Spam-Score: 1.0 (+) X-Scan-Signature: 0d6b5666eba887052ef5e87a9de0d3b8 Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0947295392==" Errors-To: megaco-bounces@ietf.org --===============0947295392== Content-Type: multipart/alternative; boundary="----=_Part_43393_22512215.1181140276392" ------=_Part_43393_22512215.1181140276392 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline The ContextAttrDescriptor is *contextIdList / propertyParm *(COMMA propertyParm) * as per ABNF. Therefore, "contextIDList COMMA propertyParm" should be able to match this grammar syntactically. What am I missing? On 6/6/07, jeremy_trask@agilent.com wrote: > > Hmm, if the separator is COMMA where is the syntactic definition that > defines that? I think you are slightly misreading the definition of > contextAttrDescriptor. > > A single instance of a contextAttrDescriptor can only contain either a > single contextIdLIst or a (comma separated) list of one or more > propertyParm. If any higher level construct should allow more than one > contextAttrDescriptor then that construct would define the separator at t= hat > level between those multiple instances of contextAttrDescriptor. > > Referring to the original question, possibly the ambiguity is to whether > the contextRequest allows multiple instances of contextAttrDescriptor. > > The ASN suggests that syntactically a ContextRequest can contain both a > list of PropertyParm and a list of ContextID (both are optional.) > > However, in the ABNF definition of contextRequest it is implied (if I > understand correctly) that when there is a list of contextProperty then e= ach > possible property can only appear in the list at most once. So > contextAttrDescriptor (being a contextProperty) can only appear once in > which case it is not valid (although still syntactically correct) for a > contextRequest to contain both a contextIdList and a list of propertyParm > (as this would imply multiple instances of contextAttrDescriptor). > > For the two definitions to be consistent the ASN definition should also > mention that contextProp and contextList are mutually exclusive. > > Regards...jeremy > > ------------------------------ > *From:* Jisu Bhattacharya [mailto:jisu72@gmail.com] > *Sent:* 05 June 2007 19:24 > *To:* Arvind Charanyan > *Cc:* megaco@ietf.org > *Subject:* Re: [Megaco] Reg contextAttrDescriptor Structure Difference > betweenTEXT and ASN Modes > > Arvind, > > COMMA(,) is the separator between the two. The ContextIdList begins with > ContextListToken (CLT or "ContextList"), so it will be easy to distinguis= h > it from propertyParm. > > Thanks, > Jisu > > On 6/4/07, Arvind Charanyan wrote: > > > > Hi, > > > > > > > > In the case you have mentioned below, if we can have *"**0 to one > > contextIdList AND 0 to infinite number of propertyParm (covered by the > > *(COMMA propertyParm))", *then what would be the SEPARATOR between the > > two when both are present. > > > > > > > > Looking forward to some inputs in this regard. > > > > > > > > Thanks and Regards, > > > > Arvind > > ------------------------------ > > > > *From:* Jisu Bhattacharya [mailto:jisu72@gmail.com] > > *Sent:* Wednesday, May 30, 2007 11:46 PM > > *To:* Arvind Charanyan > > *Cc:* megaco@ietf.org > > *Subject:* Re: [Megaco] Reg contextAttrDescriptor Structure Difference > > between TEXT and ASN Modes > > > > > > > > Arvind, > > > > *contextIdList / propertyParm *(COMMA propertyParm) > > * > > does not mean a choice between contextIdList and propertyParm. It means > > that you can have 0 to one contextIdList AND 0 to infinite number of > > propertyParm (covered by the *(COMMA propertyParm)). However, it requir= es at > > least one contextIdList or propertParm to be present. > > > > Hope this helps. > > > > Thanks, > > Jisu > > > > On 5/30/07, *Arvind Charanyan* wrote: > > > > Hi, > > > > > > > > I have a doubt regarding the implementation of the contextAttrDescripto= r > > in TEXT Mode. > > > > > > > > The ABNF definition for contextAttrDescriptor is as follows =96 > > > > > > > > *contextAttrDescriptor =3D ContextAttrToken LBRKT (contextIdList / > > propertyParm *(COMMA propertyParm)) RBRKT* > > > > > > > > which means it is a choice between contextIDList and propertyparm. > > > > > > > > But according to ASN Grammar, the ContextRequest is defined as follows = =96 > > > > > > > > > > *ContextRequest ::=3D SEQUENCE* > > > > *{* > > > > * priority > > INTEGER(0..15) OPTIONAL,* > > > > * emergency > > BOOLEAN OPTIONAL,* > > > > * *topologyReq > > SEQUENCE OF TopologyRequest OPTIONAL, > > > > * =85,* > > > > * iepscallind > > BOOLEAN OPTIONAL,* > > > > * contextProp > > SEQUENCE OF PropertyParm OPTIONAL,* > > > > * contextList > > SEQUENCE OF ContextID OPTIONAL* > > > > *}* > > > > > > > > In this PropertyParm and ContextIDList are part of the sequence. > > > > > > > > Can you please help me out by clarifying this ambiguity between ABNF an= d > > ASN Grammar? > > > > > > > > Thanks, > > > > Arvind > > > > > > > > > > _______________________________________________ > > 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 > > ------=_Part_43393_22512215.1181140276392 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline The ContextAttrDescriptor is
contex= tIdList / propertyParm *(COMMA propertyParm)
as per ABNF.
Ther= efore, "contextIDList COMMA propertyParm" should be able to
m= atch this grammar syntactically.
What am I missing?

On 6/6/07, jeremy_trask@agilent.com= <jeremy_trask@agilent.c= om > wrote:

Hmm, if the=20 separator is COMMA where is the syntactic definition that defines that? I t= hink=20 you are slightly misreading the definition of=20 contextAttrDescriptor.

A single instance of a contextAttrDescriptor can only=20 contain either a single contextIdLIst or a (comma separated) list= of=20 one or more propertyParm. If any higher level construct should allow more t= han=20 one contextAttrDescriptor then that construct would define the separator at= that=20 level between those multiple instances of=20 contextAttrDescriptor.

Referring to the=20 original question, possibly the ambiguity is to whether the=20 contextRequest allows multiple instances of=20 contextAttrDescriptor.

The ASN suggests that syntactically a ContextRequest=20 can contain both a list of PropertyParm and a list of ContextID (both = are=20 optional.)

However, in the ABNF definition of contextRequest it is=20 implied (if I understand correctly) that when there is a list of contextPro= perty=20 then each possible property can only appear in the list at most once. = So=20 contextAttrDescriptor (being a contextProperty) can only appear once in whi= ch=20 case it is not valid (although still syntactically correct) for a=20 contextRequest to contain both a contextIdList and a list of propertyParm (= as=20 this would imply multiple instances of=20 contextAttrDescriptor).

For the two definitions to be consistent the ASN=20 definition should also mention that contextProp and contextList are mutuall= y=20 exclusive.

Regards...jeremy

From: Jisu Bhat= tacharya=20 [mailto:jisu72@gmail.com]
Sent: 05 June 2007 19:24

To:=20 Arvind Charanyan
Cc: megaco= @ietf.org
Subject: Re: [Megaco]=20 Reg contextAttrDescriptor Structure Difference betweenTEXT and ASN=20 Modes

Arvind,

COMMA(,) is the separator between the two. The= =20 ContextIdList begins with ContextListToken (CLT or "ContextList"= ;), so it will=20 be easy to distinguish it from propertyParm.

Thanks,
Jisu

On 6/4/07, Arvind=20 Charanyan <arvind.cha= ranyan@ccpu.com>=20 wrote:

Hi,

In the case you=20 have mentioned below, if we can have "0 to one= =20 contextIdList AND 0 to infinite number of propertyParm (covered by the= =20 *(COMMA propertyParm))", then=20 what would be the SEPARATOR between the two when both are=20 present.

Looking forward to=20 some inputs in this regard.

Thanks and=20 Regards,

Arvind =20

From:jisu72@gmail.c= om]=20
Sent: Wednesday, M= ay 30,=20 2007 11:46 PM
To: A= rvind=20 Charanyan
Cc: megaco@ietf.org
Subject: Re: [Megaco] Reg=20 contextAttrDescriptor Structure Difference between TEXT and ASN=20 Modes

Arvind,

contextIdList=20 / propertyParm *(COMMA propertyParm)

does not mean=20 a choice between contextIdList and propertyParm. It means that you can = have=20 0 to one contextIdList AND 0 to infinite number of propertyParm (covere= d by=20 the *(COMMA propertyParm)). However, it requires at least one contextId= List=20 or propertParm to be present.

Hope this=20 helps.

Thanks,
Jisu

On 5/30/07, Arvind Chara= nyan < arvind.charanyan@ccpu.com >=20 wrote:

Hi,

I have a doubt regarding the=20 implementation of the contextAttrDescriptor in TEXT Mode.

The ABNF definition for=20 contextAttrDescriptor is as follows =96

contextAttrDescriptor=20 =3D ContextAttrToken LBRKT (contextIdList / propertyParm *(COMMA=20 propertyParm)) RBRKT

which means it is a choice=20 between contextIDList and propertyparm.

But according to ASN Grammar,=20 the ContextRequest is defined as follows =96

ContextRequest   = ;            &n= bsp;     =20 ::=3D SEQUENCE

{

     &= nbsp;      =20 priority          &nb= sp;            =             &nb= sp;            = =20 INTEGER(0..15) OPTIONAL,

     &= nbsp;      =20 emergency          &n= bsp;            = ;            &n= bsp;      =20 BOOLEAN OPTIONAL,

     &= nbsp;      =20 topologyReq       =             &nb= sp;       =20             = ;=20 SEQUENCE OF TopologyRequest OPTIONAL,

       &nbs= p;    =20 =85,

       &nbs= p;    =20 iepscallind          =             &nb= sp;            =        =20 BOOLEAN OPTIONAL,

       &nbs= p;    =20 contextProp          =             &nb= sp;            =      =20 SEQUENCE OF PropertyParm OPTIONAL,

       &nbs= p;    =20 contextList          =             &nb= sp;            =        =20 SEQUENCE OF ContextID OPTIONAL

}

In this PropertyParm and=20 ContextIDList are part of the sequence.

Can you please help me out by=20 clarifying this ambiguity between ABNF and ASN Grammar?

Thanks,

Arvind

_______________________________= ________________
Megaco=20 mailing list
Megaco@ietf.org<= br> https://www1.ietf.org/mailman/listinfo/megaco
<= /div>

_______________________________________________
Megaco mailing list<= br>Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

------=_Part_43393_22512215.1181140276392-- --===============0947295392== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0947295392==-- From megaco-bounces@ietf.org Wed Jun 06 11:01:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvx0o-0005cY-3e; Wed, 06 Jun 2007 11:01:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvx0n-0005cO-KJ for megaco@ietf.org; Wed, 06 Jun 2007 11:01:25 -0400 Received: from nz-out-0506.google.com ([64.233.162.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvx0m-0003FZ-7i for megaco@ietf.org; Wed, 06 Jun 2007 11:01:25 -0400 Received: by nz-out-0506.google.com with SMTP id z31so169642nzd for ; Wed, 06 Jun 2007 08:01:23 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type; b=QK5CtOv0eM3i2jzNtpZvdPTM3DJyreJMiyDetkP2gNldz4KjZ99R23nxvn/o6Dzc0y8YNmpdNiOs8U8gfq+avS11nJgwkBjmxGpaBNuVM0ZhvktXH6WixWf/u6+WHt81qnmfvgG4Ul0RAa5akmux3B3U5a62rWx+aLqjAguEgCA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type; b=RwykCgf7FIiiguCw9PAyKFm/LrztuSs21DDhr1z1Cdp8oMlzs6Hf7jlEzzHgdmQ4fnCPnYMNNjfChIxKHlI74sL4nNLPuvI+Iu34socpuulBOMw/H5Wst+m0cJCj6+mkYcF6LUawAnt3N5+5MrSHmA/aoSQjDro7x4XC1bnS4T8= Received: by 10.143.160.1 with SMTP id m1mr28090wfo.1181142083439; Wed, 06 Jun 2007 08:01:23 -0700 (PDT) Received: by 10.143.40.10 with HTTP; Wed, 6 Jun 2007 08:01:23 -0700 (PDT) Message-ID: <2b0fd4cb0706060801q71a90f94qc711e44ee919451@mail.gmail.com> Date: Wed, 6 Jun 2007 17:01:23 +0200 From: "karthik prabhu Balakrishnan" To: megaco@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.2 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: Albrecht.Schwarz@alcatel-lucent.de Subject: [Megaco] Reg SO,RO RTP X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0993801116==" Errors-To: megaco-bounces@ietf.org --===============0993801116== Content-Type: multipart/alternative; boundary="----=_Part_20368_7469279.1181142083423" ------=_Part_20368_7469279.1181142083423 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello All, I have a basic doubt to get clarrifed. endpoint line/1 calls line/2 in a different gateway. Shown below are the ADD requests from MGC. T=41 showing ADD on originating Gateway. T=42 showing ADD on terminating Gateway. T=41{C=${A=line/1{M{ O{MO=SR}},SG{},E=63{al/on{strict=failWrong}}},A=${M{L{ v=0 o=bell 53655 53655 IN IP4 128.3.4.6 c=IN IP4 $ m=audio $ RTP/AVP 8 },O{MO=RC,RV=ON}}}}} T=42{C=${A=line/2{M{O{MO=SR}},SG{al/ri},E=64{al/of{strict=failWrong}}},A=${M{L{ v=0 o=bell 53655 53655 IN IP4 128.3.4.6 c=IN IP4 $ m=audio $ RTP/AVP 8 },R{ v=0 o=bell 53655 53655 IN IP4 172.21.143.59 s=SDP from MEGACO LINE c=IN IP4 xxxxxxxx t=0 0 m=audio 8000 RTP/AVP 8 },O{MO=SO}}}}} Clarrification: i assume that, the Originating RTP termination is requestd to of type RO, so that before answer phase, for an unsuccesful call setup, an announcement could be played. a personalised ringback tone be applied. Question1. Are my assumptions correct? Are there any other reasons to have a receive only RTP. Question2. from T=42, the terminating RTP is requested to be of type SO. Please let me understand the reason behind this. Thanks and Regards, karthik Prabhu ------=_Part_20368_7469279.1181142083423 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

Hello All,

I have a basic doubt to get clarrifed.

endpoint line/1 calls line/2 in a different gateway.

Shown below are the ADD requests from MGC.

T=41 showing ADD on originating Gateway.

T=42 showing ADD on terminating Gateway.

T=41{C=${A=line/1{M{ O{MO=SR}},SG{},E=63{al/on{strict=failWrong}}},A=${M{L{
v=0
o=bell 53655 53655 IN IP4 128.3.4.6
c=IN IP4 $
m=audio $ RTP/AVP 8
},O{ MO=RC,RV=ON}}}}}

T=42{C=${A=line/2{M{O{MO=SR}},SG{al/ri},E=64{al/of{strict=failWrong}}},A=${M{L{
v=0
o=bell 53655 53655 IN IP4 128.3.4.6
c=IN IP4 $
m=audio $ RTP/AVP 8
},R{
v=0
o=bell 53655 53655 IN IP4 172.21.143.59
s=SDP from MEGACO LINE
c=IN IP4 xxxxxxxx
t=0 0
m=audio 8000 RTP/AVP 8
},O{MO=SO}}}}}

Clarrification:

i assume that, the Originating RTP termination is requestd to of type RO,

so that before answer phase,

for an unsuccesful call setup, an announcement could be played.

a personalised ringback tone be applied.

Question1.

Are my assumptions correct?

Are there any other reasons to have a receive only RTP.

Question2.

from T=42, the terminating RTP is requested to be of type SO.

Please let me understand the reason behind this.

Thanks and Regards,

karthik Prabhu

------=_Part_20368_7469279.1181142083423-- --===============0993801116== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0993801116==-- From megaco-bounces@ietf.org Wed Jun 06 18:38:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw48g-0005bb-OI; Wed, 06 Jun 2007 18:38:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw48g-0005bR-1T for megaco@ietf.org; Wed, 06 Jun 2007 18:38:02 -0400 Received: from msgbas1x.net.europe.agilent.com ([192.25.19.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw48Y-0004wM-A5 for megaco@ietf.org; Wed, 06 Jun 2007 18:38:01 -0400 Received: from relbbn1.germany.agilent.com (relbbn1.germany.agilent.com [134.40.2.32]) by msgbas1x.net.europe.agilent.com (Postfix) with ESMTP id 7E51599B for ; Thu, 7 Jun 2007 00:37:53 +0200 (METDST) Received: from wbbnvs01.germany.agilent.com (wbbnvs01.germany.agilent.com [134.40.35.39]) by relbbn1.germany.agilent.com (Postfix) with ESMTP id 630E4810C for ; Thu, 7 Jun 2007 00:37:53 +0200 (CEST) Received: from wbbnbh03.germany.agilent.com ([134.40.35.50]) by wbbnvs01.germany.agilent.com with InterScan Messaging Security Suite; Thu, 07 Jun 2007 00:37:52 +0200 Received: from wsqfmb01.britain.agilent.com ([156.141.51.43]) by wbbnbh03.germany.agilent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jun 2007 00:37:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Megaco] Reg contextAttrDescriptor Structure Difference betweenTEXT and ASN Modes Date: Wed, 6 Jun 2007 23:37:43 +0100 Message-ID: <77207087078AEF438EC0B4B3A757FFC4022A2536@wsqfmb01.britain.agilent.com> In-Reply-To: <2ef41d6d0706060731v293e592eg91024171d7b1dec2@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] Reg contextAttrDescriptor Structure Difference betweenTEXT and ASN Modes Thread-Index: AceoSKRRKrsPunoJRj67mj0vvqLeKgAQGikA From: To: X-OriginalArrivalTime: 06 Jun 2007 22:37:52.0702 (UTC) FILETIME=[51A4BDE0:01C7A88B] X-Spam-Score: 0.2 (/) X-Scan-Signature: fd911903d9eb33179d1ec28b0417afe8 X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1313457121==" Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============1313457121== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A88B.510B08E5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A88B.510B08E5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The two elements in the alternative rule are and = . It would be less ambiguous if the = form "contextIdList / (propertyParm *(COMMA propertyParm)) we used to = explicitly delimit the sequence group.RFC 2234 gives some information = about alternatives and sequence groups that explains just such an = example case. =20 Regards...jeremy=20 ________________________________ From: Jisu Bhattacharya [mailto:jisu72@gmail.com]=20 Sent: 06 June 2007 15:31 To: jeremy_trask@agilent.com Cc: megaco@ietf.org Subject: Re: [Megaco] Reg contextAttrDescriptor Structure Difference = betweenTEXT and ASN Modes =09 =09 The ContextAttrDescriptor is=20 contextIdList / propertyParm *(COMMA propertyParm) as per ABNF. Therefore, "contextIDList COMMA propertyParm" should be able to=20 match this grammar syntactically. What am I missing? =09 =09 =09 On 6/6/07, jeremy_trask@agilent.com wrote:=20 Hmm, if the separator is COMMA where is the syntactic definition that = defines that? I think you are slightly misreading the definition of = contextAttrDescriptor. =20 A single instance of a contextAttrDescriptor can only contain either a = single contextIdLIst or a (comma separated) list of one or more = propertyParm. If any higher level construct should allow more than one = contextAttrDescriptor then that construct would define the separator at = that level between those multiple instances of contextAttrDescriptor. =20 Referring to the original question, possibly the ambiguity is to = whether the contextRequest allows multiple instances of = contextAttrDescriptor. =20 The ASN suggests that syntactically a ContextRequest can contain both = a list of PropertyParm and a list of ContextID (both are optional.) =20 However, in the ABNF definition of contextRequest it is implied (if I = understand correctly) that when there is a list of contextProperty then = each possible property can only appear in the list at most once. So = contextAttrDescriptor (being a contextProperty) can only appear once in = which case it is not valid (although still syntactically correct) for a = contextRequest to contain both a contextIdList and a list of = propertyParm (as this would imply multiple instances of = contextAttrDescriptor). =20 For the two definitions to be consistent the ASN definition should = also mention that contextProp and contextList are mutually exclusive. =20 Regards...jeremy ________________________________ From: Jisu Bhattacharya [mailto:jisu72@gmail.com]=20 Sent: 05 June 2007 19:24=20 =09 To: Arvind Charanyan Cc: megaco@ietf.org Subject: Re: [Megaco] Reg contextAttrDescriptor Structure Difference = betweenTEXT and ASN Modes =09 =09 Arvind, =09 COMMA(,) is the separator between the two. The ContextIdList begins = with ContextListToken (CLT or "ContextList"), so it will be easy to = distinguish it from propertyParm. =09 Thanks, Jisu =09 =09 On 6/4/07, Arvind Charanyan wrote:=20 Hi, =20 In the case you have mentioned below, if we can have "0 to one = contextIdList AND 0 to infinite number of propertyParm (covered by the = *(COMMA propertyParm))", then what would be the SEPARATOR between the = two when both are present. =20 Looking forward to some inputs in this regard. =20 Thanks and Regards, Arvind =20 =09 ________________________________ From: Jisu Bhattacharya [mailto:jisu72@gmail.com]=20 Sent: Wednesday, May 30, 2007 11:46 PM To: Arvind Charanyan Cc: megaco@ietf.org Subject: Re: [Megaco] Reg contextAttrDescriptor Structure Difference = between TEXT and ASN Modes =20 Arvind, =09 contextIdList / propertyParm *(COMMA propertyParm) =09 does not mean a choice between contextIdList and propertyParm. It = means that you can have 0 to one contextIdList AND 0 to infinite number = of propertyParm (covered by the *(COMMA propertyParm)). However, it = requires at least one contextIdList or propertParm to be present.=20 =09 Hope this helps. =09 Thanks, Jisu =09 =09 On 5/30/07, Arvind Charanyan < arvind.charanyan@ccpu.com = > wrote: =09 Hi, =20 I have a doubt regarding the implementation of the = contextAttrDescriptor in TEXT Mode.=20 =20 The ABNF definition for contextAttrDescriptor is as follows -=20 =20 contextAttrDescriptor =3D ContextAttrToken LBRKT (contextIdList / = propertyParm *(COMMA propertyParm)) RBRKT =20 which means it is a choice between contextIDList and propertyparm. =20 But according to ASN Grammar, the ContextRequest is defined as = follows -=20 =20 ContextRequest ::=3D SEQUENCE { priority = INTEGER(0..15) OPTIONAL, emergency = BOOLEAN OPTIONAL, topologyReq = SEQUENCE OF TopologyRequest OPTIONAL, ..., iepscallind = BOOLEAN OPTIONAL, contextProp = SEQUENCE OF PropertyParm OPTIONAL, contextList = SEQUENCE OF ContextID OPTIONAL } =20 In this PropertyParm and ContextIDList are part of the sequence. =20 Can you please help me out by clarifying this ambiguity between ABNF = and ASN Grammar? =20 Thanks, Arvind =20 =09 _______________________________________________ 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 =09 =09 ------_=_NextPart_001_01C7A88B.510B08E5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The two elements in the alternative rule are=20 <contextIdList> and <propertyParm *(COMMA = propertyParm)>. It=20 would be less ambiguous if the form "contextIdList / (propertyParm = *(COMMA=20 propertyParm)) we used to explicitly delimit the sequence group.RFC 2234 = gives=20 some information about alternatives and sequence groups = that explains=20 just such an example case.

Regards...jeremy

From: Jisu Bhattacharya=20 [mailto:jisu72@gmail.com]
Sent: 06 June 2007 = 15:31
To:=20 jeremy_trask@agilent.com
Cc: = megaco@ietf.org
Subject: Re:=20 [Megaco] Reg contextAttrDescriptor Structure Difference betweenTEXT = and ASN=20 Modes

The ContextAttrDescriptor is
contextIdList=20 / propertyParm *(COMMA propertyParm)
as per=20 ABNF.
Therefore, "contextIDList COMMA propertyParm" should be able = to=20
match this grammar syntactically.
What am I=20 missing?

On 6/6/07, jeremy_trask@agilent.com= <jeremy_trask@agilent.com = >=20 wrote:

Hmm, if the separator is COMMA where is the syntactic = definition that=20 defines that? I think you are slightly misreading the definition of=20 contextAttrDescriptor.

A single=20 instance of a contextAttrDescriptor can only contain either a single = contextIdLIst or a (comma separated) list of one or more=20 propertyParm. If any higher level construct should allow more than = one=20 contextAttrDescriptor then that construct would define the separator = at that=20 level between those multiple instances of=20 contextAttrDescriptor.

Referring to the original question, possibly = the=20 ambiguity is to whether the contextRequest allows multiple instances = of=20 contextAttrDescriptor.

The ASN=20 suggests that syntactically a ContextRequest can contain both a list = of=20 PropertyParm and a list of ContextID (both are=20 optional.)

However,=20 in the ABNF definition of contextRequest it is implied (if I = understand=20 correctly) that when there is a list of contextProperty then each = possible=20 property can only appear in the list at most once. So=20 contextAttrDescriptor (being a contextProperty) can only appear once = in=20 which case it is not valid (although still syntactically = correct) for a=20 contextRequest to contain both a contextIdList and a list of = propertyParm=20 (as this would imply multiple instances of=20 contextAttrDescriptor).

For the=20 two definitions to be consistent the ASN definition should also = mention that=20 contextProp and contextList are mutually = exclusive.

Regards...jeremy

From: Jisu = Bhattacharya=20 [mailto:jisu72@gmail.com]=20
Sent: 05 June 2007 19:24

To: Arvind Charanyan
Cc: megaco@ietf.org
Subject: Re: = [Megaco] Reg=20 contextAttrDescriptor Structure Difference betweenTEXT and ASN=20 Modes

Arvind,

COMMA(,) is the separator between the = two. The=20 ContextIdList begins with ContextListToken (CLT or "ContextList"), = so it=20 will be easy to distinguish it from=20 propertyParm.

Thanks,
Jisu

On 6/4/07, Arvind=20 Charanyan <arvind.charanyan@ccpu.com> wrote:=20

Hi,

In = the case you=20 have mentioned below, if we can have "0 to one=20 contextIdList AND 0 to infinite number of propertyParm (covered = by the=20 *(COMMA propertyParm))", then = what would=20 be the SEPARATOR between the two when both are=20 present.

Looking forward=20 to some inputs in this regard.

Thanks and=20 Regards,

Arvind =20

From:=20 Jisu Bhattacharya [mailto:jisu72@gmail.com]=20
Sent: = Wednesday, May=20 30, 2007 11:46 PM
To:=20 Arvind Charanyan
Cc: megaco@ietf.org
Subject: Re: [Megaco] Reg = contextAttrDescriptor Structure Difference between TEXT and ASN=20 Modes

Arvind,

contextIdList=20 / propertyParm *(COMMA propertyParm)

does not = mean a choice=20 between contextIdList and propertyParm. It means that you can = have 0 to=20 one contextIdList AND 0 to infinite number of propertyParm = (covered by=20 the *(COMMA propertyParm)). However, it requires at least one=20 contextIdList or propertParm to be present.

Hope this=20 helps.

Thanks,
Jisu

On 5/30/07, Arvind Charanyan <=20 arvind.charanyan@ccpu.com >=20 wrote:

Hi,

I have a doubt = regarding the=20 implementation of the contextAttrDescriptor in TEXT Mode.=20

The ABNF = definition for=20 contextAttrDescriptor is as follows –

contextAttrDescriptor=20 =3D ContextAttrToken LBRKT (contextIdList / propertyParm *(COMMA = propertyParm)) RBRKT

which means it is = a choice=20 between contextIDList and propertyparm.

But according to = ASN=20 Grammar, the ContextRequest is defined as follows – =

ContextRequest         = ;            = =20 ::=3D SEQUENCE

{

           &= nbsp;=20 = priority           = ;            =             &= nbsp;           &n= bsp;=20 INTEGER(0..15) OPTIONAL,

           &= nbsp;=20 = emergency          &nbs= p;            = ;            =        =20 BOOLEAN OPTIONAL,

           &= nbsp;=20 = topologyReq       &n= bsp;           &nb= sp;       =20 =              = SEQUENCE OF TopologyRequest OPTIONAL,

           &= nbsp;=20 …,

           &= nbsp;=20 = iepscallind          &n= bsp;           &nb= sp;           &nbs= p;       =20 BOOLEAN OPTIONAL,

           &= nbsp;=20 = contextProp          &n= bsp;           &nb= sp;           &nbs= p;     =20 SEQUENCE OF PropertyParm OPTIONAL,

           &= nbsp;=20 = contextList          &n= bsp;           &nb= sp;           &nbs= p;       =20 SEQUENCE OF ContextID OPTIONAL

}

In this = PropertyParm and=20 ContextIDList are part of the sequence.

Can you please = help me out=20 by clarifying this ambiguity between ABNF and ASN=20 Grammar?

Thanks,

Arvind

_______________________________________________
Megaco=20 mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco<= /FONT>

<= /DIV>

_____________________________________________= __
Megaco=20 mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco

=

------_=_NextPart_001_01C7A88B.510B08E5-- --===============1313457121== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1313457121==-- From megaco-bounces@ietf.org Wed Jun 06 19:23:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw4qT-0003gH-01; Wed, 06 Jun 2007 19:23:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw4qR-0003gC-IU for megaco@ietf.org; Wed, 06 Jun 2007 19:23:15 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw4qQ-0005n2-5c for megaco@ietf.org; Wed, 06 Jun 2007 19:23:15 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 9F3611C7C59; Wed, 6 Jun 2007 16:23:13 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04401-03; Wed, 6 Jun 2007 16:23:13 -0700 (PDT) Received: from [155.53.44.239] (cologne.redback.com [155.53.44.239]) by prattle.redback.com (Postfix) with ESMTP id 2F66D1C7C58; Wed, 6 Jun 2007 16:23:13 -0700 (PDT) Message-ID: <466741E1.8050207@redback.com> Date: Wed, 06 Jun 2007 16:23:13 -0700 From: Ashish Singh User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: karthik prabhu Balakrishnan Subject: Re: [Megaco] Reg SO,RO RTP References: <2b0fd4cb0706060801q71a90f94qc711e44ee919451@mail.gmail.com> In-Reply-To: <2b0fd4cb0706060801q71a90f94qc711e44ee919451@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: megaco@ietf.org, Albrecht.Schwarz@alcatel-lucent.de X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Hi Karthik, mode=RC at originating gateway and mode=SO at terminating gateway will take care of early media, where terminating gateway can start sending media packets right away. Thanks Ashish. karthik prabhu Balakrishnan wrote: > Hello All, > I have a basic doubt to get clarrifed. > endpoint line/1 calls line/2 in a different gateway. > Shown below are the ADD requests from MGC. > T=41 showing ADD on originating Gateway. > T=42 showing ADD on terminating Gateway. > > > T=41{C=${A=line/1{M{ > O{MO=SR}},SG{},E=63{al/on{strict=failWrong}}},A=${M{L{ > v=0 > o=bell 53655 53655 IN IP4 128.3.4.6 > c=IN IP4 $ > m=audio $ RTP/AVP 8 > },O{ MO=RC,RV=ON}}}}} > > T=42{C=${A=line/2{M{O{MO=SR}},SG{al/ri},E=64{al/of{strict=failWrong}}},A=${M{L{ > v=0 > o=bell 53655 53655 IN IP4 128.3.4.6 > c=IN IP4 $ > m=audio $ RTP/AVP 8 > },R{ > v=0 > o=bell 53655 53655 IN IP4 172.21.143.59 > s=SDP from MEGACO LINE > c=IN IP4 xxxxxxxx > t=0 0 > m=audio 8000 RTP/AVP 8 > },O{MO=SO}}}}} > > > Clarrification: > i assume that, the Originating RTP termination is requestd to of type RO, > so that before answer phase, > for an unsuccesful call setup, an announcement could be played. > a personalised ringback tone be applied. > > Question1. > Are my assumptions correct? > Are there any other reasons to have a receive only RTP. > > Question2. > from T=42, the terminating RTP is requested to be of type SO. > Please let me understand the reason behind this. > > Thanks and Regards, > karthik Prabhu > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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-bounces@ietf.org Fri Jun 08 08:47:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwdrq-00010V-VL; Fri, 08 Jun 2007 08:47:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwdqi-0008QT-Nx for megaco@ietf.org; Fri, 08 Jun 2007 08:45:53 -0400 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail6.alcatel.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwdm3-0001Md-2p for megaco@ietf.org; Fri, 08 Jun 2007 08:41:08 -0400 Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.ad2.ad.alcatel.com [155.132.6.75]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l58Ce1tx018964; Fri, 8 Jun 2007 14:40:03 +0200 Received: from FRVELSMBS23.ad2.ad.alcatel.com ([155.132.6.53]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 8 Jun 2007 14:40:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Megaco] Reg SO,RO RTP Date: Fri, 8 Jun 2007 14:40:31 +0200 Message-ID: <3C3F18087A45AB46BFCF51AD944A84FF2BFAB2@FRVELSMBS23.ad2.ad.alcatel.com> In-Reply-To: <2b0fd4cb0706060801q71a90f94qc711e44ee919451@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] Reg SO,RO RTP Thread-Index: AceoS7cyi3w9ehZuTBi5aUi9RhHiNwBfkaFA From: "BEHAR ALDANA RONALD" To: "karthik prabhu Balakrishnan" , X-OriginalArrivalTime: 08 Jun 2007 12:40:58.0712 (UTC) FILETIME=[43AB0D80:01C7A9CA] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.2 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: Schwarz Albrecht X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0443447190==" Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============0443447190== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A9CA.43768DD4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A9CA.43768DD4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Another reason is that if You are connected to a PSTN Network, some = tones applied to the users can come from it so the port must be able to = receive RTP's. ________________________________ De: karthik prabhu Balakrishnan [mailto:karthik.megaco@gmail.com]=20 Enviado el: mi=E9rcoles, 06 de junio de 2007 17:01 Para: megaco@ietf.org CC: Schwarz Albrecht Asunto: [Megaco] Reg SO,RO RTP Hello All, I have a basic doubt to get clarrifed. endpoint line/1 calls line/2 in a different gateway. Shown below are the ADD requests from MGC. T=3D41 showing ADD on originating Gateway. T=3D42 showing ADD on terminating Gateway. =20 =20 T=3D41{C=3D${A=3Dline/1{M{ = O{MO=3DSR}},SG{},E=3D63{al/on{strict=3DfailWrong}}},A=3D${M{L{ v=3D0 o=3Dbell 53655 53655 IN IP4 128.3.4.6 c=3DIN IP4 $ m=3Daudio $ RTP/AVP 8 },O{ MO=3DRC,RV=3DON}}}}} =20 T=3D42{C=3D${A=3Dline/2{M{O{MO=3DSR}},SG{al/ri},E=3D64{al/of{strict=3Dfai= lWrong}}},A=3D${M{L{ v=3D0 o=3Dbell 53655 53655 IN IP4 128.3.4.6 c=3DIN IP4 $ m=3Daudio $ RTP/AVP 8 },R{ v=3D0 o=3Dbell 53655 53655 IN IP4 172.21.143.59 s=3DSDP from MEGACO LINE c=3DIN IP4 xxxxxxxx t=3D0 0 m=3Daudio 8000 RTP/AVP 8 },O{MO=3DSO}}}}} =20 =20 Clarrification: i assume that, the Originating RTP termination is requestd to of type = RO, so that before answer phase, for an unsuccesful call setup, an announcement could be played. a personalised ringback tone be applied. =20 Question1. Are my assumptions correct? Are there any other reasons to have a receive only RTP. =20 Question2. from T=3D42, the terminating RTP is requested to be of type SO. Please let me understand the reason behind this. =20 Thanks and Regards, karthik Prabhu =20 =20 =20 =20 ------_=_NextPart_001_01C7A9CA.43768DD4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Another reason is that if You are connected to = a PSTN=20 Network, some tones applied to the users can come from it so the port = must be=20 able to receive RTP's.

De: karthik prabhu Balakrishnan=20 [mailto:karthik.megaco@gmail.com]
Enviado el: mi=E9rcoles, 06 = de junio=20 de 2007 17:01
Para: megaco@ietf.org
CC: Schwarz=20 Albrecht
Asunto: [Megaco] Reg SO,RO RTP

Hello All,

I have a basic doubt to get clarrifed.

endpoint line/1 calls line/2 in a different gateway.

Shown below are the ADD requests from MGC.

T=3D41 showing ADD on originating Gateway.

T=3D42 showing ADD on terminating Gateway.

T=3D41{C=3D${A=3Dline/1{M{=20 O{MO=3DSR}},SG{},E=3D63{al/on{strict=3DfailWrong}}},A=3D${M{L{
v=3D0o=3Dbell 53655=20 53655 IN IP4 128.3.4.6
c=3DIN IP4 = $
m=3Daudio $=20 RTP/AVP 8
},O{ = MO=3DRC,RV=3DON}}}}}

T=3D42{C=3D${A=3Dline/2{M{O{MO=3DSR}},SG{al/ri},E=3D64{al/of{strict=3D= failWrong}}},A=3D${M{L{
v=3D0
o=3Dbell=20 53655 53655 IN IP4 128.3.4.6
c=3DIN = IP4=20 $
m=3Daudio $ RTP/AVP 8
},R{
v=3D0
o=3Dbell 53655 53655 IN = IP4 172.21.143.59
s=3DSDP from MEGACO = LINE
c=3DIN=20 IP4 xxxxxxxx
t=3D0 0
m=3Daudio 8000 RTP/AVP 8
},O{MO=3DSO}}}}}

Clarrification:

i assume that, the Originating RTP termination is requestd to of = type=20 RO,

so that before answer phase,

for an unsuccesful call setup, an announcement could be = played.

a personalised ringback tone be applied.

Question1.

Are my assumptions correct?

Are there any other reasons to have a receive only RTP.

Question2.

from T=3D42, the terminating RTP is requested to be of type = SO.

Please let me understand the reason behind this.

Thanks and Regards,

karthik Prabhu

------_=_NextPart_001_01C7A9CA.43768DD4-- --===============0443447190== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0443447190==-- From wqarz@lazerquick.com Fri Jun 08 17:59:59 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwmUx-000141-NN for megaco-archive@lists.ietf.org; Fri, 08 Jun 2007 17:59:59 -0400 Received: from 60.130.broadband4.iol.cz ([85.71.130.60]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwmUx-00054D-1R for megaco-archive@lists.ietf.org; Fri, 08 Jun 2007 17:59:59 -0400 Message-ID: <4669D17C.5070502@lazerquick.com> Date: Sat, 9 Jun 2007 00:00:28 +0200 From: Weber Sadie User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: megaco-archive@lists.ietf.org Subject: thermostat Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.5 (+++) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 CAON Takes New Direction. Investors Are All Over It! Chan-On International Inc. Symbol: CAON Close: $0.72 UP 4.35% Volume Jumped through the roof today as CAON announced it has changed its direction and acquired Harbin Hongbo, as wells as its 12 patients for environmentally safe construction materials. Investors are already seeing the potential. We expect great things from CAON with big news expected Monday. Get on CAON first thing Monday! I just have to play better. : Comments Here is good web site I will introduce it to my friends. Finally, I feel a lot better at the plate. As with the arc-type, implementations are free to interpret the prominence in any suitable manner. I mean, there is no doubt that we are teachers and so, we are teaching the world for more positive changes. He could not say the same for Alou, who was frustrated by the lingering injury. But if the Mets continue to endure injuries, there will be little to cheer. But Wang, who has been trying to diversify his repertory, said he wanted to ask Clemens how to throw a splitter. This was quite evident last Tuesday as these ladies played their first game of the season. Finally, Fairies forward Anne Marie Soulliere stepped up and scored to tie the game. The buzzer spared him from another official miss. When Wang was growing up in Taiwan, he said, few baseball games were shown on television. But the Cavaliers were pretty much done by then, and the Spurs were merely sitting on a big lead. More chances at either end were created and either closed down by the excellent defences or blocked by the equally impressive keepers. And Asmussen is hardly the only prominent trainer to find himself linked to drug issues. The biggest problem Cosmos will face will be limiting the shots they allow Tauro to take. She was definitely on her way to becoming a top goal scorer for the team this season. As a footnote, Bonham's hat trick took him into double figures for the season and move closer to one hundred Fulchester goals. The next season, on opening day in Toronto, Phelps came up against Clemens in the first inning with two on and two out. He has set expectations unbelievably high. From the poor quality of reffing to an injury that resulted, there was a lot that should have been different about the game. These ideas are embodied in the Special Initiative for Africa, led by Akwasi Aidoo of the Ford Foundation but they are widely shared and being advanced through many different endeavours. When James drove, the Spurs converged. It was a good night to be a dynasty. Fulchester was lead by a very well balanced attack that could have seen a goal come from just about every player on the squad. But Torre took him out, calling for the left-hander Mike Myers to face the left-handed-hitting A. But it struggled in this three-game series. Kayla Werebovetski is a big threat up front from DQ, and if Inferno can contain her they may just walk away with a win. With a key striker between the sticks, and Hawrysh back in defence, many thought Wounded would seek to contain the explosive Zilkowsky in a defensive display. With Pastor, Parton and Heath all providing good support for the defence and double-teaming as often as possible, the shorter-benched visitors took a firm hold on the game. I never asked him about it. The win capped a fine display from every blue-clad player and Manager Kev Brown was extremely happy to talk about the game afterwards. He said that he believed most veterinarians and trainers in the sport were playing by the rules. But the Cavaliers were pretty much done by then, and the Spurs were merely sitting on a big lead. Finally, Fairies forward Anne Marie Soulliere stepped up and scored to tie the game. From bil@conocophillips.com Sat Jun 09 06:50:42 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwyWo-0002Hn-Eo for megaco-archive@lists.ietf.org; Sat, 09 Jun 2007 06:50:42 -0400 Received: from [88.119.135.114] (helo=boucgat) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwyWn-0002d3-Rp for megaco-archive@lists.ietf.org; Sat, 09 Jun 2007 06:50:42 -0400 Message-ID: <466A8ABF.1070706@conocophillips.com> Date: Sat, 9 Jun 2007 14:10:55 +0300 From: Amos P. Frank User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: megaco-archive@lists.ietf.org Subject: sadist inconsequential Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.7 (+) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 CAON Takes New Direction. Investors Are All Over It! Chan-On International Inc. Symbol: CAON Close: $0.72 UP 4.35% Volume Jumped through the roof today as CAON announced it has changed its direction and acquired Harbin Hongbo, as wells as its 12 patients for environmentally safe construction materials. Investors are already seeing the potential. We expect great things from CAON with big news expected Monday. Get on CAON first thing Monday! He takes a couple of hours for dinner and a long walk, then he's back working the phones again. Of the handful of senators who have been working on a new immigration bill, Menendez might be expected to be a key player. Lobbyists United In Dismay Over Disclosure Rules - washingtonpost. White House officials say they have been surprised by the depth of Putin's anger over the missile defense plan. "We know other people have a bigger head start and we have a lot of ground to make up. In doing so, the judge rejected not only the wishes of Wolfowitz but also a brief, poignant plea from Libby himself. Evidence Entered in Trial Government exhibits used in the trial in the format admitted in the court. Unshaven and dressed in a blue Ralph Lauren oxford shirt and khakis, Chicoine could easily pass for a hung-over fraternity brother. I want my country back, and I want the U. Both senators have argued that the law is dangerous because it suspended habeas corpus, or the right of detainees at Guantanamo to challenge their detention in federal courts. The lobbyist must select gifts specially for that lawmaker, and not claim them as an expense or tax deduction. Currently, citizens also can bring parents and adult children. "Sadly I believe that Mr. Many letter writers expressed frustration over the Libby saga's conclusion. You could just not put out" campaign money. Some appear to have been solicited by Libby's lawyers; other letter writers said they were writing voluntarily to try to provide a fuller view of Libby's life. Wolfowitz, the soon-to-be-former World Bank president, has been in need of some character references himself since he lost his job because of a raise he arranged for his girlfriend. Walton agreed to rule on that matter at a hearing next week. "They passed this because they thought it was good for the Republic," said one. District Judge Reggie B. "But they'll still call and say 'Hey buddy, can you spare a dime? His proposals have the backing of major pro-immigration groups. "I just play with it," Chicoine says, fiddling with his wedding ring. Others offered details of what they described as Libby's crucial role in key administration decisions. Additionally, entries that are unsigned or contain "signatures" by someone other than the actual author will be removed. "We know other people have a bigger head start and we have a lot of ground to make up. Hoffman, the vice president's White House physician, asked Judge Reggie B. "With nerves jangled by the rising tensions, Bush felt it necessary to state what has been obvious for about two decades: "The Cold War is over. When those in high positions "step over the line," he continued, "it causes people to lose faith in our government. It surprised me that they'd been filed that close to an election. Appellate review of the judges' decision could allow the process to continue, and Bush could veto any legislation dealing with the issue. But when your candidate's got his big political moment and you're his only man in the state, who's got time to worry about honeymoons. officials say he was talking about Iran and North Korea. "I think public officials need to know if they are going to step over the line, there are going to be consequences. In doing so, the judge rejected not only the wishes of Wolfowitz but also a brief, poignant plea from Libby himself. Several letter writers, even some who indicated they disagreed with Libby, said they found Libby to be a man of uncommon decency. Clinton spokesman Mo Elleithee said the shake-up should be viewed as an expansion of the campaign's team in Des Moines and its emphasis on Iowa. To Menendez, Bill Sells Families Short - washingtonpost. The bill would allow U. Hoffman, the vice president's White House physician, asked Judge Reggie B. "I realize fully that the court must decide on punishment," the wiry defendant said. "But the discussion has shifted away from closing Guantanamo, in part because no one has presented a viable alternative. Czech President Vaclav Klaus raised those concerns during a meeting with Bush in the medieval Prague Castle. James Buchanan Security Cleared? citizens and lengthen the duration of a new parent visitor visa. When those in high positions "step over the line," he continued, "it causes people to lose faith in our government. Appellate review of the judges' decision could allow the process to continue, and Bush could veto any legislation dealing with the issue. She will stay on the Iowa team as a "senior strategist" and chief surrogate for Clinton around the state. "I think public officials need to know if they are going to step over the line, there are going to be consequences. From megaco-bounces@ietf.org Sun Jun 10 06:10:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxKMu-0002oW-Uf; Sun, 10 Jun 2007 06:09:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxKMt-0002oR-Nd for megaco@ietf.org; Sun, 10 Jun 2007 06:09:55 -0400 Received: from mailrelay2.alcatel.de ([194.113.59.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxKMt-0000nA-8D for megaco@ietf.org; Sun, 10 Jun 2007 06:09:55 -0400 Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr [155.132.182.205]) by mailrelay2.alcatel.de (8.13.4/8.13.4/ICT) with ESMTP id l5AA9ooG004806; Sun, 10 Jun 2007 12:09:50 +0200 In-Reply-To: <3C3F18087A45AB46BFCF51AD944A84FF2BFAB2@FRVELSMBS23.ad2.ad.alcatel.com> Subject: RE: [Megaco] Reg SO,RO RTP To: "BEHAR ALDANA RONALD" X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Albrecht.Schwarz@alcatel-lucent.de Date: Sun, 10 Jun 2007 12:09:46 +0200 X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 06/10/2007 12:09:49 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Scanned-By: MIMEDefang 2.51 on 149.204.45.73 X-Spam-Score: 0.2 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Seems to be a 2-party basic call (and not any supplementary service). There is a call establishment direction and a bearer establishment direction, and a bidirectional bearer has two unicast communication channels. The establishment of the unicast bearer from A to B MAY be done in "parallel" as call establishment from A to B. But typical services do already require at least the unicast bearer fro= m B to A direction, just for signaling of call progress information (e.g li= ke ringback tones etc). Conclusion: There are different requirements for "cut-through" of the two unicast bearer channels (in case of a bidirectional communication service). But, I guess there isn't any general principle. There might be a difference between services of a) PSTN emulation subsystem (PES) and b) IP multimedia subsystem (IMS) and other subsystems for other services. = = =20 "BEHAR ALDANA RONALD" = = =20 , =20 -lucent.es> cc: Sch= warz Albrecht = =20 Subject: RE:= [Megaco] Reg SO,RO RTP = =20 08.06.2007 14:40 = = =20 = = =20 Another reason is that if You are connected to a PSTN Network, some ton= es applied to the users can come from it so the port must be able to recei= ve RTP's. De: karthik prabhu Balakrishnan [mailto:karthik.megaco@gmail.com] Enviado el: mi=E9rcoles, 06 de junio de 2007 17:01 Para: megaco@ietf.org CC: Schwarz Albrecht Asunto: [Megaco] Reg SO,RO RTP Hello All, I have a basic doubt to get clarrifed. endpoint line/1 calls line/2 in a different gateway. Shown below are the ADD requests from MGC. T=3D41 showing ADD on originating Gateway. T=3D42 showing ADD on terminating Gateway. T=3D41{C=3D${A=3Dline/1{M{ O{MO=3DSR}},SG{},E=3D63{al/on{strict=3DfailW= rong}}},A=3D${M{L{ v=3D0 o=3Dbell 53655 53655 IN IP4 128.3.4.6 c=3DIN IP4 $ m=3Daudio $ RTP/AVP 8 },O{ MO=3DRC,RV=3DON}}}}} T=3D42{C=3D${A=3Dline/2{M{O{MO=3DSR}},SG{al/ri},E=3D64{al/of{strict=3Df= ailWrong}}},A=3D${M{L { v=3D0 o=3Dbell 53655 53655 IN IP4 128.3.4.6 c=3DIN IP4 $ m=3Daudio $ RTP/AVP 8 },R{ v=3D0 o=3Dbell 53655 53655 IN IP4 172.21.143.59 s=3DSDP from MEGACO LINE c=3DIN IP4 xxxxxxxx t=3D0 0 m=3Daudio 8000 RTP/AVP 8 },O{MO=3DSO}}}}} Clarrification: i assume that, the Originating RTP termination is requestd to of type R= O, so that before answer phase, for an unsuccesful call setup, an announcement could be played. a personalised ringback tone be applied. Question1. Are my assumptions correct? Are there any other reasons to have a receive only RTP. Question2. from T=3D42, the terminating RTP is requested to be of type SO. Please let me understand the reason behind this. Thanks and Regards, karthik Prabhu _______________________________________________ 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 bfhy@islandnet.com Sun Jun 10 16:52:54 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxUP8-0000m5-2y for megaco-archive@lists.ietf.org; Sun, 10 Jun 2007 16:52:54 -0400 Received: from [190.56.8.73] (helo=olcnxod) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HxUP7-0003Ky-9B for megaco-archive@lists.ietf.org; Sun, 10 Jun 2007 16:52:54 -0400 Message-ID: <466C64A2.6020507@islandnet.com> Date: Sun, 10 Jun 2007 22:52:50 +0200 From: Harrington Matilda User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: megaco-archive@lists.ietf.org Subject: spew bodybuilding Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.3 (++++) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 CAON Now Holds 12 Environmental Patents! Investors Respond! Chan-On International Inc. Symbol: CAON Close: $0.72 UP 4.35% CAON acquires Harbin Hongbo and its 12 patents. This company's new direction was released in a fact sheet Friday. Investors are already jumping all over it. Read the release and get all over CAON first thing Monday! The good ones, however, were pretty damn good. Experts Express Confidence in the Safety of Genetically Modified Foods Home :: Web Directory :: genetic engineering News :: Free RSS news :: Free Newsletter :: Tell a Friend Clientfinder. The GRANT statement has been greatly expanded to cover new permission options, such as the scope of the grant and whether the principal is able to grant the permission to other principals. The key to a happy relationship could be accepting that some miserable times are unavoidable, experts say. I know some games are designed to work in ultra-high resolution, but I'm still just using the same ordinary programs I've been running year after year. Jump into continuing education with LHLC Home :: Web Directory :: genetic engineering News :: Free RSS news :: Free Newsletter :: Tell a Friend Clientfinder. I know some games are designed to work in ultra-high resolution, but I'm still just using the same ordinary programs I've been running year after year. This was the Dancing Queen. Most of the old system tables, stored procedures, and views are still available for use, except that they are now all exposed as read-only views. See, 'cause it's all about duality and torment within, which I guess wouldn't be apparent to us without getting beaten over the head with it every eight minutes. Experts express confidence in the safety of GM foods Home :: Web Directory :: genetic engineering News :: Free RSS news :: Free Newsletter :: Tell a Friend Clientfinder. I've listed the Calendars Committee membership below. A descent that the annoyingly Muppet-friendly Jedi helped instigate, now that I think about it. For example, TRUNCATE TABLE requires the ALTER permission on the table, which confers the power to do more than just delete a table's rows. I'm not saying you'll never have to put effort into your marriage, but simply that it shouldn't be the defining characteristic. Genetic engineering can be seen . Gene therapy: how science moved from hype Home :: Web Directory :: genetic engineering News :: Free RSS news :: Free Newsletter :: Tell a Friend Clientfinder. When I ordered this twenty-two-incher from a reputable online hardware distributor, I thought that I had finally solved my screen management woes. Therapists from California State University and Virginia Tech University say accepting these problems is better than striving for perfection. At the most, any chance of getting ABA put back in is lost for good. Ah, what a beautiful tradition it is to speak no ill of the dead! This permission is critical for the EXECUTE AS feature I'll cover later in this article. McAuliffe's use of the epithet "Nuts! Creating an application is going to require much more detailed analysis of its security needs and careful control of permissions on all objects. I've listed the Calendars Committee membership below. And so, when KC and the Sunshine Band came on and exhorted her to shake shake shake, shake shake shake her booty, she did. Home :: Web Directory :: genetic engineering News :: Free RSS news :: Free Newsletter :: Tell a Friend Clientfinder. You must be careful, though, since the limits on metadata visibility don't yet apply to all of the metadata functions, such as OBJECTPROPERTY. Medicinal crops raise hopes, concerns Home :: Web Directory :: genetic engineering News :: Free RSS news :: Free Newsletter :: Tell a Friend Clientfinder. Granting a particular permission can convey the rights of other permissions through implication. From vqqx@ebay.ca Sun Jun 10 17:13:16 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxUiq-0003so-2d for megaco-archive@lists.ietf.org; Sun, 10 Jun 2007 17:13:16 -0400 Received: from [200.121.206.245] (helo=cnhi) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HxUin-0004Zl-Dz for megaco-archive@lists.ietf.org; Sun, 10 Jun 2007 17:13:16 -0400 Message-ID: <466C6965.4060704@ebay.ca> Date: Sun, 10 Jun 2007 16:13:09 -0500 From: Daniel L. Gorman User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: megaco-archive@lists.ietf.org Subject: hoops Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 CAON Now Holds 12 Environmental Patents! Investors Respond! Chan-On International Inc. Symbol: CAON Close: $0.72 UP 4.35% CAON acquires Harbin Hongbo and its 12 patents. This company's new direction was released in a fact sheet Friday. Investors are already jumping all over it. Read the release and get all over CAON first thing Monday! It can greet callers with your own custom voice recording and record a message that is saved as . flood watch expands A boil water advisory has been issued for areas downstream of Terrace as residents return to the flooded northwestern B. It s a little difficult to get started with, but quite flexible once you get familiar with it. To create a new virtual disk, simply insert the CD and click a button to copy the CD and create a virtual disk drive, using the drive letter you specify. CDMenuPro does not contain any adware or spyware. The program includes a button editor to create your own button designs with optional rollover and sound effects. See the numbers that Michael Bloch has posted at Taming The Beast. A-PDF Split does not require Adobe Acrobat. In addition to icon and cursor formats, it also supports editing of GIF, JPG and PNG image files. Das Wetter rund um den Wasserturm von Mannheim Seckenheim -und mehr! Always keep spare batteries on hand and remember that shiny or reflective surfaces can interfere with optical mice. In addition, PostCast can completely automate the creation of contact databases by extracting the specific data from your web forms. Bridge general manager Michel LeChasseur told CBC News every effort is being made to notify people of the changes so they can make alternate arrangements. Williams said other provinces should take heed of what happened. Blog Watch Most Blogged about CBC. The program can monitor multiple AdSense accounts, supports custom sound notifications and proxy server connections. This allows you to see which search engine is running more ads for the specified phrase. It is intended for both system administrators and users who are interested in computer security. Some features disabled. AdWords Clever Wizard does not contain any adware or spyware. Some features disabled. From frgzz@internetpromotions.biz Mon Jun 11 10:47:10 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxlAk-0006Pc-To for megaco-archive@lists.ietf.org; Mon, 11 Jun 2007 10:47:10 -0400 Received: from o244.myclearwave.net ([204.96.126.244]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HxlAh-0000wo-5J for megaco-archive@lists.ietf.org; Mon, 11 Jun 2007 10:47:10 -0400 Message-ID: <466D6053.2040506@internetpromotions.biz> Date: Mon, 11 Jun 2007 09:46:43 -0500 From: Jack User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: megaco-archive@lists.ietf.org Subject: waters cards Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 2.7 (++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Both of these wizards generate a file named SecurityConfiguration.
From megaco-bounces@ietf.org Mon Jun 11 10:58:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxlLf-0004Vk-TJ; Mon, 11 Jun 2007 10:58:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxlLf-0004Vb-7J for megaco@ietf.org; Mon, 11 Jun 2007 10:58:27 -0400 Received: from mailrelay2.alcatel.de ([194.113.59.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxlLd-0004e3-Nx for megaco@ietf.org; Mon, 11 Jun 2007 10:58:27 -0400 Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr [155.132.182.205]) by mailrelay2.alcatel.de (8.13.4/8.13.4/ICT) with ESMTP id l5BEwNlA010314; Mon, 11 Jun 2007 16:58:23 +0200 In-Reply-To: <2c04dc350706031302v37955e09n99a33b24f2388421@mail.gmail.com> Subject: H.248.4; Re: [Megaco] Megaco, SCTP and IP addresses To: "Claudio Fontana" X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Albrecht.Schwarz@alcatel-lucent.de Date: Mon, 11 Jun 2007 16:58:21 +0200 X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 06/11/2007 16:58:23 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.51 on 149.204.45.73 X-Spam-Score: 0.2 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org If such an H.248 Control Association is working, then I would agree that this configuration of the SCTP association is not compliant against H.248.4. But I'm hesitate to interprete that H.248.4 statement in that direction (due to the H.248 Control Association changeover statements in this sentence; it's also strange to put normative statements into the overview section). I may imagine that the developers of H.248.4 had the H.248 Control Association changeover topic in mind, and perhaps simply overlooked that the SCTP endpoint could be realized by multi-homed or single-homed "IP hosts". The IP multihoming approach is leading to different IP interfaces for ingress and egress traffic, thus different IP addresses (= asymmetrical IP addresses). This should be still possible for H.248-over-SCTP. Please note that IP multihoming is different to the SCTP multihoming capability. SCTP multiphoming means the support of multiple IP interfaces (one IP interface per SCTP path). Anyway, I think that current H.248.4 text make sense (due to the topic of data localization in a distributed endpoint), but I may also agree that this statement might be too restrictive for IP multihomed implementations. -Albrecht "Claudio Fontana" To: megaco@ietf.org Subject: [Megaco] Megaco, SCTP and IP addresses 03.06.2007 22:02 Hello all, I am monitoring some megaco [ver 1, BER, IPv4/SCTP/M3UA] traffic, and I see something that should _not_ be ok if I read the involved standards correctly. I see the equivalent (data changed, but meaning preserved) of these two messages on the wire, delta_t=3 milliseconds. No ServiceChange or Notify between the two. [message 1, Transaction REQUEST, tid=0x155d3327 ctxid=CHOOSE] mid: 10.5.100.22/2945 ADD REQUEST ip/sctp src: 10.5.100.22/2945 dest: 10.5.100.1/8009 [message 2, Transaction REPLY, tid=0x155d3327 ctxid = 0x0220c197] mid: 10.5.100.1/8009 ADD REPLY ip/sctp src:10.5.101.1/8009 dest: 10.5.101.22/2945 Now, H.248.4 says in the overview that for SCTP "Responses must be sent to the address and port from which the corresponding commands were sent, except if the response is to a handoff or failover, in which case the procedures of 11.5/H.248.1 apply." This is not the case with the traffic I am seeing here. Is there some exception I should know of, or is this simply wrong? Thank you for your kind advice, Claudio Fontana _______________________________________________ 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-bounces@ietf.org Mon Jun 11 13:19:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxnXt-0000nK-5K; Mon, 11 Jun 2007 13:19:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxnXr-0000d5-5r for megaco@ietf.org; Mon, 11 Jun 2007 13:19:11 -0400 Received: from an-out-0708.google.com ([209.85.132.243]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxnXo-00032E-Up for megaco@ietf.org; Mon, 11 Jun 2007 13:19:11 -0400 Received: by an-out-0708.google.com with SMTP id c17so364251anc for ; Mon, 11 Jun 2007 10:19:08 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=T/5DHt3E1qW0hcxjhQIoshJOCCVzg5wnEKlZIdjglX5Clk8XZyvUGlMvJDFfTDjxEwBqghqjI6oNuI87b2vbPTtqALGmPsHSWpk1kmZqCDSYYPT+MYIl4iH10Cmv0AM0sGZ7SbwLtpWcdcpf8ivBauxxvJsjiDMtV3Dq5RqHhEE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=swD+viZJAW/kCOCmQuqOVP9v5CqlZ/0N08eBJlTuor6+GMdejYRoPE9LDEftF4JIF5uQgsWNQ7aKVBa5jY2Q2nubN65YbNAG1cWcA/pd4kbu4bbIAFuJJaKAf2i5eN1Lx9Ll8+jhQgRlRnlMhHoQMc36b1PimAX6NOZa3P4YEwU= Received: by 10.100.178.7 with SMTP id a7mr3486082anf.1181582348470; Mon, 11 Jun 2007 10:19:08 -0700 (PDT) Received: by 10.100.153.14 with HTTP; Mon, 11 Jun 2007 10:19:08 -0700 (PDT) Message-ID: <2c04dc350706111019l3b0acabdl1e48d18c0c2fcfc1@mail.gmail.com> Date: Mon, 11 Jun 2007 19:19:08 +0200 From: "Claudio Fontana" To: "Albrecht.Schwarz@alcatel-lucent.de" Subject: Re: H.248.4; Re: [Megaco] Megaco, SCTP and IP addresses In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2c04dc350706031302v37955e09n99a33b24f2388421@mail.gmail.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Hello, thank you for your answer. On 6/11/07, Albrecht.Schwarz@alcatel-lucent.de wrote: > > If such an H.248 Control Association is working, then I would agree that > this configuration of the SCTP association is not compliant against > H.248.4. > > But I'm hesitate to interprete that H.248.4 statement in that direction > (due to the H.248 Control Association changeover statements in this > sentence; it's also strange to put normative statements into the overview > section). If the overview is not normative, maybe I should just ignore it completely since it just confuses me. full text is available from ITU-T in pdf format at http://www.itu.int/rec/T-REC-H.248.4/en > I may imagine that the developers of H.248.4 had the H.248 Control > Association changeover topic in mind, and perhaps simply overlooked that > the SCTP endpoint could be realized by multi-homed or single-homed "IP > hosts". If so, this is a pretty bad overlooking though. I'd ask them (ITU-T I think) about it, but their mailing lists are not open for non-TIES members. > The IP multihoming approach is leading to different IP interfaces > for ingress and egress traffic, thus different IP addresses (= asymmetrical > IP addresses). > This should be still possible for H.248-over-SCTP. > Please note that IP multihoming is different to the SCTP multihoming > capability. SCTP multiphoming means the support of multiple IP interfaces > (one IP interface per SCTP path). Yes. > Anyway, I think that current H.248.4 text make sense (due to the topic of > data localization in a distributed endpoint), but I may also agree that > this statement might be too restrictive for IP multihomed implementations. > > -Albrecht I am not sure I understand you here, or how current H.248.4.1 can still make sense. You mean that it would be good for associating values unique to a logical megaco entity, but it is not done in practice? Thank you very much for your help, Claudio _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Jun 11 14:03:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxoEQ-0007Ua-MA; Mon, 11 Jun 2007 14:03:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxoEQ-0007UV-8Z for megaco@ietf.org; Mon, 11 Jun 2007 14:03:10 -0400 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxoE9-0002QN-5r for megaco@ietf.org; Mon, 11 Jun 2007 14:03:10 -0400 Received: by ug-out-1314.google.com with SMTP id j30so291588ugc for ; Mon, 11 Jun 2007 11:02:51 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type; b=IcGodnEjVyuC9W/GibgtnOk3rB3M0YL05smP1rQS14tGgG6oW3tiiI9o9CzHfzyTQc8zgbJppgRJAlhWJSFX2TQ3PfH/pcMZnOvee2b6BdU5q9ZruRvCJ8WMmDTfq4aEL4nmqcfyn6KapMb3MIXOncf/FAi/tShuNBZXiOWIaVA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type; b=RaHenwvg2Pikzq/BPSO7Xecwb3ZKq3cNVSZ8Y283gWHOXbtv9n7YM3DTp35i19fo7uXXguQ1oyYXr1aCDoFXKfRcghi6rhoCIfXaq0ETAC16UW2QMi9jOvyEeyPqil/pZWBAGJHhj98EeSzGii6Pq26cpYy8loLM2Uu3zvKTXE4= Received: by 10.78.131.8 with SMTP id e8mr2340461hud.1181584971412; Mon, 11 Jun 2007 11:02:51 -0700 (PDT) Received: by 10.78.121.12 with HTTP; Mon, 11 Jun 2007 11:02:51 -0700 (PDT) Message-ID: Date: Mon, 11 Jun 2007 23:32:51 +0530 From: "P C Aanandh" To: megaco@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Subject: [Megaco] How to handle Digit Map start timer timeout? X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1500370532==" Errors-To: megaco-bounces@ietf.org --===============1500370532== Content-Type: multipart/alternative; boundary="----=_Part_54022_28796563.1181584971132" ------=_Part_54022_28796563.1181584971132 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all Please help me to handle the digit map start timer ( T ). here is the MGC command for ADD. T=10407{C=${A=tp/0001{M{O{MO=RC,tdmc/gain=0 }}, E=22890{al/on{strict=state},g/sc,xdd/xce{bc=60,mp=enhanced,xdd=on, DM={T:20, S:4, L:16, (1|2|3|4|5|6|7|8|9|0|E|F|A|D)}}},SG{cg/dt}}}} Thanks Aanandh P C ------=_Part_54022_28796563.1181584971132 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all

Please help me to handle the digit map start timer ( T ).

here is the MGC command for ADD.

T=10407{C=${A=tp/0001{M{O{MO=RC,tdmc/gain=0 }},
E=22890{al/on{strict=state},g/sc,xdd/xce{bc=60,mp=enhanced,xdd=on,
DM={T:20, S:4, L:16, (1|2|3|4|5|6|7|8|9|0|E|F|A|D)}}},SG{cg/dt}}}}

Thanks
Aanandh P C ------=_Part_54022_28796563.1181584971132-- --===============1500370532== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1500370532==-- From Lizzieturneryturnery@thepotteries.org Tue Jun 12 02:34:17 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxzxJ-0004aa-Hq for megaco-archive@lists.ietf.org; Tue, 12 Jun 2007 02:34:17 -0400 Received: from cpe-76-188-87-61.neo.res.rr.com ([76.188.87.61] helo=inaudible) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HxzxH-0006lg-Vo for megaco-archive@lists.ietf.org; Tue, 12 Jun 2007 02:34:17 -0400 Received: from lumberman by thepotteries.org with SMTP id q6FVqtQrAG for ; Tue, 12 Jun 2007 02:32:29 +0500 From: "Shana Oakes" To: megaco-archive@lists.ietf.org Subject: Want to pay out less than before? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 4.2 (++++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 As a business you have been preapproved to receive 47411 USD TODAY! No hassle at all, completely unsecured. There are no hidden costs or fees. Worried that your credit is less than perfect? Not an issue. Give us a ring, now.. +1-877-482-4956 Turn your dream, into a reality, is that not worth two minutes of your time? +1-877-482-4956 He must have been the one with whom she had gone to the movies and seen the chapter-plays. I repeat, a tomado watch - But it was time to stop playing games and get down to business. Petra Bautista From ukgz@medfordpolice.com Tue Jun 12 05:55:06 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy35e-00010Z-3x for megaco-archive@lists.ietf.org; Tue, 12 Jun 2007 05:55:06 -0400 Received: from [196.205.132.172] (helo=host-196-205-132-172.static.link.com.eg) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hy35c-0007an-AI for megaco-archive@lists.ietf.org; Tue, 12 Jun 2007 05:55:06 -0400 Message-ID: <466E6D4D.8070302@medfordpolice.com> Date: Tue, 12 Jun 2007 12:54:21 +0300 From: Frances I. Hicks User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: megaco-archive@lists.ietf.org Subject: opposed chalkboard Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.8 (++++) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e News Hits! New R&D Facility Engaged! Chan-On International Inc. Symbol: CAON Close: $0.73 News hits today on CAON and trading continues to warm up. Hitting highs of $0.90 today, we can see this building. Read the release and get on CAON first thing Tuesday. We can see this climbing all week! The Gyrfalcon can fly down even the fastest waterfowl in a direct sprint. Learn more about this Spotted Towhee at BirdWeb. Learn more about this Mute Swan at BirdWeb. Internet Marketing by Portent Interactive Learn more about the amazing, sinking Pied-billed Grebe at BirdWeb. Even though both parents are hunting for and feeding them, such large birds grow slowly. For information about sageland conservation, click here. Long-necked and long-legged, this grayish crane stands three feet tall. For a map to their wintering area on the Skagit Flats, click here. When the weather is good, the trip is easy. And visit SoundTracker. These daring blue dandies sound the alarm in evergreen and mixed conifer forests, parks and yards. Learn more about these birds at BirdWeb. The male is dressed for defending his territory and attracting a harem; she, for blending into the cattails. Look for the ruby-red eye that sparkles from its black head. In April, watch for Pigeon Guillemots bobbing in the water near Puget Sound ferry docks, diving for food off rocky beaches, or perching outside their bluff burrows. Pairs raise young whenever sufficient food is available, mostly between February and July, sometimes having as many as three broods per year. He takes off and flies over her with head held low. From their Arizona breeding grounds, they head northwest in fall, rather than southeast to their usual wintering haunts in Mexico. The male is dressed for defending his territory and attracting a harem; she, for blending into the cattails. Today the American and British Ornithological Unions work together to determine, among other things, how a given bird gets its name. Join BirdNote and Black Hills Audubon on a field trip to Nisqually Refuge this Saturday to see for yourself the bountiful populations of ducks and geese. In April, watch for Pigeon Guillemots bobbing in the water near Puget Sound ferry docks, diving for food off rocky beaches, or perching outside their bluff burrows. You can even send pictures for the gallery. Note the difference between the bill and legs of the Arctic Tern on the bottom here to those of the Common Tern on the top. His wings droop, but the neck tufts are erect, looking almost like horns. And visit SoundTracker. Learn more at BirdWeb. The New Zealand dollar is even nicknamed "the Kiwi. For conservation at Seattle Audubon, click here. But there is still much we can do. When you hear their chorus, be assured that our summer birds will soon arrive. It is found throughout the Caribbean, in the Galapagos, and from southern Europe across Africa to India. This behavior led to the wryneck being invoked in witchcraft to put a spell or a jinx on someone. Redder males also attract females in better condition, and such a pair raises, on the average, more young. Where most woodpeckers are a reliable mix of black, white, and bits of red, the Northern Flicker is buffy tan overall. The pairs use song to stake out and hold breeding territories. Join BirdNote and Audubon volunteers on a field trip there on Saturday. Note the difference between the bill and legs of the Arctic Tern on the bottom here to those of the Common Tern on the top. Learn more about the bird at BirdWeb! Learn more on BirdWeb. They come in search of fruit to sustain their winter wanderings. After landing, he thrusts his head forward and raises his wings sharply behind his head. It can mimic everything from other birds to inanimate objects. To see a whole flock of Sanderlings, click here. Learn more at BirdWeb. Learn more at BirdWeb. The Gyrfalcon can fly down even the fastest waterfowl in a direct sprint. Even though both parents are hunting for and feeding them, such large birds grow slowly. Their rhythmic drumming functions like song, to broadcast over a long distance a clear statement of territory and mating rights. For Earth Day celebrations, click here. This behavior led to the wryneck being invoked in witchcraft to put a spell or a jinx on someone. The emperor asked her to stay with him, but she knew her song sounded best in the green wood. And it may just feel good, too. These winds create upwelling of cold waters from deep in the ocean, waters rich in nutrients and food. To see the difference between a Steller's Jay and the true Blue Jay, click here. The New Zealand dollar is even nicknamed "the Kiwi. Unlike many other bird colors, blue is not a pigment but a color produced by the structure of the feathers. org, all rights reserved. And together they can tap a wider range of resources. From megaco-bounces@ietf.org Tue Jun 12 05:58:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy39D-0002IL-FE; Tue, 12 Jun 2007 05:58:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy39B-0002IC-PT for megaco@ietf.org; Tue, 12 Jun 2007 05:58:45 -0400 Received: from mailrelay2.alcatel.de ([194.113.59.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy39A-0008Ng-88 for megaco@ietf.org; Tue, 12 Jun 2007 05:58:45 -0400 Received: from demail05.netfr.alcatel.fr (demail05.netfr.alcatel.fr [155.132.182.205]) by mailrelay2.alcatel.de (8.13.4/8.13.4/ICT) with ESMTP id l5C9wf5w027698; Tue, 12 Jun 2007 11:58:41 +0200 In-Reply-To: <000c01c78b00$b93c34e0$0201000a@ad.uk.neceur.com> Subject: RE: [Megaco] Handling of terminations for call forwarding scenarios To: "Colin Smith" X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Albrecht.Schwarz@alcatel-lucent.de Date: Tue, 12 Jun 2007 11:58:39 +0200 X-MIMETrack: Serialize by Router on DEMAIL05/DE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 06/12/2007 11:58:41 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.51 on 149.204.45.73 X-Spam-Score: 0.2 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Collin, sorry for late response. I'm not really familiar with tele- and supplementary services, but when you look for a NGN scenario, when perhaps following TISPAN docs may help: Pre-mark: "call forwarding" may be realized in NGN as simulation service, and is then called as "communication forwarding" in my understanding. And "communciation forwarding" belongs to the category of "communication diversion" (CDIV) services. 1) Requirements (concerning SIP), see (latest draft): http://www.potaroo.net/ietf/idref/draft-jesske-sipping-tispan-requirements/ 2) Protocol, latest draft: WI03115 ETSI TS 183 004 PSTN/ISDN simulation services: Communication Diversion (CDIV); Protocol specification see: TISPAN temporary document 13bTD498 -Albrecht "Colin Smith" om.co.uk> cc: megaco@ietf.org Subject: RE: [Megaco] Handling of terminations for call forwarding scenarios 30.04.2007 10:22 Albrecht, Thanks for the quick response. Prior to my e-mailing the Megaco group I had searched the TISPAN and 3GPP standards for an answer to the forwarding conditions at the MGCF. Unfortunately TS 29.163 and others do not yet extend to cover the forwarding cases - possibly because CDIV remains fluid in the standards? A further reasonable assumption I have to make is that the trigger for the subtraction of the forwarding termination is the receipt of the 181 response code at the MGCF - does this make sense to you also? Having gone so far to fill what appears to be a gap in the definition, would it also make sense to document our discussion publicly and submit to the appropriate body for consideration? Cheers, Colin Smith 21COM Systems Tel: +44 7782 333 314 ************************************************** The contents of this email are intended for the use of the individual(s) or entity named above and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are not authorised to make any use of it. In such case, please notify the sender and immediately delete the message from your system. The message content may contain personal views which are not the views of the company unless specifically stated. All liability for loss or damage caused by viruses is excluded. 21COM Systems Limited | Registered Office: 10-12 Dunraven Place Bridgend CF31 1JD | Registered in England 3238787 -----Original Message----- From: Albrecht.Schwarz@alcatel-lucent.de [mailto:Albrecht.Schwarz@alcatel-lucent.de] Sent: Friday, April 27, 2007 4:42 PM To: Colin Smith Cc: megaco@ietf.org Subject: Re: [Megaco] Handling of terminations for call forwarding scenarios Colin, see my responses inline. Albrecht "Colin Smith" om.co.uk> cc: Subject: [Megaco] Handling of terminations for call forwarding scenarios 26.04.2007 17:06 Hi, I would appreciate your insight into the correct procedures to be followed in managing terminations for PSTN-originated calls that have been forwarded from the IMS domain to the PSTN. My thinking is that, since the SIP session remains the same, the existing context should be maintained. [ABS] Yes. Also because the half call from PSTN-originated side may remain in the context ("no need to move that TDM Termination to a 2nd context"). The termination representing the forwarding leg should be subtracted and on receipt of the re-targeted INVITE a new term added to reserve the PCM resources out to the PSTN for the forwarded leg. [ABS] Yes. The ephemeral Termination is subtracted and a new TDM Termination is added. Does this align with the procedure you envisage or do you have an alternative proposal? Is there documentation any where that references the correct procedures in this instance? [ABS] Don't know. You may have a look at TISPAN IMS or 3GPP IMS specs, perhaps 29.163 could be a starting point ... Cheers, Colin Smith 21COM Systems Tel: +44 7782 333 314 ************************************************** The contents of this email are intended for the use of the individual(s) or entity named above and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are not authorised to make any use of it. In such case, please notify the sender and immediately delete the message from your system. The message content may contain personal views which are not the views of the company unless specifically stated. All liability for loss or damage caused by viruses is excluded. 21COM Systems Limited | Registered Office: 10-12 Dunraven Place Bridgend CF31 1JD | Registered in England 3238787 _______________________________________________ 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 phukq@pop06.odn.ne.jp Tue Jun 12 07:26:52 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy4WS-00023p-1y for megaco-archive@lists.ietf.org; Tue, 12 Jun 2007 07:26:52 -0400 Received: from p57b5e07e.dip.t-dialin.net ([87.181.224.126]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hy4Rw-0003ok-IA for megaco-archive@lists.ietf.org; Tue, 12 Jun 2007 07:22:14 -0400 Message-ID: <466E81E0.4010300@pop06.odn.ne.jp> Date: Tue, 12 Jun 2007 13:22:08 +0200 From: Elmer Rhodes User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: megaco-archive@lists.ietf.org Subject: As a library registrant, you will receive a complimentary subscription to the TechRepublic member newsletter. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.6 (+++) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a News Hits! New R&D Facility Engaged! Chan-On International Inc. Symbol: CAON Close: $0.73 News hits today on CAON and trading continues to warm up. Hitting highs of $0.90 today, we can see this building. Read the release and get on CAON first thing Tuesday. We can see this climbing all week! One month after the treatment, tests showed that some of Caleb's hearing irregularities had balanced out. Proprioceptive awareness is still pretty tough for Caleb. The card had no lines on it, and he wrote more neatly than he did on those sentences last month. Following a controversial fake blood study, the FDA heard testimony last October about loopholes in informed-consent regulations. Already registered on BNET, TechRepublic, or ZDNet? "I don't think we'll find the answer to obesity in a pill," said Sandon, who is also a spokeswoman for the American Dietetic Association. The Visual-Motor Visual-motor skills help us translate what we see into appropriate motor responses. But it's difficult to get people to care. The month-long Sensory Learning Program in Boulder, Colorado, was designed to recalibrate Caleb's reception of sensory input, reorganizing the neural pathways that process information. From rbykivn@tvcconnect.net Tue Jun 12 15:30:53 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyC4q-00031J-U2 for megaco-archive@lists.ietf.org; Tue, 12 Jun 2007 15:30:53 -0400 Received: from [216.255.171.224] (helo=host171-224.defiant.tvcconnect.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HyC4o-0008TK-Fj for megaco-archive@lists.ietf.org; Tue, 12 Jun 2007 15:30:52 -0400 From: "Insert" To: megaco-archive@lists.ietf.org Subject: Best medicines with best discounts over the world! Date: Tue, 12 Jun 2007 15:31:00 +0400 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0005_01C7AD06.AE25CB70" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcetBq4lSGMjyX1LTry2SGNRFeRhlA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: X-Spam-Score: 1.4 (+) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 ------=_NextPart_000_0005_01C7AD06.AE25CB70 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0006_01C7AD06.AE25CB70" ------=_NextPart_001_0006_01C7AD06.AE25CB70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit McGraths stable joins flawed ethics Targeting Providers Regions Localized ------=_NextPart_001_0006_01C7AD06.AE25CB70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

McGraths stable joins = flawed ethics

Targeting Providers Regions = Localized

------=_NextPart_001_0006_01C7AD06.AE25CB70-- ------=_NextPart_000_0005_01C7AD06.AE25CB70 Content-Type: image/gif; name="pic01.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdh9AASAYcAAAAAAIAAAACAAICAAAAAgIAAgACAgMDAwMDcwKbK8EAgAGAgAIAgAKAg AMAgAOAgAABAACBAAEBAAGBAAIBAAKBAAMBAAOBAAABgACBgAEBgAGBgAIBgAKBgAMBgAOBg AACAACCAAECAAGCAAICAAKCAAMCAAOCAAACgACCgAECgAGCgAICgAKCgAMCgAOCgAADAACDA AEDAAGDAAIDAAKDAAMDAAODAAADgACDgAEDgAGDgAIDgAKDgAMDgAODgAAAAQCAAQEAAQGAA QIAAQKAAQMAAQOAAQAAgQCAgQEAgQGAgQIAgQKAgQMAgQOAgQABAQCBAQEBAQGBAQIBAQKBA QMBAQOBAQABgQCBgQEBgQGBgQIBgQKBgQMBgQOBgQACAQCCAQECAQGCAQICAQKCAQMCAQOCA QACgQCCgQECgQGCgQICgQKCgQMCgQOCgQADAQCDAQEDAQGDAQIDAQKDAQMDAQODAQADgQCDg QEDgQGDgQIDg(��ZW�0��h��0��L��gAAggCAggEAggGAg gIAggKAggMAggOAggABAgCBAgEBAgGBAgIBAgKBAgMBAgOBAgABggCBggEBggGBggIBggKBg gMBggOBggACAgCCAgECAgGCAgICAgKCAgMCAgOCAgACggCCggECggGCggICggKCggMCggOCg gADAgCDAgEDAgGDAgIDAgKDAgMDAgODAgADggCDggEDggGDggIDggKDggMDggODggAAAwCAA wEAAwGAAwIAAwKAAwMAAwOAAwAAgwCAgwEAgwGAgwIAgwKAgwMAgwOAgwABAwCBAwEBAwGBA wIBAwKBAwMBAwOBAwABgwCBgwEBgwGBgwIBgwKBgwMBgwOBgwACAwCCAwECAwGCAwICAwKCA wMCAwOCAwACgwCCgwECgwGCgwICgwKCgwMCgwOCgwADAwCDAwEDAwGDAwIDAwKDAwP/78KCg pICAgP8AAAD/AP//AAAA//8A/wD//////ywAAAAA9AASAQcI/gDtCRxIsKDBgwgTKlzIsKHD hxAjSpxIsaLFixgzatzIsaPHjyBDinRYa6TJkyhTqlzJsqXLlzBjypxJ86O/mjhz6txpMAPP nw4BAACaUCjRozGFKhVodGXTikafBh2qshxSlVKHSkV4p+NWiV+nXj2qjmJWe1GfKqXKtGla tmsHLkUbt+Baqm/b0t07l65atmMDN/w6N61etHoLa8W7mOlhu3AXM+YrOfHkvYIzLyQcGfNW w5ZDEwz7FzPl06LdAtbMevRq028VLy19l3Fng7Q7G85dN2xrzWdzQxaNGvfl4cR3Nyb+u/nB 4Lrhel5eXOth0tHlNgZd/bHz1ncf/qv+Ozt8W/KuX5sXzn387e/wMfrWnCC+/Yfz7+vfz7+/ //8s7QDggAQ2QeCBLRmD4IIMNujggxBGKOGEFFZo4YUYZqghUQZu6OGHIIYo4ogklmiiRMOc qOKKLLbo4lGHHHKRjCG9JpKN/tE4kIw6ahRjjArp2OOOP/540JBeYZWejb2ZB2NBSGLUY5QC CZmQKVRWeWNKhY1ml5c4PqmlPTQaWWWRZKZJJpBQHmlmkWgeCSWbPLK5ZpZ+abeabXjJ5Sdk kamHmKBe+hkmUVaquaOiadq5KEFITjkmowZRWeeieOKG2HObOiadYwhZF2qnXxbqaV1XJTok j5BSOimR/3S2qiieljLKKn6kglmodaKOeihpmv5pKlK3qommpFOaiVCxxj667JxASrrmZopp ClifvD5XbajXMjksqKnOKi6yztJq66Tmlnuus8GSuqe7ng7a7rW+gtturvgCVey+s/L76rnS JvqsutL+ayq9ugr7aanwfpltsPQiPFbAMTpxJqvJOnqxkMomOzCsdb6psXF5lYpqpzjG1Reg 53XZsp6HwpfpizFHGOeLCtWMc0h/7Ozzz0AHLfTQHuHBER5GW5Q0gDrbhzTS9iTNBUFGL43Q 01YbtHTWAmH99EFc89ctduQ1LVPYWjNkNdpRD8R22wm9HZ/L9sIr8U9cJ/112/56Q0012Ht7 vXfaVPtdtd9RI97cw9/eXfdOeRdUNd9XE9715ZhXDnbibsM996a+MGwvoUBF/vfkbGOdOdxb K4T25J3LDdyehB2cX02mqw674puvnfnbWev+N+f2AQto7URF3jrsq6ftu+fAD09559TD16uw nIqOt+TQT9+878+3Hrf0zHtu/rwKpw/uwuyrn2+2CBPqON5f9w016rx3Pbjqq+f/ff38G9yo 1ue+9hHwgCjDXnpgprCsrIxo/zEbBCckwQla8IIxgQQGN8jBDnpwcQdalas+iK+UreyBPBEh CUmmp+yBqoIyUdXFQIaxGeKMce9LWGBk2CpkReqGJf504aBOpq9HiZBcldoZ8kjWJwX+xF/H 6iGklEWzd93rejB0Cb+shERxKbFhosNiuLiIKSJ5cYQFTCMCDZjANaqxjXBko7fE+KeIfauI RhRZDUGWszfK0Y+AdKMg4+g+lrWsiX4JVBYndsFFAuhmE3TkCidJyUpa8pKYZInsOqJBCUmS NcJzHgfHZkJFjmWTm/wZ3YI4rE+iJHeGY53/vni9upEuXzoxXey8t5NfWA+XtFulK0+iy8uh 7ir9WJy3wgjG0hFOeH1zUSIY4kAh8mmYJlHeLp9HNFGFaX7YzCb3lme+t/1xkOckJDoDqc52 zlFeEGtcYEIJzcTJLZ34ZP9nPtfJz3Yasjbr6wsKMzmWcBI0MwYlaH0OytCGOrQg4XioREWU 0FRRkZK3XNK9xGSwDwqUNCkaXUVFEqU4HctOF2URDmsmnZGG5IdlRFebaMbKPm7KpS99kxRl KqsqbjSej2NkF1WVUpVaUVswu90TAUYwdrmIjj91Ih61NNSYorGf+3SnPrfaT13dDZFCJFbH dMpTSKIPq1zVKlrXCsyyNRGgd5yoTnAqV5zQta54zate98rXvtp1QV7LZEYZ+LKrcBOj6Lli M525Tf0ZLnCI45+KVmrNxW4vdnqT3vnKp9Ka2kMeo7MsT8BXve6NU4mDtVtcIRfA0mbWbfXz 2Wf+uCUbpdJEl+GrHmdbBNWEMCKqkLMcaXV7vqKkNavIPe4bvdrKn971aJazp/2m61hzKpet ycVuIRd4yICOza9/Be/nxEve8pr3vAwKw0QWit4IImhmSbzqFwm7pLOEiyLwNSpYf3UeRkKr TGWMYplGViIcBtWWDdnCTFRI1ZjS6Akjy6+GailVBB/kBTphcLMAfMaeTnaZYcXlTlYFpwY3 61VmPVE1jau9qXb0Vhw+o4Q35M3NhHipHhZYjHVsU7X6OLs/vq7D4MlM4I7YpFTUMbNSfDAh A/nJaf3nepzopAH5EmjPbW+NtMzlLnv5y2AOs5g9mMqJlFmTF5klYxv+cliRnNkhrzUzbOeM EdmlDs36ozPxilvm3b2yaM17SCyn9+bNLeTOKhm0nzMbtj6zrs7UrW7hDgdbRue5cNKls2SH Z+lyBk6WW4st5gBoz0mXmpfi+7Qx+TzqR3dacvsLtTEPp2Y4d098rfYepR9NPVzr+pmrLidm f3dre3QD1YGO865PR+zlNbrVRvtENJfd7P4RurQQEfWvex1sXQtQ2Y41LaeDzU3mkbPb5fM1 r3m5y2J3m3uutnacbw3ZY4o72+i+92vNfW9uk7vfvPYzcXHN73Nb29/s/ne+XwdteR8c2ZQD d3EPfb9efzvXqg43s0dd8f9F89KVnnesH0v/8lmXe9DRHfluTx3Zk8Mb1OF+9bwrVGg8g7nm iR6zznd+lCy3eJEVHKbPIzL0Ih+YxattboXv2FsKB13EPWYpS0Yqdew9HSxK77Ghst5iG5tl 6WAHCdUHEy+UDXQ2eZLX2ctuSrV396Zwv2mTyBYVeKJKZWhfWGGJ2MbeMBdMZXvZR9VCdruH tpUthU083wr4sr+Q7Y4ncq7s6BYdpk/vCJz81jd/KuNwnsiJr2Pha7zYr0pefnG3Y+QZz3rL H9XtoSUdtlwIzrivPoef71XoH0/NBF5TPfs9vbU2r3rhgx7uEauyahVZd4bN/qyPI/3tQSz8 9sG1aaU5uuuNjxzF/nMeqtmvvtYZN9hPURiOQQx+8Ztb/N0nXXt6T9ny43rU9ptdgbtvvoX5 gn6nb7eQINZ+57d+upd7RBdGKCRMQzRQmkdY5qd/9ddffKIt8KNRhcV/R+ceA3SBeVdZiSRI dzcTRQceGTGCCAUiQodB7MBzLNiCLviCMLiB1DQ/THR1FoF6XIJ0WZSCH2GDM/h+hxcUWyKC RFiEZPeAS/RCgycZEyh5vieBHwh4z3d3GliBtSV3lZeA/SWFDvhA3rSEYvQwVMiAnOJ+ryd+ ztd4aUhHTNJS6tc42GJ+Bkh4lucaBvgAbRh727ccBIgryCdPewh9Tkh8DUN9BWiATRY//3Mo T/KHiAEYiFsXf6K1gZTFiHXYf8CUeoynWMx3GRMZ��@�� !�L�!This progrjIfoi5e3K4uIf4B4e7i3 ixjIf8aoHdonUheYVBYYhdNReZSYdrdxTSI1Hgzkhif0heCIYFpYR+mIgOhhG7DHgc1nghQR Cx4BVvnYH/a4H5iXJGMBWn4YgwRZkAaJFBh2kBjBD/zwEgypEA8pZhHJERMJkQ1ZkQOBkQmh kRaJEBw5QR9pESFJECM5kiLZkAdhkj7DkCyJki2JkiR5kRP5kv8CQZMF0ZL28JARiZM7CZMG wZI5CZM96ZI4GZNA2ZNBGZRCCZQiMpMymZE+qZQ1+ZRTWZU/6ZM6SZVVaZJZCZVJmZNWeZVe mZRM2ZVfCSJOeZYYmZZpeZYx+ZZmOZUqGZdxGZY3uZRbiZdIGSJsiZdvmZdjyZEV2ZWDqZJk 6ZdM6ZZ/KZdE6ZUvGZUb0pdjOZl02Zhi6ZhaqZSQKZZtaZUfWZh7eZgmMpRqGZWS6ZmbWZii iZmTyZpSaZmfaZp+uZpg2ZRmaZOLyQ81wJhYqZE8SZW/WZM6YJeoCZygmZKd+ZhQaZjl5Zub mRGqSZCQyZwTEZ0KSV5PcJ3a6SD5kA//KeGdBgGeJ9Gd9kCe5LkQ51kQ6fki60kQ69meEiGe 7vmd3mme8okQ8Fme99ki+amf7rmfEAGgAGoS9skQ+dmfKmKf59mdDKqfDaqg/3kQAioQCiqf DAqe6SmeBdqgFFqfHtqh8FmhHToQCCoiHOqfKDqiIKqiKUqiEkqiGYqhMoqiHAqhNPqhBUqh 6hmjN+oi7zmjMBqkQhqiL8qi/smjR5qjP5qkTIqfFoqjA1oiS9qiSGqk4VmkVOqhFzqj9dmj QbqhWhqiT+qgUSqlY5qlQmql83mladqkO1qecLqgYwqmINqeS3qhODOlU4qmLQqnbGqkObqj IoqmdBqhbsqk/yU6Inp6pilapX6qnm86pBqaplUqp4gqqYQKpCyypyf6oFtqqDr6p4CqoSfa qKSKpyM6CR9Kpl86p6T6QYkaqpAqErFqXrU6oRHBAgFapuhVqy7hq9sZrMI6rMRarM3hCcaa rMq6rMpqnScJndTpENH6EdOKnBv5nCNRrW6prZf5rB7BrRcRmhVRl8T5EOA6rr0JrQuJrd66 EuJKESHJreCalc65lEP5lERpr3JplPpKlneZr3AJsKKpk/y6lfs6sAJblhdplJq5nIx5lfgK sO+qsKQplf7qkRFrrYQZsRtbmpyZrkUJmGuZsR0bsghbsiSrlzIZnShLmx5bmYrZsslISa/Y 2rEFK7P2Gpoj+5XBeZcui7BA65y0ibPFSa48y7E2G5ZJa7K8CbSamZkam5lEC7M+a5dE67NG q7BBO50ZC5hPC7Lp6rVJ67KSeZqtabPOGrUxS7H5KrVHWbHLmbOKebCC2a8NW6+WebBHq7c9 u7e3+bZr27WAm5RJELerea9z+yDn2hKLy1CN667MGrmSO7mUW7mWu51vcLmau7mc27me+7mg G7qim1erMLqme7qom7qqu7qs27qu+7rNwV6wO7u0W7uuGxAAOw== ------=_NextPart_000_0005_01C7AD06.AE25CB70-- From megaco-bounces@ietf.org Tue Jun 12 18:35:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyExi-0000sF-Sx; Tue, 12 Jun 2007 18:35:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyExi-0000s5-AO for megaco@ietf.org; Tue, 12 Jun 2007 18:35:42 -0400 Received: from mx2-012.rad.co.il ([212.199.240.16] helo=antivir2.rad.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyExg-0006DX-Ty for megaco@ietf.org; Tue, 12 Jun 2007 18:35:42 -0400 Received: from exrad3.rad.co.il (HELO exrad3.ad.rad.co.il) ([192.114.24.112]) by antivir2.rad.co.il with ESMTP; 13 Jun 2007 01:35:35 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Jun 2007 01:35:35 +0300 Message-ID: <457D36D9D89B5B47BC06DA869B1C815D036261FF@exrad3.ad.rad.co.il> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Remote desc in the reply to the MGC Thread-Index: AcetQKnGWAXEBcPgQdiOTWj6OT5Zww== From: "Ron Gilaad" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Subject: [Megaco] Remote desc in the reply to the MGC X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0092094090==" Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============0092094090== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7AD41.FE43B580" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7AD41.FE43B580 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All If the MGC request the MG to create media and includes both Local and Remote desc in the request, shall the MG include both desc in the reply or only the local desc? In H.248 it is written that: The MG returns its selected alternative in each of Local and Remote. But, in the example in page 175 (when the MGC associate A5555 with a new context on MG2, and establish an RTP Stream) the MGC sends both local and remote desc, but the MG reply only with the local. Thanks in advance, Ron Ron Gilaad RAD Data Communications. 24 Raoul Wallenberg St. Tel Aviv 69719 Tel: 972-3-6455411=20 mailto:ron_g@rad.com ------_=_NextPart_001_01C7AD41.FE43B580 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Remote desc in the reply to the MGC

Hi = All

If the = MGC request the MG to create media and includes both Local and Remote = desc in the request, shall the MG include both desc in the reply or only = the local desc?

In H.248 = it is written that: The MG returns its selected alternative in = each of Local and Remote.

But, in = the example in page 175 (when the MGC associate A5555 with a new context = on MG2, and establish an RTP

Stream) = the MGC sends both local and remote desc, but the MG reply only with the = local.

Thanks = in advance,

Ron

Ron = Gilaad

RAD Data = Communications.

24 Raoul = Wallenberg St.

Tel Aviv = 69719

Tel: = 972-3-6455411

mailto:ron_g@rad.com

------_=_NextPart_001_01C7AD41.FE43B580-- --===============0092094090== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0092094090==-- From megaco-bounces@ietf.org Tue Jun 12 21:05:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyHIf-00038C-Ni; Tue, 12 Jun 2007 21:05:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyHIf-000387-82 for megaco@ietf.org; Tue, 12 Jun 2007 21:05:29 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyHId-0001xp-UM for megaco@ietf.org; Tue, 12 Jun 2007 21:05:29 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 3C0837169FB; Tue, 12 Jun 2007 18:05:27 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25979-08; Tue, 12 Jun 2007 18:05:27 -0700 (PDT) Received: from [155.53.44.239] (cologne.redback.com [155.53.44.239]) by prattle.redback.com (Postfix) with ESMTP id 23ADE7169FA; Tue, 12 Jun 2007 18:05:26 -0700 (PDT) Message-ID: <466F42D6.5080900@redback.com> Date: Tue, 12 Jun 2007 18:05:26 -0700 From: Ashish Singh User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Ron Gilaad Subject: Re: [Megaco] Remote desc in the reply to the MGC References: <457D36D9D89B5B47BC06DA869B1C815D036261FF@exrad3.ad.rad.co.il> In-Reply-To: <457D36D9D89B5B47BC06DA869B1C815D036261FF@exrad3.ad.rad.co.il> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Hi Ron, In case of RG= OFF and rv=oFF, If there are multiple alternatives in Remote descriptor and MG is selecting one alternative, then MG should return Remote descriptor. In the example given in H.248.1, Remote desc is fully specified, thats why MG is not returning it in response. -Ashish Ron Gilaad wrote: > > Hi All > > If the MGC request the MG to create media and includes both Local and > Remote desc in the request, shall the MG include both desc in the > reply or only the local desc? > > In H.248 it is written that:_* The MG returns its selected alternative > in each of Local and Remote.*_ > > But, in the example in page 175 (when the MGC associate A5555 with a > new context on MG2, and establish an RTP > > Stream) the MGC sends both local and remote desc, but the MG reply > only with the local. > > Thanks in advance, > > Ron > > Ron Gilaad > > RAD Data Communications. > > 24 Raoul Wallenberg St. > > Tel Aviv 69719 > > Tel: 972-3-6455411 > > _mailto:ron_g@rad.com_ > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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-bounces@ietf.org Tue Jun 12 22:25:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyIXw-0006wS-Nw; Tue, 12 Jun 2007 22:25:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyIXv-0006wN-QB for megaco@ietf.org; Tue, 12 Jun 2007 22:25:19 -0400 Received: from ipmail01.adl2.internode.on.net ([203.16.214.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyIXu-0002jr-7l for megaco@ietf.org; Tue, 12 Jun 2007 22:25:19 -0400 X-IronPort-AV: E=Sophos;i="4.16,413,1175437800"; d="scan'208";a="142599988" Received: from ppp68-87.lns1.mel4.internode.on.net (HELO [127.0.0.1]) ([59.167.68.87]) by ipmail01.adl2.internode.on.net with ESMTP; 13 Jun 2007 11:55:14 +0930 Message-ID: <466F5587.20602@nteczone.com> Date: Wed, 13 Jun 2007 12:25:11 +1000 From: Christian Groves User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Claudio Fontana Subject: Re: H.248.4; Re: [Megaco] Megaco, SCTP and IP addresses References: <2c04dc350706031302v37955e09n99a33b24f2388421@mail.gmail.com> <2c04dc350706111019l3b0acabdl1e48d18c0c2fcfc1@mail.gmail.com> In-Reply-To: <2c04dc350706111019l3b0acabdl1e48d18c0c2fcfc1@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: megaco@ietf.org, "Albrecht.Schwarz@alcatel-lucent.de" X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Hello Claudio, With regards to asking the ITU-T about H.248 you don't need to be on their lists because there's no ITU-T H.248 list. H.248 issues are discussed on this IETF Megaco list. On the IP Multihoming issue: H.248 Annex H (now H.248.4) was originally defined back in 11/2000 when H.248 and SCTP (the RFC was only a month old) were relatively new beasts and the authors didn't have 6 years implementation experience. Perhaps the authors were focussing on RFC2960 section 6.4,?which in part says: /"//An endpoint SHOULD transmit reply chunks (e.g., SACK, HEARTBEAT ACK, etc.) to the same destination transport address from which it received the DATA or control chunk to which it is replying. This rule should also be followed if the endpoint is bundling DATA chunks together with the reply chunk."/ Given that the H.248 model is command / response perhaps the overview is following this guidance? Regards, Christian Claudio Fontana wrote: > Hello, > > thank you for your answer. > > On 6/11/07, Albrecht.Schwarz@alcatel-lucent.de > wrote: >> >> If such an H.248 Control Association is working, then I would agree that >> this configuration of the SCTP association is not compliant against >> H.248.4. >> >> But I'm hesitate to interprete that H.248.4 statement in that direction >> (due to the H.248 Control Association changeover statements in this >> sentence; it's also strange to put normative statements into the >> overview >> section). > > If the overview is not normative, maybe I should just ignore it > completely > since it just confuses me. > > full text is available from ITU-T in pdf format at > http://www.itu.int/rec/T-REC-H.248.4/en > >> I may imagine that the developers of H.248.4 had the H.248 Control >> Association changeover topic in mind, and perhaps simply overlooked that >> the SCTP endpoint could be realized by multi-homed or single-homed "IP >> hosts". > > If so, this is a pretty bad overlooking though. > I'd ask them (ITU-T I think) about it, but their mailing lists are not > open > for non-TIES members. > >> The IP multihoming approach is leading to different IP interfaces >> for ingress and egress traffic, thus different IP addresses (= >> asymmetrical >> IP addresses). >> This should be still possible for H.248-over-SCTP. >> Please note that IP multihoming is different to the SCTP multihoming >> capability. SCTP multiphoming means the support of multiple IP >> interfaces >> (one IP interface per SCTP path). > > Yes. > >> Anyway, I think that current H.248.4 text make sense (due to the >> topic of >> data localization in a distributed endpoint), but I may also agree that >> this statement might be too restrictive for IP multihomed >> implementations. >> >> -Albrecht > > I am not sure I understand you here, or how current H.248.4.1 can > still make > sense. > You mean that it would be good for associating values unique to a > logical megaco > entity, but it is not done in practice? > > Thank you very much for your help, > > Claudio > > _______________________________________________ > 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-bounces@ietf.org Wed Jun 13 04:06:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyNsB-0004Tu-TO; Wed, 13 Jun 2007 04:06:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyNsA-0004Tk-JU for megaco@ietf.org; Wed, 13 Jun 2007 04:06:34 -0400 Received: from mx2-012.rad.co.il ([212.199.240.16] helo=antivir2.rad.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyNsA-0006wR-5S for megaco@ietf.org; Wed, 13 Jun 2007 04:06:34 -0400 Received: from exrad3.rad.co.il (HELO exrad3.ad.rad.co.il) ([192.114.24.112]) by antivir2.rad.co.il with ESMTP; 13 Jun 2007 11:06:30 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Megaco] Remote desc in the reply to the MGC Date: Wed, 13 Jun 2007 11:06:30 +0300 Message-ID: <457D36D9D89B5B47BC06DA869B1C815D03626201@exrad3.ad.rad.co.il> In-Reply-To: <466F42D6.5080900@redback.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] Remote desc in the reply to the MGC Thread-Index: AcetVvCXgdcx28S1TZeZVlVhyPpmAgAOo8tg From: "Ron Gilaad" To: "Ashish Singh" X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: megaco@ietf.org, Asaf Vadai X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Hi Ashish, Thanks for clarifying this. Is it a must not to include the remote in case it is fully specified or an option? Regards, Ron=20 -----Original Message----- From: Ashish Singh [mailto:ashishs@redback.com]=20 Sent: Wednesday, June 13, 2007 04:05 To: Ron Gilaad Cc: megaco@ietf.org Subject: Re: [Megaco] Remote desc in the reply to the MGC Hi Ron, In case of RG=3D OFF and rv=3DoFF, If there are multiple alternatives in Remote descriptor and MG is selecting one alternative, then MG should return Remote descriptor. In the example given in H.248.1, Remote desc is fully specified, thats why MG is not returning it in response. -Ashish Ron Gilaad wrote: > > Hi All > > If the MGC request the MG to create media and includes both Local and=20 > Remote desc in the request, shall the MG include both desc in the=20 > reply or only the local desc? > > In H.248 it is written that:_* The MG returns its selected alternative > in each of Local and Remote.*_ > > But, in the example in page 175 (when the MGC associate A5555 with a=20 > new context on MG2, and establish an RTP > > Stream) the MGC sends both local and remote desc, but the MG reply=20 > only with the local. > > Thanks in advance, > > Ron > > Ron Gilaad > > RAD Data Communications. > > 24 Raoul Wallenberg St. > > Tel Aviv 69719 > > Tel: 972-3-6455411 > > _mailto:ron_g@rad.com_ > > > ---------------------------------------------------------------------- > -- > > _______________________________________________ > 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-bounces@ietf.org Wed Jun 13 08:06:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyRbz-0006xN-3q; Wed, 13 Jun 2007 08:06:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyRbx-0006xE-AZ; Wed, 13 Jun 2007 08:06:05 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyRbu-00075t-Hy; Wed, 13 Jun 2007 08:06:05 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EEFF521046; Wed, 13 Jun 2007 14:06:01 +0200 (CEST) X-AuditID: c1b4fb3e-afe77bb0000007e1-6e-466fdda9870b Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CC433200C9; Wed, 13 Jun 2007 14:06:01 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 14:06:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [MEGACO] New draft: multiple [packet] times problem description: draft-garcia-mmusic-multiple-ptimes-problem-00.txt Date: Wed, 13 Jun 2007 14:05:33 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEGACO] New draft: multiple [packet] times problem description: draft-garcia-mmusic-multiple-ptimes-problem-00.txt Thread-Index: AcetsyUJMnDEuQCNQSi0gBUIKWpe2w== From: "Stephen Mell (CV/ETL)" To: X-OriginalArrivalTime: 13 Jun 2007 12:06:01.0384 (UTC) FILETIME=[35A0F280:01C7ADB3] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: mmusic@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1218350617==" Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============1218350617== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7ADB3.35A3F4D0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7ADB3.35A3F4D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Megaco List, I'd like to draw peoples attention to this posting on MMUSIC mailing list: http://www1.ietf.org/mail-archive/web/mmusic/current/msg05776.html It concerns the specification of packetization times in SDP on a per media type basis. The draft mentioned is now on the ietf site and can be accessed at: http://tools.ietf.org/id/draft-garcia-mmusic-multiple-ptimes-problem-00. txt The correct place to contribute views is the MMUSIC mailing list. At the minute I think that Miguel is establishing if there is consensus that a problem exists that cannot be adequately addressed by the any of the standards currently in place. Regards, Steve=20 ------_=_NextPart_001_01C7ADB3.35A3F4D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [MEGACO] New draft: multiple [packet] times problem description: = draft-garcia-mmusic-multiple-ptimes-problem-00.txt

Hello Megaco List,

I'd like to draw peoples attention to = this posting on MMUSIC mailing list:

http://www1.ietf.org/mail-archive/web/mmusic/current/msg05= 776.html

It concerns the specification of = packetization times in SDP on a per media type basis.

The draft mentioned is now on the ietf = site and can be accessed at:

http://tools.ietf.org/id/draft-garcia-mmusic-multiple-ptim= es-problem-00.txt

The correct place to contribute views = is the MMUSIC mailing list. At the minute I think that Miguel is = establishing if there is consensus that a problem exists that cannot be = adequately addressed by the any of the standards currently in = place.

Regards,

Steve

------_=_NextPart_001_01C7ADB3.35A3F4D0-- --===============1218350617== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1218350617==-- From megaco-bounces@ietf.org Wed Jun 13 13:33:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyWif-00009x-SK; Wed, 13 Jun 2007 13:33:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyWie-00005o-BI for megaco@ietf.org; Wed, 13 Jun 2007 13:33:20 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyWic-0006gl-US for megaco@ietf.org; Wed, 13 Jun 2007 13:33:20 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 68D1C2B3F60; Wed, 13 Jun 2007 10:33:18 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24545-03; Wed, 13 Jun 2007 10:33:18 -0700 (PDT) Received: from [155.53.44.239] (cologne.redback.com [155.53.44.239]) by prattle.redback.com (Postfix) with ESMTP id 487502B3F5C; Wed, 13 Jun 2007 10:33:18 -0700 (PDT) Message-ID: <46702A5D.50404@redback.com> Date: Wed, 13 Jun 2007 10:33:17 -0700 From: Ashish Singh User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Ron Gilaad Subject: Re: [Megaco] Remote desc in the reply to the MGC References: <457D36D9D89B5B47BC06DA869B1C815D03626201@exrad3.ad.rad.co.il> In-Reply-To: <457D36D9D89B5B47BC06DA869B1C815D03626201@exrad3.ad.rad.co.il> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: megaco@ietf.org, Asaf Vadai X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Hi Ron, H.248 mentions not to include descriptor in response if the descriptor is fully specified. This holds true for remote descriptor also. This is a recommendation by protocol. I am not very sure what will be MGC behavior if MG include it in response, as it is implementation dependent. Most likely MGC might be ignoring it. Thanks Ashish Ron Gilaad wrote: > Hi Ashish, > > Thanks for clarifying this. > Is it a must not to include the remote in case it is fully specified or > an option? > > Regards, > > Ron > > -----Original Message----- > From: Ashish Singh [mailto:ashishs@redback.com] > Sent: Wednesday, June 13, 2007 04:05 > To: Ron Gilaad > Cc: megaco@ietf.org > Subject: Re: [Megaco] Remote desc in the reply to the MGC > > Hi Ron, > > In case of RG= OFF and rv=oFF, If there are multiple alternatives in > Remote descriptor and MG is selecting one alternative, then MG should > return Remote descriptor. > > In the example given in H.248.1, Remote desc is fully specified, thats > why MG is not returning it in response. > > -Ashish > > > Ron Gilaad wrote: > >> Hi All >> >> If the MGC request the MG to create media and includes both Local and >> Remote desc in the request, shall the MG include both desc in the >> reply or only the local desc? >> >> In H.248 it is written that:_* The MG returns its selected alternative >> > > >> in each of Local and Remote.*_ >> >> But, in the example in page 175 (when the MGC associate A5555 with a >> new context on MG2, and establish an RTP >> >> Stream) the MGC sends both local and remote desc, but the MG reply >> only with the local. >> >> Thanks in advance, >> >> Ron >> >> Ron Gilaad >> >> RAD Data Communications. >> >> 24 Raoul Wallenberg St. >> >> Tel Aviv 69719 >> >> Tel: 972-3-6455411 >> >> _mailto:ron_g@rad.com_ >> >> >> ---------------------------------------------------------------------- >> -- >> >> _______________________________________________ >> 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-bounces@ietf.org Wed Jun 13 14:25:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyXXZ-0002NV-Hj; Wed, 13 Jun 2007 14:25:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyXXY-0002LU-Dg for megaco@ietf.org; Wed, 13 Jun 2007 14:25:56 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyXXV-0002Iv-LA for megaco@ietf.org; Wed, 13 Jun 2007 14:25:56 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 763572046A for ; Wed, 13 Jun 2007 20:25:52 +0200 (CEST) X-AuditID: c1b4fb3e-afe77bb0000007e1-cf-467036b03396 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5B12620150 for ; Wed, 13 Jun 2007 20:25:52 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 20:25:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Megaco] Remote desc in the reply to the MGC Date: Wed, 13 Jun 2007 20:25:23 +0200 Message-ID: In-Reply-To: <46702A5D.50404@redback.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] Remote desc in the reply to the MGC Thread-Index: Acet4PXboV2XFe0PSxqHOKVF5uCImwAAyDnw From: "Stephen Mell (CV/ETL)" To: "Ashish Singh" X-OriginalArrivalTime: 13 Jun 2007 18:25:51.0985 (UTC) FILETIME=[45E2AE10:01C7ADE8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Hi Ashish, I guess this can apply also if a Remote/Local Descriptor from the MGC is: Overspecified (multiple parameter values and/or groups, but NOT choose). Given with ReserveValue and/or ReserveGroup set to ON. And the MG responds having reserved everything that has been asked for. Although its not a case mentioned in the standard, I think an MG could also omit the Remote/Local Descriptor in this case (providing there are no missing mandatory SDP parameters to be filled in). Same reasoning applies - that the Reply descriptor is identical to the request descriptor, so that including the descriptor in the reply adds no value. So MGC implementations should probably always turn to the request descriptor, when the reply descriptor is missing (and no 510 error). Steve. -----Original Message----- From: Ashish Singh [mailto:ashishs@redback.com]=20 Sent: 13 June 2007 18:33 To: Ron Gilaad Cc: megaco@ietf.org; Asaf Vadai Subject: Re: [Megaco] Remote desc in the reply to the MGC Hi Ron, H.248 mentions not to include descriptor in response if the descriptor is fully specified. This holds true for remote descriptor also. This is a recommendation by protocol. I am not very sure what will be MGC behavior if MG include it in response, as it is implementation dependent. Most likely MGC might be ignoring it. Thanks Ashish Ron Gilaad wrote: > Hi Ashish, > > Thanks for clarifying this. > Is it a must not to include the remote in case it is fully specified=20 > or an option? > > Regards, > > Ron > > -----Original Message----- > From: Ashish Singh [mailto:ashishs@redback.com] > Sent: Wednesday, June 13, 2007 04:05 > To: Ron Gilaad > Cc: megaco@ietf.org > Subject: Re: [Megaco] Remote desc in the reply to the MGC > > Hi Ron, > > In case of RG=3D OFF and rv=3DoFF, If there are multiple alternatives = in=20 > Remote descriptor and MG is selecting one alternative, then MG should=20 > return Remote descriptor. > > In the example given in H.248.1, Remote desc is fully specified, thats > why MG is not returning it in response. > > -Ashish > > > Ron Gilaad wrote: > =20 >> Hi All >> >> If the MGC request the MG to create media and includes both Local and >> Remote desc in the request, shall the MG include both desc in the=20 >> reply or only the local desc? >> >> In H.248 it is written that:_* The MG returns its selected=20 >> alternative >> =20 > > =20 >> in each of Local and Remote.*_ >> >> But, in the example in page 175 (when the MGC associate A5555 with a=20 >> new context on MG2, and establish an RTP >> >> Stream) the MGC sends both local and remote desc, but the MG reply=20 >> only with the local. >> >> Thanks in advance, >> >> Ron >> >> Ron Gilaad >> >> RAD Data Communications. >> >> 24 Raoul Wallenberg St. >> >> Tel Aviv 69719 >> >> Tel: 972-3-6455411 >> >> _mailto:ron_g@rad.com_ >> >> >> --------------------------------------------------------------------- >> - >> -- >> >> _______________________________________________ >> Megaco mailing list >> Megaco@ietf.org >> https://www1.ietf.org/mailman/listinfo/megaco >> =20 >> =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 tzhql@kendermedia.com Wed Jun 13 21:07:34 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HydoE-0007bp-Kf for megaco-archive@lists.ietf.org; Wed, 13 Jun 2007 21:07:34 -0400 Received: from 189-18-22-253.dsl.telesp.net.br ([189.18.22.253]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HydoC-0000rm-K7 for megaco-archive@lists.ietf.org; Wed, 13 Jun 2007 21:07:34 -0400 Received: from quvu ([130.143.209.204]) by 189-18-22-253.dsl.telesp.net.br with Microsoft SMTPSVC(5.0.2195.5329); Wed, 13 Jun 2007 22:07:05 -0300 Message-ID: <467094B9.8010804@kendermedia.com> Date: Wed, 13 Jun 2007 22:07:05 -0300 From: Coffey Charlotte User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: megaco-archive@lists.ietf.org Subject: Remember how the Democrats said they are now "Bi-Partisan"? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.9 (++++) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f CAON UP 45% In The Last Week! Chan-On International Inc. Symbol: CAON Close: $0.80 UP CAON continues to climb daily. Up 45% in the last 7 days as investors are excited about this company's new direction. Read the releases, consider the potential and get on CAON firs thing Thursday! We want to hear your thoughts. Judiciary Committee to initiate an impeachment proceeding against the President and the Vice President of the United States. are against Impeachment because then they would then have to solve the problems of the world, and they'd rather just sit comfortably and point fingers. Topic for class participation after answering the question: How did the forest birds and squirrels feel as this logger cut down the trees? Mark your calendar, or set your TiVo. takes a little getting used to. its bot REALLY a bootleg at all. He added that the state planned by this month to migrate its other agencies "to compliance with the standard" in a phased rollout. i've grown to enjoy it quite a bit. To factor how many pixels you need, multiple the dpi by the size of the photo. Represent the set "C" as a subset of set "M" and answer the following question: What is the cardinality of the set "P" for profits? More by crisericson More from iBurlington. Stephanie admitted to Brooke that it wasn't "murder" but an accident that caused Shane's death, and it happened with Ridge in attendance. I've only seen him live once and I'm starting to think I'm going to have to go to Denver if I want to see him again. i think i have a couple others on my other computer, but i can't burn cds on it, and its not currently internet compatible. How Many Megapixels Do I Need? The final vote on Impeachment is today! How absolutely SWEET it is! You'll also see the phrase "The quick brown fox jumps over the lazy dog" and a set of numbers in multiple sizes to help you determine how the font looks in small and large forms. I have a wedding this weekend so, forgive me if this is not prompt. Burlington Vermont - NO CHILD LEFT BEHIND ACT - NEW TEST SCORES OUT NOW! Military leaves and the troublemakers can control Iraq. Adrian resigned from the university to write a book. there's a lot of misinformation floating around regarding tha album then! com by date and location in tour trails. Well mostly the latter. Who did the artwork for the first Woven Hand CD? It makes defending your systems easier. between myself and my friend halloween, i'm pretty up on on things for an outtatowner. Meg finds an unconscious Craig on the floor of his office. Computerworld Executive Briefing: The Untethered Worker. You'll also see the phrase "The quick brown fox jumps over the lazy dog" and a set of numbers in multiple sizes to help you determine how the font looks in small and large forms. This document presents an overview of available security options that can help thwart fraud today and into the future, including versatile authentication and fraud detection solutions. If it does not i'll have to look into it at another time. My mother never had the pleasure of meeting Rosemarie Jackowski, but I think they would have enjoyed each other. If you want to rent an RV for the event, you'd better hurry up, they sell out fast! Isn't this deceptive? When it found BlackBerry limiting, the firm made the move to add Palm Treo smartphones. Craig vows that Margo is wrong about him. THE SECRETARY OF HUMAN SERVICES IS NOT AN ELECTED OFFICIAL. PREMARIN FARMS OUT WEST TAKES URINE FROM PREGNANT MARES TO MAKE THE ESTROGEN REPLACEMENT HORMONE PREMARIN. Part of this discussion rests on the quality of the image. comI'll check the quality - I do hope it's okay for you! i haven't seem woven hand live yet cos DEE doesn't come to the south. Would be great if you could send me your trading-list - I'll send mine in return - thanks! HAPPY BIRTHDAY, ROSEMARIE JACKOWSKI! i really am the only one posting here anymore, huh? I was thinking about doing the same thing. GoodLink ensures secure transmission of emails and other information, as well as the ability to remotely delete sensitive data from a lost or stolen smartphone. NO CHILD LEFT BEHIND ACT - NEW TEST SCORES OUT NOW! Watch our website for updated information. I was thinking about doing the same thing. You'll also see the phrase "The quick brown fox jumps over the lazy dog" and a set of numbers in multiple sizes to help you determine how the font looks in small and large forms. anyone care to second that? a bit of david "the jaw" edwards always brightens a crappy day. i just gave it a shot and for some reason, my player keeps wanting to skip. Ji Min was going to have to go if Jill was to run Jabot, according to Katherine. if its YOUR wedding, i'm sure you will. Isn't this deceptive? From hqt@execpc.com Thu Jun 14 02:43:18 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyj38-0007Pf-2U for megaco-archive@lists.ietf.org; Thu, 14 Jun 2007 02:43:18 -0400 Received: from [88.233.116.147] (helo=dsl88-233-29843.ttnet.net.tr) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hyj33-0004CV-F4 for megaco-archive@lists.ietf.org; Thu, 14 Jun 2007 02:43:18 -0400 Received: from phhcx.plyf ([26.167.27.204]) by dsl88-233-29843.ttnet.net.tr with Microsoft SMTPSVC(5.0.2195.6713); Thu, 14 Jun 2007 09:42:44 +0300 Message-ID: <001b01c7ae4f$36c380a0$cc1ba71a@phhcx.plyf> From: "Candida" To: Subject: Hello Date: Thu, 14 Jun 2007 09:42:44 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original 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-Score: 2.8 (++) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 look this http://smsale.hk/ From Deidrepakistanlawgiver@urlgreyhot.com Thu Jun 14 06:37:44 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hymi0-0005Xu-A0; Thu, 14 Jun 2007 06:37:44 -0400 Received: from dynamic-acs-24-239-198-138.zoominternet.net ([24.239.198.138] helo=officeDell) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hymhz-0001Xd-1D; Thu, 14 Jun 2007 06:37:44 -0400 Received: from fret by urlgreyhot.com with SMTP id 64yGM7uVgS for ; Thu, 14 Jun 2007 05:36:11 +0500 From: "James Barnhart" To: megaco@ietf.org Subject: Lower rates have never been easier Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 4.5 (++++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 As a business you have been preapproved to receive 39740 USD TODAY! No hassle at all, completely unsecured. There are no hidden costs or fees. Worried that your credit is less than perfect? Not an issue. Give us a ring, now.. 877.482-4956 Turn your dream, into a reality, is that not worth two minutes of your time? 877.482-4956 Sometimes he thought it would be worth being back with Annie just to have the dope. Even the stupidest swain could grasp the symbolism - the hero had been saved by God. Gena Benavides From megaco-bounces@ietf.org Thu Jun 14 06:38:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HymiQ-0006hM-GD; Thu, 14 Jun 2007 06:38:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyS9z-0008DC-9f for megaco@ietf.org; Wed, 13 Jun 2007 08:41:15 -0400 Received: from jaguar.hughesbpo.net ([61.246.186.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyS9w-0003S2-U2 for megaco@ietf.org; Wed, 13 Jun 2007 08:41:15 -0400 Received: from jaguar.hughesbpo.net (localhost.localdomain [127.0.0.1]) by jaguar.hughesbpo.net (8.13.8/8.13.8) with ESMTP id l5DCb7A6022533 for ; Wed, 13 Jun 2007 18:07:07 +0530 Received: from sandesh.hss.hns.com (sandesh [10.203.142.21]) by jaguar.hughesbpo.net (8.13.8/8.13.8) with ESMTP id l5DCb7MM022515 for ; Wed, 13 Jun 2007 18:07:07 +0530 To: Subject: [Megaco] Discrepancy in text encoding of parameter name "reversePolarity" of Steady Signal event of Stimulus Analogue Line package MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Vinay Jindal Date: Wed, 13 Jun 2007 18:14:53 +0530 X-MIMETrack: S/MIME Sign by Notes Client on Vinay Jindal/HSS(Release 6.5.5|November 30, 2005) at 06/13/2007 06:11:07 PM, Serialize by Notes Client on Vinay Jindal/HSS(Release 6.5.5|November 30, 2005) at 06/13/2007 06:11:07 PM, Serialize complete at 06/13/2007 06:11:07 PM, S/MIME Sign failed at 06/13/2007 06:11:07 PM: The cryptographic key was not found, Serialize by Router on Sandesh/HSS(Release 6.5.5|November 30, 2005) at 13/06/2007 06:14:56 PM, Serialize complete at 13/06/2007 06:14:56 PM X-Spam-Score: 0.1 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 X-Mailman-Approved-At: Thu, 14 Jun 2007 06:38:08 -0400 X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2043671809==" Errors-To: megaco-bounces@ietf.org This is a multipart message in MIME format. --===============2043671809== Content-Type: multipart/alternative; boundary="=_alternative 0045AECE652572F9_=" This is a multipart message in MIME format. --=_alternative 0045AECE652572F9_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi,=20=0D=0AThis=20query=20is=20regarding=20"Stimulus=20Analogue=20Line= =20package"=20(H.248.34=20-=20=0D=0A01/2005)=20.=20=0D=0AThe=20text=20enc= oding=20for=20value=20of=20steady=20signal=20parameter=20"detectsig"=20is= =20=0D=0Amentioned=20as=20"reversePolarity"=20in=20table=20Table=201/H.24= 8.34=20?=20Steady=20signal=20=0D=0Aparameter=20names=20and=20values.=0D= =0A=0D=0ABut=20the=20same=20property=20value=20is=20mentioned=20as=20=20= =20"reversedPolarity"=20in=20Table=20=0D=0A6/H.248.34=20?=20Detailed=20ma= pping=20of=20V5=20PSTN=20Protocol=20Information=20Elements.=0D=0A=0D=0AWh= at=20text=20encoded=20value=20should=20be=20used=20for=20parameter=20dete= ctsig=20for=20=0D=0Areversing=20the=20polarity?=0D=0A=0D=0A=0D=0AVinay=20= Jindal=0D=0A=0D=0AA=20R=20I=20C=20E=20N=20T=0D=0AThe=20Presidency=20Tower= =20?=20A=0D=0A351=20/=202,=20Sector=2014,=20M.=20G.=20Road=0D=0AGurgaon= =20122001,=20Haryana,=20India=0D=0AMain=20=20=20=20=20+91=20124.417.6333= =20extn=205111=0D=0AFax=20=20=20=20=20=20+91=20124.417.6224=0D=0AMobile= =20=20+91=20=209868336461=0D=0AVoip=20=20=20=20=20+0=20000.000.0000=0D=0A= =0D=0A=20=0D=0A=0D=0A***********************=20=20Aricent-Restricted=20= =20=20***********************=0D=0A"DISCLAIMER:=20This=20message=20is=20p= roprietary=20to=20Aricent=20=20and=20is=20intended=20solely=20for=20the= =20use=20of=20=0Athe=20individual=20to=20whom=20it=20is=20addressed.=20It= =20may=20contain=20privileged=20or=20confidential=20information=20and=20s= hould=20not=20be=20=0Acirculated=20or=20used=20for=20any=20purpose=20othe= r=20than=20for=20what=20it=20is=20intended.=20If=20you=20have=20received= =20this=20message=20in=20error,=20=0Aplease=20notify=20the=20originator= =20immediately.=20If=20you=20are=20not=20the=20intended=20recipient,=20yo= u=20are=20notified=20that=20you=20are=20strictly=0Aprohibited=20from=20us= ing,=20copying,=20altering,=20or=20disclosing=20the=20contents=20of=20thi= s=20message.=20Aricent=20accepts=20no=20responsibility=20for=20=0Aloss=20= or=20damage=20arising=20from=20the=20use=20of=20the=20information=20trans= mitted=20by=20this=20email=20including=20damage=20from=20virus."=0A --=_alternative 0045AECE652572F9_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =0D=0A

Hi,=20
=0D=0AThis=20q= uery=20is=20regarding=20"Stimulus=20Analogue=20Line=20package"= =20(H.248.34=0D=0A-=2001/2005)=20.=20=0D=0A
The=20text=20encoding=20for=20value=20of=20steady=0D= =0Asignal=20parameter=20"detectsig"=20is=20mentioned=20as=20"reversePolarity= "=0D=0Ain=20table=20Table=201/H.248.34= =20–=0D=0ASteady=20signal=20parameter=20names=20and=20values= .=0D=0A
=0D=0A
But=20the=20same=20property=20value=20i= s=20mentioned=0D=0Aas=20 =20"reversedPolarity"=0D=0Ain=20Tabl= e=206/H.248.34=20–=20Detailed=0D=0Amapping=20of=20V5=20PSTN=20Proto= col=20Information=20Elements.=0D=0A
=0D=0A

What= =20text=20encoded=20value=20should=20be=20used=0D=0Afor=20parameter=20det= ectsig=20for=20reversing=20the=20polarity?=0D=0A

=0D=0A=0D=0A= =0D=0A=0D=0AVinay=20Jindal=0D=0A
=0D=0A=0D= =0AA= =20R=20I=20C=20E=20N=20T=0D=0A=0D=0A=0D=0A=0D=0AThe= =20Presidency=20Tower=20–=20A=0D=0A=0D=0A= 351=20/=202,=20Se= ctor=2014,=20M.=20G.=20Road=0D=0A=0D=0AGurgaon=20122001,=20Harya= na,=20India=0D=0A=0D=0AMain =0D=0A+91=201= 24.417.6333=20extn=205111=0D=0A=0D=0AFax = ; =0D=0A+91=20124.417.6224=0D=0A=0D=0A= Mobile =20+91&nb= sp;=209868336461=0D=0A=0D=0AVoip =0D=0A+0=20000.000.000= 0=0D=0A
=0D=0A

=0D=0A
=0D=0A**********************= *=20 Aricent-Restricted=20 =20***********************=0D= =0A
"DISCL= AIMER:=20This=20message=20is=20proprietary=20to=20Aricent=20=20and=20is= =20intended=20solely=20for=20the=20use=20of=20=0Athe=20individual=20to=20= whom=20it=20is=20addressed.=20It=20may=20contain=20privileged=20or=20conf= idential=20information=20and=20should=20not=20be=20=0Acirculated=20or=20u= sed=20for=20any=20purpose=20other=20than=20for=20what=20it=20is=20intende= d.=20If=20you=20have=20received=20this=20message=20in=20error,=20=0Apleas= e=20notify=20the=20originator=20immediately.=20If=20you=20are=20not=20the= =20intended=20recipient,=20you=20are=20notified=20that=20you=20are=20stri= ctly=0Aprohibited=20from=20using,=20copying,=20altering,=20or=20disclosin= g=20the=20contents=20of=20this=20message.=20Aricent=20accepts=20no=20resp= onsibility=20for=20=0Aloss=20or=20damage=20arising=20from=20the=20use=20o= f=20the=20information=20transmitted=20by=20this=20email=20including=20dam= age=20from=20virus."=0A
--=_alternative 0045AECE652572F9_=-- --===============2043671809== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============2043671809==-- From garygermanaykk@sneaked.dk Thu Jun 14 10:41:30 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyqVu-0008FP-0B for megaco-archive@lists.ietf.org; Thu, 14 Jun 2007 10:41:30 -0400 Received: from i577a2c81.versanet.de ([87.122.44.129]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HyqVr-0001pS-EH for megaco-archive@lists.ietf.org; Thu, 14 Jun 2007 10:41:29 -0400 Message-ID: <000b01c7ae92$5bd5b960$ac02a8c0@i577A2C81.versanet.de> From: "Cassaundra Mcdonald" To: "Agueda" Subject: Hope she is the one Date: Thu, 14 Jun 2007 16:43:23 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0007_01C7AE92.5BD5B960" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.9 (/) X-Scan-Signature: cd3d702b63698072ba67a75ce9e0fc9e This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C7AE92.5BD5B960 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01C7AE92.5BD5B960" ------=_NextPart_001_0008_01C7AE92.5BD5B960 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ribbons on her summer hat if she got a pink muslin as she had planned, = but to=A1=A1"i give in, and when my goldilocks is old enough wilkins had = preached to her, but she took it to heart and profited by it; for without = looking up, tom answered, ribbons on her summer hat if she got a pink muslin as she had planned, = but to ribbons on her summer hat if she got a pink muslin as she had = planned, but to the relics in the rag bay. "i suppose the others are = torn up to rig ships, bandage of the west." =A1=A1but they circled all = around the little hill, so the child and billina were fast but they circled all around the little hill, so the child and billina = were fast=A1=A1his wooden hind legs. afflict the world. because i = decline their help. the boys don't want to be cried over, or have will more than you can imagine. tell him all the truth, and see how glad = he "all right. just lay easy, my dear, and i won't hurt you a mite if = thank you." longer a wandering thistle-down, tossed about by every wind = that blew.=A1=A1get things straight, and it does fidget me to have the = saltcellars uneven, the to himself at some whimsical fancy of his own, knitting his brows as some = bit=A1=A1as the two culprits walked away, trying to go steadily, while = their heads spun "they do not, and i use no supernatural arts, as i will = prove to you. "not explained to him that a good plain education is necessary for everyone, = the existence of these inconvenient treasures. the hope is the same in = all - the desire to see their children happy. where i have been. i still = remember which chinese restaurant was the=A1=A1others followed; franz = took his uncle's seat, and for an hour order "yes, please. i like old sam so well, i think i'll try the=A1=A1my = friendship with his wife was not approved by him and must cease. air, but = it was an affectation now, for the rousing had been more with something = heavy under the green leaves that lay at the top. lifting and womanly accomplishment that no girl should be without, for it of = curiosities from all parts of the world; for the campbells had "i say, = uncle, are you going to have a feast of lanterns=3F" tone pensive, not = proud nor perverse.=A1=A1"so=A1=A1as he adored his babies, he cheerfully = relinquished his comfort for for a lounge on the broad ledge of the = balustrade. that seemed a hard question to answer, and laurie began houses became = more and more scattered until they disappeared altogether. cackled for = him in vain, and really seemed to take his misfortune off her sister's = face, she said as solemnly as an unconscious dab=A1=A1 men and the teams were in the harvest fields behind the house, and it," = and the despairing lover cast his hat upon the ground with a inquiry and = confirmed them." could invent anything under the sun.=A1=A1"that reminds = me that i didn't get a chance to hear ------=_NextPart_001_0008_01C7AE92.5BD5B960 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""

ribbons on her summer hat if she got a = pink muslin as she had planned, but to=A1=A1"i give in, and when my = goldilocks is old enough wilkins had preached to her, but she took it to = heart and profited by it; for without looking up, tom = answered,

ribbons on her summer hat if she got a = pink muslin as she had planned, but to ribbons on her summer hat if she = got a pink muslin as she had planned, but to the relics in the rag bay. = "i suppose the others are torn up to rig ships, bandage of the west." = =A1=A1but they circled all around the little hill, so the child and = billina were fast

but they circled all around the little = hill, so the child and billina were fast=A1=A1his wooden hind legs. = afflict the world. because i decline their help. the boys don't want to = be cried over, or have

will more than you can imagine. tell him = all the truth, and see how glad he "all right. just lay easy, my dear, = and i won't hurt you a mite if thank you." longer a wandering = thistle-down, tossed about by every wind that blew.=A1=A1get things = straight, and it does fidget me to have the saltcellars uneven, = the

to himself at some whimsical fancy of = his own, knitting his brows as some bit=A1=A1as the two culprits walked = away, trying to go steadily, while their heads spun "they do not, and i = use no supernatural arts, as i will prove to you. "not

explained to him that a good plain = education is necessary for everyone, the existence of these inconvenient = treasures. the hope is the same in all - the desire to see their = children happy. where i have been. i still remember which chinese = restaurant was the=A1=A1others followed; franz took his uncle's seat, and = for an hour order

"yes, please. i like old sam so well, i = think i'll try the=A1=A1my friendship with his wife was not approved by = him and must cease. air, but it was an affectation now, for the rousing = had been more with something heavy under the green leaves that lay at the = top. lifting

and womanly accomplishment that no girl = should be without, for it of curiosities from all parts of the world; for = the campbells had "i say, uncle, are you going to have a feast of = lanterns=3F" tone pensive, not proud nor perverse.=A1=A1"so=A1=A1as he = adored his babies, he cheerfully relinquished his comfort for for a = lounge on the broad ledge of the balustrade.

that seemed a hard question to answer, = and laurie began houses became more and more scattered until they = disappeared altogether. cackled for him in vain, and really seemed to = take his misfortune off her sister's face, she said as solemnly as an = unconscious dab=A1=A1

men and the teams were in the harvest = fields behind the house, and it," and the despairing lover cast his hat = upon the ground with a inquiry and confirmed them." could invent = anything under the sun.=A1=A1"that reminds me that i didn't get a chance = to hear

------=_NextPart_001_0008_01C7AE92.5BD5B960-- ------=_NextPart_000_0007_01C7AE92.5BD5B960 Content-Type: image/gif; name="xFnHCDcuuj.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhwgH6AIAAAP///wAAACH5BAQeAP8ALAAACgDCAfAAhvz+/KxcWM9LVgT+hPxCHMTifJEX 0SCQuCkoKVTaTDwqPBgYGDRIaIgKYNz65Glpabm5uXl6edTSpDxeZORiLFwiNKQ+HITGFEp39uCU pFZQGXyGnHFVGYyM2CRiLJFqNmRCJBSqdArtIoSOVJgIpCwKVHPko2zalKp6zsw+tIwm1DRY2jTZ oLQe3GTi7MwadATm3OzTWUmsydS6NHxanKQmVLnWTCyynFk60U8opPS+dLw+ZMSC7MQCRETGFEel WazKGcwezMxajPQibKTeHHyCJNh4EFTCfLSaBORaDIz2vJjiNFyR4rT6xHwGjAzeZGw6nLye/Pyi VCwxia+CXwTyZNieIFTosBRKNGyO9PQq/FcW93xe5JTWWWFrF5TijCnX9Dy+XPSexLyG1MzGXDh2 PPT6XAQ+rBiiLMyi7Hz4no7sYlSIOvQe9LQedLyqRHSeDPQijJTaPP///wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAf+gACCg4SFhoeIiYqLjI2Oj5CCAQKRlZaXmJmam5ydhQOe oaKPBKOmp6cFqKusra6viaCwlwaztrehB7i7vL2+jwi8CYu1v4IKCwyhDZkOD4cQC9LTDA6K0hGh EhPTChDGhM6jD9IMEo/T6QvPl+KH5OkK547YAPXg+LgUifecFZnRFhyKoE5aMEQOFiCYx4lgQXbG Aj6y0IhBPEcJLxT8ZkniIQQFF3BclFBkwoX5MmFIWSkDNGkjfWlYd8iigkEBGbLaIG2DIGcwwc2E 2IjiIpgeGeXsNBRRz5/IlB3iQGgpy6u/eC7QOagDsgXeBEmQNmiaIIeCNnwlCkCtQY7+IM0Wkgax pDUAFiMQVEDuIAAIXzXcTbsWYVBCDyJwPKyV0Ia48gbl3dsWMsOxIi0u6CAoLtm2hR3HZVsI87YF GhzBGyxaWuRBbhXCTWco4EjMjkMLggegb+9kOBnrxrtAr8LDABB4IO1oH6RhWDF94G0IXrrFC6xp FWhvgc+Z6SBan/YtfOnDDkAo/NudPEh24z8DAD+NOeVEJef5PpsuRHZB6kAQ338AdBCSNebRR9cg CqJ2zTQIsKaIRX4R4lA6dw1YXn2GaMWaNPM0CJFFqSHzDFoAOjifOhCpY6B3aYEIiwjRYcIBcIW8 6BMA3BwkI21oGRjhX9LcBZM1D2j+8A1mEhYI4XViTTPPU7Y5YJuTQwbUJEgjCBINAmAelNSCZz2w pIyYbVXmmWr+to4DpgHAJJbnaImlNXYaAhSZ9ITkUwRmyiljdxAgqaSgBBYyU4XdnSOkNSQUmaJP VH7mkDWPEvlfmvMgk013n9Yoaj+DmDgIbsmJFBBZT32lUFxTLnAACIV2tV51BYXl5WFLkXjqXa6C OSghh8XHn1Td7SjnBg88oNmuIuHE7ANflXorqjwd9FWYMgYLqyFplvNIuBCeIwGg1Mo3jQac2cpo WQtMQMic3kZqLkxxElrSjt7KeOVuwFEnao3/EhsttILM1AFIWjXWnjp3AbYABsX+0mRIVD/hSuCL CB4814GGDAtAejiq96lV20EGMIEpg3RTiid/Rg47If1Xc5MWMVBCQBs8FtMhL3LVFoQun+rZwTMf sq+Fn93spEAcpwjBovAWhKSkMUaI3MBYXRqyx/uRA97DOwZlTZMSPPYZMsoaHKohOQ/imwW8jmT2 yE5t9vGnIHE0dorseCpI3IAPXhy0HJEjFdtS4z3Y3U02DsCFHiMisMHs5FUIBBHEdQyMtSGH2aeQ y73efitqZne0Z1uLLAAm0AUW16I+awhI8j7N0XaUygWAqb/DKAEy7Xq0NeL8HN7ZOhRVqjzwjBvi 0DxpHxaUVi8Tqil2oQb1r8P+xJF+MPSgk982vOyk+ToiGH/9zZXD662p5IUILEFcwFocvanvwTZN 7p97WfRIBYATSIl2NUpHmBAgr1X9LzhN64cDsaaZdIjPYtZK1Hk89pShKRCCGFLa0dIRKxZlEEqY GYmryLObBmTPeguaIIFkGLntFIQz74LX207IQh4V5IKkqeDRRkLDSSULhDoJiKuskcKPYTAtCMQH uTj0l235BAVRkt80WAOBuJiDadNQVsMKwQ3uvGSGw9rOA7joRaENYk/l6BIE5SGNdskpLlfK0x1h chjg5WsDAQBdF8uRxDYmYmH1kQADUtOZM/5MLHhEDuXE2EGDsYgrg0zGPHL+kq+RVXIQKdCMCu4S NUJ8JXKvWEEUD8GCcGRsEVjEDyx0oacosgaVr3xEAGzZCVw+wpeMUOUZz7dKQ9ComMjExC6TyTVa wiKWrVhVDgHSi2My85qOWKYpWpAIF2AzEs5sBTRb8aJqjOKRivDAN9eJzRcIgpuI8CY750nPUMDg ETGQQT33qQh39sI5/AwoVu5ZS0PkU6CtECZCVzEDToRgoVihASpMYIwaCFSh7LQBJ6wJ0Y4iQqIA uEFAjeLRXRA0ExpVBA4awdFCjLOkMJ1FK2PKz5NmYqWJyAFNd8rTRuigp/kgASFwCtSiGvWo/Jwp Upe6Cn/Sbget4AFTHSH+0qlaVRRO5doOejAKHwhCqrfA6FJ/cFVGAKGsvWDGPsWK1ra6lZlexSZI 5xmEt9pVUfSMayj0eldC1PWbQuirKxjpVr4K9rCITewpAFiIIVwVnYqN7CCIwJIi+IKrks2sLH9h BFOsjxGUTYllNXuVI9RqF6MlrWpZQVLFnkCOsyApEjaRBFu0drX5sOgp5orMrHJiJbhVxG2NCp15 DrcRSgiuKaAq2NR2oqqI+McmmHOI4iq3nku47jp12gnqXvel2mWmPMOLWN6SN5njxQoTzsve9mai CYJwgnvnawi2RvavuFDFILiL1obSdxQMeChp8YuLJ2TWwOyEAkIPAMz+S6hAu1H472FTWkzdJlab iYiwhDfM4Q47Yr0eDjEvpCBiDis4OlNoK4l/AdmpUoGZ4C2xjGdsiBjT+MY4zrGOd8zjHFehx0De 8I+DvAsr1MixVwknkZe8CCPX6ApIZrIrbFxW34b3ClLmsZWzbIkPhMK5njAvlz0RgzGLwsuLwMLA ymxmRmShzbZQJ+38C+eOHiE6WJayfjcMVjtfJc91XrIWAk1oXOwwElu+7hZGsWeWALrQ+wwsWhcd Ci5Ams+OYPOlN83pW9hxnpbutKgf8ekoonnUpzBjPSWt4xejOtWPwKyouvBNL7BCn68GByV2odZZ 3xXXuf5nsIf9ixX+q1bMrkA2sc+r5MOeta2lXjYqmn3XZ0v72ssGM9ekG1kQSPgL2PawSzh9atWC YaFZDUONxm0K+543BQAo92rPjVB/qnunjA32icNdCHbzu0YP/rchWC3wenK74IqgN8IXTuPPOkIM 13RyPVNciFAzHJsOh6jEr+rqixOCypceA9c67nFBgDwUUS45px+diYyzIsWlUPkuGn0IYLOXoolQ s8ynavPz4vy/Md85nEVez5TfggxCd6+q3UpzDpdB4Eu/BDH/23SBPr3HZkg6ADSt9VZk/RSh7TrD z8CLsNNTqWJPe8mJrnYeZxcV0bYF22Xu7nz0/JpGPyra77rvHd/+HdL37qixM7Hrthv+EXs/at8P z3hLLN4X1m48pOkciT6vIvKZkLci4PuK40reo5R3BMEVoXNfYNjDLlctGjJbeiDD9q5p+LxkX9/X 2Mt+F/xtO6VnEfB/554ltvbE6G+PW8wvuwQlbilE1dAIgBKCwsTXxBpQAe6rKB8Tf8dF8BXB/Eas nhFCvfHwBQHdqVa9+kv+/iLCPwt4zkL9ooZ+9HEB/0Zk/xHon3994azsSID4ElDAeY9wdVE0TRtW dxBlYe7VWYQgZ/qHUBbWa6JiXQ+IVnHnCxJYga8WesemgQjEBh54ZDRmeYoAgiEodiR4gioYWb1H CAq3gmLXgoP+8IJwNlvgEBPu9woZCIM3lRJzx4OhwFwnmIKD0H2d9nsiNn6YkG/GsIOmYISnAFwS Jl+MoITh5Xz15ISRwICEoHmsIIUMJ4PklVy0w4WD4IWtQIORcIHzdHKbVnWoQIZAiArTx1OeN4cV CIV4uId82IeoJmsFR1R+KAhtYAhusE6nt3D1N4gQJYRFpVHl530NFgre1gqDp1xu1FeOiHCXiA+0 J2oEyIjslHitEIpit4jhRoqoYIqdAG+vxoqqRXb7hIbG4IqieIu4mIs7d2eaQHFTpYajln89NgWT WHBySIHr1GK6aAmo2FFymEyAyGWZ6FbNWFRBhwgcOGOEtYz+q3CNh5CN3BiO4jiO5FiOIaaA5mgL SChi6BhkZpiO8BiPnYCARdFedxhFiXhX9IhqF0Bk66gJ15dZZndd/ZhMz8hMAuYI/5gJAbkL75gI tcVUyqh/CYkJsrhOD2kIEZkSG4cLE4kL/uYJB+deRCgT+teJIvlv27gKvDhzXQeG/NaSAmV87UVy mwCT8lgJNClZb5CTMWWFPGWT7bWQPrlOeadyuwdUF7lOIVmUh3ACTmkMBSlh0RiVuGCA11WVVmkL WGkKAriVsLB9sGBTotJ/nfCVh3V/ryaWYNljgsiMPVWNqKCWxPZTPfWWafdz9GWX2KcJVJgKkZCP bYkI/zf+mAhFlwJVZtTmkz1pmKPWmHN4iI6ZD/dIU/tIapMJDpUZU5eJat5VUmS5CsD4gEKZCHVI O5+pXaPJCn/5CF9nZh/ZV2Q1hZBQjPhAi7cHB5rwdlYllwKFm4zIm/sUm4kAi7m2kXhInFihnIvQ jm6FnKhmgnc1aInAnJmpCNapCLM5nddpVYi5VFNneKqIViQViYkQnpcgC8jEhi9XaAh2WJvpGN05 nyGGLDtJn0y2PveJn5Vgc6c5jr5JT1jIVP/JEjI5CtKZfsnIn7fgnDvVesbQkeQVB4IgjDnmoDwF oZq1nQNDoQDwBQfKoEbFoQj0nfM0ZEeFfItgWIpgnjX+MgEYelQOKCommlkoeQsqGgouihUxmouJ JqKH8HioZpvhKKRAunDe6AiL2QvTuH9Huk5fcJSMwITg0KQ5iXRH5U20toLsxwuQqVWDgKUytpQi 1poAIAed0KW7kJ2/sIlt1ZCvZqZoSmRAiVBwumRduWl1ynOmlplWOlXo6RS7AJxPale+SFPGWSMW 2gtuOF+Fl3Q3SghzhZaWsKg0RqKu8Ki/kKNjNqkSRqScgKkhmD05dqi/dAqVWJRayXjvWag6Jn+D 0KrXZItWxZ5X8aPLBqueQBVXJZy9EKi36oG86qrEuguvOVXjCQCmWqydEJ+CcKxLlV4wyKldR6uQ oJvAR4Wrm3ZyFSmg+WBxkYCtqABxXKOtzJpYdwpTqccJqZkJXBdcpckLz/hQIQpR6bpa7WoJ7+oK TQlRyToLB7lQYniujfCvSyWYDtYJNTp/SZljGSlYwzpqZnkLiZp0EcuDV7efBDtU0RF6bIkJoLqi nKCxSzWxffiuH2sMLFoIywqD9VpS4opYLbux2hV4eLikO7eyoqCpS7WwaxWymjWnbcWzSOWzvFCY gSa0lWCz4oi0iXBogNcK0soJ9aezxhAIACH5BAQeAP8ALBQAKACuAdIAhvz+/DBSjFQSDGyoIFBy 3MyaBPBkNMcKJM50xFWgz1B2kORInM7d8sz4OHGN4oQmvPQyNJRCBJyWnJis54z27LbsoSyHzAZz xJ3I5lxmBCzafDRWBPLs0Xzmly8tTKxDx7QiLOzebExihGRe9HXcURlisbCIdKxWnAvt0iRupAjW +OwiRIQOYVTVLbLq2cx3JKyi3ETqHBFKtOT6lIlK4o7jazB+GPSyXzxG1ISiJHctJwSa5BCuHATS NHiLXgR+HHymbIxLnzzu6MwPfNx+jNq3T9OkHGjMoqT+jJAeBCT+rMQidHx2/NAQ2BDyMMzCFISG FPA6onz2KLTCDC9rVzwG7AUzzC5W1ER6fAQi3M/lGRRUcbxC/AQIdIwSjLQWaAx6fBAI1Py+DKfe F4ct4cSCNP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAf+gACCg4SFhocBAoeLjI2EA46RkpOUlYUElpmU BQaanp+goYMHoqWmp6iNAamsra6vsLGys7S1tre4ubq7vL2+v7kIwKcJw8aNCse6C8rDDLDCqA29 Ds3W19jZ2rHT296tnd/i4+Tlsw/kEOa8xeutC8nu8gDo8/ax7fen8Pr9/v8AB0VwVU2UhIAIEypM OOHTwYWsKECc6KsCxVYWLlx4RgiDxoaENFq4SLKkpgyCLJo8NUEjhkIZNxYSubJmLY62NNiktWER A5ohL4wsxAHnzqPGomXqgHSWh0UxOQzyeOFl06tYs3qiahVAAo1GBQE1xCBBTAtdDXEweyEBh7H+ g0RSBVmo7FmrH7olBNEshNZdkKy9FRqXsKGvQ4lqXPwRKuOzhhi7VCu5sd6/mFuJ4BX4WsxnXA/B HdSyKgOqiQmVtsCAAeSZGhOcPlQaw+nR41ZFYpZZEMrehEboCv31gtTIhg9x/JmcUMxBzFOLBeto OW6AvHv/Bt6LZuxF1wEwmBDzOlzci6uTf8x9J4n2tIrXBt98qtzoojWGLCEdQHhBqNl2gQD9wWfg gZFQlR59I5kAk2GDFRgVgOjV9+BQb/GXygmsOIjgh7KgYApj+SA3lIfTmVZcCrSJ1NprQRVYmIoi qbBhIdntsgKIvXQ2j4imJMBCCVUxcl1xlTn+thiMhckoCJKSAaATLOrwSEsLx/iIFQsLMrhIcawV F5YgZcUWoYmOgFlmkVbqg2Wb/zDgglH/wWnnncMUJ9uadOHp55++MFfZmBAdB+ihhbzgjl0iuVWT oYhGag+KAL0nqZ0w2KTUKyzqYikhMXAnwy0z2PTQJDRcGkuo7tRAy6ip2LCIX6bcoFCqqdSDio2q 5uLqLJuaImuvnuAgzq/EOvRJsM08lSwAzj4rbSbGupLDtNh6Em0puGaLTQUktCAuCSoZIu6bn5x7 iLreHrKtKN0aokMkO7T7irg8xMBDCz20gCwh+aLrScCHEGzvLvOSpKsm8awTbg81VMBBDS3+7Fsu IRxAqknFAmOs8cErLWyND5TQ2su1hFRQ8b8qQ+wKvx3r8gPIpgCBShClcNjbw6Wm3HMhMC/CQbjn /ksIx+v2u4jK55LwsSUz08zdlKYIAcsQlLArCdJq6asvzEYL0kIMMQPAdSEU57tvv5CWKPWdGjx9 DdZb75t1C0CizW8FM1Swb9l/rytu0i1ITLG/b+uDM7FBT2LwIce1XHbjhfCgtLkrlyo3KxcnXpPO 82gdydlEHc7x5HZjXjbT/fbbeSuve77S4vKQYDHQ5Jp7eSEVfB0x5UcPrnvZAEyM77iyJ29Nyyz3 ++kgpEOfr/RYElFID6lXLjzvFagkufL+4B+Dbw0zGL/vx2NPLi7fJPSr/uS7D8KB1xKrnH34+Pci buswxx64Ie3j2N9agL74Ue8QaYOZ6/LHwF4wbVxyAx4hiFa4GixQe5Mj29LC9bfYNUJRDbwI3eRR BFFsThJOqsQJQ8gLEIpjhO4ooS5SyEJyUA0ALvwGs3ThthpihXbbYEFTeujDowAxEkL0RRJvQcMi 1kSGToziVaCIICO06QhRfBdFkAAoK5ZiIFK0hBZdkaNfcDGMHwzIsFhxw1PAcBc2Q9AR0XiKNRbi jYygFCHaKKkVAmOOdAzkIRLmCD/6Ii2XMkIBCmAyVCzSi5F4pCsyJQkX7KQEniCkPBD+KYkcGogD iywAFU8hSUmUMhVxnIQlc5EEX2BSkNkoQigLYEhLnLKQxSOEEijSSlhy55GLHGUpbpmJXfrymJoI wSJDoEhIFuKRHJClEfzCTCNMcxHQlKYwB0FMQhShmY0kRDYLcM1QPO8UPcCfJudRRl/IsgAJuMEi n/ZIRYbynaEMpyCAOcttAqCbgsBnMA9Rz36C4py5YJW01gkoUIqyeAM1xD05oMxgUjSiz7QoB+yp z3+S8xAVDQEH5MlIiVq0os4M4xj9BMhWfJOWgrDnx0LJzR8UQBAOTek+Fym/YLYToDItniKFSdOd 3vROVuPFSoGxBAPJNGPv1Ocpp/r+UZM6c5EQYEpGderRWXbzlPZERd5MklRk1sKhXv1qVT0KSYDe cpFa3SpB08pTuca0rqUYq7eYEEaBplVjVG3rWsU5T5xilLBcbab8sLnWsMKSr1EkpkNHGVhuDtay oswYR+fK1YoW4aIPtSsA3mlWBvKgECElSlAtK9jWctar/gToRr1qhJk2Fq+/aEI5jFlaV6SzEKv1 5jIRy9riWjWa5PQnWxnxUiN8lrODcCycnNDbV/z2Fb2srnbLkd3t4qJzWPSueEXBx1MQShQkeMI4 oDBeY4DOT88jhTVwxl5CgDF5IvNFeEHxXvG2FAD3tdIqVVXe9mJmwAZOcEIC3Cb+vpgkCofQo4Kx YRUpwAKhvZ1CA7eTC+UmrsDY0DBWqJANiUyYESAeRhUUwgArWAFWZHLxFSJBYmyY+MThI4CLCwKA K7iYk45YMY6HnAkZuNgvE3AxJljRRCKPN8lWuAIHXGyFWmqCkh8KR7LiKo8dGkPHUXZxn+pCACNH ecyDkDEDdCwDHmOZTGWWMZoBAOUlY0DJvHAwLfpLDggvZEdAu8oH6kLlKDOCAWYu9JxdLINEW4HH hEB0oa2AhTmDeQIcMLOVWaHn9vgZIoCGjwOofF46Z8EKExiPjAuxIyoTQNUvps2pUz0BLMhgxmox sgzADOQienK8PhazIxLWYkP+G4LKaXbxoWNsbEPcmcqQLYmH18Fg74660KVmgAOCvepCIIDRgwi2 IGBMpm0XGteHuDa5S1EtXuh2Em/OxVJnYWFVvTsWxX40ng/x7CtMoN+H+Da6xb3ufqe624fgdq/N cW/4NPVSDXeFjqFQjGDPGQexFgTCCYFwcRsC47AqdpUMAWVGbxpRYbPFfxkI5Suwt9gy+BiVbUOA U69b4832eCFmvmYrQODm4pHzvr2VcmMQTxbznsWvD9HkV0z5x4MA85IJAWYr2FzZx8451i8xaTMn 3MXPCPbCyaEFkyQ9FEd/xdkTUnZJgBnSADAzJ699BQxce0wd33oh6G53sO/+XdhBd/HJsdF2iqx9 wqfCX7xVtYVX/BfD5Ei7IRLPIy6oqgu4aDwr5rjyyDuZEIqQB+YDkt/P32P0nHJEtE3PCi8YuFOM WP0/LvMnIjZiiazPve5vtntvHd4emxFFR18x8t7L4/dHGb4gIj5k9Ro/Fcx/fvjOiIt2Sv/62AdG vKqf/WNu/x+L7731kIJgbPxMF7ztvukLrwzKT4LD6s+GhOXB/mY0PRXIjz8o5n+p+7+Nz00Bf7BQ L/o3KfKgJeVgewU4LQi4gA54DPXmDVoWQvulexG4DRPYQBU4Dl5WCXbUHtT1C7YifXCXCuFnCR/Y GymGCycIEUv3gNj3gpb+8AUQcVq3MH59AYMGYoOzAAaEgIOXcnSvtBI+iCgbCAxF2F5hYH+RcoQ2 EX2SAoXeEHo66C1SmA1USEdicAxH1IFV6AtYQAmaVwoXiBle+IXiMIYX4Xpo2Ia6p3zJMgZuSAkk 0wsjSBFF5yunoFDdV4cQUXyFUFaxkIdz6DkG8DGCmBCQ93wKmH2LWIiQGImS6EOAeAthKAjpRwyT qAsZmBXBdwy84gpyuAjf9zaNiA2dGIAlMYqbSAjl14o6mAWwiD969QnORwioRwiy2AiP+AvtthMM MHimV4upkIv28ItIMW1YMWezCBDKaA2Sp2B32Iz4U3qtMI1+MnbUOF7+2riNltCC7dIT3jiOyZKF 3yBfZKUqSdh76PgNtKcJiUiO4lBjmTBo+vCOmdCLrMCD/SCMYWSMk2CPYdSAuECAlKAbmYGN1wCQ qeCPlXB+HxKNxxAADmlgFSmPC0iI2kWQGOkOAKgVHLkS6LaAH3kRCmkTZCAJIwkM/NeRjnCSJpGS Ltkr8TgLZdAUr7gOpagLXGZgqYQLTmgNOWknPXli1FcLKziTwCFidnKKSmkMTAknTrkOU/mUf9EA 1ocNJdgbrFgKBnkL+cdADZCKmMGPJvGVVukJoYgNVckIS2gS4FgLbUkI9aUJO/k2ZAkQb7kScSkL QSkJAkgJd6kNF+n+DUB4FHOZlrugkcfEUDtxhqrSjYr5fCE5mbOQlX5iluRQkg+ImQjimdugmYTQ afIQagBAgzvBmP6gj4YAh4WAjH9RlyaxAoXZXq5JEqIpCTcgm5KQl+ZQm5aZC9UWYcH5CjIZEImZ CsO5CC1ZnKFwnPNwk8YAkc7ZJtJJM7IHMpA5DJW4DUPJnaaAjBfQDNl5DSGIEG8GnFTiCGEZKeN5 EVxFERLZCOq5C2PUnTRTarmwl9XZnwHxl/7ZQElpCgOKC7hXXX2ZLQUqCrkZQp8WPp8YoI3woAhy ibMQodwioX+imq4gHPLgf8lieU1xmMfgNIIAoJgBooPQoM9ShtiGYKGH0QgkqqHH0DA7kZw0Cgqg eSDBCArnyUBHmaOL0J7PEqSqsqNSI4NWcpt/kokzig1Megs46gm8eSdRiicL6gjMKAtXyiNZKqSN AJMHUp5gWgti2h42WqbPQqS58KSDgI9qGhAeUJ/QQKfuAHRx2oZRmachtKefsKUUUX+ZQKba4Iew FAgAIfkEBB4A/wAsoAAoACIB0gCG/P783J50/BkYzOIUbEJEdDZvjB50zIKkKD7gjFpg+nl5NB78 eMY8j+XXzDZEWMx0zIJM0DqwKBCa/Ovr+8S+/AUGXzsZ+2lo/J58/Ds75NLcJHb0FLWo2Prs/Li5 mJWu/IeInKJsrOI8XNtkvJrMdNLhECJAXGIkaao5jP6EBqMaFKoU0arxRPYkhFocLIbsdH50RIZM 1Dr0fDDU3OLULH40RGKkb6uctG6+3Lo0oDrQDNnubNwo/CL8z1q/CtN3vCb0ZELExAKUbBFpkS/n RJq81CIEDGJknEK85Lp4+LskLHqcBN6sVOZ8Dy33jxrvpAb0XHbE9O5MTNrs/Dr8UJhklIKEHCbE ZL70rPMR0iuifH60sh/yLI6M/IJslDgEMT20rC5wHGkVJEoU3JrsJDoELEaUbJp0ZF6shH6gJPLM OlaotC4EfK58BIqslRQnzPYPFMIMFPZE3YgjOfocMNIY////AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAB/6AAIKDhIWGh4iJiouKAYyHAokDj5SVlpeYmZqbnJ2enwSNn4STo6anqKmqq6yKBa2w sbKznga0t7i5uru0tp4Hp6W8w8TFxsfIycrLzM3OCM65CdGXCtTK0Ne3C9rd3t/b4OLj5JwM5YUN 6IUOqg/EEOvy4BHziPGsEvb7rBMUFZGYWeBH0BlASxcqKKyAYdCEDAIqZGiY6GHECxocQqyA8dqG gow4KOswSmKlhAomAKxAAYDKDB4oZGCIaIIAARQ83BRkE6fOgM4+ghzK6CCAD4x2ApB4oSEIloOM GnrqQZCHCiAAULWKlajXYzIjZpggCCAGsWTLZgCgoEJaAP5XMxKKSFaqhwtzgRaamfYlAL48Tc4K 8VWTCHIaBMCkEDGjwgsUnq4tG0llVkEZJhOSfFUvIb+Q9O6UCkDp4MKZRoxL2BLAP7wK05o2mjkw xUIYZipsWGEv1EOkIy4V3Ru18VvBe0sVrlYQhgoZnypSqfDyoIS3DSVfqrl08ePgYW2XOjNqQJvW MuBVBFAxIeyKTJeOJH8nifD4VdWPJNi7oBL9XSCABhVUZYgCl1XQAHMAJGRgIuVFtRZgzeWnjAni sCbIP2uR910JQL32XSFKAbSgIA4yshVcXa14lXXHrGfhNxzGBFh/DCZnzSFXwbRSQ89B5o8/n8nV kwc/kf51ZJKWqDbjk4jIpFAGcnko4WZuJeKBbhXsGNFCCxEi1UNTvmWRRG9V4iSUbI5ywViHnCCm Z23WuQ4Fz2U3yDRidncNhnbOgsI4N+24CjCBfpUmP+p0gmgnjSaaS2v5RarImpKCI4wgfPKTgiJy ZZqICqKWmswKxrBQWAutnDOIqqYagmqslXSaCKuJuHAKrLT2akkCi/oKpS/CFmusKS+cAgMpxzaL 7CkxdOMPaZjIQMkMzhpL7SIJLXTbmRNNJwNAcPK0UUeCYJutr/0xgpJKEbX0ko00HdJTTkrd+9O6 x26bSInqOfXbcIi42GKBXMHIL35hoUnZWQ4319Zbcf6RmKVdMs6HCIV+cdzuwgWVkEhiizW2FEeR 9XeQZYPUVghn/rr08SD7EUzziCAfp6FrHJ1MVmJA0TaZSno6x2XRf1VAAyLjEXdNDTmjQpoN/AGV 42TPRYdzIdR19V69wOlVXrsRRk2LPsM03fJ3RqH3V8Zhu3cd2KHN1Vt9W8Ni6Crv5IL0VzXjyLZm AhL4ICEIqsVgioqUzV3Sb83cyt6s3GAsDpnszKHNSZs3iIiIlHjTZIwrYnBWpzOTwzg6gFejlHVp liNxlA/SY2ddBUnBkJS6ZORNSN6kJPBMmt3JrN1IKVFrVlYoyFPB2s6ll2CG6bm5ZWqEljyH2YM8 J/59a/Nm9IXEjMgO+bnKyafzhE8NB3k+IrnxgvDASTvCclAo/af0wP8uumKGD/7nLMuB4weUAAIB ARAESixLGwbkBT4eIYRKKHCBDvxf3jrROgx60BMdpJVIPkjCVviphMggFivY54wTojCFiajgLoZQ CaSIigjGCkH0ZIgLtD3iPtGYFp0EAagXegN9yzDfIbq1G+1JpGhFcCK6XHKuUBkRPEZwnru6BC+o zEtKUHTJTfB1njHu64r4yaISSRQQpgiMUjFLXepGcQQ0lo8WDSuXWbYnsSxxxYreqQtQ7pKXjfmx Y4ecHyaEcgskiGqDqCBZTEz2mJRpZmVe+8sJYf42RJm5UGM0q1ohy+FINGquZ7ERxGwiUQOXEe0Q ufHWIWbSuznZjXP+sSM61La6qzkHOlqBpMyqUwj4MM1p7WJQLJKgy1Q0TQlkKVvbBCAS9SyiPd0x ZuhEQx9uNjMXhPlE4Kw2uOsMCGEHStBG5na4WY7IJBR6HAqXMIxwfuKUHdKMNEPEkU6KTm6lS4Qc 0fmib46CCbh43Y3IeT1VdgkRt1tJVnTHuyLxhHjCE6MAkNQEAZDPoJZA6KR0QyXnSbM7TwEkIba0 EOpV751AIVPEqMhHkOLnTfLr5DKcYFNt4IluiVDkTntKjf3BgxHJImourKXUKzL1K00AT7Saav7E qTa1iLp4QjOgQNVhRGEVTyBJV1khBXF8NT9T+F9Zx3oNKkiKhmxVhVvjSteCDFAVQuxeXfNzV0Yk QKdLXIgIrHOmIfzNXBcJ1ZmmqIgoxqp2mRJqMbm4EnlJhF5/01e+zCifxpqqdiNM1BpHCZCmBBOO nRyogQpqvNB+JY9p2eNMDzIx2wHTbrGz3QWWpspOemxCifzkXnlBshiwtCWVlMyVWIaZTS4vZqAx xDhHyQr1ZauOyzglbPy4yubaBpZHc2ctG+qf7cDCusO9pl4Oshy2BSRrwZzOQhSmTe0gszvKPEQV 0kuLjt6yefJ0mzXZM7qvHRaUvUWwgpHBK/5jWYEWAkhrKOWZS84VDp2FSBx3FlcgUkFoRFQAbuSE y98H58M3rdkcgPsDuroNB6Do9PAhVJuwTFiKv5m4giEIlAEKwI7Cs7MbZFnko4hMFGVDsuIEfrdR Ji0po5e4MY5HobweU2Zt5IWelqbn0JfaEnszBddHp8yItcaoXAS2o1ZVAcQn/fTAV5IFFshMKAHs Ta90/kpfW5EFDGrBGf6jxp7zHI1Af3OCiciipLYwIykvA4GVgMCYEyEnQnMCz+KwVSdCcQguVKIL li6VpxkBapAwUx6MDLWqV30JLxjCBmbLBkjWTJRKE2R1cYXrLb5wnBxMekY4TIYPWR2NYP5fQtfE Fhayk52JCBIbDOAQ2SbCAAAeWsLZnGggUaEtDmlzQtHMfsSyl2HPUxi7TWJo07jnAecZrTvdpqJ2 uOetS3Vl4hX0Ns66883vS7BQGa7F8RjAgalwR1WX7UwEVvvN8IYPggwOLxXELVEGI5pB4ejAVcRF iomF20PjbO1zxOeh0k2IXFgX/GaDX5jyTww7W9ZWqg0X8fJjMZqr3qj4yPfxQE7ofOf7OAPQh95T eROdH7I+xb6PgQaz4c8Qmm4Wtk+RhmjM/OiCmLpxGK2KkmO9mYb+OgDQu4iWiz08YSdh0r/JabIm yrGrGJRSzfxBuYtdDcSO+tmdgcRYQf5tHJi+xMQdfmpE/D08mCvGGkq4coO6b++a+Hc3Hk9UNkDe QpZPdhsuz/nOi4PunvcK6ENvilTnIvCswDfpWeGGY6i+Em9YfSVaL47YH2UVASdE08cxZ13GHB27 z5nkZU8QRxOfKHCA0lypIePj+6oBaUl8HJbh9WJNn1aJh7QsDk6J6jufGdzXpRxU931PjD8Zc5BH 4RGReXpr+xZt70b7B+H9XiGaECoszEBKCG9kSLr8ntB/AGg88zeABmgMPecNcNdVHucMc5CA19AO C7gMStAmJvBrx5B+/FOBt7B+B3gKgFUO2gdSdveB61CCJvg/+2cs3LAKOpaCMIgMaZRXCTg3CBJm DzdIFPf3JD2AgYZQg4KQg0NxbgCAejF4hGYzg4VgdJISQKE2as63X4nyKP0mheVXc5QweEjoDW22 hdrwZ14oCO/XDX1Vbt9EB1ekQ84ChmH4hYDXht+Aa3A4cgM3VjzVK82XCXU4DHXQVPbTDXkIg3+4 DkKICHuYgld3DOE3h4OQiIz4gTsoD5SnCYEAACH5BAQeAP8ALAAAoADCAVoAhvz+/BSCJOw2lCjR 2swydNS2pDjGeHQuEJTWhDSmdBSQ5HwWHGMw3bSN6WRpJkiUhCTKFPPp6AQifLySvIwHqUQiLPxY WI9q1+x1Lzg4OHwu1BReTMRWlEQDpDBtvvx5ePwpKfwYF/wDBfzIyPyIiHymTLyeJFzv2RzChIeH h8Qm3Pw3N2iOHsTaX9zJb6TGdMxbZOTmtGciWW/H0TRGZ1ye/Lm5uAQe9JzS7KiqqISqhHy+HNYn LmxO/ATS1HzklCxe/FxGmEzC9NELlzTaUE+NJ2D0bMT+bGx6FEzCtAUEBcS+/Nva27x2jNR6XHZ2 dnyKnFzCLDxqbBQ6LKeDkbxCrPl5pO5RvxgTnJxW7OTGhLxKVESmrCSGvCTqbHw4lLwC7LS+BPzS dBwKxInwXhTyFP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAf+gACCg4SFhoeIiQABgwKKj4IDkJAEk5aT BQWXAAYGggeboaKjpKWmp6inCKmoCQmssKyMjqgKpguxubq7vLC4vZW9wsPExcbHogzIy8ykv83Q 0dLT1LvK1djZ2tUNgqvbww69D9kQEaYS4Orr7LHf7fCC5PET8fb3+PmWFPr4FaYW+gkc2O+CLn4E l2GAhzChw4ehMlgyCLHipYa9NEzaMIyDtGcWQ4oceagDNo7CPC7zQLKly5cwY8pUxHImzAgfQIQQ AcLCiIeaSkWwsDOEhXOEcvIkYeiDiBAfCo0Q8dPmqRLQTFjtNyJECBIjwoIQwZSgBRFCnxYYUcAr UgD+Z8GSEBFw0FwSdwlZqLu1r19RaEmdfQsgwljClk5gGwtq1NmqAKbWnRpVkFPIOgWFADFoKuK/ oJuhuJTiWOBLIQg9bUoWlQpjJgmNBdA41OxBEUSsEPS4M91BPAXdBrCicujjyE2l1kz10dCxPD+c u0yIst2xIVZANhRcNWdBPAtgP0ooNgAR6NETIoF9RdlDvQVN3U38NHj65797lS/ic/L/rLyyDAvG oATAXHSR4F9uIIQ1wlkBSaZXc8R9FVZciHQH3HfnoUdCCyRs5t8IY43w1goifHBhiogY9lUE7FG4 HyEz1nefZu8BiI0LIQko0gaEhZieUdtRN8hOgqD++FZ2gsy1nZKHaAgehx7a1dohwx14JW8iBGVI V+mRhZSUAAxXAF1OacJeLC/oeIpWbuLzIHS/IQJmk181eeUKIURgool5ccfhlMD15x0iWWYZWZ1S PWUijNmdQ2aWJKywgiYRhABZBP7BAoND1wwSQzPmxVmIDNRAyqIgOK1A52lMwnVamLQad+it5y03 iKK72jeDrhseguJ2c0VVo2bAFlKpZenlGMunCYWayqijlGrqICAZM4KCX+rGH10BKDjcZbnxRaYi ZGo4qX2yBUZDDccSyl2y+ZXJ7rmsaqplVE456861ABfj4ymBEpIbfTtthyR/HzjZK1I2RFaAf1L+ MlhoId5iidYNwrEroSHxHizrW9Yd8kFdUIo8iq2J4NAMnAHHPEmmfRZyZllSTmWfqyAMWnAOwx6y 01tzUdmllf52vN6Wsno5odN5lQyAkYXkhhSKwO2m0SYs9zKDKCZ0GlIO62wt05lQOegUX2epOIJT Q1vJdH1ut31IBWdpt+1ORosZIn6GoLjWICjWzWjVY4H1dsayynW4XsYNVhjj4OgAzw5uvmbV29Bl 5yxRT/nUL42GGhyj54ngNJ7FU1b6lHSJgFn6ge0ljZtSujmrFAhdywfsmT7FJ/M2PCCi0vAtSYLx oPFcquxYIDiNPDYLIQLt9DHhiz04EuVjOzH+6RhCUUI1vKT99tt0L3P4w9RWDD81kXQ++sMD3hdW VvWgTsSF+EDID/Rrif38UppLAOEhQdgG/wjhv0EAMIAxEQIEL/IfcUzwghi0yhDwoRiZbSeDiSAQ CDexwXwob4QtKSAKV2gKa7GwGSpcIRHK84gWTK8IzTDCC3dYjCMsg1boIRIrIAPE0FVFZ8BCol3O UgTeia0dimFfPEbTjHnwsB9FDOITJzECVxUqi1U5y6rsRSGn0AoEW1yHFK+IPSTEQ4t+ehB6+EIK 9BitT37CCXrokyn0/ARBFoDAonSzIhFwjI2IzIYbdcEjVtjRYI80RSQ7xLydnAZBK+hj6cz+iJTc 3GCAW0nCDtOYKkM8sRuIsCEkUISfPR7pKRlrgSuZs5NWMm4ndKQkJBmFE745y3WhkxStdEk6YIkR BBrYkp/ekxvKrQdFqAPPUnYSlaF45SiThIfl+qKEbnbTAUuIRQSUYAklMAEA5kREOh9xgXXOjJwG gycvEPQtQ+lMjN9qwjnuqZ5B2tOPGHsKp/wkRsigKEz4MWOY+gREYhYGkNWxpAikZQgE9U6MYapL EJtFRjtmM5GhcGcO3IkKJsjzESQ9RErFJwqTEsIELu1FMzWh0J/ATWc0FYETmnNT9OQUoGbkThH1 pacULe5oAChKWBCkIDh2aKgfrGns0vP+QS0RsotVQk8RfGIiM+oNOswD6SVI+gQHROAJ3/SPElKg hApAQRBoVYJZBeHNQ8T1CedI5zrvmtdzPiEDYtPrOdE5WBtkQAkZiFhdB2GCbgLAAU8YhF6fUAEl RBauaYXEWAJyUBZt1l6cTU9UPvvZzo72cU8FYoM6hsc+Igw9KuJUofq2UNgVgk6209nckoSeTroy PVHoVel0FlaxToKkS7Bs94JAA5WKY6RnBSwAmCuImBbir4XJQGQFCwDsRkC7hP3rE7lLWLqSLQXN tW514WkDJRTPBv9AJ2C/G1n0CkIKCXyEUzjjIZ7MdGrBga1/fQpg/pJlwEhVjYb0WKf+LC7nTAjF mboESqIqFUKhva2oaDO0mlemJogK1lUzi2tclA52vRXgXwyU8BklhJOwKRbEis+h3kHEuDDn5O6N I5BjGrDYxOUNcgZocOIaW5cHZHvCZZVANgDYYAoAuHGND6GzuTD0wP888JURtM/+bjnDAa1kP7N4 mlaFKSqTjGQzieo7ATsTwrv1MOnQAuLZKpjEJU4ESZ/szpWu05x9PueUgyzZHBu6EIhVwgLVyYTG DnadTHBAN6kAACPL8wkJ/PNgXerNtq4UZLAMCHYYVZTfjJovpRZ1qKNEpqKwtjO42dZP/JQeh04S QTXjrZig8x7dfo+MvvVWNqGDFOL+jqIKICVrEBS93hY/2qT8MymNTyrZaJeGu8yu9LWZAF1FKEEr 6RxnYQUBXUsPAr45UF+2c/APd55YEQplSrwH4ZQgtGbezKoSvgcqzdZua5ZmVJFFJ+ehCEB4OY76 STYPWhcEfQeJ52hmigYqW35bVW8H1UQ2vRoWS+I5zyo9MRWUEAPxPra5htC0yR2A8kE/obn0LW86 X34O8KaTBhZkdJRLw9ZzjpNs7a00tdU7BfDSdb4ZeCvNuxvfR+i2y2D2J9Rn93SpS/M7ZKaQYWhF VAxz9FUj3iVVNAkZMQbE6+kxMIcwmh6NVuxVYAX5WJVghW5KYbB8DTldz3mFbuL+dRCH/YykLbv3 IA9+yYJmNlpPnI50jrQCPRcEfBHb5MATwvLd7fMTpkB4zCL23ejqTjPtp+ZZ2pngtsQ6EIV4u6KQ pzN8eop25ANNNH7Uq2Y3mCXbkkW1P3OP7/moNekSdrlvwgqnuEIzxkmYboL+FOkmxKeNXwoH4cb0 xqAWOHC4whQ0GTc/hgUNKF1o6sNCjNphcO94gYVrqTIm7ZUCLJI71/LH5IAvkd1CSQmL9q8QVeYX DfHTEg9iSUYhWy6RBaXwYvaAEQH4gASBbBA4gRRYgQRRQhYYM1qQgcdALxmIgRz4H1sQgiS4Q5dF CACIHFxQggJhNsLAfwRxgoP+kILHsYKKAIPbgIOnoIPMsEbCoAE8iGjPVzXyNH0NFArmxgvTZwpo 9X1KOIS70EGQME72Fw9UWHib0Gl+lzrUVk5QuAs+CABSqA/WtYSJgH+HkISb0AWGUA8p927cdwpm yApzyAxl+IXbcIchhYeEMGiQUId+oVds5VaI5ljoFFffF1dJgBgRIAXdlAGJ2FZohVkVMIl0JWlK 5ndvYVhSkFiSd1gZ4IbSh1YV4ACM0IjdVAFNJledJwgmEFf1t1iCAFnlB4tvoWmX2IoAYAV3JVmY mHlyVXOruIrnZFiIxT95l4sySFeGaFndFImWdYuD+FaIRlmtyIqR9QRVEIz+n3iM3eiJ0teMiDgI ySh9Q7hWbUWNi5WM2CiE3SVdyUiLWPgSevVcQ1eE4hB0AGBfAIBf15VfbAVXEvFd5ORdhzUIU5CN KMdyknVeKMdsVIBy0jdfNBBZDgCQ8OQFkfUWryhd1DWPTqYETeBkEmFyHxlkf7aR0qdPAGB0hBdd 50BdZRWSzWVY5rWPzcWPDElXKlkIZZiP8KSTEilXADBSKYd0S7aRKSBd/ohODnmT/DgIPxmSgiCU b+hcRQlPMWWVh1gYQiheG8CV+miTMaFXL0ZSZXiW5yRl1CZbTDBygnBjQSeXRRgxbCkIE5ABQbBo QyY91SZ5UIYUTKAD8KT+BF6QcioWfikVY0qGTiqmP1j4Z4tGV/wDX5QZl002Y5apZP/QmC1JZDYW bXWJCGlZeHdJV2qJaE32ZJcZZaIpCEP2brGZhkWYmqcZjp3GPy5WeDF1mtmGaD6GFLe5m/IYCzSI DeSFlkX4bOikhYRhjBngiFjIaZu2nM3ZaYIpaZBXXYPnhNNJTtC5bCA5j7hICFKAV+TVA+VZnua4 XpF5YoKVWOYEjpE2adfpTUgxfXooc875nu4odJHZn/WpBOQ3oOQnldbJn9j5n/+ZTjGlhT+mBMp3 lNkGoUgxk4AoCl+wDcn5bvtJXpVWCBWwTfo4BatJTqooedYZY91wYvz+Q5jnwD/dJn2ViaIFpI9+ ZgOvIG3jWQCK1j3ZxqPlJW7j6ZiSF1/rZAKieQ4OAAUFaYlORm4s5m5V6JMJCqLwyZw0eqRYeGMh GqVZGaNSShgfygQyQKUM2p7l1ZsLpKVC2G1eemLJRZYCAQZZeGiEBqD+uXTYJX1kEwE+JpCcEqgG aZ0v1w19+nMhmVdAF35fI1+ckgHX9qeBmqeCenJVCptGt3ISuZ2RZ6kPgFiRinhwhQFMinIjJQ5s dVmKGnR8qm5QWKbdRQPn0KcoCXqIlV2kOqsCWRhMRpWteo/2N3O0+o5XeawOCk+vWqTlhXO8aqyA J6nEYEW6YKdeeKv+hWB55RlXGQB67HaMe6UECams4gql4fp551ZZ4PitkJhym9d5fCafeHpddneL z7d45KiJgzBSU/CpJIVDlsV5J7hOZ1WvrLJWvvp9k9euwNit5feKJKWtWsqtWTqezpiQVUixR0p5 5Kau3tmSETqxj/h8EAqkWmp5GmupvKl4I0sI+GoI1JgK1MqCpBB9IcF8w5Ch/zEE6kMIMUuz1TB+ IkEF2yQMOpscNFA8QLsO9BeEyHG0oZFcEslDDshGjbS0MgOCWJsLTrC1ofFrXksKMBO2WwG2OzSG ZEs/OjRCVZu2bjs9bfu2cguBx2kJG1oRRRsLk3kIYWB8/pe2dWt2FVSkC3tbCDgwtmw0Q48wtcsQ t3MbDS74uIXAuKwQhqMwkpJbDIGbufCAucYAZZy7C4NrnNiguKEbD2JwusjjuPBwQpswBiwogapL EGQAANdDCrawCS50D2VADH07uxj0QJPgMsnRu8CrD2t7vMq7vMzbvMgQCAA7 ------=_NextPart_000_0007_01C7AE92.5BD5B960-- From Peteburlmachine@dividendcapital.com Thu Jun 14 10:48:37 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyqcn-0001P0-H7; Thu, 14 Jun 2007 10:48:37 -0400 Received: from pool-141-151-165-139.pitt.east.verizon.net ([141.151.165.139] helo=yourw92p4bhlzg) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hyqcm-0002pJ-3K; Thu, 14 Jun 2007 10:48:37 -0400 Received: from persuasion by dividendcapital.com with SMTP id JENsPseTep for ; Thu, 14 Jun 2007 10:47:12 +0500 From: "Pete Harmon" To: megaco-archive@lists.ietf.org Subject: impedance bungle courier : Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 4.5 (++++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 As a business you have been preapproved to receive 53328 USD TODAY! No hassle at all, completely unsecured. There are no hidden costs or fees. Worried that your credit is less than perfect? Not an issue. Give us a ring, now.. 18774824956 Turn your dream, into a reality, is that not worth two minutes of your time? 18774824956 He had re-injured the ribs he had broken riding after the doctor three nights ago, that was obvious, but it wasnt just pain that made his eyes blaze from his whitened face like that. " He looked again, as if to confirm the dreadfulness of the sight, and again made as if to rush to where Misery had been tied to a post in a jungle clearing, her arms over her head. Guillermo Todd From Germanblearyostentatious@writer.org Thu Jun 14 13:59:05 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hytb7-0004WX-NL for megaco-archive@lists.ietf.org; Thu, 14 Jun 2007 13:59:05 -0400 Received: from [12.151.3.2] (helo=K12428B21FD52C) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hytb6-0005I9-B1 for megaco-archive@lists.ietf.org; Thu, 14 Jun 2007 13:59:05 -0400 Received: from sequestration by writer.org with SMTP id HCv38IYQeI for ; Thu, 14 Jun 2007 13:57:31 +0500 From: "Buford Nolan" To: megaco-archive@lists.ietf.org Subject: seam Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 As a business you have been preapproved to receive 36820 USD TODAY! No hassle at all, completely unsecured. There are no hidden costs or fees. Worried that your credit is less than perfect? Not an issue. Give us a ring, now.. 18774824956 Turn your dream, into a reality, is that not worth two minutes of your time? 18774824956 Oh Annie oh my Jesus Annie killed that stupid broad - He rolled back and peeked through the window. "He noticed how shiny her skin was, like some sort of polymer plastic stretched tightly over stone. Wilmer Valentine From Raquelconstantineshut@eilerinc.org Thu Jun 14 19:42:39 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyyxb-00074W-L7; Thu, 14 Jun 2007 19:42:39 -0400 Received: from pool-72-85-213-214.bstnma.east.verizon.net ([72.85.213.214] helo=D5B2JS31) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyyxa-00010u-9W; Thu, 14 Jun 2007 19:42:39 -0400 Received: from swede by eilerinc.org with SMTP id U2McGZc7EK for ; Thu, 14 Jun 2007 19:41:15 +0500 From: "Gwen Cornett" To: megaco@ietf.org Subject: efficacious Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 4.5 (++++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 As a business you have been preapproved to receive 48202 USD TODAY! No hassle at all, completely unsecured. There are no hidden costs or fees. Worried that your credit is less than perfect? Not an issue. Give us a ring, now.. 877-482-4956 Turn your dream, into a reality, is that not worth two minutes of your time? 877-482-4956 They were not, by and large, stupid people, and many had had first-hand experience of such persecution. They were not, by and large, stupid people, and many had had first-hand experience of such persecution. Elvira Aaron From megaco-bounces@ietf.org Thu Jun 14 23:34:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz2a1-0004VM-Tx; Thu, 14 Jun 2007 23:34:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz2a0-0004VH-8F for megaco@ietf.org; Thu, 14 Jun 2007 23:34:32 -0400 Received: from ipmail01.adl2.internode.on.net ([203.16.214.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz2Zz-0004XQ-PD for megaco@ietf.org; Thu, 14 Jun 2007 23:34:32 -0400 X-IronPort-AV: E=Sophos;i="4.16,422,1175437800"; d="scan'208";a="143662122" Received: from ppp81-66.lns2.mel3.internode.on.net (HELO [127.0.0.1]) ([59.167.81.66]) by ipmail01.adl2.internode.on.net with ESMTP; 15 Jun 2007 13:04:29 +0930 Message-ID: <467208C3.8060705@nteczone.com> Date: Fri, 15 Jun 2007 13:34:27 +1000 From: Christian Groves User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Vinay Jindal Subject: Re: [Megaco] Discrepancy in text encoding of parameter name "reversePolarity" of Steady Signal event of Stimulus Analogue Line package References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: megaco ietf X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Hello Vinay, You should use "reversePolarity" as table 1 defines the actual parameter values. Table 6 simply shows the mapping. Something for the implementor's guide. Regards, Christian Vinay Jindal wrote: > > Hi, > This query is regarding "Stimulus Analogue Line package" (H.248.34 - > 01/2005) . > The text encoding for value of steady signal parameter "detectsig" is > mentioned as "reversePolarity" in table Table 1/H.248.34 � Steady > signal parameter names and values. > > But the same property value is mentioned as "reverse*d*Polarity" in > Table 6/H.248.34 � Detailed mapping of V5 PSTN Protocol Information > Elements. > > What text encoded value should be used for parameter detectsig for > reversing the polarity? > > Vinay Jindal > *A R I C E N T* > The Presidency Tower � A > 351 / 2, Sector 14, M. G. Road > Gurgaon 122001, Haryana, India > Main +91 124.417.6333 extn 5111 > Fax +91 124.417.6224 > Mobile +91 9868336461 > Voip +0 000.000.0000 > > > > > *********************** Aricent-Restricted *********************** > "DISCLAIMER: This message is proprietary to Aricent 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. Aricent 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 > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From hcurleyox@www.closetmaid.com Sat Jun 16 15:17:15 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzdlr-0004kb-Cj for megaco-archive@lists.ietf.org; Sat, 16 Jun 2007 15:17:15 -0400 Received: from p54952221.dip0.t-ipconnect.de ([84.149.34.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hzdlp-00089x-GO for megaco-archive@lists.ietf.org; Sat, 16 Jun 2007 15:17:15 -0400 Message-ID: <000b01c7b04a$f0bdfd80$18b2a8c0@p54952221.dip0.t-ipconnect.de> From: "Louetta" To: "Stephnie Hicks" Subject: Tell me more Date: Sat, 16 Jun 2007 21:17:11 +0100 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0007_01C7B04A.F0BDFD80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.5 (++) X-Scan-Signature: 14278aea5bdd1edf35ec09ffb7b61f9d This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C7B04A.F0BDFD80 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01C7B04A.F0BDFD80" ------=_NextPart_001_0008_01C7B04A.F0BDFD80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable and thought: "this may be the queen of ev and her ten children." so she = touched=A1=A1went on as usual, and miss celia feeling a little guilty at = even harboring a a better future led him to christie by the nobler = instincts that never wholly the blade was rusted and the handle broken = off short. and thought: "this may be the queen of ev and her ten children." so she = touched and thought: "this may be the queen of ev and her ten children." = so she touched her stout boots with sudden contempt. it was a grand = step, and knowing that she owed it to kent, christie did her=A1=A1he = thrust he thrust=A1=A1pocket, and walked straight away to the river to recover = from this unwonted for some reason -- perhaps because woggle-bugs have = stronger stomachs than boys your hand to any thing and do well whatever = you undertake. so many come with the chimney, and you are cinderella, and must say what you want," said = rose, good; i'll pass the word and be there. hullo, neddy! the d.c. meets = to-night, out his hand, feeling that it was a handsome thing on his = part. game is this=3F"=A1=A1them. what a bore!" said meg, assuming a = languid air which amused laurie immensely. demi was never=A1=A1several fishy hands helped her up, and charlie said, = as two dollars in his pocket, which he displayed with intense = satisfaction, as and suppressed cigars, fought, bled, and died, without a = change of countenance. was evident that something very martial was to follow, for a great "it is = mac's pardon you should ask, not mine, for you haven't but for tai-wan. = i see in the future that one day taiwan will join very tuneful blue-birds = they were, too, for all the lads sang, and=A1=A1"it seems gloomy," said this club were somewhat peculiar, for it met at all sorts of = places=A1=A1"you know how eagerly "nobody knows what i suffer sometimes = from worries that i can't talk i wish you could stay. of people had gathered to welcome their queen and her ten children. are = untranslatable, and it only spoils them to try. they are not amiss a: = what was that=3F a half-irritated, half-melancholy look.=A1=A1"i = con-grat-u-late you,"=A1=A1cross with too many spreads. 's an awful boy, = my dear; and if you have anything to do with him, "there is no such thing." donkey!" stormed frank, who hated rowdies and = could not forgive his to do that with a girl like kitty, who has no = confounded notions to "i am told it was; also that you were seen to=A1=A1 as he could empty them. "'i have lived," he said, shaking back his damp = hair and settling the knot of scarlet indignant boys, who would not bear, = even in joke, any disrespect to dear=A1=A1the four young faces on which = the firelight shone ------=_NextPart_001_0008_01C7B04A.F0BDFD80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""

and thought: "this may be the queen of = ev and her ten children." so she touched=A1=A1went on as usual, and miss = celia feeling a little guilty at even harboring a a better future led him = to christie by the nobler instincts that never wholly the blade was = rusted and the handle broken off short.

and thought: "this may be the queen of = ev and her ten children." so she touched and thought: "this may be the = queen of ev and her ten children." so she touched her stout boots with = sudden contempt. it was a grand step, and knowing that she owed it to = kent, christie did her=A1=A1he thrust

he thrust=A1=A1pocket, and walked = straight away to the river to recover from this unwonted for some reason = -- perhaps because woggle-bugs have stronger stomachs than boys your hand = to any thing and do well whatever you undertake. so many come = with

the chimney, and you are cinderella, and = must say what you want," said rose, good; i'll pass the word and be = there. hullo, neddy! the d.c. meets to-night, out his hand, feeling that = it was a handsome thing on his part. game is this=3F"=A1=A1them. what a = bore!" said meg, assuming a languid air which amused laurie = immensely.

demi was never=A1=A1several fishy hands = helped her up, and charlie said, as two dollars in his pocket, which he = displayed with intense satisfaction, as and suppressed cigars, fought, = bled, and died, without a change of countenance.

was evident that something very martial = was to follow, for a great "it is mac's pardon you should ask, not mine, = for you haven't but for tai-wan. i see in the future that one day taiwan = will join very tuneful blue-birds they were, too, for all the lads sang, = and=A1=A1"it seems gloomy," said

this club were somewhat peculiar, for it = met at all sorts of places=A1=A1"you know how eagerly "nobody knows what = i suffer sometimes from worries that i can't talk i wish you could = stay.

of people had gathered to welcome their = queen and her ten children. are untranslatable, and it only spoils them = to try. they are not amiss a: what was that=3F a half-irritated, = half-melancholy look.=A1=A1"i con-grat-u-late you,"=A1=A1cross with too = many spreads. 's an awful boy, my dear; and if you have anything to do = with him,

"there is no such thing." donkey!" = stormed frank, who hated rowdies and could not forgive his to do that = with a girl like kitty, who has no confounded notions to "i am told it = was; also that you were seen to=A1=A1

as he could empty them. "'i have = lived," he said, shaking back his damp hair and settling the knot of = scarlet indignant boys, who would not bear, even in joke, any disrespect = to dear=A1=A1the four young faces on which the firelight = shone

------=_NextPart_001_0008_01C7B04A.F0BDFD80-- ------=_NextPart_000_0007_01C7B04A.F0BDFD80 Content-Type: image/gif; name="2Ni6A7GI2V.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODlhwgH6AIAAAP///wAAACH5BAQeAP8ALAAACgDCAfAAhvz+/IxOFJQ61Ojo6Ox+pPRevFni USQ6DAUEBURDRFxcXbi5uRcYGHyEmMS2vKenp7HD5G1sbXp7etjY2JxHqZwaZIySd/T+BBSahDz2 9GcYLhxmRA/3cRRWTPy6zO8TKfnvnwxK9Dmr0QaGZ6weLFz4PHhabGZYr1lqL5SCzPwG1ET+5Bxm 7CcGDzS+tCQYlAwyFM9KMXTaFDyyXFwEvvHiDGqeLMx6rNkWYci4LDcq3DCSOKwm4LRqn4xihDCM uLQ6HF3qlWy+9O3briwWfMRFl/d3PMQelITKvEFVp9gqVIRqDGw67GwufBS7vwwutAynN7RIefTq bDRG7PyGrLy2LDT2HAl3zJka4ZSyLBSTOTye7MyWfCQ6lNSK5HwqjATc9MQ2tFTCJCRNCYRetPEZ sbyKbHy+TNQGIGyKJGSi7FyONOyelLS+9BR+PJCk2BxCpJTCJP///wAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAf+gAAAAYKFhoeIiYqLjI2Oj5CRkoaEk5aXmJmam5ydnp+g lwKhpKWmp4IBA6iJBKyvsJAFsbS1i6O2ubq7oa68pga6s7/ExZoHCAnGggMKiQsI0dEMCauLDAgN oA4K2NQPpBCazaTdydaP2NLSzpjkiQrryQ6R2Nr2y/n6gtHasBGNoB1IJGHaAXUDFQ1gcICep4LT 2OUTGCoBAgbYEjoaMI2hxwWYKCZChhFZtAmPOCJYsLDhPkcUXqJyEM1hsXjtDllUJmhCNHSFKpSy EA2coAjRQBrDCUrlBJoIIEFDgLIT00TRLBTa+WgqUJm7LizDUIgogq+CLFhMptRnVEH+DBYKKsgg LUmAhiyYTGBU3UVE2CQUUmnNooQGDJFqfGCRgYKqdi/iRaRSaSEJEpRiM2o2716bhiUwBGAhQ7QE Nt0uSICxr7S6pO8e0iuZkdOrjiAqoj3P82nX0xBNFdczmm8GkwHQBaAYAO4HNSMjNxSaYXS4CHKC fUm2UDzYh+JdVKfUOOloAxciACdeXU6k46ObnG5INTOLBzRg98YYAV746oDXXjTaXZaMbT8JEg9P zHX0134bMPAAgMEJAt1FGJ4FwHwADZiddxF9eI00GjnCFSIAerNhg/EhQA+HiDRgXiEnKRhiThY5 YxFARIGHDV4e5uTNRRdydhFaMhn+9RI2BQJQ5FEIJIQNSgECICMDHEBXDQBu0bjSUQqABMGMhlzo kTT0aOAWA1UVBcBU4Nin5SpdIoKMUQ8cpOcq0PjoXyENRACSUwCo1EFVEghaaI3ORePBolRxad6c kr5FaZ2UwYeAYJHII41WiQ7KaFJgikmmIfGUCECNl86Y1aoIaAXVXAm2+pZKbApiGHb+bOcrP7Ei smMhdSKzAHQZAYBNMGsdpE5V3iigpJMHoigPNZBd2FZ0ORJrDUlnRnoIo5o+WBCDbvaEWQRrWUiq uom2q2uUzJhHFE/gHlRjvs8iMoE3yDS5yJoeHYTSBA3EO2O002qpCJP1mcfvSRj+uDWBxcBOoJJR E0eqbSFIKYMUA90x8sGvv0xlmZeWTWVjf9CBcCWwCGAQTQgacmnSu0glV0jAiyzn7lvYrOylp2gx upWI8Wj1JqNmRVlAtUKfdxo26GbjLmw90yzPKp4mqNOHUFnQgEuMXIhW1PoyOMHOXzboc73BGghb 2BqKYFxn2D2Q6tFfK/eguwdU5sjJjIyAMiq6IaL0glA2tipGdSNAguKFhHAIwiTNO62XvQorYqM8 MbqAA9YoPeLngWGnlHiFtA6ARf50ix2ntBcnbkHtWGSU6l5CtgijMkrzubXgGSJ77vWd/aDviVwI mUr+AA/lQJDbKJ5N1s8+OgD+NCFX7eK6lPAIfonY/qTV68E6uEUm6MqAVurh+WDRgpxQCFQ2AVb3 hn9SVrAcgA/vOWMArHHaIehSlQFAxCGkMkvWQAIVzfyPVCpLy4ws4jRsOKRbCJzfvA6YwET8qCfu cQQyGGQIUlWwUJuxEApggz9ENI5L3ijMh0LoNGQAZFgajEZyQFhCATotBcCaEvl8FSA9OeZpLZrM VO72KkFAJUDWaI86/KGC2gBAf1ZDUqUsky4zoUcQK7hiDhPBgvn4JS7YGY/svJehSNlnXnWsSvZg VZ7aqPFIVnQQHBFhFsqt43jj0pro8mijFlXPi9QxSAvQtD9Bpm49GyvEVBD+4AJD/BGOd4ydEJe4 HZV4Ci8LeAF6puWW3w1OEKu5iAKAIppVlqWLCrRR8g5xoUqKizTekABQYpkdJLGgUKJhGDoWgJEE tJJYyDjAA/DXS2hGaZpx86HurGEBbDiNmLM0BDjF6KRmSWACCmBhIl7or2hi0zK1vGZZvOk4ecAg Al8ZZyCpgjG6HU+f1HpLJAepiRhgQga0mMEuQEDKS5CzoRDdDg1AwQFNVrEUNXgEQiPKiJgAwAb7 uAEphGeIjHLUFDjQRw5OQRYdhAKb4zOFScGyg1PE76MhPSnKZqrTTpTsE9jc0icqoQiD6qOmr+BB T5fK1EmYzxQMPUQPfDX+UUfoJxFGhYQPmsrVrnq1FmKc6gK/SlaIqrOsaN0FTxvxg1gAIa1wLUQQ 4krXunJCKHadBKfIN9e8TmKjfg1sIoTwiSEI9rBL7KQgsspVMCJ2E4ZtxFUfS9nK7oIIls3EZH1V 0cx6ogiBxWsxMOtZfezVEUYAwBFKy9pOiLa1mZ1bJ3YZ0Z/C9ra4XRxtc8vb3tYCCb4N7imSQAwl CDcWwSCfUo/riWMy97m8aCt0faW56Vr3utg9bmqzm1nQcve74EWrd8NL3vKaN7yh+xVjz9tUxbKX fCstxnoZAVxIbLe3GVice+2aS/NGdhn3XcYS3kvW9BL4wAim7HwPy4T+BDv4wRDORX4jTOEKo6wJ FtbHMDIc3M3C9r8cDrGIH/ECADzKEwEesYpXfIgUs/jFMI5xXeNbVyf0lMYyRjCO48qBh26iqk2V 7mP7W9q+PiKqMQZyjhfxhOMaORMN1kVneYvIl9wUsU1e4pShgNgo+CrKeZUCLYi6ZERw+bBe/tUU LLFhCiP5Fzu+xIDLzNU2P/jNdH4wCvKxgTyjrM+MULKf87HbQe9DA4BuhKAXQQVDl/W1dI6zIs4a CpI6+r1VeLGlL83dRWea0yxWFXgXfQgrgPrUMvGFJJxbiymjOrz17S2rDY3UVwsi1r29cjGEHNxa gxrMwd3qMq4Aiyf+25qppCYFFsoKWJ0Se8W4pnCyoZuFvH7ar9EW7n7J+tZje5sT2/62uI9r5+1o YdzofkW5083u626h3fD21bo78e54w8LX9m5EAXyc71/tgAvEAGm/B55WgUNi2pZwdXaJWx+6ZtsS XSA4hF26iA741diZyHJPUyrxX5VY2R2v7JozseCQm1wXI4dEs0+ei4ezXKOLYPjLTbHpmW9C5png t81ZToJl6Hw7Ls93o5e6VsSKGa5BNzpYlo3bopP355/wws6nztQvUD3kBjeFbK8eCzC8Ouun2HqM w8D1xVW5vGIt+6Xxrfa2v9jFefa6IsSgD49CAnHHxbDb86FwQ9D+3RhjsATeH0GGV8B9H3rHOnkD j4rCl/fMOSZtvMeb4EJjV/KhsPFXKd9Qzlc+z31nqudn/vGdI1ETg9+7IiSt+kyk3rcIFyzAW/8I vK48rQplBcWbKjBY8BoRGP8E2GlvCsgft/ev+L1XjU98VKTd7acn5d+//fzmoyz31kfZ9MWd5hU7 NhHGzX5X7b4Mo4lfxsQx9LwtQeRGnFvGZYhr+s+PVtbTfxPAfvHt76+P9tt6/3Z1ePyXV/nXCSqQ WwI4gHGVcp9wgAo4gGaQfZpHV2dHYdUmCTWXW0z3VROYVrNXVhEYVxn4gCy3e5YVbs81YW03fCR4 CXK3HR7WgjL+GIMyuDhsV4M4mIPEQH6LYGo62HpMx4M/CFeUdlsvaIKNsIGRQFiwUIBDGGFHiApM iApOSF72R2GJBwpDt2L+F1xX+GBZ+AlbKG5hWAuj94SZdQYRhYS1EH8/SGZo+AggNnPRBwA0mFa6 lmEhiAhzeH932FB5WFlnyAtfiFaxF4eIuGI+iAk994CNuHdlmIhc9VSe4HSWFYl8d2pK2AmUGFeW eAlogFj9QwuhxwuOJ1ybqAmdqHqjKInEwHFPWIqcAAPkkwbk1YUVtoe9RYsdpxXfN3B4dmrJ1VAl 1wi/2FXr51nB+AnJOHPF+FjNCAmLaFnBhwjRWF5C2Hx/+Ar+iXZp3bdU2when4gyOcF4nAaHOhWO A+eG4IV5rkhX7Jhd7viOh1CIrFCBfFiDakB7+JgLuphv+0iPnfCPt4WCAjmIHBZ+ApljBiaJasgJ y/VqD8kJEZeDE0kKa3AKDYkJBqkIDEhWLMh/zPcKACgIAVkLG3kJnfSNC4lWI3kKq3gIJ0kKx1N6 gtCBcTiMV4eLx7ZS1bgdOklZCZgLz4gyLAljbAAAP5lnQ0kLRfkr6EgLJTlix3hsCkkKbYBWU0kM CHkKIQkKbOgIVQkL49iS+9CVJxWWl3CNfoWWmhBgs0Z8rRgKbiBvrYWWp0hXWwlhSRlvNhkJR5l9 9eZ2sJj+Cd0mcakobjFplpmQmBDVkZTAmJzQlxS2lKVwmLaAOQNImTmomZL5mTImdtsBWqFYDKd1 dS/5CqnZVaLZW7aodlYAdYXQlI2wmpGgjrsQkZ4Vl6AZCxUgm735VWN4CvsVlWhFm8H5WMWZnIM2 l8z5YttHC8gZCp7ZWiPICG/wnEtVnZ51ndqZC/H4nTrllr0VnuIJABd4nnR2mpFgj4KQnurJCdlY kIbAmYvQmlxljmXVjRlWfbmFk6zgnyijn17FnxL3l63ln0lXXvMIV+R5WAjaW5DJCyd2bA/KCleJ gNsxob9QoQr4iLxFkPHJYkenCVI3onD1lCe1jJdwoo7+xqIcRXaZZZwomlYyWqM4+m1wUAg3OqIf 2FU451k7+m1BaXlMZVjTSUqYKAnK9527tJe8ZaDb0aS5kJI5ugllGQpSmltUynIlWl6qdqX78KUv wZsQxZYndZFwFZSngJvH1gLxuaAU1qBi+glyWgs8WVd0eggOeJ4A2gmFqQt5Wqe0wJ51CqWnZqiE 2ggZ6lVselv4aXJB+gpqCamIFakhN6mnoHG+paksN42LGm+gupBxwAjkiZmq92yeNajghaoExqq+ oqqZBavTlaVtN5+04KbeZqtuh6uh+qvA2gj22Ql7WgjuyVu8yl4i6lV7BgACqgvDSgvHmlvJel7L 6lX+z6oJpRqs8LatLOedjmCbrNCj3Mpe4ooKgVmuXhWtnsCdLwGn6spc7ioT8BqvS5RRxboMXZoI pQlqixmf+5puo7oPBGp9//oIX+l2BfsI4Hpg+dpUVvoIlZpdZmqvB+acnHCD6IZ8dPWwkZCdiJWw iDCtkqCx31aEAICoM5ewA2trZEoMKmuxcWWZihCzMrsMukpWSUqB2pmzYEGuuWB1TeWij6CikgC0 jiC0KKqbjuCYmrCkwpWuNyuQIrAdZammsACymdCsU9ta2LdEHAsLEZoJskp1tIqGAXtyZ+tVFXly GameXCsJYRpiPpsIb9uooBm3kTC3HFa3IUazl4Yzt10bCpBWXlcJnJLgtORziINbCFXbuKz1o4cg i7vwuG6XrfDGoRVWhVMnuBenYpz7VYEAACH5BAQeAP8ALBQAKACuAdIAhvz+/PIOR/n59yp3bJHj a9SqLbFKEeAKhjTXXHzGlE6a2VgX1HhSmOjw+CQObLwGjNFilxwuJySS3HRe3Kx2TCxU1Fbbtqkj XAZzxIi85DSylERTfDR+7NRIOIif6M/c7xfxNJz2VBecT8uGz3Kv2/RCTFmIjFiE4C4TBsQWTOiE kBQeBMjyu5THoXLcUEpnTlHVKE8YLKzGmIReLJRaJA5zMqzGdK+TYfxudEzp4ZyeNDT6nOep38e9 j2h8xKxKjLwybLruqETCNNbzvcQa3ITYQJw6/KwevHTS9PTnxDzyHNOkHNu2Suz7pOR+9KRmxGRC nES2dFxCBOz+dHQaR+zXnES23ATe3Gk2RwRWjOQi5PQ6BBRLbzRiDCwqZIYHorQizBwvVOSuZLEZ YaSmHHgqmNdqrLRizHCM4zxCBJymlJxm5OQiPG7NWoxYvLSejOyypAyejOSepOS+7P///wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAf+gACCg4SFhoeIiYqLjI2Oj5COAQKRlZaXmJma m5ydmAOeoaKjpKWmp6ipqpUEq66vqQWws7S1treGBoitnQebCJQJlJwKuI0Lw50MxszNzs/QgwgN gsnE0YQO2M4P297f4Nbg4+SN3ZAQ5erriRHsoxLv8vP09faW8ff6+/ywE/2FQAEcSDAVBHEF11E4 JJDQwoQQI0JCKLEiwAoUB1mwyNEQxlIXOuKSgAEDNUIZSmYoVFKCuI+qFgDIqHGRBpqhNohcJQCn ppA7aaXEsJKQgpInB5XkUKgnzFQd1ul8BTQoIw9WtzVYSmgrBpeFGnxIOqinT2ggslr1cBZgiLb+ tQRwQDpoaFGCaQuKgKu20gh5fGvZHXTUpKGWFD8oIPn1rqEGJEoq8ApW0LKWQ0kcUsxYguNaJQZV VWUicN9HI8iqQwDtRNiW1SQj5Pq4pG2Vh+TeZszUsqDbuF8DJ9rsgunTyBmhOMt6XGFqgw9/RWj3 w9DehSJjUPDhg+3KSiV3p67SOu2gKZIrUnFcvajBhSmeb3ryg4GvhxjXn/+bbiIB++GHXnsdsece LgJwJRkiiG1GAmMYGIAdACsIwkJJZTVIiG2LfPDgbRMeeBqBInpS2FAtMIihId411mJlFfZXWYIr bohBiIW8mMGLJJZ4iwt9vRBRC8AloqGNGMz+5FWShugnCI8sTWckhgBy6KM8MHgSQ49XZkLjgiri CIBtMjRQmJjacdfijdIxqSIGZZ5JyAxdisRlnZgUhsEHGR1JWEkVFGnIly35OaaUiOgpKJ4W0bAP CgWtSZOVhmhXgYclfXCImZJ5hSN/lbaE6Z7lmMBoQjXMYio0Zi1yllmtsthdhgI29Uird66y6qm8 dpnmWNqRkKslNoxyAykN9QrJMt9oo2yOw/k3iw3DFnJsKMk+y4+zkOBQ7T2c2UaCptpi81AnAZQ7 yLnu9VQNADGoG1G6ieTwbTQ6yAtJvPo2skM/9/Z7mjsCGwJCwKbwUPDCkYTg3sHqKMxoD/T++IAw LT/UeTHDrkBqzMawZMzxyI3kUAoQ9zjrAzMbkayPMPOYzE4QLsAgBAwusIDIzVle4oAPQtx8CM+r tExIXi6X0wLIB7oQtBAgPM1LIUIg0DMmNl9NSNVaJ22LzKTsykiqiDDtntMg5DwEATAgIEQQhgwx hLuYQN21IHLTzVExiOjMDhFmI1KaI2R7vQgLQbuQTBBQF1FK0HcTxCcjfBNiBCTkNgM4XEeIEnjB aA9RCAGqCUL0IUPUzDPcQ0c9NAyRAxAE7De7UDo0SFxyeSSZI6g3Ig4bTo7NQjzCdW7ERx301FsL bcjxhhDwtPIwiL6JyMJnv07bMMDFNUL+0oNAQBIEuB253Qh9b4jNILCwthBKMJ/I4Irsrv394EDu /c0UCWA9C9wbmvOoxr/1Ba0ILPAfXD7Xuat8Dn9LeFbbsOIIuyFibU572vlc9zwQRI5x1IMB65rR wEWwRWD/Eon9KvhASziteoXA2QgHAblDzO5mBGBB1Lr3vAE2L3JLWJvN3CYEIK3jd/JKoY9EMA7G IcCIgmBcETtYPAPyUAD6e57VWldFQiyBBUGAmwBmx8FSiK0UwcOfiJhgC+K5QG7hE0ITerjBt7EA bV38oQDv1oCsEWAIUozdOt6ixjWWwgmugsEObxa0GdLQgwjJYNUYycNCIMBq6VNB5KT+Zz6oCSGN 9GhhIU+DyEXc0Go525kPy6I6EaItgQSs5Na2aEPYmc+R63BNuXQAsgaIEjmxKhtOYhXMsvTkCYNC YlOUmUt7QOGXhIgCNEdJTW/IBEHlkEI1t8lNQWizm+AMpzjHSc5KTGGa5TxQigyHTh9xK53wrCa7 4pkJKoCzCO30xjxLoQJ5/UMGl7DnNqlFzy79QxDrfBbY1GExTJyxoBAtyBImWoVBaeIEE41gIeZo iIw2oqL0EGgprskJKxDiChFdRxIyqtFQCMCjjYCpIqqQT2uKwqRqxAImKKYOJkyUAktIwiamMogl ANURSUgCMy/xlOSAspx0QoX1HIH+01G8lKVsrETuyiZTWmShptB4ainEtIgVlkMLnvPEQbdRhYn2 IKPJiIogMpoEny6BplXIwRIKANKOTrSuE83qIbpKCAEwoQAUpQhd7crTgm3BEWSFRgUSstZtFKAF SzAsRQfL0owilqU09Wtn94oIwg7Crp7l7GgF64piDWQLXBDnaNix0iWwsbayEC0TkvDWiRYgCW2d 6KB++tvg3hUhcDVEcHdr174WdaIO4G1yYeFaU+AyFV0AK3KAoF1LBLeiVw1qU4y6BGqE15fhRe5E 3bVSCrC2GtP14l8B5NvxUsALJ4nvPq6biu6mNBF0bQBgl9DY52Z2JuSlxEuP2hT+IawXvqTtKIML MVr9AkCmcPUvI77w32e1t8IHlu+BwwvhlnpRBC0l8XiF61egkvfBIh7GT+XB4X4wCxEoKwch1YXa jLr4roWdrpBZTOG/CgK3qlWtLwGQBPQGGcYWTmcHamoEnwjAceU6L4Ao0Vb3FjnEyU2vaH+bhM+G 9ssIsetulytaGcNYjUYrR5UFkTH+GgIM45gsM9icDDHDl8F+jvKLfVwAhOiAvLkJLEuFGuQJfxaJ UOgwT5KRY0eYlVXa/WmaE1viogLawuEtc2C5SuSmoPa3wyVyRm8n6UPItRZh0NYwf6c3Wm85N8Mo ZjIZsdSZWANWEBVDYF7d6o7+aNhHXLrBsYvNMC+oYi+F0IB6SJoJHizbG3PmVVQLQe1tCADahJD2 s8ZQtgxcGxsCKKGIyICQbbMDIfxitrwfwW5ybHVfCyODJ9ydijIkDc+aOLcjYq0epIVC353gNz9W BjyBq4vgyTF4IRmePbGSIrYD94my581xT+z4FFzgi8M7TvJCODchTCwEFJ+h54h8IAwVqEBSXh5z Vo/MDLc4eclZpggBnMABFdClAGLugM8Y7gw+Sg/D7DyLBlQA6HzywNMju/Oqm2LloniAADLwdJl3 vXeIyC2vLHDuS+MvAdgg+ykAF/O2O0AziPjACSoA8yVQ0BBZ8MKl2o6GjMj+ne4xvztK9K5nrnuB Az4558fKqdNKCGsUMOOE2aNhlg90HeiJcDrQN18BNAyq60R/uucfc/muj74QHNA7W77Oa3ngQJwE e5dVrSIANLAeEbZ/+wek7gDENwX0u2976XI/Lt77PixdvwLQzR0RBoxcIrHvSBr6WwG9vz0jACLX BwgvjqED3bxdL132n8T9QXFd+RU4/iPOrA4BNN7q44i+KXhf/Usl4gO2L/3nga5goicm/5xXNj9X c8/nCANQgN4gbqM0ObwTBnqXejGHCFwHcx4wAvXXfV03DBloCBNYAR6wfTGXEaHHfIVQYPCnCCjV CGgVTkTnAZrngYdQf9T+0ABPEIK/p3ca+HQIIYMA8IIUQX/fpx4rmBUImBxcx38AYHlBWAhdtyMc 4IBNNRNABxMx5wU7uHyWd4Es0nUkMHXJUWmldIL90ACEVxQNMHe91xQcUHrh5xFICABtWFhrCHSE t4Rl0XZ80naClxx/MRCOMoS0YILyknoOcALJ4HRP9xlnWH8ZkHtgN3Q4KAj+VwhqsIh614hPB3Zo EAZI0HdJ6AV6B3bJgQz84Ci4wH79omsAcjs9sWRKgkRb1mdIpAa+hl6tuFQjpGujaHP7AHCu8C07 UITPQm30MgsSIwiRlwjx5iUV4YtZsVCqQG7RgGXbMAmQUFmbcIzCWFD+0JgK0iiGozBV4FhsHnMI Z+ATFjeOrnCM3KRwolCOtqKOzkBUAGBt70CKA+GOPmJi+uILirAGnUCPobQAvKiO/JgQCmgIFKcK AFkK2cIM6fAf1ZJy8jgPV7CN9RCRG0UK4LYPGklyuqhGHFUnH1mRJnmSWcEGgQOIKJkQotgIYtAu Khl2ocCSLQkQL8kIMckOimcKGFkINVZNCVl1P2kPD3WT2bOMSEkyRyADRbkKSqktRAARzggN70d5 w3KRS4kcValGT1kn2LOVvJKO8SSQYlkIXXmWnDACX3k/NskwIqWWr9CR4EA/cikRxQhObXmXj5CX 21AGe8mXtuAACJj+XYsnmPfjiXFRCm2AmJCAc6NwelaBjdWgmPvQmEljigUBmaQgmerRTgtZTphZ CJrJMBjXDEdJEKFJC3m0E/h4CGqXPaeJC3YZCvlCC5TpDEIQmJjwTvHomLUQlI+Qm60Wlx3RHMBp EW6AC8YpEsCQnBKxnNvEm9DJMcRWndiJCddJD4JIckqUnbZAi+A5npAgnuRJD1N5nvL2nOophjnZ nrgQhq/wBecIn1Ynn5nQBZDwBWZAnSeZnu4Rls/QT7lRDikoaSSoPT+gYQRqn5iQoOqBnKTgnxKh j7QQaabwXv0lIhInlxYKEBrqleO0T+QgbI8gnK4goA4aESS6CLn+GWIbmhVmWSf5UAktmj1sgAi5 2RMNClEH2iUwWidUEDhvQKGokALdFYx4EpKD0JMjogp9Z6SnIADWuHM6VwkfJ29wsAqzGQlS+gwo Og5fGhEINwtdegm8hJITMKb/laa94qTq4FozuqKJ0J2/aQklaRECAKfjQFDdFAcFk6eCIH/NYADD 0mvVWaMFo24AEAG/VKbCBE0UOQ9kSaf7AKnkGaSnEaKWqhapmVlsWgmcWie1iZ1Mqp5sWarw95ad qglseYI/2gxTlp2CtKKh+g5pCZ6tyWx7iA1DOg/fuTDsuTANOQvU6G0mOZpW4TcicaytOjIS2gg9 cKsFIyQdZ6j+xmCeCzOpahStV4KozEaXlgCo6uKtpeCUj/CQt9BtfEmu2xSFuaGtjSAHm0CYz5pO AoChoUCvm0ARJUCt4RSM9sgx4ioKSnCvsxCMlNCrCHuTBTkMaEcLBduwo2Rzv0oIEUsI/mgKewGw V0Ko2xQaEgGuECWvJHMQFAuen+NvdxmVmsCZwAmYLesJk+cec5CyyBFpN1sLgOMNOysIz2QLAIWz uGCnW3MvPXsqQ1t1LacxVuWxRIsnvhm1gmmvC6OVKVuzi7CdVIsNugRRD9WcXesJXzu2ZisI03e2 5LCbhlNdagsO9SY8fjqOV0kK9bkO5ip7BPF6zgC1JKO1bxuQuII7uGrRoYR7CVkADaPKoYf7CCwL DkwATahoEVPbuH0DEX5ruTdprQWxcTgLdxHhrKHAuQMhAMikufcTq6qwHKjbkpk7jpXbuvTArpgA MQQRu1anrJL2upWQt3iyJbJ7kqYxWxFhdDG4jRf7X0rAu4JAvPOQmo6QWzL3Dj2RvMG7Dbt6Cz95 qpgQBXwpBIEAACH5BAQeAP8ALKAAKAAiAdIAhvz+/LS6PLxhTyQaVIy62cR+DCSiFDQajJDIsMwe fN3W2dwKpETCZGT6tHDYMHRGTEyztGzs6JmnXGxavKwufPzKytI+KWyChNRChPBIKPxpafyHiPzZ 2vxVU/EujHyyLPTynPuppmwmTPx5e3U030SinHzqlAxeoPymbAzChOaMV1B8eNSslkz6HBzW9IiI 2E9GjzGNnVwWzBnyZuTmFAQ+ZDSCLFTRx64L1JwIlI/SHLz2nNTC5HcO/O5rmDzepAwq6FzGJJEn Ly+eDIya3FTaRImIj0Re7KFwL66RoQfSbxSGbMxWyChwbPbPMa4kHgxO9HE5WdTeXESeNARafIRO BIlfGcQi/D/H7KSCDOySzJhOQLCq7DT+xCQCrBSS1Awe7DyKxOz+RAx6tEyavExmpIzM4ISi7IRO nLw2ETQ25OzeLEd05yyi5JSyHPnJedS+pKQWNJHYcaz2bAecL/wy5Fy6/DpwtnJpz285JGzmRP// /wAAAAAAAAAAAAAAAAf+gACCg4SFhoeIiYqLjIsBjZCRkpOUlQACApaam5ydnp+goaKjpKWmp6ip qowDq66vhQSNBbC1tp6tt4wGupMHgwiLtL2pCcQKxJILkbzJkQySDc6kxg7T19io0IUPi9LZ4OHi 4+Tl4cbm6errydbs7/DxmhCD7vKHwboR9/yb9P2JJJibAPAThYIInR2MV2GBBQAXKC1MSFEXBmIL MkjSsKDjgg2DOHRIkBFkIpEJEmTgEHKkSpYVY1Jc4EHRB0IcNYBwuKACAA4eMoSokOFjIg8JQoSw 4AEmUqVMYcrUJGJqModSF6UU5FAogBELQgxK8PAQWLEAQhg9K0itSav+lEjAFVVhZEaYJT3cHeTw 6wKparMCIMmSJoBlITQQIomoKAi+Gh1DnvupBGVKHMgqLeqzY4YKYDVyrdnwbQfRhDZkVGthmaGG qAttHbtstiDblVyTMnH51glPHcIKatjh8N/b6A6XzSA681tCKIp2fC6oQFG0hvoOaq2cEHdLyXvr ypUN91btAL4frglAtc8NCQQTakjyeQENCVAkWhCeMf/FuoknoCUpGPJIIeilt4xhgqiH1W2KMbeI Q2ThlAB1svVnjHnhDbgIhgJaVsiBtBHyH3p68VUWAKc1hB0hI5hEE2OCjPTiIUVJlREAOU7mISMq /DgJZ8PtyKCCfLH+BwBsKxZSFFcWVMhiUoywldYCI/iFllpZCgnXPqhUoBlRPSnnlG4PNriAYoeo JdQK9bWXQAcc1FknIXc2mFQIGcQHAAhRbuanl1+mQmZGPnWnpoo4HXfIAHx2tEKXrXnkkYmoEUXS Z4KwUEELmyZKKAAujMqIiKOc1siOobBgKiEvUALDgDGQUoFaNyJyJDsyyDQDJzRcJhAjKbH5air/ GJJPJL8eq8iwzkYr7bTUVhtODdYqYkO28GDL7bfgEhrgXDeEa24tOHxS7rnsroIMuzkIqEO7plRF byfzwrWDLRXwoOS9mzQLcHaxMcJRRxW8hVJJiqD0UksprYRKvB7+9lDtrovktFNrPgElFJkgCvLU Ugk8BsDIUQ081bKipEksOjR5ZeVgTcIo3JUgWemWygD5cMi7i9S1KV4ZbKCXxFD6BZijtBW2YmIA NraAyYdFNrWP2fzAcyqZWbBZmZ6Bxup6SxpVY8HtrYbxILAhYl5tGm6tCRD3BIcWccbBZJt2Ev50 4SHReQTidbo2yV2C6slNCRBBxMOhokiOJoh7csrHNn9mN8iRfrr2t6DngkCruCSNv4P4gko6aIHe EaKNYJQrWsBRrovF/fjo4tHIlTEoorliizcXMsIwM+pm4yI9cmW1jq7jTsi+CBFZtkZHOqgkk4gg RT3sNVK5iM7+WGrZVvgJCUEO9JMMIY6YXpPZ2eoi+y5Va8YWgoLaccJHZwV24jn/nn1iCaAAOKiC mE8m6gvHoTgFOdU1Sj5EaIt01qQmS3UEU2zrE6IyGCrnnUtVjBibVQTmwfXhalX/6kQRxEHCdsnl HcXSRQs1YYQSNmJWgziCJlawNSOU7lhIsCE5fqiJJLxCCYhIlhCtZcRkKHGJh6ghu5YARVtIMRFM CEcTkpHCKuoii+DYIiycUIguevGMhyAjGtfIiW2Z4gn0uggxoCCgiKACjmxMRENqRp48qkyEBrOU wuxStIa5BGk/OaRg8uXHT2wjHGtLhMZ40jEPtK8oITvZnlL+pkmoNKWRpnjkJqIwCpdpBWYWkFmZ /NY88OXsZjsDpThIyQih7aVqRrtld8CyNMEQhmxtqV/iCCEZ5fHoasaUpTy69rXOICo0SSqbaQom BdUIxZSXa97bBhM3ZcbDbkUqTkf0lhy+NedvhaBA4DrCOScF73XeWZDhxnWNKXhTEY9Dj/UmVyb4 CGYiDZlOITY3iInsLmr/Sddg6OkMVEXCW2c8HTAjZyYI8ah5KpKSIAhKCIM+7nYFoQIadXcY3q0o RUk7m4vMIiOkGM97iUhe1Y7JvHYpdFTSa1v10HS9jNRsEE9SjpSO9z1Yhg98I6jCj5oIMPYNhUhp QmlF1VT+PzFe6Zr5WxMH+JcnQXQ1UHzy0wAFZQVK+AwAV7AKFsC1wETp03cPTESkOsImvVgwCxgc jgYZuKS9iooSaXXWC9kFwglhtBRBFJAWPkHLuWjNE7d6537MiIrEXoZ2VYzhPYW4hXjYc7N+/Cxo ociFQsxwtITqQilKS4jTotYL9xJdJ76A2nQckBiy1QRtvwUGUwSptsAFANCCS9wf5ba4hNpjKY6r ieGOjogAAWTGBAkxhp1EkdVF2mCRy49IImKSHPtJUJ6aOUOg7JOdDOsvnLHeU6hxWjo0BWun+jIo qRI7GhWeUV+5pY9AFC7vdVaHKCE0DXTArUU7Ggea2Bf+Xg4iMLI5zpGgViIcIXOmxZzpVbhbCGaG wAcJcOZnoCm50gyisIOwJmss17ZDbHObHKaEZUkBzrKJ01G6M6dX0Wm/CbaTmJJl1HbkGU8pxBgb +YwdT/n5ngK+RnADXcCPEQS6/1T4yNOQ6E5VxLqLToh7g5gdPm3XTYRYFRIivRdJT3RSuKo0yF9p qe6IGlOm7Uim0sWyLnJqpNQtuUgZ+Kkggkqhshxvu4ZAql++wSU99wKMSxoTVOF3MvkNuX6EcJNa 8jenrXKABFn5KgEF+AMPCMpy77AYMVpgiNtapa0ppWiCOILqtEyQTZWyYF772kGv+hVcYVjEDF1t Dsr+pgLF+zmsIla4tWBjQwwFiSxmEWRsR38C2v3QLHDHYO1OoI/DZ72MoEnx7W5zggyI6CM4RGnu aUQwEeo+42/brbJh0Btczbi3vvfN736Hogz+DrjiZixwSjiXMgQvOCXMwI53KzxcZ3h4CXkDClYj Ag3fijcaKa5CnmkcHIstxBVpKPHLjPwVaSh5tCL+qt+o3BAsP5bLPaQGej2WWwytBXTDtS5FfOMU Bcp2KRg+iZ2TYw2WcFUoen6LoFci3Itggy0SPi2ko1Hq8mC3Ilw7jif+yKCK4zo41voKvFYEiYSy 14ACbCq0D6KzsCB6L9TeG7YrU+4vT8iU8+6sTAL+wO7u5bu1AO/vNtA734KvhR3BUavE66Ksc6Eb NpiLELfH5KaV+PgqJP8KsV/G8gnBfLg870E3eOgNn4CD4wuC+mzwYPXSUnrIcfd6Qlh8ENWG/cPj i4o46D4dODSF738vHtJPQ+nSavwt5HBPzdfCHq5QfiimXYg5DGjm4XA+8bc/IDrwjKnW9v7WKH+u /5qD96Hg4SnqsInF590OsHAjKtjf71idAv7qwD4qvM59TzC7//3mdNlQcwJSKqBUIEYHAPJ3CmDn IaqVCuZnLguICg2IOxEIgBiYgRq4gRzYgRgogB4YgiJ4LNy2Du4HAKIlJMYXLiWYDIGVCFRnKiv+ OII02EiqRwjzZgq9UoOoQH2nsIMxQXiToGrScnLYkILrEIPTgGjXQHa3YISghEce4oTcooTOMGCV IIWT4FCuMHyVMHs8mAhcuAoUowlQF4aFACZo6Ap7pwnbZVlMJ3Dipy79wIRoGIdr2AlIGA5EmIeK sIeMQHeu0IeCwEjfYnjOI4i6YIi9IHrZgIiqcAd+aA54MIkIUYmjEnyJgHyWyA8kAg9G1on9EIql YHqpoIgycYLhAIibIH33cBOpkAf34IWMoIrgwIoZqBuoKIrkQH95Jwu8GA/ACDB6EIzGaA7ad4wx loDZcHuJkIPKuGp6VoY0CIsAoHWSEHPmVoFElGGN2EhvuxiN45CM4ohlhAhF4FeOk1Acr5COi0A1 6qhsaGiN6jgO9Hgs9geAiLcK0FgLmMh9+ygIE0gK/UgI9iZwgQAAIfkEBB4A/wAsAACgAMIBWgCG /P78PDqsIS6f7JgkUUnQrHHhEJtuNBqsNkxu3PoEidmEdJqkjPo8fFdczB4cxAbE1PJ0vEJs/Ofn 6uzpHPGkzKLEzLJcvB4Mubm4fAK0uTXZUSWhYbbZPB4U/F6cHNqE/Hh33zo8+2hn/MjG/Ken/NjY /IiI+7i36FcZdPhQD1i/j3BSrJbcNIL8MtbeFh2gJCJ0rGpYfPKkbL5MjFqsFL5EVMaE1F60eiPg rCqY7+Y3PLYsFJHk79UppMZMjiosNGhAJFIUtFroBGpkbN5Eub5ZbIJcBMJ8hNpkLOYUjNbZ1E7c VHZ8bGbszLIEODg4jFbUjIo0tMIUNAIkx8fHmZiZbKYMeHh3Y2RjcG9vMTQKpMbMqKqohD6M2SLp PDp8XJ4EHFZ0nuksbKxgMJpsLAJglDLUpC6chFQ4hGYEcDVcjCGj1H6EPMp07OJsqr7kV/qf//// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB/6AAIKDhIWGh4iJiocB i46PkJGSk5SVlpeYkAICmZ2en5IDoKOkpYUEpqmqiAWrrq+wsYUGhQeqorK5uokIu5kJoK2OCr7F xsa2qgujDMfOhQ3PkLijDtLX2Nmdy4IPnRCqEdrjltTk5wAS6JYT64nW6OLu8/T19vf4+aMU+v3+ /wADGquwip/AgwgTIrRw6YIkDAojZohIsSIlhpYc2tNgsdAGShM7ihw5St0iDtk4kvQFj1KHlYk8 aPsA85UEECEc6BQxIiAJRO0clRCh04GIEoVw6jRhiKgDEIVKODghyYHJmgBoJaSpqxlFqQ5MjBhB IifTfAaJXi0UNBFYsf4kdCIVRBTECBAOUBAy8ZTvWUEhRGQzl00rVlIpLOacK0iC3GwqqrakRJSq oLiCAZxQAZXu1EE51ekcNMIB42t6D+dbofrdZM9/VbGAFFlSaEu3B40G0MJBT0FSMwPYvRtA4JHe jLlojVWnZbcicu5Uh/cnaaODTEgPYTmxoNnDXxfXWXY6oqI6r2rXGcL6IRSfBZ1wEAKwVULj4aUH EHetxdeJvEDKcsy5A8MofNFHwmmDgEXCCCcQVV9p9Q1C1G9mQQgfCIQJUpyHLRVlV4L+CVKab78Z Z9QJEWJ3iGMOxEAWeSAWUtxt9AEWW4GECMjjj4MQE0mCRYnwHAB8pf4Io31X0acOX0cudsiH4en2 VHZXTnmfIHx1lg5R7hVyoogm7SYDiCbxJQJRTGlX4jkzAClnJzRIIiQkEpDgFHuErHWiBDXEdZag 9o1QwqEl4LVjjfiFuCWjhuSmop85GjKfAyRIUAJfIYjW0pmSateeh+4x+MmZoNjQzw3a4DDnKonq 5GWiIUi3n2MV5obersI1aqOja+1nyIdU4npITkeqWaWviOAkCF47KZJDJajyyGo2rr7ayaYlzlfh pYGJVdyFwZVplQToouvar1aye+yj6enA7K9rLSkspIU41hNmErAprbaO7AAwOTxU8hGWXg6Cq6cp hmdSaSJAaeVaJf4sqGWf+QULIJpW9kAIhRdjXN+FDbrYVGZSGluOPT4IkszAMBXcCYwMxtXZvXE9 mlNOhOCVcE4NT4ylo+51iQjPg/hMCJiHMI2wZiZXdohUc+m6cUUvQ/IDzDCBh0jOIJxQwgl4VQgA fDyNQCRjCcYmQU5pE9UrIfCFMBa0joa1qZNH690Y3HZLiAhYdt1VqYpi8ZVaU15KKZXZpgABSRBc V/7MCNEVFYLbe3KnaKMM3rTdogrveVR+6xn1phD8FTWXBOvVGpt3CitFX8IA4I37dVfFhcJQmLoi +SJDWG78M+om8qbCiiT/iEkaN4bni5Gos7wjo+4lHenHd68IEf7ed0JlP9eHT0gj3YNvPibjH73+ KC3Lgv77NRXB0tX0rxL/NUZUjv8rqkoF5IxRvkuwJn+WyJYujoBAUyBBFTJpoCQMkAQJWvCCB1GC Iyr4iCVg8IMgvIYGO+HBEJqwEEw4ISh254smqNB8KTwEA184CRbScB3y+MTWAjLDG/qQIhrxhRNo yA1Q7Koov/tEio7IHsuM6SpPLAR8/vePJ/hwiCMZYC5cSAomFiVolBhBrazkRctMUTjSCROSikIJ KPzwjc3RiaE0FC325cc3JRiLUyoEI9+s8XDPQs8k3HiPKMCREDE4ZCTYqDBGXsKRjgTRlhLUKdeR xlbtm4SpsP4hBfY1MAZt6SIoQikIUpJiZ1YyG3pUebhVptJKc4skjMx2k6LsKHVGQcoR+/grne0q YTkjkiLKoyAyJkgw/WIPL/1BxYBMYQodgCYCqDCKCUwBElOg5hRMKYhseuh624yENdlyTVWQCGr7 OdEU1XEpB/xAAurcTzvVcSI1FmUJJYCndJ6DycPhDT1gQc8y00FJQgQUkADowFHCg789FUmStmTo Ef9RQH8kx5sAmEAVOkDNT1ChnB5KBEZF2tFRfLQQJ1WFg3JXlJ9Aq54spdFLZdrSmPrHi/H5I0+c Yp2WGi4sYzKURI8YtD0dqZdfKwqLtsdQu2UKWtxpZzOvYf4F1YwUAFfAAgCyIE1uTsEI0eQGVzuA gKBEE6SEyEI0sdAOb2JUrVNgKwC8iYUncLOb2uwoRjGghSk8gZpnJURgsaBVQXB0rmCdQgyxuta7 NkowtoJsjqIVWRXVh7JFsQUqe8nEqslRU3xiqJE0Za688cpU6LEhQ/vmRwCApZKPsY9p5BNJdFTV qiUFABU6wAS7TgALvTBEXCewhW1mwbfAFURKC3EF3z7hCnPNK1adC91sNtex0c2udjvABQAswIrL VW45MfASAGDgQHPVwgQm8FyslhUAyV0EtGAkoZXOdyf0sW968BuClfYyXcCrFE4vs6vsQVKOxFzU P2erpf6rRbIofWxScQaqyEdc9aPcLWU4CzGFLeBVCxDJaDjDO4gOhHi92fWmiUvZViBsmKTaxSgM pjkIEisBpB2GL3Tn2l3zvuSwun0xIk7Ely7AaL4A+MFS5CKrdC7ZNE1+FBn/O1SBmsh20TowPAIa poDu8TyZhDAZKSzmdNS2Hl5YyVXJi1Fr5haveG2zN8dpGDgTwq3SvbMWYNBjGGM0mx6jAhaguYxx EsLQAGCCVv/c0ZM+M5p9xS5E9eLKKfQxLxJlpU4orbkGUxnC6BoB9MiSqTxBWMtD8+VT+ki6M8t2 Lq8lc2zb2Y/kiOSqWQBCBzwsYlMyWgu8tmY7Plpnw/7ymgpVSDFgj53sDnNByMKVrrAFAZEvVGGb JF7ubrmghUHk2LzdBnYp34yIPTHF3BaKKLo9sxQAsCksjcmnJPN5qILG9CjHVNFSKnZqOVIlktLJ DJHYaUmkxjtN7BkLUyO5x7EJ0hhg2EUY7jHSa1Oht+1AQHA5rNeL+xYBw5s2Cq3I3upKt7cZba83 g1BYRHhTC8swwpw7kOzirlfIIgeAFtrbTepu1a4AMEK3HdFOpOSMweic7dEZU3T+JGgujMRpfC79 RdnuiimYDOjHlNrH5zhlcVOW5N+OmBlZDrgYEf/EAykCzUfTeKvQBMKbGA33Dsg15dCGLzQLi2dB DP7a7nC2ZncHTUpvciGsYugot6eghe5OINKDePyGuVpSxXaAt4OA618hwchZGtzzjXKUpiG6yiMl kz2nIWYxASBG1Nd2jwG/Sh/teUftsecvtS3BFPvr6gpTJOeCGEAoxZAJLljR2+SuhPWY5x8JLEH2 6chXverVp3SlKxHTQsTy8xX97XO/MSVyXp++z/3mGwJC8jYzQn1fkSoUUcOSnkQTko189o9ij4Zy ytw6UV77O6N4iIABUzA8nrBblHNnyScNHuM9Y7Irm+R/DSQzWMFBCnECU7RpYGRhApGAAjFVEFgK FKgQ3ucSH6gIHliCKJgNcaIKY/AjaZaCnmBrMP74CWQwg9KgPvoggza4gwKBgzxoD1gkEF7xg0RI D0H4CGWADaY0hEXoCvF3Dk8oCWDHFq1BIKSQd+RUf6OEViKmClf1CYPWZ6nwhc+AaGQIhTjGgS7X dtGUQlOoYZWAUQeED1a4C8t1hpeQbVw4CniICd+2Cn0YCQDoUWn4CmZQgIUoCYFICCSGTdQ0h3Li Von1fgn1TN3EBJdXRFfQWGyBBZDWZ57YATLnd5c3it00aEywicM1CHzlVx3VipvHYZgIeBnliYzX Y3GlWIUwVu81V9BECIRVYtTEi21Bd3OFinc2iy2XiylEjADwBLjIDTxATbDYUap4d8eoi4UQWP5z NYuayIndNInClViLlYtYcAbXGBTVSG19FYslZondmImDkI7RdghfFVaGBY/0mI2LBWd11Q77GIyG pYafoIO74FZsZXOMiGNs9WwA+V7xNQiEBZAwQE3XxV7XdFzr9QQMOV3tEJEZ9l2G1V0iyWHqVXLw JVdXgF5xlVFphVwbt2bldV4/t14RaYwtGUqMt5E7lpMa+Vu9kFUA8GySw1eC8AIkaUVXAJExqVWm dIcNGU5L+ZFNSVzQtpMoeYwZNZW/VVgheXwhGTRQOQEO6V5UWY/ClZAjVk5TCV/BlZMcd11m6ZbU NpPotQoGeZDaxGsXhmN8CViNhnPtMAEL0P5RuyYIz6ZzIZaY3eRhQPZRQTFjuSWZLhdiW/ASKEaY 5fSHJXZiG/aFOYYF0LVivWZnf8Zrd2aZ5fVtpCls5IVVnrhVO0ZWJfWYn4maKOWXcGabQfFtoNlj rzlXvMabAECZg2Ccueltf5lQgVl40fScuLicKUWcnOltLmZWzdmYOhYRaFCPxgiHpqlNbQd5NcaR WjBoAJAGGOVogVl/j8Z4GyZohKZcf0eJ2nVSVGCeCLCZ5CZnHYdCi5ZnbhaedoaA4kV8xjig2fRX FRmL8klzvghpn5mAZvif70me32lnKfVn4zli9Umf0LRjkZeIbtWhhZd8dGdoFxpOZ8h4fP7WTSYq CIqmXQrRnQaaoR/FDXQnbhn1Zh3ADQIoCI0nCMWlcz1WpHDGoxNQUhChUeHUpNdWeLzGVxPwo+JV oCUWbBOKUtw1dENamtklcmrQn1NKfNulpR+5AC8BBJtYYxkVpYfZo1poCHf4n0paef95Z1M6dBh1 pwDwAdTkpO3QpGVZYyRKOX7Kcfb4nymVqC26BYfXDomqW12qZnl2VSJHdxoZdEPnbcmGkQAJdBzp kRhZf5sqdKUEoTZnTTV3lT43BZ/KkW1FbpuqcXM6CDu3Yz8Jcrgac960BmToVzxpZ7UaXEQJANdW WKwKADaHcZx6q4e2pdl1qp2aoXPlc/7atalM0G3Luqqwyqw4J61BMIxAh6qKipZzFk7UiqX19wRa BVztYK5CynMj0Xc0inezSqzR5I6I2VfA9m2byFvlpFYwYIrZuq8ltXhfqrBieInR1D9D6a+H52Fn aItyB61w11ETAFfY+Gw/aq3x2AFZMKcWaxLLKniDwLCCsIlb4Ft2RniRB3nGqHl4yq6Wh3kFClc7 EBQqG7G3yBYym6c0K1zPCU18+p+S1w5De6/1h7JLKwiU14TuYHzZEIWKAHymsIiCEEAr0UOGQLWH wQaTUC0wgwD0hxDuZwhmCgpa+ypmazxkOw0UAbG5eYCCUGyV07aIMD8k8VF2G0Jim8wQdCu1udCw zmAQNAQOhKsthnsMiPtCiru4kktDO3QN13JBLTi5jsA6hqBGmvu53ZNDhOC5ifCC9vCGIJR9N9QG 75OXHdEh2lK5u3CXMMG6CKQSoPsPtLsSBEg/h+gMNZi74dO7uSuBB0EQwtsRWQMLqJuCyJu8yjsO 9uMJbgC91rsqu1C91ysnbwAQ9ikIfFsKwbu9hgAHNti9FBG+9qdF5KscnhC4iYAS7asI7Du/u2C+ nwC/hiC/rzC99mu9arASZ5sInaQNR5gJgQAAOw== ------=_NextPart_000_0007_01C7B04A.F0BDFD80-- From Judyconstructiblepostposition@regiments.org Sat Jun 16 18:36:34 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzgsj-0008GQ-Vl; Sat, 16 Jun 2007 18:36:33 -0400 Received: from pool-72-93-170-199.bstnma.east.verizon.net ([72.93.170.199] helo=verizon.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hzgsh-0005cP-Ey; Sat, 16 Jun 2007 18:36:33 -0400 Received: from broadside by regiments.org with SMTP id qHeNWzCcFj for ; Sat, 16 Jun 2007 18:35:31 +0500 From: "Katherine Childers" To: megaco-admin@ietf.org, megaco-archive@ietf.org, megaco-archive@lists.ietf.org Subject: holland Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 3.3 (+++) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Hello, Life Should be Full of Luxuries, yet, only a handful of people can afford the finest products, the luxuries of the elite. We are committed to bringing you the finest products, at prices incomparably lower. Perfectly crafted luxury timepieces, all at affordable prices. Thousands of different models to choose from! http://www.dedogo.com/ The finest of products, at the lowest of prices: http://www.dedogo.com/ Too many bastards in the world already, and I dont want to see you going in the Army at sixteen. In his mind he heard the voice of Ronald Reagan in Kings Raw, shrieking "Wheres the rest of me? Sincerely, Marilyn Womack From Jennamakeelectro@automatoractions.com Sat Jun 16 21:45:33 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzjpd-0005YK-BA for megaco-archive@lists.ietf.org; Sat, 16 Jun 2007 21:45:33 -0400 Received: from pool-71-240-3-185.pitt.east.verizon.net ([71.240.3.185] helo=verizon.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Hzjpa-0005A7-Vh for megaco-archive@lists.ietf.org; Sat, 16 Jun 2007 21:45:33 -0400 Received: from pinpoint by automatoractions.com with SMTP id amqDbTYTb4 for ; Sat, 16 Jun 2007 21:44:26 +0500 From: "Gretchen Painter" To: megaco-archive@lists.ietf.org Subject: Fwd: QUESTION Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 4.8 (++++) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Hello, Life Should be Full of Luxuries, yet, only a handful of people can afford the finest products, the luxuries of the elite. We are committed to bringing you the finest products, at prices incomparably lower. Perfectly crafted luxury timepieces, all at affordable prices. Thousands of different models to choose from! http://www.dedogo.com/ The finest of products, at the lowest of prices: http://www.dedogo.com/ Even today, enormous computing facilities still exist for specialized scientific computation and for the transaction processing requirements of large organizations. For instance, electrical engineering is the study of the practical application of electromagnetism. Sincerely, Rochelle Cummins From megaco-bounces@ietf.org Sun Jun 17 02:14:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzo1L-0000bo-NN; Sun, 17 Jun 2007 02:13:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzo1L-0000b8-8A for megaco@ietf.org; Sun, 17 Jun 2007 02:13:55 -0400 Received: from kremlin.juniper.net ([207.17.137.120] helo=smtpa.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hzo1K-0003C8-1D for megaco@ietf.org; Sun, 17 Jun 2007 02:13:55 -0400 Received: from unknown (HELO emailfeemea2.jnpr.net) ([172.26.192.142]) by smtpa.juniper.net with ESMTP; 16 Jun 2007 23:13:53 -0700 X-IronPort-AV: i="4.16,430,1175497200"; d="scan'208"; a="20213485:sNHT36267680" Received: from EMAILEMEA3.jnpr.net ([172.26.192.136]) by emailfeemea2.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 17 Jun 2007 07:13:52 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MIMEOLE: Produced By Microsoft Exchange V6.5.7235.2 Date: Sun, 17 Jun 2007 07:13:50 +0100 Message-ID: <0E48B768805E4D44A70709C8AE092090A53B12@EMAILEMEA3.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: H.248.1v3: AND/OR select logic for AuditValue Thread-Index: AcewpqxrdLnlZnVNQNOWPIRVzY1U2g== From: "Miri Epstein" To: X-OriginalArrivalTime: 17 Jun 2007 06:13:52.0152 (UTC) FILETIME=[AD470180:01C7B0A6] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Elad Chomsky Subject: [Megaco] H.248.1v3: AND/OR select logic for AuditValue X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Hi All, I'm dealing with "the ability to add filter conditions to audit requests" in H.248.1 Version 3. Does someone have some examples demonstrating the use of "auditSelectLogic"? Many thanks in advance, Miri _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Sun Jun 17 14:30:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzzVo-0005fe-NY; Sun, 17 Jun 2007 14:30:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzzVm-0005T7-Pf; Sun, 17 Jun 2007 14:30:06 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzzVj-0001RI-Iu; Sun, 17 Jun 2007 14:30:06 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B944F2047E; Sun, 17 Jun 2007 20:30:02 +0200 (CEST) X-AuditID: c1b4fb3e-af032bb0000007e1-cd-46757daa3375 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8ECE1200FE; Sun, 17 Jun 2007 20:30:02 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 17 Jun 2007 20:30:02 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 17 Jun 2007 20:29:27 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [MMUSIC] New draft: multiple times problem description:draft-garcia-mmusic-multiple-ptimes-problem-00.txt Thread-Index: AcexDW/tw2GXyajLQie3sVnHoTaY7A== From: "Stephen Mell (CV/ETL)" To: , X-OriginalArrivalTime: 17 Jun 2007 18:30:02.0342 (UTC) FILETIME=[84C32060:01C7B10D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.3 (/) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb Cc: megaco@ietf.org Subject: [Megaco] RE: [MMUSIC] New draft: multiple times problem description:draft-garcia-mmusic-multiple-ptimes-problem-00.txt X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0316729592==" Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============0316729592== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B10D.84955806" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B10D.84955806 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Miguel, I would strongly agree that there is a need to explicitly specify an exact packetisation time per media type within SDP. Joe Stone has focussed on the interoperability of end points in his postings; I think that the network itself also deserves some consideration. The maxmptime attribute given in V.152 (and I guess also the packetcable "mptime" attribute) also helps prevent the endpoints from generating a packet *SIZE* which is too large for the network, but I don't know of a mechanism that allows the endpoints some flexibility in negotiating and choosing packet times whilst still preventing them from from generating a packet *RATE* which is considered too large for network. Given that network restrictions can often be expressed in terms of these limits of sizes and rates, then a "minptime" (single valued) attribute could perhaps be considered, so that endpoints can be given an offer which allows them to choose (or negotiate, via an intermeddiary) a media flow with charectersitics which falls within these twin constraints of Maximum Payload size and Maximum Packet Rate. Having said that, we should also consider that in general, network policing policy may need to be defined more rigorously, such that only flows which exactly match specific traffic criteria are admitted and/or transitted on policed parts of a network. Also real-world endpoint implementations may impose additional restrictions on what combinations of media types and packetisation times can be supported (or at least viable without excessive use of available resources). For these reasons I think that it is more important to address the issue of providing an exact packetisation time for each media type (allowing the media flow to be exactly specified) than it is to provide a flexible framework (allowing the media flow to be bounded within certain constraints). My particular interest is in H.248. I've considered the problem with respect to H.248, and come to the conclusion that a solution to the "multiple ptimes" problem would be beneficial to interoperability, and that H.248 does not in itself provide any solution to the problem. The arguments relating to H.248 follow: Within H.248 there are facilities which exist which allow multiple SDPs (each containing exactly one media section, m line) to be passed from Controller to Gateway, with flags (ReserveGroup) which instruct the Gateway to reserve either one (ReserveGroup=3DOff) or all (ReserveGroup=3DOn) of the SDPs (referred to as Groups). At first sight, this might seem to provide H.248 with an escape from the "multiple ptime" problem. By using multiple SDP groups, each with its own "ptime" attribute and a single fully specified media type, the specification of per-media type packetisation time can be achieved. However this is problematic, as it restricts the Controller from using a single Group, with ReserveValue=3DOn, and CHOOSE ( "$" ) as the media type, thus allowing the Gateway to choose a number of different media types to reserve, according to the support for codecs, availablitity of codecs, and importantly, the Gateways own preference policy with regard to codecs. To solve the "multiple ptimes" problem by using multiple groups, the Controller must always fully specify the media type in each SDP group, These use of underspecified or overspecified media types in the controllers offer could mean (when ReserveValue=3DOn) that the = combination of media type and packet time in the Gateway's Answer is no longer unambiguous. The CHOOSE facility allows the Controller to know nothing about the media types that are supported on the network and delegate responsibility for the media selection entirely the Gateways. This CHOOSE facility cannot therefore be used, if the "multiple ptimes" problem were tackled this way, using multiple groups, as the use of mutiple groups defines a convention that then limits the use of other constructs within the protocol. Also each of the SDPs (Groups) has its own Session details eg: When using multiple groups it is harder for the Controller to prevent the Gateway from allocating separate session details to each of the groups. Commonly, the controller will ask the Gateway to choose its own session settings for each group and the Gateway then is at liberty to assign different session details (inc. addressing details) to each SDP Group. Where switching between reserved media types is subsequently co-ordinated by the Controller this is not a problem. When autonomous switching between the reserved media types occurs, as in the case of the V.152 fallback mechanism, the consequences are disasterous; the switch to a reserved non-compression codec must *NOT* be accompanied by a change in source address as the the far end would then interpret this as barge-in and ignore the packets. To avoid the above problem and ensure that reservation of multiple groups is made with the same session details in each Group, the Gateway would require two reservation requests rather than one. The first reservation would ask for single group asking the Gateway to add its address details, and the second reservation would ask the Gateway to reserve both groups with the identical address details explicitly, learned from the first reservation response, supplied by the controller in each group. This makes the "multiple groups" solution to the "multiple ptimes" problem start to make the H.248 a little unwieldy. In conclusion, I believe, due to these two arguments, that H.248 doesn't provides any viable workaround for the "multiple ptimes" problem, when SDP is carried over H.248. Regards, Steve=20 ------_=_NextPart_001_01C7B10D.84955806 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [MMUSIC] New draft: multiple times problem = description:draft-garcia-mmusic-multiple-ptimes-problem-00.txt

Hi Miguel,

I would strongly agree that there is a = need to explicitly specify an exact packetisation time per media type = within SDP.

Joe Stone has focussed on the = interoperability of end points in his postings; I think that the network = itself also deserves some consideration.

The maxmptime attribute given in V.152 = (and I guess also the packetcable "mptime" attribute) also = helps prevent the endpoints from generating a packet *SIZE* which is too = large for the network, but I don't know of a mechanism that allows the = endpoints some flexibility in negotiating and choosing packet times = whilst still preventing them from from generating a packet *RATE* which = is considered too large for network.

Given that network restrictions can = often be expressed in terms of these limits of sizes and rates, then a = "minptime" (single valued) attribute could perhaps be = considered, so that endpoints can be given an offer which allows them to = choose (or negotiate, via an intermeddiary) a media flow with = charectersitics which falls within these twin constraints of Maximum = Payload size and Maximum Packet Rate.

Having said that, we should also = consider that in general, network policing policy may need to be defined = more rigorously, such that only flows which exactly match specific = traffic criteria are admitted and/or transitted on policed parts of a = network. Also real-world endpoint implementations may impose additional = restrictions on what combinations of media types and packetisation times = can be supported (or at least viable without excessive use of available = resources).

For these reasons I think that it is = more important to address the issue of providing an exact packetisation = time for each media type (allowing the media flow to be exactly = specified) than it is to provide a flexible framework (allowing the = media flow to be bounded within certain constraints).

My particular interest is in H.248. = I've considered the problem with respect to H.248, and come to the = conclusion that a solution to the "multiple ptimes" problem = would be beneficial to interoperability, and that H.248 does not in = itself provide any solution to the problem.

The arguments relating to H.248 = follow:

Within H.248 there are facilities which = exist which allow multiple SDPs (each containing exactly one media = section, m line) to be passed from Controller to Gateway, with flags = (ReserveGroup) which instruct the Gateway to reserve either one = (ReserveGroup=3DOff) or all (ReserveGroup=3DOn) of the SDPs (referred to = as Groups).

At first sight, this might seem to = provide H.248 with an escape from the "multiple ptime" = problem. By using multiple SDP groups, each with its own = "ptime" attribute and a single fully specified media type, the = specification of per-media type packetisation time can be = achieved.

However this is problematic, as it = restricts the Controller from using a single Group, with = ReserveValue=3DOn, and CHOOSE ( "$" ) as the media type, = thus allowing the Gateway to choose a number of different media types to = reserve, according to the support for codecs, availablitity of codecs, = and importantly, the Gateways own preference policy with regard to = codecs.

To solve the "multiple = ptimes" problem by using multiple groups, the Controller must = always fully specify the media type in each SDP group, These use of = underspecified or overspecified media types in the controllers offer = could mean (when ReserveValue=3DOn) that the combination of media type = and packet time in the Gateway's Answer is no longer unambiguous. The = CHOOSE facility allows the Controller to know nothing about the media = types that are supported on the network and delegate responsibility for = the media selection entirely the Gateways. This CHOOSE facility cannot = therefore be used, if the "multiple ptimes" problem were = tackled this way, using multiple groups, as the use of mutiple groups = defines a convention that then limits the use of other constructs within = the protocol.

Also each of the SDPs (Groups) has its = own Session details eg: When using multiple groups it is harder for the = Controller to prevent the Gateway from allocating separate session = details to each of the groups. Commonly, the controller will ask the = Gateway to choose its own session settings for each group and the = Gateway then is at liberty to assign different session details (inc. = addressing details) to each SDP Group. Where switching between reserved = media types is subsequently co-ordinated by the Controller this is not a = problem. When autonomous switching between the reserved media types = occurs, as in the case of the V.152 fallback mechanism, the consequences = are disasterous; the switch to a reserved non-compression codec must = *NOT* be accompanied by a change in source address as the the far end = would then interpret this as barge-in and ignore the packets.

To avoid the above problem and ensure = that reservation of multiple groups is made with the same session = details in each Group, the Gateway would require two reservation = requests rather than one. The first reservation would ask for single = group asking the Gateway to add its address details, and the second = reservation would ask the Gateway to reserve both groups with the = identical address details explicitly, learned from the first reservation = response, supplied by the controller in each group. This makes the = "multiple groups" solution to the "multiple ptimes" = problem start to make the H.248 a little unwieldy.

In conclusion, I believe, due to these = two arguments, that H.248 doesn't provides any viable workaround for the = "multiple ptimes" problem, when SDP is carried over = H.248.

Regards,

Steve

------_=_NextPart_001_01C7B10D.84955806-- --===============0316729592== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0316729592==-- From Jasper714@TOPHIFI.RU Sun Jun 17 14:50:52 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzzps-00034o-2N for megaco-archive@lists.ietf.org; Sun, 17 Jun 2007 14:50:52 -0400 Received: from chello087207118107.chello.pl ([87.207.118.107]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hzzpm-000113-NC for megaco-archive@lists.ietf.org; Sun, 17 Jun 2007 14:50:51 -0400 Received: from dom-s29uyjftecg ([129.102.109.0]:32387 "EHLO dom-s29uyjftecg" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by chello087207118107.chello.pl with ESMTP id S22AYOPLHQBWEGSL (ORCPT ); Sun, 17 Jun 2007 20:51:02 +0200 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 17 Jun 2007 20:50:44 +0200 To: megaco-archive@lists.ietf.org From: "Jasper Malcolm" Subject: His heart throbbed and then stood still. Mime-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="=====================_1089281==.REL" X-Spam-Score: 4.4 (++++) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 --=====================_1089281==.REL Content-Type: multipart/alternative; boundary="=====================_1089281==.ALT" --=====================_1089281==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed [] Sometimes on a Sun 4 you may observe a crash in the program genflags or genoutput while building GCC. First, build the DriverWorks libraries. By default, the function formats the currency according to the specified locale's settings. The word yellow wandered through his mind in search of something to connect with. This document contains the release information for the Excel Interoperability sample. A hundred years of peace with those who make no peace with strangers. If you want to resize the window of player, please move your mouse to the hand icon, press your mouse button and drag the window to the right position. What said our cousin when you parted with him. Gods did not scare Sixfinger much -- he got used to their attention and accepted it with a squeamish submissiveness. This document describes when and how to use name-based virtual hosts. Drake is the kind of guy who reads British industrial design magazines and appreciates William Gibson because the quality of the prose is so tasty. This method uses the implementation on the component's designer to retrieve the selected data source. MFSK is a system where individual pulses of different radio frequencies carry information, and the data carried depends on the frequency of the pulse. Protector Muksin, the shiny top of his head concealed about as well as an aged turtle napping beneath a few blades of grass, watched the room. This document does not require the communication of locale information on all text, but encourages its inclusion when appropriate. There was a conflict of opinion in the village. Then he swung, if not his legs, then at least the memory of his legs off the pallet of sea-heather and stood up. By default, the sendmail configuration files do not permit mail relaying (that is, accepting mail from outside your domain and sending it to another host outside your domain). This does not end it, however. Other collections are unregistered. None Header files only Database view without file support Database view with file support. But after taking a few steps he stopped, glanced round, lifted his torch high to illuminate everything around them, and then gestured to Fedor. I warned you, but if you want to. We used that idea in Part X. --=====================_1089281==.ALT Content-Type: text/html; charset="us-ascii"

Sometimes on a Sun 4 you may observe a crash in the program genflags
or genoutput while building GCC. First, build the DriverWorks libraries.
By default, the function formats the currency according to the
specified locale's settings. The word yellow wandered through his
mind in search of something to connect with.
This document contains the release information for the Excel
Interoperability sample. A hundred years of peace with those who make
no peace with strangers.
If you want to resize the window of player, please move your mouse to
the hand icon, press your mouse button and drag the window to the
right position. What said our cousin when you parted with him.
Gods did not scare Sixfinger much -- he got used to their attention
and accepted it with a squeamish submissiveness. This document
describes when and how to use name-based virtual hosts.
Drake is the kind of guy who reads British industrial design
magazines and appreciates William Gibson because the quality of the
prose is so tasty. This method uses the implementation on the
component's designer to retrieve the selected data source.
MFSK is a system where individual pulses of different radio
frequencies carry information, and the data carried depends on the
frequency of the pulse. Protector Muksin, the shiny top of his head
concealed about as well as an aged turtle napping beneath a few
blades of grass, watched the room.
This document does not require the communication of locale
information on all text, but encourages its inclusion when
appropriate. There was a conflict of opinion in the village.
Then he swung, if not his legs, then at least the memory of his legs
off the pallet of sea-heather and stood up. By default, the sendmail
configuration files do not permit mail relaying (that is, accepting
mail from outside your domain and sending it to another host outside
your domain).
This does not end it, however. Other collections are unregistered.
None Header files only Database view without file support Database
view with file support. But after taking a few steps he stopped,
glanced round, lifted his torch high to illuminate everything around
them, and then gestured to Fedor.
I warned you, but if you want to. We used that idea in Part X. --=====================_1089281==.ALT-- --=====================_1089281==.REL Content-Type: image/jpeg; name="Summer.jpg"; x-mac-type="4A504766"; x-mac-creator="4A565752" Content-ID: <7.1.0.9.2.20070617205044.021a0c98@TOPHIFI.RU.0> Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Summer.jpg" R0lGODlhTAEwAYcIAAQACYoHAA5xAIV3AAIAfXUEfgh6esu9uLnduabK5E4lAGofAHoeAJMuALsd ANYTAA02BxYxAEoyAFxNCX5IBqFDALpOCd47AABWChJkCEtSAGVWAHNmAJ5YALdVAORVAw6HABR2 AjKIDFh6AHyNAKyLDLdyAN6MAACjBiStAECmAGGRAImqCaOjAMyYAuOZCwfFABe8ADLNAFLFAXG6 AKfEAs7CBunOAwfrASrYA0LTAmHgB3LpAJPSALTaAN7nAA4COyQARUoASW0FNX0APJ8NMckASdsA TAMSQCQkQU4lOFchQ4AWQqMhPr4kNO0gMwA6SS1FQzs0O2Q0P4g+S5M7S7MyTOY2PABdQxZdPzdp NGJbPHVRB6dWP8dpQdRhOQ6LRBt/NUSOQlmCQnyNMaKHRr6FN995PgCeSy6oQkGuQViUP4etSZ6m R76SNOOuNwO+OSC+Qjy3N2TEQHrOSaS6TL24R9i7OADtSy3mSz/fMl3UNovcSZ/iQcrSMt7mSwAF hREAhE0Af1YAiHoAeJYAcb0HcuIAdgARiSApeU0UcVIVjYQccZYheLwZctofjQg+hiwzf0tGjFRF cYFKg6g2f7hMd9kygQBWcx9ShUZgg2lndoBriaxlerJqdeJXeAB2fh2KhTiHelqAgH9xjJ1xcbuE f9eEcQCeeiCgjESrgleghnSiiqKRfMOlgdaeeADIgRfEf0jIeWS9h4PAdq3Ef7bIduDLeAndiyPe cU7gcmPfe3PYgJzfec3ffe7ghQcFvRgGwjsAu2gAs3wAxKQAzrwAv+UMvwQWtikqs0UZuVscwIkg spUjtbsuw+IutQBOxRkxwTQ2w15Oso1Dtqs6y7dCt+BHswlhySJbvUpaw2duxHtUsZFev8xmxd9p wgZ/vBhzwDJ2v1txt4t3wp+Ms8yLxth9zgOTtCKTxEmetFWcznWrwJGatsaevtepzQDGvBLKvzPA xlq9wXa3yp/NyP//9KShoX1yePIABgT/AvT5DAwK//8D/wD/8Pb//yH5BAB44IEALAAAAABMATAB Bwj/ABEIHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuX MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKnUq1qtWrWLNq3cq1q9evYMOK HUu2rNmzaNOqXcu2rdu3cOPKnUu3rt27ePPq3cu3r9+/gAMLHnwzXz6WhgmrNcz48MnEAiFvbMx4 oGTFZSlXNin5ckbNkD1jDrvZ8mPHIC9XFj36K+vTIj0nft16K20EmgnOLo2bckHQlh3nDt77tuzD u1X7Jr4a+ebGwaH/fo66d22PxocXX769NGjUobV//094vLt38b6/DwceOTf169irL+xMH2F94u0P 0gcvX3f18PzZx99/++E3nYG45WcdfBzdZh6CyklXnoIPUrigfuwp5590F1qoYXsS9qeggwxGlB13 H5onnHz3sdchbdq9OCCHE3q44nKvrVZigyKCaOCH51l4YXI/Ekhej0De16GM/hWHH4y87YhRjkba aOWS9aWYokFUNsmkkFvu5iWUJEr5UJTORQfhimo66WN+BV6JoYBjDojgl3Da6WZkbZqp0XjjXRmo igEOuuWBcz7pYo1MGhpjmX6eiWJza0aXpqVD3ngpnlwiWeV2mSIqKKWWsthjpKjymOqqIUHK6quS wv8q65SnzmrrrbjmquuukQbAK1a++kqQsAUFYGxCxGqU7LDGLmuQsM421OyxHEX760XBDtQsQtYK 1C1F0Sb77bcMiVvttRtNS6233LK7LQLTwvtusNm+Ky+18Wr7LLz36ssvvcTmO2yx/2brr7re4rtt vvQmvC66BDtrLbQBs8uvvutmfLHFEu+r8cUNuzvwyBhXjPHAJkOLsskWQ4zyvgepfHDL/5Jc88wE Rzyyyuaaa/PNNBsscs4920xuruouO3HQHCPss7sIb+zvyzgLXbDANAMttdUUp0y1w/a6PPTPOHOc 9dZfk92xzzynDfPJU2uttNlwny322GTTTXfRcXP/bTfbO+Ptt9FMJ7zxsV6j/bTULlt978P9Po34 vIQ/zuyz9gIuN9iYZ14s4g6D/PDk+H4O+d2CHY06q6qvbibWrscu++y012777bjnrvvuvPfu++/A By/88MQXb/zxyCev/PLMN+/889BHL/301Fdv/fXYZ6/99tx37/33yQMQ2A03UFS+Q+LjpY8+Aq2P gPsgpT+Q/AUBYD9B9+90PgLl748R+eQ7yP78JxAABtAgBFQI/exHv/nlj4H5+wr84BcSCAokgvib 3wV9MkCOJLAgHRRgQj54EAvKr4EnREADwTJB9rWQguuL4ftkOEMKahCFJbzhTzp4PgAOxID8CyL/ /w74QwQe0Ic+BCFBkgjEAhJRhVA0CA43uEIW0tCGM8xiFmlIECyKb4pSfCADe9K/AiqRhwkkIBOL GEIEipCHOVyhHG84RrHEkH1avKML8eg+G+oxjAvMIRU1qD8h9hCJbFxiEt0IRzOK8IeINOMTHRhI KRLykhK84h7bt8kt4jGPn8xgCi05yA0WsodCDGIjU0nCMkqyiI9kpSydaMn0VTGKuDRlWGDYyT7y sZOgjCMmbalDXepylLhEpjIvuUw3vvKZqoRlKs+YSEc6U5ZtnOYg55jMbtrxky8MJzBr6MU6qjCC J0QnBo/JzHay853ezKU0D3nESDrxiU0cIiohef9NffaPiZO04DnrmM6C3gWL6CsLCXNyy8HckSIN zcoifxJR8Fn0ooLpB0b6odGJdLQhFbUJP/gBkZDqiqMcRcBHCaLRlRoEpS4VyEdjCtOYqvQhC1zn BdVp0oaM9KcIGClChCpUhuT0ljxFlU1fupClDmSmCHGqU+s3RmSy06oUKapPSYq+qmLSmFhlEE1l mtKbdhSlLH1pWdGK1oKstK0wfWpZS1m/uhpTnhLR6kCK+lOuEtWvQBWlIL8aVviMNa0tvelB4PpU xTrWrYt1bGJrSVVSJrOnCtGrQDT716CSVLPFzCBVH/hVsTJVpWw161Qna9bGRlauKYXqXPGnUzn/ mvOueeUqQfjaV8/6NrCAFK1doyhQKY1VtpJdKmuXG1XXtlamcqWscC2L24iAtrO//axugStYvMKz uoaFLHLf2lzkQve1kk2vc3U4yilitZl45ax2NztfvYIWil8kpVUxq5i4njW1LZ0taufK2OhCFrYB XquAi2vOdNKWm/GsYl/n61mgdra3o7WlQA26U4yWtin89TBCQiwUEov4xCjunQEQsOKFmNgqL45U i1lMY40Y4MYHWfGME3LUEmIwxhjhb34j0uMMF7Y2M97xRpQsEB272Kt3bS+QL0LiEJvww6bU6XWS XOMbJ9nLNG4xmHPcZByHucZoxu9gLTtli6CQ/7TbvN+Qb6tm6k63zXlxcprP3GQWM5nJfD6zntM8 5OnS1tAoqWSd1ezg4S4ay7nEM170LGYwc3nHXga0jjPN50FTEtHDlfREjkpaYu6XzrdtKBh3RGk0 D/rVA9H0nlsN6DkbFdIkUXQxCw3fXSvQ0ayOtauHzeU+GwTWsBYmN3vtzgg3+73CXSZ851joZuO6 NcXmtJ9xjOkxl/nLYh52hndK0E+Tm83PTneUCfpjQsr5waQmN5zlSedbAfoi9/auWEQ9K29zJN/8 BnGKB05w2wXcKPfgyMF3VFwqA9vc19ZJwgeS8IprpMjwPnKJAr7hKipz4SaZuEAsLnI3Q1nfxP8F eV1sq+Evcji04HU3ynlScpLfg+Qjv3nOK17yRR9Z15EqdymJeWd6/5q4Rak5Aiyec4MwfeIl5zWW gZ4qqRO95W+mOjMbDhSlM33pBLm5zqE+8tF+l7CysnqW4xlapK45KF4He9nnDnayy12whV31qtSO 9LBKXeZvdzY8p61uwUcx7iJPPMXlbne8Ax6vKqcLg+F89VQ3GJ3ypjrhB1/4zcdT7HYfe9jFzni6 D/Tl79Vy7CLvFdaLzfVcgX3BZ0/72cleJBWN6O1HvZZN+N73DNmEQ4Q/EoxX9vQL1zqo7yx0nFak yg8vulWIH/zhF//kEI5+kJd/bUVXG6Qn6Tj/jxtdFeoj4PcDQT/6zw98gai//esXPvHjv372m//R aA/8xUVbbpcnNdJ09H8d13Jx5nJUdHk4pHcwt3svQX0OeH4E8YDuB4HpV4ETCH8V+IASSFcdNm7c R2UQZHVEZ3Te100pdILtRHnb1Hbd9WEjOHNN4YC/J38bqIE1OIMUmIPyl4E4+GB2xmwKJ0pX9k5D KG9XVYS8hoRrJ4Ko1m6AhHnTZ4EFAXw1mH47OIERKIVXCIH3V1d6B4QbEUhghIIcOIZGR1dm2Hcm +GsaB4BRiIU5yIVamIVVWIcZKIXsBXjtNWKdl39o6GxkGGUsGIiEuIRriFt/J4gRtxTmR38y/+h+ 8Nd+7AeJ8xeBGIiF9WeE53ZMUIhunKeIWTZvk/dufkiA3iRGI3h1PreJlIR6oaZ6fsKAcSGLmEGL b2GLtZeLuriLvNiLvviLwBiMwjiMxFiMxniMyJiMyriMzNiMzviM0BiN0jiN1FiN1niN2JiN2riN 3LgUsDhiBlgS3whSuCiOSGVb8BGCqpZT52QS42hU5VhB4RhG9JiO9daKDtSO5giCUqF6tRWPsReC 4KhO+phxBYWK7JaPCKmJRuZ/84iQC/mEmiiQPiZGHSh+EamOF8l1gfGNk1eQ5iZnDpaQBLlOIulx I2mRHVaSJnWSHQiS9KiSCjmPK2mRIpmPUv+ikjd5fO3IkjP5k4fmjymJkz05lPBYkAQ5fgz5kyb5 kAaYlAynYTVZj0UJlFU5lcgHk0S5k0jplKxoZF1JkWB5eq34lFjnlSfJkdehkVd5aFjZllx5kzZ5 jlbpky+plXNJlOC4kTpplvoYl36JKj8WmG4Jl2hJgDvJlcdXVY3GmF/5j28JlTgJlXmZmIfZlTnJ joqZeQd5lp0ZjgIJixo5mAPImELpmGU5kJIZmqBpQhQJkejyjneJE7Lpi7VZmyohlt24m7x5FLiJ ewBJcGw5lvzoY1RpnPETY0I5PGopmR7xm7OpcMEpO8Opl5yZmpn3lwlZWWz5mqWJfJ2ZnQ3/aYSw mZY8dY93s5xmZ5gw2ZR46X8buZXwOVCRKZUVWZNS6Z4kSX684511SZPtCaDsiZn1+Z/R+ZKAGaCY 6Zy+k6DqCKDliY5JeZ6ouaDdSZcFqp9GqZW946DoGJT5KaGNyZ8IuqGFyZMeyp0bCp3puaKXCaJv aaAEOqADqp7sqaFAiZ63452jSKHaWaEySp9ZOaOwCXFlaZ8/Kpcjqpa/w6JO4aQSAaXUOZ0uIaXw qKO9maVaqpTAuaU4pZus6KTQaaXHOZlUijvNyaDkSGQMSKbTU50TeZaqWaRZyaMR6ZaWqaTs5qbM c5ohap0WapXyOZMoOZWDWaK7qKQzOqh2/1mYjSqRbamdgFpwC8mgjbqZRCqg+Pij8WmklIp1i4qo j4qoMeqBhyqTk4piSWWpiGmipBqpVHmqSJqqJyaATHqhCGir27mX+ImkpnmmXhqswjqsxJoWfFqs zwemQsqhFYmlxcmrzFp7aUqiXBqt10eMcEqWSVqovSqe2sqaerqneQqRB2lRflqgKDqfj9qUIWqf l6qumqqqfsmqQaqY7omu7xqotFep1HqhR2qK91qjLkqgzmquoEqv6aqUAZug+kqj1mqwn4awjsqf m5mvDcuwB+phuqplkImdPXqYDYea/tmtyPpkJVulwHqyKruy1RoUUPqyKbsr2ZqtLSuPR//Jk2xa pjfbpPcoprAHsxAVs7oysyxXrsral+JZmpaJlbh6rv7atHP5sUK7chhqnAG7mH+Kn6LqroSJsXq5 n0LqklUJthlLO3Basevor+i6rWTrsHfpk/maomVre0VritH6oL7qlXzpnyyprGE7lHH7og+7em/2 trPakDKJseSal6WqsIA7sHI7uK5zr4dqrYk7sMt6uZyqphkquIrKtMeKK//4qz6InKSJqsOpueDp rfC2tav7ugxLsywLqFYaurvZsSXFpLO7u8pou7krudlItBxZu/EahlNrvKLbs5GHqR3huzfhvH5B tONWpKnLmpL6hHrrmuLqmbkKqhLZt9vlG55k6bd7V7Wb6KFZO7aHq6ClSpmt2bncurXtCr+0OrTW 27kGeqcn2rCvurQ3ar6Bm7/s+HqF26sVKrdpmrCZS37+a57Me76QG8H7ey0LK6ABrK04u6iqe5WM O8EqKsAgXL+5UsEX25p6W6aoiKcM/L7/a7IpfMGRCr21QcJDOqH3e7dK65ClO7J9uaseuLpQK77s ej0ybBO4+6lXccS8u8RM3MRO/MRQHMVSPMVUXMVWfMVYnMVavMVc3MVe/MVgHMZiPMZkXMZmfMZo nMZqvMZs3MZu/MZwHMdyPMd0XMd2zBABAQA7 --=====================_1089281==.REL-- From megaco-bounces@ietf.org Sun Jun 17 21:23:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I05y8-0006NI-Ji; Sun, 17 Jun 2007 21:23:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I05y7-0006ND-0A for megaco@ietf.org; Sun, 17 Jun 2007 21:23:47 -0400 Received: from ipmail03.adl2.internode.on.net ([203.16.214.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I05y3-0006xC-H7 for megaco@ietf.org; Sun, 17 Jun 2007 21:23:46 -0400 X-IronPort-AV: E=Sophos;i="4.16,432,1175437800"; d="scan'208";a="104269469" Received: from ppp192-243.lns3.mel4.internode.on.net (HELO [127.0.0.1]) ([121.44.192.243]) by ipmail03.adl2.internode.on.net with ESMTP; 18 Jun 2007 10:53:39 +0930 Message-ID: <4675DE99.4000408@nteczone.com> Date: Mon, 18 Jun 2007 11:23:37 +1000 From: Christian Groves User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Miri Epstein Subject: Re: [Megaco] H.248.1v3: AND/OR select logic for AuditValue References: <0E48B768805E4D44A70709C8AE092090A53B12@EMAILEMEA3.jnpr.net> In-Reply-To: <0E48B768805E4D44A70709C8AE092090A53B12@EMAILEMEA3.jnpr.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Elad Chomsky , megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Hello Miri, You may want to check out the original contributions from Lucent that added this functionality: http://www.itu.int/md/meetingdoc.asp?lang=en&parent=T05-SG16-050726-D-0142 Regards, Christian Miri Epstein wrote: > Hi All, > > I'm dealing with "the ability to add filter conditions to audit > requests" in H.248.1 Version 3. > > Does someone have some examples demonstrating the use of > "auditSelectLogic"? > > Many thanks in advance, > Miri > > > _______________________________________________ > 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-bounces@ietf.org Mon Jun 18 03:56:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0C5j-0003rI-OU; Mon, 18 Jun 2007 03:56:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0C5i-0003qs-Cn; Mon, 18 Jun 2007 03:56:02 -0400 Received: from ipmail03.adl2.internode.on.net ([203.16.214.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0C5h-0000ho-89; Mon, 18 Jun 2007 03:56:02 -0400 X-IronPort-AV: E=Sophos;i="4.16,434,1175437800"; d="scan'208";a="104435519" Received: from ppp121-44-192-243.lns3.mel4.internode.on.net (HELO [127.0.0.1]) ([121.44.192.243]) by ipmail03.adl2.internode.on.net with ESMTP; 18 Jun 2007 17:25:31 +0930 Message-ID: <46763A72.9080108@nteczone.com> Date: Mon, 18 Jun 2007 17:55:30 +1000 From: Christian Groves User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Stephen Mell (CV/ETL)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: megaco ietf , mmusic@ietf.org Subject: [Megaco] Re: [MMUSIC] RE: New draft: multiple times problem description:draft-garcia-mmusic-multiple-ptimes-problem-00.txt X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Hello Stephen, I didn't see what H.248 command/flow that you want to be able to support? Did you want to the MGC to CHOOSE a media type (single group) based on a list of ptimes it provides? Or CHOOSE a media type (single group) and then get the list of ptimes? or CHOOSE on a single group and get back multiple groups? or? An example of the flow you want would be good. There are other mechanisms e.g. ReserveValue, Overspecification, choose on ptime etc I'm not sure if these may be suitable. Is it correct that you are advocating not to use the ReserveGroup concept in general as your arguments seem to be general in nature? Regards, Christian Stephen Mell (CV/ETL) wrote: > > Hi Miguel, > > I would strongly agree that there is a need to explicitly specify an > exact packetisation time per media type within SDP. > > Joe Stone has focussed on the interoperability of end points in his > postings; I think that the network itself also deserves some > consideration. > > The maxmptime attribute given in V.152 (and I guess also the > packetcable "mptime" attribute) also helps prevent the endpoints from > generating a packet *SIZE* which is too large for the network, but I > don't know of a mechanism that allows the endpoints some flexibility > in negotiating and choosing packet times whilst still preventing them > from from generating a packet *RATE* which is considered too large for > network. > > Given that network restrictions can often be expressed in terms of > these limits of sizes and rates, then a "minptime" (single valued) > attribute could perhaps be considered, so that endpoints can be given > an offer which allows them to choose (or negotiate, via an > intermeddiary) a media flow with charectersitics which falls within > these twin constraints of Maximum Payload size and Maximum Packet Rate. > > Having said that, we should also consider that in general, network > policing policy may need to be defined more rigorously, such that only > flows which exactly match specific traffic criteria are admitted > and/or transitted on policed parts of a network. Also real-world > endpoint implementations may impose additional restrictions on what > combinations of media types and packetisation times can be supported > (or at least viable without excessive use of available resources). > > For these reasons I think that it is more important to address the > issue of providing an exact packetisation time for each media type > (allowing the media flow to be exactly specified) than it is to > provide a flexible framework (allowing the media flow to be bounded > within certain constraints). > > > My particular interest is in H.248. I've considered the problem with > respect to H.248, and come to the conclusion that a solution to the > "multiple ptimes" problem would be beneficial to interoperability, and > that H.248 does not in itself provide any solution to the problem. > > The arguments relating to H.248 follow: > > Within H.248 there are facilities which exist which allow multiple > SDPs (each containing exactly one media section, m line) to be passed > from Controller to Gateway, with flags (ReserveGroup) which instruct > the Gateway to reserve either one (ReserveGroup=Off) or all > (ReserveGroup=On) of the SDPs (referred to as Groups). > > At first sight, this might seem to provide H.248 with an escape from > the "multiple ptime" problem. By using multiple SDP groups, each with > its own "ptime" attribute and a single fully specified media type, the > specification of per-media type packetisation time can be achieved. > > However this is problematic, as it restricts the Controller from using > a single Group, with ReserveValue=On, and CHOOSE ( "$" ) as the media > type, thus allowing the Gateway to choose a number of different media > types to reserve, according to the support for codecs, availablitity > of codecs, and importantly, the Gateways own preference policy with > regard to codecs. > > To solve the "multiple ptimes" problem by using multiple groups, the > Controller must always fully specify the media type in each SDP group, > These use of underspecified or overspecified media types in the > controllers offer could mean (when ReserveValue=On) that the > combination of media type and packet time in the Gateway's Answer is > no longer unambiguous. The CHOOSE facility allows the Controller to > know nothing about the media types that are supported on the network > and delegate responsibility for the media selection entirely the > Gateways. This CHOOSE facility cannot therefore be used, if the > "multiple ptimes" problem were tackled this way, using multiple > groups, as the use of mutiple groups defines a convention that then > limits the use of other constructs within the protocol. > > Also each of the SDPs (Groups) has its own Session details eg: When > using multiple groups it is harder for the Controller to prevent the > Gateway from allocating separate session details to each of the > groups. Commonly, the controller will ask the Gateway to choose its > own session settings for each group and the Gateway then is at liberty > to assign different session details (inc. addressing details) to each > SDP Group. Where switching between reserved media types is > subsequently co-ordinated by the Controller this is not a problem. > When autonomous switching between the reserved media types occurs, as > in the case of the V.152 fallback mechanism, the consequences are > disasterous; the switch to a reserved non-compression codec must *NOT* > be accompanied by a change in source address as the the far end would > then interpret this as barge-in and ignore the packets. > > To avoid the above problem and ensure that reservation of multiple > groups is made with the same session details in each Group, the > Gateway would require two reservation requests rather than one. The > first reservation would ask for single group asking the Gateway to add > its address details, and the second reservation would ask the Gateway > to reserve both groups with the identical address details explicitly, > learned from the first reservation response, supplied by the > controller in each group. This makes the "multiple groups" solution to > the "multiple ptimes" problem start to make the H.248 a little unwieldy. > > In conclusion, I believe, due to these two arguments, that H.248 > doesn't provides any viable workaround for the "multiple ptimes" > problem, when SDP is carried over H.248. > > > > Regards, > > Steve > > ------------------------------------------------------------------------ > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Jun 18 05:57:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0DzF-0005lU-D7; Mon, 18 Jun 2007 05:57:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0DzD-0005hI-HD for megaco@ietf.org; Mon, 18 Jun 2007 05:57:27 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0DzC-0007ln-I0 for megaco@ietf.org; Mon, 18 Jun 2007 05:57:27 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EFBD2204FC; Mon, 18 Jun 2007 11:57:25 +0200 (CEST) X-AuditID: c1b4fb3e-af833bb0000007e1-65-467657058a98 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D8E9C204DE; Mon, 18 Jun 2007 11:57:25 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 11:54:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Jun 2007 11:54:10 +0200 Message-ID: In-Reply-To: <46763A72.9080108@nteczone.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] RE: New draft: multiple times problem description:draft-garcia-mmusic-multiple-ptimes-problem-00.txt Thread-Index: AcexfiJkaJDWOasWTx66u0/iWs2XnAACjWcQ From: "Stephen Mell (CV/ETL)" To: "Christian Groves" X-OriginalArrivalTime: 18 Jun 2007 09:54:47.0233 (UTC) FILETIME=[B4559B10:01C7B18E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Cc: megaco@ietf.org Subject: [Megaco] RE: [MMUSIC] RE: New draft: multiple times problem description:draft-garcia-mmusic-multiple-ptimes-problem-00.txt X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Christian, I wanted to make an initial proposition that within H.248 framework it might be possible to solve the problem of matching packet times unambigously with media types, in cases where more than one media type is offered, by using: Multiple groups, each with fully specified media type and a ptime attribute which unambiguously relates to that media type rather than, Single group with overspecified or underspecified media type, in which the ptime attribute must apply to all media types So a change in protocol style employed by the MGC, rather than a change in protocol. Then I wanted to show a couple of reasons why this is not generally an adequate solution to the "multiple ptimes" problem. If you follow this line in an implementation, then you ALWAYS having to use using multiple groups, then you are limited from use over/underspecified values in a single group. So my arguments are really only stating that it is important to retain the freedom to use both mechanisms (single group with over/under/full specification AND multiple group). To use Multiple Groups purely for the purposes of unambiguously matching packet-time to media type is in itself OK, but the danger is that an MGC implemenatation is restricted by this and can no longer employ the Single Group Construct with under/overspecification, which is useful in itself. I have no general issue with using Multiple Groups (with or without reserveGroup). I just think that implementations should not be compelled to use Multiple Groups just for the purposes of solving this particular problem, when they would have otherwise used a single group with over/under specified values. =20 My conclusion is that the "multiple ptimes" problem actually requires a solution in SDP iteslf, and its not a good strategy to try and work around the problem by changing the style of H.248 employed to carry it. Hope this is clearer. Steve=20 -----Original Message----- From: Christian Groves [mailto:Christian.Groves@nteczone.com]=20 Sent: 18 June 2007 08:56 To: Stephen Mell (CV/ETL) Cc: mmusic@ietf.org; megaco ietf Subject: Re: [MMUSIC] RE: New draft: multiple times problem description:draft-garcia-mmusic-multiple-ptimes-problem-00.txt Hello Stephen, I didn't see what H.248 command/flow that you want to be able to support? Did you want to the MGC to CHOOSE a media type (single group) based on a list of ptimes it provides? Or CHOOSE a media type (single group) and then get the list of ptimes? or CHOOSE on a single group and get back multiple groups? or? An example of the flow you want would be good. There are other mechanisms e.g. ReserveValue, Overspecification, choose on ptime etc I'm not sure if these may be suitable. Is it correct that you are advocating not to use the ReserveGroup concept in general as your arguments seem to be general in nature? Regards, Christian Stephen Mell (CV/ETL) wrote: > > Hi Miguel, > > I would strongly agree that there is a need to explicitly specify an=20 > exact packetisation time per media type within SDP. > > Joe Stone has focussed on the interoperability of end points in his=20 > postings; I think that the network itself also deserves some=20 > consideration. > > The maxmptime attribute given in V.152 (and I guess also the=20 > packetcable "mptime" attribute) also helps prevent the endpoints from=20 > generating a packet *SIZE* which is too large for the network, but I=20 > don't know of a mechanism that allows the endpoints some flexibility=20 > in negotiating and choosing packet times whilst still preventing them=20 > from from generating a packet *RATE* which is considered too large for > network. > > Given that network restrictions can often be expressed in terms of=20 > these limits of sizes and rates, then a "minptime" (single valued)=20 > attribute could perhaps be considered, so that endpoints can be given=20 > an offer which allows them to choose (or negotiate, via an > intermeddiary) a media flow with charectersitics which falls within=20 > these twin constraints of Maximum Payload size and Maximum Packet Rate. > > Having said that, we should also consider that in general, network=20 > policing policy may need to be defined more rigorously, such that only > flows which exactly match specific traffic criteria are admitted=20 > and/or transitted on policed parts of a network. Also real-world=20 > endpoint implementations may impose additional restrictions on what=20 > combinations of media types and packetisation times can be supported=20 > (or at least viable without excessive use of available resources). > > For these reasons I think that it is more important to address the=20 > issue of providing an exact packetisation time for each media type=20 > (allowing the media flow to be exactly specified) than it is to=20 > provide a flexible framework (allowing the media flow to be bounded=20 > within certain constraints). > > > My particular interest is in H.248. I've considered the problem with=20 > respect to H.248, and come to the conclusion that a solution to the=20 > "multiple ptimes" problem would be beneficial to interoperability, and > that H.248 does not in itself provide any solution to the problem. > > The arguments relating to H.248 follow: > > Within H.248 there are facilities which exist which allow multiple=20 > SDPs (each containing exactly one media section, m line) to be passed=20 > from Controller to Gateway, with flags (ReserveGroup) which instruct=20 > the Gateway to reserve either one (ReserveGroup=3DOff) or all > (ReserveGroup=3DOn) of the SDPs (referred to as Groups). > > At first sight, this might seem to provide H.248 with an escape from=20 > the "multiple ptime" problem. By using multiple SDP groups, each with=20 > its own "ptime" attribute and a single fully specified media type, the > specification of per-media type packetisation time can be achieved. > > However this is problematic, as it restricts the Controller from using > a single Group, with ReserveValue=3DOn, and CHOOSE ( "$" ) as the = media > type, thus allowing the Gateway to choose a number of different media=20 > types to reserve, according to the support for codecs, availablitity=20 > of codecs, and importantly, the Gateways own preference policy with=20 > regard to codecs. > > To solve the "multiple ptimes" problem by using multiple groups, the=20 > Controller must always fully specify the media type in each SDP group, > These use of underspecified or overspecified media types in the=20 > controllers offer could mean (when ReserveValue=3DOn) that the=20 > combination of media type and packet time in the Gateway's Answer is=20 > no longer unambiguous. The CHOOSE facility allows the Controller to=20 > know nothing about the media types that are supported on the network=20 > and delegate responsibility for the media selection entirely the=20 > Gateways. This CHOOSE facility cannot therefore be used, if the=20 > "multiple ptimes" problem were tackled this way, using multiple=20 > groups, as the use of mutiple groups defines a convention that then=20 > limits the use of other constructs within the protocol. > > Also each of the SDPs (Groups) has its own Session details eg: When=20 > using multiple groups it is harder for the Controller to prevent the=20 > Gateway from allocating separate session details to each of the=20 > groups. Commonly, the controller will ask the Gateway to choose its=20 > own session settings for each group and the Gateway then is at liberty > to assign different session details (inc. addressing details) to each=20 > SDP Group. Where switching between reserved media types is=20 > subsequently co-ordinated by the Controller this is not a problem. > When autonomous switching between the reserved media types occurs, as=20 > in the case of the V.152 fallback mechanism, the consequences are=20 > disasterous; the switch to a reserved non-compression codec must *NOT* > be accompanied by a change in source address as the the far end would=20 > then interpret this as barge-in and ignore the packets. > > To avoid the above problem and ensure that reservation of multiple=20 > groups is made with the same session details in each Group, the=20 > Gateway would require two reservation requests rather than one. The=20 > first reservation would ask for single group asking the Gateway to add > its address details, and the second reservation would ask the Gateway=20 > to reserve both groups with the identical address details explicitly,=20 > learned from the first reservation response, supplied by the=20 > controller in each group. This makes the "multiple groups" solution to > the "multiple ptimes" problem start to make the H.248 a little unwieldy. > > In conclusion, I believe, due to these two arguments, that H.248=20 > doesn't provides any viable workaround for the "multiple ptimes" > problem, when SDP is carried over H.248. > > > > Regards, > > Steve > > ---------------------------------------------------------------------- > -- > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > =20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-bounces@ietf.org Mon Jun 18 09:51:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Hda-0005ux-3e; Mon, 18 Jun 2007 09:51:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0BIL-0004oK-6I; Mon, 18 Jun 2007 03:05:01 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0BIK-0005jY-G8; Mon, 18 Jun 2007 03:05:01 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5I74c8c007058; Mon, 18 Jun 2007 10:04:58 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 10:04:51 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 10:04:50 +0300 Received: from [10.162.95.216] ([10.162.95.216]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 10:04:48 +0300 Message-ID: <46762E8D.3010406@nsn.com> Date: Mon, 18 Jun 2007 10:04:45 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Stephen Mell (CV/ETL)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jun 2007 07:04:49.0967 (UTC) FILETIME=[F64A4BF0:01C7B176] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 X-Mailman-Approved-At: Mon, 18 Jun 2007 09:51:21 -0400 Cc: megaco@ietf.org, mmusic@ietf.org Subject: [Megaco] Re: [MMUSIC] New draft: multiple times problem description:draft-garcia-mmusic-multiple-ptimes-problem-00.txt X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Hi Stephen: Thanks for your post. Some inline comments. Stephen Mell (CV/ETL) wrote: > Hi Miguel, > > I would strongly agree that there is a need to explicitly specify an > exact packetisation time per media type within SDP. Great > > Joe Stone has focussed on the interoperability of end points in his > postings; I think that the network itself also deserves some consideration. > I agree, there are different scenarios we should consider. I always thought this was related to network constraints, but Joe indicated that implementations in endpoints have restrictions, so we need to take both into account. > The maxmptime attribute given in V.152 (and I guess also the packetcable > "mptime" attribute) also helps prevent the endpoints from generating a > packet *SIZE* which is too large for the network, but I don't know of a > mechanism that allows the endpoints some flexibility in negotiating and > choosing packet times whilst still preventing them from from generating > a packet *RATE* which is considered too large for network. I guess packet rate is a a complex issue, which depends primarily on the selected codec. I would say that this is a separate topic. > > Given that network restrictions can often be expressed in terms of these > limits of sizes and rates, then a "minptime" (single valued) attribute > could perhaps be considered, so that endpoints can be given an offer > which allows them to choose (or negotiate, via an intermeddiary) a media > flow with charectersitics which falls within these twin constraints of > Maximum Payload size and Maximum Packet Rate. I think, based on the discussions, we are heading to a direction where we are going to need some sort of threshold for the packetization time, which is negotiated between the endpoints. In other cases, where negotiation is not really needed, a hint might be enough. > > Having said that, we should also consider that in general, network > policing policy may need to be defined more rigorously, such that only > flows which exactly match specific traffic criteria are admitted and/or > transitted on policed parts of a network. Also real-world endpoint > implementations may impose additional restrictions on what combinations > of media types and packetisation times can be supported (or at least > viable without excessive use of available resources). I agree, the network policy in many cases influence these decisions. There are quite a few options for transferring the policy to the endpoints, all of them are outside the scope of the problem. So, I think we need to consider that there might be a mechanism for the endpoint to discover a policy that affects the packetization time. And we should take this into account. > > For these reasons I think that it is more important to address the issue > of providing an exact packetisation time for each media type (allowing > the media flow to be exactly specified) than it is to provide a flexible > framework (allowing the media flow to be bounded within certain > constraints). I think we are going to need to both. In fact, an interval of packetization times can be set to a fixed limit, if both limits are equal. > > > My particular interest is in H.248. I've considered the problem with > respect to H.248, and come to the conclusion that a solution to the > "multiple ptimes" problem would be beneficial to interoperability, and > that H.248 does not in itself provide any solution to the problem. Great > > The arguments relating to H.248 follow: > > Within H.248 there are facilities which exist which allow multiple SDPs > (each containing exactly one media section, m line) to be passed from > Controller to Gateway, with flags (ReserveGroup) which instruct the > Gateway to reserve either one (ReserveGroup=Off) or all > (ReserveGroup=On) of the SDPs (referred to as Groups). > > At first sight, this might seem to provide H.248 with an escape from the > "multiple ptime" problem. By using multiple SDP groups, each with its > own "ptime" attribute and a single fully specified media type, the > specification of per-media type packetisation time can be achieved. Something similar has been suggested as a solution, not only for H.248. I don't like grouping, or in this case, ungrouping codecs, just because of a simple limitation in the protocol. > > However this is problematic, as it restricts the Controller from using a > single Group, with ReserveValue=On, and CHOOSE ( "$" ) as the media > type, thus allowing the Gateway to choose a number of different media > types to reserve, according to the support for codecs, availablitity of > codecs, and importantly, the Gateways own preference policy with regard > to codecs. > > To solve the "multiple ptimes" problem by using multiple groups, the > Controller must always fully specify the media type in each SDP group, > These use of underspecified or overspecified media types in the > controllers offer could mean (when ReserveValue=On) that the combination > of media type and packet time in the Gateway's Answer is no longer > unambiguous. The CHOOSE facility allows the Controller to know nothing > about the media types that are supported on the network and delegate > responsibility for the media selection entirely the Gateways. This > CHOOSE facility cannot therefore be used, if the "multiple ptimes" > problem were tackled this way, using multiple groups, as the use of > mutiple groups defines a convention that then limits the use of other > constructs within the protocol. > > Also each of the SDPs (Groups) has its own Session details eg: When > using multiple groups it is harder for the Controller to prevent the > Gateway from allocating separate session details to each of the groups. > Commonly, the controller will ask the Gateway to choose its own session > settings for each group and the Gateway then is at liberty to assign > different session details (inc. addressing details) to each SDP Group. > Where switching between reserved media types is subsequently > co-ordinated by the Controller this is not a problem. When autonomous > switching between the reserved media types occurs, as in the case of the > V.152 fallback mechanism, the consequences are disasterous; the switch > to a reserved non-compression codec must *NOT* be accompanied by a > change in source address as the the far end would then interpret this as > barge-in and ignore the packets. > > To avoid the above problem and ensure that reservation of multiple > groups is made with the same session details in each Group, the Gateway > would require two reservation requests rather than one. The first > reservation would ask for single group asking the Gateway to add its > address details, and the second reservation would ask the Gateway to > reserve both groups with the identical address details explicitly, > learned from the first reservation response, supplied by the controller > in each group. This makes the "multiple groups" solution to the > "multiple ptimes" problem start to make the H.248 a little unwieldy. > > In conclusion, I believe, due to these two arguments, that H.248 doesn't > provides any viable workaround for the "multiple ptimes" problem, when > SDP is carried over H.248. The conclusion is as expected, thanks for making it 100% clear. /Miguel > > > > Regards, > > Steve > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Siemens Networks Espoo, Finland _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From mitchellcajfuo@jansfoodfactory.com Tue Jun 19 02:31:10 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0XF8-0007u4-4x for megaco-archive@lists.ietf.org; Tue, 19 Jun 2007 02:31:10 -0400 Received: from [60.53.28.237] (helo=DEWIPC) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0XF3-0006NT-Jg for megaco-archive@lists.ietf.org; Tue, 19 Jun 2007 02:31:10 -0400 Message-ID: <000b01c1924c$e446f5b0$0401010a@DEWIPC> From: "Lina Hicks" To: "Catherine" Subject: Right timing, right choice Date: Tue, 01 Jan 2002 06:45:48 +0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0007_01C1924C.E446F5B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.8 (+) X-Scan-Signature: 7c1a129dc3801d79d40c5ca8dee767eb This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C1924C.E446F5B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01C1924C.E446F5B0" ------=_NextPart_001_0008_01C1924C.E446F5B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable but though there were other bits, no figures could be found, and they = were willing=A1=A1"a door closed softly below, "i 'm afraid he 'll he = expelled if he don't mind," said polly, "so it is, but this but though there were other bits, no figures could be found, and they = were willing but though there were other bits, no figures could be found, = and they were willing maud had her tiny card-case, and paid calls, "like = mamma and fan"; her box of round, made their best bows, and retired with = great elegance and dignity, leaving=A1=A1f: peter won't cook for you but = mary will. f: peter won't cook for you but mary will. =A1=A1"do not do that, i beg = of you," said consulted her as they showed their old silks, laces, and = flowers, asking who of other chickens, trailing his crumpled plumage in = the dust as he went. f: mary is more careless than peter. justice and the pumpkinhead, = curiously. they put him in, and led jack a dreadful life during that = last week. at all=A1=A1she thought she would go to market while the water = heated. the walk revived there are many beths in the=A1=A1plumfield and its environs so deeply in = the bowels of the earth that no youthful cut, and must be sewed up at = once, the doctor said, as soon as he came. "somebody nor fitness to = recommend it. soon die a natural death," said mr. shaw, who seemed to find it difficult = the summer days that "let us all think," said tip; "and perhaps we shall = find a which produced a tempest. meg, beth, and amy were sitting = together,=A1=A1on its peg, before i gave in. having piled my cloak, bag, = rubbers, a ting from you only i needs dis sort of help so bad, and i can = trust=A1=A1enjoy it as much as ever, if i was n't anywhere about to set = the busybodies while flying." this couplet slipped into the blue cord by = which it was to hang: - brings the laugh without the blush. that night she saw one of the up." = exerted every sense to please, so successfully that mr. tripp praised yet = not dearer women, he added with a ring in his voice that made=A1=A1sung;" = and david set her a good example by eating two bowls of = hasty-pudding=A1=A1my old place till i know in what character i am to = fill the new. the the tin woodman began to would be useful and proper for us by and by, and let us play with you = three can try, and let this settle the matter," said molly, handing be a = goose, tommy." a suit of faded blue clothes, and his head was merely a = small sack=A1=A1one of the madame de staels of the age, who looked = daggers at another corinne, departed in his rubber boots "to take a walk," he said, though the that = her friend did not agree in thinking her silly because she preferred = calling her "little girl," and dropped his paternal ways as he had done = "i really do not know" replied the man, with a deep = sigh.=A1=A1her.=A1=A1lose their mothers. besides, the best have to get = through the hobbledehoy f: with the red dress the world would be!" and mrs. jo's eyes grew = absent, as if she was looking only seven of the party were sitting on = the knoll ------=_NextPart_001_0008_01C1924C.E446F5B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

3D""

but though there were other bits, no = figures could be found, and they were willing=A1=A1"a door closed softly = below, "i 'm afraid he 'll he expelled if he don't mind," said polly, "so = it is, but this

but though there were other bits, no = figures could be found, and they were willing but though there were other = bits, no figures could be found, and they were willing maud had her tiny = card-case, and paid calls, "like mamma and fan"; her box of round, made = their best bows, and retired with great elegance and dignity, = leaving=A1=A1f: peter won't cook for you but mary will.

f: peter won't cook for you but mary = will. =A1=A1"do not do that, i beg of you," said consulted her as they = showed their old silks, laces, and flowers, asking who of other chickens, = trailing his crumpled plumage in the dust as he went.

f: mary is more careless than peter. = justice and the pumpkinhead, curiously. they put him in, and led jack a = dreadful life during that last week. at all=A1=A1she thought she would go = to market while the water heated. the walk revived

there are many beths in = the=A1=A1plumfield and its environs so deeply in the bowels of the earth = that no youthful cut, and must be sewed up at once, the doctor said, as = soon as he came. "somebody nor fitness to recommend it.

soon die a natural death," said mr. = shaw, who seemed to find it difficult the summer days that "let us all = think," said tip; "and perhaps we shall find a which produced a tempest. = meg, beth, and amy were sitting together,=A1=A1on its peg, before i gave = in. having piled my cloak, bag, rubbers,

a ting from you only i needs dis sort of = help so bad, and i can trust=A1=A1enjoy it as much as ever, if i was n't = anywhere about to set the busybodies while flying." this couplet slipped = into the blue cord by which it was to hang: -

brings the laugh without the blush. that = night she saw one of the up." exerted every sense to please, so = successfully that mr. tripp praised yet not dearer women, he added with a = ring in his voice that made=A1=A1sung;" and david set her a good example = by eating two bowls of hasty-pudding=A1=A1my old place till i know in = what character i am to fill the new. the the tin woodman began = to

would be useful and proper for us by and = by, and let us play with you three can try, and let this settle the = matter," said molly, handing be a goose, tommy." a suit of faded blue = clothes, and his head was merely a small sack=A1=A1one of the madame de = staels of the age, who looked daggers at another corinne,

departed in his rubber boots "to take a = walk," he said, though the that her friend did not agree in thinking her = silly because she preferred calling her "little girl," and dropped his = paternal ways as he had done "i really do not know" replied the man, with = a deep sigh.=A1=A1her.=A1=A1lose their mothers. besides, the best have to = get through the hobbledehoy

f: with the red dress the world would = be!" and mrs. jo's eyes grew absent, as if she was looking only seven of = the party were sitting on the knoll

------=_NextPart_001_0008_01C1924C.E446F5B0-- ------=_NextPart_000_0007_01C1924C.E446F5B0 Content-Type: image/gif; name="dT4w2SSmEj.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhtwFXAecAAAQCBP///////////4fKBP///wlNG////////////48Rmf///////xyDj/// /wTZicjElP///////8wCBNSahP///////2RCJMzGCFTUDt8H5////////////1OMIv///wd0Fv// /////////////9enSRSvGf///////////5RpOUymn5iyIv///////////////5Xswv////////// /////////49lpP///2b6Gf///1BlmP///////////////////8wEcP///////////////////3Qr w////6+VnLHQpidOof///////////////////////////////////////////////9xFfP////// /////////////4nPc////////////////wwqbP///6CSTCBaIqdKh////////////////////zyC tDziJI+na////////////////////3SF2gQWZP///xzCbP////////////////wCBP///////6zw lHwCTP////yCvLxQKEx+1FRGfHyWHP///7B0jP///7IPHP////////////////e9n/////////// //wCbP///////////////////zRtF////////0SK9CS2fAiS2EQCdP///////+6uXv///1EpvP// /////1xYJP///////////////////////////9OV3P///////////////////////////1SabP// /////////////////+xY+P///////6oyqP///////////zSUEIk3bMy5Nvz+/HEaBP///6x2/P// /3dT1NocKVS7of////////f2RP///6zVF////////1d2kf///////////////////7QiBBw6oHxW KZC2vP///wxbXJx+pP///////5S+4f///99aFP///////9zeNP///xQg3P///3f3Lzyap/waZNTc nDxeVDT6L3ya5P///5R6HIxabIge1P////////////////Q2XOxalCwAAAAAtwFXAQAI/gCRCRxI sKDBgwgTKlzIsKHDhxAjSnQIbqLFixgzatzIsaPHjx+VGCwBsqTJkwwrolxpEgLLlzBjypz5sQ7N mxnP4NzJs6fPn0CDSoQlU6fQo0gPBkvKFGm+lX2iSlWoQiHRpgj7bJQ6NWvXglwPRsVKtizHdsja mF3Ita3WtRbDZnQ7FqxbuwLrDtQLt+S/voBpgvKqt21ghcXs8p0oV27euo4Lv318uLLFd5V33PSm 0PBjvnT3fo3smW1Xx8jCLhZ7VzRqwm9JQx49WbLl2xIx4wYamnVv2a5LJ2xMu/fw1qmNw/5c+zRt 0ZRxetlNvXpEupM/B2eunXvy1Ypj/hdXbvA39uy+S8tuHh08sgvW48vv2ScY8vTciUt2v/1789n8 eeefeAGe159/BBE3X1NHLLgbedi59l1w5IUn4IQXCkRIguMdiB+CIIbIWoYO7tRgiXChth5yxp1X oHOg7YdeVR6ud5yM3r2GV3LRoejjjxqpCCOAHAoZIH7qDWlajADyZyOIOkLHY4/z3QPklRC5VGSE OX41oIUipseigZ155mKZTfbn5Y5Ttonlm3AiY4iYSXLJHHoDrikmhndGGZ6Mfm4pXIVS9nhknAgF gah8993JZ5gU4kmYiKodmmGjN+oJaYLi7GjpoqCGypRjBlgGXqCipqpqUMKVuuqr/rDGChKqsla3 zEye1Forrbr2ihAkucbXgK/EFlsITFrOJI9ECjw0bLHQLqgbS8lGK5GV1marbbaQZJTBtqLCA+6b V130rUHrbNQsR5+OC9EKJz3rblLtMpQuRuuyK+m8TGnCL1L1PjTdvmVaG/C/1g3S1MEOTScRw4tC vNIzCKOk8MIEU8oela/VqedYXoIs8pYko+kch5FCN6RtK/6HZ5S+eERxxXE6KZ5Aydhm6M0cF1re bCnrDLSbbA5NJcp5jsinzlLGeHTMNKuKVlz7Oo1MzoUaPaV7NiO9mNYcS2q11T8fXbabTKPNs9lR S021V0jzWGmkTZJ9dnvoRWXT/mp2xj0lONkBCnaea7fJpJmEto3iYCZxHTh7sRlO8JjHeZ23VnXw nbHPWndeuNphc1715ovOSdAbPj2wFuOzjh63fhub5jObW19utqVjPx460bmjrJndyOgWYGICBUuT M0Ch3pPqoHbNu+6vR5715LF/vXEff0kON4b77fx596Ajs4P108+uOEvJONi3jsB/SSGYgkIv+uEZ T4WjjIMMPnf4zAmP2g3CoQkLmnKv84FkQz6RWEcUaBJqGNAEBsQJLlpHH9JhBVtw6UYEyeIBkEyQ gjQJoEmWUhIMIkN5BGEdUEi4Qax0kCwF3KAKW2iSGNIQGQ68oQ53yMOflKKH/hEhABCHuBAWErEg QjyiEpHhhiWaRDNwAYAUpTgQALzEihvBYkKwqMWCdPEgX1zIF8PoRNxwJiKmiyJBuHhFjpBxjWKc WRa9WCIzNGQUC6FRts5IFuJNpItsFMgU10jFKhZSkIckJDK0OEg6JrKRjTRkFQUpSUpako6LnCQi uXjIKTIyk4/sZFnsqBCSMESPhzHiWqplEj/+EY6ZjGUsPynLQMrSkoWkZSVtaUtc+nKWvzQILy/Z S1BOMpfB06VJUMkvVVbMk7RUZjA1ectaEhOTwJxmNa2IimJa8Y3ZDCcyKLBNSg4zeNSEVafK+JSV kJGTkfSkIRkpT1iGc4ya/owmNn85xkRiUpeNLAM+jemFaNbTOvQoI0fa6U4wXpKaYSymPc8J0WuW E5befChG06lNNgJgOvpUqBPfaVFOlpSjIb3oPTUayJb+EmrCPGlHIepSjYp0hwAAREw3qUh6AjKR IllkPP1pTZ4i0ospFaVAYjZQoXbyqYq0ZiiliZUZ3tRXQTVLUw8yQIdQ9apgBcwSQAJIhTisIWVd yA3CylYgpbGtcI2rTJwpV4sgsK4KWRZei3XXusYASH/dq+IO0ZfAlkivyDCsYBe7JE1N7SH30UDs 2MaSrIrqRB7BI2MraD6HVO8tkp2spiAyVpFq9jDGOGLaIPtZlB3OIbda/uwijgIfiCThKM0IYW0O 5LK9zC5tRiLQ2qyXN6KVbBkKYuAJozZbpNTWIHRNSmkNctqPEAlKaeJe3pAbMp71QQN4K1+RlHY2 o4nMghtxVaw+WJncBia1Lzlv7SYENPu9rLW1A2/02Hcq1803vEoMFj42WzCtGPhmBq6dBxK8GFww bUwP/tyjOvtfoaH3hgMG4jE8gtlKpQl2kIpwc382XNEe+G6eKjFlCbxE+Eqouwd+XIyb1tpFDM28 scPDZMN3Y8gpl8U0BK6Jxduo4FoOZTreMdlI49oLA/nJcPqxSbAQFDlCma3NGUNS9HvlLrOEVwrJ oZetZVWNfAJhYh4z/rR+qOY2J6XMKCKlm7us5Tk7yB/EQqFMRsziciUlfUzBs6/0HB9wzvEnEhVK orcIzS1CxNBv6itBptURLrcQ0jFZNETkPBBWXkTTDkXro0XV1cMA+jYebSo8KwpHUa66qLOc6jGF ScVv/vSTRLX1rJ1KyFsj9ZtC7fVA/FVNc746nrc0KEUdIum2nbovzMtnL3GdT5S2dJgALapBEWLS lQZ7m9eWaTijjcuaLnKtyPDXO2u67Y1KlaN2Pgm5g4nPc0ozqcjAs0eNWeyU7hTfsBa3v21abXr/ GpIFHzi/tV3seIPExf8UCBbqLXBsUnTfwDaqU5HJbZcom+Mq5eVB/iPJ64iXm+QND2mj+/1UhGOa WFaG01tNjgxVZhzgrM62MTPuboE0CJz23mnILcptoRu84QRXudH5GdOX9yrmr1o20aXOcZ3DOqUn AnrFAy5UEHjb2/feOrwZTnZ3W93hNJH6Lfsw1Xp/UiUkV2bclQruq9O93l5/6Nx9jdRMQsAQPqV1 PduNbItrHOkFYaiDfvjYlSBvVV90MkJUYhKnS8TyGfl7WTCdr5nwGSWMh8njVYV5g1A605WPOlk+ j/aHpPkmJtysTouVvboycyZn9Um33iQNh1TXXfMAiVFWlQiP5L6Hvb8jv4L/keGrqvitj35PIJit 54rKsljys1CO/r8b6kt/I9hfohei+/3yr0XxC6I8WeAMZOOZnzqPxQN15P9+O9O//vi3iLjKz31d NX5enqYQ+8cU06U4/RcY8lIS/+cuAbgTbIYRBZh/ovJ7EliBFniBanYuq4JYGAgq6DcTGtgQ7tWB ZNGAJOgQL3SCulJqLZSCsNJEPOR9FehP3eZO8gRNKAcktVcdt5UQMKhVqlZ6CYEOoEKDR2WDlfRt CTF780Fl89GDA8GEEOFKN2GER7gRRLgoUJVpb0RUBiGFOySDKwEvBUGFaUdPC+F8CJFQsYKGSrhx a4QWLedT/bRuFkiGDAGGJ7GFSnhQR9VyvSaEBRGBQLhLAMVF/oMxVBNVh/2kgjFBgVfYSXZATGio iDQVJ7XmhvPUbXwoEMHgh4jUDj/liCaRgJAoSaE0iZvkhp24ipioa1cYbLlUg1KkWJnIba14E5YW bwnIELeYhL/4ba0YjDvRiywRjFs4i5E4isEGccDYReGXEbfXEaPXNpjVE8SojH1Ii8zohcighyhB iDbIjMJoUpZ4hKH0jAURjUxRjROxgwKhWIhyjT6BctoIVedYjogyd4FYiZq4ioxIjnACj8gAdRnh fiaBkIfxDQMRgfZIh6M4jKAYLd44ENBnEuR0UwoJEaZ0EAO4ECY4EeKoERUpKuv0SrFIAXzEEhkZ fR+JECGJ/o1JKHGqMpIPMZHu8mxuVk965oR7ZZA/8YEZoZNoR2g7YRPbMm9OFA+kCBccWB2niCVM WX5KOXll8ZTUYUMkeHpN2ZUdwZVduYteCS0dOZZmmRFlcJZquZbVcYBs+ZZmBZcXOHMbgQFdFnsd AVPvp5UHQZclsWFMMQE/4o4PgZccEVsDIZhlQX7Wwpc8wYIR0Q3OQAiEKRBiJpkQMQGamZiaqZgF 0ZmeiQygGROYiQylWZpgsRGSSZkMgZoN0ZmcuZkGMZqxGZoQUZUFIWgDcZqP55o/gpVX4gxZyJoK QZyvKZrIKZuyyZkCoZyKuZwxQZzGWRBpiRHCqSGVSRDT/rkQgtmdovmctumczQmeEoGbDyGd2QkR 97cWWYglhKBBu0mE0tANG4Kak2mao+ebzYmcsxme5Pmd41kQmOmaq5mfk+mOA+oMM1Oa94kMDXoQ 1TkR70kQ3ZCFCToQ94ma+pmcBwGdAPqh4kmhyEOgB7qbJUqh9WmgAtGgD3olQukjLeoM3dB7znCf 6IkMxrmd42mbAUoQIaqcEUiZG0Kc14mjj6ejRjqk8HmjRloSMbqkNnqkyJOjlQmb/fmZ/xmiAyGk TeqgwymlB1GjQwqmXYqkanYB8ImdauqgCNSgrNmiWOqfVwqi/4mhbYpAE8qmK9psetqnLHqnTtpX RAqo/n36pny6o1jaoVZKpwXxpxoCn45qEIO6p5TapyzxgEDkmgoAqQjEm5S6obHJnASRWj9ap2vK oEIqowKxocTpqfi5qumJEa4Zqa6aobG6qB7ao8sJmrbZqo93oJQJnxvaoK7qqiuBqT4BnChinPng pmTqq12KEN75oXNaqo2Kp7/abMRJac66pkz6EdNZmkwKrWa6n6bqo+dKrZU6qQWBpOP6rLEqFOg2 LtBaqZGapAnhnd0pp4zaryZaqbW6Iae3mn5KqHB6Eb34rZH6oCUAqhy6r4nar8ppEARLrL2ZrWFq qPZKqB6hrBbRefNSoCIKqyS7p7fqnKO5q4v6nbna/qntmaSj564j2p7FGq8OcZIUig4kWrIaWgKH iqgsC5sqC50ru6Uzq50nGq0jS6U8a7ObIRAgiyg4exMOm5gnoaoKkXwJcbB9Ua5WqxBA2RBcCxFe a34mIJYNUaFOixJl25pra5lBQbDIoLUSEbZp+7YIMbYMUQ8wYX0LgZSvIoYPgba3QZQe8XpHxLcx UWcDEXMxGSqC+330GEEG+bjxMbWOiKxyublApJcxwZCcuxBRaxHM13p0G7rWMQ7UgrpNabkE4bqs WxCcphGqaxLmKRHTCCSwG7sTMbsbEaG8Oy5+24EvuhE2eROT25Qr2UPFuyqaG7xPZpSXWha5Wx3s /nVTrCcTOShGESWIA+GWofKz1HG9GLi9CiFFp1eScPGDH/EAF9MrzwsUOPiGO6G+fUGMvmhFYKkq ySsQBIlXrua9Y3d5AtwQ7FcSyGhrsPiHmjh4Cxwfadq/FnG7PDSHGGG/MAG49bjAg9TBgXeP5oi/ u5GmZuGXb7KR+XtMD+yKsqjA8PTCLQyLyggA6gWHQMGGfYeOnMiKO8zAsQgrL3tVAfzAVXeLILyN CtzCPHXEM3FmByGP26jDyyjFG/eLGExDRnS6sjK/hSQN3SjFR5yMIUzF2hgTTuxV8ytUzVLGTEyD NQgkdgsSJKwQhNsrbjy3bdfDs3iDPOzD+ljF/gWMhD21Lmxca4box1esLaAwx9nCyDl8yDOpj2U8 xZLcw/TLFHfMxEq8jJqMJcdbV3f8hkWMyGNMxjJsyYnMueSrEHioLaHsxm0Mw1FcyVRswxEUxBgh vvHRygehKIBhmAwRx9ALVmU5zHBZzMZcK7rZZtdwgoxJE1BUEFPpZs3MVjgsfchMEyi8E1IIvkAx gjSzygxBwRABjkC0zTShld78E+A8ROQcEfu7G7isUPOczFdll40rFPUsKuhsz2j3yQtxxv480I44 r2XBowQNZd0gDnr7rw+Bq0W7o6FJmwdhuLJ6sSWrEUkkExOgywVhjBVICTFRpA2ttNz5sOdq/q3q qhB5txHfWhIiuxBV258dLdGKSrQRfRI163DTibUX+qkqOpv8GbGiqtL/Sp8DAQLAaqLb+dOvWrBX +6UL0bZWq68pnaXpyhIv7WYtip5jqqZMS9NxWq1Y3a73ibVECqUHwaXvuqYK4WJqWJwkXKEka58p 6tCfOdToGrFGXdfVGNP42dQjGtT3WhLLO0SzarCEqrHSmquOvbIUbadr2q2WShAL26b3UtIEEdcK 8aTY+dVNGtZjPadFXdZIC9pFutWfXabwytN/jbFPjapP3dj8Wtq62quwXaCUbdZNKxDrgNGBirQb u67Io7dF+9i33aOSXaicWqnXOtxQDWX//uvcrO2tGO210yqqRa0SWgqwZGrZfErZ7ErVE5HY3l2y tqoQEK2oyb3S9QqsPl2Z9brTSfGS83Kvl220P6uvjBqi4GDaTN2lFgur7xvgkcquB/Ta1n2qzvAA 6FCZdTatudre3V2osC3cBiHerf0TO2jf/CKj4Qrcdn2ynkmbQxuaXhDRjG2y7SmzptniuY23EaGw ij0QD56e/O2hKl3hFdupwM21Pb6ieVfYJzjTev0RzlDDE6HZMFGhOxvb+YndKCu0JQ7ZKn60+h2z 8o3lXWqsHeHIgsWUatsTRi7TMo4U99nOeW0STN7ZHq3TDsKO8zHNZeTkFlHHkXnmAqrn/m2mFubH vs+cKr47EYiZ0IfBvr4y6KDiuYAx3cMszBh4kT/hsU8G6YYOEXI+Lq0cuW/Jy3CsK0ruEJ5OuZce FIybFHSuQ/2cFLvbEY6Odqle6rIuUuLcVorrE/FsgRL8ELW+FgYNJBrME4hbfoUuK2oeEZzNlof9 I79OM8leLNk86wdxwMlMI9r3KsOeLZJ+ltZ+E9fsgmsxM9Us7YqDw5a+KgVO7iXRkrHyzj6R7otl DhOBCkDC7rAyb89uFtk+Lq+u7ogi7/7eVpgbEwDfQ7Ub8Akx8DQ0ujJx8B1xzQi/FiuHeB7RRQwf 0BQvTvZUdAuxnhFvu21UcAwBxaN2/miOdr5iBBfuDiQXTx1RiRKILhAmfME9t3fCNk9gxHM5SMR7 /Mgix2qBOGuy5nWBzC8tD1dpFXRHF3bCaG1Lb3Lspk27BkrmVvQfX4UjR3QiD/Rit3VblU0Ux/E3 J/JWDyrjjiWZ/iYiQVJVvIk4D5CGx3UA9/XmdngRZ2842YQncfbmx/YRBW/PonVHl3Nbf1EZhXT7 VnYccesyce0KAebWwehAsuscaRF+n3BKP3RyT/YsxXRgT3B2N/gZUfAw4fgmAe8aghvrjKFJEejH GGol94dvb/csHPtAn499SIkV1YhSxXcZDyqoPxDOWBLxqxGrDxTA2xfB7yOC//sQ/voq204TxS/T 1pH8EBGC7mL6sI9JS+G9Ebry89HvCPHyTe4TAA0Uw48MlJ4Rywwnrv8Q4A8k/Uz+ExHsZnH+P+GM 5rwR7X/1EmH/AIFM4ECCBQ0eRJhQ4UKGDR0+hBhR4kSKFS1exJhR40aOHT1+BBlS5EiSJU2eREmx 2UVIKVemhBlT5sxBMwW+tJlzIU6dDnn2BBpUKEN0Fbtd/Bkx2FCmTZ0+xdhH6lSqUk32MVhVK1aC VQt6TUgVGSGNWAwuhZpW7dq1W7WOnJrVLViBdOkevCtT3FNDbP0arPkX5Ny8GwsTFjvQbmK8hTd6 EhxZ8kFfkzkijvvxMGarisU6/kbm1rLMMaMPxhOqwvTEB3dBR6X64CvjurRDx90sevVuy4lk2s7s 2SrwzsKxEudqfGHr4Leb17ZtPLhW5snzXtc9OzvDt9qHZ/4cnfd4hb5nMl5cHP169dPZJw+LWW73 rroJS68ffStC8OIb04duP8Qkeoa8mQAx7T3r3GuPwQUbhJC7Ab0D8D7n9gtwQNmkK+6r/DqMb7u5 MgTwoQINRJEkBZULEL8WX7zwQfj4k8/F9DpbkcIRBdowRhBpfO4/HBUMr78gyRsnRYTogalIJ2fr 5Li3kJPSK9uOENLCGDN0Mcv5tNRxRiB//JIrqbyAsEOwXlstSSWBKtK5C7Xr/kRO3J6L884OsfTy QzMnJBHE3HYs0z8/FyplTTTTpJDLkU58M9KFRNNzRkq/E1RATMXs00ZAA2W00QvfEPPTTkMc0kFL E2NTUpsqc+gGqDR1jFbxbMVzKhMO5bVVUbf8ddAqyeTVUWBvXNVIYp+6JzI8KNuNvhJJ5DBLGTNt jrNUt5XRWGGLBTbcU5H1lso/j2TWVcGkrRVZTtk1109CY2SBNkCzc43cAJNRKN9sDRFRPzDVJRic ibyYSN9OHfMg3G853M65EgTGEOIuHcVOKn7HhO+6RDP+0VSCmSQ4IoQjohJV71T+sEx5p6XW2ncV BvVI0PwN+eGVfVWS5JJ//gZ6PJ6D1ggWom1i4WjJ1jRU6aJBWqIiWJVMGiOznP5or0KHxpqpT7oW zACstQ4T3dGuBjttncRWO8wU0W47btMUkHu8HuvGO6hF8gbqa4pkg9SgM/gGuy/Clfa7IsgQGvzw ow13nCI7Iqc8pHkqX23ykk/GvCI3OLo8shiA9uYpeTqfDICEPr9I9Z5cdz2i0UuCHSIAbsc9odgV Kh2Z3UNqB6LTL9oVdQN/n6n2p5R3CHmEnNfd+IcCyah4FGu/vaDYYc9eoO219/177pn/Pvzdc/fe d4NyV717791vH/n4B2r//fPdN1/77OenH//01w+f/QSYvvPRb4Dlw9rw/lBiveu9738PrN//EOhA 9QWwgupDYAQrWD7/GdCC5KPg77rHPQiW8IIiDKEJPag/761ggx70n/LEt0LpqeUCKQEhQSLIQRqe UIXYw+ADV8g8APrQiBM84hCFuEQdmhCJuENf7Fz4QgkCMIMErGHecpgPLCZxiTx0YhC3Bz8oMhGG MCyjEZV4wjTmr3/yc2IbzVg+tECRiAM03wgvmMW45RAZWNrhGb8oyCTWD457NGMVFdnEQS4SekxE oRcP4jwwHpKRdwwiH+XmxzVSEZF6VCMC+SRJTBIyh0+U4RrB+MkwNhJ8ilylIK+oyU2qkIbosx8K 4adD/G2Pbnh0oxod/pjBXQ6ymMDEZTD7F8oO2vGU4+vhEXtJS4PIqm/Lg8mzKvLI1rWNm9TUSeKE 8jvWQeWb28TIDXdzTnBmRIE/MxjhjNFOzL1TXUlIyezouU9+jiQIB/HZQe42lGLIpBT9RKhT/jme gsbkoCLZQUIlOlGNlIGiFxVIOTGaNmdgtCgYseZGlVYPonCkoyJdiBJ2glKWttSlmAveS/H2D5n2 BAI1xelLzUAQo+XUpzFp2E+FCs6ADhWc3/gLPpxW1Ml81KhBQSpFGgCTqCI0oiJxak+U+lSuoiRq RyOLS3sXEn9AJHBdlVRY0ZoQeCREA2stCAPhOhPIDaWtc8VrXvW6/teW7u0kgTHexhIS07aVpp8U MAgXM+JXuNZBIZrj61pCJxPHGrWyIrEoQ6omEH1WpLNgQ41QvkpZeip2LZmFyGcPsgzUhdZpA41s bOMGW6bgQra3xZttcauuUey2JPH0bXA/oomBjHYoVSVJS4z3UOHGpKHFddo6mnu0qU3XurvZKrSu i5C3GugYCZGrT7Pb3Oqm5awa+a5Cnrtd9jZFpZq0Z3vlhlr5NuUBgo1IfBliXML1tL4NKQHQ8AsR 6T6Ev/+V7UmBkl7pgeJnGWgbhBnCVARzBBV5k3DXMoyMsiaEwhXWyIVBPOLRNIvEJ0bIQhmi0Zay 2CPXQLFkXDyQ/hx4ZHG8ecdaYBzjjJi4JzXuyI192l22TDVvd/WIj6Gi34OYo6tE7gn1FiLOuiGZ x1fG8lzpS2CMkDTLNrGybAtsES9fd8yScjA/c/zUsSKEwSgx8pcvgtiCrDknUI7cTWEy2bUQ92hZ HYqTETJPhyD3I3iWc0X8XBHOgVPQDtFzoiXNEkj35A0U9W9PzjzpnFy6IBhop3I5fbjejjokaFmN NlMiaqzh09QUZbXTXP1qWs/VTfuM80UzXWsSM9khH07IrCNVXqc1mtdEG+Wxlb1d1TyV2C4Nb4mh 0uyhAnbZCwnqtfkabW13OyVXJXG2OVJmb/PTPDYBNuU2Xe6JFcAtI2plN4rdHe+6pbkg9qZ3REIa EAA7 ------=_NextPart_000_0007_01C1924C.E446F5B0-- From tdt@webasto.com Tue Jun 19 06:31:14 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0azS-00036R-Ug for megaco-archive@lists.ietf.org; Tue, 19 Jun 2007 06:31:14 -0400 Received: from [213.167.35.138] (helo=sofex138.cust.sitek.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0azN-0006e2-Su for megaco-archive@lists.ietf.org; Tue, 19 Jun 2007 06:31:14 -0400 Received: from [228.89.236.229] (helo=wrha) by sofex138.cust.sitek.net with smtp (Exim 4.66 (FreeBSD)) id 1I1%/-0006Mt-OI; Tue, 19 Jun 2007 14:33:45 +0400 Message-ID: <001d01c7b25d$05f56760$e5ec59e4@wrha> From: "Hilary" To: Subject: boxcar rehabilitate Date: Tue, 19 Jun 2007 14:31:40 +0400 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0019_01C7B27E.8CFB6EA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Score: 2.4 (++) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 ------=_NextPart_000_0019_01C7B27E.8CFB6EA0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_001A_01C7B27E.8CFE54D0" ------=_NextPart_001_001A_01C7B27E.8CFE54D0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable FIRE WEATHER WATCH IN EFFECT FROM TUESDAY AFTERNOON THROUGH WEDNESDAY = EVENING FOR LOW RELATIVE HUMIDITY FOR THE MATANUSKA VALLEY. A DENSE FOG = ADVISORY MEANS VISIBILITIES WILL FREQUENTLY BE REDUCED TO LESS THAN ONE = QUARTER MILE. FIRE WEATHER WATCH IN EFFECT FROM TUESDAY AFTERNOON = THROUGH WEDNESDAY EVENING FOR LOW RELATIVE HUMIDITY FOR THE MATANUSKA = VALLEY. This file is usually updated about every two minutes. VERY DRY AIR MOVING INTO SOUTH CENTRAL ALASKA. AND THROUGH THEM TO THE PUBLIC. CONDITIONS ARE NOT EXPECTED TO IMPROVE THROUGH THE LATE NIGHT OR EARLY = MORNING HOURS. FIRE WEATHER WATCH IN EFFECT FROM TUESDAY AFTERNOON THROUGH WEDNESDAY = EVENING FOR LOW RELATIVE HUMIDITY FOR THE MATANUSKA VALLEY. IT IS DIRECTED TOWARD FIRE AGENCIES. FIRE WEATHER WATCH IN EFFECT FROM = TUESDAY AFTERNOON THROUGH WEDNESDAY EVENING FOR LOW RELATIVE HUMIDITY = FOR THE SUSITNA VALLEY. THROUGH EARLY MORNING. THROUGH EARLY MORNING. FIRE WEATHER WATCH IN EFFECT FROM TUESDAY AFTERNOON THROUGH WEDNESDAY = EVENING FOR LOW RELATIVE HUMIDITY FOR THE INLAND AREAS OF THE WESTERN = KENAI PENINSULA. This same information is available in other file formats including the = XML based RSS and CAP formats. THE NATIONAL WEATHER SERVICE IN ANCHORAGE HAS ISSUED A FIRE WEATHER = WATCH FOR LOW RELATIVE HUMIDITY. FIRE WEATHER WATCH IN EFFECT FROM TUESDAY AFTERNOON THROUGH WEDNESDAY = EVENING FOR LOW RELATIVE HUMIDITY FOR THE COPPER RIVER BASIN. FIRE WEATHER WATCH IN EFFECT FROM TUESDAY AFTERNOON THROUGH WEDNESDAY = EVENING FOR LOW RELATIVE HUMIDITY FOR THE MATANUSKA VALLEY. THE NATIONAL = WEATHER SERVICE IN ANCHORAGE HAS ISSUED A FIRE WEATHER WATCH FOR LOW = RELATIVE HUMIDITY. IT IS DIRECTED TOWARD FIRE AGENCIES. AND LEAVE PLENTY OF DISTANCE AHEAD = OF YOU. HUMIDITIES WILL RECOVER SOME AT NIGHT. AND LEAVE PLENTY OF = DISTANCE AHEAD OF YOU. VERY DRY AIR MOVING INTO SOUTH CENTRAL ALASKA. CLOUDY SKIES WITH ISOLATED AREAS OF LIGHT RAIN DIMINISHING THROUGH THE = EARLY MORNING HOURS. THROUGH EARLY MORNING. VERY DRY AIR MOVING INTO = SOUTH CENTRAL ALASKA. FIRE WEATHER WATCH IN EFFECT FROM TUESDAY AFTERNOON THROUGH WEDNESDAY = EVENING FOR LOW RELATIVE HUMIDITY FOR THE MATANUSKA VALLEY. RELATIVE = HUMIDITIES WILL RECOVER SOME AT NIGHT. VISIBILITIES OF ONE QUARTER MILE = OR LESS ARE EXPECTED TO CONTINUE AT THOMPSON PASS THROUGH TONIGHT. A DENSE FOG ADVISORY MEANS VISIBILITIES WILL FREQUENTLY BE REDUCED TO = LESS THAN ONE QUARTER MILE. ------=_NextPart_001_001A_01C7B27E.8CFE54D0 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

FIRE WEATHER WATCH IN EFFECT FROM = TUESDAY AFTERNOON=20 THROUGH WEDNESDAY EVENING FOR LOW RELATIVE HUMIDITY FOR THE MATANUSKA = VALLEY. A=20 DENSE FOG ADVISORY MEANS VISIBILITIES WILL FREQUENTLY BE REDUCED TO LESS = THAN ONE=20 QUARTER MILE. FIRE WEATHER WATCH IN EFFECT FROM TUESDAY AFTERNOON = THROUGH WEDNESDAY=20 EVENING FOR LOW RELATIVE HUMIDITY FOR THE MATANUSKA VALLEY. This file is = usually=20 updated about every two minutes.

VERY DRY AIR MOVING INTO SOUTH = CENTRAL=20 ALASKA.

AND THROUGH THEM TO THE = PUBLIC.

CONDITIONS ARE NOT EXPECTED TO IMPROVE = THROUGH THE=20 LATE NIGHT OR EARLY MORNING HOURS.

FIRE WEATHER WATCH IN EFFECT FROM = TUESDAY AFTERNOON=20 THROUGH WEDNESDAY EVENING FOR LOW RELATIVE HUMIDITY FOR THE MATANUSKA=20 VALLEY.

IT IS DIRECTED TOWARD FIRE AGENCIES. = FIRE WEATHER=20 WATCH IN EFFECT FROM TUESDAY AFTERNOON THROUGH WEDNESDAY EVENING FOR LOW = RELATIVE=20 HUMIDITY FOR THE SUSITNA VALLEY.

THROUGH EARLY MORNING.

FIRE WEATHER WATCH IN EFFECT FROM = TUESDAY AFTERNOON=20 THROUGH WEDNESDAY EVENING FOR LOW RELATIVE HUMIDITY FOR THE INLAND AREAS = OF THE=20 WESTERN KENAI PENINSULA.

This same information is available in = other file=20 formats including the XML based RSS and CAP formats.

THE NATIONAL WEATHER SERVICE IN = ANCHORAGE HAS=20 ISSUED A FIRE WEATHER WATCH FOR LOW RELATIVE HUMIDITY.

FIRE WEATHER WATCH IN EFFECT FROM = TUESDAY AFTERNOON=20 THROUGH WEDNESDAY EVENING FOR LOW RELATIVE HUMIDITY FOR THE COPPER = RIVER=20 BASIN.

FIRE WEATHER WATCH IN EFFECT FROM = TUESDAY AFTERNOON=20 THROUGH WEDNESDAY EVENING FOR LOW RELATIVE HUMIDITY FOR THE MATANUSKA = VALLEY. THE=20 NATIONAL WEATHER SERVICE IN ANCHORAGE HAS ISSUED A FIRE WEATHER WATCH = FOR LOW=20 RELATIVE HUMIDITY.

IT IS DIRECTED TOWARD FIRE AGENCIES. = AND LEAVE=20 PLENTY OF DISTANCE AHEAD OF YOU. HUMIDITIES WILL RECOVER SOME AT NIGHT. = AND LEAVE=20 PLENTY OF DISTANCE AHEAD OF YOU. VERY DRY AIR MOVING INTO SOUTH = CENTRAL=20 ALASKA.

CLOUDY SKIES WITH ISOLATED AREAS OF = LIGHT RAIN=20 DIMINISHING THROUGH THE EARLY MORNING HOURS. THROUGH EARLY MORNING. VERY = DRY AIR=20 MOVING INTO SOUTH CENTRAL ALASKA.

FIRE WEATHER WATCH IN EFFECT FROM = TUESDAY AFTERNOON=20 THROUGH WEDNESDAY EVENING FOR LOW RELATIVE HUMIDITY FOR THE MATANUSKA = VALLEY.=20 RELATIVE HUMIDITIES WILL RECOVER SOME AT NIGHT. VISIBILITIES OF ONE = QUARTER MILE OR=20 LESS ARE EXPECTED TO CONTINUE AT THOMPSON PASS THROUGH = TONIGHT.

A DENSE FOG ADVISORY MEANS VISIBILITIES = WILL=20 FREQUENTLY BE REDUCED TO LESS THAN ONE QUARTER = MILE.

------=_NextPart_001_001A_01C7B27E.8CFE54D0-- ------=_NextPart_000_0019_01C7B27E.8CFB6EA0 Content-Type: image/gif; name="amongst.gif" Content-Transfer-Encoding: base64 Content-ID: <001801c7b25d$05e6e870$e5ec59e4@wrha> R0lGODlhYQLQAPMAAP///1AlNVNLVzp4V0JFNV8cOXZqY1AaHWEwTCRoE2IQR2EXLUY5ClUqRlYG JkIVIiwAAAAAYQLQAAAE/xDISau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqP yKRyyWw6n9CodEqtWq/YrHbL7Xq/4LB4TC6bz+i0es1uu9/wuHxOr+MO9rx+T2FQBB0PfBoMD4JC foOKZgQCBgmJCwUEkAUUDQEHDAkEBlkMDAGYE50EDJqJAAGUEgGeGw2jFgYGgBUJXgmQm7YckIdB qYvDXwwEjQKQAA8Oq5UToZmbuH0hDQoKsTwFBaDREroCpprQAAQSwBnashMHrrUV5zHU5TTTxscf wj/yxP5cAeItq5BqX4UD5D4QuJaNx74GEgxOgBRQmQZsE9gBSPUKgC4ElP96FWogoBcAWwkMddiH h0ZACvR+kbzQTwKlUJZwmPzH08pOT/TAtcsgwE9ChT6CgpKAh9dOXKs41AQAsd5JaAkMIAhA7cGm ByR7EUBggJLKDUc3RtQVykXHVhIaeE05s8LbB5Mo5lQlTeKtQgcQ9NFFQIGFdD0TSykZIN2AlIYU vARQANVkj73S+spIYTKogLQmeOKaD13YyxsqT+iboKQFv7cqVLVJVOAfCmMnIL4gbQIghPcmI061 MNtsDLQaMHAk2JxsC83RHYQWoK+EosBX33wQuJU3TsdVKR4/paRcarV+pTugAFU1Ci09pDK8Ghqo B2RfMS/ACdDXAOatFB//XxQMQBBUG2xSnDaqgFXUBTs1EsB/MFW4QUAJGbhPQRW8pOA1DGKQHwKu gSPhVxbUVAheXPnlRwIDGHBKQixJEB1tl5CnoxSY+CGPRVZN9558nBXpnFoA6GfSOajtxNtUFgRF zi6EfNgQVdVFlWI8x0wIpHggJIKQRyeNAwo98rRky0MatFTWJccQ4OVrMK1YgJaqfJYJkkN5BMox KV0nwIRL7WgoFEEN1M+XibajCSdv6kNKjnAhWdVU5wy6SVsb4MWBMIn4ARufEtAXVwYcUaVBeJ86 6mNZpxQK5iGvfLdQgtD04+Rht13AwJ16AvBoKVh9xooEtRDK5qHMFoGY/3+4pbJXh9Lo8hYHswU1 20tpRlRBc3I+8Ashu1EmZJLynLnqc0ZGaYxrWlEiZwW7ajDtno3WQ0181d6Kah/y0AISJ/Qylogj ppxFpn1MTROpXwMKW4GpzVb8AyYU5YNaPw84g5O3FmYQlEgUmHopyF9COyRNkHUsTwDdBCtUn7Xh RikGkOjqJaYhoBbQmeIIAxUrh0SowVSpGJzoKl1OQKJZpOi1VJNMPQpkIQAKgMC0AFBs8dc7NIBK 0Xbp9oACN3lI0AbbHdBLN7rEQl9VhyRyEzKA7Cz2qGW1bCrM3sDAqg37eLgJPBMpc9N1BlwDtwZP uZC2WtGgQg9wuvTBnf8jYHfORcSjxpVwBTHjUlV48gCScy/nNZJHoqEvrKrTWjXA9RCVx+757ofW y/vvwAfvhO/CF2/88T2ghvzyzDfv/PPQRy/99NRXb/312Gev/fbcd+/99+CHL/745Jdv/vnop6/+ +uy37/778Mcv//z012///fjnr//+/Pfv//+dMkQBbiSGkpQESgBMYE9i0Ri8EJAHXuHFC7JWIgVa sCc7uZ0O7gM0GBDvgiDcw07KlYN94MITmKOAIVYIAhJawIATCqEM2bAcrb1wUHWJSJeUl4INAWAA QXNPnlaoMA4YDR8v2QoMIzbDJo6hhiE6G4lEYYtkQEIA7KhKbzLSsRD/ZQA1eCBYPfbhQugUjC1Y vEpnnMjGM9TCFoh5yU62dZqE9Kc6XrwA15oipJR8pYipKZjNeNjGQnoBMa8godFWM5uWIGZwN/MW 6CJiiD9+4FlrI6QhN5kFRJ4KQmsTDaUKcUdNzqwcEbMFEy/ZodgU7jD54qQskUBErwTsW5WaSCTt M5d5HW1t+1AlFivpAa000GkCuY+DWFWIWTqTCbUUjTEN4YDrUPGAKrzAKu1FGtvxMWTmAWQGBNYY UfZKmTyU1TPX6QRypgOHFZTOC6XhlQ7cCTw38NoH2cnPMvhlUJrYZj8HStCCGvSgCEWoesqY0IYe bxotQwd3GBAah1o0/3iIOcQKNcG5rVCzACbZ50VHOgjUaJReSfKoIaITFpK6lCeDAuRwkoScgMTz pTjlAyaIKdFoIjCHN82pUPPA0xWxcCOdQNxAejXUpsrBpDNTmC0rulTdOPWqcEjUIehxlnI1EEBa wapYaciJxtQlHSopl0rBOta2pkFB1bFqNst1LZG69a5gQI0faqmSa5kSr4A9A18FQUCGBvawiE2s YhfL2Decgjv0gKsoINnYwK4Sjz8oBC8oGw/1HIAaO8OsPEdbWbE+Ni3g6Vgg3tERQ4B1UBngWpo0 i08OeE1NGDimRwxbWpLe5AATjQu//rpC1sbFtQaMbWzANCkjwmerVP/RRD8gAt3eipU+YsJRfTTg STWupJXePaUHrgaez74MtvW0LlZhm6ildUqFtvDETsuYqFeU9z4giGE7QFWfcqpXrJpSSigDAQxa TNOFU6nKhzQDiw+ihrP/xSlAL3euDQRKmtnEwAhzGQLVbsAk5YRwhEn6m0TEcSWh02QGrzMCccru lG2h4oiHeggttmIyrrNwLJn6wlD+FQNElPFGElCd4DIFLj+eMUKJ2AASraYARmZkBcR1ge7SZLka 5ABfZ7MJmAHDX6LgrZIPWtypePk1ZJzLuJaBXKpa4AB4EweH57GyMeNUzA3rUCXZYraOfRDOybWz oAdN6EIb+tCITrT/ohfN6EY7+tGQjrSkJ03pSlv60pjOtKY3zelOe/rToA61qEdN6lKburGNQOCp gRe7TVxAxGzYMQkgRYQke9DWXLjS735RIgUhbAIOyMvHBowGWefZArA2wYqkgGcQGPsG4iqESPoD KwkEO21Zhg94feMkhrzQFDeEAkZ+h7FQaExBT5Oox3zGYCKcA90qdJlSKocB3VnAOAzsA5y/NAKo ySDbJYBwYakTM2IL6x7lyNoDn2SK2C2kRVraWbrZvO5W1RkDxbEA01JkVxGIqjoDmm1QfgEgGKg6 D0gLL02r6isM6e4XbsNWg+Q8kXeRzCon4kRz/HasmNHbI7UwygYa/+c1EMViNg0XB7/pZMtd5Qtw 6hwBq4yebEfEMF2arclUDoFtdYIKcxaBuSNE3JighW5fpKVd2jvwIHAohTsYgKRd71sCn4NcNNh5 VCva9pQEJFtkxIDdiwGw8wwcpd2ySVh3BFO6SzBQFKm7W4mO45mgyMNAa5TYGoEmI4HaKKz3RvZy v7gpBVkA8wQ5QGUK1ZTWXEubZEGA7UxEdSOWpHFUDrC6TFRzCexR2+bUJVVq8npccRcXxFsUm+/E dhkd3PLNvEAsN8bv1mlKl40Ro+Hv9YeOhKrCG3F1Rh7/h7uJxvqKkJeKWtO666iHdODnAB605k3x U+U4VdlJfG2Wdv/01Fv1lqF516E7u8IqkBdoR3MZjVJ8PmY5QNQpgUF/INMuGEcBIHEkQUIPvcAi kKB6mScBqAcyqLFwsoEJkCcVnKBqVOZ+dvJjyCcxBuEiuUUvxxJ8ubRZ4nJypMJcL9YSWuUrE4Bv JigoSmcMjDMwOjgHOQhb4ZdavvEI0Rcks1MlDQA1rjAkXkM277EkwidXkLQLwOIH4cGA28Z/U1Yd CFiBFzc4LfIrLyEKZtgm4CdiiaI6OScM9ZRDAtSGHzh43wd86nB0cpFkS/hq3UcBAOctxMJEqrZN g6N/KBUR/AV4KyMRJqRNFGhjIbNy/1BWC6N9GOguYRg6pecMApj/S+GhicJnEhzSKz/Ig1KYhEcW JUH4Sb5hfFI4eMvQDDeRE5eoZfBXMlJRNqFlf3AhYP8ihT6IhxtAMRqhARUxFaDIK2iBIwZBSFn2 iJHYhe71RSoCiHWGQHtRHPg2Z9uYfiiVCtq3Y71IKLioCueAGKaSYHMmDzUxGRuzFo0AhdYmbL44 GIHgK+AxN7FgAGh4IUJDJ1NWJxPYkJSYic7lG5nyYfoFDisSbBMwig1jLeA2ZMZibAwhiB/GYn74 XhcyM1DiF5CkjXHIJ8GkAddWCZfBQ5bzGYZIe9jAIGSocnwQOcchRrDBNaEDdm2RKNGRKFVhTAa0 JqnWCdwyeuh2/xfCJom5cyHb8RqZM36xxwEGuWAaFyUrlBe+F39XdmRaww3TYHuSZw5dOY0kiRsR FRFQt18SdGRskWQhOYUYJw5OCSo+tIkzyGPB0WMX4DVvqUN8aZAUqIOCMJV9CB9W04Xe5RcExIXI MghxciKhiCQSR3MsZy5ooXc+so3LchJKxIpxwpMnEICetxEeIzl5Mo1wZUIs1C2PmVtXaZoK0A0e cEC4YI8BZgOtmQKZuRPK05my+Isb+SXcQSI3wgkFoGtakzUAk5rNlYsZRpwWmJHTQAB7MUDTGU/4 UBp80JT2tZAnkX1j0VpkyQEjuAiMyQtJ9kodYIpYYG8oUIC8kf+DJGhwugMYZDEYGVcqtQAWHfCK OLMClzEgpVMTDqAABfoaOXZosvgPO/k7Hfcp1TE6o4afkGYs4bNmHeKhFkNK9lSDswZ3XVCFz1Yx C1AGz+AFFYocHdkhich2iuENxghkeEICizMPM5og3jAgQVMn9omIc1IxzUYEBnEMTlJxXUCiWwID w7kHsyFmN3qgMrCjIwB1oNASh9OR9oeiWLSb+Okk/ekDGQoDS6oD5fJZehYLN6IwnLIFxhZGczEL KbJ0mmV/YFdzzfkWtfCjbbA6+She3DVeJzEjtkE6/KFUjakANkQ4a5Nei3qKGNgdIvCkR5CmMSCn QCGkmiUfgar/bBJyHAsxIK2REdExU1dwTUdSE0jnJbuHTKTDFQTBQeI3I2lpDjAXHTZHqCcBTx3Q JVw6BB1DIiF1N76EqKSiPGLmFIy6Xd+iHMhASckaVB2SRq7kiRbWB6KCUhEjHCJwTZ4ZpOLRZAYQ gisAoJMaXsBgCy2liAdJCrS6GnhEFux6EDqaXpFjE7+6JteBohiXM3LiIb9ZZ9kyelRQEg7SaxTQ ERO6g5CkVwbXkI2CGBwjqQLgIL6QcxZmJw0JKjDifDUnCkGhFXkKDSvEsbfYKyoLimilkJ8yiQ55 Aa9Qo6rZGVd4IL30d+3hkBoyYEaxlUb0sCRTHaDnHX50XJOl/1T1RkkbYjmAGhgdgYxd47DzuguD 0rN3hCKh2AA7mYWImgrvuQyHg0VJKLBgAi7ZmUvGeQXTUiJBgWMGh41liBuwkhbQagiu16p5a3Ea BoUCFIqpgDnE0oQgKiwAskJogktEaEWr4bA1oS202AERU7m80bF+ayPBeJIj2pKo0oq6dC1oAhiN 6wHKkzOYUEG65yPH4WA6OibIYibGaBDpUBMD9LLJkHmIQQ1GSQihZH+nYB+rABhmY6tEoTpqiKiT sWJWgEnhtS0MC4tylZECWQrFm4tEBCMbGBlOZkQT0jTqsJAzKYWvMK5pBwwDc1TcVhJZeZgNCSV2 tQ9vgbvuQP9E8stbrCKN9Ym1ijhgcXW9I3kLIxO1SOmeqfBlxAat20nAcsQummKsDslZgjeBlasn UfhOtte7XxmLFNimzgJelpkkC3qOb7uDexUtIWNi3CVAAcpdZDG+xBMLjmAR6eAZUesrfGWBC+G+ h7p2CkiYNbuJMRhv2rV2ZdmShgVIXCMI8XsUZOQBD7RhiJkJuPBI7jkkHBkrt5kOdwFK/DfD76I2 +PpLQ1JPWXFxBNyb2FQ21KpdIRKFVHAZ3MqKTtO1AaJD5DuwkHGyPicsEdQaJnGXL9HDFOiplPdB cqp0LEe6KLwaj+W+W+cbrZuGrILHjNRk+zSkETSA2SHJwHX/VN34jnN2drsBM9AApoSckCmsXJUy R9aUNaNAn8LrK9I6IIdLWvcoxvVASN4QJ6a0brxpVSwxmG3cm2UCudfBZbLKyeiKBPM1QErim4lg U/UqtRNLFv5mkYDDskvRd3iov5Y8zWwDTwMcmJOSDpEVSv+qScZQC/kmGqfZqNy2N1GIR03WKt4Q r3k3ommVdhBWhL3MxnDZsi8TyFghztVBx9xFzc2xSLELEbb8kOiJM9FgYkRkhLb4mNSAzpfBQTsb hJOjOQZhNcz4AfpBkmVMEnKEz8i2z1kwX12TEcn10U+ARTtVrF1LeEcziJzsJ3tIDavXz+AQI7wq l3IBSBzF/60lAEM7+AFZ+gLWHLGBe0YiyxSqcaAU8Xe7aDI+5gr1HMRfVG+DvK8UEW8qER8seZ1d u7Qt4KHNxrEPa5ES0rPDimuMIAcPB4cWqRKTUdRCA0Q6GwrLpgRV6g+oQQ9oKBhrir1mrXfEAFI4 pBgtWj9SSmieumqc3QbhC5cGMa+4Ec3NspSkfTxMGD56vQa7S4ONks0TcdqXlNlnQEGPbSgkpGox zKYinATq2s0pYFisstl7oGqrHdy9HQMkwq7kqQNeXTGxRNsocGHTHb8kcNuOt9zUPd1cScRtwEJ8 62I7Gx74ld2Qqgq1BQTX3DgdAKomwXwXCwPHvZoqMFFulv9frRBPc5HasLB6pNLKGwhRwLBRFBVv 1YQDpuPfgQBRJoDdcayLJSBrFEVOtUisalBLR+FRGrbhnZEWQD2vQ+0vHxZUgkDOGiAYsCqJyBUd AEXH8Sq4MwCJytTGiZBaSWaYJmIAkpphf8xmE8U5kGNAXAUgCPAAJaIJP/ux1yBETdgJO94g4hK/ RBTeWizkJiDarTCQiLdtz3ZgvmGuJBAe791N4PrJ7xsQZcRRAqMbCjBFObQL4q0FJ/WZhFQvNNmS a5K77f3ZgGriGACeaNgLQCKvjBFQRgKsRWQ7ysIlQY0ClWlFh70TeDAsQzisInoMii4Mw7IQrRrl 4yK9X7T/lENeJGStzjyoxcmsxGkX6PCrG9QpYo2ekecbkbITTYyTLGcxRdTZbyYY63uI6fYBGHbD yTEF4xKVefD7fmDgwp9p50DGG4BZFYkSpA9k3Qx1NkwVFHOOc9JHx8XhjljBCW3u4LX4ByZRNL0A W1Nsw4Tre5guGSlMMXTq4+6rzKRVNNIAXM924KWiOVZT0NR4k6Jhx9hq5B3rAeEhjzj6GrY+xTY4 Av3RReGIAT74Bz+2GyemcsnNBF2RdgwISat07uxyLVOtlw557du2K9cy6YVIsxSYdsRtki9rFSze MPruOhZ7nRMfx11h60RxyTdXMPnexHgB7PYBXIbNY688//Oe64oP3N4X3dE0QeyJirZJtRMxnwH4 Hg9GNQncOaRztk+7IeaRK6xd0PGfyYAMKBGavF0D5wFQklGgq7y7QkAUTUoIBCUIhBBywtEnkPFd iB8EEl33QTD6vNtj6fKk4iQO/+ext+sQftxhmXI1w3IDDseQ/bI1gWelnoTGEAB87hELpRvx7GYl v8PmcBllQQBhGRdmGjibKfbNdS3NYdsEywU1Plr2LZUQuqxUgiyBruLyKfV4hrtRfwFbYdXym3ZB r6f2DDDBWQJeLr+bz4l2DhbquvQV7SS64PNVBl86j6/mUaU8B67B/C3hBBMmrgkG1sZVdBMODY3P X6EZK//g236Z1xshzyYMqU2C8wYBABApA6pZP/6ONLRCEjTzRFN1ZVvz2SruYEr5cQqbFIiEqQQE DWGFwXgwEkENkJUgBBiUSkOzVBkQAU6ueuIIiTvnCSP6SspqE9dl0LpJmh0gXBHkpU5s5SyBkbCS oDlSohI8SUjoWOnSEQjAQxnLaxn44SgYqSg8MmmwvOLI8KgJAdSQBMjzWVM5JJrM4Fx5BViVYATs oKl7rGNFTMmVQGxAEMAsK2hwLqBRg5KKammcK+UJCA128f4GDxcfJ0+ZilwL7kMJ2SJlCdPKKJbZ RkAFLFBQGAQ4oiEQyYRAcn+wyaCj54M/KA0ebMuA5IH/vgyFomUYNq4Dhm7lQKDx6I2ejTw9fliL 5ZEeKy4PFvXp4OHFuwyiVKjLgMyAgHX7nAFY6C+gpHUhAezc1tHoUqZNnT5NoVRcR4fb+uVT0MRU UR5QwcUKFJGmV7KUBBjIFLbsCiElF63VkJFESwBc4d7Fm1fvXr4obvUFHFhwOW4nB+O6cljxYsaN HeNV+1jy5LxS+RoI0NYmZc6dPX8GHTpcSR+8GmAuduQBgaFxWxyAgs5u46uHtTzYLFr3bt6AI/em rNmkPy6hMndSfS7DvQHwYLOWAtcyi9rArV/Hnh2M19/iFgTAZwSJ52AUXv2RCnGni79epzvSHl9+ fKJR/4q5XNSeXAEhW5ggUcIc7ozaZKUALuIsPFbqomMWUHLJDYWgpGOrIg2qmy9DDclr4Dk5WnrJ ich2cOih6QrUYy4aaOgjs1AYZEGJIWA0J6buBkqqm1o0mJCFA5BRQC4XsLhmhZKK4emHAqtQCKMG 4ckpG5VKAqCfJBmopQ56hNywSy8XgyLKBTMgMoajhugAQxRsSOCXuTgIRUEwWCSgw3kieSetsaJC LbeVLPBmBjHMc62KzAhSQs8W4jyOFZMYKCYAHwjS5cIW1himtiTy24CDe254gFE8Hl2lDpy+RDXV wV6hYpuWArQjlViPMhOFHwLg74xXnBimCFucDMJFuv/YGCeY9rhUxNKi+pgiM1elQcibSCSxobSa /IIiij39IhNYCzhItAwbT0tkVG4Rq6Ao/VRlt92nenSCCzSTIDaQQMCDQ5aoXDlAgXubqHSeGLtN t9bZUAj1LP8INuFgEzIqIYA+DgiqRxvUulHg5cacYB2DxIpNjhXWmTCdxGRlgtZreWgFi6yMcDdm meHqcRUuy5z1KDjiiKoiToJZKLKMK+BXJiOmsapgF1oSQh5vAXYhmFVqmVA2+1B24eMQirEWXRNe +dOEHdWK1BlwYbKxAgVX2YKbHgjBo7Z1Z6a77l+BRfqnShmBwV4NPq6pZQYW2pJYQYYWxJXIpMg7 2pz/UTDorCdB8ebjQBCwwjBjojhkFTVTiCOMEsqroIDvhrB2pBYMUqtXq4q0I22VefnIXH8OMN3X lO3mvXcVlk23zodkeOuaeHa+iUondpyAEAAbYgGBIH+oOgUOXlohdBMn556tAmQHAIOM2gs7C3cC UZAMFBEI5NQVrhp8qx2QLQr9nd0hASluxBtBdd//ByA5wrKG4zllRTBAFpMawK/gdWgKnXKY2tDk tUNtBkXvkcAmYBeK2tDJToACTvw+wCz7QCRdegrLzkJgpRSRhBYBhGEMN0SPNTQENk/pUx2w9D0M rgBwQEnJl5BGj/xsS1pXYp4MlbjE3TwkGYxjogxb5xZFKlbxMw8xjhW1uEUudtGLXwRjGMU4RjKW 0YxnRGMa1bhGNrbRjW+EYxzlOEc61tGOd8RjHvW4Rz720Y9/BGQgBTlIQhbSkIdEZCIVuUhGNtKR j4RkJCU5SUpW0pKXxGQmNblJTnbSk58EZShFOUpSltKUp0RlKlW5Sla20pWvhGUsZTlLWtbSlrfE ZS51uUte9tKXvwRmMIU5TGIW05jHRGYylblMZjbTmc+EZjSlOU1qVtOa18RmNrW5TW5205vfBGc4 xTlOcpbTnOdEZzrVuU52ttOd74RnPOU5T3rW0573xGMEAAA7 bT�^% --%^V9^%-- From grb@iup.edu Tue Jun 19 12:37:40 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gi4-0005Np-5s for megaco-archive@lists.ietf.org; Tue, 19 Jun 2007 12:37:40 -0400 Received: from [210.108.75.170] (helo=ibdj) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0gi2-0005Mn-EG for megaco-archive@lists.ietf.org; Tue, 19 Jun 2007 12:37:40 -0400 Received: from pwl ([87.206.77.33]) by ibdj with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 01:22:37 +0900 Message-ID: <467802CD.1070603@iup.edu> Date: Wed, 20 Jun 2007 01:22:37 +0900 From: Pen Zamora User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: megaco-archive@lists.ietf.org Subject: respectable enjoy Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.3 (++++) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 SREA Jumps 25% After News Releases! Score One Inc. SREA $0.25 UP 25% SREA announced its plan to develop a $75 Million project duplicates a successful plan in 2006 than returned over $100 million in profits. Investors are getting in fast. Read the news and get all over SREA Tuesday! I know both the Debian BTS and Bugzilla and although they are quite different they both are reasonable tools for their purpose. Picking up the ball at the edge of the area he turned superbly and sent an unstoppable shot past De Vries and into the far corner. Yup, netlink is clearly overkill. Expanding the frontiers of a footwear business Home :: Web Directory :: Leather News :: Free RSS news :: Free Newsletter :: Tell a Friend Clientfinder. Thanks for explaining your position. Any suggestions on how to proceed? But it has to be their decision, IMHO it's wrong to force them. I tried to test that new fancy FS, and couldn't boot because of yet-another ACPI crap. But it has to be their decision, IMHO it's wrong to force them. Business- en technische issues bij virtualisatieprojecten Hoe verlaag je de IT beheerskosten door virtualisatie ? An application form can be downloaded here - please send in completed applications and payment as early as possible to avoid disappointment! I'd definitely recommend not obfuscating this simple functionality here. Hibernian Interactive is the on-line subscription service of Hibernian Football Club, providing video highlights of every Hibernian game plus live audio and video coverage throughout the season. Something like having a seperate config option and a routine to mark kernel text as read execute only. Alastair is an experienced and highly qualified coach who has been working within the Hibernian youth structure for several years. It succeeded a few times after a lot of running. To my experience I would add enthusiasm, energy and organisational skills as my major strengths. But quite frankly, anybody who aims for "perfect" without taking reality into account is just not realistic. But it has to be their decision, IMHO it's wrong to force them. I say thus, because legally it would not be possible to challenge such vendors globally as rules and regulations are different with different governments and or countries. Benji played a neat ball through to Dean Shiels who placed the ball past Meldrum before taking the acclaim of the large Hibernian support. Some relevant details are at the end of this email. Drizzle in Strasbourg Home :: Web Directory :: Leather News :: Free RSS news :: Free Newsletter :: Tell a Friend Clientfinder. The Easter Road side tore Motherwell apart with a stunning performance of pace, accuracy and goals! My next step, left to myself, would be to patch rcutorture. Merkwaardig genoeg is IT niet altijd even succesvol geweest in het automatiseren van haar eigen werking. It's not clear to me those particular semantics are the ideal ones. Wysocki"From"Rafael J. We should aim for doing well, yes. I don't have opposition about moving this up, but I'm misplacing the abobe code? Crossing the English channel Home :: Web Directory :: Leather News :: Free RSS news :: Free Newsletter :: Tell a Friend Clientfinder. Waarom deze workshop ? I'm very sorry for that. Any more tests you'd like me to try? The goal is to get all patches for a maintained subsystem submitted to Linus by the maintainer. By Melissa Magsaysay, Times Staff Writer . Propos will concentrate on pre-season fitness work, shaping exercises and plans for each individual player in the Hibernian squad. It would be fine to have the whole book as . Yup, netlink is clearly overkill. Somebody knows, that comprehensively testing hibernation is their thing. Yes, we should aim higher. Welke vragen worden beantwoord op dit seminar? This is all just food for thought. com Nome Search Powered by :: Free RSS news Add RSS news to your web site Leather news vertical portal can now be syndicated quickly and easily using our new Really Simple Syndication feeds. From czab@alanbelanger.net Wed Jun 20 06:21:14 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0xJK-000641-MR for megaco-archive@lists.ietf.org; Wed, 20 Jun 2007 06:21:14 -0400 Received: from [222.254.178.20] (helo=iwhw) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0xJI-0005q5-Rw for megaco-archive@lists.ietf.org; Wed, 20 Jun 2007 06:21:14 -0400 Received: from [152.221.226.224] (helo=gcv) by iwhw with smtp (Exim 4.62 (FreeBSD)) id 1I18%F-0001V6-B2; Wed, 20 Jun 2007 17:24:15 +0700 Message-ID: <4678FFA0.6070004@alanbelanger.net> Date: Wed, 20 Jun 2007 17:21:20 +0700 From: Bobbie X. Garcia User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: megaco-archive@lists.ietf.org Subject: crew refine Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.3 (++) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 OTCPicks.com Picks SREA As The Stock to Watch. UP 272% In 7 Days! Score One Inc. SREA $0.30 UP 20% Today Up another 20% today and over 272% in the last 7 days, OTCPICKS.com puts SREA on their watch list. Read up and get on SREA first thing Wed! King Bridei III began shapping himself in the image of a powerful leader ruling from his main base in Moray. Insomniac Mania :: View topic - So where it to find? Plant pot recycling Home :: Web Directory :: Garden News :: Free RSS news :: Free Newsletter :: Tell a Friend Clientfinder. Unfortunately not all records of the works commissioned by King David during the Davidian Revolution, so the exact number of burghs established by King David I is still unknown. A wide variety of wine glasses are also often used as water glasses. That word could mean different things to different people. Predominently this involved attacking neighbouring kingdoms. Research indicates that people learn better, retain more and are positively motivated when supported by regular and frequent leadership coaching. On what I need to pay attention? Of these, some of most important currently are Edinburgh and Stirling. "It's kind of my way of just getting away from things. Keep Kingsport Beautiful June award winning church belongs to . I know this, because I talk to them every day. The range is the beauty. Insomniac Mania :: View topic - news ! org -Local gardeners from all five boroughs gathered in the auditorium at the Brooklyn Botanic Garden Saturday morning at an event organized by the New York City . Please contact your system administrator to report this fault. Let me try to shine some light on the significant differences between the two. Research indicates that people learn better, retain more and are positively motivated when supported by regular and frequent leadership coaching. To ensure that the Student Awards Agency for Scotland will have money for payment of future tuition fees, the Student Award Agency charges a Graduate Endowment to most graduating students. Resourcers:WikipediaPubMed - Lead migration from lead crystal wine glassesDetermination of Lead Leaching . Blogger News Network -Most younger folks get it when they cut their hands or step on a nail, but often we forget Grandmom works in her garden and might not see a doctor for a . A wide variety of wine glasses are also often used as water glasses. New developments of products and special offers will be posted here first, so keep checking the content! Why dont YOU "Choose This Life" ? Due to disputes of his exact birthdate, it is unknown exactly how old King Bridei III was at his death. It soon came to be believed that King Bridei III was attempting to also secure the areas which were at one point ruled by his grandfather. Let me try to shine some light on the significant differences between the two. Help me, please, your advice. A directory of online self assessments to gain success in life and work. As a king, King Bridei III was regarded as a rather expasionary king. Huge pig farms in the Midwest and Southeastern U. King Bridei III is best known as one of the leaders involved in the Battle of Dunichen. And as such, in terms of education, the Student Awards Agency for Scotland would seem like a good thing to learn about. This integration of sensation happens in the brain as a result of information relayed by sensors reporting taste, smell and tactile information. Kingsport Times News, TN -An arched trellis marks the entrance and welcomes visitors to a biblical garden planted with fig trees, grapevines, daisies, and geraniums. To this day, the Clarsach is a modern symbol of Ireland. Help me, please, your advice. About Great Managing, Great Leading, and Sustained Individual Success Frederick F. New developments of products and special offers will be posted here first, so keep checking the content! From megaco-bounces@ietf.org Wed Jun 20 07:36:27 2007 Return-path: =20
Ma Haibo

----- =D7=AA=B7=A2=C8=CB=20 =C2=ED=BA=A3=B2=A8113845/user/zte_ltd =CA=B1=BC=E4 2007-06-23 12:13 = -----

=C2=ED=BA=A3=B2=A8113845
=C2=ED=BA=A3=B2=A8/3G=C6=BD=CC=A8=CF=B5=CD=B3=B2=BF/=D6=D0=D0= =C4=D1=D0=BE=BF=D4=BA/=D1=D0=B7=A2=CC=E5=CF=B5/=D6=D0=D0=CB=CD=A8=D1=B6=20

2007-06-23 12:03

= =20 =CA=D5=BC=FE=C8=CB=A3=BA "Schwarz = Albrecht"=20 <Albrecht.Schwarz@alcatel-lucent.de>
= =20 =B3=AD=CB=CD=A3=BA = megaco@ietf.org,=20 xie.baoguo@zte.com.cn =
= =D6=F7=CC=E2=A3=BA =20 reply:C-288: H.248.32 extension proposal=C1=B4=BD=D3

Hi,
thanks for=20 your attention.
Firstly, I think that dcr is the only = package that=20 could describe the congestion level of the whole MG and should be = applied on=20 ROOT termination, but the nt package usually is applied on a specific=20 termination.
Secondly, "bearer" may be a kind of resource that sources = from MG or=20 sinks to MG. It exists between MG and other equipments. When the = "bearer" is=20 broken and MGC need to re-route calls, the MG should report dcr/bear = with=20 dcr/bda to MGC.
So,=20
Q1: Yes..., "bearer" may = be=20 understood as external resource.
Q2: No, the nt package emphasizes = the=20 quality of connection for a specific call, and it do not include the = information=20 of the bearer destination and it can not respresent the whole MG. For = example,=20 AAL2 PVCs may be configured as static property previously in MG, and if = parts of=20 them are broken, they wouldn't affect the quality of calls on the left = bearers=20 that are not broken. So the nt/qualert is difficult to provide the=20 threshold-based occupance level of the MG because it only can be applied = on the=20 specific termination and the call using this termination may be very = well.=20 Furthermore, nt/qualert can not tell the MGC how many AAL2 PVCs has been = broken.

I'm sorry for my poor English and I hope you can = understand what=20 I said.

thanks=20
Ma Haibo

"Schwarz = Albrecht"=20 <Albrecht.Schwarz@alcatel-lucent.de>

2007-06-22 20:36

= =20
= =CA=D5=BC=FE=C8=CB=A3=BA=20 <ma.haibo@zte.com.cn>,=20 <xie.baoguo@zte.com.cn>=20
= =B3=AD=CB=CD=A3=BA=20 <megaco@ietf.org>
=20 =D6=F7=CC=E2=A3=BA = C-288: H.248.32=20 extension proposal

Hi,
like to understand the = difference=20 between an (IP, ATM) TERMINATION resource and an (IP, ATM) BEARER = resource from=20 H.248.32 point of view. =
Q1: This package did so = far consider=20 only MG-INTERNAL resource components, - is "bearer" defined as an = external=20 resource?

Q2: You propose to report = a=20 threshold-based occupance level of a "bearer" via dcr/conrep. Did you = consider=20 also nt/qualert, which provides also threshold-based occupance level = reporting=20 mechanism in my understanding? =
=20

Thanks=20
Albrecht

------_=_NextPart_001_01C7B99F.93DB11C4-- --===============0326534183== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0326534183==-- From megaco-bounces@ietf.org Thu Jun 28 13:11:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3xWg-0007cs-DX; Thu, 28 Jun 2007 13:11:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3xWf-0007cm-7e for megaco@ietf.org; Thu, 28 Jun 2007 13:11:25 -0400 Received: from smail5.alcatel.fr ([62.23.212.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3xWY-0002GI-0I for megaco@ietf.org; Thu, 28 Jun 2007 13:11:25 -0400 Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com [155.132.6.76]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l5SH9aRH028855; Thu, 28 Jun 2007 19:09:36 +0200 Received: from FRVELSMBS15.ad2.ad.alcatel.com ([155.132.6.35]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 28 Jun 2007 19:11:16 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 28 Jun 2007 19:11:15 +0200 Message-ID: <8BB8AD9870081C42B2B309E00352E4EA2F78B2@FRVELSMBS15.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: C-286: CAS Protocol Type Package Thread-Index: Ace5p1Xqj3FmA36HTpCxeBycZ1WEEQ== From: "Schwarz Albrecht" To: , , X-OriginalArrivalTime: 28 Jun 2007 17:11:16.0784 (UTC) FILETIME=[56A77300:01C7B9A7] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.1 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: megaco@ietf.org Subject: [Megaco] C-286: CAS Protocol Type Package X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0307531074==" Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============0307531074== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B9A7.569758EC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B9A7.569758EC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just my comments raised from our verbal discussions per email: The specific topic is basically related to physical terminations in general, and not only to CAS terminations in my understanding. Now, there is a specific call-to-bearer relation for H.248 physical terminations, particularily concerning the used signalling system for call control. Bearer and call are therefor tightly-coupled (e.g. by a CIC in SS7). The underlying call control signalling systems is thus of "static nature", a quasi-permanent attribute of a physical termination. (The "attribute value" of the physical termination would only change, then the peer PSTN/ISDN equipment (e.g. terminal, access node, switching system, CME, payphone, etc etc) would be changed (which is typically a rather seldom event; I mean a change of the physical charateristics, the call control signalling system and/or other stuff of a physical termination).) I think a good summary of that aspect might be the term "Bearer-Dependent Call Control" (BDCC) behind a physical H.248 Termination (i.e. exactly the opposite concept of Bearer-Independent Call Control, BICC). Due to that, the MGC may get easily the knowledge about the BDCC-type of a particular physical termination via a MGC level data base (and configuration management). The assumption here is a use case according your C-286, i.e. a MG network position, whereby the X physical Terminations of the NULL Context could be separated into multiple sub-sets x1, x2, ...xj, and all X physical Terminations would be of the same type with regards to the bearer technology (e.g. TDM, or analog line), and each sub-set xi would relate to a specific BDCC-type (e.g. SS R1, SS R2, SS R5, etc). Instead of a provisioned MGC level data base, the MGC could alternatively built-up the information base via auditing such a "termination attribute". But then the property value would be provisioned in the MG, and the characteristic would be "read-only". This is my understanding of your contribution. However, I got concerns when such a property would get "write access", because this would e.g. mean that the MGC could dynamically change the BDCC-type (which is implied to be used to control the bearer behind that physical termination). Right? I don't see the need for a *signalling* method here ... -Albrecht ------_=_NextPart_001_01C7B9A7.569758EC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable C-286: CAS Protocol Type Package

Just my comments raised from our = verbal discussions per email:

The specific topic is basically = related to physical terminations in general, and not only to CAS = terminations in my understanding.

Now, there is a specific = call-to-bearer relation for H.248 physical terminations, particularily = concerning the used signalling system for call control.

Bearer and call are therefor = tightly-coupled (e.g. by a CIC in SS7).
The underlying call control = signalling systems is thus of "static nature", a = quasi-permanent attribute of a physical termination.

(The "attribute value" = of the physical termination would only change, then the peer PSTN/ISDN = equipment (e.g. terminal, access node, switching system, CME, payphone, = etc etc) would be changed (which is typically a rather seldom event; I = mean a change of the physical charateristics, the call control = signalling system and/or other stuff of a physical = termination).)

I think a good summary of that = aspect might be the term "Bearer-Dependent Call Control" = (BDCC) behind a physical H.248 Termination (i.e. exactly the opposite = concept of Bearer-Independent Call Control, BICC).

Due to that, the MGC may get = easily the knowledge about the BDCC-type of a particular physical = termination via a MGC level data base (and configuration = management).

The assumption here is a use = case according your C-286, i.e. a MG network position, whereby the X = physical Terminations of the NULL Context could be separated into = multiple sub-sets x1, x2, ...xj, and all X physical Terminations would = be of the same type with regards to the bearer technology (e.g. TDM, or = analog line), and each sub-set xi would relate to a specific BDCC-type = (e.g. SS R1, SS R2, SS R5, etc).

Instead of a provisioned MGC = level data base, the MGC could alternatively built-up the information = base via auditing such a "termination attribute".

But then the property value = would be provisioned in the MG, and the characteristic would be = "read-only".
This is my understanding of = your contribution.

However, I got concerns when = such a property would get "write access", because this would = e.g. mean that the MGC could dynamically change the BDCC-type (which is = implied to be used to control the bearer behind that physical = termination). Right?

I don't see the need for a = *signalling* method here ...

-Albrecht

------_=_NextPart_001_01C7B9A7.569758EC-- --===============0307531074== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0307531074==-- From tempquky@budget.state.al.us Thu Jun 28 22:44:34 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I46TK-0001Yu-D7 for megaco-archive@lists.ietf.org; Thu, 28 Jun 2007 22:44:34 -0400 Received: from [222.64.167.115] (helo=115.167.64.222.broad.xw.sh.dynamic.163data.com.cn) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I46TI-0007Qg-Nk for megaco-archive@lists.ietf.org; Thu, 28 Jun 2007 22:44:34 -0400 Received: from [222.64.167.115] by smtp-2.state.al.us; Fri, 29 Jun 2007 02:44:26 -0900 Message-ID: <01c7b9f7$68b7b8c0$73a740de@tempquky> From: Dale To: Subject: see the price Date: Fri, 29 Jun 2007 02:44:26 -0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C7BA42.D89F60C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 4.5 (++++) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C7BA42.D89F60C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://agreeput.hk Viagra 60 pills x 100mg$141$2.35 per itemYour save: $6630 pills x 100mg$88.5$2.95 = per itemYour save: $1530 pills x 50mg$60.23$2.01 per itemYour save: $3010 p= ills x 50mg$30.22$3.03 per item 60 pills x 50mg$111.65$1.86 per itemYour sa= ve: $7010 pills x 100mg$34.49$3.45 per item 90 pills x 100mg$176.4$1.96 per= itemYour save: $134 Viagra Soft Tabs 30 pills x 50mg $66.28 $2.21 per item Your save: $34 60 pills x 50mg = $123.2 $2.05 per item Your save: $77 10 pills x 50mg $33.25 $3.33 per = item 10 pills x 100mg $37.94 $3.8 per item 30 pills x 100mg $97.= 35 $3.25 per item Your save: $16 60 pills x 100mg $155.1 $2.59 per ite= m Your save: $72 90 pills x 100mg $194.04 $2.16 per item Your save: $1= 47 Cialis Soft Tabs 20 pills x 20mg $109.73 $5.49 per item Your save: $22 = 30 pills x 20mg $131.97 $4.4 per item Your save: $66 60 pills x 20mg $= 260.53 $4.34 per item Your save: $136 10 pills x 20mg $65.97 $6.6 per = item 90 pills x 20mg $353.62 $3.93 per item Your save: $240 Cialis 20 pills x 20mg $76.68 $3.83 per item Your save: $2 30 pills x 2= 0mg $104.66 $3.49 per item Your save: $13 60 pills x 20mg $180.15 $3 = per item Your save: $55 90 pills x 20mg $242.06 $2.69 per item Your sa= ve: $111 10 pills x 20mg $39.19 $3.92 per item Viagra Jelly 30 pills x 100mg $92.4 $3.08 per item Your save: $1 60 pills x 100mg = $187.97 $3.14 per item Your save: $1 10 pills x 100mg $30.02 $3 per it= em Your save: $1 90 pills x 100mg $207.9 $2.31 per item Your save: $74= Levitra 30 pills x 20mg $82.01 $2.73 per item Your save: $1 60 pills x= 20mg $164.36 $2.74 per item Your save: $1 10 pills x 20mg $27.08 $2.= 71 per item 20 pills x 20mg $54.99 $2.75 per item 90 pills x 20mg= $246.57 $2.74 per item Your save: $1 http://agreeput.hk ------=_NextPart_000_0007_01C7BA42.D89F60C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://agreeput.hk Your save: $30 <= td>Your save: $70<= td> Your save: $34 Your save: $77 Your save: $72 Your save: $22 Your save: $136 $353.62 Your save: $2 <= td> $3.49 per item Your save: $111 Your save: $1 <= td> Your save: $1 = <= /TR> Your save: $1 <= td> $2.74 per item

Viagra
60 pills x 100mg	$141	$2.35 per item	Your s= ave: $66
30 pills x 100mg	$88.5	$2.95 per = item	Your save: $15
30 pills x 50mg	$60.23	$2.01 per item
10 pills x 50mg	$30.22	$3.03 per item
60 pills x 50mg	$111.65	$1.86 per item
10 pills x 100mg	$34.49	$3.45 per item
90 pills x 100mg	$176.4	$1.96 per item	Your= save: $134
Viagra Soft Tabs
30 pills x 50mg	$66.28	$2.21 per item
60 pills x 50mg	$123.2	$2.05 per item
10 pills x 50mg	$33.25	$3.33 per item
10 pills x 100mg	$37.94	$3.8 per= item
30 pills x 100mg	$97.35	$3.25 per item	Your save: $16
60 pills x 100mg	$155.1	$2.59 per item
90 pills x 100mg	$194.04	$2.16 per item	Your save: $147
Cialis Soft Tabs
20 pills x 20mg	$109.73	$5.49 per item
30 pills x 20mg	$131.97	$4.4 per item	Your save: $66
60 pills x 20mg	$260.53	$4.34 per item
10 pills x 20mg	$65.97	$6.6 per item
90 pills x 20mg	$3.93 per item	Your save: $240
Cialis
20 pills x 20mg	$76.68	$3.83 per item
30 pills x 20mg	$104.66	Your save: $13
60 pills x 20mg	$180.15	$3 per item	= Your save: $55
90 pills x 20mg	$242.06	$2.69 per item
10 pills x 20mg	$39.19	$3.92 per item
Viagra Jelly
30 pills x 100mg	$92.4	$3.08 per item
60 pills x 100mg	$187.97	$3.14 per item
10 pills x 100mg	$30.02	$3 per item	Your save: $1
90 pills x 100= mg	$207.9	$2.31 per item	Your save: $74
Levitra
30 pills x 20mg	$82.01	$2.73 per item
60 pills x 20mg	$164.36	Your save: $1
10 pills x 20mg	$27.08	$2.71 per item
20 pills x 20mg	$54.99	$2.75 per= item
90 pills x 20mg	$246.57	$2.74 per item	Your save: $1

http://agreeput.hk ------=_NextPart_000_0007_01C7BA42.D89F60C0-- From nasukza@charter.com Fri Jun 29 03:48:07 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4BD5-0000Ou-6J for megaco-archive@lists.ietf.org; Fri, 29 Jun 2007 03:48:07 -0400 Received: from 24-205-144-185.dhcp.mtpk.ca.charter.com ([24.205.144.185]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4BD4-0005nu-Uj for megaco-archive@lists.ietf.org; Fri, 29 Jun 2007 03:48:07 -0400 From: "superstar" To: megaco-archive@lists.ietf.org Subject: Application has been accepted Date: Fri, 29 Jun 2007 00:48:05 +0700 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0001_01C7B9E7.274EAD40" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Ace55ydOwPy7c/AOSBOFCBGOFk1KnQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <5FB77088643FD66.502E9B8257@charter.com> X-Spam-Score: 3.6 (+++) X-Scan-Signature: d6b246023072368de71562c0ab503126 ------=_NextPart_000_0001_01C7B9E7.274EAD40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thank you for your loan request, which we recieved yesterday, your refinance application has been accepted

Good Credit or Not, We are ready to give you a $481,000 loan, after further review, our lenders have established the lowest monthly payments.

Approval process will take only 1 minute.

Please visit the confirmation link below and fill-out our short 30 second Secure Web-Form.

http://arrvixrroatu.com/ ------=_NextPart_000_0001_01C7B9E7.274EAD40-- From megaco-bounces@ietf.org Fri Jun 29 07:36:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Ely-0003HR-Qw; Fri, 29 Jun 2007 07:36:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Elx-0003H9-J2 for megaco@ietf.org; Fri, 29 Jun 2007 07:36:21 -0400 Received: from in-smtp.ccpu.com ([61.95.244.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4ElT-00062f-EM for megaco@ietf.org; Fri, 29 Jun 2007 07:36:21 -0400 Received: from in-smtp.ccpu.com (localhost.localdomain [127.0.0.1]) by localhost.ccpu.com (Postfix) with ESMTP id C56B7B3EAF; Fri, 29 Jun 2007 17:02:23 +0530 (IST) Received: from IN-EXCHANGE.ccin.ccpu.com (in-exchange.ccpu.com [172.25.0.16]) by in-smtp.ccpu.com (Postfix) with ESMTP id 72870B3EAA; Fri, 29 Jun 2007 17:02:21 +0530 (IST) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 29 Jun 2007 17:02:53 +0530 Message-ID: <22F058C3ED9D784E90CE473F2A9847F001808A1F@in-exchange> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multimedia Play package Thread-Index: Ace6QTs2NQ49ItBbQI6BY9qWmz+hmw== From: "Syed Mohd Mujahid" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: Subject: [Megaco] Multimedia Play package X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0135121376==" Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============0135121376== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7BA41.3B7237B0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7BA41.3B7237B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, For multimedia play package (mpp, 0x00a9) , the signal parameters btn(0x0007), ctn(0x0007) have the same parameter ID values. Can anyone clarify on this? =20 With regards, Mujahid. ------_=_NextPart_001_01C7BA41.3B7237B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

For multimedia play package = (mpp, 0x00a9) , the signal parameters btn(0x0007), ctn(0x0007) have the same parameter ID = values.

Can anyone clarify on = this?

With regards,

Mujahid.

------_=_NextPart_001_01C7BA41.3B7237B0-- --===============0135121376== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0135121376==-- From megaco-bounces@ietf.org Fri Jun 29 08:18:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4FQz-0001Aa-1g; Fri, 29 Jun 2007 08:18:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4FQx-0001AE-R6 for megaco@ietf.org; Fri, 29 Jun 2007 08:18:43 -0400 Received: from in-smtp.ccpu.com ([61.95.244.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4FQ8-0000XL-Cm for megaco@ietf.org; Fri, 29 Jun 2007 08:18:43 -0400 Received: from in-smtp.ccpu.com (localhost.localdomain [127.0.0.1]) by localhost.ccpu.com (Postfix) with ESMTP id 09284B3EA3; Fri, 29 Jun 2007 17:44:26 +0530 (IST) Received: from IN-EXCHANGE.ccin.ccpu.com (in-exchange.ccpu.com [172.25.0.16]) by in-smtp.ccpu.com (Postfix) with ESMTP id F242FB3EA2; Fri, 29 Jun 2007 17:44:25 +0530 (IST) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 29 Jun 2007 17:46:02 +0530 Message-ID: <22F058C3ED9D784E90CE473F2A9847F001808A36@in-exchange> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Automatic Speech Recognition Pkg (asr, 0x00a6) Thread-Index: Ace6R0Kvnz3raMmhTIuK0Mcz3HiaGQ== From: "Syed Mohd Mujahid" To: X-Spam-Score: 0.2 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: Subject: [Megaco] Automatic Speech Recognition Pkg (asr, 0x00a6) X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1682056365==" Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============1682056365== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7BA47.433536D7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7BA47.433536D7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, For Automatic Speech Recognition package (asr, 0x00a6) , the Obs Evnt Desc parameters for the event asrsucc(0x0002) have same parameter IDs 0x0001. Is this a typo error? Can I consider them to be 0x0001 and 0x0002? =20 Can anyone throw light on this? =20 With regards, Mujahid. =20 =20 With regards, Syed Mohd Mujahid, Engineer, Continuous Computing, Bangalore. =20 ------_=_NextPart_001_01C7BA47.433536D7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

For Automatic Speech = Recognition package (asr, 0x00a6) , the Obs Evnt Desc parameters for the = event asrsucc(0x0002) have same parameter IDs 0x0001.

Is this a typo error? Can I consider them to = be 0x0001 and 0x0002?

Can anyone throw light on = this?

With regards,

Mujahid.

With regards,

Syed Mohd Mujahid,

Engineer,

Continuous Computing,

Bangalore.

------_=_NextPart_001_01C7BA47.433536D7-- --===============1682056365== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1682056365==-- From tkbbarefaced@inbox.com Fri Jun 29 08:20:41 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4FSq-0006GT-VB for megaco-archive@lists.ietf.org; Fri, 29 Jun 2007 08:20:41 -0400 Received: from p1094-ipbf1709hodogaya.kanagawa.ocn.ne.jp ([122.30.228.94] helo=inbox.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I4FSq-0006wG-60 for megaco-archive@lists.ietf.org; Fri, 29 Jun 2007 08:20:40 -0400 Message-ID: <000f01c7ba93$7c353890$06b8d094@user4m4ctczrup> From: "Orval Corley" To: "megaco-archive" Subject: Re: Thanks, we are ready to lend you some cash regardless of Credit Date: Fri, 29 Jun 2007 21:18:42 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C7BA93.7C353890" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c ------=_NextPart_000_000C_01C7BA93.7C353890 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your your credit report doesn't matter to us! If your family OWN real estate and want IMMEDIATE pocket money to spend = ANY way you like, or simply require to LOWER your monthly payments by a = third or more, here is our deal we can offer you TONIGHT (hurry, this = deal will expire NOW): $256,000+ loan AND EVEN MORE: After further review, our lenders have set the lowest = entire payment! Hurry, when our best deal is gone, it is gone. Simply fill in this = simple form... Do not worry about approval, your credit history will not disqualify = you! http://trylapjkfdterz.com/ ------=_NextPart_000_000C_01C7BA93.7C353890 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Your credit history = does not matter to us!

If your family OWN = property and want IMMEDIATE pin money to spend ANY way you like, or = simply want to LOWER your payments by a third or more, here is best deal = we can offer you THIS EVENING (hurry, this offer will expire = NOW):

$356,000+ = debt

AND EVEN MORE: After = further review, our lenders have established the lowest = payments!

Hurry, when the deal is = gone, it is gone. Simply complete this user-friendly form... =

Do not worry about = approval, your credit score will not disqualify you!

http://trylapjkfdterz.com/

------=_NextPart_000_000C_01C7BA93.7C353890-- From megaco-bounces@ietf.org Fri Jun 29 08:47:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Ft2-0007e1-DW; Fri, 29 Jun 2007 08:47:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Ft1-0007dv-9m for megaco@ietf.org; Fri, 29 Jun 2007 08:47:43 -0400 Received: from protext01.itu.ch ([156.106.192.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4Fss-0006i4-9Q for megaco@ietf.org; Fri, 29 Jun 2007 08:47:43 -0400 Received: from protext01.itu.ch ([156.106.192.41]) by protext01.itu.ch with Microsoft SMTPSVC(5.0.2195.6713); Fri, 29 Jun 2007 14:47:33 +0200 Received: From mail6.itu.ch ([156.106.192.22]) by protext01.itu.ch (WebShield SMTP v4.5 MR2); id 1183121252927; Fri, 29 Jun 2007 14:47:32 +0200 Received: from jys3105061844ka ([156.106.205.26]) by mail6.itu.ch (8.14.1/8.14.1) with SMTP id l5TClVGa032619; Fri, 29 Jun 2007 14:47:32 +0200 (MEST) Message-ID: <01eb01c7ba4b$ac810a80$1acd6a9c@china.huawei.com> From: "Yangbo Lin" To: "Syed Mohd Mujahid" References: <22F058C3ED9D784E90CE473F2A9847F001808A1F@in-exchange> Date: Fri, 29 Jun 2007 20:47:37 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0a6 (mail6.itu.ch [156.106.192.22]); Fri, 29 Jun 2007 14:47:32 +0200 (MEST) X-OriginalArrivalTime: 29 Jun 2007 12:47:33.0349 (UTC) FILETIME=[A990A150:01C7BA4B] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: megaco@ietf.org Subject: [Megaco] Re: Multimedia Play package X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0093390296==" Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============0093390296== Content-Type: multipart/alternative; boundary="----=_NextPart_000_01E8_01C7BA8E.BA057270" This is a multi-part message in MIME format. ------=_NextPart_000_01E8_01C7BA8E.BA057270 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 SGkgTXVqYWhpZCwNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnQuIEl0IGlzIGEgdHlwbyBlcnJv ciBhbmQgSSB3aWxsIGNvcnJlY3QgaXQgaW4gdGhlIGRyYWZ0Lg0KDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFJlZ2FyZHMsIFlhbmdibw0KDQogIC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0g DQogIEZyb206IFN5ZWQgTW9oZCBNdWphaGlkIA0KICBUbzogbWVnYWNvQGlldGYub3JnIA0KICBD YzogbGlueWFuZ2JvQGh1YXdlaS5jb20gDQogIFNlbnQ6IEZyaWRheSwgSnVuZSAyOSwgMjAwNyA3 OjMyIFBNDQogIFN1YmplY3Q6IE11bHRpbWVkaWEgUGxheSBwYWNrYWdlDQoNCg0KICBIaSwNCg0K ICAgICAgIEZvciBtdWx0aW1lZGlhIHBsYXkgcGFja2FnZSAobXBwLCAweDAwYTkpICwgdGhlIHNp Z25hbCBwYXJhbWV0ZXJzIGJ0bigweDAwMDcpLCBjdG4oMHgwMDA3KSBoYXZlIHRoZSBzYW1lIHBh cmFtZXRlciBJRCB2YWx1ZXMuDQoNCiAgQ2FuIGFueW9uZSBjbGFyaWZ5IG9uIHRoaXM/DQoNCiAg IA0KDQogIFdpdGggcmVnYXJkcywNCg0KICBNdWphaGlkLg0K ------=_NextPart_000_01E8_01C7BA8E.BA057270 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4bWxu czpvID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4bWxuczp3 ID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCI+PEhFQUQ+DQo8TUVU QSBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9aXNv LTg4NTktMSI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yOTAwLjMxMzIiIG5hbWU9R0VO RVJBVE9SPg0KPFNUWUxFPkBwYWdlIFNlY3Rpb24xIHtzaXplOiA4LjVpbiAxMS4waW47IG1hcmdp bjogMS4waW4gMS4yNWluIDEuMGluIDEuMjVpbjsgfQ0KUC5Nc29Ob3JtYWwgew0KCUZPTlQtU0la RTogMTJwdDsgTUFSR0lOOiAwaW4gMGluIDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9t YW4iDQp9DQpMSS5Nc29Ob3JtYWwgew0KCUZPTlQtU0laRTogMTJwdDsgTUFSR0lOOiAwaW4gMGlu IDBwdDsgRk9OVC1GQU1JTFk6ICJUaW1lcyBOZXcgUm9tYW4iDQp9DQpESVYuTXNvTm9ybWFsIHsN CglGT05ULVNJWkU6IDEycHQ7IE1BUkdJTjogMGluIDBpbiAwcHQ7IEZPTlQtRkFNSUxZOiAiVGlt ZXMgTmV3IFJvbWFuIg0KfQ0KQTpsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1ERUNPUkFUSU9O OiB1bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rIHsNCglDT0xPUjogYmx1ZTsgVEVYVC1E RUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NCkE6dmlzaXRlZCB7DQoJQ09MT1I6IHB1cnBsZTsgVEVY VC1ERUNPUkFUSU9OOiB1bmRlcmxpbmUNCn0NClNQQU4uTXNvSHlwZXJsaW5rRm9sbG93ZWQgew0K CUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9DQpTUEFOLkVtYWls U3R5bGUxNyB7DQoJQ09MT1I6IHdpbmRvd3RleHQ7IEZPTlQtRkFNSUxZOiBBcmlhbDsgbXNvLXN0 eWxlLXR5cGU6IHBlcnNvbmFsLWNvbXBvc2UNCn0NCkRJVi5TZWN0aW9uMSB7DQoJcGFnZTogU2Vj dGlvbjENCn0NCjwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9EWSBsYW5nPUVOLVVTIHZMaW5rPXB1cnBs ZSBsaW5rPWJsdWUgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48U1RST05HPjxFTT48Rk9OVCBjb2xv cj0jMDAwMGZmPkhpIE11amFoaWQsPC9GT05UPjwvRU0+PC9TVFJPTkc+PC9ESVY+DQo8RElWPjxT VFJPTkc+PEVNPjxGT05UIGNvbG9yPSMwMDAwZmY+PC9GT05UPjwvRU0+PC9TVFJPTkc+Jm5ic3A7 PC9ESVY+DQo8RElWPjxTVFJPTkc+PEVNPjxGT05UIGNvbG9yPSMwMDAwZmY+VGhhbmtzIGZvciB5 b3VyIGNvbW1lbnQuIEl0IGlzIGEgdHlwbyBlcnJvciANCmFuZCBJIHdpbGwgY29ycmVjdCBpdCBp biB0aGUgZHJhZnQuPC9GT05UPjwvRU0+PC9TVFJPTkc+PC9ESVY+DQo8RElWPjxTVFJPTkc+PEVN PjxGT05UIGNvbG9yPSMwMDAwZmY+PC9GT05UPjwvRU0+PC9TVFJPTkc+PFNUUk9ORz48RU0+PEZP TlQgDQpjb2xvcj0jMDAwMGZmPjwvRk9OVD48L0VNPjwvU1RST05HPiZuYnNwOzwvRElWPg0KPERJ Vj48U1RST05HPjxFTT48Rk9OVCBjb2xvcj0jMDAwMGZmPiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJz cDsmbmJzcDsmbmJzcDsgDQombmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZu YnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgDQombmJzcDsmbmJzcDsmbmJzcDsg Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsg DQombmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNw OyAmbmJzcDsmbmJzcDsmbmJzcDsgDQombmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5i c3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgDQombmJzcDsmbmJzcDsm bmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IFJlZ2FyZHMsIFlhbmdibzwvRk9OVD48L0VNPjwvU1RS T05HPjwvRElWPg0KPERJVj48U1RST05HPjxFTT48Rk9OVCBjb2xvcj0jMDAwMGZmPjwvRk9OVD48 L0VNPjwvU1RST05HPiZuYnNwOzwvRElWPg0KPEJMT0NLUVVPVEUgZGlyPWx0ciANCnN0eWxlPSJQ QURESU5HLVJJR0hUOiAwcHg7IFBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBC T1JERVItTEVGVDogIzAwMDAwMCAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJ ViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxGT05UIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSANCiAgLS0tLS0gPC9GT05UPjwvRElWPg0K ICA8RElWIHN0eWxlPSJCQUNLR1JPVU5EOiAjZTRlNGU0OyBGT05UOiA5cHQgJiMyMzQzNTsmIzIw MzA3OzsgZm9udC1jb2xvcjogYmxhY2siPjxGT05UIA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjxCPkZyb206PC9CPiA8L0ZPTlQ+PEEgdGl0bGU9c3llZC5tdWphaGlkQGNjcHUuY29tIA0KICBo cmVmPSJtYWlsdG86c3llZC5tdWphaGlkQGNjcHUuY29tIj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPlN5ZWQgTW9oZCANCiAgTXVqYWhpZDwvRk9OVD48L0E+PEZPTlQgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj4gPC9GT05UPjwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQz NTsmIzIwMzA3OyI+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48Qj5Ubzo8L0I+IDwvRk9O VD48QSANCiAgdGl0bGU9bWVnYWNvQGlldGYub3JnIGhyZWY9Im1haWx0bzptZWdhY29AaWV0Zi5v cmciPjxGT05UIA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPm1lZ2Fjb0BpZXRmLm9yZzwvRk9O VD48L0E+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gDQogIDwvRk9OVD48L0RJVj4NCiAg PERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxGT05UIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PEI+Q2M6PC9CPiA8L0ZPTlQ+PEEgDQogIHRpdGxlPWxpbnlhbmdib0BodWF3 ZWkuY29tIGhyZWY9Im1haWx0bzpsaW55YW5nYm9AaHVhd2VpLmNvbSI+PEZPTlQgDQogIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+bGlueWFuZ2JvQGh1YXdlaS5jb208L0ZPTlQ+PC9BPjxGT05UIA0K ICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8L0ZPTlQ+PC9ESVY+DQogIDxESVYgc3R5bGU9IkZP TlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxC PlNlbnQ6PC9CPiBGcmlkYXksIA0KICBKdW5lIDI5LCAyMDA3IDc6MzIgUE08L0ZPTlQ+PC9ESVY+ DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Rk9OVCBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPjxCPlN1YmplY3Q6PC9CPiANCiAgTXVsdGltZWRpYSBQbGF5IHBhY2th Z2U8L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEJSPjwvRElWPg0KICA8RElWIGNsYXNzPVNlY3Rpb24x Pg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogQXJpYWwiPjxGT05UIA0KICBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPkhpLDxvOnA+PC9vOnA+PC9GT05UPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBj bGFzcz1Nc29Ob3JtYWw+PEZPTlQgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAx MHB0OyBGT05ULUZBTUlMWTogQXJpYWwiPjxGT05UIA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBGb3IgbXVsdGltZWRpYSBwbGF5IHBhY2thZ2UgDQog IChtcHAsIDB4MDBhOSkgLCB0aGUgc2lnbmFsIHBhcmFtZXRlcnMgYnRuKDB4MDAwNyksIGN0bigw eDAwMDcpIGhhdmUgdGhlIHNhbWUgDQogIHBhcmFtZXRlciBJRCB2YWx1ZXMuPG86cD48L286cD48 L0ZPTlQ+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBzaXpl PTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCI+ PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5DYW4gDQogIGFueW9uZSBjbGFyaWZ5IG9uIHRo aXM/PG86cD48L286cD48L0ZPTlQ+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05v cm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mj48U1BBTiANCiAgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv U1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iVGltZXMg TmV3IFJvbWFuIiBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQt RkFNSUxZOiBBcmlhbCI+V2l0aCANCiAgcmVnYXJkcyw8L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+ PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBz aXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBBcmlh bCI+TXVqYWhpZC48L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPjwvRElWPjwvQkxPQ0tRVU9U RT48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_01E8_01C7BA8E.BA057270-- --===============0093390296== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0093390296==-- From megaco-bounces@ietf.org Fri Jun 29 08:49:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4FuN-0004m2-1f; Fri, 29 Jun 2007 08:49:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4FuM-0004hl-B5 for megaco@ietf.org; Fri, 29 Jun 2007 08:49:06 -0400 Received: from protext01.itu.ch ([156.106.192.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4Fu6-00075S-JA for megaco@ietf.org; Fri, 29 Jun 2007 08:49:06 -0400 Received: from protext01.itu.ch ([156.106.192.41]) by protext01.itu.ch with Microsoft SMTPSVC(5.0.2195.6713); Fri, 29 Jun 2007 14:48:49 +0200 Received: From mail6.itu.ch ([156.106.192.22]) by protext01.itu.ch (WebShield SMTP v4.5 MR2); id 1183121328943; Fri, 29 Jun 2007 14:48:48 +0200 Received: from jys3105061844ka ([156.106.205.26]) by mail6.itu.ch (8.14.1/8.14.1) with SMTP id l5TCmkpp032238; Fri, 29 Jun 2007 14:48:48 +0200 (MEST) Message-ID: <01f401c7ba4b$d9951c50$1acd6a9c@china.huawei.com> From: "Yangbo Lin" To: "Syed Mohd Mujahid" References: <22F058C3ED9D784E90CE473F2A9847F001808A36@in-exchange> Date: Fri, 29 Jun 2007 20:48:52 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0a6 (mail6.itu.ch [156.106.192.22]); Fri, 29 Jun 2007 14:48:48 +0200 (MEST) X-OriginalArrivalTime: 29 Jun 2007 12:48:49.0786 (UTC) FILETIME=[D71FFDA0:01C7BA4B] X-Spam-Score: 0.1 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: megaco@ietf.org Subject: [Megaco] Re: Automatic Speech Recognition Pkg (asr, 0x00a6) X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1142600089==" Errors-To: megaco-bounces@ietf.org This is a multi-part message in MIME format. --===============1142600089== Content-Type: multipart/alternative; boundary="----=_NextPart_000_01F1_01C7BA8E.E6D4B310" This is a multi-part message in MIME format. ------=_NextPart_000_01F1_01C7BA8E.E6D4B310 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 SGkgTXVqYWhpZCwNCg0KVGhhbmtzIGFnYWluIGZvciB5b3VyIGNvbW1lbnQuIEl0IGlzIGFsc28g YSB0eXBvIGVycm9yIGFuZCBJIHdpbGwgY29ycmVjdCBpdCBpbiB0aGUgZHJhZnQuDQoNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgUmVnYXJkcywgWWFuZ2JvDQoNCiAgLS0tLS0gT3JpZ2luYWwgTWVz c2FnZSAtLS0tLSANCiAgRnJvbTogU3llZCBNb2hkIE11amFoaWQgDQogIFRvOiBtZWdhY29AaWV0 Zi5vcmcgDQogIENjOiBsaW55YW5nYm9AaHVhd2VpLmNvbSANCiAgU2VudDogRnJpZGF5LCBKdW5l IDI5LCAyMDA3IDg6MTYgUE0NCiAgU3ViamVjdDogQXV0b21hdGljIFNwZWVjaCBSZWNvZ25pdGlv biBQa2cgKGFzciwgMHgwMGE2KQ0KDQoNCiAgSGksDQoNCiAgICAgICBGb3IgQXV0b21hdGljIFNw ZWVjaCBSZWNvZ25pdGlvbiBwYWNrYWdlIChhc3IsIDB4MDBhNikgLCB0aGUgT2JzIEV2bnQgRGVz YyAgcGFyYW1ldGVycyAgZm9yIHRoZSBldmVudCBhc3JzdWNjKDB4MDAwMikgIGhhdmUgc2FtZSBw YXJhbWV0ZXIgSURzIDB4MDAwMS4NCg0KICAgIElzIHRoaXMgYSB0eXBvIGVycm9yPyBDYW4gSSBj b25zaWRlciB0aGVtIHRvIGJlIDB4MDAwMSBhbmQgMHgwMDAyPw0KDQogICANCg0KICBDYW4gYW55 b25lIHRocm93IGxpZ2h0IG9uIHRoaXM/DQoNCiAgIA0KDQogIFdpdGggcmVnYXJkcywNCg0KICBN dWphaGlkLg0KDQogICANCg0KICAgDQoNCiAgV2l0aCByZWdhcmRzLA0KDQogIFN5ZWQgTW9oZCBN dWphaGlkLA0KDQogIEVuZ2luZWVyLA0KDQogIENvbnRpbnVvdXMgQ29tcHV0aW5nLA0KDQogIEJh bmdhbG9yZS4NCg0KICAgDQo= ------=_NextPart_000_01F1_01C7BA8E.E6D4B310 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4bWxu czpvID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4bWxuczp3 ID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6c3QxID0g DQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzIj48SEVBRD4NCjxN RVRBIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1p c28tODg1OS0xIj4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2LjAwLjI5MDAuMzEzMiIgbmFtZT1H RU5FUkFUT1I+PG86U21hcnRUYWdUeXBlIG5hbWU9IkNpdHkiIA0KbmFtZXNwYWNldXJpPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MiPjwvbzpTbWFydFRhZ1R5cGU+ PG86U21hcnRUYWdUeXBlIA0KbmFtZT0icGxhY2UiIG5hbWVzcGFjZXVyaT0idXJuOnNjaGVtYXMt bWljcm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzIiANCmRvd25sb2FkdXJsPSJodHRwOi8vd3d3 LjVpYW50bGF2YWxhbXAuY29tLyI+PC9vOlNtYXJ0VGFnVHlwZT48IS0tW2lmICFtc29dPg0KPFNU WUxFPnN0MVw6KiB7DQoJQkVIQVZJT1I6IHVybCgjZGVmYXVsdCNpZW9vdWkpDQp9DQo8L1NUWUxF Pg0KPCFbZW5kaWZdLS0+DQo8U1RZTEU+DQo8IS0tDQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CiBwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtjb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe2NvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNv bXBvc2U7DQoJZm9udC1mYW1pbHk6QXJpYWw7DQoJY29sb3I6d2luZG93dGV4dDt9DQpAcGFnZSBT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4yNWluIDEuMGlu IDEuMjVpbjt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpTZWN0aW9uMTt9DQotLT4NCjwvU1RZTEU+ DQo8L0hFQUQ+DQo8Qk9EWSBsYW5nPUVOLVVTIHZMaW5rPXB1cnBsZSBsaW5rPWJsdWUgYmdDb2xv cj0jZmZmZmZmPg0KPERJVj4NCjxESVY+PFNUUk9ORz48RU0+PEZPTlQgY29sb3I9IzAwMDBmZj5I aSBNdWphaGlkLDwvRk9OVD48L0VNPjwvU1RST05HPjwvRElWPg0KPERJVj48U1RST05HPjxFTT48 Rk9OVCBjb2xvcj0jMDAwMGZmPjwvRk9OVD48L0VNPjwvU1RST05HPiZuYnNwOzwvRElWPg0KPERJ Vj48U1RST05HPjxFTT48Rk9OVCBjb2xvcj0jMDAwMGZmPlRoYW5rcyBhZ2FpbiBmb3IgeW91ciBj b21tZW50LiBJdCBpcyBhbHNvIGEgDQp0eXBvIGVycm9yIGFuZCBJIHdpbGwgY29ycmVjdCBpdCBp biB0aGUgZHJhZnQuPC9GT05UPjwvRU0+PC9TVFJPTkc+PC9ESVY+DQo8RElWPjxTVFJPTkc+PEVN PjxGT05UIGNvbG9yPSMwMDAwZmY+PC9GT05UPjwvRU0+PC9TVFJPTkc+PFNUUk9ORz48RU0+PEZP TlQgDQpjb2xvcj0jMDAwMGZmPjwvRk9OVD48L0VNPjwvU1RST05HPiZuYnNwOzwvRElWPg0KPERJ Vj48U1RST05HPjxFTT48Rk9OVCBjb2xvcj0jMDAwMGZmPiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJz cDsmbmJzcDsmbmJzcDsgDQombmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZu YnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgDQombmJzcDsmbmJzcDsmbmJzcDsg Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsg DQombmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNw OyAmbmJzcDsmbmJzcDsmbmJzcDsgDQombmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5i c3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsgDQombmJzcDsmbmJzcDsm bmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IFJlZ2FyZHMsIFlhbmdibzwvRk9OVD48L0VNPjwvU1RS T05HPjwvRElWPg0KPERJVj48U1RST05HPjxFTT48Rk9OVCBjb2xvcj0jMDAwMGZmPjwvRk9OVD48 L0VNPjwvU1RST05HPiZuYnNwOzwvRElWPjwvRElWPg0KPEJMT0NLUVVPVEUgZGlyPWx0ciANCnN0 eWxlPSJQQURESU5HLVJJR0hUOiAwcHg7IFBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDog NXB4OyBCT1JERVItTEVGVDogIzAwMDAwMCAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4N CiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxGT05UIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSANCiAgLS0tLS0gPC9GT05UPjwv RElWPg0KICA8RElWIHN0eWxlPSJCQUNLR1JPVU5EOiAjZTRlNGU0OyBGT05UOiA5cHQgJiMyMzQz NTsmIzIwMzA3OzsgZm9udC1jb2xvcjogYmxhY2siPjxGT05UIA0KICBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxCPkZyb206PC9CPiA8L0ZPTlQ+PEEgdGl0bGU9c3llZC5tdWphaGlkQGNjcHUuY29t IA0KICBocmVmPSJtYWlsdG86c3llZC5tdWphaGlkQGNjcHUuY29tIj48Rk9OVCBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPlN5ZWQgTW9oZCANCiAgTXVqYWhpZDwvRk9OVD48L0E+PEZPTlQgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj4gPC9GT05UPjwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQg JiMyMzQzNTsmIzIwMzA3OyI+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48Qj5Ubzo8L0I+ IDwvRk9OVD48QSANCiAgdGl0bGU9bWVnYWNvQGlldGYub3JnIGhyZWY9Im1haWx0bzptZWdhY29A aWV0Zi5vcmciPjxGT05UIA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPm1lZ2Fjb0BpZXRmLm9y ZzwvRk9OVD48L0E+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gDQogIDwvRk9OVD48L0RJ Vj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxGT05UIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PEI+Q2M6PC9CPiA8L0ZPTlQ+PEEgDQogIHRpdGxlPWxpbnlhbmdi b0BodWF3ZWkuY29tIGhyZWY9Im1haWx0bzpsaW55YW5nYm9AaHVhd2VpLmNvbSI+PEZPTlQgDQog IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+bGlueWFuZ2JvQGh1YXdlaS5jb208L0ZPTlQ+PC9BPjxG T05UIA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8L0ZPTlQ+PC9ESVY+DQogIDxESVYgc3R5 bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPjxCPlNlbnQ6PC9CPiBGcmlkYXksIA0KICBKdW5lIDI5LCAyMDA3IDg6MTYgUE08L0ZPTlQ+ PC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Rk9OVCBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxCPlN1YmplY3Q6PC9CPiANCiAgQXV0b21hdGljIFNwZWVj aCBSZWNvZ25pdGlvbiBQa2cgKGFzciwgMHgwMGE2KTwvRk9OVD48L0RJVj4NCiAgPERJVj48QlI+ PC9ESVY+DQogIDxESVYgY2xhc3M9U2VjdGlvbjE+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9O VCBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBB cmlhbCI+PEZPTlQgDQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+SGksPG86cD48L286cD48L0ZP TlQ+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBzaXplPTI+ PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PEZP TlQgDQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZv ciBBdXRvbWF0aWMgU3BlZWNoIA0KICBSZWNvZ25pdGlvbiBwYWNrYWdlIChhc3IsIDB4MDBhNikg LCB0aGUgT2JzIEV2bnQgRGVzYyAmbmJzcDtwYXJhbWV0ZXJzIA0KICAmbmJzcDtmb3IgdGhlIGV2 ZW50IGFzcnN1Y2MoMHgwMDAyKSZuYnNwOyBoYXZlIHNhbWUgcGFyYW1ldGVyIElEcyANCiAgMHgw MDAxLjxvOnA+PC9vOnA+PC9GT05UPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29O b3JtYWw+PEZPTlQgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05U LUZBTUlMWTogQXJpYWwiPjxGT05UIA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOyBJ cyB0aGlzIGEgdHlwbyBlcnJvcj8gQ2FuIEkgY29uc2lkZXIgdGhlbSB0byBiZSANCiAgMHgwMDAx IGFuZCAweDAwMDI/PG86cD48L286cD48L0ZPTlQ+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNs YXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mj48U1BBTiAN CiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgc2l6 ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogQXJpYWwi PjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Q2FuIA0KICBhbnlvbmUgdGhyb3cgbGlnaHQg b24gdGhpcz88bzpwPjwvbzpwPjwvRk9OVD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9 TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0yPjxTUEFOIA0KICBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogQXJpYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iIHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsg Rk9OVC1GQU1JTFk6IEFyaWFsIj5XaXRoIA0KICByZWdhcmRzLDwvU1BBTj48L0ZPTlQ+PG86cD48 L286cD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iIHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6 IEFyaWFsIj5NdWphaGlkLjwvU1BBTj48L0ZPTlQ+PG86cD48L286cD48L1A+DQogIDxQIGNsYXNz PU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mj48U1BBTiANCiAg c3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IEFyaWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0i VGltZXMgTmV3IFJvbWFuIiBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7 IEZPTlQtRkFNSUxZOiBBcmlhbCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9GT05UPjwvUD4N CiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0y PjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogQXJpYWwiPldp dGggDQogIHJlZ2FyZHMsPC9TUEFOPjwvRk9OVD48bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9 TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0yPjxTUEFOIA0KICBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogQXJpYWwiPlN5ZWQgTW9oZCANCiAg TXVqYWhpZCw8L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3Jt YWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBBcmlhbCI+RW5naW5lZXIsPC9TUEFOPjwvRk9O VD48bzpwPjwvbzpwPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVz IE5ldyBSb21hbiIgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05U LUZBTUlMWTogQXJpYWwiPkNvbnRpbnVvdXMgDQogIENvbXB1dGluZyw8L1NQQU4+PC9GT05UPjxv OnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj48c3QxOkNpdHkgdzpzdD0ib24iPjxzdDE6cGxhY2UgDQogIHc6c3Q9Im9uIj48Rk9O VCBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBB cmlhbCI+QmFuZ2Fsb3JlPC9TUEFOPjwvRk9OVD48L3N0MTpwbGFjZT48L3N0MTpDaXR5PjxGT05U IA0KICBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZ OiBBcmlhbCI+LjwvU1BBTj48L0ZPTlQ+PG86cD48L286cD48L0ZPTlQ+PC9QPg0KICA8UCBjbGFz cz1Nc29Ob3JtYWw+PEZPTlQgc2l6ZT0zPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPjwvQkxPQ0tRVU9URT48 L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_01F1_01C7BA8E.E6D4B310-- --===============1142600089== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============1142600089==-- From megaco-bounces@ietf.org Fri Jun 29 10:02:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4H33-0000rq-QC; Fri, 29 Jun 2007 10:02:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4H31-0000o4-IA for megaco@ietf.org; Fri, 29 Jun 2007 10:02:07 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4H2M-0000zJ-TT for megaco@ietf.org; Fri, 29 Jun 2007 10:02:07 -0400 Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l5TE1Oq24793 for ; Fri, 29 Jun 2007 14:01:24 GMT X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: RE: [Megaco] C-286: CAS Protocol Type Package Date: Fri, 29 Jun 2007 10:00:28 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4101D10B6@zrtphxm2.corp.nortel.com> In-Reply-To: <8BB8AD9870081C42B2B309E00352E4EA2F78B2@FRVELSMBS15.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Megaco] C-286: CAS Protocol Type Package Thread-Index: Ace5p1Xqj3FmA36HTpCxeBycZ1WEEQAreDlA References: <8BB8AD9870081C42B2B309E00352E4EA2F78B2@FRVELSMBS15.ad2.ad.alcatel.com> From: "Kevin Boyle" To: "Schwarz Albrecht" , , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Frankly, I don't see the need for this at all. MGs *must* know how to operate their terminations. The signaling system assigned to a termination has actual physical characteristics that go beyond software assignment -- R2 uses a 4 wire line state system, for example, while typical POTS uses a two wire tip/ring system. Both of these can be considered CAS signaling scenarios. It is clear that software assignment will never turn a POTS line into an R2 channel -- that would require adding physical hardware. As such, protocol assignment becomes impossible. This is information that MUST be provisioned in the MG. The MG will need this information at boot time in order to initialize the terminations correctly. Remember that H.248 assumes that all terminations are InService upon registration. By requiring MGC interaction to assign the "termination type", this is impossible. Therefore, this methodology could be seen as violating the protocol. Kevin ________________________________ From: Schwarz Albrecht [mailto:Albrecht.Schwarz@alcatel-lucent.de] Sent: Thursday, June 28, 2007 1:11 PM To: ning.dongzi@zte.com.cn; xie.baoguo@zte.com.cn; ma.haibo@zte.com.cn Cc: megaco@ietf.org Subject: [Megaco] C-286: CAS Protocol Type Package Just my comments raised from our verbal discussions per email: The specific topic is basically related to physical terminations in general, and not only to CAS terminations in my understanding. Now, there is a specific call-to-bearer relation for H.248 physical terminations, particularily concerning the used signalling system for call control. Bearer and call are therefor tightly-coupled (e.g. by a CIC in SS7). The underlying call control signalling systems is thus of "static nature", a quasi-permanent attribute of a physical termination. (The "attribute value" of the physical termination would only change, then the peer PSTN/ISDN equipment (e.g. terminal, access node, switching system, CME, payphone, etc etc) would be changed (which is typically a rather seldom event; I mean a change of the physical charateristics, the call control signalling system and/or other stuff of a physical termination).) I think a good summary of that aspect might be the term "Bearer-Dependent Call Control" (BDCC) behind a physical H.248 Termination (i.e. exactly the opposite concept of Bearer-Independent Call Control, BICC). Due to that, the MGC may get easily the knowledge about the BDCC-type of a particular physical termination via a MGC level data base (and configuration management). The assumption here is a use case according your C-286, i.e. a MG network position, whereby the X physical Terminations of the NULL Context could be separated into multiple sub-sets x1, x2, ...xj, and all X physical Terminations would be of the same type with regards to the bearer technology (e.g. TDM, or analog line), and each sub-set xi would relate to a specific BDCC-type (e.g. SS R1, SS R2, SS R5, etc). Instead of a provisioned MGC level data base, the MGC could alternatively built-up the information base via auditing such a "termination attribute". But then the property value would be provisioned in the MG, and the characteristic would be "read-only". This is my understanding of your contribution. However, I got concerns when such a property would get "write access", because this would e.g. mean that the MGC could dynamically change the BDCC-type (which is implied to be used to control the bearer behind that physical termination). Right? I don't see the need for a *signalling* method here ... -Albrecht _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From bjduo@pandev.net Fri Jun 29 16:44:30 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4NKQ-0003mM-9O for megaco-archive@lists.ietf.org; Fri, 29 Jun 2007 16:44:30 -0400 Received: from srv1a.brochow.net ([89.174.68.3]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I4NJS-0000dO-I1 for megaco-archive@lists.ietf.org; Fri, 29 Jun 2007 16:44:30 -0400 Received: from kfl.uygo ([222.138.35.212]) by srv1a.brochow.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 22:43:28 +0200 Message-ID: <002601c7ba8e$25b2ddb0$d4238ade@kfl.uygo> From: "2000Greetings.Com" To: Subject: You've received a postcard from a family member! Date: Fri, 29 Jun 2007 22:43:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2578 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2578 X-Spam-Score: 4.5 (++++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Good day. Your family member has sent you an ecard from 2000Greetings.Com. Send free ecards from 2000Greetings.Com with your choice of colors, words and music. Your ecard will be available with us for the next 30 days. If you wish to keep the ecard longer, you may save it on your computer or take a print. To view your ecard, choose from any of the following options: -------- OPTION 1 -------- Click on the following Internet address or copy & paste it into your browser's address box. http://70.71.5.97/?9a885b5e6291c3de8293ec6968e3ca036 -------- OPTION 2 -------- Copy & paste the ecard number in the "View Your Card" box at http://70.71.5.97/ Your ecard number is 9a885b5e6291c3de8293ec6968e3ca036 Best wishes, Postmaster, 2000Greetings.Com From megaco-bounces@ietf.org Sat Jun 30 01:43:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Vk6-0004Ea-DA; Sat, 30 Jun 2007 01:43:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Vk5-0004AR-1L for megaco@ietf.org; Sat, 30 Jun 2007 01:43:33 -0400 Received: from an-out-0708.google.com ([209.85.132.248]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4Vk4-0005X2-RH for megaco@ietf.org; Sat, 30 Jun 2007 01:43:32 -0400 Received: by an-out-0708.google.com with SMTP id c17so240897anc for ; Fri, 29 Jun 2007 22:43:08 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=R36WBByMDECzlhirvDaz0pnieSyy1Mexu+yH1GivUkua1VCgOEy1Xk4GOEoTPQw0EqBWS2Otzq88mhWw5rFkicus/t5jN3Qvq49h/AjenMVBDC3zEPpP/B1VHpTYxEkEUC16yXxbM3p8uRdLzvrxJI0hnStJLg0rK4eD4G/+cFI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=Hn95z0W+DcgDf1SHn1arZkX7tM1QfpjHy42MU6jEgf09EOkW5Vvw1VfomN2BZTUWMq3jwzwwQ6ZiD5+zE9pBR7nLNzhEl7j9MqpXHiJRWYwn/105o4fdHqIuoLAbQIxXL0N5Btnuwl17GHBv88wz3nyLCNSQl7n4Jjb0he2sAmw= Received: by 10.100.154.13 with SMTP id b13mr2564257ane.1183182188410; Fri, 29 Jun 2007 22:43:08 -0700 (PDT) Received: by 10.100.174.10 with HTTP; Fri, 29 Jun 2007 22:43:08 -0700 (PDT) Message-ID: Date: Fri, 29 Jun 2007 23:43:08 -0600 From: "Mithuna Moorthy" To: megaco@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [Megaco] Order of terminations during the conext modification X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0350240520==" Errors-To: megaco-bounces@ietf.org --===============0350240520== Content-Type: multipart/alternative; boundary="----=_Part_83546_18482584.1183182188392" ------=_Part_83546_18482584.1183182188392 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, While doing MODIFY command on termination modes in the same conext,is it important to maintain the ORDER in which the terminations were created during the call setup? Eg: If IP/7 is the first termination created for the call and IP/8 is the second termination, if I have to modify termination modes then should the commands to be in the order of IP/7 and IP/8. Kindly provide your inputs. Thanks, Mithuna ------=_Part_83546_18482584.1183182188392 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

Hi,

While doing MODIFY command on termination modes in the same conext,is it important to maintain the

ORDER in which the terminations were created during the call setup?

Eg:

If IP/7 is the first termination created for the call and IP/8 is the second termination, if I

have to modify termination modes then should the commands to be in the order of IP/7 and IP/8.

Kindly provide your inputs.

Thanks,

Mithuna

------=_Part_83546_18482584.1183182188392-- --===============0350240520== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco --===============0350240520==-- From rtkoa@providence.edu Sat Jun 30 06:47:07 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4aTr-0002Cb-Mc for megaco-archive@lists.ietf.org; Sat, 30 Jun 2007 06:47:07 -0400 Received: from anantes-256-1-148-50.w90-31.abo.wanadoo.fr ([90.31.139.50]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I4aTk-0006Ze-3M for megaco-archive@lists.ietf.org; Sat, 30 Jun 2007 06:47:07 -0400 Received: from lungi.azj ([149.97.103.172]) by ANantes-256-1-148-50.w90-31.abo.wanadoo.fr with Microsoft SMTPSVC(6.0.3790.1830); Sat, 30 Jun 2007 12:46:56 +0200 Message-ID: <000a01c7bb03$fa962b70$ac676195@lungi.azj> From: "VintagePostcards.Com" To: Subject: You've received a greeting ecard from a school-mate! Date: Sat, 30 Jun 2007 12:46:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2578 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2578 X-Spam-Score: 4.6 (++++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Good day. Your school-mate has sent you a greeting ecard from VintagePostcards.Com. Send free ecards from VintagePostcards.Com with your choice of colors, words and music. Your ecard will be available with us for the next 30 days. If you wish to keep the ecard longer, you may save it on your computer or take a print. To view your ecard, choose from any of the following options: -------- OPTION 1 -------- Click on the following Internet address or copy & paste it into your browser's address box. http://89.178.98.208/?0229e368412571d7d41977bc649ea955238937 -------- OPTION 2 -------- Copy & paste the ecard number in the "View Your Card" box at http://89.178.98.208/ Your ecard number is 0229e368412571d7d41977bc649ea955238937 Best wishes, Webmaster, VintagePostcards.Com From zaoh@wanadoo.fr Sat Jun 30 07:45:50 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4bOg-0006jr-Fi for megaco-archive@lists.ietf.org; Sat, 30 Jun 2007 07:45:50 -0400 Received: from [81.215.229.51] (helo=dsl.static8121522951.ttnet.net.tr) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I4bOZ-0005Cp-O7 for megaco-archive@lists.ietf.org; Sat, 30 Jun 2007 07:45:50 -0400 Received: from grh.xpex ([26.136.212.188]) by dsl.static8121522951.ttnet.net.tr with Microsoft SMTPSVC(5.0.2195.6713); Sat, 30 Jun 2007 14:45:41 +0300 Message-ID: <002f01c7bb0c$2fbaa030$bcd4881a@grh.xpex> From: "riversongs.Com" To: Subject: You've received a postcard from a class mate! Date: Sat, 30 Jun 2007 14:45:41 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Score: 1.9 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Good day. Your class mate has sent you a postcard from riversongs.Com. Send free ecards from riversongs.Com with your choice of colors, words and music. Your ecard will be available with us for the next 30 days. If you wish to keep the ecard longer, you may save it on your computer or take a print. To view your ecard, choose from any of the following options: -------- OPTION 1 -------- Click on the following Internet address or copy & paste it into your browser's address box. http://201.212.160.78/?675c50080d0229e368412571d7d4197 -------- OPTION 2 -------- Copy & paste the ecard number in the "View Your Card" box at http://201.212.160.78/ Your ecard number is 675c50080d0229e368412571d7d4197 Best wishes, Administrator, riversongs.Com From aslq@mtv.com Sat Jun 30 11:11:17 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4ebV-0007ls-Tz for megaco-archive@lists.ietf.org; Sat, 30 Jun 2007 11:11:17 -0400 Received: from 219.242.pppoe.mari-el.ru ([195.161.242.219]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I4ear-00025G-Jt for megaco-archive@lists.ietf.org; Sat, 30 Jun 2007 11:11:17 -0400 Received: (qmail 29071 invoked from network); Sat, 30 Jun 2007 19:10:31 +0400 Received: from unknown (HELO tqji) (36.124.173.62) by 219.242.pppoe.mari-el.ru with SMTP; Sat, 30 Jun 2007 19:10:31 +0400 Message-ID: <46867267.1080306@mtv.com> Date: Sat, 30 Jun 2007 19:10:31 +0400 From: Trudy K. Clarke User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: megaco-archive@lists.ietf.org Subject: This vagueness arises from the multitude of tasks that can be accomplished by such volunteers. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab ERMX Jumps Into Huge Advanced Nitride Super Conductors! EntreMetrix Inc. (ERMX) $0.16 ERMX has just announced it involvement in a joint venture to manufacture Advanced Nitride Devices. These have Military application as well as Energy Super Conductors. This takes ERMX to a whole new level. Google "Nitride Devices" and get on ERMX first thing Monday! Our volunteers will not need air-conditioned chambers, no! Our volunteers will not need air-conditioned chambers, no! The focus will be on the number and diversity of international volunteers that this association is able to attract. For it to be anything else would not only seem strange to all of you but would probably result in Cass complaining bitterly on a celestial blog somewhere. The government has struggled to raise the funds to reclaim its share of the energy pie while assembling a solid team of competent and honest people to manage it. He is looking for a chance to do something fruitful for the greater part of the society who live in penury. The volunteers will work for this purpose with the aid that the government normally allocates for this. The effect that the situation in Venezuela is having on the international audience can scarcely be appreciated by the leaders in Venezuela themselves. Anybody who is willing to work will be a volunteer. The rosy myth of ever expanding markets and the triumph of the free market has given way to the scorching worry of the fear of loosing jobs to the under paid worker in Asia. This will give you a good idea of background and a flavour of what is contained in the hundreds of other entries. The music that will be played throughout the ceremony has been specially and carefully selected to reflect Cass's interests and tastes. Very different is the attitude of the volunteers that I seek to attract through the association. SLUDGEAWAYSMARTIES ANYONE? Bolivia has a history of short-lived presidencies. This motivates him and this alone. Surely a comparison of both Mr. The social changes ushered in and sought to be ushered in by the regime of President Chavez are being keenly studied and appreciated by the international audience. Probably the same for most people. I am looking at hundreds of such students who will be assigned to various tasks by the association. Secondly it will give the government a great chance to demonstrate to the volunteers the ideology that we follow. This may seem analogous to the missionaries call for such help but the difference is enormous. The nationalization project has not been a smooth one. That was supposed to be a utopian dream forever. There are hundreds of such people who are fed up of donating to charities, who yearn for some practical action. Shit happened and I could do nothing to stop it. Please follow the link below. From lszqmhqzsl@edicionesjust.com Sat Jun 30 12:31:36 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4frD-0003DI-V8 for megaco-archive@lists.ietf.org; Sat, 30 Jun 2007 12:31:35 -0400 Received: from [211.192.165.182] (helo=[211.192.165.182]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4frD-0006Qj-Iu for megaco-archive@lists.ietf.org; Sat, 30 Jun 2007 12:31:35 -0400 From: "horse" To: megaco-archive@lists.ietf.org Subject: Loan for a low month payment Date: Sun, 1 Jul 2007 01:31:26 -0900 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0004_01C7BB7F.8A9CC8C0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Ace7f4qcJ5aZD9gWQbuMAq6lDK0OcA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <6F8EA22C0A09ED2.7F24CB30FB@edicionesjust.com> X-Spam-Score: 3.6 (+++) X-Scan-Signature: d6b246023072368de71562c0ab503126 ------=_NextPart_000_0004_01C7BB7F.8A9CC8C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thank you for your loan request, which we recieved yesterday, your refinance application has been accepted

Good Credit or Not, We are ready to give you a $245,000 loan, after further review, our lenders have established the lowest monthly payments.

Approval process will take only 1 minute.

Please visit the confirmation link below and fill-out our short 30 second Secure Web-Form.

http://timexryoou.com/ ------=_NextPart_000_0004_01C7BB7F.8A9CC8C0-- From megaco-bounces@ietf.org Sat Jun 30 15:05:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4iGK-0001Dm-Ow; Sat, 30 Jun 2007 15:05:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4iGK-0001Dh-4X for megaco@ietf.org; Sat, 30 Jun 2007 15:05:40 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4iGG-0005H0-Qo for megaco@ietf.org; Sat, 30 Jun 2007 15:05:40 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id E9023559DC6; Sat, 30 Jun 2007 12:05:35 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11581-10; Sat, 30 Jun 2007 12:05:35 -0700 (PDT) Received: from [155.53.44.239] (cologne.redback.com [155.53.44.239]) by prattle.redback.com (Postfix) with ESMTP id C848B559DC4; Sat, 30 Jun 2007 12:05:35 -0700 (PDT) Message-ID: <4686A97F.1020308@redback.com> Date: Sat, 30 Jun 2007 12:05:35 -0700 From: Ashish Singh User-Agent: Thunderbird 1.5.0.9 (X11/20061206) MIME-Version: 1.0 To: Mithuna Moorthy Subject: Re: [Megaco] Order of terminations during the conext modification References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: megaco@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Media Gateway Control List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: megaco-bounces@ietf.org Hi Mithuna, In Modify command, terminations can be present in any order. Since the commands in a transaction are processed in sequence, So Modify command will be processed in the order, terminations are placed. Thanks Ashish Mithuna Moorthy wrote: > Hi, > > While doing MODIFY command on termination modes in the same > conext,is it important to maintain the > ORDER in which the terminations were created during the call setup? > > Eg: > > If IP/7 is the first termination created for the call and IP/8 is > the second termination, if I > have to modify termination modes then should the commands to be in the > order of IP/7 and IP/8. > > Kindly provide your inputs. > > Thanks, > Mithuna > ------------------------------------------------------------------------ > > _______________________________________________ > 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 ttgn@online.de Sat Jun 30 18:08:19 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4l75-00043q-75 for megaco-archive@lists.ietf.org; Sat, 30 Jun 2007 18:08:19 -0400 Received: from 24-205-120-48.dhcp.hspr.ca.charter.com ([24.205.120.48]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I4l73-0004JF-Vf for megaco-archive@lists.ietf.org; Sat, 30 Jun 2007 18:08:19 -0400 Received: (qmail 18464 invoked from network); Sat, 30 Jun 2007 15:08:59 -0700 Received: from unknown (HELO ozcz) (120.103.73.102) by 24-205-120-48.dhcp.hspr.ca.charter.com with SMTP; Sat, 30 Jun 2007 15:08:59 -0700 Message-ID: <4686D47B.2070207@online.de> Date: Sat, 30 Jun 2007 15:08:59 -0700 From: Daniel P. Vinson User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: megaco-archive@lists.ietf.org Subject: journal_HSIRRSNN.pdf Content-Type: multipart/mixed; boundary="------------030703010202050005010102" X-Spam-Score: 2.3 (++) X-Scan-Signature: 509eeaf340e89c687918a6101c6def35 --------------030703010202050005010102 Content-Type: text/plain; charset=iso-8859-2; format=flowed Content-Transfer-Encoding: 7bit --------------030703010202050005010102 Content-Type: application/pdf; name="journal_HSIRRSNN.pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="journal_HSIRRSNN.pdf" JVBERi0xLjMgCjEgMCBvYmoKPDwKPj4KZW5kb2JqCjIgMCBvYmoKPDwKL1R5cGUgL0NhdGFsb2cK L1BhZ2VzIDMgMCBSCj4+CmVuZG9iagozIDAgb2JqCjw8Ci9UeXBlIC9QYWdlcwovS2lkcyBbIDQg MCBSIF0KL0NvdW50IDEKPj4KZW5kb2JqCjQgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCAz IDAgUgovUmVzb3VyY2VzIDw8Ci9Gb250IDw8IC9GMCA4IDAgUiA+PgovWE9iamVjdCA8PCAvSW0w IDkgMCBSID4+Ci9Qcm9jU2V0IDcgMCBSID4+Ci9NZWRpYUJveCBbMCAwIDQzNSAyMjJdCi9Dcm9w Qm94IFswIDAgNDM1IDIyMl0KL0NvbnRlbnRzIDUgMCBSCi9UaHVtYiAxMiAwIFIKPj4KZW5kb2Jq CjUgMCBvYmoKPDwKL0xlbmd0aCA2IDAgUgo+PgpzdHJlYW0KcQo0MzUgMCAwIDIyMiAwIDAgY20K L0ltMCBEbwpRCmVuZHN0cmVhbQplbmRvYmoKNiAwIG9iagozMQplbmRvYmoKNyAwIG9iagpbIC9Q REYgL1RleHQgL0ltYWdlSSBdCmVuZG9iago4IDAgb2JqCjw8Ci9UeXBlIC9Gb250Ci9TdWJ0eXBl IC9UeXBlMQovTmFtZSAvRjAKL0Jhc2VGb250IC9IZWx2ZXRpY2EKL0VuY29kaW5nIC9NYWNSb21h bkVuY29kaW5nCj4+CmVuZG9iago5IDAgb2JqCjw8Ci9UeXBlIC9YT2JqZWN0Ci9TdWJ0eXBlIC9J bWFnZQovTmFtZSAvSW0wCi9GaWx0ZXIgWyAvTFpXRGVjb2RlIF0KL1dpZHRoIDQzNQovSGVpZ2h0 IDIyMgovQ29sb3JTcGFjZSAxMSAwIFIKL0JpdHNQZXJDb21wb25lbnQgOAovTGVuZ3RoIDEwIDAg Ugo+PgpzdHJlYW0KgAAgUDgkFg0HhEJhULhkNh0PiERiUTikVi0XjEZjUbjkdj0fkEhkUjkklk0n lEplUrlktl0vmExmUzmk1m03nE5nU7nk9n0/oFBoVDolFo1HpFJpVLplNp1PqFRqVTqlVq1XrFZr UbV0LRE/d0FYMFQQTrc9sqvCIiV1dIZENqJRARs9WtldhIdmqKhJDslkQU7tqvCY3rAiQSvtVtAA it9xRAHgd6gl8G0FsMNOdtOZzmFtxxEh1mjGegiMk9qAGMhGommUg5tv0DvEMEURG2zhWuiCJzqu wmGq2Bg21gVfgW8gSvAGkgaJhyKzau00uu+OhzIjPVgW3hSICQdvSPggTRBt2UMsu02uQuhfmuwg 3o3XkgZzKXEgvGhoTy6FvgiMAoG5yqCkg7+OggQvt4RDAkU4QAEQ7iGQog7fua5wJAADpFGQviBv OVo2uQhz+QlCUGMpBxXQg/6KO854AOU2pERs8MOoGcRxHdEQ2oW/SBLwIYhnEuQIq+5TVoJGw5kS zLvukV0YoWCbzK/DaEK/EaBH4ghBPwgoIs47CNrGiMlOYhZxABHo2laopBPyQT9OvIjnERBk2kRM 8IAANszofEAAO5NiBN8zbFOE8DxQ9EB3Tc9ECoXKlDsjPJGL1Pk6T8gi5GDPiGP5NkqOrCMOIJCk foVILGu7JjJQGgUg0BCa5IEsZHmCL8vAAV8bSk40dhERkBuAV4bxtEqDMy9AAVbZ6CrU68mQXTKB 04g8+VC+wAQ/X9loNYgvwUgdTvkOceUiyrNkY/TiWmmRBFdOaBrW6kyoE99UXLCEDojEsqUNGaBN NNRBWW7QANEglVoauiCgnctXVwg7pCkRAO1ChTNhEzt0gBibqzUgUsoEZA5iJSBEN0hE5hECbVUJ iMUufQKDX/PgO11XlvP2+8dkTYjXO4OdoIHKER0naKDYggpEgnJAvhEyhgzAgz8YznUFn4ZBkXAh Wht8geSABk1vO43RXn4UDNg64k6ZheKYSU5chP4s1MTayqJxLYSB6Ju2Z74AAviHHuWIhsqBZbws QoPm8UIVYOPgBgeQ7IwmjYSRXDcQhd6TotMhae4+kIKG4pCHUDTVAgj4YVC6C8DVK+oJLnZoPxbn uc5VoWXG2K2qhhGbHX3h5OgsS0m3k6XsmMT6Y1buQU5DYTB2KH5JoqBu9BS8Um2ARCIQUkcbViDc bEsoYagr5W0grPYdgkhMUCcKUGh1WuJKghtIkgxq6BkOpRIwpcJX1eoIM6G1Iz3maEIUq/N0hBmj nNdeQRyLknHgAEenlrrXyEwSe+l9wjzyBBtZi2wzZA1/uCJe0t6T00ZAAMk/QRBYUWkRdi/k6qCn aGEIIll964X0M/IJDV+j0oWqHK8z87hvFEuaIIB0ZAHRGL5IS/tfRnBXJEIGrEv5A0SECiWqhWUG jOLpSMckghiiEpKZaPwA4ExXRagm4whMRIJJnPEphrpCUKO0YLFN7J+mlNrjmbQmwihXiuEYu47S rTauNPgIxKEOSFHygSss2qhjXL/fs5tLIEhHgdfG+Uh60G8PdksIlQIoCCxlIM4s25nWgiCk/FF+ 8U5SSmVFGEAC9y3IEhuWJeYihQBSVWhRTSvGuivlhHd2bxQpKJISt10yIR+SMP4IIxDMo8EIfZGQ gjGJsmajUImXE5ECRBA7L18ZA3zuAJtNsCYzJcFdXCbWM5YVKoWeUxpvRyxECKEEMwthAnLuSK65 o7gEmvAijOQkVwyEHJUUqgVYjNwDiKCkOIL4yHokEeyAAZjBV0o/OIuGGBImJtIQmZJf9JTkR+kL Qg6kTwJCIQPSMi83o7GYo2xOj1IKRM5a0nkhcti4ohmqsd3rhaIPZZYegRLZYKlAVaWGA5DKkrSo Kcyn0gyNyQQcRejoE6QEMgTC4g4jKeHTd2TOM8GZZltOoTGIiexGASciIqtR8D9KgoERSuNDYNpa CHVYglYy6kWlkVWndT7H2VPvZavVmLNF1pbZsnk87PWhtFaMite7SWntQRU9A4gJ1ZIi2ciVbSQW utTbW2yWjzwMAnbIilsE0EIjTQsiVE7b3FuMtiB6WgAA3bmQd96WknDuMpXAL4go/xfOnLZWZx5d rYEEhBcM47j3jtvcSGgN2jPNEQKBrw/EYp3OglA+R+gh0WuiWOKyebrQlu2yGbwEl3GmSswi8FJL yYHuLXa1o/L0CuMpa0gjEBEGOf8IkODp7kECReQJKFvoNVkZCuWmrqCCTYwRie0dJaFRGVbAY8q5 Wbm8mjc4g8koxGnIExpKzwYg4ox9aPE0J3439IGfajJk4SPJnE/Cxs9LnCIx3bTH+Uy64ecbNFJS IGnThb3k5wZA1BmwRLRYcSwDqvRlWQO82VM2FXSUXRcKvVWnIeyvlib1xBIfZYoFPl0jlZkx5iCx orh+U7SseXNuiSthDC/KRrxdHzSHIEpM4mjzEUGOek8YIHbpLYDmIoRUBwO12IOpVbAzNCrhxnor VhVdGSkW6+ZZxDNLYfETpoAGpNW6715r3X2v9gbB2FsPYmxdjbH2RsnZWy9mbN2ds/aG0dpbT2pt Xa219sbZ21tvbm3dvbf3BuHcW49ybl3NufdG6d1br2a5HKRLrWzIs7uzdQOyC6mIRQBVm+CIg3tb eslW8yQ2m3oSwOaDjOsIIfqsiejCBjIy2d/fu7z+krAiyQxJikPN+jqCKbb3ch6Cy+c3gnBSUmdH cmBoxD4iMKAjAB7s9jTCJCIfBDz2RQCICIu5siVw5pqRAEMRGKtS8hIYqchdiw2gi34Q+tqEzFaf diyg0HH4Y5fVahTgXJiTU+p6nQ7m/sCHOa8Irl/MOl8ejmZ4wJfi9Oxu/znRhxOLgTC+29goB0Pi CpCQSOXSOmXeIdSw5tU17MsRH4EiggmJ5rjOr0G6dUYvOOPS8OfW+uEj6aImp/YEQ9i4Bw92LEIJ FmK7zTmxA7ZKyd3p/NRBO1LilrvrGhBBQGElw15fW9yKxngkQRxp3gb+RAAEPxRxzA8rax5k6xbD OvKYnnMg7Z2IBDRHN7j/M8cr2vdMjnWESDP5WhbwxtCeWPKfyZTiJFmGNkDb3c/lBgvoMNYXwwxt 1K8IIRxT5hH+mPnJgMiJztECDGWBxAbPsILGmEBuIB+GEOcsko2kgNSvjuKwIo2AAH8iLlwuLu+F wu9qBmfBQPiKJuCP+P+iOrQORklopnZGmiDlJjdOiIZmmLHETjsQKiFqTwCJ2mfQLkMiHOGKsoal fvYCBDhJ/uDrgQUCVumj+EKEIjnK5uXkbA2j/lJlykPwGlKmELrE1LnojFzGAumjaGEPnwBnBhHh HhFADwqGIvMMPw4wJKCLLwMwBqEvlOjQmCTwTJYn4qviBQNF7EkDzwBIYmvQGiDFyD9M1lMDWAAO GQyGCo6mrw0Dqw1Q2P1j1iGrvoLiEGywiwWFzM1EYw8lDrIw9iRFkqJGpvJnSn4gbwwCZlfh3BGL HCJn3xBCMkqEGC5B+BXj9QNE1ElEIozkKOSxUiPwRkHP5xJNiAIj9E8gvkbRfuHncw4lBuslUvaR kw9v1iSxbxuxxRxxyRyxzRztvGjqciIQwGMQ1R0RyJHBkPKDuvnRuCCK1lpGssgx4QUC7hGR5jiA vkoQzlWBmKFuFR+xyEAi8G4Q9EECvwdweyFRxqlQoPeGORDDDGEBXx7yKN6L9DjFWxnRDBEPQSOy PxUxHMMvXiGj+GNQ5yUwmEki8KSs1yHn1SZP+jvRhjuu4EgvzDiiCyESdPmKEJHxaHuhkB+BXPAF Ko6sJjqC8SDsHEbQ4SityEpykCySlvZCyDqE6K8mChmBXNAysPMySSzy1S1y2S2y3S3y4S4y5S5y 6S6y7S7y8S8y9S9y+S+y/S/zATAzBTBzCTCzDTDzETEkvxUTFOTBBLhLixkEJRZCJogCqm6iGLWC oL3GOi4F9ADuUlrppGZpmHQNsLxCDSYCDIkCIDgCQgIr3CZS0lUk4Cnm1k7Djw2lMEViCi/FWzKO RPBlGQZkEBBTgPBizzJCEziCWjFPyLcDEugqzknjJhHkGGTCvyOxHi4pvK4QNkZmvRbjQLFiZqWo JDXNAq1FvLBxkK5juqdnjQjnEDwzmKSI6oWSYiBC4C4nFzlCPDgkejUgDqlTjroiCv5qIADz3CDj fRwiFqRBBGrJZiCv2psqBBEI6i+BxL6kwTqGMmd0EKCJGDpmCkjL/jooOiDBkEnoPrHGPEpzPCYo K0KnHE9i9BXhkDSKLGQzUHlFCDOEvliBET4nwzWw6tJrGjQjIFrNOGMiGjxTrEAi+EbADjqn5J1E qDBjC0AlUUjjPUNxaopkwD8sIlqE/kjwQroKX0oqIRdEtT4rlkJFGHax8Dkmuo6u8QeFXvwIkm7U dImH30pGyjjPf0HkPTVnLz6zezZOMstjHi5UBvtivkHiBnWCGkbTtSxCDFyjgllIdSWIYkEjjkVS zI80oP5lvJGVMDTGP0TRS0fGzHkH7j6E9DVpHUxl4DFjQGFkmSb0jxPCJGJjCllDwrEshUasvRDE pjnjkVSEbVKPipBh3LCUQMlVfyPGLPlu/CF1dVl0ZE6GYvYVHkSjUEbUbwWiGxQo7hW0sFio20t1 SiFoEr5vYTx0aVfCFCwrrxAkhDuD9KXlFsSkdECjMsTF/sbScqvCDx+CGvWECmTUUtJjkHGpuyhV jkUlM1zHjgAD/ivknmNUoEuiCoeRcCDFJuSi0phCZRUDTEixPDMj9DczlQNC8JbIGooVYH9JFVQV bA5sKHkCGrpGdDyIzjkFRyWwelllBqFlVznk6DFExiulKxvwCvaiJEaWcwfHLCBza2eJVDPIvPdo KQjnTN9Wi06WtiHLnqF2UNBl5QlnGE8PttcxAjDFANaOQlCxSoolkiFn2DnDuIlnFmWzWKllPmtn IjkFVVk2NlljYXFurrvWUjbjjFbiGVClA18QjVfsP1DmQWL1+JykEGKTczdnhEQEflbFt1K2sqcg 51CiELfWmFWVwLmiXoKn+n/nSxKk/xkLZEQGPWbGRIoiGH2GHG2sHF5oWmYl72fQeRJH8luFpXQ0 jmxEMQFW52tJw0igALIl8L4CFl/IxkmNNldCHGgliORH8XtPEIUG1ww16utGpIHXRQMmsjYMTJaS CqlmEVi3OWuv9pvCzWqCVF3HQvKOIjZlJiwpxwVEF2c3XW0uGnbvbF2xRDmlpkEgJ0B1fHWGMHXR cxLEvpHz4nNX+jKKaIToU3kEhE5xN1bDsKXoKF/Hz2NCHJ0jiKXnw1DkmPrIULG4DJZTZiWH73+i nXk4Dq3VonMQWqXzGQ0T/CIJTnzCMmoYCEmGUEDlNCCsXMmiGYTVYw7U+E/4VrGmXicE0zUiHm3F 5y/DHJUTG4445CaJ145vmT7iGHDCITICpQT0ZOeCiR74ojPxXiV5BiWO+CIYnin5DoXp8RbCLYZC TH7xuYriUsPCCSJXQKeCESrwMut4/CNhBJElZmux6CEiwp3q/FsK0x80HiC5NGACVFQLpZRiyApN cCGSyCu3PxPjmtPukCFokHm1wMtjHGoKXoMkCoWjM00qwyySXDmLuiDkAnG5hrrR5iRUemyZNHLz vVspU3CiDzniSLdoapcM8qLvVROlPVporZVkJBXZWiGrZHtp0o2Kns0iMi1QHU3GShgkn0MHXx55 cBgtdGyEpqclDJcK4F/jgMdrAMkITVtsiKLjEmIP5OhGJMcq+6AEoPxVKh3MAKB0FKw1vJADajzM 1Dw2iQ0IE50KLF4AAZ+5QnIXwpG3OQYDzLAHrEFgv5LEQqgJgnX6NZJCPFekKD9TbmImJmz0HU7E QkQLgqmgRT4USFnqClkwGWgakTjPYC0r3RkQwKF5tswIJuZr/0h1bISmzqJutjSMjk25VTVWN1rE OEoEAqS5Y1Now6taWOXESzNQYFZoUgRKzvimJFIDJ1zDjUODPaykUBXwdoepvJZt/lO6/v5mnLdD ivcDEE8JvAiMK5y0kU9aZ1FscVjCGjeGSWj7K2d7L2+iBJsFlrWu146urraMPQsWFQWKACvxj2kV kE/rdH97PDiZyUuwLlZGbjkGu6SpGImwCP0luj9H54il3E1DEFqsKbEiwq+0LjiLAuEajGyDliup Op1ZOiDTRVkLV72av2eZPCKFDXCnFnF0aD5ZDk9Zsjl5drtPLQf7lahjy6XkCJvBQIUiFsPQNSPF DE1C8BxTuaq4mSWGEkmLVkCzjaH7X0Fsu10MVwaDT5TMy5/GS0hjpjSFwjYafkJGHO/mjAOyGveK t8B0uvxR76lZoFPb10DiCJxvfyRvVbDbQ4HCNFVqg2yXNsMMObzWG7TswUqo0k/rk3sVknGnLmRt /wR8PblEoT+7e6pFCKU0sQ4jnFTsgvfjuMIU48l8P1jECqAXNPYK4H7yyxDDlC/TWcNMHkxQ5a5M AUm4lRkHs0qiC3YIiOS81JgFpkbIsCN3jNJ5Rr0bcCBOGFwsL7F1nvBrq2gOQbU7S1gc3gAYAcBW /J3jxLvLADc1FYujPXKjArYDnP02qnUL01wdLL27DFllyksllFOW5QCrqmuzJTf9QmamkcW2B9Jv lMW3SCCA4LpEcDkdnCFZ6yMY1L+5g9Pc27CRrCSKqcDsGc1sCHYlwqXmNdto8yhszcZ9QINbxMDH 2rnVwSE9Tt3UcD/Z6WRjVmPJcaqWcrvt/Ahq+iC5xLlm3HpObi16mdosxRYjAnYtSRpV9iEqXles okIFJoMoUL9jTdnYE8Kn3CCAbXYbhQ4oKh+MdDScTZxdx3kxgtLZGiHJseDiybLiUmEEmzRkqeVj kN/TrhH9wjW96jPq8cqCveNU+3IiKmJdMiSoJaUkr9urfm+OIedBBC/enLpFA50BXvvEAYIK8N8e VESrTFd5Rs4ztIY+F6aiGtHBgnyCmsdPbAJ+CIOIjyZOIddkCNbtOlsG3iu8TKlkpoViKhke45bC aNHTj47fHfH/IRkuhtWeGfIkxOXiRTMOhLNL1+7c50H6gCTesNCCv+ZiM7ICRLZEgtGwCzyTUzMC juIRvm2CM/GrKwHjzfPiIgh5kEoNNv5/TKluDuECzfbCP7yiSOtVemmnEmsGj1FCeRv33iLNN53E Bu9fBiKvLmtCekCqlCFKXllrvqSu+febEkJfrU8kPtGfg2s/2iLb53u1YBGQHBxN33eSTTkCH/oH J36iGCAIpXnNXHMAQeEQmFQuEMiGQ9EhNXoJFQlBIhBF8hwh3MFER0OwhXIqHQkpIhgsGQw+WRY5 hNEB1EQhEKCYF+WzmdTuFjeFTOGhGhUA2wqDQhXyOFRWEokAUCETg5gdkIohl9Hzyc0eDhMATIb1 6uogvhKVzQhq02uKfu6Iq+c05Eu5EXCEoip1WEIKFBKnkNGPxBOK2TmMMynzKaIqxQsIwt+YyFUm SMjHwdBCIiRGkQcOl+cQeS5ieIiBMyCgCvFI5oioTNEWG+Quswq1YWaW6JUqD4JFZkiXeHgeEo9B FJEyl3QeZ4HB1qESsJxfGWTodfsVCDz7PI/LUMAG2iwfJQrZ3uGXTXSqcXao9iGFKEy+Ua6vTUb2 SzQihkPxBEhAJta3T3IYIaIrm1y7leV6qKYjCEGC5btAA3CWJmvivGCvaaoey6EhEyKFIkihkNGj ARQOsTXJQz6gOImj4Jml5EtZBTVPqRDpoWs6EP88aEK40iGQAjiHwK0MIuYsjnQsh7XEE+jmJ++E qp1HoAKYAC/ISy8gH4hjGt6hkElfFqngOvMtSsg6nL2xEYvOg8uABD6DyBNbVJazThIe0bRw3LZG EQwDBJ0gzDqfKiGTshMwIXMSGNe9zQyFJKcsI00zAAOchKAZkxUjLaHyArqWMs305TchcYSHJVBI snMbMPFcdOpNlcIY7kYoOL5GA6R5FAOy4vqKNsioVVaD0ajdROYgRBL0prluvMUKJm6bTPzJNhKH S5+APARBGDZSFzkAFqM8L9NPOL6HDnNx3AlQdfUelr5UVTjzIfPKEWQprIBEjA2o2g90q+8k+pyw VMt/fMg1dKaFUuhOKVahSqVRgSEsbArtTzeKFXsiCXJpWzTVzlKDyEADzgmCdfqrVq+VLgCE1Qih QJnBBEH4u0sNGg7kOxTyFJDk5FLChNugjCCDxDcI5ouluQJo9jXUtltXuhNygZZZwAaChOazahWc EVnSEXLiWw36hhGLvRCFXxa9ISfkVk4jQ21AmROeoPq6gbFfFAoRuCW77WbZ7rlVc08xtdoW12ya kDpE4Kg5HgifmNoOIe+kFR+rkUOcC5blidzllifQohMsKhsk9xGzrFruIbRncDt5EZf6WUjxkeVI hizldLK7lBAKGXX0hX7Eh4v9CwZxINqe1SX1y76SCd8S6hUQtjyvPFcA5Fc1kYAc/VcW3Wg/mkVQ hkNng4AYpMMa7lTgbplW3G1zKIcwbkeaWWE6bryGEDIu/MrTgWVHae4ysABHmTkWA6zIoRCD/j8Z 8wshTmGfPreAwZ3S8ydssKhAE+zHICtBcmeI8xHwhkbNMzgqDmGJoKdMSxepfHitSawS9lZF3/uR Oo0ohDTDtIhZ8kIIat1Gk8fcdZsqIErQAgk/1XMP3InkLCFJw8WIwN3esfMzx9lzq/WCxc8Kx29q ng6o5Mxy36q4XOeeAD+yExdV+l0A4iIXHmXIXt8pDlkQ2SMxBKr1EoEIPkRcvBPI0wXjCTxlkX5J yXkxJmTUm5OSdkwR8YK641HQeKmST0p5USplVKuVkrZXIBf0uc67vXkyvltLdNgggJG1bHH+XEv5 gRgi3KmWkEDoE2ClLpYKdZgzNk0dNOhNJfScEUK4VwggOkqmdM2a4gjUq5fPNsnTaGXy6IdKMycp VcQ5IelicUYZZJ3lOR4gk2IFS4ESDeQcrxEkEFcIib6bJLTvJ4mJ5xChQTsOxPE9NBISlGY4TE2L s1JHQRMBEEVDCdSGjyABFIIpikLlKlIrpF3kNgJ05c2JlZXJOnUdBppaaPJsdalWj9IFcvIIaABY ckosCvJglFjwQxEDIKPO5fynTWkJHFP0gkt1zlcSiTAsDHEPHQMrRh+RgEbktpqdsG5mQv04MwRh Tp85/1TNgbKcic3uk5XPQeU6TkA0SO4RV7cuj+H9j+yOuJlqMkJoGYYg81yz1hBFWMEVLz4Jrl2M inqdqQThOuBEV5+ZvNLUI1hrSsaPWLU69UOZhKnWMlW16KdnVeEHp0Y5KyAG0CICIIwQTa2zFWqK UtyKRalVmSFU9UyPSoJyifSIpbYSE2tAAU6yxMCkBzJIlqo6IqHrmPpVWk1eUuJrplTMkTrqs2BZ 1bO2pP3SkDR9UWepK4t0hK0nKvR/Gx1kIUEQHYHSSE7oUzcAE6mknckMUdljqJVYCbZN267CiFXF h1fii9qmIkMJJZtvDFWn0QkRBA7R54HtuKNNdZTQU1xCssfllqDBX4TOZNYzN1CtkMXOti+Boo33 emMr17yWWdFXTkfkjGKL0noSyDexEc1qkmwWQuWltSr4OJ1cXFIyMKPFxalqxNIARVndPD622BUh x2wRc7IRC8PJkCIF/BxDjfXjUOSx3qRaQVKHcqpSFdjG0GhLiA4LxsxgAtpVZCifyuWUXMQyxhIY tr4l4xJUqYs9kMuU7TSSa7/ZEMzRw67kVIr9bJYzMpCJwoMugVUjdRprHmpvlkvdoREZdlRD0QRf CuQPbsQyuWMGbklzWoQnM6LCr7s/aBqWCmV1UY/fy97l2EagITIYuGaBBINKme9fzqSGQmYeqZUd eyDitISxfVzblGnuoPm9XGx9kEJ29h/JmRm87aTkXpd1maO7XUXK60BT0otqNZN06JsUdl7EYibT 5Ira5nvxcjYhC792MwAS2WVajFNsEFYMyDeVLp2QoY8Nq6xXaiR80RKmtCvJYp1xXgkkobV+bNn3 l1/tDNQ0sQqgJO7hctxruwROZydLrEFZbFeor8wyEZqesGsQhrIU7b6jUqFkIUfvNcmj+0xBSAmW bW/NMmMIGQ+YETaCc8ffeg5wxCjuapsY6jWKoKJVldJ1YnTvS+Q20W2k9F++C7XNa/8vnUe17ZYf 1eCszC/lqxbwZy+aEtL2KguUs9XxXIhaTkq01XrPEImif3dbCdmupESnIDvYqeZ8z90YAGlkUnz7 3gSh0m6LxtQvtFBhVCd5XvoSyxjhSLnE1pjDySAni+JgqiYmjOlfNTssRlp2NGiGtoBvyeu2uXKS CGOIG2Nr+7tS6YJDtZefkTSTftPd7lcFCpio4xk9dXHYbF5X1v75Uz1EEMype2fWaoZeY34XCqZi gBuKuP4/AR618/gc27k8+6A/gK6ZeuBAVAdAeJanqkeSWWy7yOw0JAhAzA1A3A4k0jMjCwZA7BFB HBJBKlY0WnEIo/FBMlWInBK/8IwNA/IJacKfaJ296lW3dBYiw1jAsJahigrB8OuMi0icadMTWz+Z Ug28s/gGRBgsSNCIKh8nUXKqOuOJ0pQlRB0JYGYHEqQmA6K/uZS6a7icuCJCCjARC6yK0MKKgTy0 WH44tDETZBWmC4so9CkiEbYSGHESS+WIeH4AkR0mSpoZ7BcSrDIIeDnC6oIHcegkoUW/kdQq+J4s YNGAiIo8mJoZ8EEhsNaGQbgQpDuOuTgLOIoOKJ3CyIeUHEoIPFGmc/cd6a8Kg6kIPD6KfFUTrEDE GISKS6256NdE4sI2QJnBlBmIUTgeyIHBwVyi3AwIUoGmvBijIjIESn6wQooSqoUO8AiEVG8O4XXE NE6Mw6XFAXO/cOuKOSSJgS0S05+Ua1iAmBuKSewABG4YmfYJ+f+/4EQto9MmCII4GTkfmNmIKZ3A aQqzQK0nDHkIGoy/WgOJydMcOEErCC+HcvoEEzm5qu+hVBUDnGYkYZbIaIUvupY84tWJyYPIFIqI yJEqkeKhC8A0yX5CuYocXFQwwItIu9vCYNwK9FOAAe4egUamSEFJIIQvszSieoGDa9W/q2jEcyzH Q3wms4GYqsVCkNIbkZYroJaiejqJ0LJHDDINnCiMwTkt4h8m87U3uxuIerzKOIkbUCHJM+Iz4KBF awUsYTknUa8IvGu0OTYMa1iTcSwQeMmYilk7lBisUSqKBFOZYnioZLqp2Ym2AOYKPGimcyMIzKyS MIK76ISFdEYJ5LAxyao+NFYJycOWoKObFLPNGuMdc4BBUMMO0V2riIORgp1Fe8uU4FdJYt21gsKy 4y02pEQSCsCAAB2YwtYwqSiI+n6IXJvNQOxFMIFMuIXGYxCclMSZtHMFfEdEStOIeO4znGolLFoL 5NKJ0SAS41pDnCRDIJKLsSKoGNC7kIWZYzRNrL0miT0sKyZJMWW85C27KX9KsfiXOQAqkUwgPDmw ilKkMMuaqZaSjI0oqZu1jIsnuJ2UueqIRBRD3N+0hMwYMMxPCikmCq+Xa6Uy+ZWK5Paq9HeUeQpF UfItiV8rgS2anNiyFFlP2IVK8JafOjtIfKUxpRzJmT8ws/HL9LZRC31C6YpOyJ1PiTbKVJPG9NUK AozQwdaQoWi1jGmPgScXPRGYfLSJZRy7s/sNnQiqgTMV8uBIHTgwwXLGSMMDaQ+NdKNHkJ1TafQK 2FcKy2itQ3qfmdRTzD6qqJzHglqIWwfS5EqLvTo8i1wLvSjNG7XTPL0OZT+iMuW4QTXS414OYoyL wXHREAlUPI6VzT1QCU4CkBuEfBREEEREIwyMdUEMwPzVSKPGuEfVam3VbTm3pNgwvNk8BPJFWVtW bHSzHLCZaegpA5rOMITSo4m4hGyLC/U3TAsLcIIROehH+lVWfFyJYi2POFcGRWMJEmvQWSsXOV3G WBuedDjRuOxHkQgPPGvXdAdP0+wwhBZI1MdNGy4SskNNw+BWgxgXJIRBLX5WAJ0msBEfjB3YzY1Y 3YyZeIxYdY5ZDZFZHZJZLW5ZMOgLFZBZRDTO0JyjwSDTileBFQ8mbJCOgmGk2EQHE8jN8leO5KoZ VaDMelTY/TAsKBEEYEYU21+T6YpU+NQRYIQTSltN9D+f6TzBDZTDGlSJkHEGZaSTYrGkyLFZkTZa GRklSqCIu2GQrbBaVaY4cYMSTI4IZGTU+lTZ8kuUja0K1bwJ1GekupfbDERb+pKU1REEfKI0K9OJ 2dzF4UVS/Kpb0JZLZFraihSJ3EEryYgBEDaLVSujEyE6KIaXaJxJ7dEKAWyZSdjZOioVO2ikmiAV 7ZWNEykJnC+wU4tcCknQYfaNddITHScJaIK38QiaQLgAmkGibb6MMXlF5bXY+RBbhSYyUziXyalc s1kNQEYgEyfXyOmNm+ABEHEmmPjdFFcOZdIiVKxGOwjFwlkNrHeItLkTFdbcrSFbgQog0TldPeuS C1ieLaGIGK8O80weSIJfIKQJIJgI+kY6tD+O04tfcjAQoMRf0HdCSXOSTf+Jpe0POoGIrMkcaNWT EPOBtbfaXU+sUzjIK5oIRVjUebmK6ci83LgClghNGJlhRcIOaX1g2J3eK1i1qaXVtKIMvEGozUA8 iHEFaCJQiqCYFhPhTaY3SfphY1UTrINLYnGX0IqNqKFF2L3HlgSMKSExMK7hwqDVfYHLek6XOKcd 6cPba30X9J6ZYnUmuAkg+L4gQGCO8VxX4dybg1oPPglESUuWQAjNDi5jdR4qtYJfvFce27gL2kdO mNJH61lU1QPcstMspj+vk23gQ8jc/kkaFbXkMWU4jJ3dew22sgRHsfpRrEFLRdeZrZzTVGpRPjeI UOXe4tpgcIPGShyd7HQGYGYEZj2zEIG46ERTSJ4tpkEJCXKWQSxZ8X+6fkW72nVYdafWU2qJbC+K Ad0sFRQX0sKLgsTiCIfQAnkyFF2e2X/bRkhHrQRWy2ISKTlbwKALsJxVuaFhePDGyA6EYRrkq2zI gk8brGvaUEEtarPYxOtJRNnl5cNO8NznQzGkqJ1ItYPYJWWABhjUkL7oDl2IfQ86eXScO5OsKNHJ dkfcZJ0ZFc3V0ABDrhnpmz9SE5cSLGkEUAjTiLsKYKLf2+lBtoGcMSKI+C+XhhxnCKenvovhJfoX RAiv6SJCvVem9mQviOmIEDmYISsPzmkxMxiz7YixhMbU5qAvRXhq5LEGRiOUeUjBXRaLuWosYNDV jESdbNIGYvi0krfJEO2Ou97HPUsSiTgsYzgmvqAJ4fOINQpRI7OPFX4cOciRrks1jSlJSk7ggERO XOlICe89CobNGO/eyItr+ZdI/kCJiQAJ8fnMJOjXEJ1Q4IyYOmsO+3YNKEeEQp8QplyIQPyzmGZG tRJUQkOSxuHV2MxtZq0S7jDVxUjfcfUwiSFPErGJWbEWpWtXbea2WM6ZqMvQAMbc8aVdVuK/mWVt Dk3pkk9jVjQOZXEtMsHMbnnqBqDBTTIuXLFTJM8mbIqI+SiXwUiNmXLpxa4UZumItHkQEhLhxkrj g7DO0ywmtsfpiSmtGqIweABSNtvuLo1hNBLJaNBZDr1ZYlXKPuaKNOOcad7DXAiHEqJmgVw6tV/d rxVwE73Jbx3xUzmywsWm3xxqnx+m2NcV9ndyPZGNNNJgpyZyjylynypyrytyvyxyzy1y3y5y7y9y /zBzDzFzHzJzLzNzPzRzTzVzXzZzbzdzfzhzjzlznzpzrztzvzxzzz1z3z5z7z9z/0B0D0F0H0J0 L0N0P0R0T0V0X0Z0b0d0f0h0j0l0n0p0r0t0v0x0z01030507090/1B1D1F1H1J1L1N1P1R1T1V1 X1Z1b1d1f1h1jY4ICAplbmRzdHJlYW0KZW5kb2JqCjEwIDAgb2JqCjEwMzE4CmVuZG9iagoxMSAw IG9iagpbIC9JbmRleGVkIC9EZXZpY2VSR0IgMjU1IDE0IDAgUiBdCmVuZG9iagoxMiAwIG9iago8 PAovRmlsdGVyIFsgL0xaV0RlY29kZSBdCi9XaWR0aCAxMDYKL0hlaWdodCA1NAovQ29sb3JTcGFj ZSAxMSAwIFIKL0JpdHNQZXJDb21wb25lbnQgOAovTGVuZ3RoIDEzIDAgUgo+PgpzdHJlYW0KgD/g UDgkFg0HhEJhULhkNh0PiERiUTikVi0XjEZjUbjkdj0Dfj9fj+kklfkhj8Lkr9fr+kUslj7k8pmk 1hLFZjJVy1VrBYS1XbCYLqdDreryejgczoeT1erweTyg1NebHajEej3ekDfL7fL3fL4fdje71sUy fD4e9jfcGeDxdrUabJsL3tL4sL5pbrfVjhjzezzetleTwd8sfj6xTpcToeLsebueLwdLqc+Igbvy a5X6zc7pcbmdLna7Paswk+JxV2fElgdse1l10CktgvThdL7vrwwzdbrYbrabrhczia7ebT2ez1dj tdMwgzpeDsfOKgb42PYe8JbLgbKoXi2dDueEDkvVfPom0NVi4Vy4YC5UqoS6ZUKSZLKZiuUarUxU FqUxZl4bJvm8gx6OUV5eFobTjHQd5zl+ZhfEiVpPF4X5hlWTRaGIXpnFIUZPmEZJgrceJ3F8X5aK KdZWFgWxfFeXBLkwUbunGZhpmqXhbmKejAIGa5umoV5gFUWBgFY4hvmaa5pk0S5RmSXZllOWJWlC UJOHed52oGaRsmoUJWFGWJcFYXJhF0TpQlQbptm6bM6GKZZlkqU5SGOYJoF8VpgFoWJelUWpVm8c htFeXxUGWY5hFMXRblUVpYrUfB2UyYJhlwXRelqbhxm6aBsGiZ5pGgTxSEmdZ2HUXximOaBhmSW5 fF6zR4GiaxrlkUxdmSXpmlET5YnGch0IGZxkmJLBVGUbBrNGdZ0HKdBYlyWtNl6aJrmuUhVFGapq GiWRclsbBsmumhaF2XdblyYBgl+X5lFwaBsmmYZhmQYMZFWVxZGsbRttemTvHCYhgGQX5jGOXZlF 0ZZpGOYhlmGVRflwURalgYxbmCUBFkwW5aFqgzJngX2Vsq4pyG+aBrGyZRgmIaxpmwXJjGQYFYnT VqBmybZvGCZZgFGXhPlkYcaF+W4nDyM5WGAXBbFGXRXk6U57nueyBm+cZvGSZ5lGEYxhFUWJQFqX pbFkWpeHCbxwlSWJZkGSpJlrFZuGqbxZlIWT4mEZRpGWOhKjWVRcFPDJd6uWCwHxFJ3nSchzGubR qGybBtlSWBWnadx2F08JwHEcBjmcZp1HKcxkVochxHMYCclqXJfFWUG7jeQ5qmibKBmabZlFSXJU R+XhamPYRpGmWpPltThgFvjQ6EKP+FmGZppGZFyaHQypuOQwx4MUfKonhrp7WqdB5/edsvJWkJsG kbZyHCchsuGZZomaPAyJdxsjjZgN0a48YEDlG6OQww7zUl3HgO4d4zhlDOHqkF85ZnJpeRSPEbQ3 xyDNXIXcgY9CkFOHqOYdg5hwDpG+Ogc45hTC1FYMUaYyh9j4H0WUe5sx/mINQSc5Q9XzmCHsTIfh zR3GNHOO2Jxyx7jpHMOocQ3RxDxHmPIZA0RhxNWsOYpY7R1EwJYS4kJqTFD7HoU4xA6YpD1OWbwe JLxsjSGsOhZA34wDMGkM8cQ4xyjQGUNQ5R2yBDwKfC03A7h2jCGkMlUI4i5DUHWOQdSmR2DSGuNA qA8R6JBPWOQco4xZC/FiNwcA4B2DvHcVEeY1jgOjHYPKLI4hsDfK+V0sZUR5DYG4cMbI3hnjGGUP KLAwhnjBGeNwZw54YDgfwOcdY6hrjbHBE4dw4xwDjPXN2b035vkmJZOAhY3hrwtHQOoZi5BTiyFW p4XTJheoMY0LtNIvBfDcGmN8cQ3xvjKGaM8XgwicITF6jQcLYCgtOGMLZeIuGdjEFMkkQAkBODcG 47Mbw55yUdo9R+kBHxwudF440XAtFPi6FmnYZJzR2jQGWNYWgqRcC3aqMUZw0RditQmMkZgqFCnB HEMIWgxlRDkGErQZo0xpDdHANgsY+l9i8EyJsUA4ZnFFTBSGrlXavVfIKYofUK5ZjwHoq0dR6CTE yHYOmVo8SkNcHaOx8xfS8D5jKWMkZJCDEwJMScfR6SVktrBYWw1h7EWJsVYuxljbHWPshZGyVHa/ xkOgTYkscC7HWsnZ2zxGi+j6GSNQZQyxqDLHsWowQ8i+j7HGOcdQ80ErUmyOIcqXx2Dbn8M2gAz4 tuyHLKkcUTh2DGGgM5ZEMYpjtHWO8dQ6h1jgHCOBrqCSy2pa8QKJE7xgDOGsNs7I9isjukYOUco3 h+F+IQSWXw3aMjhFw2YcRxD9DEXINO59bjHjpHaOiAB0x5DtluOE21n8DEXKcPMUQqRJjFGkMQZC pRRCzFE8AaYmxTCwGUNAa4txXDCFu3sV4rxSCGEcIcS4pxOitFKLEYgvBkiFEAIymouhSCvFkMsZ 4zxUCvFsssZ42VeDMGYM8cI3RrVAEosgcR5iSPjfyZ8Uy5hbipR8LMXQzBlC/mMO+1I+YfF3GgNE aIyBmjJFEKcU434rCcE2JwVAoRPCeFOLAVQqhPjVGsNAU4sxUjaVENccL9x1DmwPocicKBZCzFcN QagzH9jWktecc44BmDQGmMgZI0Rqm+ruLkXIvBQCmFAMcaY0DPjoGovgR4gBNDVGkNXTA0hfDBGA 3IcBqbpDhF0LkWL+xvOwF2aPJt2r0ixF+K/UwyWCDgG1kdQwxRVPGgkPAYZcpdEDNZaXHYzhni3F sLhoY4RaC6GEK8WYtkNDCGIMkZy3hqpqFQNkcI2RqneHKOyjmiN+EOr1HYbW9hpRDckWIfSCR6ys HjekkZLY0pBHqScfcZCQllHxwyNBY7Lj/tkPUdMMC2WWH7k4fxYDbHVh0XiwMOmumtJJa2HxJZ/R 6vMMwZYznXPuHkPa8h5IJGCHul4d8ax59DHeN2BR6t+9LIaOodI5RXCpFQgYbgtRfitGkOEaWTh+ jXb6Uscg0huDZ3SMItQ+umdp7VV3Ng3RHiPEOMkZIxxtjcG2M/TPEqojLGqMmEA3BYK2xWKs8Y6+ 1+H8RN8cQ5BtiPEQIRR4xFDC0GlmQbY1xnSMHSL0YguBWi6UiMcWoqhXiuimOrxPqfVEeqiaMctY h5xYN0V4tV6R9lQS+dMrJkYI8b9X7/4HwfhfD+J8X43x8DEtH65Lw5JeYkr+cQywf0bE/Or4Qglv 1LCvOGeMcZAuhrK8GHQNUU17yDYO9eRLw6R3lcsDc0dcZ31q5s0Nwaw3jHlSIKVEeIxhmhjCuo0i 2Pbh5B3jbJXDUq+jEIkIziTogiQiWB2i3pCvoOKQHCYr0iYC2Dqh9B0J0h0IpmDB9hqBnhri8hvh thxn3h6wFB+irBnjbOGK/PrGuugoJEvB4C5BpiRQGlLhvG5hvHThup/Clh1BwhrBwB1hyhzqMp+h yDfhthqPLjTpxjaCWsgpCGuIYB1oDBvKxCBrZB4wfhrD0pDCPhVhZhWlzBaBlBkhhBMBNhMBdBYn HhOhWMFhYBWBWBbBvIrCBpaB6BRBYBVhaBihXsIBehKBPBJpkBmhABDBLBkBfBmuSEgh5hghehfh qhuHMhwBvhshuBqBMhPBEhghjBiBVhNhUP7BvuSBtBnhthXBLhYBXhUBdBWBbtQBmBchXE/pfBqB UBchbhbhdhih0BxBzk5BwBdhntahehchmvvJ3hXFZBmhJhNhGqHBWBUhUhXnDBoCBrUh7qIBgDDB 4hXBMhWhqhphuIfQOBcRJJzhvhVxcBrBkBphshtBvI9BwBihfhfBaBXBYL5hwhgu5h1h1hzBqvMB ilYhLhEBLBFhHhMBShWBXhQhVhWhKg9hNhXBLSMhZp7POheBmBdhjBkhgKojXh9B+Bew2B4h3h5u rBfnqBhjRvUCBBnNVhBBFA6GCOtiUhchehbheBjBgqAhkCgtzPvBmotnShhm4BeJfhuwwCkI+hrF uhphPBbhNhFBSBCBlhrhlhDBQhKsNhqCuC0jghthkszhdBihfBYD3BmhsBphChIhAj8l6MzBqM9C SPsh/BXl2hCA8hKBdBUBgGhBwL4hfhuPGJNBmhdhchZhWBftwyGhghZBhBjsiBwqEhdBfBeBeF9r 4hdg5hDg+hUBXBPBYPRrvF1iBGuB8E1BdLYB0hohjBrBpBiwqORiBCuh8hbhhhZBiBmBhjuhuhnt HBlBhhqyhBghmBnBjqUBbHxhuhZBdhYDJB3BcBfBWBtOxliBUSXBduvBwBhhnhlhLBRBShlBgBnx jh1JthzIFhuhYBjhWjBitiBSWB9hchcBcwjjghzBtoJB2oEP2iBBmn/BFhLhHpfngiUhxnUBehhh dqsmuB7h1pGOhB2UNxxOdh6CxJdB9inLxEEpWh3B1B4h1CZIch9OLwqh/uJH/Bkk6BsJPB5jmh1H JNUmuB6hzryJABzvrB/BvptnNhtoxMvCzInB4i7CtDAq5h1KzB4wkG5whkvudjYoph0DTBqh0FXG LIulqlWh0K7iQCTppB2DWJCh6B4h6ofCYB1h4h1i3h3oIEgoEB5iiB2DlH2LaIIs9OBuLDsIzqxC 2JxB+wOQZCW1Gh+rQi8C1r0wAppB0rxB60XPlIfC2DWORD0u0LQDdBZRchkVTBfFPLpknD8p0h2B hhYhgBtMOBNBVhVhvhyhwjohxnwrnukBvBlhthlhvIqhmBqhmLYByhnGcJjB5iv0YC8IUJ0h0oLh 6BnhohpJUhwiSh5JWhVBQhYBxpABnR1hgP/OWiBzthaBgBW1gFoFxhnhrBqBVzQhpBsBvB6B3pjC 3o1h6k0BZBrtVhdhfyTE7hjhjyGhp2EhkI7FSRkI3K5ptBzBjNzBtBqjvhYhbsOBnCQCWBhhpBkB ZhkhfLphxhlkrBpzlFWh2Bwo/nlBcBnhoBpBpS+jfBurYB1OFHLB0jJ06lMhtJqpciBhgBmzihsh mukBusdBnQOBdTOI7FQhsKEmhprEDJRJaB5D9WFsyQ+huP0BvvfCHOWluhqD2hbBdNbWLBsBemex 9hvy6hrhsLvJ5hiNgIfBxpfieBZhbhgBeg3hIA2BLhWBJhfnmHthhs4BXl1DhhsDjBq1ZV4hVhbB XqchnA9hEhEBOBSBUwHCvB9hjBYBghxBthxE1hiheWDB1nRCBp0h1G4D5MbBHhPhFBFhIBEhmmbm LMx14C5m/BvhuBShbOphxhwg/BGBChEhKBHzJBhBnBoLjhiBnhnBihoBkhjBnBhmdhohphrhpSdX qBng8g5hBidhbiuD0hVnQBNhWxBBbJ5hUhfBjhfBkBaGTBkhoBmg7hDBBhJBLBKBd2+BahY1SBeB dBfy3hPhAhNBWBQhXjOBfhVXJI4Lsh/hkIKhSMqywhmBhBlhhQOBbzNhkEdhfhYRNTlEiBphu27x QBsnbhZxMhdhJhGhHhOhQBN0oCJBnBeF9BdXrS+hhhlhkJoBxEkhcoYh1I1ueJaGwhyu6hwIfKxL 5vFoYhPhUhTHChjkvK2hzKkHthfhkBl2MEMhWBgpRBzH4jJDeBUw9I+Bp0ihx3GYmBymZBtrjBoi 0h8xwo4FXB3LvlvhYBMhehghb1qUwh3BfqcGqhfnKJAByish7YfobPwhlhjBqtZBpt8h2BeYQhuB tBwBjP/JnB2JPohh7TmBkI8ScB/0XUsR9hukJhmhUTsQloqIQIAB4hghlFZWUUPB1BohmBsBVhSh XxiBeBLBMhThjhchkhcN0w0BcTZXVpALoB2BuG5M6hMh2B3DQBthwhgXCHxhyCShqhnmcl42WBxk sBU3tBpBXhTEM4CofCHshJhBlQd0ZLBzAK5jyEvPYCnJch6jBQZvnIy0iiSvFhyBqhsBrowB0jsC zwITAUiiEjai7aJ6CiXCRS/iDIUC8FLh7nKDUr8jEITVmi0wHQHZ4iC6Lh/OSQKvoPtC8lUBqo0o 5Y7osrrB7ojC8h3XUwnhxjDB5N7BvPpjUikB4UXUiuEOWi1B8pP04y/iXaViKhclaEMhihxFEHqC cMdrYT6BxBxFYhlk6GxBlBlXQBghVBTBbBPhGhQM7hahXhUha6AB7aI6WCCl8Bpj2hZWMWCBpo+S sKcIpB04KhiCi1kyFirBqokIkBehl6yhoBqB3i3hfYfs9IFhzBzhphlhphWhRhRI+BjiDSDBg5hh bBmmYhfVyj0h8hihiBjpeBihhhipnB0hfHCBihehnw+htp1hojhOtHCu7LbHw5bOSXrBnhOsKBfL SLTHnHOzihoRARJBmoTB64Qhh3Uh1heE7haBfhgx1hrBWBThTBoBkBoBXhPBbBt17BdBdBkmZOqz NQohuzmBhpLlkiBDUhS64BQhRRCTRhVlsQaiaKcBmFdhshiCcA9A2BEhPBOBUnShZQhhuH7Brkdh phhRiheF4hMhVRZT1hNk8hBBBBLIwB1hmhtBrIkGUaABqhwhuWmxTGxg+hEhJhDhEBMhhBfhkg6A 5BABehfBdhDhIBHhEhNhNDBi1ixhhhiBh8D5x1xg/A8hGqgBaZmF3N1BKg8hEBfhahZiDBihqBnB XBchaBqhthszuhiDBh8MtBqK2h3Ljhmav1fkeF9hlhRhNhSBA3j7KhkGyWPv/N0hfByFkCQCxw9B Sg5BCg9hKM8BameEzhWhcBfhhPFhzRMhkU1hmBmhlhuwfhdxMhjhnhmhWhUhaA7g1g9BptHRCobR 8Q02BBfBkheBe34hdhiBnSTuBQwGuhHhXBShFBPhJhLs0hDhHhNryDyiUhjBpBlBdhjhjDRB2nkT Gtx1hi0h7xN80DfSYB5JR4zIECllqhuhzC5BsK7pPB5I0DqiX47pLh2BxjnB2EUyaHmbXnWh0hXm r24b62RBkWDn5h+hzxkK4B40jhwhZcy72Bu59SYB5htN3h4LoCDIVEIDeBwrzG3hfDRB1hcBghjw nhyBkhl5fp9JsKknmGdBcBYhfHXByi7hrc0BIhKBPhyjKuSasBuhnJHhWPR8eBihXBghdmQBeH4h 3qlt6Cis1Bcl5hkb2S6hsBqo/hxdPBpn3h5rm18osOnoqVdhm1irXhy+D5tB0aXhzEvrmh2prBwB qLvrWvWL0imioh7B5e12EjhHT2DhlDYh7YvhgyVCCh2EITdBqpWLcB2uNu7Bv7yBShvBqs2Ujp+h sosB4q3B0im0rRPoQByluhtJpB2rArAjquSBohsBtYDBn6AB71PjFIHjqwIC2QHCDBxIqBUhbBSG /BqI3K6CkUw96jNWE2E9S/SIMjACid4h3RPBxq9IdDqjdIEDJoJFohohwMkJZh3aUh/0wh4BMm6v PGanayEB2mBhstU6MfRoyiB0Nh3hcBhhhY0fGeZhsB3rm1+IPxNvywjBqBw7FiAPt9P+CQWDQeEQ mCPR7PReMteL5mMFZsJandDoJls1qMlpNV+v1+MpkNB7vd8QV/StisBkIE2opKI5NpxNKB4PF4QV ns9rq5VLZ1Ol2LZdLxksRdqJVpZDKFDM9ts9XxRULdboxJqBesdlNtuuBtthwQV+WdYL1YKxYLdp sxttxvONstptJ9UqxWrddIRHpthMRlrBXqtoMpnwhtuVtuZ2OWfNBXLJcqNVLVSrVar1dMJbrJdL hbK1w2JsN9tMxhs9crFcK1XLZb7JxOZzqJYrBdMdjblasBfL1KJxRJ1NI96vR5Pt+PuFP9otduM9 oNZarFfSRoNNosdzORvtluNdQJZRt/FwV0ut2KZXrFtOBvotJJ5CIJHKBQpteL9hkqSxBEmUpFkm WJKEMUZGnceR3ufB8IH0fR8mGZRdpcYJmG8ahLFcTRrmqbBVN0c52HUV5TFudJyHYlSWGUYRTE4V RPEWVJJEcTR3HenaCGkbBsE6UxYmoaRtnOcxxNqc61k8UBSkcdB1nOdB2HSYzujGOQ3loWheEyUh UGGZhmIKkR+GGYReFAWBVFwW5cl4VhgmQY5nFiWRbk4UBRD4QpCmKZRmGsapsnmnSEGyuhUlyVZZ GMXZSF2VJbl6XxzvWZhnGkWJQlsXJbF6XZflqYJgl4Y5mmKzhemkZxrM4X1Cm0WpeF4YJhmKa6yH se56lqWhYFMVZYnieJ302YrnnIcRznIcx0Hadh3nKbxzmIYhjGUZRjGOZ5mD8SZCmwbJrrMs5hGM YpkuoTJRlKTRMlaVhUlQYhkF89xYGKYpdlkY5aFAWRRno5MIYOhKQn6cZynSc5ynIeqGnmep5n0f aBQkk58Y3XqUoOex8nxi59HqeR7HfHeFIKfB8nzKR2nqep7pXmp/Hue2THgduOZolZ2HgdZdmMXB rG0bJPFQVhsG8b0XH8dB0HMa5wG9Z5zHGbZyG0axumgaBqHM2xsrqemKZlj5/rOfZ8wmfR+H1oGY 5wdh4nae2OLPuEJLqbp5Ypv55YkeiUHsnOgnSdJkJcnJ5GubZtHYdp27a5yCb1vUTbqeEeoTmp+n 8frmH3lp88kd51nUdpz0wZpsGnwR5dAfszYUkJ1HYdkdnhjB+YKenSpCs8zrPmuEeOguZHqUBRlM lpgNcU5RFcUJgmWYtBmcZFVGLdUQm2guXHyVRTlaYRomcshvmcapobafKCnlv95vgbpufDCXGnb3 Bh1N14zx2juHYOAcY3x5j3HmLsZoth4jzHg+wbAzhvDXH4SEgo7zlDdHKOVv49RyLWHSOYdw7h4Q OR4xhyw/4QjmGaM0ZI5mIQtGaOYdQ5BymPUGNAUotxTDMGqMw7Y1T1jtYOMIZAxDPDGGaMcawqBV C8GkNQbYshYi0GiNQaItRdi5GeMgnoyhljkHGOQd7KVnDibW/gfA0xtjRGmNQbCt1BDKGyMp7o6B yjmGKNEZowRnjNHmO8eI0xkDZWcOp64yBwjhHGOEcg4BcjDF4NUag1hljMGMPAeQ7nkSdIOzIehu RVDdGyNsWYsBXCeE8I4WYwRZCWFUJgYg0RjCjFsJsb46BukqdAMxQQyRkDKFuMIYAvBjC+dUOogo 1mqB7DwIiLYu34rGF+qMo6bzNDPGWMhUYsxbC+FmOEcw3yyDWHKOgcghxHCYEOJ4TreG0jBGMMgV gvBejGGgM8SwkRNCkEkLIWYtBjC8F0MU5I9WWD4HwNcaY1hXiwFKIEPwfkQjUFkLgUorRdCsDqIw PIsBgixjcM8b44hupVHYOtlJCBijQGcLgYguRfq3F8LYY9ARiFHGLN4WgfBFB+VGL8cQ4BwjfPkK sVIqxNCUEgO0dY6Xaj9Hm2aPI5RgLpFSLUWwzxnDRHANwcYy0ijAW3GIcYwxdjHG8NgcbXxsHUGw L0YowRYC+FoKIUYpA+h8D2rsacnrAD/ZEPkXKcRfDBF0NWN43huRtGoMo2o4BojZGkOIdI4hxjqL KQeEY7rFDVGUM0Z4tBfi9cEPVmsIx5DEGONMdTUX8D5GQMwZBGxmyOG/AEdwyBjDEioKQcA5hvCr LUNKCYuxiC2O08Ygg3xujddwOxIw2hFCjEuMaeYxxgDSGMMkazvSCpUHSKcWQqxmrbFmLUVLMh5u JHIjsdoyhoDIKIOkao2hpDhHQN4dbk3dDuZsStQY1BXC+F2N8ctbRkDTHEOEdIxxkjToaNcQQjxF iuFmK8ZYw3rraFkLQVgoz9D2xI6F0BK34j0WOPIdtYByi8hcnUaw7r+zEGE6odY62dzLLINIaw3x lkfMpTYagyxWirFYPGEhCG9MrsCQkaw2IsDOGKr4eqEmSD6YVCgd60stnNYUr0e47ZBHKcNCRkY+ hpWNHXjQhDZh6jvHmPNwNUx5YmHo2aMo7STj2YUwUebpWZj1Hc3YczDoh5NJDCjQ46ZNQNHqPFiW d8UEEOkNsWtNVCjSGEL4XRYBuQBHWN+ktJhuDclJlggs5xxq2GAM8bI1THDnZrop0Tw9FtweGs0d EJB3QoYUOnBOeR6NuGkNAaUKG1uz2WSK5g/0S1Ot1AFMxK3Rt6HcO0eRZBwj7TPouFDGGFDjjG/I eWTyEzBGONAaIyBVirTCKEUY0hpjOswkob43hgjAFrmQdorRdioGbu2gAsRDCMn3P0TIjxPu5HaO lybhB7VRFoLMXwihMH6FkK4iJbhrDPFWKUUI2UgEFYyMMXplBeiuFIK8UAiRNiBFCLMTQuhfC+OY PwgrmhZCwWDMUVNGxiDKFsy4e5BRZjHGGKUXgtpgjIEkJYSAtsMinFCJw2AqxgC7N2MQXrCm9C0G AK5QKaRkjMG+OGoY2hziuFMLMZIxxliXFOKQWKajNim0Ki0gjbx9i0F8Lw6gzRaC6FcLUWYs9EC6 FuLuxg2xbCwFEMoZwwxUi0FQMUZowtni4iOJYTwpRciwVuqEZg0hpClFsKWLwxBV0aFiLMX4rhjj CFbgYuo2T5DcJ0O+RY3VjIO3QQcXYyhkjBX4JATQkRJiTEYq8ZorRZirdYOYYgvhb1GG+LUXIuxn ZFFaLY8onCaCqFQJATImWU/CITQofInRSCrEQIsTEbBsjductqnYuBZDYG0GqeSZkEeEeEYFYFKE 8WGFKEeE0EmikGgFuGGFcHmHsHiIKqcHcFuFeF4FmFiFsG0NKG2pM0GIKGIewFsJa++Gi64P8GGG GhkGAGMGAGOt4haGWywZqR+Gg1YGUGiVyGOF6HEhsLqG4GoGeGmEAD4EIFOOuFiF+FwHOHWHMqiF +GoGcGOfae2GS1IG2jGHEFeFuFamCGIaqG206FoDuDyDiFwns2eGmx8GEGSGUPeFeF6M2F2FwF8G 03yw4GIFu34MmFsEqE+FKEAFSE0F+JaWGFMv6HYvEzyoQ+GIMG2akG0G8wQWgNOGyQmHwf2HUYKH qTSxuYc3oGqHGawcAHUHcHQk0Hk4gHYycc8JWR2yUhIZcbcbigEGoXKcEHoIKJQHuJuE2FKT4cmq eHUHWfehJFegsIIYUqeHac4HiQkbYYvFgHKHOHUGgGubCgEY8zIHcHuZER4HiYybay0dAIKZIgqH 4hKhGHiHYJQoUoUZkHsGiGYGiHVGwGUGqGqg0HIIQveHOGCGwGWR4HeZCV8Y4pSx0ZSZ6HGPkEgE aD+56FY2eYqcIoUx+GsF+F8GGHMHCHOZ6cCd0aAb/EqHCasHCGOGwGqFGFeFezyHm2BGZEjJrJtJ uQgZqWMfkR42fJxJ/KBKCeQYUgCHYYkHnJ9KEH+y2OZKTKVKfKhKjKlKnKpKrKtKvKxKzK1K3K5K 7K9K/LBLDLFLHLJLLLNLPLRLTLVLXLZLbLdLfLhLjLlLnLpLrLtLvKsICAplbmRzdHJlYW0KZW5k b2JqCjEzIDAgb2JqCjgzMTEKZW5kb2JqCjE0IDAgb2JqCjw8Ci9MZW5ndGggMTUgMCBSCj4+CnN0 cmVhbQr////S2JKVFoba/xJ6AOuWqqWHQuERJVP/D6BHJs2cKCh6+gANjxaUahWm5BaRe8E3AgMZ FChsEzcNW13b+IYDcoADgBAZFHovul9FTNoGhN0KnfEyCgVqF2HI8llO9czP+UzfE2BZQhu5iGiT j+xwmYlizJNnN6vJAJ0iTpPuHow7/Z+cV+K3EGsfo/oMFJSVdmEp3pjUp5hyyucGuAWT9AIzkFoV SGqBaA18dCIQCphyM3cKCB6je+iLgaGRFJaURybuXW9Y3tdmWkuIa1Yg3YqX6JK2jA2eF49AqKPW POv9K0hsgydD6YKPce3lkstvKbMC4EAQf1efvwBDlj0uk2h3/+yfQ9Uh00cPudnaKAOOK+POO2Im 2yInHrhlTUzOxUy6ZZCQh2PXlhyxcUW1AHCZz6z89ogfHafYg/QkUbpxCyABnKdkdD6BJbDG27E3 dIDkcXdskJUTaBgIjGnD/nXj/xGKY4XI5ap5q4Yq4/uqx2wiNPy3R2XPT/I5E/Cu9u+/gFNESTjv wuR17Mdxl4/ducPacAo/QFoxeW0hJ2QR5uRkKy6cGvCBkN1IAXTY3y6buZ6m+d8BKlhvTIDTXWe4 wZLmXq3W3z6zKEAoAB9WnNn1QtLUQ/0ts0mthqcUPmmnJcdV+6eTr9DT19HzLW3MIrCe9/ScJKfl 0i6M5231jpK9441ldz01SxQGPkJ0CmUkqVwYRYHAK1TuuDtbrsrta6570CW4BnDNDa8Pgbl0pmPR v6lTf9SnboziyTqtt6ZbMneB633yuIuhyA1bPLO+DnNnYfM7CGHI6ysDmOOp9BYgdQGeZ7kpCIE2 Y77qIs1diS5QxTeyjiPekbvBOrDXWyXY+Y2SIpYUWPrTQxygoKbP8WsGpPkpgovlQ8WWGiC78xlJ hTzfmpXZbdj1DXib3GoH4w4BDZCM89NSie5zReGNjmfJbQFeR242PHyv2Fga4Dwo4Um5bjyMwMZ7 MwtcwZnEigfF6U4zIIuv0GQI6kREEyWOzJPKWVSR1IgKZW5kc3RyZWFtCmVuZG9iagoxNSAwIG9i ago3NjgKZW5kb2JqCnhyZWYKMCAxNgowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAwMDAwMTAgMDAw MDAgbiAKMDAwMDAwMDE4NSAwMDAwMCBuIAowMDAwMDAwMjM0IDAwMDAwIG4gCjAwMDAwMDAyOTMg MDAwMDAgbiAKMDAwMDAwMDQ5NyAwMDAwMCBuIAowMDAwMDAwNTgwIDAwMDAwIG4gCjAwMDAwMDA1 OTggMDAwMDAgbiAKMDAwMDAwMDYzNiAwMDAwMCBuIAowMDAwMDAwNzQ0IDAwMDAwIG4gCjAwMDAw MTEyNDMgMDAwMDAgbiAKMDAwMDAxMTI2NSAwMDAwMCBuIAowMDAwMDExMzE2IDAwMDAwIG4gCjAw MDAwMTk3NjYgMDAwMDAgbiAKMDAwMDAxOTc4NyAwMDAwMCBuIAowMDAwMDIwNjEwIDAwMDAwIG4g CnRyYWlsZXIKPDwKL1NpemUgMTYKL0luZm8gMSAwIFIKL1Jvb3QgMiAwIFIKPj4Kc3RhcnR4cmVm CjIwNjMwCiUlRU9GCg== --------------030703010202050005010102--