From megaco-admin@ietf.org Wed Oct 1 08:43:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10300 for ; Wed, 1 Oct 2003 08:43:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4gJp-0005W6-F2; Wed, 01 Oct 2003 08:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4fXS-0002ZY-Jr for megaco@optimus.ietf.org; Wed, 01 Oct 2003 07:53:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09011 for ; Wed, 1 Oct 2003 07:52:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4fXM-000642-00 for megaco@ietf.org; Wed, 01 Oct 2003 07:52:56 -0400 Received: from mailrelay1.alcatel.de ([194.113.59.75] helo=mailrelay2.alcatel.de) by ietf-mx with esmtp (Exim 4.12) id 1A4fXL-00063m-00 for megaco@ietf.org; Wed, 01 Oct 2003 07:52:55 -0400 Received: from ks.sel.alcatel.de (slsv0d.stgl.sel.alcatel.de [149.204.14.10]) by mailrelay2.alcatel.de (8.12.10/8.12.9) with ESMTP id h91Bn4TC022065; Wed, 1 Oct 2003 13:49:05 +0200 (MET DST) Received: from slssiv ([149.204.245.89] helo=slsdtk.stgl.sel.alcatel.de) by ks.sel.alcatel.de with esmtp (Exim 3.31) id 1A4fWj-0001zs-00; Wed, 01 Oct 2003 13:52:17 +0200 Received: from sls0gf.stgl.sel.alcatel.de ([149.204.201.220] helo=alcatel.de) by slsdtk.stgl.sel.alcatel.de with esmtp (Exim 3.31) id 1A4fWi-0004vD-00; Wed, 01 Oct 2003 13:52:16 +0200 Message-ID: <3F7ABFEE.48753D6F@alcatel.de> Date: Wed, 01 Oct 2003 13:52:14 +0200 From: Thomas Voith X-Mailer: Mozilla 4.77 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en,de MIME-Version: 1.0 To: megaco@ietf.org, tsg16q3@itu.int Content-Type: multipart/mixed; boundary="------------11B76428C1EED84E9C6F850E" X-Alcanet-virus-scanned: h91Bn4TC022065 at mailrelay2.alcatel.de Subject: [Megaco] Event descriptor handling for static logic interfaces like CAS Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------11B76428C1EED84E9C6F850E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear list-members, H.248.26 and in H.248.ICAS I miss a feature, which has been used already for On-Hook, Off-Hook the 'strict' parameter. All interfaces, which have static states, should implement such a mechanism. The problem is that the EventsDescriptor EventBufferDescriptor or an embedded EventsDescriptor may discard events, if the newly received or replacing Event Descriptor does not match the event. In the Megaco Secnarios, always just the good case is shown. e.g. a static interface with 4 logical incoming events ( S1,S2,S3,S4) would then set the EventsDescripror like: MGC guess the MG is in state i1, no Notify will be sent by MG, when state of interface is still i1. Events { S1{strict="exact"},S2{strict="state"},S3{strict="state"},S4{strict="state"} } ( Note: in case "state" is the default, then EventsDescriptor could be shorter) The events descriptor remains active, after Notification is sent. The strict parameter avoids unnecessary Notifications for the already by MGC known state. This mechanism would be very simple and avoids lost of any events, which is strong required for signalling interfaces on MG transferred via H.248 to an MGC. For a better illustration I have attached a Excel-File containing a simple scenario. So my question/proposal is: - Is it possible to extend the existing static state interfacepackages like H.248.26 with this strict feature? - If not, can I get this functionality otherwise ? Kind regards Thomas Voith -- _______________________________________________________________ _ V | Thomas Voith +---------------+ | Dept. VS/EAC2 [Systems] | A L C A T E L | | FL/2/50 +---------------+ | | Tel: +49 711 821-40293 | Alcanet: 259-40293 Alcatel SEL AG | Fax: +49 711 821-40211 Fixed Networks Division | Lorenzstr. 10 | mailto:Thomas.Voith@alcatel.de D-70435 Stuttgart, Germany | _______________________________________________________________ --------------11B76428C1EED84E9C6F850E Content-Type: application/x-xls; name="strict_cases.xls" Content-Disposition: inline; filename="strict_cases.xls" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAAQAAAAAA AAAAEAAAAgAAAAEAAAD+////AAAAAAAAAAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////9////LgAAAP7///8EAAAABQAAAAYAAAAPAAAA CAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAAMAAAAQAAAAEQAAABIAAAATAAAAFAAAABUA AAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAA IwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAALAAAAC0AAAD+////OQAAADAA AAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADoAAAD+////OwAAADwAAAD+//// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////1IA bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAWAAUA//////////8CAAAAIAgCAAAAAADAAAAAAAAARgAAAACAxKlKEIjDAbCT Om8QiMMBLwAAAMAYAAAAAAAAVwBvAHIAawBiAG8AbwBrAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgELAAAA//////////8AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAZVUAAAAAAABfAFYAQgBBAF8AUABSAE8A SgBFAEMAVABfAEMAVQBSAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIgABAQEA AAAJAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoJgJbxCIwwGwkzpvEIjDAQAAAAAAAAAA AAAAAFYAQgBBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAIAAEA//////////8EAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARxRv EIjDAeAPJW8QiMMBAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgA AAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAD+////EwAAABQAAAAVAAAA FgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAAIgAAACMA AAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwAAAAtAAAALgAAAC8AAAAwAAAA MQAAADIAAAAzAAAANAAAADUAAAA2AAAANwAAADgAAAA5AAAAOgAAADsAAAA8AAAAPQAAAD4A AAA/AAAAQAAAAEEAAAD+////QwAAAEQAAABFAAAARgAAAEcAAABIAAAASQAAAEoAAABLAAAA /v////7///9OAAAATwAAAFAAAABRAAAAUgAAAFMAAABUAAAA/v///1YAAABXAAAAWAAAAP7/ //9aAAAAWwAAAFwAAABdAAAAXgAAAF8AAABgAAAA/v///2IAAAD+//////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////8ABBYg 4AAUAAYAAAABABMAABgAAAAAAAAAAMAgkwIEABCAA/+TAgQAEYAG/5MCFgASABEAAENvbW1h IFswXV9mbG93Z2VukwISABMADQAAQ29tbWFfZmxvd2dlbpMCBAAUgAT/kwIEABWAB/+TAhkA FgAUAABDdXJyZW5jeSBbMF1fZmxvd2dlbpMCFQAXABAAAEN1cnJlbmN5X2Zsb3dnZW6TAgQA AIAA/5MCEwAYAA4AAE5vcm1hbF9mbG93Z2VukwIEABmABf9gAQIAAQCFABYAXyQAAAAADgBz dGF0aWNfb25fb2Zfb4UAFAADQQAAAAAMAHN0YXRpY19nZW5fb4wABAABADEArgEEAAIAAQQX ABQAAwAAAP////8AAAEAAQAAAAAAAAAYAB8AAAAACQcAAAAAAAAAAAAAZGVmX3hfYWIxOgAA TwADABgAHwAAAAAJBwAAAAAAAAAAAABkZWZfeF9hYjI6AABRAAMAGAAfAAAAAAkHAAAAAAAA AAAAAGRlZl94X2FiMzoAAFMAAwAYAB8AAAAACQcAAAAAAAAAAAAAZGVmX3hfYWI0OgAAVQAD ABgAHwAAAAAJBwAAAAAAAAAAAABkZWZfeF9hbDE6AAA9AAMAGAAfAAAAAAkHAAAAAAAAAAAA AGRlZl94X2FsMjoAAD8AAwAYAB8AAAAACQcAAAAAAAAAAAAAZGVmX3hfYWwzOgAAQQADABgA HwAAAAAJBwAAAAAAAAAAAABkZWZfeF9hbDQ6AABDAAMAGAAfAAAAAAkHAAAAAAAAAAAAAGRl Zl94X2FyMToAAEYAAwAYAB8AAAAACQcAAAAAAAAAAAAAZGVmX3hfYXIyOgAASAADABgAHwAA AAAJBwAAAAAAAAAAAABkZWZfeF9hcjM6AABKAAMAGAAfAAAAAAkHAAAAAAAAAAAAAGRlZl94 X2FyNDoAAEwAAwAYAB4AAAAACAcAAAAAAAAAAAAAZGVmX3hfdGE6AAA0AAMAGAAeAAAAAAgH AAAAAAAAAAAAAGRlZl94X3RkOgAANgADABgAHgAAAAAIBwAAAAAAAAAAAABkZWZfeF90ZToA ADgAAwAYAB4AAAAACAcAAAAAAAAAAAAAZGVmX3hfdG46AAA6AAMAGAAdAAAAAAcHAAAAAAAA AAAAAGRlZmNtdDE6AAAlAAMAGAAdAAAAAAcHAAAAAAAAAAAAAGRlZmNtdDI6AAAnAAMAGAAd AAAAAAcHAAAAAAAAAAAAAGRlZmNtdDM6AAApAAMAGAAdAAAAAAcHAAAAAAAAAAAAAGRlZmNt dDQ6AAArAAMAGAAgAAAAAAoHAAAAAAAAAAAAAGRlZmNtdGxlZnQ6AAAtAAMAGAAeAAAAAAgH AAAAAAAAAAAAAGRlZmVtcHR5OgAALwADABgAIAAAAAAKBwAAAAAAAAAAAABkZWZlbnRpdHkx OgAAEgADABgAIAAAAAAKBwAAAAAAAAAAAABkZWZlbnRpdHkyOgAAFAADABgAIAAAAAAKBwAA AAAAAAAAAABkZWZlbnRpdHkzOgAAFgADABgAIAAAAAAKBwAAAAAAAAAAAABkZWZlbnRpdHk0 OgAAGAADABgAHwAAAAAJBwAAAAAAAAAAAABkZWZoaWRkZW46AAAiAAMAGAAcAAAAAAYHAAAA AAAAAAAAAGRlZml0ZjoAABcACQAYAB0AAAAABwcAAAAAAAAAAAAAZGVmbXNnMToAABwAAwAY AB0AAAAABwcAAAAAAAAAAAAAZGVmbXNnMjoAAB0AAwAYAB0AAAAABwcAAAAAAAAAAAAAZGVm bXNnMzoAAB4AAwAYAB0AAAAABwcAAAAAAAAAAAAAZGVmbXNnNDoAAB8AAwAYACEAAAAACwcA AAAAAAAAAAAAZGVmcGFyYWxlZnQ6AAAhAAMAGAAiAAAAAAwHAAAAAAAAAAAAAGRlZnBhcmFt ZXRlcjoAACAAAwAYAB4AAAAACAcAAAAAAAAAAAAAZGVmdGl0bGU6AAAQAAMAGAAgAAAAAAoH AAAAAAAAAAAAAGVudF9ib3JkZXI6AAANAAgAGAAjAAAAAA0HAAAAAAAAAAAAAG1zZ2VudGl0 eW5hbWU6AAAFAAQAGAAdAAAAAAcHAAAAAAAAAAAAAG1zZ25hbWU6AAAGAAMAGAAiAAAAAAwH AAAAAAAAAAAAAG9yaWdpbmNvbHVtbjoAAA0AAQAYAB8AAAAACQcAAAAAAAAAAAAAb3JpZ2lu cm93OgAADAABABgAIwAAAAANBwAAAAAAAAAAAABwYXJhX2xldmVsaW5nOgAADAAIABgAJAAA AAAOBwAAAAAAAAAAAABwYXJhX3NtYWxsX2V4dDoAAA4ACAAYACIAAAAADAcAAAAAAAAAAAAA cHJpbnRfZm9ybWF0OgAADAAFABgAJwAAAAARBwAAAAAAAAAAAABwcmludF9vcmllbnRhdGlv bjoAAA0ABQAYABsAIAAAAQsAAAACAAAAAAAABzsBAAIAAgAAAP8AGAAbACAAAAELAAAAAQAA AAAAAAc7AgACAAIAAAD/ABgAIAAAAAAKBwAAAAAAAAAAAABwcmludF93aWRlOgAADgAFABgA IAAAAAAKBwAAAAAAAAAAAAByZXN1bHRjZWxsOgAADwAAABgAIAAAAAAKBwAAAAAAAAAAAABz a2lwX2VtcHR5OgAACwAIABgAHQAAAAAHBwAAAAAAAAAAAABzcGFjaW5nOgAACwkIEAAABgUA 8hXMB8kAAAAGAAAA4QACALAEwQACAAAA4gAAAFwAcAAFAABWb2l0aCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQgACALAEYQECAAAAPQEEAIYA gwDTAAAAvQEAALoBDwAMAABUaGlzV29ya2Jvb2ucAAIADgAZAAIAAAASAAIAAAATAAIAAACv AQIAAAC8AQIAAAA9ABIAaAF4AHRAfyY4AAAAAAABAIoDQAACAAAAjQACAAAAIgACAAAADgAC AAEAtwECAAAA2gACAAAAMQAaAPAAAAD/f5ABAAAAAgAABQFBAHIAaQBhAGwAMQAqANwAAAD/ f5ABAAAAAAAADQFGAHUAdAB1AHIAYQBBACAAQgBrACAAQgBUADEAKgDcAAAA/3+QAQAAAAAA AA0BRgB1AHQAdQByAGEAQQAgAEIAawAgAEIAVAAxACoA3AAAAP9/kAEAAAAAAAANAUYAdQB0 AHUAcgBhAEEAIABCAGsAIABCAFQAMQAcAKAAAABRAJABAAAAAAAABgFUAGEAaABvAG0AYQAx ABoAoAAAAP9/kAEAAAACAAAFAUEAcgBpAGEAbAAxABoAGAEBAP9/vAIAAAACAAAFAUEAcgBp AGEAbAAxABoAyAABAAgAvAIAAAACAAAFAUEAcgBpAGEAbAAxABoAoAAAAAkAkAEAAAACAAAF AUEAcgBpAGEAbAAxABoA8AAAAP9/kAEAAAACAAAFAUEAcgBpAGEAbAAxABoAyAAAAP9/kAEA AAAAAAAFAUEAcgBpAGEAbAAxABoAoAACAAgAkAEAAAACAAAFAUEAcgBpAGEAbAAxABoAoAAA ABIAkAEAAAACAAAFAUEAcgBpAGEAbAAxABoAoAACABIAkAEAAAACAAAFAUEAcgBpAGEAbAAe BDMABQAXAAEjACwAIwAjADAAXAAgACIArCAiADsAXAAtACMALAAjACMAMABcACAAIgCsICIA HgQ9AAYAHAABIwAsACMAIwAwAFwAIAAiAKwgIgA7AFsAUgBlAGQAXQBcAC0AIwAsACMAIwAw AFwAIAAiAKwgIgAeBD8ABwAdAAEjACwAIwAjADAALgAwADAAXAAgACIArCAiADsAXAAtACMA LAAjACMAMAAuADAAMABcACAAIgCsICIAHgRJAAgAIgABIwAsACMAIwAwAC4AMAAwAFwAIAAi AKwgIgA7AFsAUgBlAGQAXQBcAC0AIwAsACMAIwAwAC4AMAAwAFwAIAAiAKwgIgAeBHEAKgA2 AAFfAC0AKgAgACMALAAjACMAMABcACAAIgCsICIAXwAtADsAXAAtACoAIAAjACwAIwAjADAA XAAgACIArCAiAF8ALQA7AF8ALQAqACAAIgAtACIAXAAgACIArCAiAF8ALQA7AF8ALQBAAF8A LQAeBGsAKQAzAAFfAC0AKgAgACMALAAjACMAMABcACAAXwCsIF8ALQA7AFwALQAqACAAIwAs ACMAIwAwAFwAIABfAKwgXwAtADsAXwAtACoAIAAiAC0AIgBcACAAXwCsIF8ALQA7AF8ALQBA AF8ALQAeBIEALAA+AAFfAC0AKgAgACMALAAjACMAMAAuADAAMABcACAAIgCsICIAXwAtADsA XAAtACoAIAAjACwAIwAjADAALgAwADAAXAAgACIArCAiAF8ALQA7AF8ALQAqACAAIgAtACIA PwA/AFwAIAAiAKwgIgBfAC0AOwBfAC0AQABfAC0AHgR7ACsAOwABXwAtACoAIAAjACwAIwAj ADAALgAwADAAXAAgAF8ArCBfAC0AOwBcAC0AKgAgACMALAAjACMAMAAuADAAMABcACAAXwCs IF8ALQA7AF8ALQAqACAAIgAtACIAPwA/AFwAIABfAKwgXwAtADsAXwAtAEAAXwAtAB4EHgCk ABkAACMsIyMwXCAiRE0iO1wtIywjIzBcICJETSIeBCMApQAeAAAjLCMjMFwgIkRNIjtbUmVk XVwtIywjIzBcICJETSIeBCQApgAfAAAjLCMjMC4wMFwgIkRNIjtcLSMsIyMwLjAwXCAiRE0i HgQpAKcAJAAAIywjIzAuMDBcICJETSI7W1JlZF1cLSMsIyMwLjAwXCAiRE0iHgQ+AKgAOQAA Xy0qICMsIyMwXCAiRE0iXy07XC0qICMsIyMwXCAiRE0iXy07Xy0qICItIlwgIkRNIl8tO18t QF8tHgQ+AKkAOQAAXy0qICMsIyMwXCBfRF9NXy07XC0qICMsIyMwXCBfRF9NXy07Xy0qICIt IlwgX0RfTV8tO18tQF8tHgRGAKoAQQAAXy0qICMsIyMwLjAwXCAiRE0iXy07XC0qICMsIyMw LjAwXCAiRE0iXy07Xy0qICItIj8/XCAiRE0iXy07Xy1AXy0eBEYAqwBBAABfLSogIywjIzAu MDBcIF9EX01fLTtcLSogIywjIzAuMDBcIF9EX01fLTtfLSogIi0iPz9cIF9EX01fLTtfLUBf LR4EHACsABcAACMsIyMwXCAiRiI7XC0jLCMjMFwgIkYiHgQhAK0AHAAAIywjIzBcICJGIjtb UmVkXVwtIywjIzBcICJGIh4EIgCuAB0AACMsIyMwLjAwXCAiRiI7XC0jLCMjMC4wMFwgIkYi HgQnAK8AIgAAIywjIzAuMDBcICJGIjtbUmVkXVwtIywjIzAuMDBcICJGIh4EOwCwADYAAF8t KiAjLCMjMFwgIkYiXy07XC0qICMsIyMwXCAiRiJfLTtfLSogIi0iXCAiRiJfLTtfLUBfLR4E OACxADMAAF8tKiAjLCMjMFwgX0ZfLTtcLSogIywjIzBcIF9GXy07Xy0qICItIlwgX0ZfLTtf LUBfLR4EQwCyAD4AAF8tKiAjLCMjMC4wMFwgIkYiXy07XC0qICMsIyMwLjAwXCAiRiJfLTtf LSogIi0iPz9cICJGIl8tO18tQF8tHgRAALMAOwAAXy0qICMsIyMwLjAwXCBfRl8tO1wtKiAj LCMjMC4wMFwgX0ZfLTtfLSogIi0iPz9cIF9GXy07Xy1AXy0eBBwAtAAXAAAiJCIjLCMjMF8p O1woIiQiIywjIzBcKR4EIQC1ABwAACIkIiMsIyMwXyk7W1JlZF1cKCIkIiMsIyMwXCkeBCIA tgAdAAAiJCIjLCMjMC4wMF8pO1woIiQiIywjIzAuMDBcKR4EJwC3ACIAACIkIiMsIyMwLjAw Xyk7W1JlZF1cKCIkIiMsIyMwLjAwXCkeBDcAuAAyAABfKCIkIiogIywjIzBfKTtfKCIkIiog XCgjLCMjMFwpO18oIiQiKiAiLSJfKTtfKEBfKR4EPwC5ADoAAF8oIiQiKiAjLCMjMC4wMF8p O18oIiQiKiBcKCMsIyMwLjAwXCk7XygiJCIqICItIj8/Xyk7XyhAXykeBBgAugATAAAioyIj LCMjMDtcLSKjIiMsIyMwHgQdALsAGAAAIqMiIywjIzA7W1JlZF1cLSKjIiMsIyMwHgQeALwA GQAAIqMiIywjIzAuMDA7XC0ioyIjLCMjMC4wMB4EIwC9AB4AACKjIiMsIyMwLjAwO1tSZWRd XC0ioyIjLCMjMC4wMB4ENQC+ADAAAF8tIqMiKiAjLCMjMF8tO1wtIqMiKiAjLCMjMF8tO18t IqMiKiAiLSJfLTtfLUBfLR4ELAC/ACcAAF8tKiAjLCMjMF8tO1wtKiAjLCMjMF8tO18tKiAi LSJfLTtfLUBfLR4EPQDAADgAAF8tIqMiKiAjLCMjMC4wMF8tO1wtIqMiKiAjLCMjMC4wMF8t O18tIqMiKiAiLSI/P18tO18tQF8tHgQ0AMEALwAAXy0qICMsIyMwLjAwXy07XC0qICMsIyMw LjAwXy07Xy0qICItIj8/Xy07Xy1AXy0eBA8AwgAKAABkZC9tbS95eXl54AAUAAAAAAD1/yAA AAAAAAAAAAAAAMAg4AAUAAEAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAEAAAD1/yAAAPQAAAAA AAAAAMAg4AAUAAIAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAIAAAD1/yAAAPQAAAAAAAAAAMAg 4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAA AAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAA APQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAA AAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg 4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAABACAAAAAAAAAAAAAAAMAg4AAUAAEA KwD1/yAAAPgAAAAAAAAAAMAg4AAUAAEAKQD1/yAAAPgAAAAAAAAAAMAg4AAUAAsAvwD1/yAA APgAAAAAAAAAAMAg4AAUAAsAwQD1/yAAAPgAAAAAAAAAAMAg4AAUAAEALAD1/yAAAPgAAAAA AAAAAMAg4AAUAAEAKgD1/yAAAPgAAAAAAAAAAMAg4AAUAAsAvgD1/yAAAPgAAAAAAAAAAMAg 4AAUAAsAwAD1/yAAAPgAAAAAAAAAAMAg4AAUAAoAAAD1/yEAAAAAAAAAAAAAAMAg4AAUAAEA CQD1/yAAAPgAAAAAAAAAAMAg4AAUAAkAAAABACAAAAgAAAAAAAAAAMAg4AAUAAYAAAABABMA AFgAAAAAAAAAAMAg4AAUAAAAAAABACAAACAQAAAgAAAAAMAg4AAUAAAAAAABACAAACAQAQAg QAAAAMAg4AAUAAcAAACBAQAAAFgAAAAAAAAAAMAg4AAUAAgAAACBARYAAHgREUAgQCAABDEg 4AAUAAgAAACBAR4AAHgREUAgQCAABDEg4AAUAAgAAACBARYAAHgREUAgQCAABCIg4AAUAAYA AACBAQYAABgAAAAAAAAAAMAg4AAUAAwAAACBAQYAABgAAAAAAAAAAMAg4AAUAA0AAACBAQEA AFgAAAAAAAAAAMAg4AAUAAYAAACBAR4AAHgAAAAAAAAABBYg4AAUAA4AAACBAS4AADgiIjgc OBwAAMAg4AAUAA0AAACBAQEAAHgQAAAgAAAAAMAg4AAUAAwAAACBAQYAADgQAAAgAAAAAMAg 4AAUAAYAAACBAQYAADgQAAAgAAAAAMAg4AAUAA4AAACBAS4AADggIgAcOBwAAMAg4AAUAA4A AACBAS4AADgSIjggOBwAAMAg4AAUAAYAAACBAR4AAHgQAAAgAAAABQDrAKoDDwAA8KIDAAAA AAbwaAMAAAGwAQBsAAAAGAAAAAIAAAAAAAAABwAAAAAAAAADAAAAAAAAAAMAAAAAAAAAAwAA AAAAAAADAAAAAAAAAAMAAAAAAAAAAwAAAAAAAAADAAAAAAAAAAMAAAAAAAAAAwAAAAAAAAAD AAAAAAAAAAMAAAAAAAAAAAQAAAAAAAADAAAAAAAAAAMAAAAAAAAABgAAAAAAAAAGAAAAAAAA AA4AAAAAAAAAFQAAAAAAAAAZAAAAAAAAAB8AAAAAAAAAHwAAAAAAAAAbAAAAAAAAABoAAAAA AAAAGwAAAAAAAAAbAAAAAAAAACEAAAAAAAAAIQAAAAAAAAAhAAAAAAAAAAcAAAAAAAAAIQAA AAAAAAAiAAAAAAAAACIAAAAAAAAAIQAAAAAAAAAhAAAAAAAAACEAAAAAAAAAIQAAAAAAAAAh AAAAAAAAACEAAAAAAAAAIgAAAAAAAAAiAAAAAAAAACIAAAAAAAAAIQAAAAAAAAAHAAAAAAAA AAoAAAAAAAAACgAAAAAAAAAJAAAAAAAAAAkAAAAAAAAABwAAAAAAAAAJAAAAAAAAAAoAAAAA AAAACgAAAAAAAAAKAAAAAAAAAAkAAAAAAAAACgAAAAAAAAAHAAAAAAAAABIAAAAAAAAABwAA AAAAAAARAAAAAAAAABQAAAAAAAAAFAAAAAAAAAAhAAAAAAAAACEAAAAAAAAAIQAAAAAAAAAh AAAAAAAAACQCAAAAAAAAIQAAAAAAAAARAAAAAAAAABEAAAAAAAAAEQAAAAAAAAARAAAAAAAA ABQAAAAAAAAACgAAAAAAAAAhAAAAAAAAAAcAAAAAAAAACwAAAAAAAAAKAAAAAAAAAAkAAAAA AAAACQAAAAAAAAAJAAAAAAAAAAkAAAAAAAAABwAAAAAAAAAbAAAAAAAAABsAAAAAAAAAGwAA AAAAAAAbAAAAAAAAABkAAAAAAAAAGQAAAAAAAAAGAAAAAAAAAAgAAAAAAAAACAAAAAAAAAAP AAAAAAAAAA8AAAAAAAAADwAAAAAAAAAPAAAAAAAAAA8AAAAAAAAABwAAAAAAAAAPAAAAAAAA AA8AAAAAAAAADwAAAAAAAAAHAAAAAAAAAAgAAAAAAAAACAAAAAAAAAAIAAAAAAAAAAkAAAAF AAAACQAAAAIAAAAPAAAAMwAL8BIAAAC/AAgACACBAQkAAAjAAUAAAAhAAB7xEAAAAA0AAAgM AAAIFwAACPcAABD8AHgEOQAAACwAAAADAABFbmQLAABSMgpleGNoYW5nZQMAAE1HQwIAAEdX CgAARjE6IE1vZGlmeQoAAEYzOiBOb3RpZnkKAABGOTogTm90aWZ5CwAARjEzOiBOb3RpZnkK AABGNDogTm90aWZ5DAAARjI6IE9mZi1Ib29rCwAARjQ6IE9uLUhvb2svAABEaXNjYXJkZWQs IHNpbmNlIEV2ZW50cyBEZXNjcmlwdG9yIGRvIG5vdCBtYXRjaAwAAEY1OiBPZmYtSG9vawoA AEY2OiBOb3RpZnkUAABPbixPZmYtaG9vayBleGFtcGxlcyUAAENhc2UyOiBnb29kIGFuZCBi YWQgY2FzZXMgd2l0aCBzdHJpY3QVAABDYXNlMTogb25seSBnb29kIGNhc2UeAABFdmVudHMg e2FsL29me3N0cmljdD0ic3RhdGUifX0nAAAyMDAzMDkxOFQxMDMxMDAwMDphbC9vZntpbml0 PSJGYWxzZSJ9IH0QAABPYnNlcnZlZEV2ZW50cyB7NAAARXZlbnRzIHthbC9vZntzdHJpY3Q9 InN0YXRlIn0sYWwvb257c3RyaWN0PSJleGFjdCJ9fScAADIwMDMwOTE4VDEwMzEwMDAwOmFs L29ue2luaXQ9IkZhbHNlIn0gfQoAAEY3OiBNb2RpZnkMAABGODogT2ZmLUhvb2sMAABGMTA6 IE9uLUhvb2sLAABGMTE6IE5vdGlmeQ0AAEYxMjogT2ZmLUhvb2snAAAyMDAzMDkxOFQxMDMy MDAwMDphbC9vZntpbml0PSJGYWxzZSJ9IH0nAAAyMDAzMDkxOFQxMDMzMDAwMDphbC9vZntp bml0PSJGYWxzZSJ9IH0kAAAyMDAzMDkxOFQxMDMxMDAwMDpTMntpbml0PSJGYWxzZSJ9IH0u AABFdmVudHMge1Mxe3N0cmljdD0iZXhhY3QifSxTMntzdHJpY3Q9InN0YXRlIn0sJgAAUzN7 c3RyaWN0PSJzdGF0ZSJ9LFM0e3N0cmljdD0ic3RhdGUifX0pAABJbnRlZmFjZSBoYXMgMyBl dmVudCBzdGF0ZXM6ICBTMSxTMixTMyxTNCQAADIwMDMwOTE4VDEwMzEwMDAwOlM0e2luaXQ9 IkZhbHNlIn0gfQYAAEYxOiBTMQoAAEYyOiBNb2RpZnkGAABGMzogUzIGAABGNTogUzQ2AABN RyBkbyBub3Qgc2VudCBhIE5vdGlmeSwgc2luY2Ugc3RyaWN0PSJleGFjdCIgZm9yIFMxICE+ AABFdmVudCBEZXNjcmlwdG9yIGNhbiBiZSB1cGRhdGVkLCB3aXRob3V0IGFuIHVubmVjZXNz YXJ5IE5vdGlmeS4AAEV2ZW50cyB7UzF7c3RyaWN0PSJzdGF0ZSJ9LFMye3N0cmljdD0ic3Rh dGUifSwmAABTM3tzdHJpY3Q9InN0YXRlIn0sUzR7c3RyaWN0PSJleGFjdCJ9fQYAAC4uLi4u LhUAAEdlbmVyYWwgU3RhdGUgZXhhbXBsZf8AKgQIAL0bAAAMABhZERwAAGAAAgDIHAAAFwFo ALsdAAAKAl8AvR4AAAwDbACyHwAAAQRyAGUAYQAAAAAIAADAxRIAAAAAADzIEgCQP3YAAAAA AAAYAAD/////AAAAAAQAAAAgABIAuolwMAQAAAAEAAAABwQAAAEAAAByNikCoscSAAgAAAAE AAAAAAgAAEQHAgICBwICABgABwAAAAAAAAAH////5wAAAAACBwICBQAAAEQHAgJExhIAAAAA AAAAAAAY0J0wAAAAAAAAAAA8yBIAoDR2AAAAAAAAAAAAAAAAAAAAAABEBwICYIRUMAAAAAA8 yBIAoDR2AGAJdgDwCXYABAAAAAAAAAAEAAAACAAAAKA0dgACBwICAAAAAEQHAgIAAAAAaYdw MHI2KQIIAAAAoscSAAQAAAABAAAABAAAAKLHEgByNikCCAAAAKw2dgDwK3YA5MYSAAAAAACs NnYAOumydwAAAACgNHYA0B92AAEAAABkxxIAF5ayd7Q2KQK0BlQwUMcSAHQAAAAAAAAAAgDH MAAAxTA4xxIASMcSAAgAAAAOAAAAAAAAAH96bTAOAMcw0QAAAJLHEgD8AAAACQAAAJ1FBDAA AMUw7KPHMNEAAACSxxIA/QAAAJLHEgCUyRIA378DMJLHEgC0NikCAAAAAJTJEgB0AAAAAAAA AIapDjAAAAAAkMcSAAcAAAD/////cwBwAGEAYwBpAG4AZwBwAHQAeQBuAHQAYQB0AGkAbwBu AHkAcABlAHIAbABpAG4AawAAAEgAAAAAALIEGt+dMOUDAADFsHAwjDIpAgEAAAAkyRIAAAAA AGwAAAABAAAA9O6dMAAAAAAsELJ3IMkSAAEAAAAIgAoDABgAAAAAAABwLHYAPZmydwiACgO8 l7J3xP3//6A0dgBgCXYA8Al2AAEAAAAAEAAA/wEAANw2dgALAAAAABAAAAAIAAAAAAAAAAAA AAAQAABghFQwBAAAAAAIAAAHAAAACAAAANw2/wEAAAEAAAAAAv8BCQCkyBIA2o2ydwEAAAAA AAAAAAgAAGCEVDAACAAAcAl2AOTIEgAIkrt36MgSALQUsndoErJ3AAC2AAAAAAABAAAAkMkS AEAAHvEQAAAA4MgSANacejAAAAAATNMbAwgAAADwyBIATNMbA4hkezCwY1QwAMkSAAgAAAAB AAAATNMbAwQAAAAUyRIATNMbAzTJEgCPpX0wuFJUMAAAAADNAAAANMkSAAAAAACQyRIAkMkS AHDJEgCQp3owzQAAAAAAAACQyRIAAQAAAEzTGwOqAwAA6wAAALjJEgAAAAAAes0SACWFEDDQ yRIAqgMAAEzTGwMACAAAlWAJMOsAAACqAwAA0MkSAFFgCTBIFy0C+60OMBEAAACmxRIA//// /wAgLQIAAAAALAAAAAYACgAAAAkIEAAABhAA8hXMB8kAAAAGAAAACwIYAAAAAAAAAAAAKgAA AE4pAADgMgAAMjYAAA0AAgAAAAwAAgBkAA8AAgABABEAAgAAABAACAD8qfHSTWJQP18AAgAB ACoAAgAAACsAAgAAAIIAAgABAIAACAAdAAAAAgAAACUCBAAAACwBgQACAAEFFABZAFYAACZM JjhwcmludGVkOiAmRCAmVCAgIEZsb3cgZ2VuZXJhdGVkOiAgMDEuMTAuMjAwMygxMzozNikm QyY4JlAvJk4mUiY4JkYgIChzdGF0aWNfb25fb2YpFQAAAIMAAgAAAIQAAgAAACYACABMJpPJ ZDLJPycACABMJpPJZDLJPygACAC5XC6Xy+XiPykACAC5XC6Xy+XiP00AogMAAFwAXABBAFMA TABTAEQAQwAwAFwAbgAyADMAMQA3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAABBAIF3ADEAhN/AAgBAAkA6gpvCGQAAQAPAFgCAQACAFgCAgAAAEwAZQB0AHQAZQByAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAABQUklW 4jAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAAAAAECcQJxAnAAAQJwAAAAAAAAAA AADEAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAQAFA0AwAoiAQAAAAAAAAA AAABAAEAAAAAAAAAAAAAAAAAAAAAAOFuT5UbAAAAAAAAAAAAAAAAAAAAAAACAAAAAAACAAQA AwABAAAAAAAAAAEAAAAAAAMA/wD/AAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAChACIACQBkAAEAAQAAAAIAWAJYAkwmk8lkMtk/TCaTyWQy2T8BAFUAAgAIAH0ADAAAAAAA xwIPAAYAAgB9AAwAAQAAAeMGDwACAAIAAAIOAAAAAAAqAAAAAAALAAAACAIQAAAAAAALAGgB AABUMAABEgAIAhAAAgAAAAsA/gEAABIAAAEDAAgCEAADAAAACwA7AQAAAAAAARIgCAIQAAQA AAALADsBAAB2AAABACAIAhAABQAAAAsALAEAAPt/AAECAAgCEAAGAAAACwAsAQAAAAABAQAA CAIQAAcAAAALACwBAAAAAAABAAAIAhAACAAAAAsALAEAABIAAAECAAgCEAAJAAAACwAsAQAA AAAAARIACAIQAAoAAAALACwBAAAAAAEBAAAIAhAACwAAAAsALAEAAAAAAQEAAAgCEAAMAAAA CwAsAQAAAAAAARIACAIQAA0AAAALACwBAAAAAAABAAAIAhAADgAAAAsAwgEAAFQwAAEAAAgC EAAPAAAACwAsAQAAdgAAAXYACAIQABAAAAALACwBAAB2AAABAAAIAhAAEQAAAAsALAEAAP// AAECAggCEAASAAAACwAsAQAAdgABAXYACAIQABMAAAALACwBAAAAAAEBAAAIAhAAFAAAAAsA OwEAALJ3AAEAIAgCEAAVAAAACwA7AQAAEgAAAXYgCAIQABYAAAALACwBAAASAAABAAAIAhAA FwAAAAsALAEAAAAAAAF2AAgCEAAYAAAACwAsAQAAKwIBAQAACAIQABkAAAALACwBAAC7dwAB EgAIAhAAGgAAAAsALAEAALYAAAEAAAgCEAAbAAAACwAsAQAAdgAAAbJHCAIQABwAAAALACwB AAAAAAEBA4AIAhAAHQAAAAsALAEAAAAAAQESAAgCEAAeAAAACwAsAQAAAAAAARIACAIQAB8A AAALACwBAABUMAABAAD9AAoAAAABAB4ADgAAAL4ACgAAAAIAHgAeAAMA/QAKAAIAAQAgAAEA AAABAgYAAgACAB8A/QAKAAIABQAhAAMAAAABAgYAAgAGACEA/QAKAAIACQAhAAIAAAABAgYA AgAKACEAfgIKAAMAAAAtAAAAIEABAgYAAwABAB0AAQIGAAMABQAdAAECBgADAAkAHQB+AgoA BAAAABsAAAAiQP0ACgAEAAEAKwAQAAAAvgAYAAQAAgAqACYAJgArACoAJgAmACsAKgAKAH4C CgAFAAAAGwAAACRAAQIGAAUAAQAcAAECBgAFAAUAHAD9AAoABQAGACIABAAAAL4ADAAFAAcA IgAiACkACQB+AgoABgAAABsAAAAmQAECBgAGAAEAHAABAgYABgAFABwA/QAKAAYABgAkABEA AAC+AAwABgAHACQAJAAnAAkAfgIKAAcAAAAtAAAAKEABAgYABwABABwAAQIGAAcABQAcAAEC BgAHAAkAHAB+AgoACAAAABsAAAAqQAECBgAIAAEAHAD9AAoACAACACMACQAAAL4ADAAIAAMA IwAjACgABQABAgYACAAJABwAfgIKAAkAAAAbAAAALEABAgYACQABABwAAQIGAAkABQAcAP0A CgAJAAYAIgAFAAAAvgAMAAkABwAiACIAKQAJAH4CCgAKAAAAGwAAAC5AAQIGAAoAAQAcAAEC BgAKAAUAHAD9AAoACgAGACQAEwAAAL4ADAAKAAcAJAAkACcACQB+AgoACwAAABsAAAAwQAEC BgALAAEAHAABAgYACwAFABwA/QAKAAsABgAkABIAAAC+AAwACwAHACQAJAAnAAkAfgIKAAwA AAAtAAAAMUABAgYADAABABwAAQIGAAwABQAcAAECBgAMAAkAHAB+AgoADQAAABsAAAAyQAEC BgANAAEAHAD9AAoADQACACMACgAAAL4ADAANAAMAIwAjACgABQABAgYADQAJABwAfgIKAA4A AAAbAAAAM0ABAgYADgABABwA/QAKAA4ABQAsAAsAAAABAgYADgAGACUAAQIGAA4ACQAcAH4C CgAPAAAALQAAADRAAQIGAA8AAQAcAAECBgAPAAUAHAABAgYADwAJABwAfgIKABAAAAAbAAAA NUABAgYAEAABABwA/QAKABAAAgAjAAwAAAC+AAwAEAADACMAIwAoAAUAAQIGABAACQAcAH4C CgARAAAAGwAAADZAAQIGABEAAQAcAAECBgARAAUAHAD9AAoAEQAGACIADQAAAL4ADAARAAcA IgAiACkACQB+AgoAEgAAABsAAAA3QAECBgASAAEAHAABAgYAEgAFABwA/QAKABIABgAkABMA AAC+AAwAEgAHACQAJAAnAAkAfgIKABMAAAAbAAAAOEABAgYAEwABABwAAQIGABMABQAcAP0A CgATAAYAJAASAAAAvgAMABMABwAkACQAJwAJAH4CCgAUAAAALQAAADlAAQIGABQAAQAcAAEC BgAUAAUAHAABAgYAFAAJABwAfgIKABUAAAAbAAAAOkD9AAoAFQABACsADwAAAL4AGAAVAAIA KgAmACYAKwAqACYAJgArACoACgB+AgoAFgAAAC0AAAA7QAECBgAWAAEAHAABAgYAFgAFABwA AQIGABYACQAcAH4CCgAXAAAAGwAAADxAAQIGABcAAQAcAAECBgAXAAUAHAD9AAoAFwAGACIA FgAAAL4ADAAXAAcAIgAiACkACQB+AgoAGAAAABsAAAA9QAECBgAYAAEAHAABAgYAGAAFABwA /QAKABgABgAkABQAAAC+AAwAGAAHACQAJAAnAAkAfgIKABkAAAAtAAAAPkABAgYAGQABABwA AQIGABkABQAcAAECBgAZAAkAHAB+AgoAGgAAABsAAAA/QAECBgAaAAEAHAD9AAoAGgACACMA FwAAAL4ADAAaAAMAIwAjACgABQABAgYAGgAJABwAfgIKABsAAAAbAAAAQEABAgYAGwABABwA AQIGABsABQAcAP0ACgAbAAYAIgAGAAAAvgAMABsABwAiACIAKQAJAH4CCgAcAAAAGwAAgEBA AQIGABwAAQAcAAECBgAcAAUAHAD9AAoAHAAGACQAEwAAAL4ADAAcAAcAJAAkACcACQB+AgoA HQAAABsAAABBQAECBgAdAAEAHAABAgYAHQAFABwA/QAKAB0ABgAkABsAAAC+AAwAHQAHACQA JAAnAAkAfgIKAB4AAAAtAACAQUABAgYAHgABABwAAQIGAB4ABQAcAAECBgAeAAkAHAB+AgoA HwAAABsAAABCQAECBgAfAAEAHAD9AAoAHwACACMAGAAAAL4ADAAfAAMAIwAjACgABQABAgYA HwAJABwA1wBCAFoJAABYAhwASAAsADgAQABAACwAQABAAEAAQAAsAEAAOgAsAEAAQABAAEAA LAA4ACwAQABAACwAQABAAEAAQAAsAAgCEAAgAAAACgAsAQAAVDAAARIACAIQACEAAAAKACwB AAASAAEBAwAIAhAAIgAAAAoALAEAAAAAAQESAAgCEAAjAAAACgAsAQAAdgAAAQAACAIQACQA AAAKACwBAAD7fwABAgAIAhAAJQAAAAoALAEAAAAAAAEAAAgCEAAmAAAACgAsAQAAAAABAQAA CAIQACcAAAAKACwBAAASAAEBAgAIAhAAKAAAAAoALAEAAAAAAAESAAgCEAApAAAACgAsAQAA AAAAAQAAfgIKACAAAAAbAACAQkABAgYAIAABABwAAQIGACAABQAcAP0ACgAgAAYAIgAZAAAA vgAMACAABwAiACIAKQAJAH4CCgAhAAAAGwAAAENAAQIGACEAAQAcAAECBgAhAAUAHAD9AAoA IQAGACQAEwAAAL4ADAAhAAcAJAAkACcACQB+AgoAIgAAABsAAIBDQAECBgAiAAEAHAABAgYA IgAFABwA/QAKACIABgAkABUAAAC+AAwAIgAHACQAJAAnAAkAfgIKACMAAAAtAAAAREABAgYA IwABABwAAQIGACMABQAcAAECBgAjAAkAHAB+AgoAJAAAABsAAIBEQAECBgAkAAEAHAD9AAoA JAACACMAGgAAAL4ADAAkAAMAIwAjACgABQABAgYAJAAJABwAfgIKACUAAAAbAAAARUABAgYA JQABABwAAQIGACUABQAcAP0ACgAlAAYAIgAHAAAAvgAMACUABwAiACIAKQAJAH4CCgAmAAAA GwAAgEVAAQIGACYAAQAcAAECBgAmAAUAHAD9AAoAJgAGACQAEwAAAL4ADAAmAAcAJAAkACcA CQB+AgoAJwAAABsAAABGQAECBgAnAAEAHAABAgYAJwAFABwA/QAKACcABgAkABwAAAC+AAwA JwAHACQAJAAnAAkAfgIKACgAAAAtAACARkABAgYAKAABABwAAQIGACgABQAcAAECBgAoAAkA HAD9AAoAKQAAABoAAAAAAAECBgApAAEAHAABAgYAKQAFABwAAQIGACkACQAcANcAGAAMAwAA tABAAEAAQAAsAEAAQABAAEAALADsANAADwAC8GwHAAAgAAjwCAAAAA8AAAAOrAEADwAD8FQH AAAPAATwKAAAAAEACfAQAAAAAA4ADkBBAAkADgAOQEEACQIACvAIAAAAAKwBAAUAAAAPAATw eAAAAEIBCvAIAAAAAawBAEAKAABzAAvwPgAAAL8ACAAIAMABCAAACNEBAQAAANQBAAAAANUB AAAAAP8BCAAIAIDDFAAAAGQAZQBmAGEAcgByAG8AdwAxAAAAAAAQ8BIAAAAAAAYAAAAFALMA CgAAAAUAswAAABHwAAAAAF0AGgAVABIAAQABABEAAAAAALTnGwMAAAAAAAAAAOwAhgAPAATw fgAAAEIBCvAIAAAAAqwBAAAKAACDAAvwRAAAAL8ACAAIAMABCAAACM4BBwAAANEBAQAAANQB AAAAANUBAAAAAP8BCAAIAIDDFAAAAGQAZQBmAGEAcgByAG8AdwAyAAAAAAAQ8BIAAAAAAAIA AAAIALMABgAAAAgAswAAABHwAAAAAF0AGgAVABIAAQACABEAAAAAAFzoGwMAAAAAAAAAAOwA gAAPAATweAAAAEIBCvAIAAAAA6wBAAAKAABzAAvwPgAAAL8ACAAIAMABCAAACNEBAQAAANQB AAAAANUBAAAAAP8BCAAIAIDDFAAAAGQAZQBmAGEAcgByAG8AdwAxAAAAAAAQ8BIAAAAAAAYA AAAJALMACgAAAAkAswAAABHwAAAAAF0AGgAVABIAAQADABEAAAAAAATpGwMAAAAAAAAAAOwA hgAPAATwfgAAAEIBCvAIAAAABKwBAAAKAACDAAvwRAAAAL8ACAAIAMABCAAACM4BBwAAANEB AQAAANQBAAAAANUBAAAAAP8BCAAIAIDDFAAAAGQAZQBmAGEAcgByAG8AdwAyAAAAAAAQ8BIA AAAAAAIAAAANALMABgAAAA0AswAAABHwAAAAAF0AGgAVABIAAQAEABEAAAAAAMTpGwMAAAAA AAAAAOwAhgAPAATwfgAAAEIBCvAIAAAABawBAAAKAACDAAvwRAAAAL8ACAAIAMABCAAACM4B BwAAANEBAQAAANQBAAAAANUBAAAAAP8BCAAIAIDDFAAAAGQAZQBmAGEAcgByAG8AdwAyAAAA AAAQ8BIAAAAAAAIAAAAQALMABgAAABAAswAAABHwAAAAAF0AGgAVABIAAQAFABEAAAAAAITq GwMAAAAAAAAAAOwAgAAPAATweAAAAEIBCvAIAAAABqwBAAAKAABzAAvwPgAAAL8ACAAIAMAB CAAACNEBAQAAANQBAAAAANUBAAAAAP8BCAAIAIDDFAAAAGQAZQBmAGEAcgByAG8AdwAxAAAA AAAQ8BIAAAAAAAYAAAARALMACgAAABEAswAAABHwAAAAAF0AGgAVABIAAQAGABEAAAAAAETr GwMAAAAAAAAAAOwAgAAPAATweAAAAEIBCvAIAAAAB6wBAEAKAABzAAvwPgAAAL8ACAAIAMAB CAAACNEBAQAAANQBAAAAANUBAAAAAP8BCAAIAIDDFAAAAGQAZQBmAGEAcgByAG8AdwAxAAAA AAAQ8BIAAAAAAAYAAAAXALMACgAAABcAswAAABHwAAAAAF0AGgAVABIAAQAHABEAAAAAAFAP GwMAAAAAAAAAAOwAhgAPAATwfgAAAEIBCvAIAAAACKwBAAAKAACDAAvwRAAAAL8ACAAIAMAB CAAACM4BBwAAANEBAQAAANQBAAAAANUBAAAAAP8BCAAIAIDDFAAAAGQAZQBmAGEAcgByAG8A dwAyAAAAAAAQ8BIAAAAAAAIAAAAaALMABgAAABoAswAAABHwAAAAAF0AGgAVABIAAQAIABEA AAAAAPgPGwMAAAAAAAAAAOwAgAAPAATweAAAAEIBCvAIAAAACawBAAAKAABzAAvwPgAAAL8A CAAIAMABCAAACNEBAQAAANQBAAAAANUBAAAAAP8BCAAIAIDDFAAAAGQAZQBmAGEAcgByAG8A dwAxAAAAAAAQ8BIAAAAAAAYAAAAbALMACgAAABsAswAAABHwAAAAAF0AGgAVABIAAQAJABEA AAAAALgQGwMAAAAAAAAAAOwAhgAPAATwfgAAAEIBCvAIAAAACqwBAAAKAACDAAvwRAAAAL8A CAAIAMABCAAACM4BBwAAANEBAQAAANQBAAAAANUBAAAAAP8BCAAIAIDDFAAAAGQAZQBmAGEA cgByAG8AdwAyAAAAAAAQ8BIAAAAAAAIAAAAfALMABgAAAB8AswAAABHwAAAAAF0AGgAVABIA AQAKABEAAAAAAHgRGwMAAAAAAAAAAOwAgAAPAATweAAAAEIBCvAIAAAAC6wBAAAKAABzAAvw PgAAAL8ACAAIAMABCAAACNEBAQAAANQBAAAAANUBAAAAAP8BCAAIAIDDFAAAAGQAZQBmAGEA cgByAG8AdwAxAAAAAAAQ8BIAAAAAAAYAAAAgALMACgAAACAAswAAABHwAAAAAF0AGgAVABIA AQALABEAAAAAADgSGwMAAAAAAAAAAOwAhgAPAATwfgAAAEIBCvAIAAAADKwBAAAKAACDAAvw RAAAAL8ACAAIAMABCAAACM4BBwAAANEBAQAAANQBAAAAANUBAAAAAP8BCAAIAIDDFAAAAGQA ZQBmAGEAcgByAG8AdwAyAAAAAAAQ8BIAAAAAAAIAAAAkALMABgAAACQAswAAABHwAAAAAF0A GgAVABIAAQAMABEAAAAAAPgSGwMAAAAAAAAAAOwAgAAPAATweAAAAEIBCvAIAAAADawBAAAK AABzAAvwPgAAAL8ACAAIAMABCAAACNEBAQAAANQBAAAAANUBAAAAAP8BCAAIAIDDFAAAAGQA ZQBmAGEAcgByAG8AdwAxAAAAAAAQ8BIAAAAAAAYAAAAlALMACgAAACUAswAAABHwAAAAAF0A GgAVABIAAQANABEAAAAAALgTGwMAAAAAAAAAAOwAeAAPAATweAAAAKIMCvAIAAAADqwBAAAK AACTAAvwNgAAAIAAIIUpAr8ACAAKAFgBAAAAAIEBUAAACIMBUAAACL8BEAARAAECAAAAAD8C AwADAL8DAgAKAAAAEPASAAAAAwABAPgAAAAVAAUAMgIFAMAAAAAR8AAAAABdADQAFQASABkA DgARQCCFKQJ4FBsDAAAAAA0AFgCJSLffk4cER6Dvvq3CmOalAABYAQAAAAAAAOwACAAAAA3w AAAAALYBEgASAgAAAAAAAAAAtQAQAAAAAAA8ALYAAGZsb3dnZW5fMTA0YmV0YS54bHMgdiAx LjA0YmV0YSgyMDAtMTAwMDApCkRlZmF1bHQobG9jYWwpCmdlbmVyYXRlZDogMDEuMTAuMjAw MyAoMTM6MzYpCnlvdSBuZWVkIGhlbHA/IApjYWxsIFQuVm9pdGggMjU5LTQwMjkzCkR1cmF0 aW9uOiAwOjA0IFttaW46c2VjXQooIE5vTXNnTGluZXM6IDM5O1VwZEx2bDogLTEgKQo8ABAA AAAFAAQABQC1AAAAwPgaAxwAEQAAAAAAAAAOAAUAAFZvaXRoLj4CEgC8BwAAAABAAAAAAAAA AAAAAABBAAoAAAADAAMAQAACAB0ADwADAAAAAAAAAQAAAAAAAAAdAA8AAgAAAAAAAAEAAAAA AAAACgAAAAkIEAAABhAA8hXMB8kAAAAGAAAACwIUAAAAAAAAAAAAHAAAAOxFAABQTgAADQAC AAAADAACAGQADwACAAEAEQACAAAAEAAIAPyp8dJNYlA/XwACAAEAKgACAAAAKwACAAAAggAC AAEAgAAIAB0AAAACAAAAJQIEAAAALAGBAAIAAQUUAFcAVAAAJkwmOHByaW50ZWQ6ICZEICZU ICAgRmxvdyBnZW5lcmF0ZWQ6ICAwMS4xMC4yMDAzKDEzOjM1KSZDJjgmUC8mTiZSJjgmRiAg KHN0YXRpY19nZW4pFQAAAIMAAgAAAIQAAgAAACYACABMJpPJZDLJPycACABMJpPJZDLJPygA CAC5XC6Xy+XiPykACAC5XC6Xy+XiP00AogMAAFwAXABBAFMATABTAEQAQwAwAFwAbgAyADMA MQA3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBAIF3ADEAhN/AAgBAAkA 6gpvCGQAAQAPAFgCAQACAFgCAgAAAEwAZQB0AHQAZQByAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AQAAAAIAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAABQUklW4jAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAGAAAAAAAECcQJxAnAAAQJwAAAAAAAAAAAADEAgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAMAAAAAAAAAAAAQAFA0AwAoiAQAAAAAAAAAAAABAAEAAAAAAAAAAAAAAAAA AAAAAOFuT5UbAAAAAAAAAAAAAAAAAAAAAAACAAAAAAACAAQAAwABAAAAAAAAAAEAAAAAAAMA /wD/AAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAChACIACQBkAAEAAQAAAAIA WAJYAkwmk8lkMtk/TCaTyWQy2T8BAFUAAgAIAH0ADAAAAAAAxwIPAAYAAgB9AAwAAQAAAeMG DwACAAIAAAIOAAAAAAAcAAAAAAALAAAACAIQAAAAAAALAGgBAABUMAABEgAIAhAAAgAAAAsA /gEAABIAAAEDAAgCEAADAAAACwA7AQAAAAAAARIgCAIQAAQAAAALADsBAAASAAABEiAIAhAA BQAAAAsALAEAAPt/AAECRwgCEAAGAAAACwAsAQAAAAAAAQAACAIQAAcAAAALACwBAAAAAAEB AAAIAhAACAAAAAsALAEAABIAAQECAAgCEAAJAAAACwCjAgAAAAAAARIACAIQAAoAAAALACwB AAAAAAABOgAIAhAACwAAAAsALAEAABsDAAEAAAgCEAAMAAAACwAsAQAAGwMAARIACAIQAA0A AAALACwBAAASAAEBGwMIAhAADgAAAAsALAEAAAEAAQEAAAgCEAAPAAAACwAsAQAAGwMAARIA CAIQABAAAAALACwBAAAAAAABAAAIAhAAEQAAAAsALAEAABsDAAEAAAgCEAASAAAACwAsAQAA GwMBARsDCAIQABMAAAALACwBAAASAAEBAAAIAhAAFAAAAAsAOwEAAJ0wAAEAIAgCEAAVAAAA CwA7AQAAAAAAAQAgCAIQABYAAAALACwBAAAbAwABEgAIAhAAFwAAAAsALAEAAAAAAQEAAAgC EAAYAAAACwAsAQAAKwIBAQAACAIQABkAAAALADsBAAAbAwABEiAIAhAAGgAAAAsAOwEAAAAA AAEAIAgCEAAbAAAACwAsAQAAGwMAAQAA/QAKAAAAAQAeACsAAAC+AAoAAAACAB4AHgADAP0A CgACAAEAIAABAAAAAQIGAAIAAgAfAP0ACgACAAUAIQADAAAAAQIGAAIABgAhAP0ACgACAAkA IQACAAAAAQIGAAIACgAhAH4CCgADAAAALQAAACBAAQIGAAMAAQAdAAECBgADAAUAHQABAgYA AwAJAB0AfgIKAAQAAAAbAAAAIkD9AAoABAABACsAIAAAAL4AEAAEAAIAKgAmACYAKwAqAAYA AQIGAAQACQAcAH4CCgAFAAAAGwAAACRAAQIGAAUAAQAcAP0ACgAFAAIAIwAiAAAAvgAMAAUA AwAjACMAKAAFAAECBgAFAAkAHAB+AgoABgAAABsAAAAmQAECBgAGAAEAHAABAgYABgAFABwA /QAKAAYABgAiACMAAAC+AAwABgAHACIAIgApAAkAfgIKAAcAAAAbAAAAKEABAgYABwABABwA AQIGAAcABQAcAP0ACgAHAAYAJAAeAAAAvgAMAAcABwAkACQAJwAJAH4CCgAIAAAAGwAAACpA AQIGAAgAAQAcAAECBgAIAAUAHAD9AAoACAAGACQAHwAAAL4ADAAIAAcAJAAkACcACQB+AgoA CQAAABsAAAAsQAECBgAJAAEAHAD9AAoACQAFACwAJgAAAAECBgAJAAYAJQABAgYACQAJABwA fgIKAAoAAAAtAAAALkABAgYACgABABwAAQIGAAoABQAcAAECBgAKAAkAHAB+AgoACwAAABsA AAAwQAECBgALAAEAHAD9AAoACwACACMAJAAAAL4ADAALAAMAIwAjACgABQABAgYACwAJABwA fgIKAAwAAAAbAAAAMUABAgYADAABABwAAQIGAAwABQAcAP0ACgAMAAYAIgAIAAAAvgAMAAwA BwAiACIAKQAJAH4CCgANAAAAGwAAADJAAQIGAA0AAQAcAAECBgANAAUAHAD9AAoADQAGACQA EwAAAL4ADAANAAcAJAAkACcACQB+AgoADgAAABsAAAAzQAECBgAOAAEAHAABAgYADgAFABwA /QAKAA4ABgAkAB0AAAC+AAwADgAHACQAJAAnAAkAfgIKAA8AAAAtAAAANEABAgYADwABABwA AQIGAA8ABQAcAAECBgAPAAkAHAB+AgoAEAAAABsAAAA1QAECBgAQAAEAHAD9AAoAEAACACMA JQAAAL4ADAAQAAMAIwAjACgABQABAgYAEAAJABwAfgIKABEAAAAbAAAANkABAgYAEQABABwA AQIGABEABQAcAP0ACgARAAYAIgANAAAAvgAMABEABwAiACIAKQAJAH4CCgASAAAAGwAAADdA AQIGABIAAQAcAAECBgASAAUAHAD9AAoAEgAGACQAEwAAAL4ADAASAAcAJAAkACcACQB+AgoA EwAAABsAAAA4QAECBgATAAEAHAABAgYAEwAFABwA/QAKABMABgAkACEAAAC+AAwAEwAHACQA JAAnAAkAfgIKABQAAAAtAAAAOUABAgYAFAABABwAAQIGABQABQAcAAECBgAUAAkAHAB+AgoA FQAAABsAAAA6QP0ACgAVAAEAKwAnAAAAvgAYABUAAgAqACYAJgArACoAJgAmACsAKgAKAH4C CgAWAAAAGwAAADtAAQIGABYAAQAcAAECBgAWAAUAHAD9AAoAFgAGACIAFgAAAL4ADAAWAAcA IgAiACkACQB+AgoAFwAAABsAAAA8QAECBgAXAAEAHAABAgYAFwAFABwA/QAKABcABgAkACgA AAC+AAwAFwAHACQAJAAnAAkAfgIKABgAAAAbAAAAPUABAgYAGAABABwAAQIGABgABQAcAP0A CgAYAAYAJAApAAAAvgAMABgABwAkACQAJwAJAH4CCgAZAAAALQAAAD5AAQIGABkAAQAcAAEC BgAZAAUAHAABAgYAGQAJABwAfgIKABoAAAAbAAAAP0D9AAoAGgABACsAKgAAAL4AGAAaAAIA KgAmACYAKwAqACYAJgArACoACgD9AAoAGwAAABoAAAAAAAECBgAbAAEAHAABAgYAGwAFABwA AQIGABsACQAcANcAOgAsCAAACAIcAEgALAA6AEAAQABAAEAAOgAsAEAAQABAAEAALABAAEAA QABAACwAOABAAEAAQAAsADgA7ADWAA8AAvBaBAAAUAAI8AgAAAAJAAAACKgBAA8AA/BCBAAA DwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAACoAQAFAAAADwAE8H4A AABCAQrwCAAAAAGoAQAACgAAgwAL8EQAAAC/AAgACADAAQgAAAjOAQcAAADRAQEAAADUAQAA AADVAQAAAAD/AQgACACAwxQAAABkAGUAZgBhAHIAcgBvAHcAMgAAAAAAEPASAAAAAAACAAAA BQCzAAYAAAAFALMAAAAR8AAAAABdABoAFQASAAEAAQARAAAAAAD4TRsDAAAAAAAAAADsAIAA DwAE8HgAAABCAQrwCAAAAAKoAQBACgAAcwAL8D4AAAC/AAgACADAAQgAAAjRAQEAAADUAQAA AADVAQAAAAD/AQgACACAwxQAAABkAGUAZgBhAHIAcgBvAHcAMQAAAAAAEPASAAAAAAAGAAAA BgCzAAoAAAAGALMAAAAR8AAAAABdABoAFQASAAEAAgARAAAAAACgThsDAAAAAAAAAADsAIYA DwAE8H4AAABCAQrwCAAAAAOoAQAACgAAgwAL8EQAAAC/AAgACADAAQgAAAjOAQcAAADRAQEA AADUAQAAAADVAQAAAAD/AQgACACAwxQAAABkAGUAZgBhAHIAcgBvAHcAMgAAAAAAEPASAAAA AAACAAAACwCzAAYAAAALALMAAAAR8AAAAABdABoAFQASAAEAAwARAAAAAABITxsDAAAAAAAA AADsAIAADwAE8HgAAABCAQrwCAAAAASoAQAACgAAcwAL8D4AAAC/AAgACADAAQgAAAjRAQEA AADUAQAAAADVAQAAAAD/AQgACACAwxQAAABkAGUAZgBhAHIAcgBvAHcAMQAAAAAAEPASAAAA AAAGAAAADACzAAoAAAAMALMAAAAR8AAAAABdABoAFQASAAEABAARAAAAAADwTxsDAAAAAAAA AADsAIYADwAE8H4AAABCAQrwCAAAAAWoAQAACgAAgwAL8EQAAAC/AAgACADAAQgAAAjOAQcA AADRAQEAAADUAQAAAADVAQAAAAD/AQgACACAwxQAAABkAGUAZgBhAHIAcgBvAHcAMgAAAAAA EPASAAAAAAACAAAAEACzAAYAAAAQALMAAAAR8AAAAABdABoAFQASAAEABQARAAAAAACYUBsD AAAAAAAAAADsAIAADwAE8HgAAABCAQrwCAAAAAaoAQAACgAAcwAL8D4AAAC/AAgACADAAQgA AAjRAQEAAADUAQAAAADVAQAAAAD/AQgACACAwxQAAABkAGUAZgBhAHIAcgBvAHcAMQAAAAAA EPASAAAAAAAGAAAAEQCzAAoAAAARALMAAAAR8AAAAABdABoAFQASAAEABgARAAAAAABAURsD AAAAAAAAAADsAIAADwAE8HgAAABCAQrwCAAAAAeoAQBACgAAcwAL8D4AAAC/AAgACADAAQgA AAjRAQEAAADUAQAAAADVAQAAAAD/AQgACACAwxQAAABkAGUAZgBhAHIAcgBvAHcAMQAAAAAA EPASAAAAAAAGAAAAFgCzAAoAAAAWALMAAAAR8AAAAABdABoAFQASAAEABwARAAAAAADoURsD AAAAAAAAAADsAHgADwAE8HgAAACiDArwCAAAAAioAQAACgAAkwAL8DYAAACAAADXKQK/AAgA CgBYAQAAAACBAVAAAAiDAVAAAAi/ARAAEQABAgAAAAA/AgMAAwC/AwIACgAAABDwEgAAAAMA AQD4AAAAFQAFADICBQDAAAAAEfAAAAAAXQA0ABUAEgAZAAgAEUAA1ykCkFIbAwAAAAANABYA 9sShEu7bFUKydPQiIp7VCQAAWAEAAAAAAADsAAgAAAAN8AAAAAC2ARIAEgIAAAAAAAAAALUA EAAAAAAAPAC2AABmbG93Z2VuXzEwNGJldGEueGxzIHYgMS4wNGJldGEoMjAwLTEwMDAwKQpE ZWZhdWx0KGxvY2FsKQpnZW5lcmF0ZWQ6IDAxLjEwLjIwMDMgKDEzOjM1KQp5b3UgbmVlZCBo ZWxwPyAKY2FsbCBULlZvaXRoIDI1OS00MDI5MwpEdXJhdGlvbjogMDowNCBbbWluOnNlY10K KCBOb01zZ0xpbmVzOiAyNTtVcGRMdmw6IC0xICkKPAAQAAAABQAAAAAAtQAAAAAAAAAcABEA AAAAAAAACAAFAABWb2l0aC4+AhIAvAEAAAAAQAAAAAAAAAAAAAAAQQAKAAAAAwADAEAAAgAd AA8AAwAAAAAAAAEAAAAAAAAAHQAPAAIAAAAAAAABAAAAAAAAAAoAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFQAaABpAHMAVwBvAHIAawBiAG8A bwBrAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIBBgAAAAUA AAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGUEAAAAAAAA XwBWAEIAQQBfAFAAUgBPAEoARQBDAFQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAABoAAgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAASAAAAxwsAAAAAAABkAGkAcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAACAP///////////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEIAAABkAgAAAAAAAFAAUgBPAEoARQBDAFQA dwBtAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUAAIA ////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATAAAACkA AAAAAAAAARYBAAC2AP//AQEAAAAA/////wAAAAD///////8AAAEQwrwc35hKu9liKoPmyrkZ CAIAAAAAAMAAAAAAAABGAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAMAAAAFAAAABwAAAP////// ////AQEIAAAA/////3gAAADeAAAATwMAAPUBAAD/////AAAAAAEAAAANOc9dAAD//yMAAACI AAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//8AAGsDAADWAAAA1gAAAL8D AAAAAP////8AAAAA3wD//wAAAAAMAP////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////KAAAAAIAU0z///// AAABAFMQ/////wAAAQBTlP////8AAAAAAjz/////AAD//wEBAAAAAAEATgAwAHsAMAAwADAA MgAwADgAMQA5AC0AMAAwADAAMAAtADAAMAAwADAALQBDADAAMAAwAC0AMAAwADAAMAAwADAA MAAwADAAMAA0ADYAfQAAAAAAAADfBgAAADgAAAABAdgAAAACgf7///////////8oAAAAAAD/ /wAAAAAAAAAA//////////8BAAIAHQAAACQAAAD/////SAAAAP////8AAAAAAoP+//////8I AP//aAAAAAAA////////AAAAAP//////////bABzAB0ADAAkAAAAgqAUAv/////+////mAAA AAIA///+////AAAAAP//////////AAAAAB0ADAAkAAAAAoP+//////8IAP//yAAAAAAA//// ////AAAAAP//////////AAAAAB0ADAAkAAAA/////wgAAAAAAAAAAAABAAAAAAAAAP////// /////////wAAAAD/////////////////////AAAAAP//////////cAAAAKAAAAAAAAAAAAAA AEAABAAAAAAAaAJoAv////////////////////////////8IAAEA/////01FAAD///////8A AAAA//8AAAAA//8BAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+ygEAAAD/////AQEIAAAA/////3gAAAABorAAQXR0 cmlidXQAZSBWQl9OYW0AZSA9ICJUaGkAc1dvcmtib28QayINCgqMQmFzAQKMMHswMDAyMFA4 MTktABAwAwhDBwAUAhIBJDAwNDZ9AQ18Q3JlYXRhYoJsAYZGYWxzZQxeAFByZWRlY2xhiQAG SWQAi1RydQ0iQEV4cG9zZRQcVABlbXBsYXRlRDBlcml2AiQRZUN1wHN0b21pegSIAzIAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAzGFeAAABAP8HBAAACQQAAOQEAQAAAAAAAAAAAAEA BQACABYBKgBcAEcAewAwADAAMAAyADAANABFAEYALQAwADAAMAAwAC0AMAAwADAAMAAtAEMA MAAwADAALQAwADAAMAAwADAAMAAwADAAMAAwADQANgB9ACMAMwAuADAAIwA5ACMAQwA6AFwA UAByAG8AZwByAGEAbQAgAEYAaQBsAGUAcwBcAEMAbwBtAG0AbwBuACAARgBpAGwAZQBzAFwA TQBpAGMAcgBvAHMAbwBmAHQAIABTAGgAYQByAGUAZABcAFYAQgBBAFwAVgBCAEEAMwAzADIA LgBkAGwAbAAjAFYAaQBzAHUAYQBsACAAQgBhAHMAaQBjACAARgBvAHIAIABBAHAAcABsAGkA YwBhAHQAaQBvAG4AcwAAAAAAAAAAAAAAAADmACoAXABHAHsAMAAwADAAMgAwADgAMQAzAC0A MAAwADAAMAAtADAAMAAwADAALQBDADAAMAAwAC0AMAAwADAAMAAwADAAMAAwADAAMAA0ADYA fQAjADEALgAyACMAMAAjAEMAOgBcAGEAcABwAGwAXABvAGYAcAA5ADcAZQBcAE8AZgBmAGkA YwBlAFwARQBYAEMARQBMADgALgBPAEwAQgAjAE0AaQBjAHIAbwBzAG8AZgB0ACAARQB4AGMA ZQBsACAAOAAuADAAIABPAGIAagBlAGMAdAAgAEwAaQBiAHIAYQByAHkAAAAAAAAAAAAAAAAA uAAqAFwARwB7ADAAMAAwADIAMAA0ADMAMAAtADAAMAAwADAALQAwADAAMAAwAC0AQwAwADAA MAAtADAAMAAwADAAMAAwADAAMAAwADAANAA2AH0AIwAyAC4AMAAjADAAIwBDADoAXABXAEkA TgBOAFQAXABTAHkAcwB0AGUAbQAzADIAXABTAHQAZABPAGwAZQAyAC4AVABsAGIAIwBPAEwA RQAgAEEAdQB0AG8AbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAA4AAqAFwARwB7ADgAQQBEADEA NwA5AEQAMAAtAEQAOAA4ADMALQAxADEARAAzAC0AQgBEAEUAMwAtADAAMAA5ADAAMgA3ADkA MABCADMANABGAH0AIwAyAC4AMAAjADAAIwBDADoAXABXAEkATgBOAFQAXABTAHkAcwB0AGUA bQAzADIAXABNAFMARgBvAHIAbQBzAC4AVABXAEQAIwBNAGkAYwByAG8AcwBvAGYAdAAgAEYA bwByAG0AcwAgADIALgAwACAATwBiAGoAZQBjAHQAIABMAGkAYgByAGEAcgB5AAAAAAAAAAAA AAABANQAKgBcAEcAewA0ADYAMwA1ADcANAA5ADIALQBFADMAQgA0AC0AMQAxAEQAMwAtAEIA RABFAEQALQAwADAAOQAwADIANwA5ADAAQgAzADQARgB9ACMAMgAuADAAIwAwACMAQwA6AFwA VABFAE0AUABcAFYAQgBFAFwATQBTAEYAbwByAG0AcwAuAEUAWABEACMATQBpAGMAcgBvAHMA bwBmAHQAIABGAG8AcgBtAHMAIAAyAC4AMAAgAE8AYgBqAGUAYwB0ACAATABpAGIAcgBhAHIA eQAAAAAAAAAAAAAAAQAAAOEuRQ2P4BoQhS4CYIxNC7QAAOYAKgBcAEcAewAyAEQARgA4AEQA MAA0AEMALQA1AEIARgBBAC0AMQAwADEAQgAtAEIARABFADUALQAwADAAQQBBADAAMAA0ADQA RABFADUAMgB9ACMAMgAuADAAIwAwACMAQwA6AFwAYQBwAHAAbABcAG8AZgBwADkANwBlAFwA TwBmAGYAaQBjAGUAXABNAFMATwA5ADcALgBEAEwATAAjAE0AaQBjAHIAbwBzAG8AZgB0ACAA TwBmAGYAaQBjAGUAIAA4AC4AMAAgAE8AYgBqAGUAYwB0ACAATABpAGIAcgBhAHIAeQAAAAAA AAAAAAAAAAABAAIAAwAEAgAABgIBAAgCAAAQAv///////wAAAAD//wAAzbd6PwgA//////// //////////////////8AAP////////////////////////////////////////////////// /////wEAAAAAAAAAAAAAAAAAAAAAAAAADTkBABgAVABoAGkAcwBXAG8AcgBrAGIAbwBvAGsA CgA2M2YxZmMzNWIAAwAqRAEVAv//z10AAAAAAAAAAgAAAL8DAAD//xgCAAABATADAAD///// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////8AAgAA//////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////+dQum6n3KxOkDyYIYd2+Gn/////AQAAAFACAAAoAAAA lhcHY9Ui9Hv/////AAAAAFACAAAQAAAAr0dzO+flWN//////AAAAAP////8wAAAAcAIAABAA AACJLnt8EHOtPP////8AAAAA/////zACAACQAgAAEAAAAJ1M1tLDRVIw/////wAAAAD///// UAIAALACAAAQAAAAtFwExcXSumf/////AAAAAP////9wAgAA0AIAABAAAACcakysC0Un5/// //8AAAAA/////5ACAADwAgAAEAAAAIVXlYOOQqH5/////wAAAAD/////sAIAABADAAAQAAAA snbcWhJ+UqL/////AAAAAP/////QAgAA/////xAAAAC/kz5LsCsNEf////8AAAAA//////AC AACAAAAAAAAaARsA/wDAJwAABQRFeGNlbIArEAADBFZCQffiEAAFBFdpbjE2wX4QAAUEV2lu MzIHfxAAAwRNYWOzshAACAR0ZW1wbGF0Zeh/EAAGBHN0ZG9sZZNgEAAHAE1TRm9ybXNDDxAA CgRWQkFQcm9qZWN0vr8QAAYET2ZmaWNlFXUQAAwEVGhpc1dvcmtib29rfOMQAAmAAAD/AwEA X0V2YWx1YXRlGNkQAAYEU2hlZXQx6BoQAAYEU2hlZXQy6RoQAAYEU2hlZXQz6hoQAAYEU2hl ZXQ06xoQAAgEV29ya2Jvb2trGBAACQRXb3Jrc2hlZXTB/hAABwRTaGVldDMxa1AQAAcEU2hl ZXQyMUZQEAAHBFNoZWV0MjJHUBAACARTaGVldDIyMeYjEAAJBFNoZWV0MjIxMR3qEAAIBFNo ZWV0MjIy5yMQAAgEU2hlZXQyMjPoIxAACQRTaGVldDIyMjFC6hAACQRTaGVldDIyMzFn6hAA Av//AQFUAAAAFQIAAAAA////////////////////////AAIBAP//AgIAAP////////////// ////////////////////DAICAP//DgIDAP//EAL/////EgIEAP//AAAOAAAAAQASAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAWCygAEABAAAAAEAMCoCApAJAHAUBkgDAIICAGTkBAQACgAc AFZCQVByb2pliGN0BQA0AABAAhRqBgIKPQIKBwJyARQIBQYSCQISzbd6PwiUAAwCSjwCChYA AXKAc3Rkb2xlPgIZAHMAdABkAG8AgGwAZQANAGYAJQJcAAMqXEd7MDCAMDIwNDMwLQAIHQQE QwAKAg4BEjAwNAA2fSMyLjAjMAAjQzpcV0lOTgBUXFN5c3RlbQAzMlxTdGRPbABlMi5UbGIj TwBMRSBBdXRvbWBhdGlvbgBeAAEWBAAHgAJNU0ZvciBtcz4ADgEGAFMEAEYARXIAbQBz0AAv AHqACXCAAQFGADhBRDE3OUQwAC1EODgzLTExgEQzLUJERTMARgA5MDI3OTBCMww0RhdGBDMu VFdEACNNaWNyb3NvKGZ0IAI9IABgIE8CYgGwIExpYnJhHHJ5ADkAAR5QMACIDQATaoABAVA0 NjM1ADc0OTItRTNCCjQGUEQVUFRFTVAgXFZCRVyFJkVYAacm4S5FDY/gGgAQhS4CYIxNCwa0 QZJDdk9mZmljBUR2T0BzZgBpAGMVQnZ9wClzxCoyREYAOEQwNEMtNUKARkEtMTAxQgFTEjXA KkFBQHU0REUENTIIU2FwcGxcgG9mcDk3ZVwDGAFALU85Ny5ETExDiFODBiA4LjDSUw8RgrUB ABPCAQ05GQGCn1RoaXNXb3JAa2Jvb2saTgQyRAAYgCxUAGiAMXNEAFfChmsAYsABbxAAawAc wAYAAEgFQgExAry/AwAAHotCAgEFLEIaz10iQggKK0IBEEIBAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAFRoaXNXb3JrYm9vawBUAGgAaQBzAFcAbwByAGsAYgBvAG8AawAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABJRD0iezE1OUU5MUE1LUNDODUtNEE1MS04NDMxLUQzMDNB QUExMDI4N30iDQpEb2N1bWVudD1UaGlzV29ya2Jvb2svJkgwMDAwMDAwMA0KTmFtZT0iVkJB UHJvamVjdCINCkhlbHBDb250ZXh0SUQ9IjAiDQpDTUc9IjYxNjNDQzE0RDAxNEQwMTREMDE0 RDAiDQpEUEI9Ijk0OTYzOTcwNUZBMjYwQTI2MEEyIg0KR0M9IkM3QzU2QTQxQUU0N0VQAFIA TwBKAEUAQwBUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAEAACAQMAAAAHAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAE0AAADBAQAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIB/////woAAAD/////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVQAAANAAAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQA UwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgD///// //////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABZAAAAxAEAAAAA AAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAEgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAGEAAABmAAAAAAAAADA0OEUwNDgxRiINCg0KW0hvc3QgRXh0ZW5kZXIgSW5m b10NCiZIMDAwMDAwMDE9ezM4MzJENjQwLUNGOTAtMTFDRi04RTQzLTAwQTBDOTExMDA1QX07 VkJFOyZIMDAwMDAwMDANCg0KW1dvcmtzcGFjZV0NClRoaXNXb3JrYm9vaz0wLCAwLCAwLCAw LCBDDQpTaGVldDI9MCwgMCwgMCwgMCwgQw0KU2hlZXQzMT0wLCAwLCAwLCAwLCBDDQpTaGVl dDIxPTAsIDAsIDAsIDAsIEMNClNoZWV0MT0wLCAwLCAwLCAwLCBDDQpTaGVldDM9MCwgMCwg MCwgMCwgQw0KAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQAAgAAAAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQ q5EIACsns9kwAAAAoAAAAAcAAAABAAAAQAAAAAQAAABIAAAACAAAAFgAAAASAAAAaAAAAAsA AACAAAAADAAAAIwAAAATAAAAmAAAAAIAAADkBAAAHgAAAAYAAABWb2l0aABmAB4AAAAGAAAA Vm9pdGgAZgAeAAAAEAAAAE1pY3Jvc29mdCBFeGNlbABAAAAAABxPYQ6IwwFAAAAAACeTFh3u wgEDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAP7/AAAEAAIAAAAAAAAAAAAAAAAAAAAAAAIAAAAC1c3VnC4bEJOXCAArLPmuRAAAAAXV zdWcLhsQk5cIACss+a4sAQAA6AAAAAkAAAABAAAAUAAAAA8AAABYAAAAFwAAAHAAAAALAAAA eAAAABAAAACAAAAAEwAAAIgAAAAWAAAAkAAAAA0AAACYAAAADAAAAMQAAAACAAAA5AQAAB4A AAAPAAAAQWxjYXRlbCBTRUwgQUcAAAMAAAAxFQgACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAA CwAAAAAAAAAeEAAAAgAAAA8AAABzdGF0aWNfb25fb2ZfbwANAAAAc3RhdGljX2dlbl9vAAwQ AAACAAAAHgAAAAsAAABXb3Jrc2hlZXRzAAMAAAACAAAAAJgAAAADAAAAAAAAACAAAAABAAAA NgAAAAIAAAA+AAAAAQAAAAIAAAAKAAAAX1BJRF9HVUlEAAIAAADkBAAAQQAAAE4AAAB7ADIA MgA5AEIANAA5AEUARQAtADMAOQAzADkALQA0ADQARABEAC0AQgBBAEEANAAtADkAMwA5AEYA NwAxADQAOQAzADEAQwA1AH0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQD+/wMKAAD/////IAgCAAAAAADAAAAA AAAARhoAAABNaWNyb3NvZnQgRXhjZWwgV29ya3NoZWV0AAYAAABCaWZmOAAOAAAARXhjZWwu U2hlZXQuOAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== --------------11B76428C1EED84E9C6F850E-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Oct 1 08:43:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10316 for ; Wed, 1 Oct 2003 08:43:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4gJu-0005fm-9a for megaco-archive@odin.ietf.org; Wed, 01 Oct 2003 08:43:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h91Ch6WY021802 for megaco-archive@odin.ietf.org; Wed, 1 Oct 2003 08:43:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4gJt-0005fZ-Vx for megaco-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 08:43:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10285 for ; Wed, 1 Oct 2003 08:42:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4gJs-0006Tb-00 for megaco-web-archive@ietf.org; Wed, 01 Oct 2003 08:43:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4gJs-0006TX-00 for megaco-web-archive@ietf.org; Wed, 01 Oct 2003 08:43:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4gJp-0005W6-F2; Wed, 01 Oct 2003 08:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4fXS-0002ZY-Jr for megaco@optimus.ietf.org; Wed, 01 Oct 2003 07:53:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09011 for ; Wed, 1 Oct 2003 07:52:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4fXM-000642-00 for megaco@ietf.org; Wed, 01 Oct 2003 07:52:56 -0400 Received: from mailrelay1.alcatel.de ([194.113.59.75] helo=mailrelay2.alcatel.de) by ietf-mx with esmtp (Exim 4.12) id 1A4fXL-00063m-00 for megaco@ietf.org; Wed, 01 Oct 2003 07:52:55 -0400 Received: from ks.sel.alcatel.de (slsv0d.stgl.sel.alcatel.de [149.204.14.10]) by mailrelay2.alcatel.de (8.12.10/8.12.9) with ESMTP id h91Bn4TC022065; Wed, 1 Oct 2003 13:49:05 +0200 (MET DST) Received: from slssiv ([149.204.245.89] helo=slsdtk.stgl.sel.alcatel.de) by ks.sel.alcatel.de with esmtp (Exim 3.31) id 1A4fWj-0001zs-00; Wed, 01 Oct 2003 13:52:17 +0200 Received: from sls0gf.stgl.sel.alcatel.de ([149.204.201.220] helo=alcatel.de) by slsdtk.stgl.sel.alcatel.de with esmtp (Exim 3.31) id 1A4fWi-0004vD-00; Wed, 01 Oct 2003 13:52:16 +0200 Message-ID: <3F7ABFEE.48753D6F@alcatel.de> Date: Wed, 01 Oct 2003 13:52:14 +0200 From: Thomas Voith X-Mailer: Mozilla 4.77 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en,de MIME-Version: 1.0 To: megaco@ietf.org, tsg16q3@itu.int Content-Type: multipart/mixed; boundary="------------11B76428C1EED84E9C6F850E" X-Alcanet-virus-scanned: h91Bn4TC022065 at mailrelay2.alcatel.de Subject: [Megaco] Event descriptor handling for static logic interfaces like CAS Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------11B76428C1EED84E9C6F850E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear list-members, H.248.26 and in H.248.ICAS I miss a feature, which has been used already for On-Hook, Off-Hook the 'strict' parameter. All interfaces, which have static states, should implement such a mechanism. The problem is that the EventsDescriptor EventBufferDescriptor or an embedded EventsDescriptor may discard events, if the newly received or replacing Event Descriptor does not match the event. In the Megaco Secnarios, always just the good case is shown. e.g. a static interface with 4 logical incoming events ( S1,S2,S3,S4) would then set the EventsDescripror like: MGC guess the MG is in state i1, no Notify will be sent by MG, when state of interface is still i1. Events { S1{strict="exact"},S2{strict="state"},S3{strict="state"},S4{strict="state"} } ( Note: in case "state" is the default, then EventsDescriptor could be shorter) The events descriptor remains active, after Notification is sent. The strict parameter avoids unnecessary Notifications for the already by MGC known state. This mechanism would be very simple and avoids lost of any events, which is strong required for signalling interfaces on MG transferred via H.248 to an MGC. For a better illustration I have attached a Excel-File containing a simple scenario. So my question/proposal is: - Is it possible to extend the existing static state interfacepackages like H.248.26 with this strict feature? - If not, can I get this functionality otherwise ? Kind regards Thomas Voith -- _______________________________________________________________ _ V | Thomas Voith +---------------+ | Dept. VS/EAC2 [Systems] | A L C A T E L | | FL/2/50 +---------------+ | | Tel: +49 711 821-40293 | Alcanet: 259-40293 Alcatel SEL AG | Fax: +49 711 821-40211 Fixed Networks Division | Lorenzstr. 10 | mailto:Thomas.Voith@alcatel.de D-70435 Stuttgart, Germany | _______________________________________________________________ --------------11B76428C1EED84E9C6F850E Content-Type: application/x-xls; name="strict_cases.xls" Content-Disposition: inline; filename="strict_cases.xls" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAAQAAAAAA AAAAEAAAAgAAAAEAAAD+////AAAAAAAAAAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////9////LgAAAP7///8EAAAABQAAAAYAAAAPAAAA CAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAAMAAAAQAAAAEQAAABIAAAATAAAAFAAAABUA AAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAA IwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAALAAAAC0AAAD+////OQAAADAA AAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADoAAAD+////OwAAADwAAAD+//// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////1IA bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAWAAUA//////////8CAAAAIAgCAAAAAADAAAAAAAAARgAAAACAxKlKEIjDAbCT Om8QiMMBLwAAAMAYAAAAAAAAVwBvAHIAawBiAG8AbwBrAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgELAAAA//////////8AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAZVUAAAAAAABfAFYAQgBBAF8AUABSAE8A SgBFAEMAVABfAEMAVQBSAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIgABAQEA AAAJAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoJgJbxCIwwGwkzpvEIjDAQAAAAAAAAAA AAAAAFYAQgBBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAIAAEA//////////8EAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARxRv EIjDAeAPJW8QiMMBAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgA AAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAD+////EwAAABQAAAAVAAAA FgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAAIgAAACMA AAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwAAAAtAAAALgAAAC8AAAAwAAAA MQAAADIAAAAzAAAANAAAADUAAAA2AAAANwAAADgAAAA5AAAAOgAAADsAAAA8AAAAPQAAAD4A AAA/AAAAQAAAAEEAAAD+////QwAAAEQAAABFAAAARgAAAEcAAABIAAAASQAAAEoAAABLAAAA /v////7///9OAAAATwAAAFAAAABRAAAAUgAAAFMAAABUAAAA/v///1YAAABXAAAAWAAAAP7/ //9aAAAAWwAAAFwAAABdAAAAXgAAAF8AAABgAAAA/v///2IAAAD+//////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////8ABBYg 4AAUAAYAAAABABMAABgAAAAAAAAAAMAgkwIEABCAA/+TAgQAEYAG/5MCFgASABEAAENvbW1h IFswXV9mbG93Z2VukwISABMADQAAQ29tbWFfZmxvd2dlbpMCBAAUgAT/kwIEABWAB/+TAhkA FgAUAABDdXJyZW5jeSBbMF1fZmxvd2dlbpMCFQAXABAAAEN1cnJlbmN5X2Zsb3dnZW6TAgQA AIAA/5MCEwAYAA4AAE5vcm1hbF9mbG93Z2VukwIEABmABf9gAQIAAQCFABYAXyQAAAAADgBz dGF0aWNfb25fb2Zfb4UAFAADQQAAAAAMAHN0YXRpY19nZW5fb4wABAABADEArgEEAAIAAQQX ABQAAwAAAP////8AAAEAAQAAAAAAAAAYAB8AAAAACQcAAAAAAAAAAAAAZGVmX3hfYWIxOgAA TwADABgAHwAAAAAJBwAAAAAAAAAAAABkZWZfeF9hYjI6AABRAAMAGAAfAAAAAAkHAAAAAAAA AAAAAGRlZl94X2FiMzoAAFMAAwAYAB8AAAAACQcAAAAAAAAAAAAAZGVmX3hfYWI0OgAAVQAD ABgAHwAAAAAJBwAAAAAAAAAAAABkZWZfeF9hbDE6AAA9AAMAGAAfAAAAAAkHAAAAAAAAAAAA AGRlZl94X2FsMjoAAD8AAwAYAB8AAAAACQcAAAAAAAAAAAAAZGVmX3hfYWwzOgAAQQADABgA HwAAAAAJBwAAAAAAAAAAAABkZWZfeF9hbDQ6AABDAAMAGAAfAAAAAAkHAAAAAAAAAAAAAGRl Zl94X2FyMToAAEYAAwAYAB8AAAAACQcAAAAAAAAAAAAAZGVmX3hfYXIyOgAASAADABgAHwAA AAAJBwAAAAAAAAAAAABkZWZfeF9hcjM6AABKAAMAGAAfAAAAAAkHAAAAAAAAAAAAAGRlZl94 X2FyNDoAAEwAAwAYAB4AAAAACAcAAAAAAAAAAAAAZGVmX3hfdGE6AAA0AAMAGAAeAAAAAAgH AAAAAAAAAAAAAGRlZl94X3RkOgAANgADABgAHgAAAAAIBwAAAAAAAAAAAABkZWZfeF90ZToA ADgAAwAYAB4AAAAACAcAAAAAAAAAAAAAZGVmX3hfdG46AAA6AAMAGAAdAAAAAAcHAAAAAAAA AAAAAGRlZmNtdDE6AAAlAAMAGAAdAAAAAAcHAAAAAAAAAAAAAGRlZmNtdDI6AAAnAAMAGAAd AAAAAAcHAAAAAAAAAAAAAGRlZmNtdDM6AAApAAMAGAAdAAAAAAcHAAAAAAAAAAAAAGRlZmNt dDQ6AAArAAMAGAAgAAAAAAoHAAAAAAAAAAAAAGRlZmNtdGxlZnQ6AAAtAAMAGAAeAAAAAAgH AAAAAAAAAAAAAGRlZmVtcHR5OgAALwADABgAIAAAAAAKBwAAAAAAAAAAAABkZWZlbnRpdHkx OgAAEgADABgAIAAAAAAKBwAAAAAAAAAAAABkZWZlbnRpdHkyOgAAFAADABgAIAAAAAAKBwAA AAAAAAAAAABkZWZlbnRpdHkzOgAAFgADABgAIAAAAAAKBwAAAAAAAAAAAABkZWZlbnRpdHk0 OgAAGAADABgAHwAAAAAJBwAAAAAAAAAAAABkZWZoaWRkZW46AAAiAAMAGAAcAAAAAAYHAAAA AAAAAAAAAGRlZml0ZjoAABcACQAYAB0AAAAABwcAAAAAAAAAAAAAZGVmbXNnMToAABwAAwAY AB0AAAAABwcAAAAAAAAAAAAAZGVmbXNnMjoAAB0AAwAYAB0AAAAABwcAAAAAAAAAAAAAZGVm bXNnMzoAAB4AAwAYAB0AAAAABwcAAAAAAAAAAAAAZGVmbXNnNDoAAB8AAwAYACEAAAAACwcA AAAAAAAAAAAAZGVmcGFyYWxlZnQ6AAAhAAMAGAAiAAAAAAwHAAAAAAAAAAAAAGRlZnBhcmFt ZXRlcjoAACAAAwAYAB4AAAAACAcAAAAAAAAAAAAAZGVmdGl0bGU6AAAQAAMAGAAgAAAAAAoH AAAAAAAAAAAAAGVudF9ib3JkZXI6AAANAAgAGAAjAAAAAA0HAAAAAAAAAAAAAG1zZ2VudGl0 eW5hbWU6AAAFAAQAGAAdAAAAAAcHAAAAAAAAAAAAAG1zZ25hbWU6AAAGAAMAGAAiAAAAAAwH AAAAAAAAAAAAAG9yaWdpbmNvbHVtbjoAAA0AAQAYAB8AAAAACQcAAAAAAAAAAAAAb3JpZ2lu cm93OgAADAABABgAIwAAAAANBwAAAAAAAAAAAABwYXJhX2xldmVsaW5nOgAADAAIABgAJAAA AAAOBwAAAAAAAAAAAABwYXJhX3NtYWxsX2V4dDoAAA4ACAAYACIAAAAADAcAAAAAAAAAAAAA cHJpbnRfZm9ybWF0OgAADAAFABgAJwAAAAARBwAAAAAAAAAAAABwcmludF9vcmllbnRhdGlv bjoAAA0ABQAYABsAIAAAAQsAAAACAAAAAAAABzsBAAIAAgAAAP8AGAAbACAAAAELAAAAAQAA AAAAAAc7AgACAAIAAAD/ABgAIAAAAAAKBwAAAAAAAAAAAABwcmludF93aWRlOgAADgAFABgA IAAAAAAKBwAAAAAAAAAAAAByZXN1bHRjZWxsOgAADwAAABgAIAAAAAAKBwAAAAAAAAAAAABz a2lwX2VtcHR5OgAACwAIABgAHQAAAAAHBwAAAAAAAAAAAABzcGFjaW5nOgAACwkIEAAABgUA 8hXMB8kAAAAGAAAA4QACALAEwQACAAAA4gAAAFwAcAAFAABWb2l0aCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQgACALAEYQECAAAAPQEEAIYA gwDTAAAAvQEAALoBDwAMAABUaGlzV29ya2Jvb2ucAAIADgAZAAIAAAASAAIAAAATAAIAAACv AQIAAAC8AQIAAAA9ABIAaAF4AHRAfyY4AAAAAAABAIoDQAACAAAAjQACAAAAIgACAAAADgAC AAEAtwECAAAA2gACAAAAMQAaAPAAAAD/f5ABAAAAAgAABQFBAHIAaQBhAGwAMQAqANwAAAD/ f5ABAAAAAAAADQFGAHUAdAB1AHIAYQBBACAAQgBrACAAQgBUADEAKgDcAAAA/3+QAQAAAAAA AA0BRgB1AHQAdQByAGEAQQAgAEIAawAgAEIAVAAxACoA3AAAAP9/kAEAAAAAAAANAUYAdQB0 AHUAcgBhAEEAIABCAGsAIABCAFQAMQAcAKAAAABRAJABAAAAAAAABgFUAGEAaABvAG0AYQAx ABoAoAAAAP9/kAEAAAACAAAFAUEAcgBpAGEAbAAxABoAGAEBAP9/vAIAAAACAAAFAUEAcgBp AGEAbAAxABoAyAABAAgAvAIAAAACAAAFAUEAcgBpAGEAbAAxABoAoAAAAAkAkAEAAAACAAAF AUEAcgBpAGEAbAAxABoA8AAAAP9/kAEAAAACAAAFAUEAcgBpAGEAbAAxABoAyAAAAP9/kAEA AAAAAAAFAUEAcgBpAGEAbAAxABoAoAACAAgAkAEAAAACAAAFAUEAcgBpAGEAbAAxABoAoAAA ABIAkAEAAAACAAAFAUEAcgBpAGEAbAAxABoAoAACABIAkAEAAAACAAAFAUEAcgBpAGEAbAAe BDMABQAXAAEjACwAIwAjADAAXAAgACIArCAiADsAXAAtACMALAAjACMAMABcACAAIgCsICIA HgQ9AAYAHAABIwAsACMAIwAwAFwAIAAiAKwgIgA7AFsAUgBlAGQAXQBcAC0AIwAsACMAIwAw AFwAIAAiAKwgIgAeBD8ABwAdAAEjACwAIwAjADAALgAwADAAXAAgACIArCAiADsAXAAtACMA LAAjACMAMAAuADAAMABcACAAIgCsICIAHgRJAAgAIgABIwAsACMAIwAwAC4AMAAwAFwAIAAi AKwgIgA7AFsAUgBlAGQAXQBcAC0AIwAsACMAIwAwAC4AMAAwAFwAIAAiAKwgIgAeBHEAKgA2 AAFfAC0AKgAgACMALAAjACMAMABcACAAIgCsICIAXwAtADsAXAAtACoAIAAjACwAIwAjADAA XAAgACIArCAiAF8ALQA7AF8ALQAqACAAIgAtACIAXAAgACIArCAiAF8ALQA7AF8ALQBAAF8A LQAeBGsAKQAzAAFfAC0AKgAgACMALAAjACMAMABcACAAXwCsIF8ALQA7AFwALQAqACAAIwAs ACMAIwAwAFwAIABfAKwgXwAtADsAXwAtACoAIAAiAC0AIgBcACAAXwCsIF8ALQA7AF8ALQBA AF8ALQAeBIEALAA+AAFfAC0AKgAgACMALAAjACMAMAAuADAAMABcACAAIgCsICIAXwAtADsA XAAtACoAIAAjACwAIwAjADAALgAwADAAXAAgACIArCAiAF8ALQA7AF8ALQAqACAAIgAtACIA PwA/AFwAIAAiAKwgIgBfAC0AOwBfAC0AQABfAC0AHgR7ACsAOwABXwAtACoAIAAjACwAIwAj ADAALgAwADAAXAAgAF8ArCBfAC0AOwBcAC0AKgAgACMALAAjACMAMAAuADAAMABcACAAXwCs IF8ALQA7AF8ALQAqACAAIgAtACIAPwA/AFwAIABfAKwgXwAtADsAXwAtAEAAXwAtAB4EHgCk ABkAACMsIyMwXCAiRE0iO1wtIywjIzBcICJETSIeBCMApQAeAAAjLCMjMFwgIkRNIjtbUmVk XVwtIywjIzBcICJETSIeBCQApgAfAAAjLCMjMC4wMFwgIkRNIjtcLSMsIyMwLjAwXCAiRE0i HgQpAKcAJAAAIywjIzAuMDBcICJETSI7W1JlZF1cLSMsIyMwLjAwXCAiRE0iHgQ+AKgAOQAA Xy0qICMsIyMwXCAiRE0iXy07XC0qICMsIyMwXCAiRE0iXy07Xy0qICItIlwgIkRNIl8tO18t QF8tHgQ+AKkAOQAAXy0qICMsIyMwXCBfRF9NXy07XC0qICMsIyMwXCBfRF9NXy07Xy0qICIt IlwgX0RfTV8tO18tQF8tHgRGAKoAQQAAXy0qICMsIyMwLjAwXCAiRE0iXy07XC0qICMsIyMw LjAwXCAiRE0iXy07Xy0qICItIj8/XCAiRE0iXy07Xy1AXy0eBEYAqwBBAABfLSogIywjIzAu MDBcIF9EX01fLTtcLSogIywjIzAuMDBcIF9EX01fLTtfLSogIi0iPz9cIF9EX01fLTtfLUBf LR4EHACsABcAACMsIyMwXCAiRiI7XC0jLCMjMFwgIkYiHgQhAK0AHAAAIywjIzBcICJGIjtb UmVkXVwtIywjIzBcICJGIh4EIgCuAB0AACMsIyMwLjAwXCAiRiI7XC0jLCMjMC4wMFwgIkYi HgQnAK8AIgAAIywjIzAuMDBcICJGIjtbUmVkXVwtIywjIzAuMDBcICJGIh4EOwCwADYAAF8t KiAjLCMjMFwgIkYiXy07XC0qICMsIyMwXCAiRiJfLTtfLSogIi0iXCAiRiJfLTtfLUBfLR4E OACxADMAAF8tKiAjLCMjMFwgX0ZfLTtcLSogIywjIzBcIF9GXy07Xy0qICItIlwgX0ZfLTtf LUBfLR4EQwCyAD4AAF8tKiAjLCMjMC4wMFwgIkYiXy07XC0qICMsIyMwLjAwXCAiRiJfLTtf LSogIi0iPz9cICJGIl8tO18tQF8tHgRAALMAOwAAXy0qICMsIyMwLjAwXCBfRl8tO1wtKiAj LCMjMC4wMFwgX0ZfLTtfLSogIi0iPz9cIF9GXy07Xy1AXy0eBBwAtAAXAAAiJCIjLCMjMF8p O1woIiQiIywjIzBcKR4EIQC1ABwAACIkIiMsIyMwXyk7W1JlZF1cKCIkIiMsIyMwXCkeBCIA tgAdAAAiJCIjLCMjMC4wMF8pO1woIiQiIywjIzAuMDBcKR4EJwC3ACIAACIkIiMsIyMwLjAw Xyk7W1JlZF1cKCIkIiMsIyMwLjAwXCkeBDcAuAAyAABfKCIkIiogIywjIzBfKTtfKCIkIiog XCgjLCMjMFwpO18oIiQiKiAiLSJfKTtfKEBfKR4EPwC5ADoAAF8oIiQiKiAjLCMjMC4wMF8p O18oIiQiKiBcKCMsIyMwLjAwXCk7XygiJCIqICItIj8/Xyk7XyhAXykeBBgAugATAAAioyIj LCMjMDtcLSKjIiMsIyMwHgQdALsAGAAAIqMiIywjIzA7W1JlZF1cLSKjIiMsIyMwHgQeALwA GQAAIqMiIywjIzAuMDA7XC0ioyIjLCMjMC4wMB4EIwC9AB4AACKjIiMsIyMwLjAwO1tSZWRd XC0ioyIjLCMjMC4wMB4ENQC+ADAAAF8tIqMiKiAjLCMjMF8tO1wtIqMiKiAjLCMjMF8tO18t IqMiKiAiLSJfLTtfLUBfLR4ELAC/ACcAAF8tKiAjLCMjMF8tO1wtKiAjLCMjMF8tO18tKiAi LSJfLTtfLUBfLR4EPQDAADgAAF8tIqMiKiAjLCMjMC4wMF8tO1wtIqMiKiAjLCMjMC4wMF8t O18tIqMiKiAiLSI/P18tO18tQF8tHgQ0AMEALwAAXy0qICMsIyMwLjAwXy07XC0qICMsIyMw LjAwXy07Xy0qICItIj8/Xy07Xy1AXy0eBA8AwgAKAABkZC9tbS95eXl54AAUAAAAAAD1/yAA AAAAAAAAAAAAAMAg4AAUAAEAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAEAAAD1/yAAAPQAAAAA AAAAAMAg4AAUAAIAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAIAAAD1/yAAAPQAAAAAAAAAAMAg 4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAA AAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAA APQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAA AAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg 4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAABACAAAAAAAAAAAAAAAMAg4AAUAAEA KwD1/yAAAPgAAAAAAAAAAMAg4AAUAAEAKQD1/yAAAPgAAAAAAAAAAMAg4AAUAAsAvwD1/yAA APgAAAAAAAAAAMAg4AAUAAsAwQD1/yAAAPgAAAAAAAAAAMAg4AAUAAEALAD1/yAAAPgAAAAA AAAAAMAg4AAUAAEAKgD1/yAAAPgAAAAAAAAAAMAg4AAUAAsAvgD1/yAAAPgAAAAAAAAAAMAg 4AAUAAsAwAD1/yAAAPgAAAAAAAAAAMAg4AAUAAoAAAD1/yEAAAAAAAAAAAAAAMAg4AAUAAEA CQD1/yAAAPgAAAAAAAAAAMAg4AAUAAkAAAABACAAAAgAAAAAAAAAAMAg4AAUAAYAAAABABMA AFgAAAAAAAAAAMAg4AAUAAAAAAABACAAACAQAAAgAAAAAMAg4AAUAAAAAAABACAAACAQAQAg QAAAAMAg4AAUAAcAAACBAQAAAFgAAAAAAAAAAMAg4AAUAAgAAACBARYAAHgREUAgQCAABDEg 4AAUAAgAAACBAR4AAHgREUAgQCAABDEg4AAUAAgAAACBARYAAHgREUAgQCAABCIg4AAUAAYA AACBAQYAABgAAAAAAAAAAMAg4AAUAAwAAACBAQYAABgAAAAAAAAAAMAg4AAUAA0AAACBAQEA AFgAAAAAAAAAAMAg4AAUAAYAAACBAR4AAHgAAAAAAAAABBYg4AAUAA4AAACBAS4AADgiIjgc OBwAAMAg4AAUAA0AAACBAQEAAHgQAAAgAAAAAMAg4AAUAAwAAACBAQYAADgQAAAgAAAAAMAg 4AAUAAYAAACBAQYAADgQAAAgAAAAAMAg4AAUAA4AAACBAS4AADggIgAcOBwAAMAg4AAUAA4A AACBAS4AADgSIjggOBwAAMAg4AAUAAYAAACBAR4AAHgQAAAgAAAABQDrAKoDDwAA8KIDAAAA AAbwaAMAAAGwAQBsAAAAGAAAAAIAAAAAAAAABwAAAAAAAAADAAAAAAAAAAMAAAAAAAAAAwAA AAAAAAADAAAAAAAAAAMAAAAAAAAAAwAAAAAAAAADAAAAAAAAAAMAAAAAAAAAAwAAAAAAAAAD AAAAAAAAAAMAAAAAAAAAAAQAAAAAAAADAAAAAAAAAAMAAAAAAAAABgAAAAAAAAAGAAAAAAAA AA4AAAAAAAAAFQAAAAAAAAAZAAAAAAAAAB8AAAAAAAAAHwAAAAAAAAAbAAAAAAAAABoAAAAA AAAAGwAAAAAAAAAbAAAAAAAAACEAAAAAAAAAIQAAAAAAAAAhAAAAAAAAAAcAAAAAAAAAIQAA AAAAAAAiAAAAAAAAACIAAAAAAAAAIQAAAAAAAAAhAAAAAAAAACEAAAAAAAAAIQAAAAAAAAAh AAAAAAAAACEAAAAAAAAAIgAAAAAAAAAiAAAAAAAAACIAAAAAAAAAIQAAAAAAAAAHAAAAAAAA AAoAAAAAAAAACgAAAAAAAAAJAAAAAAAAAAkAAAAAAAAABwAAAAAAAAAJAAAAAAAAAAoAAAAA AAAACgAAAAAAAAAKAAAAAAAAAAkAAAAAAAAACgAAAAAAAAAHAAAAAAAAABIAAAAAAAAABwAA AAAAAAARAAAAAAAAABQAAAAAAAAAFAAAAAAAAAAhAAAAAAAAACEAAAAAAAAAIQAAAAAAAAAh AAAAAAAAACQCAAAAAAAAIQAAAAAAAAARAAAAAAAAABEAAAAAAAAAEQAAAAAAAAARAAAAAAAA ABQAAAAAAAAACgAAAAAAAAAhAAAAAAAAAAcAAAAAAAAACwAAAAAAAAAKAAAAAAAAAAkAAAAA AAAACQAAAAAAAAAJAAAAAAAAAAkAAAAAAAAABwAAAAAAAAAbAAAAAAAAABsAAAAAAAAAGwAA AAAAAAAbAAAAAAAAABkAAAAAAAAAGQAAAAAAAAAGAAAAAAAAAAgAAAAAAAAACAAAAAAAAAAP AAAAAAAAAA8AAAAAAAAADwAAAAAAAAAPAAAAAAAAAA8AAAAAAAAABwAAAAAAAAAPAAAAAAAA AA8AAAAAAAAADwAAAAAAAAAHAAAAAAAAAAgAAAAAAAAACAAAAAAAAAAIAAAAAAAAAAkAAAAF AAAACQAAAAIAAAAPAAAAMwAL8BIAAAC/AAgACACBAQkAAAjAAUAAAAhAAB7xEAAAAA0AAAgM AAAIFwAACPcAABD8AHgEOQAAACwAAAADAABFbmQLAABSMgpleGNoYW5nZQMAAE1HQwIAAEdX CgAARjE6IE1vZGlmeQoAAEYzOiBOb3RpZnkKAABGOTogTm90aWZ5CwAARjEzOiBOb3RpZnkK AABGNDogTm90aWZ5DAAARjI6IE9mZi1Ib29rCwAARjQ6IE9uLUhvb2svAABEaXNjYXJkZWQs IHNpbmNlIEV2ZW50cyBEZXNjcmlwdG9yIGRvIG5vdCBtYXRjaAwAAEY1OiBPZmYtSG9vawoA AEY2OiBOb3RpZnkUAABPbixPZmYtaG9vayBleGFtcGxlcyUAAENhc2UyOiBnb29kIGFuZCBi YWQgY2FzZXMgd2l0aCBzdHJpY3QVAABDYXNlMTogb25seSBnb29kIGNhc2UeAABFdmVudHMg e2FsL29me3N0cmljdD0ic3RhdGUifX0nAAAyMDAzMDkxOFQxMDMxMDAwMDphbC9vZntpbml0 PSJGYWxzZSJ9IH0QAABPYnNlcnZlZEV2ZW50cyB7NAAARXZlbnRzIHthbC9vZntzdHJpY3Q9 InN0YXRlIn0sYWwvb257c3RyaWN0PSJleGFjdCJ9fScAADIwMDMwOTE4VDEwMzEwMDAwOmFs L29ue2luaXQ9IkZhbHNlIn0gfQoAAEY3OiBNb2RpZnkMAABGODogT2ZmLUhvb2sMAABGMTA6 IE9uLUhvb2sLAABGMTE6IE5vdGlmeQ0AAEYxMjogT2ZmLUhvb2snAAAyMDAzMDkxOFQxMDMy MDAwMDphbC9vZntpbml0PSJGYWxzZSJ9IH0nAAAyMDAzMDkxOFQxMDMzMDAwMDphbC9vZntp bml0PSJGYWxzZSJ9IH0kAAAyMDAzMDkxOFQxMDMxMDAwMDpTMntpbml0PSJGYWxzZSJ9IH0u AABFdmVudHMge1Mxe3N0cmljdD0iZXhhY3QifSxTMntzdHJpY3Q9InN0YXRlIn0sJgAAUzN7 c3RyaWN0PSJzdGF0ZSJ9LFM0e3N0cmljdD0ic3RhdGUifX0pAABJbnRlZmFjZSBoYXMgMyBl dmVudCBzdGF0ZXM6ICBTMSxTMixTMyxTNCQAADIwMDMwOTE4VDEwMzEwMDAwOlM0e2luaXQ9 IkZhbHNlIn0gfQYAAEYxOiBTMQoAAEYyOiBNb2RpZnkGAABGMzogUzIGAABGNTogUzQ2AABN RyBkbyBub3Qgc2VudCBhIE5vdGlmeSwgc2luY2Ugc3RyaWN0PSJleGFjdCIgZm9yIFMxICE+ AABFdmVudCBEZXNjcmlwdG9yIGNhbiBiZSB1cGRhdGVkLCB3aXRob3V0IGFuIHVubmVjZXNz YXJ5IE5vdGlmeS4AAEV2ZW50cyB7UzF7c3RyaWN0PSJzdGF0ZSJ9LFMye3N0cmljdD0ic3Rh dGUifSwmAABTM3tzdHJpY3Q9InN0YXRlIn0sUzR7c3RyaWN0PSJleGFjdCJ9fQYAAC4uLi4u LhUAAEdlbmVyYWwgU3RhdGUgZXhhbXBsZf8AKgQIAL0bAAAMABhZERwAAGAAAgDIHAAAFwFo ALsdAAAKAl8AvR4AAAwDbACyHwAAAQRyAGUAYQAAAAAIAADAxRIAAAAAADzIEgCQP3YAAAAA AAAYAAD/////AAAAAAQAAAAgABIAuolwMAQAAAAEAAAABwQAAAEAAAByNikCoscSAAgAAAAE AAAAAAgAAEQHAgICBwICABgABwAAAAAAAAAH////5wAAAAACBwICBQAAAEQHAgJExhIAAAAA AAAAAAAY0J0wAAAAAAAAAAA8yBIAoDR2AAAAAAAAAAAAAAAAAAAAAABEBwICYIRUMAAAAAA8 yBIAoDR2AGAJdgDwCXYABAAAAAAAAAAEAAAACAAAAKA0dgACBwICAAAAAEQHAgIAAAAAaYdw MHI2KQIIAAAAoscSAAQAAAABAAAABAAAAKLHEgByNikCCAAAAKw2dgDwK3YA5MYSAAAAAACs NnYAOumydwAAAACgNHYA0B92AAEAAABkxxIAF5ayd7Q2KQK0BlQwUMcSAHQAAAAAAAAAAgDH MAAAxTA4xxIASMcSAAgAAAAOAAAAAAAAAH96bTAOAMcw0QAAAJLHEgD8AAAACQAAAJ1FBDAA AMUw7KPHMNEAAACSxxIA/QAAAJLHEgCUyRIA378DMJLHEgC0NikCAAAAAJTJEgB0AAAAAAAA AIapDjAAAAAAkMcSAAcAAAD/////cwBwAGEAYwBpAG4AZwBwAHQAeQBuAHQAYQB0AGkAbwBu AHkAcABlAHIAbABpAG4AawAAAEgAAAAAALIEGt+dMOUDAADFsHAwjDIpAgEAAAAkyRIAAAAA AGwAAAABAAAA9O6dMAAAAAAsELJ3IMkSAAEAAAAIgAoDABgAAAAAAABwLHYAPZmydwiACgO8 l7J3xP3//6A0dgBgCXYA8Al2AAEAAAAAEAAA/wEAANw2dgALAAAAABAAAAAIAAAAAAAAAAAA AAAQAABghFQwBAAAAAAIAAAHAAAACAAAANw2/wEAAAEAAAAAAv8BCQCkyBIA2o2ydwEAAAAA AAAAAAgAAGCEVDAACAAAcAl2AOTIEgAIkrt36MgSALQUsndoErJ3AAC2AAAAAAABAAAAkMkS AEAAHvEQAAAA4MgSANacejAAAAAATNMbAwgAAADwyBIATNMbA4hkezCwY1QwAMkSAAgAAAAB AAAATNMbAwQAAAAUyRIATNMbAzTJEgCPpX0wuFJUMAAAAADNAAAANMkSAAAAAACQyRIAkMkS AHDJEgCQp3owzQAAAAAAAACQyRIAAQAAAEzTGwOqAwAA6wAAALjJEgAAAAAAes0SACWFEDDQ yRIAqgMAAEzTGwMACAAAlWAJMOsAAACqAwAA0MkSAFFgCTBIFy0C+60OMBEAAACmxRIA//// /wAgLQIAAAAALAAAAAYACgAAAAkIEAAABhAA8hXMB8kAAAAGAAAACwIYAAAAAAAAAAAAKgAA AE4pAADgMgAAMjYAAA0AAgAAAAwAAgBkAA8AAgABABEAAgAAABAACAD8qfHSTWJQP18AAgAB ACoAAgAAACsAAgAAAIIAAgABAIAACAAdAAAAAgAAACUCBAAAACwBgQACAAEFFABZAFYAACZM JjhwcmludGVkOiAmRCAmVCAgIEZsb3cgZ2VuZXJhdGVkOiAgMDEuMTAuMjAwMygxMzozNikm QyY4JlAvJk4mUiY4JkYgIChzdGF0aWNfb25fb2YpFQAAAIMAAgAAAIQAAgAAACYACABMJpPJ ZDLJPycACABMJpPJZDLJPygACAC5XC6Xy+XiPykACAC5XC6Xy+XiP00AogMAAFwAXABBAFMA TABTAEQAQwAwAFwAbgAyADMAMQA3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAABBAIF3ADEAhN/AAgBAAkA6gpvCGQAAQAPAFgCAQACAFgCAgAAAEwAZQB0AHQAZQByAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAABQUklW 4jAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAAAAAECcQJxAnAAAQJwAAAAAAAAAA AADEAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAQAFA0AwAoiAQAAAAAAAAA AAABAAEAAAAAAAAAAAAAAAAAAAAAAOFuT5UbAAAAAAAAAAAAAAAAAAAAAAACAAAAAAACAAQA AwABAAAAAAAAAAEAAAAAAAMA/wD/AAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAChACIACQBkAAEAAQAAAAIAWAJYAkwmk8lkMtk/TCaTyWQy2T8BAFUAAgAIAH0ADAAAAAAA xwIPAAYAAgB9AAwAAQAAAeMGDwACAAIAAAIOAAAAAAAqAAAAAAALAAAACAIQAAAAAAALAGgB AABUMAABEgAIAhAAAgAAAAsA/gEAABIAAAEDAAgCEAADAAAACwA7AQAAAAAAARIgCAIQAAQA AAALADsBAAB2AAABACAIAhAABQAAAAsALAEAAPt/AAECAAgCEAAGAAAACwAsAQAAAAABAQAA CAIQAAcAAAALACwBAAAAAAABAAAIAhAACAAAAAsALAEAABIAAAECAAgCEAAJAAAACwAsAQAA AAAAARIACAIQAAoAAAALACwBAAAAAAEBAAAIAhAACwAAAAsALAEAAAAAAQEAAAgCEAAMAAAA CwAsAQAAAAAAARIACAIQAA0AAAALACwBAAAAAAABAAAIAhAADgAAAAsAwgEAAFQwAAEAAAgC EAAPAAAACwAsAQAAdgAAAXYACAIQABAAAAALACwBAAB2AAABAAAIAhAAEQAAAAsALAEAAP// AAECAggCEAASAAAACwAsAQAAdgABAXYACAIQABMAAAALACwBAAAAAAEBAAAIAhAAFAAAAAsA OwEAALJ3AAEAIAgCEAAVAAAACwA7AQAAEgAAAXYgCAIQABYAAAALACwBAAASAAABAAAIAhAA FwAAAAsALAEAAAAAAAF2AAgCEAAYAAAACwAsAQAAKwIBAQAACAIQABkAAAALACwBAAC7dwAB EgAIAhAAGgAAAAsALAEAALYAAAEAAAgCEAAbAAAACwAsAQAAdgAAAbJHCAIQABwAAAALACwB AAAAAAEBA4AIAhAAHQAAAAsALAEAAAAAAQESAAgCEAAeAAAACwAsAQAAAAAAARIACAIQAB8A AAALACwBAABUMAABAAD9AAoAAAABAB4ADgAAAL4ACgAAAAIAHgAeAAMA/QAKAAIAAQAgAAEA AAABAgYAAgACAB8A/QAKAAIABQAhAAMAAAABAgYAAgAGACEA/QAKAAIACQAhAAIAAAABAgYA AgAKACEAfgIKAAMAAAAtAAAAIEABAgYAAwABAB0AAQIGAAMABQAdAAECBgADAAkAHQB+AgoA BAAAABsAAAAiQP0ACgAEAAEAKwAQAAAAvgAYAAQAAgAqACYAJgArACoAJgAmACsAKgAKAH4C CgAFAAAAGwAAACRAAQIGAAUAAQAcAAECBgAFAAUAHAD9AAoABQAGACIABAAAAL4ADAAFAAcA IgAiACkACQB+AgoABgAAABsAAAAmQAECBgAGAAEAHAABAgYABgAFABwA/QAKAAYABgAkABEA AAC+AAwABgAHACQAJAAnAAkAfgIKAAcAAAAtAAAAKEABAgYABwABABwAAQIGAAcABQAcAAEC BgAHAAkAHAB+AgoACAAAABsAAAAqQAECBgAIAAEAHAD9AAoACAACACMACQAAAL4ADAAIAAMA IwAjACgABQABAgYACAAJABwAfgIKAAkAAAAbAAAALEABAgYACQABABwAAQIGAAkABQAcAP0A CgAJAAYAIgAFAAAAvgAMAAkABwAiACIAKQAJAH4CCgAKAAAAGwAAAC5AAQIGAAoAAQAcAAEC BgAKAAUAHAD9AAoACgAGACQAEwAAAL4ADAAKAAcAJAAkACcACQB+AgoACwAAABsAAAAwQAEC BgALAAEAHAABAgYACwAFABwA/QAKAAsABgAkABIAAAC+AAwACwAHACQAJAAnAAkAfgIKAAwA AAAtAAAAMUABAgYADAABABwAAQIGAAwABQAcAAECBgAMAAkAHAB+AgoADQAAABsAAAAyQAEC BgANAAEAHAD9AAoADQACACMACgAAAL4ADAANAAMAIwAjACgABQABAgYADQAJABwAfgIKAA4A AAAbAAAAM0ABAgYADgABABwA/QAKAA4ABQAsAAsAAAABAgYADgAGACUAAQIGAA4ACQAcAH4C CgAPAAAALQAAADRAAQIGAA8AAQAcAAECBgAPAAUAHAABAgYADwAJABwAfgIKABAAAAAbAAAA NUABAgYAEAABABwA/QAKABAAAgAjAAwAAAC+AAwAEAADACMAIwAoAAUAAQIGABAACQAcAH4C CgARAAAAGwAAADZAAQIGABEAAQAcAAECBgARAAUAHAD9AAoAEQAGACIADQAAAL4ADAARAAcA IgAiACkACQB+AgoAEgAAABsAAAA3QAECBgASAAEAHAABAgYAEgAFABwA/QAKABIABgAkABMA AAC+AAwAEgAHACQAJAAnAAkAfgIKABMAAAAbAAAAOEABAgYAEwABABwAAQIGABMABQAcAP0A CgATAAYAJAASAAAAvgAMABMABwAkACQAJwAJAH4CCgAUAAAALQAAADlAAQIGABQAAQAcAAEC BgAUAAUAHAABAgYAFAAJABwAfgIKABUAAAAbAAAAOkD9AAoAFQABACsADwAAAL4AGAAVAAIA KgAmACYAKwAqACYAJgArACoACgB+AgoAFgAAAC0AAAA7QAECBgAWAAEAHAABAgYAFgAFABwA AQIGABYACQAcAH4CCgAXAAAAGwAAADxAAQIGABcAAQAcAAECBgAXAAUAHAD9AAoAFwAGACIA FgAAAL4ADAAXAAcAIgAiACkACQB+AgoAGAAAABsAAAA9QAECBgAYAAEAHAABAgYAGAAFABwA /QAKABgABgAkABQAAAC+AAwAGAAHACQAJAAnAAkAfgIKABkAAAAtAAAAPkABAgYAGQABABwA AQIGABkABQAcAAECBgAZAAkAHAB+AgoAGgAAABsAAAA/QAECBgAaAAEAHAD9AAoAGgACACMA FwAAAL4ADAAaAAMAIwAjACgABQABAgYAGgAJABwAfgIKABsAAAAbAAAAQEABAgYAGwABABwA AQIGABsABQAcAP0ACgAbAAYAIgAGAAAAvgAMABsABwAiACIAKQAJAH4CCgAcAAAAGwAAgEBA AQIGABwAAQAcAAECBgAcAAUAHAD9AAoAHAAGACQAEwAAAL4ADAAcAAcAJAAkACcACQB+AgoA HQAAABsAAABBQAECBgAdAAEAHAABAgYAHQAFABwA/QAKAB0ABgAkABsAAAC+AAwAHQAHACQA JAAnAAkAfgIKAB4AAAAtAACAQUABAgYAHgABABwAAQIGAB4ABQAcAAECBgAeAAkAHAB+AgoA HwAAABsAAABCQAECBgAfAAEAHAD9AAoAHwACACMAGAAAAL4ADAAfAAMAIwAjACgABQABAgYA HwAJABwA1wBCAFoJAABYAhwASAAsADgAQABAACwAQABAAEAAQAAsAEAAOgAsAEAAQABAAEAA LAA4ACwAQABAACwAQABAAEAAQAAsAAgCEAAgAAAACgAsAQAAVDAAARIACAIQACEAAAAKACwB AAASAAEBAwAIAhAAIgAAAAoALAEAAAAAAQESAAgCEAAjAAAACgAsAQAAdgAAAQAACAIQACQA AAAKACwBAAD7fwABAgAIAhAAJQAAAAoALAEAAAAAAAEAAAgCEAAmAAAACgAsAQAAAAABAQAA CAIQACcAAAAKACwBAAASAAEBAgAIAhAAKAAAAAoALAEAAAAAAAESAAgCEAApAAAACgAsAQAA AAAAAQAAfgIKACAAAAAbAACAQkABAgYAIAABABwAAQIGACAABQAcAP0ACgAgAAYAIgAZAAAA vgAMACAABwAiACIAKQAJAH4CCgAhAAAAGwAAAENAAQIGACEAAQAcAAECBgAhAAUAHAD9AAoA IQAGACQAEwAAAL4ADAAhAAcAJAAkACcACQB+AgoAIgAAABsAAIBDQAECBgAiAAEAHAABAgYA IgAFABwA/QAKACIABgAkABUAAAC+AAwAIgAHACQAJAAnAAkAfgIKACMAAAAtAAAAREABAgYA IwABABwAAQIGACMABQAcAAECBgAjAAkAHAB+AgoAJAAAABsAAIBEQAECBgAkAAEAHAD9AAoA JAACACMAGgAAAL4ADAAkAAMAIwAjACgABQABAgYAJAAJABwAfgIKACUAAAAbAAAARUABAgYA JQABABwAAQIGACUABQAcAP0ACgAlAAYAIgAHAAAAvgAMACUABwAiACIAKQAJAH4CCgAmAAAA GwAAgEVAAQIGACYAAQAcAAECBgAmAAUAHAD9AAoAJgAGACQAEwAAAL4ADAAmAAcAJAAkACcA CQB+AgoAJwAAABsAAABGQAECBgAnAAEAHAABAgYAJwAFABwA/QAKACcABgAkABwAAAC+AAwA JwAHACQAJAAnAAkAfgIKACgAAAAtAACARkABAgYAKAABABwAAQIGACgABQAcAAECBgAoAAkA HAD9AAoAKQAAABoAAAAAAAECBgApAAEAHAABAgYAKQAFABwAAQIGACkACQAcANcAGAAMAwAA tABAAEAAQAAsAEAAQABAAEAALADsANAADwAC8GwHAAAgAAjwCAAAAA8AAAAOrAEADwAD8FQH AAAPAATwKAAAAAEACfAQAAAAAA4ADkBBAAkADgAOQEEACQIACvAIAAAAAKwBAAUAAAAPAATw eAAAAEIBCvAIAAAAAawBAEAKAABzAAvwPgAAAL8ACAAIAMABCAAACNEBAQAAANQBAAAAANUB AAAAAP8BCAAIAIDDFAAAAGQAZQBmAGEAcgByAG8AdwAxAAAAAAAQ8BIAAAAAAAYAAAAFALMA CgAAAAUAswAAABHwAAAAAF0AGgAVABIAAQABABEAAAAAALTnGwMAAAAAAAAAAOwAhgAPAATw fgAAAEIBCvAIAAAAAqwBAAAKAACDAAvwRAAAAL8ACAAIAMABCAAACM4BBwAAANEBAQAAANQB AAAAANUBAAAAAP8BCAAIAIDDFAAAAGQAZQBmAGEAcgByAG8AdwAyAAAAAAAQ8BIAAAAAAAIA AAAIALMABgAAAAgAswAAABHwAAAAAF0AGgAVABIAAQACABEAAAAAAFzoGwMAAAAAAAAAAOwA gAAPAATweAAAAEIBCvAIAAAAA6wBAAAKAABzAAvwPgAAAL8ACAAIAMABCAAACNEBAQAAANQB AAAAANUBAAAAAP8BCAAIAIDDFAAAAGQAZQBmAGEAcgByAG8AdwAxAAAAAAAQ8BIAAAAAAAYA AAAJALMACgAAAAkAswAAABHwAAAAAF0AGgAVABIAAQADABEAAAAAAATpGwMAAAAAAAAAAOwA hgAPAATwfgAAAEIBCvAIAAAABKwBAAAKAACDAAvwRAAAAL8ACAAIAMABCAAACM4BBwAAANEB AQAAANQBAAAAANUBAAAAAP8BCAAIAIDDFAAAAGQAZQBmAGEAcgByAG8AdwAyAAAAAAAQ8BIA AAAAAAIAAAANALMABgAAAA0AswAAABHwAAAAAF0AGgAVABIAAQAEABEAAAAAAMTpGwMAAAAA AAAAAOwAhgAPAATwfgAAAEIBCvAIAAAABawBAAAKAACDAAvwRAAAAL8ACAAIAMABCAAACM4B BwAAANEBAQAAANQBAAAAANUBAAAAAP8BCAAIAIDDFAAAAGQAZQBmAGEAcgByAG8AdwAyAAAA AAAQ8BIAAAAAAAIAAAAQALMABgAAABAAswAAABHwAAAAAF0AGgAVABIAAQAFABEAAAAAAITq GwMAAAAAAAAAAOwAgAAPAATweAAAAEIBCvAIAAAABqwBAAAKAABzAAvwPgAAAL8ACAAIAMAB CAAACNEBAQAAANQBAAAAANUBAAAAAP8BCAAIAIDDFAAAAGQAZQBmAGEAcgByAG8AdwAxAAAA AAAQ8BIAAAAAAAYAAAARALMACgAAABEAswAAABHwAAAAAF0AGgAVABIAAQAGABEAAAAAAETr GwMAAAAAAAAAAOwAgAAPAATweAAAAEIBCvAIAAAAB6wBAEAKAABzAAvwPgAAAL8ACAAIAMAB CAAACNEBAQAAANQBAAAAANUBAAAAAP8BCAAIAIDDFAAAAGQAZQBmAGEAcgByAG8AdwAxAAAA AAAQ8BIAAAAAAAYAAAAXALMACgAAABcAswAAABHwAAAAAF0AGgAVABIAAQAHABEAAAAAAFAP GwMAAAAAAAAAAOwAhgAPAATwfgAAAEIBCvAIAAAACKwBAAAKAACDAAvwRAAAAL8ACAAIAMAB CAAACM4BBwAAANEBAQAAANQBAAAAANUBAAAAAP8BCAAIAIDDFAAAAGQAZQBmAGEAcgByAG8A dwAyAAAAAAAQ8BIAAAAAAAIAAAAaALMABgAAABoAswAAABHwAAAAAF0AGgAVABIAAQAIABEA AAAAAPgPGwMAAAAAAAAAAOwAgAAPAATweAAAAEIBCvAIAAAACawBAAAKAABzAAvwPgAAAL8A CAAIAMABCAAACNEBAQAAANQBAAAAANUBAAAAAP8BCAAIAIDDFAAAAGQAZQBmAGEAcgByAG8A dwAxAAAAAAAQ8BIAAAAAAAYAAAAbALMACgAAABsAswAAABHwAAAAAF0AGgAVABIAAQAJABEA AAAAALgQGwMAAAAAAAAAAOwAhgAPAATwfgAAAEIBCvAIAAAACqwBAAAKAACDAAvwRAAAAL8A CAAIAMABCAAACM4BBwAAANEBAQAAANQBAAAAANUBAAAAAP8BCAAIAIDDFAAAAGQAZQBmAGEA cgByAG8AdwAyAAAAAAAQ8BIAAAAAAAIAAAAfALMABgAAAB8AswAAABHwAAAAAF0AGgAVABIA AQAKABEAAAAAAHgRGwMAAAAAAAAAAOwAgAAPAATweAAAAEIBCvAIAAAAC6wBAAAKAABzAAvw PgAAAL8ACAAIAMABCAAACNEBAQAAANQBAAAAANUBAAAAAP8BCAAIAIDDFAAAAGQAZQBmAGEA cgByAG8AdwAxAAAAAAAQ8BIAAAAAAAYAAAAgALMACgAAACAAswAAABHwAAAAAF0AGgAVABIA AQALABEAAAAAADgSGwMAAAAAAAAAAOwAhgAPAATwfgAAAEIBCvAIAAAADKwBAAAKAACDAAvw RAAAAL8ACAAIAMABCAAACM4BBwAAANEBAQAAANQBAAAAANUBAAAAAP8BCAAIAIDDFAAAAGQA ZQBmAGEAcgByAG8AdwAyAAAAAAAQ8BIAAAAAAAIAAAAkALMABgAAACQAswAAABHwAAAAAF0A GgAVABIAAQAMABEAAAAAAPgSGwMAAAAAAAAAAOwAgAAPAATweAAAAEIBCvAIAAAADawBAAAK AABzAAvwPgAAAL8ACAAIAMABCAAACNEBAQAAANQBAAAAANUBAAAAAP8BCAAIAIDDFAAAAGQA ZQBmAGEAcgByAG8AdwAxAAAAAAAQ8BIAAAAAAAYAAAAlALMACgAAACUAswAAABHwAAAAAF0A GgAVABIAAQANABEAAAAAALgTGwMAAAAAAAAAAOwAeAAPAATweAAAAKIMCvAIAAAADqwBAAAK AACTAAvwNgAAAIAAIIUpAr8ACAAKAFgBAAAAAIEBUAAACIMBUAAACL8BEAARAAECAAAAAD8C AwADAL8DAgAKAAAAEPASAAAAAwABAPgAAAAVAAUAMgIFAMAAAAAR8AAAAABdADQAFQASABkA DgARQCCFKQJ4FBsDAAAAAA0AFgCJSLffk4cER6Dvvq3CmOalAABYAQAAAAAAAOwACAAAAA3w AAAAALYBEgASAgAAAAAAAAAAtQAQAAAAAAA8ALYAAGZsb3dnZW5fMTA0YmV0YS54bHMgdiAx LjA0YmV0YSgyMDAtMTAwMDApCkRlZmF1bHQobG9jYWwpCmdlbmVyYXRlZDogMDEuMTAuMjAw MyAoMTM6MzYpCnlvdSBuZWVkIGhlbHA/IApjYWxsIFQuVm9pdGggMjU5LTQwMjkzCkR1cmF0 aW9uOiAwOjA0IFttaW46c2VjXQooIE5vTXNnTGluZXM6IDM5O1VwZEx2bDogLTEgKQo8ABAA AAAFAAQABQC1AAAAwPgaAxwAEQAAAAAAAAAOAAUAAFZvaXRoLj4CEgC8BwAAAABAAAAAAAAA AAAAAABBAAoAAAADAAMAQAACAB0ADwADAAAAAAAAAQAAAAAAAAAdAA8AAgAAAAAAAAEAAAAA AAAACgAAAAkIEAAABhAA8hXMB8kAAAAGAAAACwIUAAAAAAAAAAAAHAAAAOxFAABQTgAADQAC AAAADAACAGQADwACAAEAEQACAAAAEAAIAPyp8dJNYlA/XwACAAEAKgACAAAAKwACAAAAggAC AAEAgAAIAB0AAAACAAAAJQIEAAAALAGBAAIAAQUUAFcAVAAAJkwmOHByaW50ZWQ6ICZEICZU ICAgRmxvdyBnZW5lcmF0ZWQ6ICAwMS4xMC4yMDAzKDEzOjM1KSZDJjgmUC8mTiZSJjgmRiAg KHN0YXRpY19nZW4pFQAAAIMAAgAAAIQAAgAAACYACABMJpPJZDLJPycACABMJpPJZDLJPygA CAC5XC6Xy+XiPykACAC5XC6Xy+XiP00AogMAAFwAXABBAFMATABTAEQAQwAwAFwAbgAyADMA MQA3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBAIF3ADEAhN/AAgBAAkA 6gpvCGQAAQAPAFgCAQACAFgCAgAAAEwAZQB0AHQAZQByAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AQAAAAIAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAABQUklW4jAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAGAAAAAAAECcQJxAnAAAQJwAAAAAAAAAAAADEAgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAMAAAAAAAAAAAAQAFA0AwAoiAQAAAAAAAAAAAABAAEAAAAAAAAAAAAAAAAA AAAAAOFuT5UbAAAAAAAAAAAAAAAAAAAAAAACAAAAAAACAAQAAwABAAAAAAAAAAEAAAAAAAMA /wD/AAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAChACIACQBkAAEAAQAAAAIA WAJYAkwmk8lkMtk/TCaTyWQy2T8BAFUAAgAIAH0ADAAAAAAAxwIPAAYAAgB9AAwAAQAAAeMG DwACAAIAAAIOAAAAAAAcAAAAAAALAAAACAIQAAAAAAALAGgBAABUMAABEgAIAhAAAgAAAAsA /gEAABIAAAEDAAgCEAADAAAACwA7AQAAAAAAARIgCAIQAAQAAAALADsBAAASAAABEiAIAhAA BQAAAAsALAEAAPt/AAECRwgCEAAGAAAACwAsAQAAAAAAAQAACAIQAAcAAAALACwBAAAAAAEB AAAIAhAACAAAAAsALAEAABIAAQECAAgCEAAJAAAACwCjAgAAAAAAARIACAIQAAoAAAALACwB AAAAAAABOgAIAhAACwAAAAsALAEAABsDAAEAAAgCEAAMAAAACwAsAQAAGwMAARIACAIQAA0A AAALACwBAAASAAEBGwMIAhAADgAAAAsALAEAAAEAAQEAAAgCEAAPAAAACwAsAQAAGwMAARIA CAIQABAAAAALACwBAAAAAAABAAAIAhAAEQAAAAsALAEAABsDAAEAAAgCEAASAAAACwAsAQAA GwMBARsDCAIQABMAAAALACwBAAASAAEBAAAIAhAAFAAAAAsAOwEAAJ0wAAEAIAgCEAAVAAAA CwA7AQAAAAAAAQAgCAIQABYAAAALACwBAAAbAwABEgAIAhAAFwAAAAsALAEAAAAAAQEAAAgC EAAYAAAACwAsAQAAKwIBAQAACAIQABkAAAALADsBAAAbAwABEiAIAhAAGgAAAAsAOwEAAAAA AAEAIAgCEAAbAAAACwAsAQAAGwMAAQAA/QAKAAAAAQAeACsAAAC+AAoAAAACAB4AHgADAP0A CgACAAEAIAABAAAAAQIGAAIAAgAfAP0ACgACAAUAIQADAAAAAQIGAAIABgAhAP0ACgACAAkA IQACAAAAAQIGAAIACgAhAH4CCgADAAAALQAAACBAAQIGAAMAAQAdAAECBgADAAUAHQABAgYA AwAJAB0AfgIKAAQAAAAbAAAAIkD9AAoABAABACsAIAAAAL4AEAAEAAIAKgAmACYAKwAqAAYA AQIGAAQACQAcAH4CCgAFAAAAGwAAACRAAQIGAAUAAQAcAP0ACgAFAAIAIwAiAAAAvgAMAAUA AwAjACMAKAAFAAECBgAFAAkAHAB+AgoABgAAABsAAAAmQAECBgAGAAEAHAABAgYABgAFABwA /QAKAAYABgAiACMAAAC+AAwABgAHACIAIgApAAkAfgIKAAcAAAAbAAAAKEABAgYABwABABwA AQIGAAcABQAcAP0ACgAHAAYAJAAeAAAAvgAMAAcABwAkACQAJwAJAH4CCgAIAAAAGwAAACpA AQIGAAgAAQAcAAECBgAIAAUAHAD9AAoACAAGACQAHwAAAL4ADAAIAAcAJAAkACcACQB+AgoA CQAAABsAAAAsQAECBgAJAAEAHAD9AAoACQAFACwAJgAAAAECBgAJAAYAJQABAgYACQAJABwA fgIKAAoAAAAtAAAALkABAgYACgABABwAAQIGAAoABQAcAAECBgAKAAkAHAB+AgoACwAAABsA AAAwQAECBgALAAEAHAD9AAoACwACACMAJAAAAL4ADAALAAMAIwAjACgABQABAgYACwAJABwA fgIKAAwAAAAbAAAAMUABAgYADAABABwAAQIGAAwABQAcAP0ACgAMAAYAIgAIAAAAvgAMAAwA BwAiACIAKQAJAH4CCgANAAAAGwAAADJAAQIGAA0AAQAcAAECBgANAAUAHAD9AAoADQAGACQA EwAAAL4ADAANAAcAJAAkACcACQB+AgoADgAAABsAAAAzQAECBgAOAAEAHAABAgYADgAFABwA /QAKAA4ABgAkAB0AAAC+AAwADgAHACQAJAAnAAkAfgIKAA8AAAAtAAAANEABAgYADwABABwA AQIGAA8ABQAcAAECBgAPAAkAHAB+AgoAEAAAABsAAAA1QAECBgAQAAEAHAD9AAoAEAACACMA JQAAAL4ADAAQAAMAIwAjACgABQABAgYAEAAJABwAfgIKABEAAAAbAAAANkABAgYAEQABABwA AQIGABEABQAcAP0ACgARAAYAIgANAAAAvgAMABEABwAiACIAKQAJAH4CCgASAAAAGwAAADdA AQIGABIAAQAcAAECBgASAAUAHAD9AAoAEgAGACQAEwAAAL4ADAASAAcAJAAkACcACQB+AgoA EwAAABsAAAA4QAECBgATAAEAHAABAgYAEwAFABwA/QAKABMABgAkACEAAAC+AAwAEwAHACQA JAAnAAkAfgIKABQAAAAtAAAAOUABAgYAFAABABwAAQIGABQABQAcAAECBgAUAAkAHAB+AgoA FQAAABsAAAA6QP0ACgAVAAEAKwAnAAAAvgAYABUAAgAqACYAJgArACoAJgAmACsAKgAKAH4C CgAWAAAAGwAAADtAAQIGABYAAQAcAAECBgAWAAUAHAD9AAoAFgAGACIAFgAAAL4ADAAWAAcA IgAiACkACQB+AgoAFwAAABsAAAA8QAECBgAXAAEAHAABAgYAFwAFABwA/QAKABcABgAkACgA AAC+AAwAFwAHACQAJAAnAAkAfgIKABgAAAAbAAAAPUABAgYAGAABABwAAQIGABgABQAcAP0A CgAYAAYAJAApAAAAvgAMABgABwAkACQAJwAJAH4CCgAZAAAALQAAAD5AAQIGABkAAQAcAAEC BgAZAAUAHAABAgYAGQAJABwAfgIKABoAAAAbAAAAP0D9AAoAGgABACsAKgAAAL4AGAAaAAIA KgAmACYAKwAqACYAJgArACoACgD9AAoAGwAAABoAAAAAAAECBgAbAAEAHAABAgYAGwAFABwA AQIGABsACQAcANcAOgAsCAAACAIcAEgALAA6AEAAQABAAEAAOgAsAEAAQABAAEAALABAAEAA QABAACwAOABAAEAAQAAsADgA7ADWAA8AAvBaBAAAUAAI8AgAAAAJAAAACKgBAA8AA/BCBAAA DwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAACoAQAFAAAADwAE8H4A AABCAQrwCAAAAAGoAQAACgAAgwAL8EQAAAC/AAgACADAAQgAAAjOAQcAAADRAQEAAADUAQAA AADVAQAAAAD/AQgACACAwxQAAABkAGUAZgBhAHIAcgBvAHcAMgAAAAAAEPASAAAAAAACAAAA BQCzAAYAAAAFALMAAAAR8AAAAABdABoAFQASAAEAAQARAAAAAAD4TRsDAAAAAAAAAADsAIAA DwAE8HgAAABCAQrwCAAAAAKoAQBACgAAcwAL8D4AAAC/AAgACADAAQgAAAjRAQEAAADUAQAA AADVAQAAAAD/AQgACACAwxQAAABkAGUAZgBhAHIAcgBvAHcAMQAAAAAAEPASAAAAAAAGAAAA BgCzAAoAAAAGALMAAAAR8AAAAABdABoAFQASAAEAAgARAAAAAACgThsDAAAAAAAAAADsAIYA DwAE8H4AAABCAQrwCAAAAAOoAQAACgAAgwAL8EQAAAC/AAgACADAAQgAAAjOAQcAAADRAQEA AADUAQAAAADVAQAAAAD/AQgACACAwxQAAABkAGUAZgBhAHIAcgBvAHcAMgAAAAAAEPASAAAA AAACAAAACwCzAAYAAAALALMAAAAR8AAAAABdABoAFQASAAEAAwARAAAAAABITxsDAAAAAAAA AADsAIAADwAE8HgAAABCAQrwCAAAAASoAQAACgAAcwAL8D4AAAC/AAgACADAAQgAAAjRAQEA AADUAQAAAADVAQAAAAD/AQgACACAwxQAAABkAGUAZgBhAHIAcgBvAHcAMQAAAAAAEPASAAAA AAAGAAAADACzAAoAAAAMALMAAAAR8AAAAABdABoAFQASAAEABAARAAAAAADwTxsDAAAAAAAA AADsAIYADwAE8H4AAABCAQrwCAAAAAWoAQAACgAAgwAL8EQAAAC/AAgACADAAQgAAAjOAQcA AADRAQEAAADUAQAAAADVAQAAAAD/AQgACACAwxQAAABkAGUAZgBhAHIAcgBvAHcAMgAAAAAA EPASAAAAAAACAAAAEACzAAYAAAAQALMAAAAR8AAAAABdABoAFQASAAEABQARAAAAAACYUBsD AAAAAAAAAADsAIAADwAE8HgAAABCAQrwCAAAAAaoAQAACgAAcwAL8D4AAAC/AAgACADAAQgA AAjRAQEAAADUAQAAAADVAQAAAAD/AQgACACAwxQAAABkAGUAZgBhAHIAcgBvAHcAMQAAAAAA EPASAAAAAAAGAAAAEQCzAAoAAAARALMAAAAR8AAAAABdABoAFQASAAEABgARAAAAAABAURsD AAAAAAAAAADsAIAADwAE8HgAAABCAQrwCAAAAAeoAQBACgAAcwAL8D4AAAC/AAgACADAAQgA AAjRAQEAAADUAQAAAADVAQAAAAD/AQgACACAwxQAAABkAGUAZgBhAHIAcgBvAHcAMQAAAAAA EPASAAAAAAAGAAAAFgCzAAoAAAAWALMAAAAR8AAAAABdABoAFQASAAEABwARAAAAAADoURsD AAAAAAAAAADsAHgADwAE8HgAAACiDArwCAAAAAioAQAACgAAkwAL8DYAAACAAADXKQK/AAgA CgBYAQAAAACBAVAAAAiDAVAAAAi/ARAAEQABAgAAAAA/AgMAAwC/AwIACgAAABDwEgAAAAMA AQD4AAAAFQAFADICBQDAAAAAEfAAAAAAXQA0ABUAEgAZAAgAEUAA1ykCkFIbAwAAAAANABYA 9sShEu7bFUKydPQiIp7VCQAAWAEAAAAAAADsAAgAAAAN8AAAAAC2ARIAEgIAAAAAAAAAALUA EAAAAAAAPAC2AABmbG93Z2VuXzEwNGJldGEueGxzIHYgMS4wNGJldGEoMjAwLTEwMDAwKQpE ZWZhdWx0KGxvY2FsKQpnZW5lcmF0ZWQ6IDAxLjEwLjIwMDMgKDEzOjM1KQp5b3UgbmVlZCBo ZWxwPyAKY2FsbCBULlZvaXRoIDI1OS00MDI5MwpEdXJhdGlvbjogMDowNCBbbWluOnNlY10K KCBOb01zZ0xpbmVzOiAyNTtVcGRMdmw6IC0xICkKPAAQAAAABQAAAAAAtQAAAAAAAAAcABEA AAAAAAAACAAFAABWb2l0aC4+AhIAvAEAAAAAQAAAAAAAAAAAAAAAQQAKAAAAAwADAEAAAgAd AA8AAwAAAAAAAAEAAAAAAAAAHQAPAAIAAAAAAAABAAAAAAAAAAoAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFQAaABpAHMAVwBvAHIAawBiAG8A bwBrAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIBBgAAAAUA AAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGUEAAAAAAAA XwBWAEIAQQBfAFAAUgBPAEoARQBDAFQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAABoAAgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAASAAAAxwsAAAAAAABkAGkAcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAACAP///////////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEIAAABkAgAAAAAAAFAAUgBPAEoARQBDAFQA dwBtAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUAAIA ////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATAAAACkA AAAAAAAAARYBAAC2AP//AQEAAAAA/////wAAAAD///////8AAAEQwrwc35hKu9liKoPmyrkZ CAIAAAAAAMAAAAAAAABGAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAMAAAAFAAAABwAAAP////// ////AQEIAAAA/////3gAAADeAAAATwMAAPUBAAD/////AAAAAAEAAAANOc9dAAD//yMAAACI AAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//8AAGsDAADWAAAA1gAAAL8D AAAAAP////8AAAAA3wD//wAAAAAMAP////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////KAAAAAIAU0z///// AAABAFMQ/////wAAAQBTlP////8AAAAAAjz/////AAD//wEBAAAAAAEATgAwAHsAMAAwADAA MgAwADgAMQA5AC0AMAAwADAAMAAtADAAMAAwADAALQBDADAAMAAwAC0AMAAwADAAMAAwADAA MAAwADAAMAA0ADYAfQAAAAAAAADfBgAAADgAAAABAdgAAAACgf7///////////8oAAAAAAD/ /wAAAAAAAAAA//////////8BAAIAHQAAACQAAAD/////SAAAAP////8AAAAAAoP+//////8I AP//aAAAAAAA////////AAAAAP//////////bABzAB0ADAAkAAAAgqAUAv/////+////mAAA AAIA///+////AAAAAP//////////AAAAAB0ADAAkAAAAAoP+//////8IAP//yAAAAAAA//// ////AAAAAP//////////AAAAAB0ADAAkAAAA/////wgAAAAAAAAAAAABAAAAAAAAAP////// /////////wAAAAD/////////////////////AAAAAP//////////cAAAAKAAAAAAAAAAAAAA AEAABAAAAAAAaAJoAv////////////////////////////8IAAEA/////01FAAD///////8A AAAA//8AAAAA//8BAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+ygEAAAD/////AQEIAAAA/////3gAAAABorAAQXR0 cmlidXQAZSBWQl9OYW0AZSA9ICJUaGkAc1dvcmtib28QayINCgqMQmFzAQKMMHswMDAyMFA4 MTktABAwAwhDBwAUAhIBJDAwNDZ9AQ18Q3JlYXRhYoJsAYZGYWxzZQxeAFByZWRlY2xhiQAG SWQAi1RydQ0iQEV4cG9zZRQcVABlbXBsYXRlRDBlcml2AiQRZUN1wHN0b21pegSIAzIAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAzGFeAAABAP8HBAAACQQAAOQEAQAAAAAAAAAAAAEA BQACABYBKgBcAEcAewAwADAAMAAyADAANABFAEYALQAwADAAMAAwAC0AMAAwADAAMAAtAEMA MAAwADAALQAwADAAMAAwADAAMAAwADAAMAAwADQANgB9ACMAMwAuADAAIwA5ACMAQwA6AFwA UAByAG8AZwByAGEAbQAgAEYAaQBsAGUAcwBcAEMAbwBtAG0AbwBuACAARgBpAGwAZQBzAFwA TQBpAGMAcgBvAHMAbwBmAHQAIABTAGgAYQByAGUAZABcAFYAQgBBAFwAVgBCAEEAMwAzADIA LgBkAGwAbAAjAFYAaQBzAHUAYQBsACAAQgBhAHMAaQBjACAARgBvAHIAIABBAHAAcABsAGkA YwBhAHQAaQBvAG4AcwAAAAAAAAAAAAAAAADmACoAXABHAHsAMAAwADAAMgAwADgAMQAzAC0A MAAwADAAMAAtADAAMAAwADAALQBDADAAMAAwAC0AMAAwADAAMAAwADAAMAAwADAAMAA0ADYA fQAjADEALgAyACMAMAAjAEMAOgBcAGEAcABwAGwAXABvAGYAcAA5ADcAZQBcAE8AZgBmAGkA YwBlAFwARQBYAEMARQBMADgALgBPAEwAQgAjAE0AaQBjAHIAbwBzAG8AZgB0ACAARQB4AGMA ZQBsACAAOAAuADAAIABPAGIAagBlAGMAdAAgAEwAaQBiAHIAYQByAHkAAAAAAAAAAAAAAAAA uAAqAFwARwB7ADAAMAAwADIAMAA0ADMAMAAtADAAMAAwADAALQAwADAAMAAwAC0AQwAwADAA MAAtADAAMAAwADAAMAAwADAAMAAwADAANAA2AH0AIwAyAC4AMAAjADAAIwBDADoAXABXAEkA TgBOAFQAXABTAHkAcwB0AGUAbQAzADIAXABTAHQAZABPAGwAZQAyAC4AVABsAGIAIwBPAEwA RQAgAEEAdQB0AG8AbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAA4AAqAFwARwB7ADgAQQBEADEA NwA5AEQAMAAtAEQAOAA4ADMALQAxADEARAAzAC0AQgBEAEUAMwAtADAAMAA5ADAAMgA3ADkA MABCADMANABGAH0AIwAyAC4AMAAjADAAIwBDADoAXABXAEkATgBOAFQAXABTAHkAcwB0AGUA bQAzADIAXABNAFMARgBvAHIAbQBzAC4AVABXAEQAIwBNAGkAYwByAG8AcwBvAGYAdAAgAEYA bwByAG0AcwAgADIALgAwACAATwBiAGoAZQBjAHQAIABMAGkAYgByAGEAcgB5AAAAAAAAAAAA AAABANQAKgBcAEcAewA0ADYAMwA1ADcANAA5ADIALQBFADMAQgA0AC0AMQAxAEQAMwAtAEIA RABFAEQALQAwADAAOQAwADIANwA5ADAAQgAzADQARgB9ACMAMgAuADAAIwAwACMAQwA6AFwA VABFAE0AUABcAFYAQgBFAFwATQBTAEYAbwByAG0AcwAuAEUAWABEACMATQBpAGMAcgBvAHMA bwBmAHQAIABGAG8AcgBtAHMAIAAyAC4AMAAgAE8AYgBqAGUAYwB0ACAATABpAGIAcgBhAHIA eQAAAAAAAAAAAAAAAQAAAOEuRQ2P4BoQhS4CYIxNC7QAAOYAKgBcAEcAewAyAEQARgA4AEQA MAA0AEMALQA1AEIARgBBAC0AMQAwADEAQgAtAEIARABFADUALQAwADAAQQBBADAAMAA0ADQA RABFADUAMgB9ACMAMgAuADAAIwAwACMAQwA6AFwAYQBwAHAAbABcAG8AZgBwADkANwBlAFwA TwBmAGYAaQBjAGUAXABNAFMATwA5ADcALgBEAEwATAAjAE0AaQBjAHIAbwBzAG8AZgB0ACAA TwBmAGYAaQBjAGUAIAA4AC4AMAAgAE8AYgBqAGUAYwB0ACAATABpAGIAcgBhAHIAeQAAAAAA AAAAAAAAAAABAAIAAwAEAgAABgIBAAgCAAAQAv///////wAAAAD//wAAzbd6PwgA//////// //////////////////8AAP////////////////////////////////////////////////// /////wEAAAAAAAAAAAAAAAAAAAAAAAAADTkBABgAVABoAGkAcwBXAG8AcgBrAGIAbwBvAGsA CgA2M2YxZmMzNWIAAwAqRAEVAv//z10AAAAAAAAAAgAAAL8DAAD//xgCAAABATADAAD///// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////8AAgAA//////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////+dQum6n3KxOkDyYIYd2+Gn/////AQAAAFACAAAoAAAA lhcHY9Ui9Hv/////AAAAAFACAAAQAAAAr0dzO+flWN//////AAAAAP////8wAAAAcAIAABAA AACJLnt8EHOtPP////8AAAAA/////zACAACQAgAAEAAAAJ1M1tLDRVIw/////wAAAAD///// UAIAALACAAAQAAAAtFwExcXSumf/////AAAAAP////9wAgAA0AIAABAAAACcakysC0Un5/// //8AAAAA/////5ACAADwAgAAEAAAAIVXlYOOQqH5/////wAAAAD/////sAIAABADAAAQAAAA snbcWhJ+UqL/////AAAAAP/////QAgAA/////xAAAAC/kz5LsCsNEf////8AAAAA//////AC AACAAAAAAAAaARsA/wDAJwAABQRFeGNlbIArEAADBFZCQffiEAAFBFdpbjE2wX4QAAUEV2lu MzIHfxAAAwRNYWOzshAACAR0ZW1wbGF0Zeh/EAAGBHN0ZG9sZZNgEAAHAE1TRm9ybXNDDxAA CgRWQkFQcm9qZWN0vr8QAAYET2ZmaWNlFXUQAAwEVGhpc1dvcmtib29rfOMQAAmAAAD/AwEA X0V2YWx1YXRlGNkQAAYEU2hlZXQx6BoQAAYEU2hlZXQy6RoQAAYEU2hlZXQz6hoQAAYEU2hl ZXQ06xoQAAgEV29ya2Jvb2trGBAACQRXb3Jrc2hlZXTB/hAABwRTaGVldDMxa1AQAAcEU2hl ZXQyMUZQEAAHBFNoZWV0MjJHUBAACARTaGVldDIyMeYjEAAJBFNoZWV0MjIxMR3qEAAIBFNo ZWV0MjIy5yMQAAgEU2hlZXQyMjPoIxAACQRTaGVldDIyMjFC6hAACQRTaGVldDIyMzFn6hAA Av//AQFUAAAAFQIAAAAA////////////////////////AAIBAP//AgIAAP////////////// ////////////////////DAICAP//DgIDAP//EAL/////EgIEAP//AAAOAAAAAQASAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAWCygAEABAAAAAEAMCoCApAJAHAUBkgDAIICAGTkBAQACgAc AFZCQVByb2pliGN0BQA0AABAAhRqBgIKPQIKBwJyARQIBQYSCQISzbd6PwiUAAwCSjwCChYA AXKAc3Rkb2xlPgIZAHMAdABkAG8AgGwAZQANAGYAJQJcAAMqXEd7MDCAMDIwNDMwLQAIHQQE QwAKAg4BEjAwNAA2fSMyLjAjMAAjQzpcV0lOTgBUXFN5c3RlbQAzMlxTdGRPbABlMi5UbGIj TwBMRSBBdXRvbWBhdGlvbgBeAAEWBAAHgAJNU0ZvciBtcz4ADgEGAFMEAEYARXIAbQBz0AAv AHqACXCAAQFGADhBRDE3OUQwAC1EODgzLTExgEQzLUJERTMARgA5MDI3OTBCMww0RhdGBDMu VFdEACNNaWNyb3NvKGZ0IAI9IABgIE8CYgGwIExpYnJhHHJ5ADkAAR5QMACIDQATaoABAVA0 NjM1ADc0OTItRTNCCjQGUEQVUFRFTVAgXFZCRVyFJkVYAacm4S5FDY/gGgAQhS4CYIxNCwa0 QZJDdk9mZmljBUR2T0BzZgBpAGMVQnZ9wClzxCoyREYAOEQwNEMtNUKARkEtMTAxQgFTEjXA KkFBQHU0REUENTIIU2FwcGxcgG9mcDk3ZVwDGAFALU85Ny5ETExDiFODBiA4LjDSUw8RgrUB ABPCAQ05GQGCn1RoaXNXb3JAa2Jvb2saTgQyRAAYgCxUAGiAMXNEAFfChmsAYsABbxAAawAc wAYAAEgFQgExAry/AwAAHotCAgEFLEIaz10iQggKK0IBEEIBAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAFRoaXNXb3JrYm9vawBUAGgAaQBzAFcAbwByAGsAYgBvAG8AawAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABJRD0iezE1OUU5MUE1LUNDODUtNEE1MS04NDMxLUQzMDNB QUExMDI4N30iDQpEb2N1bWVudD1UaGlzV29ya2Jvb2svJkgwMDAwMDAwMA0KTmFtZT0iVkJB UHJvamVjdCINCkhlbHBDb250ZXh0SUQ9IjAiDQpDTUc9IjYxNjNDQzE0RDAxNEQwMTREMDE0 RDAiDQpEUEI9Ijk0OTYzOTcwNUZBMjYwQTI2MEEyIg0KR0M9IkM3QzU2QTQxQUU0N0VQAFIA TwBKAEUAQwBUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAEAACAQMAAAAHAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAE0AAADBAQAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIB/////woAAAD/////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVQAAANAAAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQA UwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgD///// //////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABZAAAAxAEAAAAA AAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAEgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAGEAAABmAAAAAAAAADA0OEUwNDgxRiINCg0KW0hvc3QgRXh0ZW5kZXIgSW5m b10NCiZIMDAwMDAwMDE9ezM4MzJENjQwLUNGOTAtMTFDRi04RTQzLTAwQTBDOTExMDA1QX07 VkJFOyZIMDAwMDAwMDANCg0KW1dvcmtzcGFjZV0NClRoaXNXb3JrYm9vaz0wLCAwLCAwLCAw LCBDDQpTaGVldDI9MCwgMCwgMCwgMCwgQw0KU2hlZXQzMT0wLCAwLCAwLCAwLCBDDQpTaGVl dDIxPTAsIDAsIDAsIDAsIEMNClNoZWV0MT0wLCAwLCAwLCAwLCBDDQpTaGVldDM9MCwgMCwg MCwgMCwgQw0KAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQAAgAAAAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQ q5EIACsns9kwAAAAoAAAAAcAAAABAAAAQAAAAAQAAABIAAAACAAAAFgAAAASAAAAaAAAAAsA AACAAAAADAAAAIwAAAATAAAAmAAAAAIAAADkBAAAHgAAAAYAAABWb2l0aABmAB4AAAAGAAAA Vm9pdGgAZgAeAAAAEAAAAE1pY3Jvc29mdCBFeGNlbABAAAAAABxPYQ6IwwFAAAAAACeTFh3u wgEDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAP7/AAAEAAIAAAAAAAAAAAAAAAAAAAAAAAIAAAAC1c3VnC4bEJOXCAArLPmuRAAAAAXV zdWcLhsQk5cIACss+a4sAQAA6AAAAAkAAAABAAAAUAAAAA8AAABYAAAAFwAAAHAAAAALAAAA eAAAABAAAACAAAAAEwAAAIgAAAAWAAAAkAAAAA0AAACYAAAADAAAAMQAAAACAAAA5AQAAB4A AAAPAAAAQWxjYXRlbCBTRUwgQUcAAAMAAAAxFQgACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAA CwAAAAAAAAAeEAAAAgAAAA8AAABzdGF0aWNfb25fb2ZfbwANAAAAc3RhdGljX2dlbl9vAAwQ AAACAAAAHgAAAAsAAABXb3Jrc2hlZXRzAAMAAAACAAAAAJgAAAADAAAAAAAAACAAAAABAAAA NgAAAAIAAAA+AAAAAQAAAAIAAAAKAAAAX1BJRF9HVUlEAAIAAADkBAAAQQAAAE4AAAB7ADIA MgA5AEIANAA5AEUARQAtADMAOQAzADkALQA0ADQARABEAC0AQgBBAEEANAAtADkAMwA5AEYA NwAxADQAOQAzADEAQwA1AH0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQD+/wMKAAD/////IAgCAAAAAADAAAAA AAAARhoAAABNaWNyb3NvZnQgRXhjZWwgV29ya3NoZWV0AAYAAABCaWZmOAAOAAAARXhjZWwu U2hlZXQuOAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== --------------11B76428C1EED84E9C6F850E-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Oct 1 13:15:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24218 for ; Wed, 1 Oct 2003 13:15:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4kZ4-0007IM-Vu; Wed, 01 Oct 2003 13:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4kQc-0006CJ-0j for megaco@optimus.ietf.org; Wed, 01 Oct 2003 13:06:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23749 for ; Wed, 1 Oct 2003 13:06:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4kQa-0002FV-00 for megaco@ietf.org; Wed, 01 Oct 2003 13:06:16 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx with esmtp (Exim 4.12) id 1A4kQZ-0002F5-00 for megaco@ietf.org; Wed, 01 Oct 2003 13:06:15 -0400 Received: from FTRDMEL1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 1 Oct 2003 19:05:44 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3883E.3FC8C04E" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Wed, 1 Oct 2003 19:05:43 +0200 Message-ID: <869954804BD53B41AF69F225F15FC3315EE1A2@ftrdmel1.rd.francetelecom.fr> Thread-Topic: Service Change and Testing Thread-Index: AcOIPjh70IeLF5eKSYKQ/0cwQvBFfA== From: "CHATRAS Bruno FTRD/DAC/ISS" To: X-OriginalArrivalTime: 01 Oct 2003 17:05:44.0500 (UTC) FILETIME=[40526F40:01C3883E] Subject: [Megaco] Service Change and Testing Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3883E.3FC8C04E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 H.248 defines three values for the Termination State descriptor ("in service", "out of service" and "test"). The ServiceChange procedures allows the MG to notify the MGC when a termination is about to be taken out of service (or is being returned to service). It seems that there is not equivalent procedure when a termination is about to be tested (i.e. termination state =3D test) and is therefore not available for normal traffic. Is there a specific reason for treating these two states differently or is just that the wording "out of service" in the ServiceChange description encompasses both the "test" and "out of service" termination states. If this is the case, I think a clarification in the IG guide might be useful. =20 Regards, BC ------_=_NextPart_001_01C3883E.3FC8C04E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi,
 
H.248 = defines three=20 values for the Termination State descriptor ("in service", "out of = service" and=20 "test"). The ServiceChange procedures allows the MG to notify the MGC = when a=20 termination is about to be taken out of service (or is being returned to = service). It seems that there is not equivalent procedure when a = termination is=20 about to be tested (i.e. termination state =3D test) and is therefore = not=20 available for normal traffic. Is there a specific reason for treating = these two=20 states differently or is just that the wording "out of service" in the=20 ServiceChange description encompasses both the "test" and "out of = service"=20 termination states. If this is the case, I think a clarification in the = IG guide=20 might be useful.
 
Regards,
BC
------_=_NextPart_001_01C3883E.3FC8C04E-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Oct 1 13:15:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24233 for ; Wed, 1 Oct 2003 13:15:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4kZ8-0007J9-7G for megaco-archive@odin.ietf.org; Wed, 01 Oct 2003 13:15:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h91HF6fk028087 for megaco-archive@odin.ietf.org; Wed, 1 Oct 2003 13:15:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4kZ8-0007Iw-1w for megaco-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 13:15:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24192 for ; Wed, 1 Oct 2003 13:14:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4kZ6-0002Ol-00 for megaco-web-archive@ietf.org; Wed, 01 Oct 2003 13:15:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4kZ5-0002Oi-00 for megaco-web-archive@ietf.org; Wed, 01 Oct 2003 13:15:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4kZ4-0007IM-Vu; Wed, 01 Oct 2003 13:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4kQc-0006CJ-0j for megaco@optimus.ietf.org; Wed, 01 Oct 2003 13:06:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23749 for ; Wed, 1 Oct 2003 13:06:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4kQa-0002FV-00 for megaco@ietf.org; Wed, 01 Oct 2003 13:06:16 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx with esmtp (Exim 4.12) id 1A4kQZ-0002F5-00 for megaco@ietf.org; Wed, 01 Oct 2003 13:06:15 -0400 Received: from FTRDMEL1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 1 Oct 2003 19:05:44 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3883E.3FC8C04E" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Wed, 1 Oct 2003 19:05:43 +0200 Message-ID: <869954804BD53B41AF69F225F15FC3315EE1A2@ftrdmel1.rd.francetelecom.fr> Thread-Topic: Service Change and Testing Thread-Index: AcOIPjh70IeLF5eKSYKQ/0cwQvBFfA== From: "CHATRAS Bruno FTRD/DAC/ISS" To: X-OriginalArrivalTime: 01 Oct 2003 17:05:44.0500 (UTC) FILETIME=[40526F40:01C3883E] Subject: [Megaco] Service Change and Testing Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3883E.3FC8C04E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 H.248 defines three values for the Termination State descriptor ("in service", "out of service" and "test"). The ServiceChange procedures allows the MG to notify the MGC when a termination is about to be taken out of service (or is being returned to service). It seems that there is not equivalent procedure when a termination is about to be tested (i.e. termination state =3D test) and is therefore not available for normal traffic. Is there a specific reason for treating these two states differently or is just that the wording "out of service" in the ServiceChange description encompasses both the "test" and "out of service" termination states. If this is the case, I think a clarification in the IG guide might be useful. =20 Regards, BC ------_=_NextPart_001_01C3883E.3FC8C04E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi,
 
H.248 = defines three=20 values for the Termination State descriptor ("in service", "out of = service" and=20 "test"). The ServiceChange procedures allows the MG to notify the MGC = when a=20 termination is about to be taken out of service (or is being returned to = service). It seems that there is not equivalent procedure when a = termination is=20 about to be tested (i.e. termination state =3D test) and is therefore = not=20 available for normal traffic. Is there a specific reason for treating = these two=20 states differently or is just that the wording "out of service" in the=20 ServiceChange description encompasses both the "test" and "out of = service"=20 termination states. If this is the case, I think a clarification in the = IG guide=20 might be useful.
 
Regards,
BC
------_=_NextPart_001_01C3883E.3FC8C04E-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Oct 1 13:45:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25291 for ; Wed, 1 Oct 2003 13:45:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4l26-0000OL-4c; Wed, 01 Oct 2003 13:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4l1P-0000L8-DY for megaco@optimus.ietf.org; Wed, 01 Oct 2003 13:44:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25222 for ; Wed, 1 Oct 2003 13:44:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4l1N-0002f8-00 for megaco@ietf.org; Wed, 01 Oct 2003 13:44:17 -0400 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1A4l1M-0002es-00 for megaco@ietf.org; Wed, 01 Oct 2003 13:44:16 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h91Hhjh12224 for ; Wed, 1 Oct 2003 13:43:45 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Oct 2003 13:43:46 -0400 Message-ID: From: "Kevin Boyle" To: CHATRAS Bruno FTRD/DAC/ISS , megaco@ietf.org Subject: RE: [Megaco] Service Change and Testing Date: Wed, 1 Oct 2003 13:43:44 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , I have noticed this same discrepancy. The problem is that the MGC is allowed to set the ServiceStates parm utilizing a Modify command, while the MG has no such capability (it must utilize ServiceChange). Therefore, there is no way for the MG to set the term into the Test state. In the Annex F work at the most recent Q3 meeting, I raised the idea of restricting the SI parm to being Read-only, and mandating that state changes must utilize ServiceChange (in both directions). This would also require a new Method to set the term to Test. The big problem is that this is a change from the current function, and may have to wait until V3 due to the parsing change with the Method parm (unless there is wide acceptance to push this into earlier versions...) This simplifies the termination state model by removing the ability to change the parm in two different, competing ways. It also provides the MG the capability of setting the term into Test (which I think has value and utility). Comments? Kevin -----Original Message----- From: CHATRAS Bruno FTRD/DAC/ISS [mailto:bruno.chatras@francetelecom.com] Sent: Wednesday, October 01, 2003 1:06 PM To: megaco@ietf.org Subject: [Megaco] Service Change and Testing Hi, H.248 defines three values for the Termination State descriptor ("in service", "out of service" and "test"). The ServiceChange procedures allows the MG to notify the MGC when a termination is about to be taken out of service (or is being returned to service). It seems that there is not equivalent procedure when a termination is about to be tested (i.e. termination state = test) and is therefore not available for normal traffic. Is there a specific reason for treating these two states differently or is just that the wording "out of service" in the ServiceChange description encompasses both the "test" and "out of service" termination states. If this is the case, I think a clarification in the IG guide might be useful. Regards, BC _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Oct 1 13:45:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25306 for ; Wed, 1 Oct 2003 13:45:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4l2B-0000PS-8h for megaco-archive@odin.ietf.org; Wed, 01 Oct 2003 13:45:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h91Hj7Ei001568 for megaco-archive@odin.ietf.org; Wed, 1 Oct 2003 13:45:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4l2B-0000PD-5E for megaco-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 13:45:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25274 for ; Wed, 1 Oct 2003 13:44:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4l28-0002gG-00 for megaco-web-archive@ietf.org; Wed, 01 Oct 2003 13:45:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4l28-0002gD-00 for megaco-web-archive@ietf.org; Wed, 01 Oct 2003 13:45:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4l26-0000OL-4c; Wed, 01 Oct 2003 13:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4l1P-0000L8-DY for megaco@optimus.ietf.org; Wed, 01 Oct 2003 13:44:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25222 for ; Wed, 1 Oct 2003 13:44:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4l1N-0002f8-00 for megaco@ietf.org; Wed, 01 Oct 2003 13:44:17 -0400 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1A4l1M-0002es-00 for megaco@ietf.org; Wed, 01 Oct 2003 13:44:16 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h91Hhjh12224 for ; Wed, 1 Oct 2003 13:43:45 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Oct 2003 13:43:46 -0400 Message-ID: From: "Kevin Boyle" To: CHATRAS Bruno FTRD/DAC/ISS , megaco@ietf.org Subject: RE: [Megaco] Service Change and Testing Date: Wed, 1 Oct 2003 13:43:44 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , I have noticed this same discrepancy. The problem is that the MGC is allowed to set the ServiceStates parm utilizing a Modify command, while the MG has no such capability (it must utilize ServiceChange). Therefore, there is no way for the MG to set the term into the Test state. In the Annex F work at the most recent Q3 meeting, I raised the idea of restricting the SI parm to being Read-only, and mandating that state changes must utilize ServiceChange (in both directions). This would also require a new Method to set the term to Test. The big problem is that this is a change from the current function, and may have to wait until V3 due to the parsing change with the Method parm (unless there is wide acceptance to push this into earlier versions...) This simplifies the termination state model by removing the ability to change the parm in two different, competing ways. It also provides the MG the capability of setting the term into Test (which I think has value and utility). Comments? Kevin -----Original Message----- From: CHATRAS Bruno FTRD/DAC/ISS [mailto:bruno.chatras@francetelecom.com] Sent: Wednesday, October 01, 2003 1:06 PM To: megaco@ietf.org Subject: [Megaco] Service Change and Testing Hi, H.248 defines three values for the Termination State descriptor ("in service", "out of service" and "test"). The ServiceChange procedures allows the MG to notify the MGC when a termination is about to be taken out of service (or is being returned to service). It seems that there is not equivalent procedure when a termination is about to be tested (i.e. termination state = test) and is therefore not available for normal traffic. Is there a specific reason for treating these two states differently or is just that the wording "out of service" in the ServiceChange description encompasses both the "test" and "out of service" termination states. If this is the case, I think a clarification in the IG guide might be useful. Regards, BC _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Oct 1 23:57:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17735 for ; Wed, 1 Oct 2003 23:57:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4uaK-0000nO-Kk; Wed, 01 Oct 2003 23:57:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4uaG-0000n5-D4 for megaco@optimus.ietf.org; Wed, 01 Oct 2003 23:56:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17711 for ; Wed, 1 Oct 2003 23:56:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4uaE-0001us-00 for megaco@ietf.org; Wed, 01 Oct 2003 23:56:54 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 1A4uaD-0001uI-00 for megaco@ietf.org; Wed, 01 Oct 2003 23:56:53 -0400 Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h923rYt28292; Thu, 2 Oct 2003 13:53:34 +1000 (EST) Received: from ericsson.com.au (146.11.245.248 [146.11.245.248]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SYC1ZVW9; Thu, 2 Oct 2003 13:55:41 +1000 Message-ID: <3F7BA0FF.30607@ericsson.com.au> Date: Thu, 02 Oct 2003 13:52:31 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Voith CC: megaco@ietf.org, tsg16q3@itu.int References: <3F7ABFEE.48753D6F@alcatel.de> In-Reply-To: <3F7ABFEE.48753D6F@alcatel.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Megaco] Re: Event descriptor handling for static logic interfaces like CAS Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Thomas, Are you wanting a general purpose mechanism such as the off-hook one or do you just want the default stated for H.248.26 and H.246.ICASC? Kevin Boyle is the editor of these he may have some opinion on this. Its always possible to make amendments to existing recommendations. Bring in a contribution for consideration to SG16 or propose a detailed solution on the Megaco list for experts to review. If they are agreeable then the change will be added. Regards, Christian Thomas Voith wrote: > Dear list-members, > > H.248.26 and in H.248.ICAS I miss a feature, which has been used > already for On-Hook, Off-Hook the 'strict' parameter. > > All interfaces, which have static states, should implement such > a mechanism. > > The problem is that the EventsDescriptor EventBufferDescriptor or an > embedded EventsDescriptor may discard events, if the newly received or > replacing Event Descriptor does not match the event. > > In the Megaco Secnarios, always just the good case is shown. > > e.g. a static interface with 4 logical incoming events ( S1,S2,S3,S4) > would then set the EventsDescripror like: > > MGC guess the MG is in state i1, no Notify will be sent by MG, when > state of interface is still i1. > > Events { S1{strict="exact"},S2{strict="state"},S3{strict="state"},S4{strict="state"} } > > ( Note: in case "state" is the default, then EventsDescriptor could be shorter) > > The events descriptor remains active, after Notification is sent. > The strict parameter avoids unnecessary Notifications for the already by MGC known state. > > This mechanism would be very simple and avoids lost of any events, which is strong > required for signalling interfaces on MG transferred via H.248 to an MGC. > > > For a better illustration I have attached a Excel-File containing a simple scenario. > > So my question/proposal is: > > - Is it possible to extend the existing static state interfacepackages like H.248.26 with this > strict feature? > - If not, can I get this functionality otherwise ? > > Kind regards > > Thomas Voith > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Oct 1 23:57:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17757 for ; Wed, 1 Oct 2003 23:57:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4uaN-0000oJ-Jp for megaco-archive@odin.ietf.org; Wed, 01 Oct 2003 23:57:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h923v3Sm003109 for megaco-archive@odin.ietf.org; Wed, 1 Oct 2003 23:57:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4uaN-0000o4-Fz for megaco-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 23:57:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17718 for ; Wed, 1 Oct 2003 23:56:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4uaL-0001v4-00 for megaco-web-archive@ietf.org; Wed, 01 Oct 2003 23:57:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4uaK-0001v1-00 for megaco-web-archive@ietf.org; Wed, 01 Oct 2003 23:57:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4uaK-0000nO-Kk; Wed, 01 Oct 2003 23:57:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4uaG-0000n5-D4 for megaco@optimus.ietf.org; Wed, 01 Oct 2003 23:56:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17711 for ; Wed, 1 Oct 2003 23:56:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4uaE-0001us-00 for megaco@ietf.org; Wed, 01 Oct 2003 23:56:54 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 1A4uaD-0001uI-00 for megaco@ietf.org; Wed, 01 Oct 2003 23:56:53 -0400 Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h923rYt28292; Thu, 2 Oct 2003 13:53:34 +1000 (EST) Received: from ericsson.com.au (146.11.245.248 [146.11.245.248]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SYC1ZVW9; Thu, 2 Oct 2003 13:55:41 +1000 Message-ID: <3F7BA0FF.30607@ericsson.com.au> Date: Thu, 02 Oct 2003 13:52:31 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Voith CC: megaco@ietf.org, tsg16q3@itu.int References: <3F7ABFEE.48753D6F@alcatel.de> In-Reply-To: <3F7ABFEE.48753D6F@alcatel.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Megaco] Re: Event descriptor handling for static logic interfaces like CAS Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Thomas, Are you wanting a general purpose mechanism such as the off-hook one or do you just want the default stated for H.248.26 and H.246.ICASC? Kevin Boyle is the editor of these he may have some opinion on this. Its always possible to make amendments to existing recommendations. Bring in a contribution for consideration to SG16 or propose a detailed solution on the Megaco list for experts to review. If they are agreeable then the change will be added. Regards, Christian Thomas Voith wrote: > Dear list-members, > > H.248.26 and in H.248.ICAS I miss a feature, which has been used > already for On-Hook, Off-Hook the 'strict' parameter. > > All interfaces, which have static states, should implement such > a mechanism. > > The problem is that the EventsDescriptor EventBufferDescriptor or an > embedded EventsDescriptor may discard events, if the newly received or > replacing Event Descriptor does not match the event. > > In the Megaco Secnarios, always just the good case is shown. > > e.g. a static interface with 4 logical incoming events ( S1,S2,S3,S4) > would then set the EventsDescripror like: > > MGC guess the MG is in state i1, no Notify will be sent by MG, when > state of interface is still i1. > > Events { S1{strict="exact"},S2{strict="state"},S3{strict="state"},S4{strict="state"} } > > ( Note: in case "state" is the default, then EventsDescriptor could be shorter) > > The events descriptor remains active, after Notification is sent. > The strict parameter avoids unnecessary Notifications for the already by MGC known state. > > This mechanism would be very simple and avoids lost of any events, which is strong > required for signalling interfaces on MG transferred via H.248 to an MGC. > > > For a better illustration I have attached a Excel-File containing a simple scenario. > > So my question/proposal is: > > - Is it possible to extend the existing static state interfacepackages like H.248.26 with this > strict feature? > - If not, can I get this functionality otherwise ? > > Kind regards > > Thomas Voith > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Oct 2 04:12:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07136 for ; Thu, 2 Oct 2003 04:12:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4yZ7-0006g5-Iw; Thu, 02 Oct 2003 04:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4yYi-0006fb-3N for megaco@optimus.ietf.org; Thu, 02 Oct 2003 04:11:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07109 for ; Thu, 2 Oct 2003 04:11:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4yYf-0004Wh-00 for megaco@ietf.org; Thu, 02 Oct 2003 04:11:33 -0400 Received: from mailrelay1.alcatel.de ([194.113.59.75] helo=mailrelay2.alcatel.de) by ietf-mx with esmtp (Exim 4.12) id 1A4yYe-0004Wd-00 for megaco@ietf.org; Thu, 02 Oct 2003 04:11:32 -0400 Received: from ks.sel.alcatel.de (slsv0d.stgl.sel.alcatel.de [149.204.14.10]) by mailrelay2.alcatel.de (8.12.10/8.12.9) with ESMTP id h927uKTC018634; Thu, 2 Oct 2003 09:56:20 +0200 (MET DST) Received: from slssiv ([149.204.245.89] helo=slsdtk.stgl.sel.alcatel.de) by ks.sel.alcatel.de with esmtp (Exim 3.31) id 1A4yN4-0000TY-00; Thu, 02 Oct 2003 09:59:34 +0200 Received: from sls0gf.stgl.sel.alcatel.de ([149.204.201.220] helo=alcatel.de) by slsdtk.stgl.sel.alcatel.de with esmtp (Exim 3.31) id 1A4yN4-0003HI-00; Thu, 02 Oct 2003 09:59:34 +0200 Message-ID: <3F7BDAE5.93080507@alcatel.de> Date: Thu, 02 Oct 2003 09:59:33 +0200 From: Thomas Voith X-Mailer: Mozilla 4.77 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en,de MIME-Version: 1.0 To: Christian Groves CC: megaco@ietf.org, ITU-SG16@external.cisco.com Subject: Re: [Megaco] Re: Event descriptor handling for static logic interfaces like CAS References: <3F7ABFEE.48753D6F@alcatel.de> <3F7BA0FF.30607@ericsson.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Alcanet-virus-scanned: h927uKTC018634 at mailrelay2.alcatel.de Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Christian I want both, - strict parameter for CAS Line signals and in future for all 'static'signalling interfaces. - optionally a default strict="state" to shorten the Events Descriptor In my opinion, this should be used for all 'static' signalling interfaces. With 'static' I mean that this interface has always a state, when MG receives an EventsDescriptor from MGC. For synchronizing the states from MGC with MG the strict mechanism is very useful. Doing the same with EventBuffer, Embedded Descriptor is much more complex and increases extreme with the number of possible states on the interface. Note: This 'strict' parameter is just used by MG to determine, whether a Notify for the existing state on the interface has to be sent or not. Further on normal event handling applies. This approach has the advantage, that EventBuffer and Embedded can still be used in addition. For all 'dynamic' events like pulses, DTMF, SPCM, normal event handling applies. Best regards Thomas Christian Groves wrote: > > Hello Thomas, > > Are you wanting a general purpose mechanism such as the off-hook one or do you > just want the default stated for H.248.26 and H.246.ICASC? > > Kevin Boyle is the editor of these he may have some opinion on this. > > Its always possible to make amendments to existing recommendations. Bring in a > contribution for consideration to SG16 or propose a detailed solution on the > Megaco list for experts to review. If they are agreeable then the change will be > added. > > Regards, Christian > > Thomas Voith wrote: > > > Dear list-members, > > > > H.248.26 and in H.248.ICAS I miss a feature, which has been used > > already for On-Hook, Off-Hook the 'strict' parameter. > > > > All interfaces, which have static states, should implement such > > a mechanism. > > > > The problem is that the EventsDescriptor EventBufferDescriptor or an > > embedded EventsDescriptor may discard events, if the newly received or > > replacing Event Descriptor does not match the event. > > > > In the Megaco Secnarios, always just the good case is shown. > > > > e.g. a static interface with 4 logical incoming events ( S1,S2,S3,S4) > > would then set the EventsDescripror like: > > > > MGC guess the MG is in state i1, no Notify will be sent by MG, when > > state of interface is still i1. > > > > Events { S1{strict="exact"},S2{strict="state"},S3{strict="state"},S4{strict="state"} } > > > > ( Note: in case "state" is the default, then EventsDescriptor could be shorter) > > > > The events descriptor remains active, after Notification is sent. > > The strict parameter avoids unnecessary Notifications for the already by MGC known state. > > > > This mechanism would be very simple and avoids lost of any events, which is strong > > required for signalling interfaces on MG transferred via H.248 to an MGC. > > > > > > For a better illustration I have attached a Excel-File containing a simple scenario. > > > > So my question/proposal is: > > > > - Is it possible to extend the existing static state interfacepackages like H.248.26 with this > > strict feature? > > - If not, can I get this functionality otherwise ? > > > > Kind regards > > > > Thomas Voith > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco -- _______________________________________________________________ _ V | Thomas Voith +---------------+ | Dept. VS/EAC2 [Systems] | A L C A T E L | | FL/2/50 +---------------+ | | Tel: +49 711 821-40293 | Alcanet: 259-40293 Alcatel SEL AG | Fax: +49 711 821-40211 Fixed Networks Division | Lorenzstr. 10 | mailto:Thomas.Voith@alcatel.de D-70435 Stuttgart, Germany | _______________________________________________________________ _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Oct 2 04:12:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07151 for ; Thu, 2 Oct 2003 04:12:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4yZC-0006gq-5X for megaco-archive@odin.ietf.org; Thu, 02 Oct 2003 04:12:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h928C6DO025710 for megaco-archive@odin.ietf.org; Thu, 2 Oct 2003 04:12:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4yZB-0006gb-HI for megaco-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 04:12:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07130 for ; Thu, 2 Oct 2003 04:11:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4yZ8-0004Wu-00 for megaco-web-archive@ietf.org; Thu, 02 Oct 2003 04:12:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4yZ8-0004Wr-00 for megaco-web-archive@ietf.org; Thu, 02 Oct 2003 04:12:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4yZ7-0006g5-Iw; Thu, 02 Oct 2003 04:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4yYi-0006fb-3N for megaco@optimus.ietf.org; Thu, 02 Oct 2003 04:11:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07109 for ; Thu, 2 Oct 2003 04:11:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4yYf-0004Wh-00 for megaco@ietf.org; Thu, 02 Oct 2003 04:11:33 -0400 Received: from mailrelay1.alcatel.de ([194.113.59.75] helo=mailrelay2.alcatel.de) by ietf-mx with esmtp (Exim 4.12) id 1A4yYe-0004Wd-00 for megaco@ietf.org; Thu, 02 Oct 2003 04:11:32 -0400 Received: from ks.sel.alcatel.de (slsv0d.stgl.sel.alcatel.de [149.204.14.10]) by mailrelay2.alcatel.de (8.12.10/8.12.9) with ESMTP id h927uKTC018634; Thu, 2 Oct 2003 09:56:20 +0200 (MET DST) Received: from slssiv ([149.204.245.89] helo=slsdtk.stgl.sel.alcatel.de) by ks.sel.alcatel.de with esmtp (Exim 3.31) id 1A4yN4-0000TY-00; Thu, 02 Oct 2003 09:59:34 +0200 Received: from sls0gf.stgl.sel.alcatel.de ([149.204.201.220] helo=alcatel.de) by slsdtk.stgl.sel.alcatel.de with esmtp (Exim 3.31) id 1A4yN4-0003HI-00; Thu, 02 Oct 2003 09:59:34 +0200 Message-ID: <3F7BDAE5.93080507@alcatel.de> Date: Thu, 02 Oct 2003 09:59:33 +0200 From: Thomas Voith X-Mailer: Mozilla 4.77 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en,de MIME-Version: 1.0 To: Christian Groves CC: megaco@ietf.org, ITU-SG16@external.cisco.com Subject: Re: [Megaco] Re: Event descriptor handling for static logic interfaces like CAS References: <3F7ABFEE.48753D6F@alcatel.de> <3F7BA0FF.30607@ericsson.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Alcanet-virus-scanned: h927uKTC018634 at mailrelay2.alcatel.de Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Christian I want both, - strict parameter for CAS Line signals and in future for all 'static'signalling interfaces. - optionally a default strict="state" to shorten the Events Descriptor In my opinion, this should be used for all 'static' signalling interfaces. With 'static' I mean that this interface has always a state, when MG receives an EventsDescriptor from MGC. For synchronizing the states from MGC with MG the strict mechanism is very useful. Doing the same with EventBuffer, Embedded Descriptor is much more complex and increases extreme with the number of possible states on the interface. Note: This 'strict' parameter is just used by MG to determine, whether a Notify for the existing state on the interface has to be sent or not. Further on normal event handling applies. This approach has the advantage, that EventBuffer and Embedded can still be used in addition. For all 'dynamic' events like pulses, DTMF, SPCM, normal event handling applies. Best regards Thomas Christian Groves wrote: > > Hello Thomas, > > Are you wanting a general purpose mechanism such as the off-hook one or do you > just want the default stated for H.248.26 and H.246.ICASC? > > Kevin Boyle is the editor of these he may have some opinion on this. > > Its always possible to make amendments to existing recommendations. Bring in a > contribution for consideration to SG16 or propose a detailed solution on the > Megaco list for experts to review. If they are agreeable then the change will be > added. > > Regards, Christian > > Thomas Voith wrote: > > > Dear list-members, > > > > H.248.26 and in H.248.ICAS I miss a feature, which has been used > > already for On-Hook, Off-Hook the 'strict' parameter. > > > > All interfaces, which have static states, should implement such > > a mechanism. > > > > The problem is that the EventsDescriptor EventBufferDescriptor or an > > embedded EventsDescriptor may discard events, if the newly received or > > replacing Event Descriptor does not match the event. > > > > In the Megaco Secnarios, always just the good case is shown. > > > > e.g. a static interface with 4 logical incoming events ( S1,S2,S3,S4) > > would then set the EventsDescripror like: > > > > MGC guess the MG is in state i1, no Notify will be sent by MG, when > > state of interface is still i1. > > > > Events { S1{strict="exact"},S2{strict="state"},S3{strict="state"},S4{strict="state"} } > > > > ( Note: in case "state" is the default, then EventsDescriptor could be shorter) > > > > The events descriptor remains active, after Notification is sent. > > The strict parameter avoids unnecessary Notifications for the already by MGC known state. > > > > This mechanism would be very simple and avoids lost of any events, which is strong > > required for signalling interfaces on MG transferred via H.248 to an MGC. > > > > > > For a better illustration I have attached a Excel-File containing a simple scenario. > > > > So my question/proposal is: > > > > - Is it possible to extend the existing static state interfacepackages like H.248.26 with this > > strict feature? > > - If not, can I get this functionality otherwise ? > > > > Kind regards > > > > Thomas Voith > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco -- _______________________________________________________________ _ V | Thomas Voith +---------------+ | Dept. VS/EAC2 [Systems] | A L C A T E L | | FL/2/50 +---------------+ | | Tel: +49 711 821-40293 | Alcanet: 259-40293 Alcatel SEL AG | Fax: +49 711 821-40211 Fixed Networks Division | Lorenzstr. 10 | mailto:Thomas.Voith@alcatel.de D-70435 Stuttgart, Germany | _______________________________________________________________ _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Oct 2 04:23:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07370 for ; Thu, 2 Oct 2003 04:23:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4yjn-0007Bm-A6; Thu, 02 Oct 2003 04:23:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4yiu-00077k-OV for megaco@optimus.ietf.org; Thu, 02 Oct 2003 04:22:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07360 for ; Thu, 2 Oct 2003 04:21:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4yir-0004bw-00 for megaco@ietf.org; Thu, 02 Oct 2003 04:22:05 -0400 Received: from mailrelay1.alcatel.de ([194.113.59.75] helo=mailrelay2.alcatel.de) by ietf-mx with esmtp (Exim 4.12) id 1A4yir-0004bn-00 for megaco@ietf.org; Thu, 02 Oct 2003 04:22:05 -0400 Received: from ks.sel.alcatel.de (slsv0d.stgl.sel.alcatel.de [149.204.14.10]) by mailrelay2.alcatel.de (8.12.10/8.12.9) with ESMTP id h927uKTC018634; Thu, 2 Oct 2003 09:56:20 +0200 (MET DST) Received: from slssiv ([149.204.245.89] helo=slsdtk.stgl.sel.alcatel.de) by ks.sel.alcatel.de with esmtp (Exim 3.31) id 1A4yN4-0000TY-00; Thu, 02 Oct 2003 09:59:34 +0200 Received: from sls0gf.stgl.sel.alcatel.de ([149.204.201.220] helo=alcatel.de) by slsdtk.stgl.sel.alcatel.de with esmtp (Exim 3.31) id 1A4yN4-0003HI-00; Thu, 02 Oct 2003 09:59:34 +0200 Message-ID: <3F7BDAE5.93080507@alcatel.de> Date: Thu, 02 Oct 2003 09:59:33 +0200 From: Thomas Voith X-Mailer: Mozilla 4.77 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en,de MIME-Version: 1.0 To: Christian Groves CC: megaco@ietf.org, ITU-SG16@external.cisco.com Subject: Re: [Megaco] Re: Event descriptor handling for static logic interfaces like CAS References: <3F7ABFEE.48753D6F@alcatel.de> <3F7BA0FF.30607@ericsson.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Christian I want both, - strict parameter for CAS Line signals and in future for all 'static'signalling interfaces. - optionally a default strict="state" to shorten the Events Descriptor In my opinion, this should be used for all 'static' signalling interfaces. With 'static' I mean that this interface has always a state, when MG receives an EventsDescriptor from MGC. For synchronizing the states from MGC with MG the strict mechanism is very useful. Doing the same with EventBuffer, Embedded Descriptor is much more complex and increases extreme with the number of possible states on the interface. Note: This 'strict' parameter is just used by MG to determine, whether a Notify for the existing state on the interface has to be sent or not. Further on normal event handling applies. This approach has the advantage, that EventBuffer and Embedded can still be used in addition. For all 'dynamic' events like pulses, DTMF, SPCM, normal event handling applies. Best regards Thomas Christian Groves wrote: > > Hello Thomas, > > Are you wanting a general purpose mechanism such as the off-hook one or do you > just want the default stated for H.248.26 and H.246.ICASC? > > Kevin Boyle is the editor of these he may have some opinion on this. > > Its always possible to make amendments to existing recommendations. Bring in a > contribution for consideration to SG16 or propose a detailed solution on the > Megaco list for experts to review. If they are agreeable then the change will be > added. > > Regards, Christian > > Thomas Voith wrote: > > > Dear list-members, > > > > H.248.26 and in H.248.ICAS I miss a feature, which has been used > > already for On-Hook, Off-Hook the 'strict' parameter. > > > > All interfaces, which have static states, should implement such > > a mechanism. > > > > The problem is that the EventsDescriptor EventBufferDescriptor or an > > embedded EventsDescriptor may discard events, if the newly received or > > replacing Event Descriptor does not match the event. > > > > In the Megaco Secnarios, always just the good case is shown. > > > > e.g. a static interface with 4 logical incoming events ( S1,S2,S3,S4) > > would then set the EventsDescripror like: > > > > MGC guess the MG is in state i1, no Notify will be sent by MG, when > > state of interface is still i1. > > > > Events { S1{strict="exact"},S2{strict="state"},S3{strict="state"},S4{strict="state"} } > > > > ( Note: in case "state" is the default, then EventsDescriptor could be shorter) > > > > The events descriptor remains active, after Notification is sent. > > The strict parameter avoids unnecessary Notifications for the already by MGC known state. > > > > This mechanism would be very simple and avoids lost of any events, which is strong > > required for signalling interfaces on MG transferred via H.248 to an MGC. > > > > > > For a better illustration I have attached a Excel-File containing a simple scenario. > > > > So my question/proposal is: > > > > - Is it possible to extend the existing static state interfacepackages like H.248.26 with this > > strict feature? > > - If not, can I get this functionality otherwise ? > > > > Kind regards > > > > Thomas Voith > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco -- _______________________________________________________________ _ V | Thomas Voith +---------------+ | Dept. VS/EAC2 [Systems] | A L C A T E L | | FL/2/50 +---------------+ | | Tel: +49 711 821-40293 | Alcanet: 259-40293 Alcatel SEL AG | Fax: +49 711 821-40211 Fixed Networks Division | Lorenzstr. 10 | mailto:Thomas.Voith@alcatel.de D-70435 Stuttgart, Germany | _______________________________________________________________ _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Oct 2 04:23:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07389 for ; Thu, 2 Oct 2003 04:23:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4yjz-0007Ek-IE for megaco-archive@odin.ietf.org; Thu, 02 Oct 2003 04:23:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h928NFwr027818 for megaco-archive@odin.ietf.org; Thu, 2 Oct 2003 04:23:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4yjp-0007CL-Hk for megaco-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 04:23:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07364 for ; Thu, 2 Oct 2003 04:22:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4yjm-0004c3-00 for megaco-web-archive@ietf.org; Thu, 02 Oct 2003 04:23:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4yjm-0004c0-00 for megaco-web-archive@ietf.org; Thu, 02 Oct 2003 04:23:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4yjn-0007Bm-A6; Thu, 02 Oct 2003 04:23:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4yiu-00077k-OV for megaco@optimus.ietf.org; Thu, 02 Oct 2003 04:22:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07360 for ; Thu, 2 Oct 2003 04:21:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4yir-0004bw-00 for megaco@ietf.org; Thu, 02 Oct 2003 04:22:05 -0400 Received: from mailrelay1.alcatel.de ([194.113.59.75] helo=mailrelay2.alcatel.de) by ietf-mx with esmtp (Exim 4.12) id 1A4yir-0004bn-00 for megaco@ietf.org; Thu, 02 Oct 2003 04:22:05 -0400 Received: from ks.sel.alcatel.de (slsv0d.stgl.sel.alcatel.de [149.204.14.10]) by mailrelay2.alcatel.de (8.12.10/8.12.9) with ESMTP id h927uKTC018634; Thu, 2 Oct 2003 09:56:20 +0200 (MET DST) Received: from slssiv ([149.204.245.89] helo=slsdtk.stgl.sel.alcatel.de) by ks.sel.alcatel.de with esmtp (Exim 3.31) id 1A4yN4-0000TY-00; Thu, 02 Oct 2003 09:59:34 +0200 Received: from sls0gf.stgl.sel.alcatel.de ([149.204.201.220] helo=alcatel.de) by slsdtk.stgl.sel.alcatel.de with esmtp (Exim 3.31) id 1A4yN4-0003HI-00; Thu, 02 Oct 2003 09:59:34 +0200 Message-ID: <3F7BDAE5.93080507@alcatel.de> Date: Thu, 02 Oct 2003 09:59:33 +0200 From: Thomas Voith X-Mailer: Mozilla 4.77 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en,de MIME-Version: 1.0 To: Christian Groves CC: megaco@ietf.org, ITU-SG16@external.cisco.com Subject: Re: [Megaco] Re: Event descriptor handling for static logic interfaces like CAS References: <3F7ABFEE.48753D6F@alcatel.de> <3F7BA0FF.30607@ericsson.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Christian I want both, - strict parameter for CAS Line signals and in future for all 'static'signalling interfaces. - optionally a default strict="state" to shorten the Events Descriptor In my opinion, this should be used for all 'static' signalling interfaces. With 'static' I mean that this interface has always a state, when MG receives an EventsDescriptor from MGC. For synchronizing the states from MGC with MG the strict mechanism is very useful. Doing the same with EventBuffer, Embedded Descriptor is much more complex and increases extreme with the number of possible states on the interface. Note: This 'strict' parameter is just used by MG to determine, whether a Notify for the existing state on the interface has to be sent or not. Further on normal event handling applies. This approach has the advantage, that EventBuffer and Embedded can still be used in addition. For all 'dynamic' events like pulses, DTMF, SPCM, normal event handling applies. Best regards Thomas Christian Groves wrote: > > Hello Thomas, > > Are you wanting a general purpose mechanism such as the off-hook one or do you > just want the default stated for H.248.26 and H.246.ICASC? > > Kevin Boyle is the editor of these he may have some opinion on this. > > Its always possible to make amendments to existing recommendations. Bring in a > contribution for consideration to SG16 or propose a detailed solution on the > Megaco list for experts to review. If they are agreeable then the change will be > added. > > Regards, Christian > > Thomas Voith wrote: > > > Dear list-members, > > > > H.248.26 and in H.248.ICAS I miss a feature, which has been used > > already for On-Hook, Off-Hook the 'strict' parameter. > > > > All interfaces, which have static states, should implement such > > a mechanism. > > > > The problem is that the EventsDescriptor EventBufferDescriptor or an > > embedded EventsDescriptor may discard events, if the newly received or > > replacing Event Descriptor does not match the event. > > > > In the Megaco Secnarios, always just the good case is shown. > > > > e.g. a static interface with 4 logical incoming events ( S1,S2,S3,S4) > > would then set the EventsDescripror like: > > > > MGC guess the MG is in state i1, no Notify will be sent by MG, when > > state of interface is still i1. > > > > Events { S1{strict="exact"},S2{strict="state"},S3{strict="state"},S4{strict="state"} } > > > > ( Note: in case "state" is the default, then EventsDescriptor could be shorter) > > > > The events descriptor remains active, after Notification is sent. > > The strict parameter avoids unnecessary Notifications for the already by MGC known state. > > > > This mechanism would be very simple and avoids lost of any events, which is strong > > required for signalling interfaces on MG transferred via H.248 to an MGC. > > > > > > For a better illustration I have attached a Excel-File containing a simple scenario. > > > > So my question/proposal is: > > > > - Is it possible to extend the existing static state interfacepackages like H.248.26 with this > > strict feature? > > - If not, can I get this functionality otherwise ? > > > > Kind regards > > > > Thomas Voith > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco -- _______________________________________________________________ _ V | Thomas Voith +---------------+ | Dept. VS/EAC2 [Systems] | A L C A T E L | | FL/2/50 +---------------+ | | Tel: +49 711 821-40293 | Alcanet: 259-40293 Alcatel SEL AG | Fax: +49 711 821-40211 Fixed Networks Division | Lorenzstr. 10 | mailto:Thomas.Voith@alcatel.de D-70435 Stuttgart, Germany | _______________________________________________________________ _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Oct 2 09:15:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17702 for ; Thu, 2 Oct 2003 09:15:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A53IN-0006eu-5U; Thu, 02 Oct 2003 09:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A53Hz-0006dy-EE for megaco@optimus.ietf.org; Thu, 02 Oct 2003 09:14:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17626 for ; Thu, 2 Oct 2003 09:14:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A53Hx-0000Ll-00 for megaco@ietf.org; Thu, 02 Oct 2003 09:14:37 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1A53Hx-0000Kw-00 for megaco@ietf.org; Thu, 02 Oct 2003 09:14:37 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h92DE4u25692 for ; Thu, 2 Oct 2003 09:14:05 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Oct 2003 09:14:05 -0400 Message-ID: From: "Kevin Boyle" To: Thomas Voith , Christian Groves Cc: megaco@ietf.org, ITU-SG16@external.cisco.com Subject: RE: [Megaco] Re: Event descriptor handling for static logic inter faces like CAS Date: Thu, 2 Oct 2003 09:14:02 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Thomas, The function you want already exists in the package. Each one of the line signalling events in both ICAS and BCAS have descriptions that contain the following: The event is reported by the MG if either the timed transition to this line signal is detected or the line signal already exists. This means that the strict=state behavior is already inherent in these events. I see no problem with this, and no need for a change to these packages. Kevin -----Original Message----- From: Thomas Voith [mailto:Thomas.Voith@alcatel.de] Sent: Thursday, October 02, 2003 4:00 AM To: Christian Groves Cc: megaco@ietf.org; ITU-SG16@external.cisco.com Subject: Re: [Megaco] Re: Event descriptor handling for static logic interfaces like CAS Hello Christian I want both, - strict parameter for CAS Line signals and in future for all 'static'signalling interfaces. - optionally a default strict="state" to shorten the Events Descriptor In my opinion, this should be used for all 'static' signalling interfaces. With 'static' I mean that this interface has always a state, when MG receives an EventsDescriptor from MGC. For synchronizing the states from MGC with MG the strict mechanism is very useful. Doing the same with EventBuffer, Embedded Descriptor is much more complex and increases extreme with the number of possible states on the interface. Note: This 'strict' parameter is just used by MG to determine, whether a Notify for the existing state on the interface has to be sent or not. Further on normal event handling applies. This approach has the advantage, that EventBuffer and Embedded can still be used in addition. For all 'dynamic' events like pulses, DTMF, SPCM, normal event handling applies. Best regards Thomas Christian Groves wrote: > > Hello Thomas, > > Are you wanting a general purpose mechanism such as the off-hook one > or do you just want the default stated for H.248.26 and H.246.ICASC? > > Kevin Boyle is the editor of these he may have some opinion on this. > > Its always possible to make amendments to existing recommendations. > Bring in a contribution for consideration to SG16 or propose a > detailed solution on the Megaco list for experts to review. If they > are agreeable then the change will be added. > > Regards, Christian > > Thomas Voith wrote: > > > Dear list-members, > > > > H.248.26 and in H.248.ICAS I miss a feature, which has been used > > already for On-Hook, Off-Hook the 'strict' parameter. > > > > All interfaces, which have static states, should implement such a > > mechanism. > > > > The problem is that the EventsDescriptor EventBufferDescriptor or an > > embedded EventsDescriptor may discard events, if the newly received > > or replacing Event Descriptor does not match the event. > > > > In the Megaco Secnarios, always just the good case is shown. > > > > e.g. a static interface with 4 logical incoming events ( > > S1,S2,S3,S4) would then set the EventsDescripror like: > > > > MGC guess the MG is in state i1, no Notify will be sent by MG, when > > state of interface is still i1. > > > > Events { > > S1{strict="exact"},S2{strict="state"},S3{strict="state"},S4{strict=" > > state"} } > > > > ( Note: in case "state" is the default, then EventsDescriptor could > > be shorter) > > > > The events descriptor remains active, after Notification is sent. > > The strict parameter avoids unnecessary Notifications for the > > already by MGC known state. > > > > This mechanism would be very simple and avoids lost of any events, > > which is strong required for signalling interfaces on MG transferred > > via H.248 to an MGC. > > > > > > For a better illustration I have attached a Excel-File containing a > > simple scenario. > > > > So my question/proposal is: > > > > - Is it possible to extend the existing static state interfacepackages like H.248.26 with this > > strict feature? > > - If not, can I get this functionality otherwise ? > > > > Kind regards > > > > Thomas Voith > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco -- _______________________________________________________________ _ V | Thomas Voith +---------------+ | Dept. VS/EAC2 [Systems] | A L C A T E L | | FL/2/50 +---------------+ | | Tel: +49 711 821-40293 | Alcanet: 259-40293 Alcatel SEL AG | Fax: +49 711 821-40211 Fixed Networks Division | Lorenzstr. 10 | mailto:Thomas.Voith@alcatel.de D-70435 Stuttgart, Germany | _______________________________________________________________ _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Oct 2 09:15:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17717 for ; Thu, 2 Oct 2003 09:15:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A53IS-0006ij-MT for megaco-archive@odin.ietf.org; Thu, 02 Oct 2003 09:15:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92DF8mO025832 for megaco-archive@odin.ietf.org; Thu, 2 Oct 2003 09:15:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A53IS-0006iZ-Gd for megaco-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 09:15:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17655 for ; Thu, 2 Oct 2003 09:14:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A53IQ-0000Ma-00 for megaco-web-archive@ietf.org; Thu, 02 Oct 2003 09:15:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A53IQ-0000MW-00 for megaco-web-archive@ietf.org; Thu, 02 Oct 2003 09:15:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A53IN-0006eu-5U; Thu, 02 Oct 2003 09:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A53Hz-0006dy-EE for megaco@optimus.ietf.org; Thu, 02 Oct 2003 09:14:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17626 for ; Thu, 2 Oct 2003 09:14:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A53Hx-0000Ll-00 for megaco@ietf.org; Thu, 02 Oct 2003 09:14:37 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1A53Hx-0000Kw-00 for megaco@ietf.org; Thu, 02 Oct 2003 09:14:37 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h92DE4u25692 for ; Thu, 2 Oct 2003 09:14:05 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Oct 2003 09:14:05 -0400 Message-ID: From: "Kevin Boyle" To: Thomas Voith , Christian Groves Cc: megaco@ietf.org, ITU-SG16@external.cisco.com Subject: RE: [Megaco] Re: Event descriptor handling for static logic inter faces like CAS Date: Thu, 2 Oct 2003 09:14:02 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Thomas, The function you want already exists in the package. Each one of the line signalling events in both ICAS and BCAS have descriptions that contain the following: The event is reported by the MG if either the timed transition to this line signal is detected or the line signal already exists. This means that the strict=state behavior is already inherent in these events. I see no problem with this, and no need for a change to these packages. Kevin -----Original Message----- From: Thomas Voith [mailto:Thomas.Voith@alcatel.de] Sent: Thursday, October 02, 2003 4:00 AM To: Christian Groves Cc: megaco@ietf.org; ITU-SG16@external.cisco.com Subject: Re: [Megaco] Re: Event descriptor handling for static logic interfaces like CAS Hello Christian I want both, - strict parameter for CAS Line signals and in future for all 'static'signalling interfaces. - optionally a default strict="state" to shorten the Events Descriptor In my opinion, this should be used for all 'static' signalling interfaces. With 'static' I mean that this interface has always a state, when MG receives an EventsDescriptor from MGC. For synchronizing the states from MGC with MG the strict mechanism is very useful. Doing the same with EventBuffer, Embedded Descriptor is much more complex and increases extreme with the number of possible states on the interface. Note: This 'strict' parameter is just used by MG to determine, whether a Notify for the existing state on the interface has to be sent or not. Further on normal event handling applies. This approach has the advantage, that EventBuffer and Embedded can still be used in addition. For all 'dynamic' events like pulses, DTMF, SPCM, normal event handling applies. Best regards Thomas Christian Groves wrote: > > Hello Thomas, > > Are you wanting a general purpose mechanism such as the off-hook one > or do you just want the default stated for H.248.26 and H.246.ICASC? > > Kevin Boyle is the editor of these he may have some opinion on this. > > Its always possible to make amendments to existing recommendations. > Bring in a contribution for consideration to SG16 or propose a > detailed solution on the Megaco list for experts to review. If they > are agreeable then the change will be added. > > Regards, Christian > > Thomas Voith wrote: > > > Dear list-members, > > > > H.248.26 and in H.248.ICAS I miss a feature, which has been used > > already for On-Hook, Off-Hook the 'strict' parameter. > > > > All interfaces, which have static states, should implement such a > > mechanism. > > > > The problem is that the EventsDescriptor EventBufferDescriptor or an > > embedded EventsDescriptor may discard events, if the newly received > > or replacing Event Descriptor does not match the event. > > > > In the Megaco Secnarios, always just the good case is shown. > > > > e.g. a static interface with 4 logical incoming events ( > > S1,S2,S3,S4) would then set the EventsDescripror like: > > > > MGC guess the MG is in state i1, no Notify will be sent by MG, when > > state of interface is still i1. > > > > Events { > > S1{strict="exact"},S2{strict="state"},S3{strict="state"},S4{strict=" > > state"} } > > > > ( Note: in case "state" is the default, then EventsDescriptor could > > be shorter) > > > > The events descriptor remains active, after Notification is sent. > > The strict parameter avoids unnecessary Notifications for the > > already by MGC known state. > > > > This mechanism would be very simple and avoids lost of any events, > > which is strong required for signalling interfaces on MG transferred > > via H.248 to an MGC. > > > > > > For a better illustration I have attached a Excel-File containing a > > simple scenario. > > > > So my question/proposal is: > > > > - Is it possible to extend the existing static state interfacepackages like H.248.26 with this > > strict feature? > > - If not, can I get this functionality otherwise ? > > > > Kind regards > > > > Thomas Voith > > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco -- _______________________________________________________________ _ V | Thomas Voith +---------------+ | Dept. VS/EAC2 [Systems] | A L C A T E L | | FL/2/50 +---------------+ | | Tel: +49 711 821-40293 | Alcanet: 259-40293 Alcatel SEL AG | Fax: +49 711 821-40211 Fixed Networks Division | Lorenzstr. 10 | mailto:Thomas.Voith@alcatel.de D-70435 Stuttgart, Germany | _______________________________________________________________ _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Oct 2 10:11:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20725 for ; Thu, 2 Oct 2003 10:11:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54AY-00015v-C1; Thu, 02 Oct 2003 10:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A549a-0000xU-5z for megaco@optimus.ietf.org; Thu, 02 Oct 2003 10:10:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20553 for ; Thu, 2 Oct 2003 10:09:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A549X-00010p-00 for megaco@ietf.org; Thu, 02 Oct 2003 10:09:59 -0400 Received: from mailrelay2.alcatel.de ([194.113.59.71] helo=mailrelay1.alcatel.de) by ietf-mx with esmtp (Exim 4.12) id 1A549X-00010e-00 for megaco@ietf.org; Thu, 02 Oct 2003 10:09:59 -0400 Received: from ks.sel.alcatel.de (slsv0d.stgl.sel.alcatel.de [149.204.14.10]) by mailrelay1.alcatel.de (8.9.3/8.9.3) with ESMTP id QAA08819; Thu, 2 Oct 2003 16:09:15 +0200 (MET DST) Received: from slssiv ([149.204.245.89] helo=slsdtk.stgl.sel.alcatel.de) by ks.sel.alcatel.de with esmtp (Exim 3.31) id 1A548q-0003Rx-00; Thu, 02 Oct 2003 16:09:16 +0200 Received: from sls0gf.stgl.sel.alcatel.de ([149.204.201.220] helo=alcatel.de) by slsdtk.stgl.sel.alcatel.de with esmtp (Exim 3.31) id 1A548q-0006eY-00; Thu, 02 Oct 2003 16:09:16 +0200 Message-ID: <3F7C318B.B77E2AB5@alcatel.de> Date: Thu, 02 Oct 2003 16:09:15 +0200 From: Thomas Voith X-Mailer: Mozilla 4.77 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en,de MIME-Version: 1.0 To: Kevin Boyle CC: Christian Groves , megaco@ietf.org, ITU-SG16@external.cisco.com Subject: Re: [Megaco] Re: Event descriptor handling for static logic interfaces like CAS References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Alcanet-MTA-scanned-and-authorized: yes X-Alcanet-MTA-scanned-and-authorized: yes X-Alcanet-MTA-scanned-and-authorized: yes Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Kevin What you mean is a general behavior, but MGC can not control it. This does not solve the problem which I ment. To make it easy I take the example for 'al/on al/of': The MGC want to be notified for 'al/on' and 'al/of'. MGC assumes that the line is in state 'al/on'. With Events{al/on{strict='exact'},al/of{strict='state'},....} the MGC do not get a Notify for al/on, because it is not necessary. When MGC then knows with the next notify, that the line is off-hook, it send perhaps a new EventsDescriptor containing the DigitMap, but now with Events{al/on{strict='state'},al/of{strict='exact'},....} This avoids again not needed Notify's. Same applies for CAS, where you have more states. With this mechanism you can update the EventsDescriptor for other things bind to this termination like R2 register signalling without again a not needed Notify AND in addition all static events are detected, not only the good case next step. Regards Thomas > Kevin Boyle wrote: > > Thomas, > > The function you want already exists in the package. Each one of the line signalling events in both ICAS and BCAS have descriptions that contain the following: > > The event is reported by the MG if either the timed transition to this line signal is detected or the line signal already exists. > > This means that the strict=state behavior is already inherent in these events. I see no problem with this, and no need for a change to these packages. > > Kevin > > -----Original Message----- > From: Thomas Voith [mailto:Thomas.Voith@alcatel.de] > Sent: Thursday, October 02, 2003 4:00 AM > To: Christian Groves > Cc: megaco@ietf.org; ITU-SG16@external.cisco.com > Subject: Re: [Megaco] Re: Event descriptor handling for static logic interfaces like CAS > > Hello Christian > > I want both, > - strict parameter for CAS Line signals and in future for all 'static'signalling interfaces. > - optionally a default strict="state" to shorten the Events Descriptor > > In my opinion, this should be used for all 'static' signalling interfaces. With 'static' I mean that this interface has always a state, when MG receives an EventsDescriptor from MGC. For > synchronizing the states from MGC with MG the strict mechanism is very useful. Doing the same with EventBuffer, Embedded Descriptor > > is much more complex and increases extreme with the number of possible states on the interface. > > Note: This 'strict' parameter is just used by MG to determine, whether a Notify > for the existing state on the interface has to be sent or not. > Further on normal event handling applies. > This approach has the advantage, that EventBuffer and Embedded can still be used > in addition. > > For all 'dynamic' events like pulses, DTMF, SPCM, normal event handling applies. > > Best regards > > Thomas > > Christian Groves wrote: > > > > Hello Thomas, > > > > Are you wanting a general purpose mechanism such as the off-hook one > > or do you just want the default stated for H.248.26 and H.246.ICASC? > > > > Kevin Boyle is the editor of these he may have some opinion on this. > > > > Its always possible to make amendments to existing recommendations. > > Bring in a contribution for consideration to SG16 or propose a > > detailed solution on the Megaco list for experts to review. If they > > are agreeable then the change will be added. > > > > Regards, Christian > > > > Thomas Voith wrote: > > > > > Dear list-members, > > > > > > H.248.26 and in H.248.ICAS I miss a feature, which has been used > > > already for On-Hook, Off-Hook the 'strict' parameter. > > > > > > All interfaces, which have static states, should implement such a > > > mechanism. > > > > > > The problem is that the EventsDescriptor EventBufferDescriptor or an > > > embedded EventsDescriptor may discard events, if the newly received > > > or replacing Event Descriptor does not match the event. > > > > > > In the Megaco Secnarios, always just the good case is shown. > > > > > > e.g. a static interface with 4 logical incoming events ( > > > S1,S2,S3,S4) would then set the EventsDescripror like: > > > > > > MGC guess the MG is in state i1, no Notify will be sent by MG, when > > > state of interface is still i1. > > > > > > Events { > > > S1{strict="exact"},S2{strict="state"},S3{strict="state"},S4{strict=" > > > state"} } > > > > > > ( Note: in case "state" is the default, then EventsDescriptor could > > > be shorter) > > > > > > The events descriptor remains active, after Notification is sent. > > > The strict parameter avoids unnecessary Notifications for the > > > already by MGC known state. > > > > > > This mechanism would be very simple and avoids lost of any events, > > > which is strong required for signalling interfaces on MG transferred > > > via H.248 to an MGC. > > > > > > > > > For a better illustration I have attached a Excel-File containing a > > > simple scenario. > > > > > > So my question/proposal is: > > > > > > - Is it possible to extend the existing static state interfacepackages like H.248.26 with this > > > strict feature? > > > - If not, can I get this functionality otherwise ? > > > > > > Kind regards > > > > > > Thomas Voith > > > > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco > > -- > _______________________________________________________________ > _ > V | Thomas Voith > +---------------+ | Dept. VS/EAC2 [Systems] > | A L C A T E L | | FL/2/50 > +---------------+ | > | Tel: +49 711 821-40293 > | Alcanet: 259-40293 > Alcatel SEL AG | Fax: +49 711 821-40211 > Fixed Networks Division | > Lorenzstr. 10 | mailto:Thomas.Voith@alcatel.de > D-70435 Stuttgart, Germany | > _______________________________________________________________ > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco -- _______________________________________________________________ _ V | Thomas Voith +---------------+ | Dept. VS/EAC2 [Systems] | A L C A T E L | | FL/2/50 +---------------+ | | Tel: +49 711 821-40293 | Alcanet: 259-40293 Alcatel SEL AG | Fax: +49 711 821-40211 Fixed Networks Division | Lorenzstr. 10 | mailto:Thomas.Voith@alcatel.de D-70435 Stuttgart, Germany | _______________________________________________________________ _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Oct 2 10:11:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20747 for ; Thu, 2 Oct 2003 10:11:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54Ad-00017b-7F for megaco-archive@odin.ietf.org; Thu, 02 Oct 2003 10:11:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92EB7wa004305 for megaco-archive@odin.ietf.org; Thu, 2 Oct 2003 10:11:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54Ab-00017C-Mq for megaco-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 10:11:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20673 for ; Thu, 2 Oct 2003 10:10:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A54AZ-00011r-00 for megaco-web-archive@ietf.org; Thu, 02 Oct 2003 10:11:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A54AY-00011l-00 for megaco-web-archive@ietf.org; Thu, 02 Oct 2003 10:11:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54AY-00015v-C1; Thu, 02 Oct 2003 10:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A549a-0000xU-5z for megaco@optimus.ietf.org; Thu, 02 Oct 2003 10:10:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20553 for ; Thu, 2 Oct 2003 10:09:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A549X-00010p-00 for megaco@ietf.org; Thu, 02 Oct 2003 10:09:59 -0400 Received: from mailrelay2.alcatel.de ([194.113.59.71] helo=mailrelay1.alcatel.de) by ietf-mx with esmtp (Exim 4.12) id 1A549X-00010e-00 for megaco@ietf.org; Thu, 02 Oct 2003 10:09:59 -0400 Received: from ks.sel.alcatel.de (slsv0d.stgl.sel.alcatel.de [149.204.14.10]) by mailrelay1.alcatel.de (8.9.3/8.9.3) with ESMTP id QAA08819; Thu, 2 Oct 2003 16:09:15 +0200 (MET DST) Received: from slssiv ([149.204.245.89] helo=slsdtk.stgl.sel.alcatel.de) by ks.sel.alcatel.de with esmtp (Exim 3.31) id 1A548q-0003Rx-00; Thu, 02 Oct 2003 16:09:16 +0200 Received: from sls0gf.stgl.sel.alcatel.de ([149.204.201.220] helo=alcatel.de) by slsdtk.stgl.sel.alcatel.de with esmtp (Exim 3.31) id 1A548q-0006eY-00; Thu, 02 Oct 2003 16:09:16 +0200 Message-ID: <3F7C318B.B77E2AB5@alcatel.de> Date: Thu, 02 Oct 2003 16:09:15 +0200 From: Thomas Voith X-Mailer: Mozilla 4.77 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en,de MIME-Version: 1.0 To: Kevin Boyle CC: Christian Groves , megaco@ietf.org, ITU-SG16@external.cisco.com Subject: Re: [Megaco] Re: Event descriptor handling for static logic interfaces like CAS References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Alcanet-MTA-scanned-and-authorized: yes X-Alcanet-MTA-scanned-and-authorized: yes X-Alcanet-MTA-scanned-and-authorized: yes Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Kevin What you mean is a general behavior, but MGC can not control it. This does not solve the problem which I ment. To make it easy I take the example for 'al/on al/of': The MGC want to be notified for 'al/on' and 'al/of'. MGC assumes that the line is in state 'al/on'. With Events{al/on{strict='exact'},al/of{strict='state'},....} the MGC do not get a Notify for al/on, because it is not necessary. When MGC then knows with the next notify, that the line is off-hook, it send perhaps a new EventsDescriptor containing the DigitMap, but now with Events{al/on{strict='state'},al/of{strict='exact'},....} This avoids again not needed Notify's. Same applies for CAS, where you have more states. With this mechanism you can update the EventsDescriptor for other things bind to this termination like R2 register signalling without again a not needed Notify AND in addition all static events are detected, not only the good case next step. Regards Thomas > Kevin Boyle wrote: > > Thomas, > > The function you want already exists in the package. Each one of the line signalling events in both ICAS and BCAS have descriptions that contain the following: > > The event is reported by the MG if either the timed transition to this line signal is detected or the line signal already exists. > > This means that the strict=state behavior is already inherent in these events. I see no problem with this, and no need for a change to these packages. > > Kevin > > -----Original Message----- > From: Thomas Voith [mailto:Thomas.Voith@alcatel.de] > Sent: Thursday, October 02, 2003 4:00 AM > To: Christian Groves > Cc: megaco@ietf.org; ITU-SG16@external.cisco.com > Subject: Re: [Megaco] Re: Event descriptor handling for static logic interfaces like CAS > > Hello Christian > > I want both, > - strict parameter for CAS Line signals and in future for all 'static'signalling interfaces. > - optionally a default strict="state" to shorten the Events Descriptor > > In my opinion, this should be used for all 'static' signalling interfaces. With 'static' I mean that this interface has always a state, when MG receives an EventsDescriptor from MGC. For > synchronizing the states from MGC with MG the strict mechanism is very useful. Doing the same with EventBuffer, Embedded Descriptor > > is much more complex and increases extreme with the number of possible states on the interface. > > Note: This 'strict' parameter is just used by MG to determine, whether a Notify > for the existing state on the interface has to be sent or not. > Further on normal event handling applies. > This approach has the advantage, that EventBuffer and Embedded can still be used > in addition. > > For all 'dynamic' events like pulses, DTMF, SPCM, normal event handling applies. > > Best regards > > Thomas > > Christian Groves wrote: > > > > Hello Thomas, > > > > Are you wanting a general purpose mechanism such as the off-hook one > > or do you just want the default stated for H.248.26 and H.246.ICASC? > > > > Kevin Boyle is the editor of these he may have some opinion on this. > > > > Its always possible to make amendments to existing recommendations. > > Bring in a contribution for consideration to SG16 or propose a > > detailed solution on the Megaco list for experts to review. If they > > are agreeable then the change will be added. > > > > Regards, Christian > > > > Thomas Voith wrote: > > > > > Dear list-members, > > > > > > H.248.26 and in H.248.ICAS I miss a feature, which has been used > > > already for On-Hook, Off-Hook the 'strict' parameter. > > > > > > All interfaces, which have static states, should implement such a > > > mechanism. > > > > > > The problem is that the EventsDescriptor EventBufferDescriptor or an > > > embedded EventsDescriptor may discard events, if the newly received > > > or replacing Event Descriptor does not match the event. > > > > > > In the Megaco Secnarios, always just the good case is shown. > > > > > > e.g. a static interface with 4 logical incoming events ( > > > S1,S2,S3,S4) would then set the EventsDescripror like: > > > > > > MGC guess the MG is in state i1, no Notify will be sent by MG, when > > > state of interface is still i1. > > > > > > Events { > > > S1{strict="exact"},S2{strict="state"},S3{strict="state"},S4{strict=" > > > state"} } > > > > > > ( Note: in case "state" is the default, then EventsDescriptor could > > > be shorter) > > > > > > The events descriptor remains active, after Notification is sent. > > > The strict parameter avoids unnecessary Notifications for the > > > already by MGC known state. > > > > > > This mechanism would be very simple and avoids lost of any events, > > > which is strong required for signalling interfaces on MG transferred > > > via H.248 to an MGC. > > > > > > > > > For a better illustration I have attached a Excel-File containing a > > > simple scenario. > > > > > > So my question/proposal is: > > > > > > - Is it possible to extend the existing static state interfacepackages like H.248.26 with this > > > strict feature? > > > - If not, can I get this functionality otherwise ? > > > > > > Kind regards > > > > > > Thomas Voith > > > > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco > > -- > _______________________________________________________________ > _ > V | Thomas Voith > +---------------+ | Dept. VS/EAC2 [Systems] > | A L C A T E L | | FL/2/50 > +---------------+ | > | Tel: +49 711 821-40293 > | Alcanet: 259-40293 > Alcatel SEL AG | Fax: +49 711 821-40211 > Fixed Networks Division | > Lorenzstr. 10 | mailto:Thomas.Voith@alcatel.de > D-70435 Stuttgart, Germany | > _______________________________________________________________ > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco -- _______________________________________________________________ _ V | Thomas Voith +---------------+ | Dept. VS/EAC2 [Systems] | A L C A T E L | | FL/2/50 +---------------+ | | Tel: +49 711 821-40293 | Alcanet: 259-40293 Alcatel SEL AG | Fax: +49 711 821-40211 Fixed Networks Division | Lorenzstr. 10 | mailto:Thomas.Voith@alcatel.de D-70435 Stuttgart, Germany | _______________________________________________________________ _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Oct 2 10:30:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21930 for ; Thu, 2 Oct 2003 10:30:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54Sw-0001oX-6e; Thu, 02 Oct 2003 10:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54Sk-0001o3-Cp for megaco@optimus.ietf.org; Thu, 02 Oct 2003 10:29:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21876 for ; Thu, 2 Oct 2003 10:29:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A54Sh-0001EF-00 for megaco@ietf.org; Thu, 02 Oct 2003 10:29:47 -0400 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx with esmtp (Exim 4.12) id 1A54Sg-0001E7-00 for megaco@ietf.org; Thu, 02 Oct 2003 10:29:47 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id h92ETUIi019636; Thu, 2 Oct 2003 07:29:31 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id h92EThVp019690; Thu, 2 Oct 2003 09:29:44 -0500 Message-Id: <5.2.1.1.0.20031002095954.02afce00@IL06EXM13.corp.mot.com> X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 02 Oct 2003 10:25:23 -0400 To: "Kevin Boyle", From: Aleksandr Ryabin Subject: RE: [Megaco] CAS Metering Pulse support In-Reply-To: <5.2.1.1.0.20030916104820.02ff6770@IL06EXM13.corp.mot.com> References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1152773100==.ALT" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --=====================_1152773100==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, In continuation to this metering pulse support. I've looked through amet package and it does not seem to define procedure to detect metering pulses, it only has a procedure to generate metering pulses. I see no reason of defining a new package for detecting incoming metering pulses and I propose to reuse amet and amend it to define procedure for detecting incoming metering pulses. Here is the summary of a proposed metering pulse detection procedure using amet package: The detection of metering pulse on a termination could be enabled by MGC when no amet signals are played on a termination by requesting detection amet/pr event with a required repetition period. MG would Notify MGC with amet/pr event when number of metering pulses is detected according to repetition period parameter set. On Subtract, or explicit AuditValue MG would send amet/cpc and amet/pcslr statistics similar to as described in the package provided their description extended to detection as well. Comments? Thanks Aleks BTW IANA MEGACO page is still not updated. At 10:50 AM 9/16/2003, Aleksandr Ryabin wrote: >It is updated with H.248.22 and 25, but not with 23, 24, 26, 27 >while all of them are dated in ITU the same. Strange. > Aleks > >At 10:46 AM 9/16/2003, Kevin Boyle wrote: > >>If it is NOT updated, that is. (Apparently, it's going to be one of those >>days!) >> >>Kevin >> >>-----Original Message----- >>From: Boyle, Kevin [NCRTP:3Z40:EXCH] >>Sent: Tuesday, September 16, 2003 10:39 AM >>To: Aleksandr Ryabin; megaco@ietf.org >>Subject: RE: [Megaco] CAS Metering Pulse support >> >>Ummm... yeah. That's what I get for not looking it up before sending the >>message. :) While amet is defined in the "Extended Analog Lines >>Packages" doc, there is nothing in the amet package that actually limits >>it to analog lines. >> >> >>The updates for all the new (as of May) H.248 Sub-series Recommendations >>have already been requested of IANA. If it is updated by the end of the >>month, I'll ping them again. >> >> >>Kevin >> >>-----Original Message----- >>From: Aleksandr Ryabin >>[mailto:kengr@motorola.com] >>Sent: Tuesday, September 16, 2003 10:32 AM >>To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org >>Subject: RE: [Megaco] CAS Metering Pulse support >> >>Hi, >> >>I guess you meant H.248.26. >>Yes it seem to address the needs assuming it is extended to digital lines >>as well. >> >>BTW IANA registry should be updated with H.248.26 and H.248.27 >>http://www.iana.org/assignments/megaco-h248 >> >> >> >>Thanks, >> Aleks >> >>At 10:00 AM 9/16/2003, Kevin Boyle wrote: >> >> >>H.248.27 has a metering package (automatic metering package or >>amet). This package may address your needs. >> >>Kevin >> >>-----Original Message----- >>From: Aleksandr Ryabin >>[mailto:kengr@motorola.com >> ] >>Sent: Tuesday, September 16, 2003 9:34 AM >>To: megaco@ietf.org >>Subject: [Megaco] CAS Metering Pulse support >> >>Hi all, >> >>Below are excerpts from a previous exchange related to defining of CAS >>Metering Pulse procedures in MEGACO. >> >>Now that CAS packages related work has been moved to ITU has anyone done >>and/or planned anything in the direction to define CAS Metering Pulse >>procedures/package for MEGACO? >> >>Thanks >> Aleks >> >> >From: klaha@hss.hns.com >> >To: Aleksandr Ryabin >> >cc: vnair@hss.hns.com, megaco@ietf.org, klaha@hss.hns.com >> >Date: Tue, 4 Mar 2003 12:47:37 +0530 >> >Subject: Re: [Megaco] Re: draft-ietf-megaco-r2package-03.txt : Difference >> > from previous revision >>... >> >Aleksandr Ryabin on 03/03/2003 10:43:20 PM >>... >> >3. I can't seem to find a way to implement "Metering Pulse" procedure >> >defined for some R2 variants using ether bcas or R2 packages? For >> >example, one of the definitions of such a pulse is a "seizure ack" >> >pulse from a terminating end on a circuit in connected/answer state. >> > >> >[Kushanava] Metering is not specific to R2. It may be present in any >> >CAS signaling. Moreover not all flavours of R2 permit metering to be >> >mandatory. There should be therefore a general philosophy of attacking >> >this problem common to all CAS signaling. The solution should be >> >sensitive to >> >a) Realizing that MGC is the master for collecting and generating charging >> >information >> >b) Interworking of the CAS "metering pulse" signals with other signaling >> >(both PDN and PSTN) >> >c) Optimizing the network traffic if metering information is >> transported to >> >> >and fro between MGC and MG >> >d) Latency, if metering information is transported to and fro between MGC >> >and MG >> >We are working towards a separate package that addresses this issue. >> >Any suggestions? >>... >> >>_______________________________________________ >>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 >> --=====================_1152773100==.ALT Content-Type: text/html; charset="us-ascii" Hi,

In continuation to this metering pulse support.

I've looked through amet package and it does not seem to
define procedure to detect metering pulses, it only has
a procedure to generate metering pulses.

I see no reason of defining a new package for detecting incoming
metering pulses and I propose to reuse amet and amend it to
define procedure for detecting incoming metering pulses.

Here is the summary of a proposed metering pulse detection
procedure using amet package:

The detection of metering pulse on a termination could be enabled
by MGC when no amet signals are played on a termination by
requesting detection amet/pr event with a required repetition period.
MG would Notify MGC with amet/pr event when number of metering
pulses is detected according to repetition period parameter set.

On Subtract, or explicit AuditValue MG would send amet/cpc
and amet/pcslr statistics similar to as described in the package
provided their description extended to detection as well.

Comments?

Thanks
        Aleks

BTW IANA MEGACO page is still not updated.

At 10:50 AM 9/16/2003, Aleksandr Ryabin wrote:
It is updated with H.248.22 and 25, but not with 23, 24, 26, 27
while all of them are dated in ITU the same. Strange.
        Aleks

At 10:46 AM 9/16/2003, Kevin Boyle wrote:

If it is NOT updated, that is. (Apparently, it's going to be one of those days!)

Kevin

-----Original Message-----
From: Boyle, Kevin [NCRTP:3Z40:EXCH]
Sent: Tuesday, September 16, 2003 10:39 AM
To: Aleksandr Ryabin; megaco@ietf.org
Subject: RE: [Megaco] CAS Metering Pulse support

Ummm... yeah.  That's what I get for not looking it up before sending the message. :)  While amet is defined in the "Extended Analog Lines Packages" doc, there is nothing in the amet package that actually limits it to analog lines.

 
The updates for all the new (as of May) H.248 Sub-series Recommendations have already been requested of IANA.  If it is updated by the end of the month, I'll ping them again.

 
Kevin

-----Original Message-----
From: Aleksandr Ryabin [mailto:kengr@motorola.com]
Sent: Tuesday, September 16, 2003 10:32 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org
Subject: RE: [Megaco] CAS Metering Pulse support

Hi,

I guess you meant H.248.26.
Yes it seem to address the needs assuming it is extended to digital lines as well.

BTW IANA registry should be updated with H.248.26 and H.248.27
http://www.iana.org/assignments/megaco-h248
<http://www.iana.org/assignments/megaco-h248>

Thanks,
        Aleks

At 10:00 AM 9/16/2003, Kevin Boyle wrote:


H.248.27 has a metering package (automatic metering package or amet).  This package may address your needs.

Kevin

-----Original Message-----
From: Aleksandr Ryabin [mailto:kengr@motorola.com <mailto:kengr@motorola.com> ]
Sent: Tuesday, September 16, 2003 9:34 AM
To: megaco@ietf.org
Subject: [Megaco] CAS Metering Pulse support

Hi all,

Below are excerpts from a previous exchange related to defining of CAS Metering Pulse procedures in MEGACO.

Now that CAS packages related work has been moved to ITU has anyone done and/or planned anything in the direction to define CAS Metering Pulse procedures/package for MEGACO?

Thanks
         Aleks

>From: klaha@hss.hns.com
>To: Aleksandr Ryabin <kengr@winphoria.com>
>cc: vnair@hss.hns.com, megaco@ietf.org, klaha@hss.hns.com
>Date: Tue, 4 Mar 2003 12:47:37 +0530
>Subject: Re: [Megaco] Re: draft-ietf-megaco-r2package-03.txt : Difference
>         from previous revision
...
>Aleksandr Ryabin <kengr@winphoria.com> on 03/03/2003 10:43:20 PM
...
>3. I can't seem to find a way to implement "Metering Pulse" procedure
>defined for some R2 variants using ether bcas or R2 packages? For
>example, one of the definitions of such a pulse is a "seizure ack"
>pulse from a terminating end on a circuit in connected/answer state.
>
>[Kushanava] Metering is not specific to R2. It may be present in any
>CAS signaling. Moreover not all flavours of R2 permit metering to be
>mandatory. There should be therefore a general philosophy of attacking
>this problem common to all CAS signaling. The solution should be
>sensitive to
>a) Realizing that MGC is the master for collecting and generating charging
>information
>b) Interworking of the CAS "metering pulse" signals with other signaling
>(both PDN and PSTN)
>c) Optimizing the network traffic if metering information is transported to

>and fro between MGC and MG
>d) Latency, if metering information is transported to and fro between MGC
>and MG
>We are working towards a separate package that addresses this issue.
>Any suggestions?
...

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

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
--=====================_1152773100==.ALT-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Oct 2 10:30:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21945 for ; Thu, 2 Oct 2003 10:30:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54T3-0001pw-9O for megaco-archive@odin.ietf.org; Thu, 02 Oct 2003 10:30:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92EU9KP007060 for megaco-archive@odin.ietf.org; Thu, 2 Oct 2003 10:30:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54T3-0001pn-3Y for megaco-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 10:30:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21889 for ; Thu, 2 Oct 2003 10:29:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A54T0-0001EO-00 for megaco-web-archive@ietf.org; Thu, 02 Oct 2003 10:30:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A54T0-0001EL-00 for megaco-web-archive@ietf.org; Thu, 02 Oct 2003 10:30:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54Sw-0001oX-6e; Thu, 02 Oct 2003 10:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54Sk-0001o3-Cp for megaco@optimus.ietf.org; Thu, 02 Oct 2003 10:29:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21876 for ; Thu, 2 Oct 2003 10:29:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A54Sh-0001EF-00 for megaco@ietf.org; Thu, 02 Oct 2003 10:29:47 -0400 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx with esmtp (Exim 4.12) id 1A54Sg-0001E7-00 for megaco@ietf.org; Thu, 02 Oct 2003 10:29:47 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id h92ETUIi019636; Thu, 2 Oct 2003 07:29:31 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id h92EThVp019690; Thu, 2 Oct 2003 09:29:44 -0500 Message-Id: <5.2.1.1.0.20031002095954.02afce00@IL06EXM13.corp.mot.com> X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 02 Oct 2003 10:25:23 -0400 To: "Kevin Boyle", From: Aleksandr Ryabin Subject: RE: [Megaco] CAS Metering Pulse support In-Reply-To: <5.2.1.1.0.20030916104820.02ff6770@IL06EXM13.corp.mot.com> References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1152773100==.ALT" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --=====================_1152773100==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, In continuation to this metering pulse support. I've looked through amet package and it does not seem to define procedure to detect metering pulses, it only has a procedure to generate metering pulses. I see no reason of defining a new package for detecting incoming metering pulses and I propose to reuse amet and amend it to define procedure for detecting incoming metering pulses. Here is the summary of a proposed metering pulse detection procedure using amet package: The detection of metering pulse on a termination could be enabled by MGC when no amet signals are played on a termination by requesting detection amet/pr event with a required repetition period. MG would Notify MGC with amet/pr event when number of metering pulses is detected according to repetition period parameter set. On Subtract, or explicit AuditValue MG would send amet/cpc and amet/pcslr statistics similar to as described in the package provided their description extended to detection as well. Comments? Thanks Aleks BTW IANA MEGACO page is still not updated. At 10:50 AM 9/16/2003, Aleksandr Ryabin wrote: >It is updated with H.248.22 and 25, but not with 23, 24, 26, 27 >while all of them are dated in ITU the same. Strange. > Aleks > >At 10:46 AM 9/16/2003, Kevin Boyle wrote: > >>If it is NOT updated, that is. (Apparently, it's going to be one of those >>days!) >> >>Kevin >> >>-----Original Message----- >>From: Boyle, Kevin [NCRTP:3Z40:EXCH] >>Sent: Tuesday, September 16, 2003 10:39 AM >>To: Aleksandr Ryabin; megaco@ietf.org >>Subject: RE: [Megaco] CAS Metering Pulse support >> >>Ummm... yeah. That's what I get for not looking it up before sending the >>message. :) While amet is defined in the "Extended Analog Lines >>Packages" doc, there is nothing in the amet package that actually limits >>it to analog lines. >> >> >>The updates for all the new (as of May) H.248 Sub-series Recommendations >>have already been requested of IANA. If it is updated by the end of the >>month, I'll ping them again. >> >> >>Kevin >> >>-----Original Message----- >>From: Aleksandr Ryabin >>[mailto:kengr@motorola.com] >>Sent: Tuesday, September 16, 2003 10:32 AM >>To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org >>Subject: RE: [Megaco] CAS Metering Pulse support >> >>Hi, >> >>I guess you meant H.248.26. >>Yes it seem to address the needs assuming it is extended to digital lines >>as well. >> >>BTW IANA registry should be updated with H.248.26 and H.248.27 >>http://www.iana.org/assignments/megaco-h248 >> >> >> >>Thanks, >> Aleks >> >>At 10:00 AM 9/16/2003, Kevin Boyle wrote: >> >> >>H.248.27 has a metering package (automatic metering package or >>amet). This package may address your needs. >> >>Kevin >> >>-----Original Message----- >>From: Aleksandr Ryabin >>[mailto:kengr@motorola.com >> ] >>Sent: Tuesday, September 16, 2003 9:34 AM >>To: megaco@ietf.org >>Subject: [Megaco] CAS Metering Pulse support >> >>Hi all, >> >>Below are excerpts from a previous exchange related to defining of CAS >>Metering Pulse procedures in MEGACO. >> >>Now that CAS packages related work has been moved to ITU has anyone done >>and/or planned anything in the direction to define CAS Metering Pulse >>procedures/package for MEGACO? >> >>Thanks >> Aleks >> >> >From: klaha@hss.hns.com >> >To: Aleksandr Ryabin >> >cc: vnair@hss.hns.com, megaco@ietf.org, klaha@hss.hns.com >> >Date: Tue, 4 Mar 2003 12:47:37 +0530 >> >Subject: Re: [Megaco] Re: draft-ietf-megaco-r2package-03.txt : Difference >> > from previous revision >>... >> >Aleksandr Ryabin on 03/03/2003 10:43:20 PM >>... >> >3. I can't seem to find a way to implement "Metering Pulse" procedure >> >defined for some R2 variants using ether bcas or R2 packages? For >> >example, one of the definitions of such a pulse is a "seizure ack" >> >pulse from a terminating end on a circuit in connected/answer state. >> > >> >[Kushanava] Metering is not specific to R2. It may be present in any >> >CAS signaling. Moreover not all flavours of R2 permit metering to be >> >mandatory. There should be therefore a general philosophy of attacking >> >this problem common to all CAS signaling. The solution should be >> >sensitive to >> >a) Realizing that MGC is the master for collecting and generating charging >> >information >> >b) Interworking of the CAS "metering pulse" signals with other signaling >> >(both PDN and PSTN) >> >c) Optimizing the network traffic if metering information is >> transported to >> >> >and fro between MGC and MG >> >d) Latency, if metering information is transported to and fro between MGC >> >and MG >> >We are working towards a separate package that addresses this issue. >> >Any suggestions? >>... >> >>_______________________________________________ >>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 >> --=====================_1152773100==.ALT Content-Type: text/html; charset="us-ascii" Hi,

In continuation to this metering pulse support.

I've looked through amet package and it does not seem to
define procedure to detect metering pulses, it only has
a procedure to generate metering pulses.

I see no reason of defining a new package for detecting incoming
metering pulses and I propose to reuse amet and amend it to
define procedure for detecting incoming metering pulses.

Here is the summary of a proposed metering pulse detection
procedure using amet package:

The detection of metering pulse on a termination could be enabled
by MGC when no amet signals are played on a termination by
requesting detection amet/pr event with a required repetition period.
MG would Notify MGC with amet/pr event when number of metering
pulses is detected according to repetition period parameter set.

On Subtract, or explicit AuditValue MG would send amet/cpc
and amet/pcslr statistics similar to as described in the package
provided their description extended to detection as well.

Comments?

Thanks
        Aleks

BTW IANA MEGACO page is still not updated.

At 10:50 AM 9/16/2003, Aleksandr Ryabin wrote:
It is updated with H.248.22 and 25, but not with 23, 24, 26, 27
while all of them are dated in ITU the same. Strange.
        Aleks

At 10:46 AM 9/16/2003, Kevin Boyle wrote:

If it is NOT updated, that is. (Apparently, it's going to be one of those days!)

Kevin

-----Original Message-----
From: Boyle, Kevin [NCRTP:3Z40:EXCH]
Sent: Tuesday, September 16, 2003 10:39 AM
To: Aleksandr Ryabin; megaco@ietf.org
Subject: RE: [Megaco] CAS Metering Pulse support

Ummm... yeah.  That's what I get for not looking it up before sending the message. :)  While amet is defined in the "Extended Analog Lines Packages" doc, there is nothing in the amet package that actually limits it to analog lines.

 
The updates for all the new (as of May) H.248 Sub-series Recommendations have already been requested of IANA.  If it is updated by the end of the month, I'll ping them again.

 
Kevin

-----Original Message-----
From: Aleksandr Ryabin [mailto:kengr@motorola.com]
Sent: Tuesday, September 16, 2003 10:32 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org
Subject: RE: [Megaco] CAS Metering Pulse support

Hi,

I guess you meant H.248.26.
Yes it seem to address the needs assuming it is extended to digital lines as well.

BTW IANA registry should be updated with H.248.26 and H.248.27
http://www.iana.org/assignments/megaco-h248
<http://www.iana.org/assignments/megaco-h248>

Thanks,
        Aleks

At 10:00 AM 9/16/2003, Kevin Boyle wrote:


H.248.27 has a metering package (automatic metering package or amet).  This package may address your needs.

Kevin

-----Original Message-----
From: Aleksandr Ryabin [mailto:kengr@motorola.com <mailto:kengr@motorola.com> ]
Sent: Tuesday, September 16, 2003 9:34 AM
To: megaco@ietf.org
Subject: [Megaco] CAS Metering Pulse support

Hi all,

Below are excerpts from a previous exchange related to defining of CAS Metering Pulse procedures in MEGACO.

Now that CAS packages related work has been moved to ITU has anyone done and/or planned anything in the direction to define CAS Metering Pulse procedures/package for MEGACO?

Thanks
         Aleks

>From: klaha@hss.hns.com
>To: Aleksandr Ryabin <kengr@winphoria.com>
>cc: vnair@hss.hns.com, megaco@ietf.org, klaha@hss.hns.com
>Date: Tue, 4 Mar 2003 12:47:37 +0530
>Subject: Re: [Megaco] Re: draft-ietf-megaco-r2package-03.txt : Difference
>         from previous revision
...
>Aleksandr Ryabin <kengr@winphoria.com> on 03/03/2003 10:43:20 PM
...
>3. I can't seem to find a way to implement "Metering Pulse" procedure
>defined for some R2 variants using ether bcas or R2 packages? For
>example, one of the definitions of such a pulse is a "seizure ack"
>pulse from a terminating end on a circuit in connected/answer state.
>
>[Kushanava] Metering is not specific to R2. It may be present in any
>CAS signaling. Moreover not all flavours of R2 permit metering to be
>mandatory. There should be therefore a general philosophy of attacking
>this problem common to all CAS signaling. The solution should be
>sensitive to
>a) Realizing that MGC is the master for collecting and generating charging
>information
>b) Interworking of the CAS "metering pulse" signals with other signaling
>(both PDN and PSTN)
>c) Optimizing the network traffic if metering information is transported to

>and fro between MGC and MG
>d) Latency, if metering information is transported to and fro between MGC
>and MG
>We are working towards a separate package that addresses this issue.
>Any suggestions?
...

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

_______________________________________________
Megaco mailing list
Megaco@ietf.org
https://www1.ietf.org/mailman/listinfo/megaco
--=====================_1152773100==.ALT-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Oct 2 14:21:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18225 for ; Thu, 2 Oct 2003 14:21:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A584T-0001MB-Pf; Thu, 02 Oct 2003 14:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5849-0001Le-QT for megaco@optimus.ietf.org; Thu, 02 Oct 2003 14:20:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18181 for ; Thu, 2 Oct 2003 14:20:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5847-0004mh-00 for megaco@ietf.org; Thu, 02 Oct 2003 14:20:39 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1A5846-0004lx-00 for megaco@ietf.org; Thu, 02 Oct 2003 14:20:38 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h92IK7u08703 for ; Thu, 2 Oct 2003 14:20:07 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Oct 2003 14:20:08 -0400 Message-ID: From: "Kevin Boyle" To: Thomas Voith Cc: Christian Groves , megaco@ietf.org, ITU-SG16@external.cisco.com Subject: RE: [Megaco] Re: Event descriptor handling for static logic inter faces like CAS Date: Thu, 2 Oct 2003 14:20:03 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Apparently, I misunderstood what you were looking for. Unless I hear any objections, I will add that function to ICAS for the next meeting. Of course, this does nothing for the BCAS spec -- I assume we will need the same change there? This will require an amendment to H.248.25... I don't think this kind of change will be acceptable as an IG change. Comments? Kevin -----Original Message----- From: Thomas Voith [mailto:Thomas.Voith@alcatel.de] Sent: Thursday, October 02, 2003 10:09 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH] Cc: Christian Groves; megaco@ietf.org; ITU-SG16@external.cisco.com Subject: Re: [Megaco] Re: Event descriptor handling for static logic interfaces like CAS Hello Kevin What you mean is a general behavior, but MGC can not control it. This does not solve the problem which I ment. To make it easy I take the example for 'al/on al/of': The MGC want to be notified for 'al/on' and 'al/of'. MGC assumes that the line is in state 'al/on'. With Events{al/on{strict='exact'},al/of{strict='state'},....} the MGC do not get a Notify for al/on, because it is not necessary. When MGC then knows with the next notify, that the line is off-hook, it send perhaps a new EventsDescriptor containing the DigitMap, but now with Events{al/on{strict='state'},al/of{strict='exact'},....} This avoids again not needed Notify's. Same applies for CAS, where you have more states. With this mechanism you can update the EventsDescriptor for other things bind to this termination like R2 register signalling without again a not needed Notify AND in addition all static events are detected, not only the good case next step. Regards Thomas > Kevin Boyle wrote: > > Thomas, > > The function you want already exists in the package. Each one of the > line signalling events in both ICAS and BCAS have descriptions that > contain the following: > > The event is reported by the MG if either the timed transition to this > line signal is detected or the line signal already exists. > > This means that the strict=state behavior is already inherent in these > events. I see no problem with this, and no need for a change to these > packages. > > Kevin > > -----Original Message----- > From: Thomas Voith [mailto:Thomas.Voith@alcatel.de] > Sent: Thursday, October 02, 2003 4:00 AM > To: Christian Groves > Cc: megaco@ietf.org; ITU-SG16@external.cisco.com > Subject: Re: [Megaco] Re: Event descriptor handling for static logic > interfaces like CAS > > Hello Christian > > I want both, > - strict parameter for CAS Line signals and in future for all > 'static'signalling interfaces. > - optionally a default strict="state" to shorten the Events Descriptor > > In my opinion, this should be used for all 'static' signalling > interfaces. With 'static' I mean that this interface has always a > state, when MG receives an EventsDescriptor from MGC. For > synchronizing the states from MGC with MG the strict mechanism is very > useful. Doing the same with EventBuffer, Embedded Descriptor > > is much more complex and increases extreme with the number of possible > states on the interface. > > Note: This 'strict' parameter is just used by MG to determine, whether a Notify > for the existing state on the interface has to be sent or not. > Further on normal event handling applies. > This approach has the advantage, that EventBuffer and Embedded can still be used > in addition. > > For all 'dynamic' events like pulses, DTMF, SPCM, normal event > handling applies. > > Best regards > > Thomas > > Christian Groves wrote: > > > > Hello Thomas, > > > > Are you wanting a general purpose mechanism such as the off-hook one > > or do you just want the default stated for H.248.26 and H.246.ICASC? > > > > Kevin Boyle is the editor of these he may have some opinion on this. > > > > Its always possible to make amendments to existing recommendations. > > Bring in a contribution for consideration to SG16 or propose a > > detailed solution on the Megaco list for experts to review. If they > > are agreeable then the change will be added. > > > > Regards, Christian > > > > Thomas Voith wrote: > > > > > Dear list-members, > > > > > > H.248.26 and in H.248.ICAS I miss a feature, which has been used > > > already for On-Hook, Off-Hook the 'strict' parameter. > > > > > > All interfaces, which have static states, should implement such a > > > mechanism. > > > > > > The problem is that the EventsDescriptor EventBufferDescriptor or > > > an embedded EventsDescriptor may discard events, if the newly > > > received or replacing Event Descriptor does not match the event. > > > > > > In the Megaco Secnarios, always just the good case is shown. > > > > > > e.g. a static interface with 4 logical incoming events ( > > > S1,S2,S3,S4) would then set the EventsDescripror like: > > > > > > MGC guess the MG is in state i1, no Notify will be sent by MG, > > > when state of interface is still i1. > > > > > > Events { > > > S1{strict="exact"},S2{strict="state"},S3{strict="state"},S4{strict > > > =" > > > state"} } > > > > > > ( Note: in case "state" is the default, then EventsDescriptor > > > could be shorter) > > > > > > The events descriptor remains active, after Notification is sent. > > > The strict parameter avoids unnecessary Notifications for the > > > already by MGC known state. > > > > > > This mechanism would be very simple and avoids lost of any events, > > > which is strong required for signalling interfaces on MG > > > transferred via H.248 to an MGC. > > > > > > > > > For a better illustration I have attached a Excel-File containing > > > a simple scenario. > > > > > > So my question/proposal is: > > > > > > - Is it possible to extend the existing static state interfacepackages like H.248.26 with this > > > strict feature? > > > - If not, can I get this functionality otherwise ? > > > > > > Kind regards > > > > > > Thomas Voith > > > > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco > > -- _______________________________________________________________ > _ > V | Thomas Voith > +---------------+ | Dept. VS/EAC2 [Systems] > | A L C A T E L | | FL/2/50 > +---------------+ | > | Tel: +49 711 821-40293 > | Alcanet: 259-40293 > Alcatel SEL AG | Fax: +49 711 821-40211 > Fixed Networks Division | > Lorenzstr. 10 | mailto:Thomas.Voith@alcatel.de > D-70435 Stuttgart, Germany | > _______________________________________________________________ > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco -- _______________________________________________________________ _ V | Thomas Voith +---------------+ | Dept. VS/EAC2 [Systems] | A L C A T E L | | FL/2/50 +---------------+ | | Tel: +49 711 821-40293 | Alcanet: 259-40293 Alcatel SEL AG | Fax: +49 711 821-40211 Fixed Networks Division | Lorenzstr. 10 | mailto:Thomas.Voith@alcatel.de D-70435 Stuttgart, Germany | _______________________________________________________________ _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Oct 2 14:21:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18240 for ; Thu, 2 Oct 2003 14:21:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A584Y-0001Mz-IN for megaco-archive@odin.ietf.org; Thu, 02 Oct 2003 14:21:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92IL6Vv005261 for megaco-archive@odin.ietf.org; Thu, 2 Oct 2003 14:21:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A584W-0001Mm-Tb for megaco-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 14:21:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18194 for ; Thu, 2 Oct 2003 14:20:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A584U-0004n4-00 for megaco-web-archive@ietf.org; Thu, 02 Oct 2003 14:21:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A584T-0004n1-00 for megaco-web-archive@ietf.org; Thu, 02 Oct 2003 14:21:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A584T-0001MB-Pf; Thu, 02 Oct 2003 14:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5849-0001Le-QT for megaco@optimus.ietf.org; Thu, 02 Oct 2003 14:20:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18181 for ; Thu, 2 Oct 2003 14:20:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5847-0004mh-00 for megaco@ietf.org; Thu, 02 Oct 2003 14:20:39 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1A5846-0004lx-00 for megaco@ietf.org; Thu, 02 Oct 2003 14:20:38 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h92IK7u08703 for ; Thu, 2 Oct 2003 14:20:07 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Oct 2003 14:20:08 -0400 Message-ID: From: "Kevin Boyle" To: Thomas Voith Cc: Christian Groves , megaco@ietf.org, ITU-SG16@external.cisco.com Subject: RE: [Megaco] Re: Event descriptor handling for static logic inter faces like CAS Date: Thu, 2 Oct 2003 14:20:03 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Apparently, I misunderstood what you were looking for. Unless I hear any objections, I will add that function to ICAS for the next meeting. Of course, this does nothing for the BCAS spec -- I assume we will need the same change there? This will require an amendment to H.248.25... I don't think this kind of change will be acceptable as an IG change. Comments? Kevin -----Original Message----- From: Thomas Voith [mailto:Thomas.Voith@alcatel.de] Sent: Thursday, October 02, 2003 10:09 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH] Cc: Christian Groves; megaco@ietf.org; ITU-SG16@external.cisco.com Subject: Re: [Megaco] Re: Event descriptor handling for static logic interfaces like CAS Hello Kevin What you mean is a general behavior, but MGC can not control it. This does not solve the problem which I ment. To make it easy I take the example for 'al/on al/of': The MGC want to be notified for 'al/on' and 'al/of'. MGC assumes that the line is in state 'al/on'. With Events{al/on{strict='exact'},al/of{strict='state'},....} the MGC do not get a Notify for al/on, because it is not necessary. When MGC then knows with the next notify, that the line is off-hook, it send perhaps a new EventsDescriptor containing the DigitMap, but now with Events{al/on{strict='state'},al/of{strict='exact'},....} This avoids again not needed Notify's. Same applies for CAS, where you have more states. With this mechanism you can update the EventsDescriptor for other things bind to this termination like R2 register signalling without again a not needed Notify AND in addition all static events are detected, not only the good case next step. Regards Thomas > Kevin Boyle wrote: > > Thomas, > > The function you want already exists in the package. Each one of the > line signalling events in both ICAS and BCAS have descriptions that > contain the following: > > The event is reported by the MG if either the timed transition to this > line signal is detected or the line signal already exists. > > This means that the strict=state behavior is already inherent in these > events. I see no problem with this, and no need for a change to these > packages. > > Kevin > > -----Original Message----- > From: Thomas Voith [mailto:Thomas.Voith@alcatel.de] > Sent: Thursday, October 02, 2003 4:00 AM > To: Christian Groves > Cc: megaco@ietf.org; ITU-SG16@external.cisco.com > Subject: Re: [Megaco] Re: Event descriptor handling for static logic > interfaces like CAS > > Hello Christian > > I want both, > - strict parameter for CAS Line signals and in future for all > 'static'signalling interfaces. > - optionally a default strict="state" to shorten the Events Descriptor > > In my opinion, this should be used for all 'static' signalling > interfaces. With 'static' I mean that this interface has always a > state, when MG receives an EventsDescriptor from MGC. For > synchronizing the states from MGC with MG the strict mechanism is very > useful. Doing the same with EventBuffer, Embedded Descriptor > > is much more complex and increases extreme with the number of possible > states on the interface. > > Note: This 'strict' parameter is just used by MG to determine, whether a Notify > for the existing state on the interface has to be sent or not. > Further on normal event handling applies. > This approach has the advantage, that EventBuffer and Embedded can still be used > in addition. > > For all 'dynamic' events like pulses, DTMF, SPCM, normal event > handling applies. > > Best regards > > Thomas > > Christian Groves wrote: > > > > Hello Thomas, > > > > Are you wanting a general purpose mechanism such as the off-hook one > > or do you just want the default stated for H.248.26 and H.246.ICASC? > > > > Kevin Boyle is the editor of these he may have some opinion on this. > > > > Its always possible to make amendments to existing recommendations. > > Bring in a contribution for consideration to SG16 or propose a > > detailed solution on the Megaco list for experts to review. If they > > are agreeable then the change will be added. > > > > Regards, Christian > > > > Thomas Voith wrote: > > > > > Dear list-members, > > > > > > H.248.26 and in H.248.ICAS I miss a feature, which has been used > > > already for On-Hook, Off-Hook the 'strict' parameter. > > > > > > All interfaces, which have static states, should implement such a > > > mechanism. > > > > > > The problem is that the EventsDescriptor EventBufferDescriptor or > > > an embedded EventsDescriptor may discard events, if the newly > > > received or replacing Event Descriptor does not match the event. > > > > > > In the Megaco Secnarios, always just the good case is shown. > > > > > > e.g. a static interface with 4 logical incoming events ( > > > S1,S2,S3,S4) would then set the EventsDescripror like: > > > > > > MGC guess the MG is in state i1, no Notify will be sent by MG, > > > when state of interface is still i1. > > > > > > Events { > > > S1{strict="exact"},S2{strict="state"},S3{strict="state"},S4{strict > > > =" > > > state"} } > > > > > > ( Note: in case "state" is the default, then EventsDescriptor > > > could be shorter) > > > > > > The events descriptor remains active, after Notification is sent. > > > The strict parameter avoids unnecessary Notifications for the > > > already by MGC known state. > > > > > > This mechanism would be very simple and avoids lost of any events, > > > which is strong required for signalling interfaces on MG > > > transferred via H.248 to an MGC. > > > > > > > > > For a better illustration I have attached a Excel-File containing > > > a simple scenario. > > > > > > So my question/proposal is: > > > > > > - Is it possible to extend the existing static state interfacepackages like H.248.26 with this > > > strict feature? > > > - If not, can I get this functionality otherwise ? > > > > > > Kind regards > > > > > > Thomas Voith > > > > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco > > -- _______________________________________________________________ > _ > V | Thomas Voith > +---------------+ | Dept. VS/EAC2 [Systems] > | A L C A T E L | | FL/2/50 > +---------------+ | > | Tel: +49 711 821-40293 > | Alcanet: 259-40293 > Alcatel SEL AG | Fax: +49 711 821-40211 > Fixed Networks Division | > Lorenzstr. 10 | mailto:Thomas.Voith@alcatel.de > D-70435 Stuttgart, Germany | > _______________________________________________________________ > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco -- _______________________________________________________________ _ V | Thomas Voith +---------------+ | Dept. VS/EAC2 [Systems] | A L C A T E L | | FL/2/50 +---------------+ | | Tel: +49 711 821-40293 | Alcanet: 259-40293 Alcatel SEL AG | Fax: +49 711 821-40211 Fixed Networks Division | Lorenzstr. 10 | mailto:Thomas.Voith@alcatel.de D-70435 Stuttgart, Germany | _______________________________________________________________ _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Oct 2 17:17:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26198 for ; Thu, 2 Oct 2003 17:17:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Aoo-0003II-51; Thu, 02 Oct 2003 17:17:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A55OI-0006Xx-Fu for megaco@optimus.ietf.org; Thu, 02 Oct 2003 11:29:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26664 for ; Thu, 2 Oct 2003 11:29:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A55OH-0002Lv-00 for megaco@ietf.org; Thu, 02 Oct 2003 11:29:17 -0400 Received: from zdemail04.zdem.compaq.com ([161.114.112.28]) by ietf-mx with esmtp (Exim 4.12) id 1A55OG-0002Kd-00 for megaco@ietf.org; Thu, 02 Oct 2003 11:29:16 -0400 Received: from demexg11.emea.cpqcorp.net (demexg11.emea.cpqcorp.net [16.41.86.63]) by zdemail04.zdem.compaq.com (Postfix) with ESMTP id 19CFAE03 for ; Thu, 2 Oct 2003 17:28:44 +0200 (CEST) Received: from demexc02.emea.cpqcorp.net ([16.41.86.72]) by demexg11.emea.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Thu, 2 Oct 2003 17:28:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C388F9.DD3FCD0A" Date: Thu, 2 Oct 2003 17:28:43 +0200 Message-ID: Thread-Topic: How to retrieve the context name of an existing termination Thread-Index: AcOI+dz9bQMZNRnIQXeTRfRhXUhYqA== From: "El Moussawi, Ali" To: X-OriginalArrivalTime: 02 Oct 2003 15:28:44.0018 (UTC) FILETIME=[DD751D20:01C388F9] Subject: [Megaco] How to retrieve the context name of an existing termination Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C388F9.DD3FCD0A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Suppose that a MGC receives a IAM message, and the IAM message contains a CIC =3D 3. This means that this CIC has been already reserved at the MG level, right ? If the MGC and MG speeks MEGACO, this means that there is already a context having a termination named Trunk1/line3 (is the name right ?) in the MG. And the termination is in ReceiveOnly mode. How can we retrieve the name of the context ? If the MGC sends : MEGACO/1 [1.0.0.0]:1 Transaction =3D 1{ Context =3D $ { Modify =3D Trunk1/line3 { Media { LocalControl {Mode=3DSendReceive} } } } } Will it receive the context name in the reply ? MEGACO/1 [2.0.0.0]:2 Transaction =3D 1{ Context =3D 1 { Modify =3D Trunk1/line3=20 } } Thanks Ali ------_=_NextPart_001_01C388F9.DD3FCD0A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable How to retrieve the context name of an existing = termination

Hello,
Suppose that a MGC receives a IAM = message, and the IAM message contains a CIC =3D 3.
This means that this CIC has been = already reserved at the MG level, right ?
If the MGC and MG speeks MEGACO, this = means that there is already a context having a termination named = Trunk1/line3 (is the name right ?) in the MG. And the termination is in = ReceiveOnly mode.

How can we retrieve the name of the = context ?
If the MGC sends :
MEGACO/1 [1.0.0.0]:1
        Transaction =3D 1{
        =         Context =3D $ {
        =         =         Modify =3D Trunk1/line3 {

                      Media {

        =         =         =         =         =         =         LocalControl {Mode=3DSendReceive}

                          }

                                }

              }

            }

Will it receive the context name in = the reply ?
MEGACO/1 [2.0.0.0]:2
        Transaction =3D 1{
        =         Context =3D 1 {

                      Modify =3D Trunk1/line3
              }

            }



Thanks

Ali

------_=_NextPart_001_01C388F9.DD3FCD0A-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Oct 2 17:17:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26213 for ; Thu, 2 Oct 2003 17:17:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Aor-0003JQ-B3 for megaco-archive@odin.ietf.org; Thu, 02 Oct 2003 17:17:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92LH52q012728 for megaco-archive@odin.ietf.org; Thu, 2 Oct 2003 17:17:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Aor-0003JD-7r for megaco-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 17:17:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26173 for ; Thu, 2 Oct 2003 17:16:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Aoo-0006x4-00 for megaco-web-archive@ietf.org; Thu, 02 Oct 2003 17:17:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5Aoo-0006x1-00 for megaco-web-archive@ietf.org; Thu, 02 Oct 2003 17:17:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Aoo-0003II-51; Thu, 02 Oct 2003 17:17:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A55OI-0006Xx-Fu for megaco@optimus.ietf.org; Thu, 02 Oct 2003 11:29:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26664 for ; Thu, 2 Oct 2003 11:29:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A55OH-0002Lv-00 for megaco@ietf.org; Thu, 02 Oct 2003 11:29:17 -0400 Received: from zdemail04.zdem.compaq.com ([161.114.112.28]) by ietf-mx with esmtp (Exim 4.12) id 1A55OG-0002Kd-00 for megaco@ietf.org; Thu, 02 Oct 2003 11:29:16 -0400 Received: from demexg11.emea.cpqcorp.net (demexg11.emea.cpqcorp.net [16.41.86.63]) by zdemail04.zdem.compaq.com (Postfix) with ESMTP id 19CFAE03 for ; Thu, 2 Oct 2003 17:28:44 +0200 (CEST) Received: from demexc02.emea.cpqcorp.net ([16.41.86.72]) by demexg11.emea.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Thu, 2 Oct 2003 17:28:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C388F9.DD3FCD0A" Date: Thu, 2 Oct 2003 17:28:43 +0200 Message-ID: Thread-Topic: How to retrieve the context name of an existing termination Thread-Index: AcOI+dz9bQMZNRnIQXeTRfRhXUhYqA== From: "El Moussawi, Ali" To: X-OriginalArrivalTime: 02 Oct 2003 15:28:44.0018 (UTC) FILETIME=[DD751D20:01C388F9] Subject: [Megaco] How to retrieve the context name of an existing termination Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C388F9.DD3FCD0A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Suppose that a MGC receives a IAM message, and the IAM message contains a CIC =3D 3. This means that this CIC has been already reserved at the MG level, right ? If the MGC and MG speeks MEGACO, this means that there is already a context having a termination named Trunk1/line3 (is the name right ?) in the MG. And the termination is in ReceiveOnly mode. How can we retrieve the name of the context ? If the MGC sends : MEGACO/1 [1.0.0.0]:1 Transaction =3D 1{ Context =3D $ { Modify =3D Trunk1/line3 { Media { LocalControl {Mode=3DSendReceive} } } } } Will it receive the context name in the reply ? MEGACO/1 [2.0.0.0]:2 Transaction =3D 1{ Context =3D 1 { Modify =3D Trunk1/line3=20 } } Thanks Ali ------_=_NextPart_001_01C388F9.DD3FCD0A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable How to retrieve the context name of an existing = termination

Hello,
Suppose that a MGC receives a IAM = message, and the IAM message contains a CIC =3D 3.
This means that this CIC has been = already reserved at the MG level, right ?
If the MGC and MG speeks MEGACO, this = means that there is already a context having a termination named = Trunk1/line3 (is the name right ?) in the MG. And the termination is in = ReceiveOnly mode.

How can we retrieve the name of the = context ?
If the MGC sends :
MEGACO/1 [1.0.0.0]:1
        Transaction =3D 1{
        =         Context =3D $ {
        =         =         Modify =3D Trunk1/line3 {

                      Media {

        =         =         =         =         =         =         LocalControl {Mode=3DSendReceive}

                          }

                                }

              }

            }

Will it receive the context name in = the reply ?
MEGACO/1 [2.0.0.0]:2
        Transaction =3D 1{
        =         Context =3D 1 {

                      Modify =3D Trunk1/line3
              }

            }



Thanks

Ali

------_=_NextPart_001_01C388F9.DD3FCD0A-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Oct 2 19:26:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00484 for ; Thu, 2 Oct 2003 19:26:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Cpd-0000mO-6y; Thu, 02 Oct 2003 19:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Cp4-0000lv-Qf for megaco@optimus.ietf.org; Thu, 02 Oct 2003 19:25:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00461 for ; Thu, 2 Oct 2003 19:25:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Cp3-0000CB-00 for megaco@ietf.org; Thu, 02 Oct 2003 19:25:25 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 1A5Cp2-0000C8-00 for megaco@ietf.org; Thu, 02 Oct 2003 19:25:24 -0400 Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h92NLtt03281; Fri, 3 Oct 2003 09:21:55 +1000 (EST) Received: from ericsson.com.au (146.11.245.144 [146.11.245.144]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SYC15FWL; Fri, 3 Oct 2003 09:24:00 +1000 Message-ID: <3F7CB2D1.8070108@ericsson.com.au> Date: Fri, 03 Oct 2003 09:20:49 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "El Moussawi, Ali" CC: megaco@ietf.org Subject: Re: [Megaco] How to retrieve the context name of an existing termination References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Ali, The Termination Trunk1/line will be in the NULL context. To initiate a connection in the MG you will first have to ADD this termination to a context. The context ID at this stage can be wildcarded. The reply will contain the correct context ID. eg. > Transaction = 1{ > Context = $ { > Add.request = Trunk1/line3 {...} > Transaction = 1{ > Context = 5 { > Add.reply = Trunk1/line3 {} Regards, Christian El Moussawi, Ali wrote: > Hello, > Suppose that a MGC receives a IAM message, and the IAM message contains > a CIC = 3. > This means that this CIC has been already reserved at the MG level, right ? > If the MGC and MG speeks MEGACO, this means that there is already a > context having a termination named Trunk1/line3 (is the name right ?) in > the MG. And the termination is in ReceiveOnly mode. > > How can we retrieve the name of the context ? > If the MGC sends : > Transaction = 1{ > Context = $ { > Modify.Req = Trunk1/line3 { > > Media { > > LocalControl > {Mode=SendReceive} > > } > > } > > } > > } > > Will it receive the context name in the reply ? > MEGACO/1 [2.0.0.0]:2 > Transaction = 1{ > Context = 1 { > > Modify = Trunk1/line3 > } > > } > > > > Thanks > > Ali > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Oct 2 19:26:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00499 for ; Thu, 2 Oct 2003 19:26:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Cpf-0000nE-E9 for megaco-archive@odin.ietf.org; Thu, 02 Oct 2003 19:26:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92NQ3EP003044 for megaco-archive@odin.ietf.org; Thu, 2 Oct 2003 19:26:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Cpf-0000n1-7c for megaco-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 19:26:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00474 for ; Thu, 2 Oct 2003 19:25:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Cpd-0000CU-00 for megaco-web-archive@ietf.org; Thu, 02 Oct 2003 19:26:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5Cpd-0000CR-00 for megaco-web-archive@ietf.org; Thu, 02 Oct 2003 19:26:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Cpd-0000mO-6y; Thu, 02 Oct 2003 19:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Cp4-0000lv-Qf for megaco@optimus.ietf.org; Thu, 02 Oct 2003 19:25:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00461 for ; Thu, 2 Oct 2003 19:25:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Cp3-0000CB-00 for megaco@ietf.org; Thu, 02 Oct 2003 19:25:25 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 1A5Cp2-0000C8-00 for megaco@ietf.org; Thu, 02 Oct 2003 19:25:24 -0400 Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h92NLtt03281; Fri, 3 Oct 2003 09:21:55 +1000 (EST) Received: from ericsson.com.au (146.11.245.144 [146.11.245.144]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SYC15FWL; Fri, 3 Oct 2003 09:24:00 +1000 Message-ID: <3F7CB2D1.8070108@ericsson.com.au> Date: Fri, 03 Oct 2003 09:20:49 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "El Moussawi, Ali" CC: megaco@ietf.org Subject: Re: [Megaco] How to retrieve the context name of an existing termination References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Ali, The Termination Trunk1/line will be in the NULL context. To initiate a connection in the MG you will first have to ADD this termination to a context. The context ID at this stage can be wildcarded. The reply will contain the correct context ID. eg. > Transaction = 1{ > Context = $ { > Add.request = Trunk1/line3 {...} > Transaction = 1{ > Context = 5 { > Add.reply = Trunk1/line3 {} Regards, Christian El Moussawi, Ali wrote: > Hello, > Suppose that a MGC receives a IAM message, and the IAM message contains > a CIC = 3. > This means that this CIC has been already reserved at the MG level, right ? > If the MGC and MG speeks MEGACO, this means that there is already a > context having a termination named Trunk1/line3 (is the name right ?) in > the MG. And the termination is in ReceiveOnly mode. > > How can we retrieve the name of the context ? > If the MGC sends : > Transaction = 1{ > Context = $ { > Modify.Req = Trunk1/line3 { > > Media { > > LocalControl > {Mode=SendReceive} > > } > > } > > } > > } > > Will it receive the context name in the reply ? > MEGACO/1 [2.0.0.0]:2 > Transaction = 1{ > Context = 1 { > > Modify = Trunk1/line3 > } > > } > > > > Thanks > > Ali > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Oct 2 19:35:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00851 for ; Thu, 2 Oct 2003 19:35:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5CyN-0001Kb-4C; Thu, 02 Oct 2003 19:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Cy2-0001K1-84 for megaco@optimus.ietf.org; Thu, 02 Oct 2003 19:34:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00827 for ; Thu, 2 Oct 2003 19:34:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Cy0-0000IF-00 for megaco@ietf.org; Thu, 02 Oct 2003 19:34:40 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 1A5Cxz-0000I2-00 for megaco@ietf.org; Thu, 02 Oct 2003 19:34:39 -0400 Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h92NVGt04441; Fri, 3 Oct 2003 09:31:17 +1000 (EST) Received: from ericsson.com.au (146.11.245.144 [146.11.245.144]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SYC15F6P; Fri, 3 Oct 2003 09:33:20 +1000 Message-ID: <3F7CB504.2010007@ericsson.com.au> Date: Fri, 03 Oct 2003 09:30:12 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Boyle CC: Thomas Voith , megaco@ietf.org Subject: Re: [Megaco] Re: Event descriptor handling for static logic inter References: <200310021843.h92Ih1oN020427@domohead.cisco.com> In-Reply-To: <200310021843.h92Ih1oN020427@domohead.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Kevin and Thomas, As this exact and strict functionality seems to be tied to several packages is this something that we could perhaps add to the core protocol ie. H.248.1v3? It seems to me to control protocol operation rather than providing specific functionality. Regards, Christian Kevin Boyle wrote: > Apparently, I misunderstood what you were looking for. Unless I hear > any objections, I will add that function to ICAS for the next meeting. > > Of course, this does nothing for the BCAS spec -- I assume we will need > the same change there? This will require an amendment to H.248.25... I > don't think this kind of change will be acceptable as an IG change. > > Comments? > > Kevin > > -----Original Message----- > From: Thomas Voith [mailto:Thomas.Voith@alcatel.de] > Sent: Thursday, October 02, 2003 10:09 AM > To: Boyle, Kevin [NCRTP:3Z40:EXCH] > Cc: Christian Groves; megaco@ietf.org; ITU-SG16@external.cisco.com > Subject: Re: [Megaco] Re: Event descriptor handling for static logic > interfaces like CAS > > > Hello Kevin > > What you mean is a general behavior, but MGC can not control it. This > does not solve the problem which I ment. > > To make it easy I take the example for 'al/on al/of': > > The MGC want to be notified for 'al/on' and 'al/of'. > MGC assumes that the line is in state 'al/on'. > > With Events{al/on{strict='exact'},al/of{strict='state'},....} > the MGC do not get a Notify for al/on, because it is not necessary. > > When MGC then knows with the next notify, that the line is off-hook, it > send perhaps a new EventsDescriptor containing the DigitMap, but now > with Events{al/on{strict='state'},al/of{strict='exact'},....} > > This avoids again not needed Notify's. > > Same applies for CAS, where you have more states. > With this mechanism you can update the EventsDescriptor for other things > bind to this termination like R2 register signalling without again > > a not needed Notify AND in addition all static events are detected, not > only the good case next step. > > Regards > > Thomas > > > > > Kevin Boyle wrote: > > > > Thomas, > > > > The function you want already exists in the package. Each one of the > > line signalling events in both ICAS and BCAS have descriptions that > > contain the following: > > > > The event is reported by the MG if either the timed transition to this > > line signal is detected or the line signal already exists. > > > > This means that the strict=state behavior is already inherent in these > > events. I see no problem with this, and no need for a change to these > > packages. > > > > Kevin > > > > -----Original Message----- > > From: Thomas Voith [mailto:Thomas.Voith@alcatel.de] > > Sent: Thursday, October 02, 2003 4:00 AM > > To: Christian Groves > > Cc: megaco@ietf.org; ITU-SG16@external.cisco.com > > Subject: Re: [Megaco] Re: Event descriptor handling for static logic > > interfaces like CAS > > > > Hello Christian > > > > I want both, > > - strict parameter for CAS Line signals and in future for all > > 'static'signalling interfaces. > > - optionally a default strict="state" to shorten the Events Descriptor > > > > In my opinion, this should be used for all 'static' signalling > > interfaces. With 'static' I mean that this interface has always a > > state, when MG receives an EventsDescriptor from MGC. For > > synchronizing the states from MGC with MG the strict mechanism is very > > useful. Doing the same with EventBuffer, Embedded Descriptor > > > > is much more complex and increases extreme with the number of possible > > states on the interface. > > > > Note: This 'strict' parameter is just used by MG to determine, > whether a Notify > > for the existing state on the interface has to be sent or not. > > Further on normal event handling applies. > > This approach has the advantage, that EventBuffer and Embedded > can still be used > > in addition. > > > > For all 'dynamic' events like pulses, DTMF, SPCM, normal event > > handling applies. > > > > Best regards > > > > Thomas > > > > Christian Groves wrote: > > > > > > Hello Thomas, > > > > > > Are you wanting a general purpose mechanism such as the off-hook one > > > or do you just want the default stated for H.248.26 and H.246.ICASC? > > > > > > Kevin Boyle is the editor of these he may have some opinion on this. > > > > > > Its always possible to make amendments to existing recommendations. > > > Bring in a contribution for consideration to SG16 or propose a > > > detailed solution on the Megaco list for experts to review. If they > > > are agreeable then the change will be added. > > > > > > Regards, Christian > > > > > > Thomas Voith wrote: > > > > > > > Dear list-members, > > > > > > > > H.248.26 and in H.248.ICAS I miss a feature, which has been used > > > > already for On-Hook, Off-Hook the 'strict' parameter. > > > > > > > > All interfaces, which have static states, should implement such a > > > > mechanism. > > > > > > > > The problem is that the EventsDescriptor EventBufferDescriptor or > > > > an embedded EventsDescriptor may discard events, if the newly > > > > received or replacing Event Descriptor does not match the event. > > > > > > > > In the Megaco Secnarios, always just the good case is shown. > > > > > > > > e.g. a static interface with 4 logical incoming events ( > > > > S1,S2,S3,S4) would then set the EventsDescripror like: > > > > > > > > MGC guess the MG is in state i1, no Notify will be sent by MG, > > > > when state of interface is still i1. > > > > > > > > Events { > > > > S1{strict="exact"},S2{strict="state"},S3{strict="state"},S4{strict > > > > =" > > > > state"} } > > > > > > > > ( Note: in case "state" is the default, then EventsDescriptor > > > > could be shorter) > > > > > > > > The events descriptor remains active, after Notification is sent. > > > > The strict parameter avoids unnecessary Notifications for the > > > > already by MGC known state. > > > > > > > > This mechanism would be very simple and avoids lost of any events, > > > > which is strong required for signalling interfaces on MG > > > > transferred via H.248 to an MGC. > > > > > > > > > > > > For a better illustration I have attached a Excel-File containing > > > > a simple scenario. > > > > > > > > So my question/proposal is: > > > > > > > > - Is it possible to extend the existing static state > interfacepackages like H.248.26 with this > > > > strict feature? > > > > - If not, can I get this functionality otherwise ? > > > > > > > > Kind regards > > > > > > > > Thomas Voith > > > > > > > > > > _______________________________________________ > > > Megaco mailing list > > > Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco > > > > -- _______________________________________________________________ > > _ > > V | Thomas Voith > > +---------------+ | Dept. VS/EAC2 [Systems] > > | A L C A T E L | | FL/2/50 > > +---------------+ | > > | Tel: +49 711 821-40293 > > | Alcanet: 259-40293 > > Alcatel SEL AG | Fax: +49 711 821-40211 > > Fixed Networks Division | > > Lorenzstr. 10 | mailto:Thomas.Voith@alcatel.de > > D-70435 Stuttgart, Germany | > > _______________________________________________________________ > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco > > -- > _______________________________________________________________ > _ > V | Thomas Voith > +---------------+ | Dept. VS/EAC2 [Systems] > | A L C A T E L | | FL/2/50 > +---------------+ | > | Tel: +49 711 821-40293 > | Alcanet: 259-40293 > Alcatel SEL AG | Fax: +49 711 821-40211 > Fixed Networks Division | > Lorenzstr. 10 | mailto:Thomas.Voith@alcatel.de > D-70435 Stuttgart, Germany | > _______________________________________________________________ > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Oct 2 19:35:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00866 for ; Thu, 2 Oct 2003 19:35:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5CyP-0001LG-LL for megaco-archive@odin.ietf.org; Thu, 02 Oct 2003 19:35:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92NZ5MJ005152 for megaco-archive@odin.ietf.org; Thu, 2 Oct 2003 19:35:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5CyP-0001L1-EW for megaco-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 19:35:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00832 for ; Thu, 2 Oct 2003 19:34:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5CyN-0000Id-00 for megaco-web-archive@ietf.org; Thu, 02 Oct 2003 19:35:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5CyN-0000Ia-00 for megaco-web-archive@ietf.org; Thu, 02 Oct 2003 19:35:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5CyN-0001Kb-4C; Thu, 02 Oct 2003 19:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Cy2-0001K1-84 for megaco@optimus.ietf.org; Thu, 02 Oct 2003 19:34:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00827 for ; Thu, 2 Oct 2003 19:34:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Cy0-0000IF-00 for megaco@ietf.org; Thu, 02 Oct 2003 19:34:40 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 1A5Cxz-0000I2-00 for megaco@ietf.org; Thu, 02 Oct 2003 19:34:39 -0400 Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h92NVGt04441; Fri, 3 Oct 2003 09:31:17 +1000 (EST) Received: from ericsson.com.au (146.11.245.144 [146.11.245.144]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SYC15F6P; Fri, 3 Oct 2003 09:33:20 +1000 Message-ID: <3F7CB504.2010007@ericsson.com.au> Date: Fri, 03 Oct 2003 09:30:12 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Boyle CC: Thomas Voith , megaco@ietf.org Subject: Re: [Megaco] Re: Event descriptor handling for static logic inter References: <200310021843.h92Ih1oN020427@domohead.cisco.com> In-Reply-To: <200310021843.h92Ih1oN020427@domohead.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Kevin and Thomas, As this exact and strict functionality seems to be tied to several packages is this something that we could perhaps add to the core protocol ie. H.248.1v3? It seems to me to control protocol operation rather than providing specific functionality. Regards, Christian Kevin Boyle wrote: > Apparently, I misunderstood what you were looking for. Unless I hear > any objections, I will add that function to ICAS for the next meeting. > > Of course, this does nothing for the BCAS spec -- I assume we will need > the same change there? This will require an amendment to H.248.25... I > don't think this kind of change will be acceptable as an IG change. > > Comments? > > Kevin > > -----Original Message----- > From: Thomas Voith [mailto:Thomas.Voith@alcatel.de] > Sent: Thursday, October 02, 2003 10:09 AM > To: Boyle, Kevin [NCRTP:3Z40:EXCH] > Cc: Christian Groves; megaco@ietf.org; ITU-SG16@external.cisco.com > Subject: Re: [Megaco] Re: Event descriptor handling for static logic > interfaces like CAS > > > Hello Kevin > > What you mean is a general behavior, but MGC can not control it. This > does not solve the problem which I ment. > > To make it easy I take the example for 'al/on al/of': > > The MGC want to be notified for 'al/on' and 'al/of'. > MGC assumes that the line is in state 'al/on'. > > With Events{al/on{strict='exact'},al/of{strict='state'},....} > the MGC do not get a Notify for al/on, because it is not necessary. > > When MGC then knows with the next notify, that the line is off-hook, it > send perhaps a new EventsDescriptor containing the DigitMap, but now > with Events{al/on{strict='state'},al/of{strict='exact'},....} > > This avoids again not needed Notify's. > > Same applies for CAS, where you have more states. > With this mechanism you can update the EventsDescriptor for other things > bind to this termination like R2 register signalling without again > > a not needed Notify AND in addition all static events are detected, not > only the good case next step. > > Regards > > Thomas > > > > > Kevin Boyle wrote: > > > > Thomas, > > > > The function you want already exists in the package. Each one of the > > line signalling events in both ICAS and BCAS have descriptions that > > contain the following: > > > > The event is reported by the MG if either the timed transition to this > > line signal is detected or the line signal already exists. > > > > This means that the strict=state behavior is already inherent in these > > events. I see no problem with this, and no need for a change to these > > packages. > > > > Kevin > > > > -----Original Message----- > > From: Thomas Voith [mailto:Thomas.Voith@alcatel.de] > > Sent: Thursday, October 02, 2003 4:00 AM > > To: Christian Groves > > Cc: megaco@ietf.org; ITU-SG16@external.cisco.com > > Subject: Re: [Megaco] Re: Event descriptor handling for static logic > > interfaces like CAS > > > > Hello Christian > > > > I want both, > > - strict parameter for CAS Line signals and in future for all > > 'static'signalling interfaces. > > - optionally a default strict="state" to shorten the Events Descriptor > > > > In my opinion, this should be used for all 'static' signalling > > interfaces. With 'static' I mean that this interface has always a > > state, when MG receives an EventsDescriptor from MGC. For > > synchronizing the states from MGC with MG the strict mechanism is very > > useful. Doing the same with EventBuffer, Embedded Descriptor > > > > is much more complex and increases extreme with the number of possible > > states on the interface. > > > > Note: This 'strict' parameter is just used by MG to determine, > whether a Notify > > for the existing state on the interface has to be sent or not. > > Further on normal event handling applies. > > This approach has the advantage, that EventBuffer and Embedded > can still be used > > in addition. > > > > For all 'dynamic' events like pulses, DTMF, SPCM, normal event > > handling applies. > > > > Best regards > > > > Thomas > > > > Christian Groves wrote: > > > > > > Hello Thomas, > > > > > > Are you wanting a general purpose mechanism such as the off-hook one > > > or do you just want the default stated for H.248.26 and H.246.ICASC? > > > > > > Kevin Boyle is the editor of these he may have some opinion on this. > > > > > > Its always possible to make amendments to existing recommendations. > > > Bring in a contribution for consideration to SG16 or propose a > > > detailed solution on the Megaco list for experts to review. If they > > > are agreeable then the change will be added. > > > > > > Regards, Christian > > > > > > Thomas Voith wrote: > > > > > > > Dear list-members, > > > > > > > > H.248.26 and in H.248.ICAS I miss a feature, which has been used > > > > already for On-Hook, Off-Hook the 'strict' parameter. > > > > > > > > All interfaces, which have static states, should implement such a > > > > mechanism. > > > > > > > > The problem is that the EventsDescriptor EventBufferDescriptor or > > > > an embedded EventsDescriptor may discard events, if the newly > > > > received or replacing Event Descriptor does not match the event. > > > > > > > > In the Megaco Secnarios, always just the good case is shown. > > > > > > > > e.g. a static interface with 4 logical incoming events ( > > > > S1,S2,S3,S4) would then set the EventsDescripror like: > > > > > > > > MGC guess the MG is in state i1, no Notify will be sent by MG, > > > > when state of interface is still i1. > > > > > > > > Events { > > > > S1{strict="exact"},S2{strict="state"},S3{strict="state"},S4{strict > > > > =" > > > > state"} } > > > > > > > > ( Note: in case "state" is the default, then EventsDescriptor > > > > could be shorter) > > > > > > > > The events descriptor remains active, after Notification is sent. > > > > The strict parameter avoids unnecessary Notifications for the > > > > already by MGC known state. > > > > > > > > This mechanism would be very simple and avoids lost of any events, > > > > which is strong required for signalling interfaces on MG > > > > transferred via H.248 to an MGC. > > > > > > > > > > > > For a better illustration I have attached a Excel-File containing > > > > a simple scenario. > > > > > > > > So my question/proposal is: > > > > > > > > - Is it possible to extend the existing static state > interfacepackages like H.248.26 with this > > > > strict feature? > > > > - If not, can I get this functionality otherwise ? > > > > > > > > Kind regards > > > > > > > > Thomas Voith > > > > > > > > > > _______________________________________________ > > > Megaco mailing list > > > Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco > > > > -- _______________________________________________________________ > > _ > > V | Thomas Voith > > +---------------+ | Dept. VS/EAC2 [Systems] > > | A L C A T E L | | FL/2/50 > > +---------------+ | > > | Tel: +49 711 821-40293 > > | Alcanet: 259-40293 > > Alcatel SEL AG | Fax: +49 711 821-40211 > > Fixed Networks Division | > > Lorenzstr. 10 | mailto:Thomas.Voith@alcatel.de > > D-70435 Stuttgart, Germany | > > _______________________________________________________________ > > > > _______________________________________________ > > Megaco mailing list > > Megaco@ietf.org > > https://www1.ietf.org/mailman/listinfo/megaco > > -- > _______________________________________________________________ > _ > V | Thomas Voith > +---------------+ | Dept. VS/EAC2 [Systems] > | A L C A T E L | | FL/2/50 > +---------------+ | > | Tel: +49 711 821-40293 > | Alcanet: 259-40293 > Alcatel SEL AG | Fax: +49 711 821-40211 > Fixed Networks Division | > Lorenzstr. 10 | mailto:Thomas.Voith@alcatel.de > D-70435 Stuttgart, Germany | > _______________________________________________________________ > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Oct 2 19:51:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01167 for ; Thu, 2 Oct 2003 19:51:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5DDp-00027D-7b; Thu, 02 Oct 2003 19:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5DDQ-00026q-GN for megaco@optimus.ietf.org; Thu, 02 Oct 2003 19:50:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01149 for ; Thu, 2 Oct 2003 19:50:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5DDO-0000Ph-00 for megaco@ietf.org; Thu, 02 Oct 2003 19:50:34 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 1A5DDN-0000PX-00 for megaco@ietf.org; Thu, 02 Oct 2003 19:50:33 -0400 Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h92NlBt06309; Fri, 3 Oct 2003 09:47:12 +1000 (EST) Received: from ericsson.com.au (146.11.245.144 [146.11.245.144]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SYC15G1N; Fri, 3 Oct 2003 09:49:15 +1000 Message-ID: <3F7CB8BF.4000002@ericsson.com.au> Date: Fri, 03 Oct 2003 09:46:07 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aleksandr Ryabin CC: Kevin Boyle , megaco@ietf.org Subject: Re: [Megaco] CAS Metering Pulse support References: <5.2.1.1.0.20031002095954.02afce00@IL06EXM13.corp.mot.com> In-Reply-To: <5.2.1.1.0.20031002095954.02afce00@IL06EXM13.corp.mot.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Aleksandr, I agree that no new package is needed for the detection of metering pulse functionality. From the description of the event it seems that it clear how it to be used. The package also contains the procedural text: "If following the application of any metering pulse (regardless of whether it was generated as a result of the signal em or as a result of the signal mbp), the EventsDescriptor contains the event pr, and if the value of pcslr is equal to the value of the EventsDescriptor parameter rp, then the pr event shall be notified, and the value of the statistic pcslr shall be reset to zero. The detection of the event pr shall not cause the termination of the signal em or the signal mbp, even if the KeepActive flag is not set for the pr event." Is this text sufficient? Regards, Christian Aleksandr Ryabin wrote: > Hi, > > In continuation to this metering pulse support. > > I've looked through amet package and it does not seem to > define procedure to detect metering pulses, it only has > a procedure to generate metering pulses. > > I see no reason of defining a new package for detecting incoming > metering pulses and I propose to reuse amet and amend it to > define procedure for detecting incoming metering pulses. > > Here is the summary of a proposed metering pulse detection > procedure using amet package: > > The detection of metering pulse on a termination could be enabled > by MGC when no amet signals are played on a termination by > requesting detection amet/pr event with a required repetition period. > MG would Notify MGC with amet/pr event when number of metering > pulses is detected according to repetition period parameter set. > > On Subtract, or explicit AuditValue MG would send amet/cpc > and amet/pcslr statistics similar to as described in the package > provided their description extended to detection as well. > > Comments? > > Thanks > Aleks > > BTW IANA MEGACO page is still not updated. > > At 10:50 AM 9/16/2003, Aleksandr Ryabin wrote: > >> It is updated with H.248.22 and 25, but not with 23, 24, 26, 27 >> while all of them are dated in ITU the same. Strange. >> Aleks >> >> At 10:46 AM 9/16/2003, Kevin Boyle wrote: >> >>> If it is NOT updated, that is. (Apparently, it's going to be one of >>> those days!) >>> >>> Kevin >>> >>> -----Original Message----- >>> From: Boyle, Kevin [NCRTP:3Z40:EXCH] >>> Sent: Tuesday, September 16, 2003 10:39 AM >>> To: Aleksandr Ryabin; megaco@ietf.org >>> Subject: RE: [Megaco] CAS Metering Pulse support >>> >>> Ummm... yeah. That's what I get for not looking it up before sending >>> the message. :) While amet is defined in the "Extended Analog Lines >>> Packages" doc, there is nothing in the amet package that actually >>> limits it to analog lines. >>> >>> >>> The updates for all the new (as of May) H.248 Sub-series >>> Recommendations have already been requested of IANA. If it is >>> updated by the end of the month, I'll ping them again. >>> >>> >>> Kevin >>> >>> -----Original Message----- >>> From: Aleksandr Ryabin [mailto:kengr@motorola.com] >>> Sent: Tuesday, September 16, 2003 10:32 AM >>> To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org >>> Subject: RE: [Megaco] CAS Metering Pulse support >>> >>> Hi, >>> >>> I guess you meant H.248.26. >>> Yes it seem to address the needs assuming it is extended to digital >>> lines as well. >>> >>> BTW IANA registry should be updated with H.248.26 and H.248.27 >>> http://www.iana.org/assignments/megaco-h248 >>> >>> >>> Thanks, >>> Aleks >>> >>> At 10:00 AM 9/16/2003, Kevin Boyle wrote: >>> >>> >>> H.248.27 has a metering package (automatic metering package or >>> amet). This package may address your needs. >>> >>> Kevin >>> >>> -----Original Message----- >>> From: Aleksandr Ryabin [mailto:kengr@motorola.com >>> ] >>> Sent: Tuesday, September 16, 2003 9:34 AM >>> To: megaco@ietf.org >>> Subject: [Megaco] CAS Metering Pulse support >>> >>> Hi all, >>> >>> Below are excerpts from a previous exchange related to defining of >>> CAS Metering Pulse procedures in MEGACO. >>> >>> Now that CAS packages related work has been moved to ITU has anyone >>> done and/or planned anything in the direction to define CAS Metering >>> Pulse procedures/package for MEGACO? >>> >>> Thanks >>> Aleks >>> >>> >From: klaha@hss.hns.com >>> >To: Aleksandr Ryabin >>> >cc: vnair@hss.hns.com, megaco@ietf.org, klaha@hss.hns.com >>> >Date: Tue, 4 Mar 2003 12:47:37 +0530 >>> >Subject: Re: [Megaco] Re: draft-ietf-megaco-r2package-03.txt : >>> Difference >>> > from previous revision >>> ... >>> >Aleksandr Ryabin on 03/03/2003 10:43:20 PM >>> ... >>> >3. I can't seem to find a way to implement "Metering Pulse" procedure >>> >defined for some R2 variants using ether bcas or R2 packages? For >>> >example, one of the definitions of such a pulse is a "seizure ack" >>> >pulse from a terminating end on a circuit in connected/answer state. >>> > >>> >[Kushanava] Metering is not specific to R2. It may be present in any >>> >CAS signaling. Moreover not all flavours of R2 permit metering to be >>> >mandatory. There should be therefore a general philosophy of attacking >>> >this problem common to all CAS signaling. The solution should be >>> >sensitive to >>> >a) Realizing that MGC is the master for collecting and generating >>> charging >>> >information >>> >b) Interworking of the CAS "metering pulse" signals with other >>> signaling >>> >(both PDN and PSTN) >>> >c) Optimizing the network traffic if metering information is >>> transported to >>> >>> >and fro between MGC and MG >>> >d) Latency, if metering information is transported to and fro >>> between MGC >>> >and MG >>> >We are working towards a separate package that addresses this issue. >>> >Any suggestions? >>> ... >>> >>> _______________________________________________ >>> Megaco mailing list >>> Megaco@ietf.org >>> https://www1.ietf.org/mailman/listinfo/megaco >>> >>> >>> _______________________________________________ >>> Megaco mailing list >>> Megaco@ietf.org >>> https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Oct 2 19:51:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01182 for ; Thu, 2 Oct 2003 19:51:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5DDr-00028d-3R for megaco-archive@odin.ietf.org; Thu, 02 Oct 2003 19:51:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92Np3X5008213 for megaco-archive@odin.ietf.org; Thu, 2 Oct 2003 19:51:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5DDq-00028O-UM for megaco-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 19:51:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01161 for ; Thu, 2 Oct 2003 19:50:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5DDo-0000Py-00 for megaco-web-archive@ietf.org; Thu, 02 Oct 2003 19:51:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5DDo-0000Pv-00 for megaco-web-archive@ietf.org; Thu, 02 Oct 2003 19:51:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5DDp-00027D-7b; Thu, 02 Oct 2003 19:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5DDQ-00026q-GN for megaco@optimus.ietf.org; Thu, 02 Oct 2003 19:50:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01149 for ; Thu, 2 Oct 2003 19:50:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5DDO-0000Ph-00 for megaco@ietf.org; Thu, 02 Oct 2003 19:50:34 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 1A5DDN-0000PX-00 for megaco@ietf.org; Thu, 02 Oct 2003 19:50:33 -0400 Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h92NlBt06309; Fri, 3 Oct 2003 09:47:12 +1000 (EST) Received: from ericsson.com.au (146.11.245.144 [146.11.245.144]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SYC15G1N; Fri, 3 Oct 2003 09:49:15 +1000 Message-ID: <3F7CB8BF.4000002@ericsson.com.au> Date: Fri, 03 Oct 2003 09:46:07 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aleksandr Ryabin CC: Kevin Boyle , megaco@ietf.org Subject: Re: [Megaco] CAS Metering Pulse support References: <5.2.1.1.0.20031002095954.02afce00@IL06EXM13.corp.mot.com> In-Reply-To: <5.2.1.1.0.20031002095954.02afce00@IL06EXM13.corp.mot.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Aleksandr, I agree that no new package is needed for the detection of metering pulse functionality. From the description of the event it seems that it clear how it to be used. The package also contains the procedural text: "If following the application of any metering pulse (regardless of whether it was generated as a result of the signal em or as a result of the signal mbp), the EventsDescriptor contains the event pr, and if the value of pcslr is equal to the value of the EventsDescriptor parameter rp, then the pr event shall be notified, and the value of the statistic pcslr shall be reset to zero. The detection of the event pr shall not cause the termination of the signal em or the signal mbp, even if the KeepActive flag is not set for the pr event." Is this text sufficient? Regards, Christian Aleksandr Ryabin wrote: > Hi, > > In continuation to this metering pulse support. > > I've looked through amet package and it does not seem to > define procedure to detect metering pulses, it only has > a procedure to generate metering pulses. > > I see no reason of defining a new package for detecting incoming > metering pulses and I propose to reuse amet and amend it to > define procedure for detecting incoming metering pulses. > > Here is the summary of a proposed metering pulse detection > procedure using amet package: > > The detection of metering pulse on a termination could be enabled > by MGC when no amet signals are played on a termination by > requesting detection amet/pr event with a required repetition period. > MG would Notify MGC with amet/pr event when number of metering > pulses is detected according to repetition period parameter set. > > On Subtract, or explicit AuditValue MG would send amet/cpc > and amet/pcslr statistics similar to as described in the package > provided their description extended to detection as well. > > Comments? > > Thanks > Aleks > > BTW IANA MEGACO page is still not updated. > > At 10:50 AM 9/16/2003, Aleksandr Ryabin wrote: > >> It is updated with H.248.22 and 25, but not with 23, 24, 26, 27 >> while all of them are dated in ITU the same. Strange. >> Aleks >> >> At 10:46 AM 9/16/2003, Kevin Boyle wrote: >> >>> If it is NOT updated, that is. (Apparently, it's going to be one of >>> those days!) >>> >>> Kevin >>> >>> -----Original Message----- >>> From: Boyle, Kevin [NCRTP:3Z40:EXCH] >>> Sent: Tuesday, September 16, 2003 10:39 AM >>> To: Aleksandr Ryabin; megaco@ietf.org >>> Subject: RE: [Megaco] CAS Metering Pulse support >>> >>> Ummm... yeah. That's what I get for not looking it up before sending >>> the message. :) While amet is defined in the "Extended Analog Lines >>> Packages" doc, there is nothing in the amet package that actually >>> limits it to analog lines. >>> >>> >>> The updates for all the new (as of May) H.248 Sub-series >>> Recommendations have already been requested of IANA. If it is >>> updated by the end of the month, I'll ping them again. >>> >>> >>> Kevin >>> >>> -----Original Message----- >>> From: Aleksandr Ryabin [mailto:kengr@motorola.com] >>> Sent: Tuesday, September 16, 2003 10:32 AM >>> To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org >>> Subject: RE: [Megaco] CAS Metering Pulse support >>> >>> Hi, >>> >>> I guess you meant H.248.26. >>> Yes it seem to address the needs assuming it is extended to digital >>> lines as well. >>> >>> BTW IANA registry should be updated with H.248.26 and H.248.27 >>> http://www.iana.org/assignments/megaco-h248 >>> >>> >>> Thanks, >>> Aleks >>> >>> At 10:00 AM 9/16/2003, Kevin Boyle wrote: >>> >>> >>> H.248.27 has a metering package (automatic metering package or >>> amet). This package may address your needs. >>> >>> Kevin >>> >>> -----Original Message----- >>> From: Aleksandr Ryabin [mailto:kengr@motorola.com >>> ] >>> Sent: Tuesday, September 16, 2003 9:34 AM >>> To: megaco@ietf.org >>> Subject: [Megaco] CAS Metering Pulse support >>> >>> Hi all, >>> >>> Below are excerpts from a previous exchange related to defining of >>> CAS Metering Pulse procedures in MEGACO. >>> >>> Now that CAS packages related work has been moved to ITU has anyone >>> done and/or planned anything in the direction to define CAS Metering >>> Pulse procedures/package for MEGACO? >>> >>> Thanks >>> Aleks >>> >>> >From: klaha@hss.hns.com >>> >To: Aleksandr Ryabin >>> >cc: vnair@hss.hns.com, megaco@ietf.org, klaha@hss.hns.com >>> >Date: Tue, 4 Mar 2003 12:47:37 +0530 >>> >Subject: Re: [Megaco] Re: draft-ietf-megaco-r2package-03.txt : >>> Difference >>> > from previous revision >>> ... >>> >Aleksandr Ryabin on 03/03/2003 10:43:20 PM >>> ... >>> >3. I can't seem to find a way to implement "Metering Pulse" procedure >>> >defined for some R2 variants using ether bcas or R2 packages? For >>> >example, one of the definitions of such a pulse is a "seizure ack" >>> >pulse from a terminating end on a circuit in connected/answer state. >>> > >>> >[Kushanava] Metering is not specific to R2. It may be present in any >>> >CAS signaling. Moreover not all flavours of R2 permit metering to be >>> >mandatory. There should be therefore a general philosophy of attacking >>> >this problem common to all CAS signaling. The solution should be >>> >sensitive to >>> >a) Realizing that MGC is the master for collecting and generating >>> charging >>> >information >>> >b) Interworking of the CAS "metering pulse" signals with other >>> signaling >>> >(both PDN and PSTN) >>> >c) Optimizing the network traffic if metering information is >>> transported to >>> >>> >and fro between MGC and MG >>> >d) Latency, if metering information is transported to and fro >>> between MGC >>> >and MG >>> >We are working towards a separate package that addresses this issue. >>> >Any suggestions? >>> ... >>> >>> _______________________________________________ >>> Megaco mailing list >>> Megaco@ietf.org >>> https://www1.ietf.org/mailman/listinfo/megaco >>> >>> >>> _______________________________________________ >>> Megaco mailing list >>> Megaco@ietf.org >>> https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Oct 2 20:28:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02080 for ; Thu, 2 Oct 2003 20:28:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Dnd-0003dD-DX; Thu, 02 Oct 2003 20:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Dmr-0003Yx-V8 for megaco@optimus.ietf.org; Thu, 02 Oct 2003 20:27:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02040 for ; Thu, 2 Oct 2003 20:27:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Dmp-0000k3-00 for megaco@ietf.org; Thu, 02 Oct 2003 20:27:11 -0400 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 1A5Dmo-0000k0-00 for megaco@ietf.org; Thu, 02 Oct 2003 20:27:11 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h930R7P1018179; Thu, 2 Oct 2003 17:27:07 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id h930R4Su028200; Thu, 2 Oct 2003 19:27:05 -0500 Message-Id: <5.2.1.1.0.20031002200223.0246ded8@IL06EXM13.corp.mot.com> X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 02 Oct 2003 20:24:23 -0400 To: Christian Groves, From: Aleksandr Ryabin Subject: Re: [Megaco] CAS Metering Pulse support Cc: Kevin Boyle In-Reply-To: <3F7CB8BF.4000002@ericsson.com.au> References: <5.2.1.1.0.20031002095954.02afce00@IL06EXM13.corp.mot.com> <5.2.1.1.0.20031002095954.02afce00@IL06EXM13.corp.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi Christian, No description of the event does say how to use it for detection incoming metering pulse. More over it explicitly limits to generation: "This event is used in conjunction with the "enable metering" and "metering pulse burst" signals defined in this package..." My point being that descriptions of amet events and statistics are siting that event pr is generated and statistics are changed only based on previously applied em, or mbp signal. The wording needs to be amended to cover the cases when event is generated and statistics are changed as a result *detection* of incoming metering pulse. That is, for example, the text you have referenced should be changed to something like this (I've placed the changes in [] for visibility): "If following the application [or detection] of any metering pulse (regardless of [whether it was detected, or] whether it was generated as a result of the signal em or as a result of the signal mbp), the EventsDescriptor contains the event pr, and if the value of pcslr is equal to the value of the EventsDescriptor parameter rp, then the pr event shall be notified, and the value of the statistic pcslr shall be reset to zero. The detection of the event pr shall not cause the termination of the signal em or the signal mbp, [if currently active,] even if the KeepActive flag is not set for the pr event." Regards, Aleks At 07:46 PM 10/2/2003, Christian Groves wrote: >Hello Aleksandr, > >I agree that no new package is needed for the detection of metering pulse >functionality. From the description of the event it seems that it clear >how it to be used. > >The package also contains the procedural text: >"If following the application of any metering pulse (regardless of whether >it was generated as a result of the signal em or as a result of the signal >mbp), the EventsDescriptor contains the event pr, and if the value of >pcslr is equal to the value of the EventsDescriptor parameter rp, then the >pr event shall be notified, and the value of the statistic pcslr shall be >reset to zero. The detection of the event pr shall not cause the >termination of the signal em or the signal mbp, even if the KeepActive >flag is not set for the pr event." > >Is this text sufficient? > >Regards, Christian > >Aleksandr Ryabin wrote: > >>Hi, >>In continuation to this metering pulse support. >>I've looked through amet package and it does not seem to >>define procedure to detect metering pulses, it only has >>a procedure to generate metering pulses. >>I see no reason of defining a new package for detecting incoming >>metering pulses and I propose to reuse amet and amend it to >>define procedure for detecting incoming metering pulses. >>Here is the summary of a proposed metering pulse detection >>procedure using amet package: >>The detection of metering pulse on a termination could be enabled >>by MGC when no amet signals are played on a termination by >>requesting detection amet/pr event with a required repetition period. >>MG would Notify MGC with amet/pr event when number of metering >>pulses is detected according to repetition period parameter set. >>On Subtract, or explicit AuditValue MG would send amet/cpc >>and amet/pcslr statistics similar to as described in the package >>provided their description extended to detection as well. >>Comments? >>Thanks >> Aleks >>BTW IANA MEGACO page is still not updated. >>At 10:50 AM 9/16/2003, Aleksandr Ryabin wrote: >> >>>It is updated with H.248.22 and 25, but not with 23, 24, 26, 27 >>>while all of them are dated in ITU the same. Strange. >>> Aleks >>> >>>At 10:46 AM 9/16/2003, Kevin Boyle wrote: >>> >>>>If it is NOT updated, that is. (Apparently, it's going to be one of >>>>those days!) >>>> >>>>Kevin >>>> >>>>-----Original Message----- >>>>From: Boyle, Kevin [NCRTP:3Z40:EXCH] >>>>Sent: Tuesday, September 16, 2003 10:39 AM >>>>To: Aleksandr Ryabin; megaco@ietf.org >>>>Subject: RE: [Megaco] CAS Metering Pulse support >>>> >>>>Ummm... yeah. That's what I get for not looking it up before sending >>>>the message. :) While amet is defined in the "Extended Analog Lines >>>>Packages" doc, there is nothing in the amet package that actually >>>>limits it to analog lines. >>>> >>>> >>>>The updates for all the new (as of May) H.248 Sub-series >>>>Recommendations have already been requested of IANA. If it is updated >>>>by the end of the month, I'll ping them again. >>>> >>>> >>>>Kevin >>>> >>>>-----Original Message----- >>>>From: Aleksandr Ryabin [mailto:kengr@motorola.com] >>>>Sent: Tuesday, September 16, 2003 10:32 AM >>>>To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org >>>>Subject: RE: [Megaco] CAS Metering Pulse support >>>> >>>>Hi, >>>> >>>>I guess you meant H.248.26. >>>>Yes it seem to address the needs assuming it is extended to digital >>>>lines as well. >>>> >>>>BTW IANA registry should be updated with H.248.26 and H.248.27 >>>>http://www.iana.org/assignments/megaco-h248 >>>> >>>> >>>>Thanks, >>>> Aleks >>>> >>>>At 10:00 AM 9/16/2003, Kevin Boyle wrote: >>>> >>>> >>>>H.248.27 has a metering package (automatic metering package or >>>>amet). This package may address your needs. >>>> >>>>Kevin >>>> >>>>-----Original Message----- >>>>From: Aleksandr Ryabin [mailto:kengr@motorola.com >>>> ] >>>>Sent: Tuesday, September 16, 2003 9:34 AM >>>>To: megaco@ietf.org >>>>Subject: [Megaco] CAS Metering Pulse support >>>> >>>>Hi all, >>>> >>>>Below are excerpts from a previous exchange related to defining of CAS >>>>Metering Pulse procedures in MEGACO. >>>> >>>>Now that CAS packages related work has been moved to ITU has anyone >>>>done and/or planned anything in the direction to define CAS Metering >>>>Pulse procedures/package for MEGACO? >>>> >>>>Thanks >>>> Aleks >>>> >>>> >From: klaha@hss.hns.com >>>> >To: Aleksandr Ryabin >>>> >cc: vnair@hss.hns.com, megaco@ietf.org, klaha@hss.hns.com >>>> >Date: Tue, 4 Mar 2003 12:47:37 +0530 >>>> >Subject: Re: [Megaco] Re: draft-ietf-megaco-r2package-03.txt : Difference >>>> > from previous revision >>>>... >>>> >Aleksandr Ryabin on 03/03/2003 10:43:20 PM >>>>... >>>> >3. I can't seem to find a way to implement "Metering Pulse" procedure >>>> >defined for some R2 variants using ether bcas or R2 packages? For >>>> >example, one of the definitions of such a pulse is a "seizure ack" >>>> >pulse from a terminating end on a circuit in connected/answer state. >>>> > >>>> >[Kushanava] Metering is not specific to R2. It may be present in any >>>> >CAS signaling. Moreover not all flavours of R2 permit metering to be >>>> >mandatory. There should be therefore a general philosophy of attacking >>>> >this problem common to all CAS signaling. The solution should be >>>> >sensitive to >>>> >a) Realizing that MGC is the master for collecting and generating >>>> charging >>>> >information >>>> >b) Interworking of the CAS "metering pulse" signals with other signaling >>>> >(both PDN and PSTN) >>>> >c) Optimizing the network traffic if metering information is >>>> transported to >>>> >>>> >and fro between MGC and MG >>>> >d) Latency, if metering information is transported to and fro between MGC >>>> >and MG >>>> >We are working towards a separate package that addresses this issue. >>>> >Any suggestions? >>>>... >>>> >>>>_______________________________________________ >>>>Megaco mailing list >>>>Megaco@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/megaco >>>> >>>>_______________________________________________ >>>>Megaco mailing list >>>>Megaco@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Oct 2 20:28:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02095 for ; Thu, 2 Oct 2003 20:28:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Dnh-0003em-6U for megaco-archive@odin.ietf.org; Thu, 02 Oct 2003 20:28:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h930S5T4014050 for megaco-archive@odin.ietf.org; Thu, 2 Oct 2003 20:28:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Dnh-0003eX-28 for megaco-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 20:28:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02074 for ; Thu, 2 Oct 2003 20:27:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Dne-0000kW-00 for megaco-web-archive@ietf.org; Thu, 02 Oct 2003 20:28:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5Dne-0000kT-00 for megaco-web-archive@ietf.org; Thu, 02 Oct 2003 20:28:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Dnd-0003dD-DX; Thu, 02 Oct 2003 20:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Dmr-0003Yx-V8 for megaco@optimus.ietf.org; Thu, 02 Oct 2003 20:27:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02040 for ; Thu, 2 Oct 2003 20:27:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Dmp-0000k3-00 for megaco@ietf.org; Thu, 02 Oct 2003 20:27:11 -0400 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 1A5Dmo-0000k0-00 for megaco@ietf.org; Thu, 02 Oct 2003 20:27:11 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h930R7P1018179; Thu, 2 Oct 2003 17:27:07 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id h930R4Su028200; Thu, 2 Oct 2003 19:27:05 -0500 Message-Id: <5.2.1.1.0.20031002200223.0246ded8@IL06EXM13.corp.mot.com> X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 02 Oct 2003 20:24:23 -0400 To: Christian Groves, From: Aleksandr Ryabin Subject: Re: [Megaco] CAS Metering Pulse support Cc: Kevin Boyle In-Reply-To: <3F7CB8BF.4000002@ericsson.com.au> References: <5.2.1.1.0.20031002095954.02afce00@IL06EXM13.corp.mot.com> <5.2.1.1.0.20031002095954.02afce00@IL06EXM13.corp.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi Christian, No description of the event does say how to use it for detection incoming metering pulse. More over it explicitly limits to generation: "This event is used in conjunction with the "enable metering" and "metering pulse burst" signals defined in this package..." My point being that descriptions of amet events and statistics are siting that event pr is generated and statistics are changed only based on previously applied em, or mbp signal. The wording needs to be amended to cover the cases when event is generated and statistics are changed as a result *detection* of incoming metering pulse. That is, for example, the text you have referenced should be changed to something like this (I've placed the changes in [] for visibility): "If following the application [or detection] of any metering pulse (regardless of [whether it was detected, or] whether it was generated as a result of the signal em or as a result of the signal mbp), the EventsDescriptor contains the event pr, and if the value of pcslr is equal to the value of the EventsDescriptor parameter rp, then the pr event shall be notified, and the value of the statistic pcslr shall be reset to zero. The detection of the event pr shall not cause the termination of the signal em or the signal mbp, [if currently active,] even if the KeepActive flag is not set for the pr event." Regards, Aleks At 07:46 PM 10/2/2003, Christian Groves wrote: >Hello Aleksandr, > >I agree that no new package is needed for the detection of metering pulse >functionality. From the description of the event it seems that it clear >how it to be used. > >The package also contains the procedural text: >"If following the application of any metering pulse (regardless of whether >it was generated as a result of the signal em or as a result of the signal >mbp), the EventsDescriptor contains the event pr, and if the value of >pcslr is equal to the value of the EventsDescriptor parameter rp, then the >pr event shall be notified, and the value of the statistic pcslr shall be >reset to zero. The detection of the event pr shall not cause the >termination of the signal em or the signal mbp, even if the KeepActive >flag is not set for the pr event." > >Is this text sufficient? > >Regards, Christian > >Aleksandr Ryabin wrote: > >>Hi, >>In continuation to this metering pulse support. >>I've looked through amet package and it does not seem to >>define procedure to detect metering pulses, it only has >>a procedure to generate metering pulses. >>I see no reason of defining a new package for detecting incoming >>metering pulses and I propose to reuse amet and amend it to >>define procedure for detecting incoming metering pulses. >>Here is the summary of a proposed metering pulse detection >>procedure using amet package: >>The detection of metering pulse on a termination could be enabled >>by MGC when no amet signals are played on a termination by >>requesting detection amet/pr event with a required repetition period. >>MG would Notify MGC with amet/pr event when number of metering >>pulses is detected according to repetition period parameter set. >>On Subtract, or explicit AuditValue MG would send amet/cpc >>and amet/pcslr statistics similar to as described in the package >>provided their description extended to detection as well. >>Comments? >>Thanks >> Aleks >>BTW IANA MEGACO page is still not updated. >>At 10:50 AM 9/16/2003, Aleksandr Ryabin wrote: >> >>>It is updated with H.248.22 and 25, but not with 23, 24, 26, 27 >>>while all of them are dated in ITU the same. Strange. >>> Aleks >>> >>>At 10:46 AM 9/16/2003, Kevin Boyle wrote: >>> >>>>If it is NOT updated, that is. (Apparently, it's going to be one of >>>>those days!) >>>> >>>>Kevin >>>> >>>>-----Original Message----- >>>>From: Boyle, Kevin [NCRTP:3Z40:EXCH] >>>>Sent: Tuesday, September 16, 2003 10:39 AM >>>>To: Aleksandr Ryabin; megaco@ietf.org >>>>Subject: RE: [Megaco] CAS Metering Pulse support >>>> >>>>Ummm... yeah. That's what I get for not looking it up before sending >>>>the message. :) While amet is defined in the "Extended Analog Lines >>>>Packages" doc, there is nothing in the amet package that actually >>>>limits it to analog lines. >>>> >>>> >>>>The updates for all the new (as of May) H.248 Sub-series >>>>Recommendations have already been requested of IANA. If it is updated >>>>by the end of the month, I'll ping them again. >>>> >>>> >>>>Kevin >>>> >>>>-----Original Message----- >>>>From: Aleksandr Ryabin [mailto:kengr@motorola.com] >>>>Sent: Tuesday, September 16, 2003 10:32 AM >>>>To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org >>>>Subject: RE: [Megaco] CAS Metering Pulse support >>>> >>>>Hi, >>>> >>>>I guess you meant H.248.26. >>>>Yes it seem to address the needs assuming it is extended to digital >>>>lines as well. >>>> >>>>BTW IANA registry should be updated with H.248.26 and H.248.27 >>>>http://www.iana.org/assignments/megaco-h248 >>>> >>>> >>>>Thanks, >>>> Aleks >>>> >>>>At 10:00 AM 9/16/2003, Kevin Boyle wrote: >>>> >>>> >>>>H.248.27 has a metering package (automatic metering package or >>>>amet). This package may address your needs. >>>> >>>>Kevin >>>> >>>>-----Original Message----- >>>>From: Aleksandr Ryabin [mailto:kengr@motorola.com >>>> ] >>>>Sent: Tuesday, September 16, 2003 9:34 AM >>>>To: megaco@ietf.org >>>>Subject: [Megaco] CAS Metering Pulse support >>>> >>>>Hi all, >>>> >>>>Below are excerpts from a previous exchange related to defining of CAS >>>>Metering Pulse procedures in MEGACO. >>>> >>>>Now that CAS packages related work has been moved to ITU has anyone >>>>done and/or planned anything in the direction to define CAS Metering >>>>Pulse procedures/package for MEGACO? >>>> >>>>Thanks >>>> Aleks >>>> >>>> >From: klaha@hss.hns.com >>>> >To: Aleksandr Ryabin >>>> >cc: vnair@hss.hns.com, megaco@ietf.org, klaha@hss.hns.com >>>> >Date: Tue, 4 Mar 2003 12:47:37 +0530 >>>> >Subject: Re: [Megaco] Re: draft-ietf-megaco-r2package-03.txt : Difference >>>> > from previous revision >>>>... >>>> >Aleksandr Ryabin on 03/03/2003 10:43:20 PM >>>>... >>>> >3. I can't seem to find a way to implement "Metering Pulse" procedure >>>> >defined for some R2 variants using ether bcas or R2 packages? For >>>> >example, one of the definitions of such a pulse is a "seizure ack" >>>> >pulse from a terminating end on a circuit in connected/answer state. >>>> > >>>> >[Kushanava] Metering is not specific to R2. It may be present in any >>>> >CAS signaling. Moreover not all flavours of R2 permit metering to be >>>> >mandatory. There should be therefore a general philosophy of attacking >>>> >this problem common to all CAS signaling. The solution should be >>>> >sensitive to >>>> >a) Realizing that MGC is the master for collecting and generating >>>> charging >>>> >information >>>> >b) Interworking of the CAS "metering pulse" signals with other signaling >>>> >(both PDN and PSTN) >>>> >c) Optimizing the network traffic if metering information is >>>> transported to >>>> >>>> >and fro between MGC and MG >>>> >d) Latency, if metering information is transported to and fro between MGC >>>> >and MG >>>> >We are working towards a separate package that addresses this issue. >>>> >Any suggestions? >>>>... >>>> >>>>_______________________________________________ >>>>Megaco mailing list >>>>Megaco@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/megaco >>>> >>>>_______________________________________________ >>>>Megaco mailing list >>>>Megaco@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Oct 2 20:31:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02253 for ; Thu, 2 Oct 2003 20:31:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5DqZ-0003vy-1p; Thu, 02 Oct 2003 20:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5DqN-0003uS-Iv for megaco@optimus.ietf.org; Thu, 02 Oct 2003 20:30:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02183 for ; Thu, 2 Oct 2003 20:30:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5DqL-0000n6-00 for megaco@ietf.org; Thu, 02 Oct 2003 20:30:49 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx with esmtp (Exim 4.12) id 1A5DqK-0000mv-00 for megaco@ietf.org; Thu, 02 Oct 2003 20:30:48 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h930Ui5e020580; Thu, 2 Oct 2003 17:30:45 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h930Ufgj007799; Thu, 2 Oct 2003 19:30:42 -0500 Message-Id: <5.2.1.1.0.20031002202531.0247e898@IL06EXM13.corp.mot.com> X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 02 Oct 2003 20:27:55 -0400 To: "El Moussawi, Ali", , Christian Groves From: Aleksandr Ryabin Subject: Re: [Megaco] How to retrieve the context name of an existing termination In-Reply-To: <3F7CB2D1.8070108@ericsson.com.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi, In other words MG does not know anything about the CIC being "reserved" It is a job of MGC "to let MG know" about it by issuing the Add command. Regards, Aleks At 07:20 PM 10/2/2003, Christian Groves wrote: >Hello Ali, > >The Termination Trunk1/line will be in the NULL context. To initiate a >connection in the MG you will first have to ADD this termination to a >context. The context ID at this stage can be wildcarded. The reply will >contain the correct context ID. > >eg. > > Transaction = 1{ > > Context = $ { > > Add.request = Trunk1/line3 {...} > > Transaction = 1{ > > Context = 5 { > > Add.reply = Trunk1/line3 {} > > >Regards, Christian > >El Moussawi, Ali wrote: >>Hello, >>Suppose that a MGC receives a IAM message, and the IAM message contains a >>CIC = 3. >>This means that this CIC has been already reserved at the MG level, right ? >>If the MGC and MG speeks MEGACO, this means that there is already a >>context having a termination named Trunk1/line3 (is the name right ?) in >>the MG. And the termination is in ReceiveOnly mode. >>How can we retrieve the name of the context ? >>If the MGC sends : >> Transaction = 1{ >> Context = $ { >> Modify.Req = Trunk1/line3 { >> Media { >> LocalControl >> {Mode=SendReceive} >> } >> } >> } >> } >>Will it receive the context name in the reply ? >>MEGACO/1 [2.0.0.0]:2 >> Transaction = 1{ >> Context = 1 { >> Modify = Trunk1/line3 >> } >> } >> >>Thanks >>Ali > > >_______________________________________________ >Megaco mailing list >Megaco@ietf.org >https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Oct 2 20:31:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02268 for ; Thu, 2 Oct 2003 20:31:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Dqa-0003xO-9R for megaco-archive@odin.ietf.org; Thu, 02 Oct 2003 20:31:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h930V48V015204 for megaco-archive@odin.ietf.org; Thu, 2 Oct 2003 20:31:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Dqa-0003x9-5w for megaco-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 20:31:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02188 for ; Thu, 2 Oct 2003 20:30:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5DqX-0000nT-00 for megaco-web-archive@ietf.org; Thu, 02 Oct 2003 20:31:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5DqX-0000nQ-00 for megaco-web-archive@ietf.org; Thu, 02 Oct 2003 20:31:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5DqZ-0003vy-1p; Thu, 02 Oct 2003 20:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5DqN-0003uS-Iv for megaco@optimus.ietf.org; Thu, 02 Oct 2003 20:30:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02183 for ; Thu, 2 Oct 2003 20:30:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5DqL-0000n6-00 for megaco@ietf.org; Thu, 02 Oct 2003 20:30:49 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx with esmtp (Exim 4.12) id 1A5DqK-0000mv-00 for megaco@ietf.org; Thu, 02 Oct 2003 20:30:48 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h930Ui5e020580; Thu, 2 Oct 2003 17:30:45 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h930Ufgj007799; Thu, 2 Oct 2003 19:30:42 -0500 Message-Id: <5.2.1.1.0.20031002202531.0247e898@IL06EXM13.corp.mot.com> X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 02 Oct 2003 20:27:55 -0400 To: "El Moussawi, Ali", , Christian Groves From: Aleksandr Ryabin Subject: Re: [Megaco] How to retrieve the context name of an existing termination In-Reply-To: <3F7CB2D1.8070108@ericsson.com.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi, In other words MG does not know anything about the CIC being "reserved" It is a job of MGC "to let MG know" about it by issuing the Add command. Regards, Aleks At 07:20 PM 10/2/2003, Christian Groves wrote: >Hello Ali, > >The Termination Trunk1/line will be in the NULL context. To initiate a >connection in the MG you will first have to ADD this termination to a >context. The context ID at this stage can be wildcarded. The reply will >contain the correct context ID. > >eg. > > Transaction = 1{ > > Context = $ { > > Add.request = Trunk1/line3 {...} > > Transaction = 1{ > > Context = 5 { > > Add.reply = Trunk1/line3 {} > > >Regards, Christian > >El Moussawi, Ali wrote: >>Hello, >>Suppose that a MGC receives a IAM message, and the IAM message contains a >>CIC = 3. >>This means that this CIC has been already reserved at the MG level, right ? >>If the MGC and MG speeks MEGACO, this means that there is already a >>context having a termination named Trunk1/line3 (is the name right ?) in >>the MG. And the termination is in ReceiveOnly mode. >>How can we retrieve the name of the context ? >>If the MGC sends : >> Transaction = 1{ >> Context = $ { >> Modify.Req = Trunk1/line3 { >> Media { >> LocalControl >> {Mode=SendReceive} >> } >> } >> } >> } >>Will it receive the context name in the reply ? >>MEGACO/1 [2.0.0.0]:2 >> Transaction = 1{ >> Context = 1 { >> Modify = Trunk1/line3 >> } >> } >> >>Thanks >>Ali > > >_______________________________________________ >Megaco mailing list >Megaco@ietf.org >https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Oct 2 23:43:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07229 for ; Thu, 2 Oct 2003 23:43:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5GqL-0004sY-Pj; Thu, 02 Oct 2003 23:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Gq2-0004sA-9b for megaco@optimus.ietf.org; Thu, 02 Oct 2003 23:42:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07186 for ; Thu, 2 Oct 2003 23:42:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Gq0-0002f6-00 for megaco@ietf.org; Thu, 02 Oct 2003 23:42:40 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 1A5Gpz-0002ev-00 for megaco@ietf.org; Thu, 02 Oct 2003 23:42:39 -0400 Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h933dKt05447; Fri, 3 Oct 2003 13:39:21 +1000 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.245.155]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SYC15KPX; Fri, 3 Oct 2003 13:41:23 +1000 Message-ID: <3F7CEF26.10307@ericsson.com.au> Date: Fri, 03 Oct 2003 13:38:14 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aleksandr Ryabin CC: megaco@ietf.org, Kevin Boyle Subject: Re: [Megaco] CAS Metering Pulse support References: <5.2.1.1.0.20031002095954.02afce00@IL06EXM13.corp.mot.com> <5.2.1.1.0.20031002095954.02afce00@IL06EXM13.corp.mot.com> <5.2.1.1.0.20031002200223.0246ded8@IL06EXM13.corp.mot.com> In-Reply-To: <5.2.1.1.0.20031002200223.0246ded8@IL06EXM13.corp.mot.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello Aleksandr, I'm happy enough to have the your proposed amendment if the editor agrees. Regards, Christian Aleksandr Ryabin wrote: > Hi Christian, > > No description of the event does say how to use it for detection > incoming metering pulse. More over it explicitly limits to generation: > "This event is used in conjunction with the "enable metering" and > "metering pulse burst" signals defined in this package..." > > My point being that descriptions of amet events and statistics > are siting that event pr is generated and statistics are changed > only based on previously applied em, or mbp signal. > > The wording needs to be amended to cover the cases when event > is generated and statistics are changed as a result *detection* of > incoming metering pulse. > > That is, for example, the text you have referenced should be changed > to something like this (I've placed the changes in [] for visibility): > > "If following the application [or detection] of any metering pulse > (regardless > of [whether it was detected, or] whether it was generated as a result > of the signal em or as a result of the signal mbp), the EventsDescriptor > contains the event pr, and if the value of pcslr is equal to the value > of the > EventsDescriptor parameter rp, then the pr event shall be notified, and > the value of the statistic pcslr shall be reset to zero. The detection of > the event pr shall not cause the termination of the signal em or the > signal mbp, [if currently active,] even if the KeepActive flag is not > set for the pr event." > > Regards, > Aleks > > At 07:46 PM 10/2/2003, Christian Groves wrote: > >> Hello Aleksandr, >> >> I agree that no new package is needed for the detection of metering >> pulse functionality. From the description of the event it seems that >> it clear how it to be used. >> >> The package also contains the procedural text: >> "If following the application of any metering pulse (regardless of >> whether it was generated as a result of the signal em or as a result >> of the signal mbp), the EventsDescriptor contains the event pr, and if >> the value of pcslr is equal to the value of the EventsDescriptor >> parameter rp, then the pr event shall be notified, and the value of >> the statistic pcslr shall be reset to zero. The detection of the >> event pr shall not cause the termination of the signal em or the >> signal mbp, even if the KeepActive flag is not set for the pr event." >> >> Is this text sufficient? >> >> Regards, Christian >> >> Aleksandr Ryabin wrote: >> >>> Hi, >>> In continuation to this metering pulse support. >>> I've looked through amet package and it does not seem to >>> define procedure to detect metering pulses, it only has >>> a procedure to generate metering pulses. >>> I see no reason of defining a new package for detecting incoming >>> metering pulses and I propose to reuse amet and amend it to >>> define procedure for detecting incoming metering pulses. >>> Here is the summary of a proposed metering pulse detection >>> procedure using amet package: >>> The detection of metering pulse on a termination could be enabled >>> by MGC when no amet signals are played on a termination by >>> requesting detection amet/pr event with a required repetition period. >>> MG would Notify MGC with amet/pr event when number of metering >>> pulses is detected according to repetition period parameter set. >>> On Subtract, or explicit AuditValue MG would send amet/cpc >>> and amet/pcslr statistics similar to as described in the package >>> provided their description extended to detection as well. >>> Comments? >>> Thanks >>> Aleks >>> BTW IANA MEGACO page is still not updated. >>> At 10:50 AM 9/16/2003, Aleksandr Ryabin wrote: >>> >>>> It is updated with H.248.22 and 25, but not with 23, 24, 26, 27 >>>> while all of them are dated in ITU the same. Strange. >>>> Aleks >>>> >>>> At 10:46 AM 9/16/2003, Kevin Boyle wrote: >>>> >>>>> If it is NOT updated, that is. (Apparently, it's going to be one of >>>>> those days!) >>>>> >>>>> Kevin >>>>> >>>>> -----Original Message----- >>>>> From: Boyle, Kevin [NCRTP:3Z40:EXCH] >>>>> Sent: Tuesday, September 16, 2003 10:39 AM >>>>> To: Aleksandr Ryabin; megaco@ietf.org >>>>> Subject: RE: [Megaco] CAS Metering Pulse support >>>>> >>>>> Ummm... yeah. That's what I get for not looking it up before >>>>> sending the message. :) While amet is defined in the "Extended >>>>> Analog Lines Packages" doc, there is nothing in the amet package >>>>> that actually limits it to analog lines. >>>>> >>>>> >>>>> The updates for all the new (as of May) H.248 Sub-series >>>>> Recommendations have already been requested of IANA. If it is >>>>> updated by the end of the month, I'll ping them again. >>>>> >>>>> >>>>> Kevin >>>>> >>>>> -----Original Message----- >>>>> From: Aleksandr Ryabin [mailto:kengr@motorola.com] >>>>> Sent: Tuesday, September 16, 2003 10:32 AM >>>>> To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org >>>>> Subject: RE: [Megaco] CAS Metering Pulse support >>>>> >>>>> Hi, >>>>> >>>>> I guess you meant H.248.26. >>>>> Yes it seem to address the needs assuming it is extended to digital >>>>> lines as well. >>>>> >>>>> BTW IANA registry should be updated with H.248.26 and H.248.27 >>>>> http://www.iana.org/assignments/megaco-h248 >>>>> >>>>> >>>>> Thanks, >>>>> Aleks >>>>> >>>>> At 10:00 AM 9/16/2003, Kevin Boyle wrote: >>>>> >>>>> >>>>> H.248.27 has a metering package (automatic metering package or >>>>> amet). This package may address your needs. >>>>> >>>>> Kevin >>>>> >>>>> -----Original Message----- >>>>> From: Aleksandr Ryabin [mailto:kengr@motorola.com >>>>> ] >>>>> Sent: Tuesday, September 16, 2003 9:34 AM >>>>> To: megaco@ietf.org >>>>> Subject: [Megaco] CAS Metering Pulse support >>>>> >>>>> Hi all, >>>>> >>>>> Below are excerpts from a previous exchange related to defining of >>>>> CAS Metering Pulse procedures in MEGACO. >>>>> >>>>> Now that CAS packages related work has been moved to ITU has anyone >>>>> done and/or planned anything in the direction to define CAS >>>>> Metering Pulse procedures/package for MEGACO? >>>>> >>>>> Thanks >>>>> Aleks >>>>> >>>>> >From: klaha@hss.hns.com >>>>> >To: Aleksandr Ryabin >>>>> >cc: vnair@hss.hns.com, megaco@ietf.org, klaha@hss.hns.com >>>>> >Date: Tue, 4 Mar 2003 12:47:37 +0530 >>>>> >Subject: Re: [Megaco] Re: draft-ietf-megaco-r2package-03.txt : >>>>> Difference >>>>> > from previous revision >>>>> ... >>>>> >Aleksandr Ryabin on 03/03/2003 10:43:20 PM >>>>> ... >>>>> >3. I can't seem to find a way to implement "Metering Pulse" procedure >>>>> >defined for some R2 variants using ether bcas or R2 packages? For >>>>> >example, one of the definitions of such a pulse is a "seizure ack" >>>>> >pulse from a terminating end on a circuit in connected/answer state. >>>>> > >>>>> >[Kushanava] Metering is not specific to R2. It may be present in any >>>>> >CAS signaling. Moreover not all flavours of R2 permit metering to be >>>>> >mandatory. There should be therefore a general philosophy of >>>>> attacking >>>>> >this problem common to all CAS signaling. The solution should be >>>>> >sensitive to >>>>> >a) Realizing that MGC is the master for collecting and generating >>>>> charging >>>>> >information >>>>> >b) Interworking of the CAS "metering pulse" signals with other >>>>> signaling >>>>> >(both PDN and PSTN) >>>>> >c) Optimizing the network traffic if metering information is >>>>> transported to >>>>> >>>>> >and fro between MGC and MG >>>>> >d) Latency, if metering information is transported to and fro >>>>> between MGC >>>>> >and MG >>>>> >We are working towards a separate package that addresses this issue. >>>>> >Any suggestions? >>>>> ... >>>>> >>>>> _______________________________________________ >>>>> Megaco mailing list >>>>> Megaco@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/megaco >>>>> >>>>> _______________________________________________ >>>>> Megaco mailing list >>>>> Megaco@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/megaco > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Oct 2 23:43:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07244 for ; Thu, 2 Oct 2003 23:43:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5GqR-0004tU-0j for megaco-archive@odin.ietf.org; Thu, 02 Oct 2003 23:43:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h933h6iU018811 for megaco-archive@odin.ietf.org; Thu, 2 Oct 2003 23:43:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5GqQ-0004tK-Rf for megaco-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 23:43:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07207 for ; Thu, 2 Oct 2003 23:42:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5GqO-0002fU-00 for megaco-web-archive@ietf.org; Thu, 02 Oct 2003 23:43:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5GqO-0002fR-00 for megaco-web-archive@ietf.org; Thu, 02 Oct 2003 23:43:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5GqL-0004sY-Pj; Thu, 02 Oct 2003 23:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Gq2-0004sA-9b for megaco@optimus.ietf.org; Thu, 02 Oct 2003 23:42:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07186 for ; Thu, 2 Oct 2003 23:42:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Gq0-0002f6-00 for megaco@ietf.org; Thu, 02 Oct 2003 23:42:40 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 1A5Gpz-0002ev-00 for megaco@ietf.org; Thu, 02 Oct 2003 23:42:39 -0400 Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h933dKt05447; Fri, 3 Oct 2003 13:39:21 +1000 (EST) Received: from ericsson.com.au (E0050DA878EDF [146.11.245.155]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SYC15KPX; Fri, 3 Oct 2003 13:41:23 +1000 Message-ID: <3F7CEF26.10307@ericsson.com.au> Date: Fri, 03 Oct 2003 13:38:14 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aleksandr Ryabin CC: megaco@ietf.org, Kevin Boyle Subject: Re: [Megaco] CAS Metering Pulse support References: <5.2.1.1.0.20031002095954.02afce00@IL06EXM13.corp.mot.com> <5.2.1.1.0.20031002095954.02afce00@IL06EXM13.corp.mot.com> <5.2.1.1.0.20031002200223.0246ded8@IL06EXM13.corp.mot.com> In-Reply-To: <5.2.1.1.0.20031002200223.0246ded8@IL06EXM13.corp.mot.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Aleksandr, I'm happy enough to have the your proposed amendment if the editor agrees. Regards, Christian Aleksandr Ryabin wrote: > Hi Christian, > > No description of the event does say how to use it for detection > incoming metering pulse. More over it explicitly limits to generation: > "This event is used in conjunction with the "enable metering" and > "metering pulse burst" signals defined in this package..." > > My point being that descriptions of amet events and statistics > are siting that event pr is generated and statistics are changed > only based on previously applied em, or mbp signal. > > The wording needs to be amended to cover the cases when event > is generated and statistics are changed as a result *detection* of > incoming metering pulse. > > That is, for example, the text you have referenced should be changed > to something like this (I've placed the changes in [] for visibility): > > "If following the application [or detection] of any metering pulse > (regardless > of [whether it was detected, or] whether it was generated as a result > of the signal em or as a result of the signal mbp), the EventsDescriptor > contains the event pr, and if the value of pcslr is equal to the value > of the > EventsDescriptor parameter rp, then the pr event shall be notified, and > the value of the statistic pcslr shall be reset to zero. The detection of > the event pr shall not cause the termination of the signal em or the > signal mbp, [if currently active,] even if the KeepActive flag is not > set for the pr event." > > Regards, > Aleks > > At 07:46 PM 10/2/2003, Christian Groves wrote: > >> Hello Aleksandr, >> >> I agree that no new package is needed for the detection of metering >> pulse functionality. From the description of the event it seems that >> it clear how it to be used. >> >> The package also contains the procedural text: >> "If following the application of any metering pulse (regardless of >> whether it was generated as a result of the signal em or as a result >> of the signal mbp), the EventsDescriptor contains the event pr, and if >> the value of pcslr is equal to the value of the EventsDescriptor >> parameter rp, then the pr event shall be notified, and the value of >> the statistic pcslr shall be reset to zero. The detection of the >> event pr shall not cause the termination of the signal em or the >> signal mbp, even if the KeepActive flag is not set for the pr event." >> >> Is this text sufficient? >> >> Regards, Christian >> >> Aleksandr Ryabin wrote: >> >>> Hi, >>> In continuation to this metering pulse support. >>> I've looked through amet package and it does not seem to >>> define procedure to detect metering pulses, it only has >>> a procedure to generate metering pulses. >>> I see no reason of defining a new package for detecting incoming >>> metering pulses and I propose to reuse amet and amend it to >>> define procedure for detecting incoming metering pulses. >>> Here is the summary of a proposed metering pulse detection >>> procedure using amet package: >>> The detection of metering pulse on a termination could be enabled >>> by MGC when no amet signals are played on a termination by >>> requesting detection amet/pr event with a required repetition period. >>> MG would Notify MGC with amet/pr event when number of metering >>> pulses is detected according to repetition period parameter set. >>> On Subtract, or explicit AuditValue MG would send amet/cpc >>> and amet/pcslr statistics similar to as described in the package >>> provided their description extended to detection as well. >>> Comments? >>> Thanks >>> Aleks >>> BTW IANA MEGACO page is still not updated. >>> At 10:50 AM 9/16/2003, Aleksandr Ryabin wrote: >>> >>>> It is updated with H.248.22 and 25, but not with 23, 24, 26, 27 >>>> while all of them are dated in ITU the same. Strange. >>>> Aleks >>>> >>>> At 10:46 AM 9/16/2003, Kevin Boyle wrote: >>>> >>>>> If it is NOT updated, that is. (Apparently, it's going to be one of >>>>> those days!) >>>>> >>>>> Kevin >>>>> >>>>> -----Original Message----- >>>>> From: Boyle, Kevin [NCRTP:3Z40:EXCH] >>>>> Sent: Tuesday, September 16, 2003 10:39 AM >>>>> To: Aleksandr Ryabin; megaco@ietf.org >>>>> Subject: RE: [Megaco] CAS Metering Pulse support >>>>> >>>>> Ummm... yeah. That's what I get for not looking it up before >>>>> sending the message. :) While amet is defined in the "Extended >>>>> Analog Lines Packages" doc, there is nothing in the amet package >>>>> that actually limits it to analog lines. >>>>> >>>>> >>>>> The updates for all the new (as of May) H.248 Sub-series >>>>> Recommendations have already been requested of IANA. If it is >>>>> updated by the end of the month, I'll ping them again. >>>>> >>>>> >>>>> Kevin >>>>> >>>>> -----Original Message----- >>>>> From: Aleksandr Ryabin [mailto:kengr@motorola.com] >>>>> Sent: Tuesday, September 16, 2003 10:32 AM >>>>> To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org >>>>> Subject: RE: [Megaco] CAS Metering Pulse support >>>>> >>>>> Hi, >>>>> >>>>> I guess you meant H.248.26. >>>>> Yes it seem to address the needs assuming it is extended to digital >>>>> lines as well. >>>>> >>>>> BTW IANA registry should be updated with H.248.26 and H.248.27 >>>>> http://www.iana.org/assignments/megaco-h248 >>>>> >>>>> >>>>> Thanks, >>>>> Aleks >>>>> >>>>> At 10:00 AM 9/16/2003, Kevin Boyle wrote: >>>>> >>>>> >>>>> H.248.27 has a metering package (automatic metering package or >>>>> amet). This package may address your needs. >>>>> >>>>> Kevin >>>>> >>>>> -----Original Message----- >>>>> From: Aleksandr Ryabin [mailto:kengr@motorola.com >>>>> ] >>>>> Sent: Tuesday, September 16, 2003 9:34 AM >>>>> To: megaco@ietf.org >>>>> Subject: [Megaco] CAS Metering Pulse support >>>>> >>>>> Hi all, >>>>> >>>>> Below are excerpts from a previous exchange related to defining of >>>>> CAS Metering Pulse procedures in MEGACO. >>>>> >>>>> Now that CAS packages related work has been moved to ITU has anyone >>>>> done and/or planned anything in the direction to define CAS >>>>> Metering Pulse procedures/package for MEGACO? >>>>> >>>>> Thanks >>>>> Aleks >>>>> >>>>> >From: klaha@hss.hns.com >>>>> >To: Aleksandr Ryabin >>>>> >cc: vnair@hss.hns.com, megaco@ietf.org, klaha@hss.hns.com >>>>> >Date: Tue, 4 Mar 2003 12:47:37 +0530 >>>>> >Subject: Re: [Megaco] Re: draft-ietf-megaco-r2package-03.txt : >>>>> Difference >>>>> > from previous revision >>>>> ... >>>>> >Aleksandr Ryabin on 03/03/2003 10:43:20 PM >>>>> ... >>>>> >3. I can't seem to find a way to implement "Metering Pulse" procedure >>>>> >defined for some R2 variants using ether bcas or R2 packages? For >>>>> >example, one of the definitions of such a pulse is a "seizure ack" >>>>> >pulse from a terminating end on a circuit in connected/answer state. >>>>> > >>>>> >[Kushanava] Metering is not specific to R2. It may be present in any >>>>> >CAS signaling. Moreover not all flavours of R2 permit metering to be >>>>> >mandatory. There should be therefore a general philosophy of >>>>> attacking >>>>> >this problem common to all CAS signaling. The solution should be >>>>> >sensitive to >>>>> >a) Realizing that MGC is the master for collecting and generating >>>>> charging >>>>> >information >>>>> >b) Interworking of the CAS "metering pulse" signals with other >>>>> signaling >>>>> >(both PDN and PSTN) >>>>> >c) Optimizing the network traffic if metering information is >>>>> transported to >>>>> >>>>> >and fro between MGC and MG >>>>> >d) Latency, if metering information is transported to and fro >>>>> between MGC >>>>> >and MG >>>>> >We are working towards a separate package that addresses this issue. >>>>> >Any suggestions? >>>>> ... >>>>> >>>>> _______________________________________________ >>>>> Megaco mailing list >>>>> Megaco@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/megaco >>>>> >>>>> _______________________________________________ >>>>> Megaco mailing list >>>>> Megaco@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/megaco > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Oct 3 09:36:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06544 for ; Fri, 3 Oct 2003 09:36:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Q6E-0005zm-He; Fri, 03 Oct 2003 09:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Q5P-0005tj-2L for megaco@optimus.ietf.org; Fri, 03 Oct 2003 09:35:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06487 for ; Fri, 3 Oct 2003 09:35:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Q5N-0000ru-00 for megaco@ietf.org; Fri, 03 Oct 2003 09:35:09 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1A5Q5M-0000rW-00 for megaco@ietf.org; Fri, 03 Oct 2003 09:35:08 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h93DYb110814 for ; Fri, 3 Oct 2003 09:34:37 -0400 (EDT) Received: from zrtpd0jh.us.nortel.com ([47.140.202.34]) by zrtpd0jn.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T9HC3JA0; Fri, 3 Oct 2003 09:34:37 -0400 Received: by zrtpd0jh.us.nortel.com with Internet Mail Service (5.5.2653.19) id <41VAX9ZZ>; Fri, 3 Oct 2003 09:34:37 -0400 Message-ID: X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Kevin Boyle" To: Christian Groves , Aleksandr Ryabin Cc: megaco@ietf.org Subject: RE: [Megaco] CAS Metering Pulse support Date: Fri, 3 Oct 2003 09:34:33 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , The amet package was never designed to do pulse detection. The pr event is meant to allow the MGC to stay updated with the actual number of pulses applied -- it has nothing to do with pulses detected. This allows the MGC to have an accurate view of the number of pulses applied, rather than guessing -- and possibly being wrong due to network latency, message loss, retransmission, etc., etc., etc. I think shoehorning detection in here isn't really appropriate. Further, are we sure that ALL pulse generation applications will be required to detect pulses? In the analog line case, the MG has no reason to detect pulses -- pulses are being sent to the CPE for the end-user's benefit. I think that it would be far wiser to define an extension package to handle detection, and not subject applications that only want to do generation to doing detection as well. Kevin -----Original Message----- From: Christian Groves [mailto:Christian.Groves@ericsson.com.au] Sent: Thursday, October 02, 2003 11:38 PM To: Aleksandr Ryabin Cc: megaco@ietf.org; Boyle, Kevin [NCRTP:3Z40:EXCH] Subject: Re: [Megaco] CAS Metering Pulse support Hello Aleksandr, I'm happy enough to have the your proposed amendment if the editor agrees. Regards, Christian Aleksandr Ryabin wrote: > Hi Christian, > > No description of the event does say how to use it for detection > incoming metering pulse. More over it explicitly limits to generation: > "This event is used in conjunction with the "enable metering" and > "metering pulse burst" signals defined in this package..." > > My point being that descriptions of amet events and statistics are > siting that event pr is generated and statistics are changed only > based on previously applied em, or mbp signal. > > The wording needs to be amended to cover the cases when event is > generated and statistics are changed as a result *detection* of > incoming metering pulse. > > That is, for example, the text you have referenced should be changed > to something like this (I've placed the changes in [] for visibility): > > "If following the application [or detection] of any metering pulse > (regardless > of [whether it was detected, or] whether it was generated as a result > of the signal em or as a result of the signal mbp), the EventsDescriptor > contains the event pr, and if the value of pcslr is equal to the value > of the > EventsDescriptor parameter rp, then the pr event shall be notified, and > the value of the statistic pcslr shall be reset to zero. The detection of > the event pr shall not cause the termination of the signal em or the > signal mbp, [if currently active,] even if the KeepActive flag is not > set for the pr event." > > Regards, > Aleks > > At 07:46 PM 10/2/2003, Christian Groves wrote: > >> Hello Aleksandr, >> >> I agree that no new package is needed for the detection of metering >> pulse functionality. From the description of the event it seems that >> it clear how it to be used. >> >> The package also contains the procedural text: >> "If following the application of any metering pulse (regardless of >> whether it was generated as a result of the signal em or as a result >> of the signal mbp), the EventsDescriptor contains the event pr, and if >> the value of pcslr is equal to the value of the EventsDescriptor >> parameter rp, then the pr event shall be notified, and the value of >> the statistic pcslr shall be reset to zero. The detection of the >> event pr shall not cause the termination of the signal em or the >> signal mbp, even if the KeepActive flag is not set for the pr event." >> >> Is this text sufficient? >> >> Regards, Christian >> >> Aleksandr Ryabin wrote: >> >>> Hi, >>> In continuation to this metering pulse support. >>> I've looked through amet package and it does not seem to define >>> procedure to detect metering pulses, it only has a procedure to >>> generate metering pulses. I see no reason of defining a new package >>> for detecting incoming metering pulses and I propose to reuse amet >>> and amend it to define procedure for detecting incoming metering >>> pulses. Here is the summary of a proposed metering pulse detection >>> procedure using amet package: >>> The detection of metering pulse on a termination could be enabled >>> by MGC when no amet signals are played on a termination by >>> requesting detection amet/pr event with a required repetition period. >>> MG would Notify MGC with amet/pr event when number of metering >>> pulses is detected according to repetition period parameter set. >>> On Subtract, or explicit AuditValue MG would send amet/cpc >>> and amet/pcslr statistics similar to as described in the package >>> provided their description extended to detection as well. >>> Comments? >>> Thanks >>> Aleks >>> BTW IANA MEGACO page is still not updated. >>> At 10:50 AM 9/16/2003, Aleksandr Ryabin wrote: >>> >>>> It is updated with H.248.22 and 25, but not with 23, 24, 26, 27 >>>> while all of them are dated in ITU the same. Strange. >>>> Aleks >>>> >>>> At 10:46 AM 9/16/2003, Kevin Boyle wrote: >>>> >>>>> If it is NOT updated, that is. (Apparently, it's going to be one >>>>> of >>>>> those days!) >>>>> >>>>> Kevin >>>>> >>>>> -----Original Message----- >>>>> From: Boyle, Kevin [NCRTP:3Z40:EXCH] >>>>> Sent: Tuesday, September 16, 2003 10:39 AM >>>>> To: Aleksandr Ryabin; megaco@ietf.org >>>>> Subject: RE: [Megaco] CAS Metering Pulse support >>>>> >>>>> Ummm... yeah. That's what I get for not looking it up before >>>>> sending the message. :) While amet is defined in the "Extended >>>>> Analog Lines Packages" doc, there is nothing in the amet package >>>>> that actually limits it to analog lines. >>>>> >>>>> >>>>> The updates for all the new (as of May) H.248 Sub-series >>>>> Recommendations have already been requested of IANA. If it is >>>>> updated by the end of the month, I'll ping them again. >>>>> >>>>> >>>>> Kevin >>>>> >>>>> -----Original Message----- >>>>> From: Aleksandr Ryabin [mailto:kengr@motorola.com] >>>>> Sent: Tuesday, September 16, 2003 10:32 AM >>>>> To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org >>>>> Subject: RE: [Megaco] CAS Metering Pulse support >>>>> >>>>> Hi, >>>>> >>>>> I guess you meant H.248.26. >>>>> Yes it seem to address the needs assuming it is extended to >>>>> digital >>>>> lines as well. >>>>> >>>>> BTW IANA registry should be updated with H.248.26 and H.248.27 >>>>> http://www.iana.org/assignments/megaco-h248 >>>>> >>>>> >>>>> Thanks, >>>>> Aleks >>>>> >>>>> At 10:00 AM 9/16/2003, Kevin Boyle wrote: >>>>> >>>>> >>>>> H.248.27 has a metering package (automatic metering package or >>>>> amet). This package may address your needs. >>>>> >>>>> Kevin >>>>> >>>>> -----Original Message----- >>>>> From: Aleksandr Ryabin [mailto:kengr@motorola.com >>>>> ] >>>>> Sent: Tuesday, September 16, 2003 9:34 AM >>>>> To: megaco@ietf.org >>>>> Subject: [Megaco] CAS Metering Pulse support >>>>> >>>>> Hi all, >>>>> >>>>> Below are excerpts from a previous exchange related to defining of >>>>> CAS Metering Pulse procedures in MEGACO. >>>>> >>>>> Now that CAS packages related work has been moved to ITU has >>>>> anyone >>>>> done and/or planned anything in the direction to define CAS >>>>> Metering Pulse procedures/package for MEGACO? >>>>> >>>>> Thanks >>>>> Aleks >>>>> >>>>> >From: klaha@hss.hns.com >>>>> >To: Aleksandr Ryabin >>>>> >cc: vnair@hss.hns.com, megaco@ietf.org, klaha@hss.hns.com >>>>> >Date: Tue, 4 Mar 2003 12:47:37 +0530 >>>>> >Subject: Re: [Megaco] Re: draft-ietf-megaco-r2package-03.txt : >>>>> Difference >>>>> > from previous revision >>>>> ... >>>>> >Aleksandr Ryabin on 03/03/2003 10:43:20 PM >>>>> ... >>>>> >3. I can't seem to find a way to implement "Metering Pulse" >>>>> >procedure defined for some R2 variants using ether bcas or R2 >>>>> >packages? For example, one of the definitions of such a pulse is >>>>> >a "seizure ack" pulse from a terminating end on a circuit in >>>>> >connected/answer state. >>>>> > >>>>> >[Kushanava] Metering is not specific to R2. It may be present in >>>>> >any CAS signaling. Moreover not all flavours of R2 permit >>>>> >metering to be mandatory. There should be therefore a general >>>>> >philosophy of >>>>> attacking >>>>> >this problem common to all CAS signaling. The solution should be >>>>> >sensitive to >>>>> >a) Realizing that MGC is the master for collecting and generating >>>>> charging >>>>> >information >>>>> >b) Interworking of the CAS "metering pulse" signals with other >>>>> signaling >>>>> >(both PDN and PSTN) >>>>> >c) Optimizing the network traffic if metering information is >>>>> transported to >>>>> >>>>> >and fro between MGC and MG >>>>> >d) Latency, if metering information is transported to and fro >>>>> between MGC >>>>> >and MG >>>>> >We are working towards a separate package that addresses this >>>>> >issue. Any suggestions? >>>>> ... >>>>> >>>>> _______________________________________________ >>>>> Megaco mailing list >>>>> Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco >>>>> >>>>> _______________________________________________ >>>>> Megaco mailing list >>>>> Megaco@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/megaco > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri Oct 3 09:36:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06559 for ; Fri, 3 Oct 2003 09:36:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Q6K-00061D-2v for megaco-archive@odin.ietf.org; Fri, 03 Oct 2003 09:36:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93Da8qe023131 for megaco-archive@odin.ietf.org; Fri, 3 Oct 2003 09:36:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Q6J-000610-Ve for megaco-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 09:36:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06526 for ; Fri, 3 Oct 2003 09:35:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Q6I-0000sT-00 for megaco-web-archive@ietf.org; Fri, 03 Oct 2003 09:36:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5Q6H-0000sP-00 for megaco-web-archive@ietf.org; Fri, 03 Oct 2003 09:36:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Q6E-0005zm-He; Fri, 03 Oct 2003 09:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Q5P-0005tj-2L for megaco@optimus.ietf.org; Fri, 03 Oct 2003 09:35:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06487 for ; Fri, 3 Oct 2003 09:35:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Q5N-0000ru-00 for megaco@ietf.org; Fri, 03 Oct 2003 09:35:09 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1A5Q5M-0000rW-00 for megaco@ietf.org; Fri, 03 Oct 2003 09:35:08 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h93DYb110814 for ; Fri, 3 Oct 2003 09:34:37 -0400 (EDT) Received: from zrtpd0jh.us.nortel.com ([47.140.202.34]) by zrtpd0jn.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T9HC3JA0; Fri, 3 Oct 2003 09:34:37 -0400 Received: by zrtpd0jh.us.nortel.com with Internet Mail Service (5.5.2653.19) id <41VAX9ZZ>; Fri, 3 Oct 2003 09:34:37 -0400 Message-ID: X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Kevin Boyle" To: Christian Groves , Aleksandr Ryabin Cc: megaco@ietf.org Subject: RE: [Megaco] CAS Metering Pulse support Date: Fri, 3 Oct 2003 09:34:33 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , The amet package was never designed to do pulse detection. The pr event is meant to allow the MGC to stay updated with the actual number of pulses applied -- it has nothing to do with pulses detected. This allows the MGC to have an accurate view of the number of pulses applied, rather than guessing -- and possibly being wrong due to network latency, message loss, retransmission, etc., etc., etc. I think shoehorning detection in here isn't really appropriate. Further, are we sure that ALL pulse generation applications will be required to detect pulses? In the analog line case, the MG has no reason to detect pulses -- pulses are being sent to the CPE for the end-user's benefit. I think that it would be far wiser to define an extension package to handle detection, and not subject applications that only want to do generation to doing detection as well. Kevin -----Original Message----- From: Christian Groves [mailto:Christian.Groves@ericsson.com.au] Sent: Thursday, October 02, 2003 11:38 PM To: Aleksandr Ryabin Cc: megaco@ietf.org; Boyle, Kevin [NCRTP:3Z40:EXCH] Subject: Re: [Megaco] CAS Metering Pulse support Hello Aleksandr, I'm happy enough to have the your proposed amendment if the editor agrees. Regards, Christian Aleksandr Ryabin wrote: > Hi Christian, > > No description of the event does say how to use it for detection > incoming metering pulse. More over it explicitly limits to generation: > "This event is used in conjunction with the "enable metering" and > "metering pulse burst" signals defined in this package..." > > My point being that descriptions of amet events and statistics are > siting that event pr is generated and statistics are changed only > based on previously applied em, or mbp signal. > > The wording needs to be amended to cover the cases when event is > generated and statistics are changed as a result *detection* of > incoming metering pulse. > > That is, for example, the text you have referenced should be changed > to something like this (I've placed the changes in [] for visibility): > > "If following the application [or detection] of any metering pulse > (regardless > of [whether it was detected, or] whether it was generated as a result > of the signal em or as a result of the signal mbp), the EventsDescriptor > contains the event pr, and if the value of pcslr is equal to the value > of the > EventsDescriptor parameter rp, then the pr event shall be notified, and > the value of the statistic pcslr shall be reset to zero. The detection of > the event pr shall not cause the termination of the signal em or the > signal mbp, [if currently active,] even if the KeepActive flag is not > set for the pr event." > > Regards, > Aleks > > At 07:46 PM 10/2/2003, Christian Groves wrote: > >> Hello Aleksandr, >> >> I agree that no new package is needed for the detection of metering >> pulse functionality. From the description of the event it seems that >> it clear how it to be used. >> >> The package also contains the procedural text: >> "If following the application of any metering pulse (regardless of >> whether it was generated as a result of the signal em or as a result >> of the signal mbp), the EventsDescriptor contains the event pr, and if >> the value of pcslr is equal to the value of the EventsDescriptor >> parameter rp, then the pr event shall be notified, and the value of >> the statistic pcslr shall be reset to zero. The detection of the >> event pr shall not cause the termination of the signal em or the >> signal mbp, even if the KeepActive flag is not set for the pr event." >> >> Is this text sufficient? >> >> Regards, Christian >> >> Aleksandr Ryabin wrote: >> >>> Hi, >>> In continuation to this metering pulse support. >>> I've looked through amet package and it does not seem to define >>> procedure to detect metering pulses, it only has a procedure to >>> generate metering pulses. I see no reason of defining a new package >>> for detecting incoming metering pulses and I propose to reuse amet >>> and amend it to define procedure for detecting incoming metering >>> pulses. Here is the summary of a proposed metering pulse detection >>> procedure using amet package: >>> The detection of metering pulse on a termination could be enabled >>> by MGC when no amet signals are played on a termination by >>> requesting detection amet/pr event with a required repetition period. >>> MG would Notify MGC with amet/pr event when number of metering >>> pulses is detected according to repetition period parameter set. >>> On Subtract, or explicit AuditValue MG would send amet/cpc >>> and amet/pcslr statistics similar to as described in the package >>> provided their description extended to detection as well. >>> Comments? >>> Thanks >>> Aleks >>> BTW IANA MEGACO page is still not updated. >>> At 10:50 AM 9/16/2003, Aleksandr Ryabin wrote: >>> >>>> It is updated with H.248.22 and 25, but not with 23, 24, 26, 27 >>>> while all of them are dated in ITU the same. Strange. >>>> Aleks >>>> >>>> At 10:46 AM 9/16/2003, Kevin Boyle wrote: >>>> >>>>> If it is NOT updated, that is. (Apparently, it's going to be one >>>>> of >>>>> those days!) >>>>> >>>>> Kevin >>>>> >>>>> -----Original Message----- >>>>> From: Boyle, Kevin [NCRTP:3Z40:EXCH] >>>>> Sent: Tuesday, September 16, 2003 10:39 AM >>>>> To: Aleksandr Ryabin; megaco@ietf.org >>>>> Subject: RE: [Megaco] CAS Metering Pulse support >>>>> >>>>> Ummm... yeah. That's what I get for not looking it up before >>>>> sending the message. :) While amet is defined in the "Extended >>>>> Analog Lines Packages" doc, there is nothing in the amet package >>>>> that actually limits it to analog lines. >>>>> >>>>> >>>>> The updates for all the new (as of May) H.248 Sub-series >>>>> Recommendations have already been requested of IANA. If it is >>>>> updated by the end of the month, I'll ping them again. >>>>> >>>>> >>>>> Kevin >>>>> >>>>> -----Original Message----- >>>>> From: Aleksandr Ryabin [mailto:kengr@motorola.com] >>>>> Sent: Tuesday, September 16, 2003 10:32 AM >>>>> To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org >>>>> Subject: RE: [Megaco] CAS Metering Pulse support >>>>> >>>>> Hi, >>>>> >>>>> I guess you meant H.248.26. >>>>> Yes it seem to address the needs assuming it is extended to >>>>> digital >>>>> lines as well. >>>>> >>>>> BTW IANA registry should be updated with H.248.26 and H.248.27 >>>>> http://www.iana.org/assignments/megaco-h248 >>>>> >>>>> >>>>> Thanks, >>>>> Aleks >>>>> >>>>> At 10:00 AM 9/16/2003, Kevin Boyle wrote: >>>>> >>>>> >>>>> H.248.27 has a metering package (automatic metering package or >>>>> amet). This package may address your needs. >>>>> >>>>> Kevin >>>>> >>>>> -----Original Message----- >>>>> From: Aleksandr Ryabin [mailto:kengr@motorola.com >>>>> ] >>>>> Sent: Tuesday, September 16, 2003 9:34 AM >>>>> To: megaco@ietf.org >>>>> Subject: [Megaco] CAS Metering Pulse support >>>>> >>>>> Hi all, >>>>> >>>>> Below are excerpts from a previous exchange related to defining of >>>>> CAS Metering Pulse procedures in MEGACO. >>>>> >>>>> Now that CAS packages related work has been moved to ITU has >>>>> anyone >>>>> done and/or planned anything in the direction to define CAS >>>>> Metering Pulse procedures/package for MEGACO? >>>>> >>>>> Thanks >>>>> Aleks >>>>> >>>>> >From: klaha@hss.hns.com >>>>> >To: Aleksandr Ryabin >>>>> >cc: vnair@hss.hns.com, megaco@ietf.org, klaha@hss.hns.com >>>>> >Date: Tue, 4 Mar 2003 12:47:37 +0530 >>>>> >Subject: Re: [Megaco] Re: draft-ietf-megaco-r2package-03.txt : >>>>> Difference >>>>> > from previous revision >>>>> ... >>>>> >Aleksandr Ryabin on 03/03/2003 10:43:20 PM >>>>> ... >>>>> >3. I can't seem to find a way to implement "Metering Pulse" >>>>> >procedure defined for some R2 variants using ether bcas or R2 >>>>> >packages? For example, one of the definitions of such a pulse is >>>>> >a "seizure ack" pulse from a terminating end on a circuit in >>>>> >connected/answer state. >>>>> > >>>>> >[Kushanava] Metering is not specific to R2. It may be present in >>>>> >any CAS signaling. Moreover not all flavours of R2 permit >>>>> >metering to be mandatory. There should be therefore a general >>>>> >philosophy of >>>>> attacking >>>>> >this problem common to all CAS signaling. The solution should be >>>>> >sensitive to >>>>> >a) Realizing that MGC is the master for collecting and generating >>>>> charging >>>>> >information >>>>> >b) Interworking of the CAS "metering pulse" signals with other >>>>> signaling >>>>> >(both PDN and PSTN) >>>>> >c) Optimizing the network traffic if metering information is >>>>> transported to >>>>> >>>>> >and fro between MGC and MG >>>>> >d) Latency, if metering information is transported to and fro >>>>> between MGC >>>>> >and MG >>>>> >We are working towards a separate package that addresses this >>>>> >issue. Any suggestions? >>>>> ... >>>>> >>>>> _______________________________________________ >>>>> Megaco mailing list >>>>> Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco >>>>> >>>>> _______________________________________________ >>>>> Megaco mailing list >>>>> Megaco@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/megaco > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Oct 3 11:26:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12006 for ; Fri, 3 Oct 2003 11:26:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Rog-0002iw-CV; Fri, 03 Oct 2003 11:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Ro7-0002iD-Rq for megaco@optimus.ietf.org; Fri, 03 Oct 2003 11:25:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11965 for ; Fri, 3 Oct 2003 11:25:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Ro2-00026Y-00 for megaco@ietf.org; Fri, 03 Oct 2003 11:25:22 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx with esmtp (Exim 4.12) id 1A5Ro1-00026V-00 for megaco@ietf.org; Fri, 03 Oct 2003 11:25:21 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h93FPI5e001110; Fri, 3 Oct 2003 08:25:18 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id h93FPHSu003940; Fri, 3 Oct 2003 10:25:17 -0500 Message-Id: <5.2.1.1.0.20031003103125.023debb8@IL06EXM13.corp.mot.com> X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 03 Oct 2003 11:21:26 -0400 To: "Kevin Boyle", From: Aleksandr Ryabin Subject: RE: [Megaco] CAS Metering Pulse support Cc: Christian Groves In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi, Sounds reasonable. Except that it probably should not be an extension since an application might be needing detection only and no generation. That is it should be then a standalone metd ("Metering Detection Package"). Since amet and metd are complimentary I think it would be reasonable to keep them together, that is to a amend H.248.26 to include it. Would you as the editor of H.248.26 recommend amending it to include new metd or rather have new H.248.metd, or something else? I can provide a baseline text, if necessary. Regards, Aleks At 09:34 AM 10/3/2003, Kevin Boyle wrote: >The amet package was never designed to do pulse detection. The pr event is >meant to allow the MGC to stay updated with the actual number of pulses >applied -- it has nothing to do with pulses detected. This allows the MGC >to have an accurate view of the number of pulses applied, rather than >guessing -- and possibly being wrong due to network latency, message loss, >retransmission, etc., etc., etc. I think shoehorning detection in here >isn't really appropriate. > >Further, are we sure that ALL pulse generation applications will be required >to detect pulses? In the analog line case, the MG has no reason to detect >pulses -- pulses are being sent to the CPE for the end-user's benefit. I >think that it would be far wiser to define an extension package to handle >detection, and not subject applications that only want to do generation to >doing detection as well. > >Kevin > >-----Original Message----- >From: Christian Groves [mailto:Christian.Groves@ericsson.com.au] >Sent: Thursday, October 02, 2003 11:38 PM >To: Aleksandr Ryabin >Cc: megaco@ietf.org; Boyle, Kevin [NCRTP:3Z40:EXCH] >Subject: Re: [Megaco] CAS Metering Pulse support > > >Hello Aleksandr, > >I'm happy enough to have the your proposed amendment if the editor agrees. > >Regards, Christian > >Aleksandr Ryabin wrote: > > Hi Christian, > > > > No description of the event does say how to use it for detection > > incoming metering pulse. More over it explicitly limits to generation: > > "This event is used in conjunction with the "enable metering" and > > "metering pulse burst" signals defined in this package..." > > > > My point being that descriptions of amet events and statistics are > > siting that event pr is generated and statistics are changed only > > based on previously applied em, or mbp signal. > > > > The wording needs to be amended to cover the cases when event is > > generated and statistics are changed as a result *detection* of > > incoming metering pulse. > > > > That is, for example, the text you have referenced should be changed > > to something like this (I've placed the changes in [] for visibility): > > > > "If following the application [or detection] of any metering pulse > > (regardless > > of [whether it was detected, or] whether it was generated as a result > > of the signal em or as a result of the signal mbp), the EventsDescriptor > > contains the event pr, and if the value of pcslr is equal to the value > > of the > > EventsDescriptor parameter rp, then the pr event shall be notified, and > > the value of the statistic pcslr shall be reset to zero. The detection of > > the event pr shall not cause the termination of the signal em or the > > signal mbp, [if currently active,] even if the KeepActive flag is not > > set for the pr event." > > > > Regards, > > Aleks > > > > At 07:46 PM 10/2/2003, Christian Groves wrote: > > > >> Hello Aleksandr, > >> > >> I agree that no new package is needed for the detection of metering > >> pulse functionality. From the description of the event it seems that > >> it clear how it to be used. > >> > >> The package also contains the procedural text: > >> "If following the application of any metering pulse (regardless of > >> whether it was generated as a result of the signal em or as a result > >> of the signal mbp), the EventsDescriptor contains the event pr, and if > >> the value of pcslr is equal to the value of the EventsDescriptor > >> parameter rp, then the pr event shall be notified, and the value of > >> the statistic pcslr shall be reset to zero. The detection of the > >> event pr shall not cause the termination of the signal em or the > >> signal mbp, even if the KeepActive flag is not set for the pr event." > >> > >> Is this text sufficient? > >> > >> Regards, Christian > >> > >> Aleksandr Ryabin wrote: > >> > >>> Hi, > >>> In continuation to this metering pulse support. > >>> I've looked through amet package and it does not seem to define > >>> procedure to detect metering pulses, it only has a procedure to > >>> generate metering pulses. I see no reason of defining a new package > >>> for detecting incoming metering pulses and I propose to reuse amet > >>> and amend it to define procedure for detecting incoming metering > >>> pulses. Here is the summary of a proposed metering pulse detection > >>> procedure using amet package: > >>> The detection of metering pulse on a termination could be enabled > >>> by MGC when no amet signals are played on a termination by > >>> requesting detection amet/pr event with a required repetition period. > >>> MG would Notify MGC with amet/pr event when number of metering > >>> pulses is detected according to repetition period parameter set. > >>> On Subtract, or explicit AuditValue MG would send amet/cpc > >>> and amet/pcslr statistics similar to as described in the package > >>> provided their description extended to detection as well. > >>> Comments? > >>> Thanks > >>> Aleks > >>> BTW IANA MEGACO page is still not updated. > >>> At 10:50 AM 9/16/2003, Aleksandr Ryabin wrote: > >>> > >>>> It is updated with H.248.22 and 25, but not with 23, 24, 26, 27 > >>>> while all of them are dated in ITU the same. Strange. > >>>> Aleks > >>>> > >>>> At 10:46 AM 9/16/2003, Kevin Boyle wrote: > >>>> > >>>>> If it is NOT updated, that is. (Apparently, it's going to be one > >>>>> of > >>>>> those days!) > >>>>> > >>>>> Kevin > >>>>> > >>>>> -----Original Message----- > >>>>> From: Boyle, Kevin [NCRTP:3Z40:EXCH] > >>>>> Sent: Tuesday, September 16, 2003 10:39 AM > >>>>> To: Aleksandr Ryabin; megaco@ietf.org > >>>>> Subject: RE: [Megaco] CAS Metering Pulse support > >>>>> > >>>>> Ummm... yeah. That's what I get for not looking it up before > >>>>> sending the message. :) While amet is defined in the "Extended > >>>>> Analog Lines Packages" doc, there is nothing in the amet package > >>>>> that actually limits it to analog lines. > >>>>> > >>>>> > >>>>> The updates for all the new (as of May) H.248 Sub-series > >>>>> Recommendations have already been requested of IANA. If it is > >>>>> updated by the end of the month, I'll ping them again. > >>>>> > >>>>> > >>>>> Kevin > >>>>> > >>>>> -----Original Message----- > >>>>> From: Aleksandr Ryabin [mailto:kengr@motorola.com] > >>>>> Sent: Tuesday, September 16, 2003 10:32 AM > >>>>> To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org > >>>>> Subject: RE: [Megaco] CAS Metering Pulse support > >>>>> > >>>>> Hi, > >>>>> > >>>>> I guess you meant H.248.26. > >>>>> Yes it seem to address the needs assuming it is extended to > >>>>> digital > >>>>> lines as well. > >>>>> > >>>>> BTW IANA registry should be updated with H.248.26 and H.248.27 > >>>>> http://www.iana.org/assignments/megaco-h248 > >>>>> > >>>>> > >>>>> Thanks, > >>>>> Aleks > >>>>> > >>>>> At 10:00 AM 9/16/2003, Kevin Boyle wrote: > >>>>> > >>>>> > >>>>> H.248.27 has a metering package (automatic metering package or > >>>>> amet). This package may address your needs. > >>>>> > >>>>> Kevin > >>>>> > >>>>> -----Original Message----- > >>>>> From: Aleksandr Ryabin [mailto:kengr@motorola.com > >>>>> ] > >>>>> Sent: Tuesday, September 16, 2003 9:34 AM > >>>>> To: megaco@ietf.org > >>>>> Subject: [Megaco] CAS Metering Pulse support > >>>>> > >>>>> Hi all, > >>>>> > >>>>> Below are excerpts from a previous exchange related to defining of > >>>>> CAS Metering Pulse procedures in MEGACO. > >>>>> > >>>>> Now that CAS packages related work has been moved to ITU has > >>>>> anyone > >>>>> done and/or planned anything in the direction to define CAS > >>>>> Metering Pulse procedures/package for MEGACO? > >>>>> > >>>>> Thanks > >>>>> Aleks > >>>>> > >>>>> >From: klaha@hss.hns.com > >>>>> >To: Aleksandr Ryabin > >>>>> >cc: vnair@hss.hns.com, megaco@ietf.org, klaha@hss.hns.com > >>>>> >Date: Tue, 4 Mar 2003 12:47:37 +0530 > >>>>> >Subject: Re: [Megaco] Re: draft-ietf-megaco-r2package-03.txt : > >>>>> Difference > >>>>> > from previous revision > >>>>> ... > >>>>> >Aleksandr Ryabin on 03/03/2003 10:43:20 PM > >>>>> ... > >>>>> >3. I can't seem to find a way to implement "Metering Pulse" > >>>>> >procedure defined for some R2 variants using ether bcas or R2 > >>>>> >packages? For example, one of the definitions of such a pulse is > >>>>> >a "seizure ack" pulse from a terminating end on a circuit in > >>>>> >connected/answer state. > >>>>> > > >>>>> >[Kushanava] Metering is not specific to R2. It may be present in > >>>>> >any CAS signaling. Moreover not all flavours of R2 permit > >>>>> >metering to be mandatory. There should be therefore a general > >>>>> >philosophy of > >>>>> attacking > >>>>> >this problem common to all CAS signaling. The solution should be > >>>>> >sensitive to > >>>>> >a) Realizing that MGC is the master for collecting and generating > >>>>> charging > >>>>> >information > >>>>> >b) Interworking of the CAS "metering pulse" signals with other > >>>>> signaling > >>>>> >(both PDN and PSTN) > >>>>> >c) Optimizing the network traffic if metering information is > >>>>> transported to > >>>>> > >>>>> >and fro between MGC and MG > >>>>> >d) Latency, if metering information is transported to and fro > >>>>> between MGC > >>>>> >and MG > >>>>> >We are working towards a separate package that addresses this > >>>>> >issue. Any suggestions? > >>>>> ... > >>>>> > >>>>> _______________________________________________ > >>>>> Megaco mailing list > >>>>> Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco > >>>>> > >>>>> _______________________________________________ > >>>>> Megaco mailing list > >>>>> Megaco@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/megaco > > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri Oct 3 11:26:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12021 for ; Fri, 3 Oct 2003 11:26:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Rok-0002kU-4L for megaco-archive@odin.ietf.org; Fri, 03 Oct 2003 11:26:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93FQ6kr010560 for megaco-archive@odin.ietf.org; Fri, 3 Oct 2003 11:26:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Rok-0002kF-0g for megaco-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 11:26:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11989 for ; Fri, 3 Oct 2003 11:25:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Roj-000275-00 for megaco-web-archive@ietf.org; Fri, 03 Oct 2003 11:26:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5Roi-000272-00 for megaco-web-archive@ietf.org; Fri, 03 Oct 2003 11:26:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Rog-0002iw-CV; Fri, 03 Oct 2003 11:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Ro7-0002iD-Rq for megaco@optimus.ietf.org; Fri, 03 Oct 2003 11:25:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11965 for ; Fri, 3 Oct 2003 11:25:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Ro2-00026Y-00 for megaco@ietf.org; Fri, 03 Oct 2003 11:25:22 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx with esmtp (Exim 4.12) id 1A5Ro1-00026V-00 for megaco@ietf.org; Fri, 03 Oct 2003 11:25:21 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h93FPI5e001110; Fri, 3 Oct 2003 08:25:18 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id h93FPHSu003940; Fri, 3 Oct 2003 10:25:17 -0500 Message-Id: <5.2.1.1.0.20031003103125.023debb8@IL06EXM13.corp.mot.com> X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 03 Oct 2003 11:21:26 -0400 To: "Kevin Boyle", From: Aleksandr Ryabin Subject: RE: [Megaco] CAS Metering Pulse support Cc: Christian Groves In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi, Sounds reasonable. Except that it probably should not be an extension since an application might be needing detection only and no generation. That is it should be then a standalone metd ("Metering Detection Package"). Since amet and metd are complimentary I think it would be reasonable to keep them together, that is to a amend H.248.26 to include it. Would you as the editor of H.248.26 recommend amending it to include new metd or rather have new H.248.metd, or something else? I can provide a baseline text, if necessary. Regards, Aleks At 09:34 AM 10/3/2003, Kevin Boyle wrote: >The amet package was never designed to do pulse detection. The pr event is >meant to allow the MGC to stay updated with the actual number of pulses >applied -- it has nothing to do with pulses detected. This allows the MGC >to have an accurate view of the number of pulses applied, rather than >guessing -- and possibly being wrong due to network latency, message loss, >retransmission, etc., etc., etc. I think shoehorning detection in here >isn't really appropriate. > >Further, are we sure that ALL pulse generation applications will be required >to detect pulses? In the analog line case, the MG has no reason to detect >pulses -- pulses are being sent to the CPE for the end-user's benefit. I >think that it would be far wiser to define an extension package to handle >detection, and not subject applications that only want to do generation to >doing detection as well. > >Kevin > >-----Original Message----- >From: Christian Groves [mailto:Christian.Groves@ericsson.com.au] >Sent: Thursday, October 02, 2003 11:38 PM >To: Aleksandr Ryabin >Cc: megaco@ietf.org; Boyle, Kevin [NCRTP:3Z40:EXCH] >Subject: Re: [Megaco] CAS Metering Pulse support > > >Hello Aleksandr, > >I'm happy enough to have the your proposed amendment if the editor agrees. > >Regards, Christian > >Aleksandr Ryabin wrote: > > Hi Christian, > > > > No description of the event does say how to use it for detection > > incoming metering pulse. More over it explicitly limits to generation: > > "This event is used in conjunction with the "enable metering" and > > "metering pulse burst" signals defined in this package..." > > > > My point being that descriptions of amet events and statistics are > > siting that event pr is generated and statistics are changed only > > based on previously applied em, or mbp signal. > > > > The wording needs to be amended to cover the cases when event is > > generated and statistics are changed as a result *detection* of > > incoming metering pulse. > > > > That is, for example, the text you have referenced should be changed > > to something like this (I've placed the changes in [] for visibility): > > > > "If following the application [or detection] of any metering pulse > > (regardless > > of [whether it was detected, or] whether it was generated as a result > > of the signal em or as a result of the signal mbp), the EventsDescriptor > > contains the event pr, and if the value of pcslr is equal to the value > > of the > > EventsDescriptor parameter rp, then the pr event shall be notified, and > > the value of the statistic pcslr shall be reset to zero. The detection of > > the event pr shall not cause the termination of the signal em or the > > signal mbp, [if currently active,] even if the KeepActive flag is not > > set for the pr event." > > > > Regards, > > Aleks > > > > At 07:46 PM 10/2/2003, Christian Groves wrote: > > > >> Hello Aleksandr, > >> > >> I agree that no new package is needed for the detection of metering > >> pulse functionality. From the description of the event it seems that > >> it clear how it to be used. > >> > >> The package also contains the procedural text: > >> "If following the application of any metering pulse (regardless of > >> whether it was generated as a result of the signal em or as a result > >> of the signal mbp), the EventsDescriptor contains the event pr, and if > >> the value of pcslr is equal to the value of the EventsDescriptor > >> parameter rp, then the pr event shall be notified, and the value of > >> the statistic pcslr shall be reset to zero. The detection of the > >> event pr shall not cause the termination of the signal em or the > >> signal mbp, even if the KeepActive flag is not set for the pr event." > >> > >> Is this text sufficient? > >> > >> Regards, Christian > >> > >> Aleksandr Ryabin wrote: > >> > >>> Hi, > >>> In continuation to this metering pulse support. > >>> I've looked through amet package and it does not seem to define > >>> procedure to detect metering pulses, it only has a procedure to > >>> generate metering pulses. I see no reason of defining a new package > >>> for detecting incoming metering pulses and I propose to reuse amet > >>> and amend it to define procedure for detecting incoming metering > >>> pulses. Here is the summary of a proposed metering pulse detection > >>> procedure using amet package: > >>> The detection of metering pulse on a termination could be enabled > >>> by MGC when no amet signals are played on a termination by > >>> requesting detection amet/pr event with a required repetition period. > >>> MG would Notify MGC with amet/pr event when number of metering > >>> pulses is detected according to repetition period parameter set. > >>> On Subtract, or explicit AuditValue MG would send amet/cpc > >>> and amet/pcslr statistics similar to as described in the package > >>> provided their description extended to detection as well. > >>> Comments? > >>> Thanks > >>> Aleks > >>> BTW IANA MEGACO page is still not updated. > >>> At 10:50 AM 9/16/2003, Aleksandr Ryabin wrote: > >>> > >>>> It is updated with H.248.22 and 25, but not with 23, 24, 26, 27 > >>>> while all of them are dated in ITU the same. Strange. > >>>> Aleks > >>>> > >>>> At 10:46 AM 9/16/2003, Kevin Boyle wrote: > >>>> > >>>>> If it is NOT updated, that is. (Apparently, it's going to be one > >>>>> of > >>>>> those days!) > >>>>> > >>>>> Kevin > >>>>> > >>>>> -----Original Message----- > >>>>> From: Boyle, Kevin [NCRTP:3Z40:EXCH] > >>>>> Sent: Tuesday, September 16, 2003 10:39 AM > >>>>> To: Aleksandr Ryabin; megaco@ietf.org > >>>>> Subject: RE: [Megaco] CAS Metering Pulse support > >>>>> > >>>>> Ummm... yeah. That's what I get for not looking it up before > >>>>> sending the message. :) While amet is defined in the "Extended > >>>>> Analog Lines Packages" doc, there is nothing in the amet package > >>>>> that actually limits it to analog lines. > >>>>> > >>>>> > >>>>> The updates for all the new (as of May) H.248 Sub-series > >>>>> Recommendations have already been requested of IANA. If it is > >>>>> updated by the end of the month, I'll ping them again. > >>>>> > >>>>> > >>>>> Kevin > >>>>> > >>>>> -----Original Message----- > >>>>> From: Aleksandr Ryabin [mailto:kengr@motorola.com] > >>>>> Sent: Tuesday, September 16, 2003 10:32 AM > >>>>> To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org > >>>>> Subject: RE: [Megaco] CAS Metering Pulse support > >>>>> > >>>>> Hi, > >>>>> > >>>>> I guess you meant H.248.26. > >>>>> Yes it seem to address the needs assuming it is extended to > >>>>> digital > >>>>> lines as well. > >>>>> > >>>>> BTW IANA registry should be updated with H.248.26 and H.248.27 > >>>>> http://www.iana.org/assignments/megaco-h248 > >>>>> > >>>>> > >>>>> Thanks, > >>>>> Aleks > >>>>> > >>>>> At 10:00 AM 9/16/2003, Kevin Boyle wrote: > >>>>> > >>>>> > >>>>> H.248.27 has a metering package (automatic metering package or > >>>>> amet). This package may address your needs. > >>>>> > >>>>> Kevin > >>>>> > >>>>> -----Original Message----- > >>>>> From: Aleksandr Ryabin [mailto:kengr@motorola.com > >>>>> ] > >>>>> Sent: Tuesday, September 16, 2003 9:34 AM > >>>>> To: megaco@ietf.org > >>>>> Subject: [Megaco] CAS Metering Pulse support > >>>>> > >>>>> Hi all, > >>>>> > >>>>> Below are excerpts from a previous exchange related to defining of > >>>>> CAS Metering Pulse procedures in MEGACO. > >>>>> > >>>>> Now that CAS packages related work has been moved to ITU has > >>>>> anyone > >>>>> done and/or planned anything in the direction to define CAS > >>>>> Metering Pulse procedures/package for MEGACO? > >>>>> > >>>>> Thanks > >>>>> Aleks > >>>>> > >>>>> >From: klaha@hss.hns.com > >>>>> >To: Aleksandr Ryabin > >>>>> >cc: vnair@hss.hns.com, megaco@ietf.org, klaha@hss.hns.com > >>>>> >Date: Tue, 4 Mar 2003 12:47:37 +0530 > >>>>> >Subject: Re: [Megaco] Re: draft-ietf-megaco-r2package-03.txt : > >>>>> Difference > >>>>> > from previous revision > >>>>> ... > >>>>> >Aleksandr Ryabin on 03/03/2003 10:43:20 PM > >>>>> ... > >>>>> >3. I can't seem to find a way to implement "Metering Pulse" > >>>>> >procedure defined for some R2 variants using ether bcas or R2 > >>>>> >packages? For example, one of the definitions of such a pulse is > >>>>> >a "seizure ack" pulse from a terminating end on a circuit in > >>>>> >connected/answer state. > >>>>> > > >>>>> >[Kushanava] Metering is not specific to R2. It may be present in > >>>>> >any CAS signaling. Moreover not all flavours of R2 permit > >>>>> >metering to be mandatory. There should be therefore a general > >>>>> >philosophy of > >>>>> attacking > >>>>> >this problem common to all CAS signaling. The solution should be > >>>>> >sensitive to > >>>>> >a) Realizing that MGC is the master for collecting and generating > >>>>> charging > >>>>> >information > >>>>> >b) Interworking of the CAS "metering pulse" signals with other > >>>>> signaling > >>>>> >(both PDN and PSTN) > >>>>> >c) Optimizing the network traffic if metering information is > >>>>> transported to > >>>>> > >>>>> >and fro between MGC and MG > >>>>> >d) Latency, if metering information is transported to and fro > >>>>> between MGC > >>>>> >and MG > >>>>> >We are working towards a separate package that addresses this > >>>>> >issue. Any suggestions? > >>>>> ... > >>>>> > >>>>> _______________________________________________ > >>>>> Megaco mailing list > >>>>> Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco > >>>>> > >>>>> _______________________________________________ > >>>>> Megaco mailing list > >>>>> Megaco@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/megaco > > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Oct 3 11:29:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12177 for ; Fri, 3 Oct 2003 11:29:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5RrZ-0002t4-RI; Fri, 03 Oct 2003 11:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5RrR-0002sn-Fz for megaco@optimus.ietf.org; Fri, 03 Oct 2003 11:28:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12153 for ; Fri, 3 Oct 2003 11:28:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5RrQ-00029W-00 for megaco@ietf.org; Fri, 03 Oct 2003 11:28:52 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1A5RrQ-00029H-00 for megaco@ietf.org; Fri, 03 Oct 2003 11:28:52 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h93FSK107063 for ; Fri, 3 Oct 2003 11:28:20 -0400 (EDT) Received: from zrtpd0jh.us.nortel.com ([47.140.202.34]) by zrtpd0jn.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T9HC3VTP; Fri, 3 Oct 2003 11:28:21 -0400 Received: by zrtpd0jh.us.nortel.com with Internet Mail Service (5.5.2653.19) id <41VAYL2M>; Fri, 3 Oct 2003 11:28:21 -0400 Message-ID: X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Kevin Boyle" To: Aleksandr Ryabin , megaco@ietf.org Cc: Christian Groves Subject: RE: [Megaco] CAS Metering Pulse support Date: Fri, 3 Oct 2003 11:28:17 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , I have no problem with producing an amendment to H.248.26. There really is no need for us to produce 1000 recommendations with 1 package each. Kevin -----Original Message----- From: Aleksandr Ryabin [mailto:kengr@motorola.com] Sent: Friday, October 03, 2003 11:21 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org Cc: Christian Groves Subject: RE: [Megaco] CAS Metering Pulse support Hi, Sounds reasonable. Except that it probably should not be an extension since an application might be needing detection only and no generation. That is it should be then a standalone metd ("Metering Detection Package"). Since amet and metd are complimentary I think it would be reasonable to keep them together, that is to a amend H.248.26 to include it. Would you as the editor of H.248.26 recommend amending it to include new metd or rather have new H.248.metd, or something else? I can provide a baseline text, if necessary. Regards, Aleks At 09:34 AM 10/3/2003, Kevin Boyle wrote: >The amet package was never designed to do pulse detection. The pr >event is meant to allow the MGC to stay updated with the actual number >of pulses applied -- it has nothing to do with pulses detected. This >allows the MGC to have an accurate view of the number of pulses >applied, rather than guessing -- and possibly being wrong due to >network latency, message loss, retransmission, etc., etc., etc. I >think shoehorning detection in here isn't really appropriate. > >Further, are we sure that ALL pulse generation applications will be >required to detect pulses? In the analog line case, the MG has no >reason to detect pulses -- pulses are being sent to the CPE for the >end-user's benefit. I think that it would be far wiser to define an >extension package to handle detection, and not subject applications >that only want to do generation to doing detection as well. > >Kevin > >-----Original Message----- >From: Christian Groves [mailto:Christian.Groves@ericsson.com.au] >Sent: Thursday, October 02, 2003 11:38 PM >To: Aleksandr Ryabin >Cc: megaco@ietf.org; Boyle, Kevin [NCRTP:3Z40:EXCH] >Subject: Re: [Megaco] CAS Metering Pulse support > > >Hello Aleksandr, > >I'm happy enough to have the your proposed amendment if the editor >agrees. > >Regards, Christian > >Aleksandr Ryabin wrote: > > Hi Christian, > > > > No description of the event does say how to use it for detection > > incoming metering pulse. More over it explicitly limits to > > generation: "This event is used in conjunction with the "enable > > metering" and "metering pulse burst" signals defined in this > > package..." > > > > My point being that descriptions of amet events and statistics are > > siting that event pr is generated and statistics are changed only > > based on previously applied em, or mbp signal. > > > > The wording needs to be amended to cover the cases when event is > > generated and statistics are changed as a result *detection* of > > incoming metering pulse. > > > > That is, for example, the text you have referenced should be changed > > to something like this (I've placed the changes in [] for > > visibility): > > > > "If following the application [or detection] of any metering pulse > > (regardless of [whether it was detected, or] whether it was > > generated as a result of the signal em or as a result of the signal > > mbp), the EventsDescriptor contains the event pr, and if the value > > of pcslr is equal to the value of the > > EventsDescriptor parameter rp, then the pr event shall be notified, and > > the value of the statistic pcslr shall be reset to zero. The detection of > > the event pr shall not cause the termination of the signal em or the > > signal mbp, [if currently active,] even if the KeepActive flag is not > > set for the pr event." > > > > Regards, > > Aleks > > > > At 07:46 PM 10/2/2003, Christian Groves wrote: > > > >> Hello Aleksandr, > >> > >> I agree that no new package is needed for the detection of metering > >> pulse functionality. From the description of the event it seems > >> that it clear how it to be used. > >> > >> The package also contains the procedural text: > >> "If following the application of any metering pulse (regardless of > >> whether it was generated as a result of the signal em or as a > >> result of the signal mbp), the EventsDescriptor contains the event > >> pr, and if the value of pcslr is equal to the value of the > >> EventsDescriptor parameter rp, then the pr event shall be notified, > >> and the value of the statistic pcslr shall be reset to zero. The > >> detection of the event pr shall not cause the termination of the > >> signal em or the signal mbp, even if the KeepActive flag is not set > >> for the pr event." > >> > >> Is this text sufficient? > >> > >> Regards, Christian > >> > >> Aleksandr Ryabin wrote: > >> > >>> Hi, > >>> In continuation to this metering pulse support. > >>> I've looked through amet package and it does not seem to define > >>> procedure to detect metering pulses, it only has a procedure to > >>> generate metering pulses. I see no reason of defining a new > >>> package for detecting incoming metering pulses and I propose to > >>> reuse amet and amend it to define procedure for detecting incoming > >>> metering pulses. Here is the summary of a proposed metering pulse > >>> detection procedure using amet package: The detection of metering > >>> pulse on a termination could be enabled by MGC when no amet > >>> signals are played on a termination by requesting detection > >>> amet/pr event with a required repetition period. MG would Notify > >>> MGC with amet/pr event when number of metering pulses is detected > >>> according to repetition period parameter set. On Subtract, or > >>> explicit AuditValue MG would send amet/cpc and amet/pcslr > >>> statistics similar to as described in the package provided their > >>> description extended to detection as well. Comments? > >>> Thanks > >>> Aleks > >>> BTW IANA MEGACO page is still not updated. > >>> At 10:50 AM 9/16/2003, Aleksandr Ryabin wrote: > >>> > >>>> It is updated with H.248.22 and 25, but not with 23, 24, 26, 27 > >>>> while all of them are dated in ITU the same. Strange. > >>>> Aleks > >>>> > >>>> At 10:46 AM 9/16/2003, Kevin Boyle wrote: > >>>> > >>>>> If it is NOT updated, that is. (Apparently, it's going to be one > >>>>> of those days!) > >>>>> > >>>>> Kevin > >>>>> > >>>>> -----Original Message----- > >>>>> From: Boyle, Kevin [NCRTP:3Z40:EXCH] > >>>>> Sent: Tuesday, September 16, 2003 10:39 AM > >>>>> To: Aleksandr Ryabin; megaco@ietf.org > >>>>> Subject: RE: [Megaco] CAS Metering Pulse support > >>>>> > >>>>> Ummm... yeah. That's what I get for not looking it up before > >>>>> sending the message. :) While amet is defined in the "Extended > >>>>> Analog Lines Packages" doc, there is nothing in the amet package > >>>>> that actually limits it to analog lines. > >>>>> > >>>>> > >>>>> The updates for all the new (as of May) H.248 Sub-series > >>>>> Recommendations have already been requested of IANA. If it is > >>>>> updated by the end of the month, I'll ping them again. > >>>>> > >>>>> > >>>>> Kevin > >>>>> > >>>>> -----Original Message----- > >>>>> From: Aleksandr Ryabin [mailto:kengr@motorola.com] > >>>>> Sent: Tuesday, September 16, 2003 10:32 AM > >>>>> To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org > >>>>> Subject: RE: [Megaco] CAS Metering Pulse support > >>>>> > >>>>> Hi, > >>>>> > >>>>> I guess you meant H.248.26. > >>>>> Yes it seem to address the needs assuming it is extended to > >>>>> digital lines as well. > >>>>> > >>>>> BTW IANA registry should be updated with H.248.26 and H.248.27 > >>>>> http://www.iana.org/assignments/megaco-h248 > >>>>> > >>>>> > >>>>> Thanks, > >>>>> Aleks > >>>>> > >>>>> At 10:00 AM 9/16/2003, Kevin Boyle wrote: > >>>>> > >>>>> > >>>>> H.248.27 has a metering package (automatic metering package or > >>>>> amet). This package may address your needs. > >>>>> > >>>>> Kevin > >>>>> > >>>>> -----Original Message----- > >>>>> From: Aleksandr Ryabin [mailto:kengr@motorola.com > >>>>> ] > >>>>> Sent: Tuesday, September 16, 2003 9:34 AM > >>>>> To: megaco@ietf.org > >>>>> Subject: [Megaco] CAS Metering Pulse support > >>>>> > >>>>> Hi all, > >>>>> > >>>>> Below are excerpts from a previous exchange related to defining > >>>>> of CAS Metering Pulse procedures in MEGACO. > >>>>> > >>>>> Now that CAS packages related work has been moved to ITU has > >>>>> anyone done and/or planned anything in the direction to define > >>>>> CAS Metering Pulse procedures/package for MEGACO? > >>>>> > >>>>> Thanks > >>>>> Aleks > >>>>> > >>>>> >From: klaha@hss.hns.com > >>>>> >To: Aleksandr Ryabin > >>>>> >cc: vnair@hss.hns.com, megaco@ietf.org, klaha@hss.hns.com > >>>>> >Date: Tue, 4 Mar 2003 12:47:37 +0530 > >>>>> >Subject: Re: [Megaco] Re: draft-ietf-megaco-r2package-03.txt : > >>>>> Difference > >>>>> > from previous revision > >>>>> ... > >>>>> >Aleksandr Ryabin on 03/03/2003 10:43:20 > >>>>> >PM > >>>>> ... > >>>>> >3. I can't seem to find a way to implement "Metering Pulse" > >>>>> >procedure defined for some R2 variants using ether bcas or R2 > >>>>> >packages? For example, one of the definitions of such a pulse > >>>>> >is a "seizure ack" pulse from a terminating end on a circuit in > >>>>> >connected/answer state. > >>>>> > > >>>>> >[Kushanava] Metering is not specific to R2. It may be present > >>>>> >in any CAS signaling. Moreover not all flavours of R2 permit > >>>>> >metering to be mandatory. There should be therefore a general > >>>>> >philosophy of > >>>>> attacking > >>>>> >this problem common to all CAS signaling. The solution should > >>>>> >be sensitive to > >>>>> >a) Realizing that MGC is the master for collecting and > >>>>> >generating > >>>>> charging > >>>>> >information > >>>>> >b) Interworking of the CAS "metering pulse" signals with other > >>>>> signaling > >>>>> >(both PDN and PSTN) > >>>>> >c) Optimizing the network traffic if metering information is > >>>>> transported to > >>>>> > >>>>> >and fro between MGC and MG > >>>>> >d) Latency, if metering information is transported to and fro > >>>>> between MGC > >>>>> >and MG > >>>>> >We are working towards a separate package that addresses this > >>>>> >issue. Any suggestions? > >>>>> ... > >>>>> > >>>>> _______________________________________________ > >>>>> Megaco mailing list > >>>>> Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco > >>>>> > >>>>> _______________________________________________ > >>>>> Megaco mailing list > >>>>> Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco > > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri Oct 3 11:29:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12192 for ; Fri, 3 Oct 2003 11:29:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Rrc-0002uL-7F for megaco-archive@odin.ietf.org; Fri, 03 Oct 2003 11:29:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93FT4FX011171 for megaco-archive@odin.ietf.org; Fri, 3 Oct 2003 11:29:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Rrc-0002u6-20 for megaco-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 11:29:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12157 for ; Fri, 3 Oct 2003 11:28:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Rrb-00029c-00 for megaco-web-archive@ietf.org; Fri, 03 Oct 2003 11:29:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5Rra-00029Z-00 for megaco-web-archive@ietf.org; Fri, 03 Oct 2003 11:29:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5RrZ-0002t4-RI; Fri, 03 Oct 2003 11:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5RrR-0002sn-Fz for megaco@optimus.ietf.org; Fri, 03 Oct 2003 11:28:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12153 for ; Fri, 3 Oct 2003 11:28:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5RrQ-00029W-00 for megaco@ietf.org; Fri, 03 Oct 2003 11:28:52 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1A5RrQ-00029H-00 for megaco@ietf.org; Fri, 03 Oct 2003 11:28:52 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h93FSK107063 for ; Fri, 3 Oct 2003 11:28:20 -0400 (EDT) Received: from zrtpd0jh.us.nortel.com ([47.140.202.34]) by zrtpd0jn.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T9HC3VTP; Fri, 3 Oct 2003 11:28:21 -0400 Received: by zrtpd0jh.us.nortel.com with Internet Mail Service (5.5.2653.19) id <41VAYL2M>; Fri, 3 Oct 2003 11:28:21 -0400 Message-ID: X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Kevin Boyle" To: Aleksandr Ryabin , megaco@ietf.org Cc: Christian Groves Subject: RE: [Megaco] CAS Metering Pulse support Date: Fri, 3 Oct 2003 11:28:17 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , I have no problem with producing an amendment to H.248.26. There really is no need for us to produce 1000 recommendations with 1 package each. Kevin -----Original Message----- From: Aleksandr Ryabin [mailto:kengr@motorola.com] Sent: Friday, October 03, 2003 11:21 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org Cc: Christian Groves Subject: RE: [Megaco] CAS Metering Pulse support Hi, Sounds reasonable. Except that it probably should not be an extension since an application might be needing detection only and no generation. That is it should be then a standalone metd ("Metering Detection Package"). Since amet and metd are complimentary I think it would be reasonable to keep them together, that is to a amend H.248.26 to include it. Would you as the editor of H.248.26 recommend amending it to include new metd or rather have new H.248.metd, or something else? I can provide a baseline text, if necessary. Regards, Aleks At 09:34 AM 10/3/2003, Kevin Boyle wrote: >The amet package was never designed to do pulse detection. The pr >event is meant to allow the MGC to stay updated with the actual number >of pulses applied -- it has nothing to do with pulses detected. This >allows the MGC to have an accurate view of the number of pulses >applied, rather than guessing -- and possibly being wrong due to >network latency, message loss, retransmission, etc., etc., etc. I >think shoehorning detection in here isn't really appropriate. > >Further, are we sure that ALL pulse generation applications will be >required to detect pulses? In the analog line case, the MG has no >reason to detect pulses -- pulses are being sent to the CPE for the >end-user's benefit. I think that it would be far wiser to define an >extension package to handle detection, and not subject applications >that only want to do generation to doing detection as well. > >Kevin > >-----Original Message----- >From: Christian Groves [mailto:Christian.Groves@ericsson.com.au] >Sent: Thursday, October 02, 2003 11:38 PM >To: Aleksandr Ryabin >Cc: megaco@ietf.org; Boyle, Kevin [NCRTP:3Z40:EXCH] >Subject: Re: [Megaco] CAS Metering Pulse support > > >Hello Aleksandr, > >I'm happy enough to have the your proposed amendment if the editor >agrees. > >Regards, Christian > >Aleksandr Ryabin wrote: > > Hi Christian, > > > > No description of the event does say how to use it for detection > > incoming metering pulse. More over it explicitly limits to > > generation: "This event is used in conjunction with the "enable > > metering" and "metering pulse burst" signals defined in this > > package..." > > > > My point being that descriptions of amet events and statistics are > > siting that event pr is generated and statistics are changed only > > based on previously applied em, or mbp signal. > > > > The wording needs to be amended to cover the cases when event is > > generated and statistics are changed as a result *detection* of > > incoming metering pulse. > > > > That is, for example, the text you have referenced should be changed > > to something like this (I've placed the changes in [] for > > visibility): > > > > "If following the application [or detection] of any metering pulse > > (regardless of [whether it was detected, or] whether it was > > generated as a result of the signal em or as a result of the signal > > mbp), the EventsDescriptor contains the event pr, and if the value > > of pcslr is equal to the value of the > > EventsDescriptor parameter rp, then the pr event shall be notified, and > > the value of the statistic pcslr shall be reset to zero. The detection of > > the event pr shall not cause the termination of the signal em or the > > signal mbp, [if currently active,] even if the KeepActive flag is not > > set for the pr event." > > > > Regards, > > Aleks > > > > At 07:46 PM 10/2/2003, Christian Groves wrote: > > > >> Hello Aleksandr, > >> > >> I agree that no new package is needed for the detection of metering > >> pulse functionality. From the description of the event it seems > >> that it clear how it to be used. > >> > >> The package also contains the procedural text: > >> "If following the application of any metering pulse (regardless of > >> whether it was generated as a result of the signal em or as a > >> result of the signal mbp), the EventsDescriptor contains the event > >> pr, and if the value of pcslr is equal to the value of the > >> EventsDescriptor parameter rp, then the pr event shall be notified, > >> and the value of the statistic pcslr shall be reset to zero. The > >> detection of the event pr shall not cause the termination of the > >> signal em or the signal mbp, even if the KeepActive flag is not set > >> for the pr event." > >> > >> Is this text sufficient? > >> > >> Regards, Christian > >> > >> Aleksandr Ryabin wrote: > >> > >>> Hi, > >>> In continuation to this metering pulse support. > >>> I've looked through amet package and it does not seem to define > >>> procedure to detect metering pulses, it only has a procedure to > >>> generate metering pulses. I see no reason of defining a new > >>> package for detecting incoming metering pulses and I propose to > >>> reuse amet and amend it to define procedure for detecting incoming > >>> metering pulses. Here is the summary of a proposed metering pulse > >>> detection procedure using amet package: The detection of metering > >>> pulse on a termination could be enabled by MGC when no amet > >>> signals are played on a termination by requesting detection > >>> amet/pr event with a required repetition period. MG would Notify > >>> MGC with amet/pr event when number of metering pulses is detected > >>> according to repetition period parameter set. On Subtract, or > >>> explicit AuditValue MG would send amet/cpc and amet/pcslr > >>> statistics similar to as described in the package provided their > >>> description extended to detection as well. Comments? > >>> Thanks > >>> Aleks > >>> BTW IANA MEGACO page is still not updated. > >>> At 10:50 AM 9/16/2003, Aleksandr Ryabin wrote: > >>> > >>>> It is updated with H.248.22 and 25, but not with 23, 24, 26, 27 > >>>> while all of them are dated in ITU the same. Strange. > >>>> Aleks > >>>> > >>>> At 10:46 AM 9/16/2003, Kevin Boyle wrote: > >>>> > >>>>> If it is NOT updated, that is. (Apparently, it's going to be one > >>>>> of those days!) > >>>>> > >>>>> Kevin > >>>>> > >>>>> -----Original Message----- > >>>>> From: Boyle, Kevin [NCRTP:3Z40:EXCH] > >>>>> Sent: Tuesday, September 16, 2003 10:39 AM > >>>>> To: Aleksandr Ryabin; megaco@ietf.org > >>>>> Subject: RE: [Megaco] CAS Metering Pulse support > >>>>> > >>>>> Ummm... yeah. That's what I get for not looking it up before > >>>>> sending the message. :) While amet is defined in the "Extended > >>>>> Analog Lines Packages" doc, there is nothing in the amet package > >>>>> that actually limits it to analog lines. > >>>>> > >>>>> > >>>>> The updates for all the new (as of May) H.248 Sub-series > >>>>> Recommendations have already been requested of IANA. If it is > >>>>> updated by the end of the month, I'll ping them again. > >>>>> > >>>>> > >>>>> Kevin > >>>>> > >>>>> -----Original Message----- > >>>>> From: Aleksandr Ryabin [mailto:kengr@motorola.com] > >>>>> Sent: Tuesday, September 16, 2003 10:32 AM > >>>>> To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org > >>>>> Subject: RE: [Megaco] CAS Metering Pulse support > >>>>> > >>>>> Hi, > >>>>> > >>>>> I guess you meant H.248.26. > >>>>> Yes it seem to address the needs assuming it is extended to > >>>>> digital lines as well. > >>>>> > >>>>> BTW IANA registry should be updated with H.248.26 and H.248.27 > >>>>> http://www.iana.org/assignments/megaco-h248 > >>>>> > >>>>> > >>>>> Thanks, > >>>>> Aleks > >>>>> > >>>>> At 10:00 AM 9/16/2003, Kevin Boyle wrote: > >>>>> > >>>>> > >>>>> H.248.27 has a metering package (automatic metering package or > >>>>> amet). This package may address your needs. > >>>>> > >>>>> Kevin > >>>>> > >>>>> -----Original Message----- > >>>>> From: Aleksandr Ryabin [mailto:kengr@motorola.com > >>>>> ] > >>>>> Sent: Tuesday, September 16, 2003 9:34 AM > >>>>> To: megaco@ietf.org > >>>>> Subject: [Megaco] CAS Metering Pulse support > >>>>> > >>>>> Hi all, > >>>>> > >>>>> Below are excerpts from a previous exchange related to defining > >>>>> of CAS Metering Pulse procedures in MEGACO. > >>>>> > >>>>> Now that CAS packages related work has been moved to ITU has > >>>>> anyone done and/or planned anything in the direction to define > >>>>> CAS Metering Pulse procedures/package for MEGACO? > >>>>> > >>>>> Thanks > >>>>> Aleks > >>>>> > >>>>> >From: klaha@hss.hns.com > >>>>> >To: Aleksandr Ryabin > >>>>> >cc: vnair@hss.hns.com, megaco@ietf.org, klaha@hss.hns.com > >>>>> >Date: Tue, 4 Mar 2003 12:47:37 +0530 > >>>>> >Subject: Re: [Megaco] Re: draft-ietf-megaco-r2package-03.txt : > >>>>> Difference > >>>>> > from previous revision > >>>>> ... > >>>>> >Aleksandr Ryabin on 03/03/2003 10:43:20 > >>>>> >PM > >>>>> ... > >>>>> >3. I can't seem to find a way to implement "Metering Pulse" > >>>>> >procedure defined for some R2 variants using ether bcas or R2 > >>>>> >packages? For example, one of the definitions of such a pulse > >>>>> >is a "seizure ack" pulse from a terminating end on a circuit in > >>>>> >connected/answer state. > >>>>> > > >>>>> >[Kushanava] Metering is not specific to R2. It may be present > >>>>> >in any CAS signaling. Moreover not all flavours of R2 permit > >>>>> >metering to be mandatory. There should be therefore a general > >>>>> >philosophy of > >>>>> attacking > >>>>> >this problem common to all CAS signaling. The solution should > >>>>> >be sensitive to > >>>>> >a) Realizing that MGC is the master for collecting and > >>>>> >generating > >>>>> charging > >>>>> >information > >>>>> >b) Interworking of the CAS "metering pulse" signals with other > >>>>> signaling > >>>>> >(both PDN and PSTN) > >>>>> >c) Optimizing the network traffic if metering information is > >>>>> transported to > >>>>> > >>>>> >and fro between MGC and MG > >>>>> >d) Latency, if metering information is transported to and fro > >>>>> between MGC > >>>>> >and MG > >>>>> >We are working towards a separate package that addresses this > >>>>> >issue. Any suggestions? > >>>>> ... > >>>>> > >>>>> _______________________________________________ > >>>>> Megaco mailing list > >>>>> Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco > >>>>> > >>>>> _______________________________________________ > >>>>> Megaco mailing list > >>>>> Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco > > > > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Oct 3 13:13:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16909 for ; Fri, 3 Oct 2003 13:13:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5TUC-0000pg-PG; Fri, 03 Oct 2003 13:13:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5TU6-0000pR-HW for megaco@optimus.ietf.org; Fri, 03 Oct 2003 13:12:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16889 for ; Fri, 3 Oct 2003 13:12:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5TU4-0003nM-00 for megaco@ietf.org; Fri, 03 Oct 2003 13:12:52 -0400 Received: from exchange.santera.com ([4.22.157.11] helo=excalibur.santera.com) by ietf-mx with smtp (Exim 4.12) id 1A5TU4-0003nG-00 for megaco@ietf.org; Fri, 03 Oct 2003 13:12:52 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: normal Priority: normal Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Megaco] CAS Metering Pulse support Date: Fri, 3 Oct 2003 12:12:15 -0500 Message-ID: Thread-Topic: [Megaco] CAS Metering Pulse support thread-index: AcOJwaDUV+dKSH5iTTOiM+0no4tbgAAAUQdA From: "Soncodi, Adrian" To: "Christian Groves" , "Aleksandr Ryabin" Cc: , "Kevin Boyle" Content-Transfer-Encoding: quoted-printable Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable In some countries a tandem switch is required to propagate meter pulses = (backwards) from the outgoing R2 trunk to the incoming R2 trunk. These = pulses are used for billing. A potential problem is that the pulse rate = may be very high, sometimes it can be a sub-second interval. Therefore, = a tandem MGC which has a considerable number of R2 trunks will have a = big overhead for propagating meter pulses, which will affect its call = processing rate. So I'm wondering if anything can be done about this. Here are two = possibilities: 1) Allow the MG to detect meter pulses but report them in chunks of N. = By default, N=3D1 (report every pulse), but the MGC could also select, = say, N=3D10, in which case the MG reports once every 10 pulses. (A = residual pulse count could be reported on Subtract). This method saves a = lot of NTFY messages. However, on the other side, the MGC would be = forced to propagate the pulses as bursts-of-N, and I am not sure a = switch is allowed to transform constant-rate pulsing into bursts. (On = the other hand why not? because it's only the total pulse count that is = relevant for charging. Time-of-day periods with higher charging rates = actually result in more meter pulses.) 2) Define a mode which allows the meter pulses to be propagated directly = between MGs, without MGC involvement, i.e. by a method similar to = RFC2833. RFC2833 does not currently have an event defined for meter = pulses, but it could be extended, since it defines a lot of = signaling-related tones anyway. In addition to solving the NTFY = messaging overhead, this method would have the side benefit that it = would also work between two MGCs that use SIP or BICC between them. = Currently, there is no way to transport meter pulse information in SIP = or BICC, and this would have a terrible overhead anyway. Of course, the ability to detect meter pulses is still required, because = there is always the possibility that the MGC must perform the = meter-pulse-based charging itself (rather than propagate). Any other ideas or comments? Adrian Soncodi -----Original Message----- From: Christian Groves [mailto:Christian.Groves@ericsson.com.au] Sent: Thursday, October 02, 2003 10:38 PM To: Aleksandr Ryabin Cc: megaco@ietf.org; Kevin Boyle Subject: Re: [Megaco] CAS Metering Pulse support Hello Aleksandr, I'm happy enough to have the your proposed amendment if the editor = agrees. Regards, Christian Aleksandr Ryabin wrote: > Hi Christian, >=20 > No description of the event does say how to use it for detection > incoming metering pulse. More over it explicitly limits to generation: > "This event is used in conjunction with the "enable metering" and > "metering pulse burst" signals defined in this package..." >=20 > My point being that descriptions of amet events and statistics > are siting that event pr is generated and statistics are changed > only based on previously applied em, or mbp signal. >=20 > The wording needs to be amended to cover the cases when event > is generated and statistics are changed as a result *detection* of > incoming metering pulse. >=20 > That is, for example, the text you have referenced should be changed > to something like this (I've placed the changes in [] for visibility): >=20 > "If following the application [or detection] of any metering pulse=20 > (regardless > of [whether it was detected, or] whether it was generated as a result > of the signal em or as a result of the signal mbp), the = EventsDescriptor > contains the event pr, and if the value of pcslr is equal to the value = > of the > EventsDescriptor parameter rp, then the pr event shall be notified, = and > the value of the statistic pcslr shall be reset to zero. The = detection of > the event pr shall not cause the termination of the signal em or the > signal mbp, [if currently active,] even if the KeepActive flag is not > set for the pr event." >=20 > Regards, > Aleks >=20 > At 07:46 PM 10/2/2003, Christian Groves wrote: >=20 >> Hello Aleksandr, >> >> I agree that no new package is needed for the detection of metering=20 >> pulse functionality. From the description of the event it seems that=20 >> it clear how it to be used. >> >> The package also contains the procedural text: >> "If following the application of any metering pulse (regardless of=20 >> whether it was generated as a result of the signal em or as a result=20 >> of the signal mbp), the EventsDescriptor contains the event pr, and = if=20 >> the value of pcslr is equal to the value of the EventsDescriptor=20 >> parameter rp, then the pr event shall be notified, and the value of=20 >> the statistic pcslr shall be reset to zero. The detection of the=20 >> event pr shall not cause the termination of the signal em or the=20 >> signal mbp, even if the KeepActive flag is not set for the pr event." >> >> Is this text sufficient? >> >> Regards, Christian >> >> Aleksandr Ryabin wrote: >> >>> Hi, >>> In continuation to this metering pulse support. >>> I've looked through amet package and it does not seem to >>> define procedure to detect metering pulses, it only has >>> a procedure to generate metering pulses. >>> I see no reason of defining a new package for detecting incoming >>> metering pulses and I propose to reuse amet and amend it to >>> define procedure for detecting incoming metering pulses. >>> Here is the summary of a proposed metering pulse detection >>> procedure using amet package: >>> The detection of metering pulse on a termination could be enabled >>> by MGC when no amet signals are played on a termination by >>> requesting detection amet/pr event with a required repetition = period. >>> MG would Notify MGC with amet/pr event when number of metering >>> pulses is detected according to repetition period parameter set. >>> On Subtract, or explicit AuditValue MG would send amet/cpc >>> and amet/pcslr statistics similar to as described in the package >>> provided their description extended to detection as well. >>> Comments? >>> Thanks >>> Aleks >>> BTW IANA MEGACO page is still not updated. >>> At 10:50 AM 9/16/2003, Aleksandr Ryabin wrote: >>> >>>> It is updated with H.248.22 and 25, but not with 23, 24, 26, 27 >>>> while all of them are dated in ITU the same. Strange. >>>> Aleks >>>> >>>> At 10:46 AM 9/16/2003, Kevin Boyle wrote: >>>> >>>>> If it is NOT updated, that is. (Apparently, it's going to be one = of=20 >>>>> those days!) >>>>> >>>>> Kevin >>>>> >>>>> -----Original Message----- >>>>> From: Boyle, Kevin [NCRTP:3Z40:EXCH] >>>>> Sent: Tuesday, September 16, 2003 10:39 AM >>>>> To: Aleksandr Ryabin; megaco@ietf.org >>>>> Subject: RE: [Megaco] CAS Metering Pulse support >>>>> >>>>> Ummm... yeah. That's what I get for not looking it up before=20 >>>>> sending the message. :) While amet is defined in the "Extended=20 >>>>> Analog Lines Packages" doc, there is nothing in the amet package=20 >>>>> that actually limits it to analog lines. >>>>> >>>>> >>>>> The updates for all the new (as of May) H.248 Sub-series=20 >>>>> Recommendations have already been requested of IANA. If it is=20 >>>>> updated by the end of the month, I'll ping them again. >>>>> >>>>> >>>>> Kevin >>>>> >>>>> -----Original Message----- >>>>> From: Aleksandr Ryabin [mailto:kengr@motorola.com] >>>>> Sent: Tuesday, September 16, 2003 10:32 AM >>>>> To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org >>>>> Subject: RE: [Megaco] CAS Metering Pulse support >>>>> >>>>> Hi, >>>>> >>>>> I guess you meant H.248.26. >>>>> Yes it seem to address the needs assuming it is extended to = digital=20 >>>>> lines as well. >>>>> >>>>> BTW IANA registry should be updated with H.248.26 and H.248.27 >>>>> http://www.iana.org/assignments/megaco-h248 >>>>> >>>>> >>>>> Thanks, >>>>> Aleks >>>>> >>>>> At 10:00 AM 9/16/2003, Kevin Boyle wrote: >>>>> >>>>> >>>>> H.248.27 has a metering package (automatic metering package or=20 >>>>> amet). This package may address your needs. >>>>> >>>>> Kevin >>>>> >>>>> -----Original Message----- >>>>> From: Aleksandr Ryabin [mailto:kengr@motorola.com=20 >>>>> ] >>>>> Sent: Tuesday, September 16, 2003 9:34 AM >>>>> To: megaco@ietf.org >>>>> Subject: [Megaco] CAS Metering Pulse support >>>>> >>>>> Hi all, >>>>> >>>>> Below are excerpts from a previous exchange related to defining of = >>>>> CAS Metering Pulse procedures in MEGACO. >>>>> >>>>> Now that CAS packages related work has been moved to ITU has = anyone=20 >>>>> done and/or planned anything in the direction to define CAS=20 >>>>> Metering Pulse procedures/package for MEGACO? >>>>> >>>>> Thanks >>>>> Aleks >>>>> >>>>> >From: klaha@hss.hns.com >>>>> >To: Aleksandr Ryabin >>>>> >cc: vnair@hss.hns.com, megaco@ietf.org, klaha@hss.hns.com >>>>> >Date: Tue, 4 Mar 2003 12:47:37 +0530 >>>>> >Subject: Re: [Megaco] Re: draft-ietf-megaco-r2package-03.txt :=20 >>>>> Difference >>>>> > from previous revision >>>>> ... >>>>> >Aleksandr Ryabin on 03/03/2003 10:43:20 PM >>>>> ... >>>>> >3. I can't seem to find a way to implement "Metering Pulse" = procedure >>>>> >defined for some R2 variants using ether bcas or R2 packages? For >>>>> >example, one of the definitions of such a pulse is a "seizure = ack" >>>>> >pulse from a terminating end on a circuit in connected/answer = state. >>>>> > >>>>> >[Kushanava] Metering is not specific to R2. It may be present in = any >>>>> >CAS signaling. Moreover not all flavours of R2 permit metering to = be >>>>> >mandatory. There should be therefore a general philosophy of=20 >>>>> attacking >>>>> >this problem common to all CAS signaling. The solution should be >>>>> >sensitive to >>>>> >a) Realizing that MGC is the master for collecting and generating = >>>>> charging >>>>> >information >>>>> >b) Interworking of the CAS "metering pulse" signals with other=20 >>>>> signaling >>>>> >(both PDN and PSTN) >>>>> >c) Optimizing the network traffic if metering information is=20 >>>>> transported to >>>>> >>>>> >and fro between MGC and MG >>>>> >d) Latency, if metering information is transported to and fro=20 >>>>> between MGC >>>>> >and MG >>>>> >We are working towards a separate package that addresses this = issue. >>>>> >Any suggestions? >>>>> ... >>>>> >>>>> _______________________________________________ >>>>> 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 >=20 >=20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you are not the intended recipient you are notified that = disclosing, copying, distributing or taking any action in reliance on = the contents of this information is strictly prohibited. If you have = received this email in error please notify the sender and delete the = email.=20 Santera, a Tekelec Company http://www.santera.com 972-461-4100 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri Oct 3 13:13:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16924 for ; Fri, 3 Oct 2003 13:13:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5TUG-0000qw-Fb for megaco-archive@odin.ietf.org; Fri, 03 Oct 2003 13:13:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93HD4xg003272 for megaco-archive@odin.ietf.org; Fri, 3 Oct 2003 13:13:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5TUG-0000qh-Ai for megaco-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 13:13:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16896 for ; Fri, 3 Oct 2003 13:12:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5TUE-0003nW-00 for megaco-web-archive@ietf.org; Fri, 03 Oct 2003 13:13:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5TUD-0003nQ-00 for megaco-web-archive@ietf.org; Fri, 03 Oct 2003 13:13:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5TUC-0000pg-PG; Fri, 03 Oct 2003 13:13:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5TU6-0000pR-HW for megaco@optimus.ietf.org; Fri, 03 Oct 2003 13:12:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16889 for ; Fri, 3 Oct 2003 13:12:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5TU4-0003nM-00 for megaco@ietf.org; Fri, 03 Oct 2003 13:12:52 -0400 Received: from exchange.santera.com ([4.22.157.11] helo=excalibur.santera.com) by ietf-mx with smtp (Exim 4.12) id 1A5TU4-0003nG-00 for megaco@ietf.org; Fri, 03 Oct 2003 13:12:52 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: normal Priority: normal Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Megaco] CAS Metering Pulse support Date: Fri, 3 Oct 2003 12:12:15 -0500 Message-ID: Thread-Topic: [Megaco] CAS Metering Pulse support thread-index: AcOJwaDUV+dKSH5iTTOiM+0no4tbgAAAUQdA From: "Soncodi, Adrian" To: "Christian Groves" , "Aleksandr Ryabin" Cc: , "Kevin Boyle" Content-Transfer-Encoding: quoted-printable Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable In some countries a tandem switch is required to propagate meter pulses = (backwards) from the outgoing R2 trunk to the incoming R2 trunk. These = pulses are used for billing. A potential problem is that the pulse rate = may be very high, sometimes it can be a sub-second interval. Therefore, = a tandem MGC which has a considerable number of R2 trunks will have a = big overhead for propagating meter pulses, which will affect its call = processing rate. So I'm wondering if anything can be done about this. Here are two = possibilities: 1) Allow the MG to detect meter pulses but report them in chunks of N. = By default, N=3D1 (report every pulse), but the MGC could also select, = say, N=3D10, in which case the MG reports once every 10 pulses. (A = residual pulse count could be reported on Subtract). This method saves a = lot of NTFY messages. However, on the other side, the MGC would be = forced to propagate the pulses as bursts-of-N, and I am not sure a = switch is allowed to transform constant-rate pulsing into bursts. (On = the other hand why not? because it's only the total pulse count that is = relevant for charging. Time-of-day periods with higher charging rates = actually result in more meter pulses.) 2) Define a mode which allows the meter pulses to be propagated directly = between MGs, without MGC involvement, i.e. by a method similar to = RFC2833. RFC2833 does not currently have an event defined for meter = pulses, but it could be extended, since it defines a lot of = signaling-related tones anyway. In addition to solving the NTFY = messaging overhead, this method would have the side benefit that it = would also work between two MGCs that use SIP or BICC between them. = Currently, there is no way to transport meter pulse information in SIP = or BICC, and this would have a terrible overhead anyway. Of course, the ability to detect meter pulses is still required, because = there is always the possibility that the MGC must perform the = meter-pulse-based charging itself (rather than propagate). Any other ideas or comments? Adrian Soncodi -----Original Message----- From: Christian Groves [mailto:Christian.Groves@ericsson.com.au] Sent: Thursday, October 02, 2003 10:38 PM To: Aleksandr Ryabin Cc: megaco@ietf.org; Kevin Boyle Subject: Re: [Megaco] CAS Metering Pulse support Hello Aleksandr, I'm happy enough to have the your proposed amendment if the editor = agrees. Regards, Christian Aleksandr Ryabin wrote: > Hi Christian, >=20 > No description of the event does say how to use it for detection > incoming metering pulse. More over it explicitly limits to generation: > "This event is used in conjunction with the "enable metering" and > "metering pulse burst" signals defined in this package..." >=20 > My point being that descriptions of amet events and statistics > are siting that event pr is generated and statistics are changed > only based on previously applied em, or mbp signal. >=20 > The wording needs to be amended to cover the cases when event > is generated and statistics are changed as a result *detection* of > incoming metering pulse. >=20 > That is, for example, the text you have referenced should be changed > to something like this (I've placed the changes in [] for visibility): >=20 > "If following the application [or detection] of any metering pulse=20 > (regardless > of [whether it was detected, or] whether it was generated as a result > of the signal em or as a result of the signal mbp), the = EventsDescriptor > contains the event pr, and if the value of pcslr is equal to the value = > of the > EventsDescriptor parameter rp, then the pr event shall be notified, = and > the value of the statistic pcslr shall be reset to zero. The = detection of > the event pr shall not cause the termination of the signal em or the > signal mbp, [if currently active,] even if the KeepActive flag is not > set for the pr event." >=20 > Regards, > Aleks >=20 > At 07:46 PM 10/2/2003, Christian Groves wrote: >=20 >> Hello Aleksandr, >> >> I agree that no new package is needed for the detection of metering=20 >> pulse functionality. From the description of the event it seems that=20 >> it clear how it to be used. >> >> The package also contains the procedural text: >> "If following the application of any metering pulse (regardless of=20 >> whether it was generated as a result of the signal em or as a result=20 >> of the signal mbp), the EventsDescriptor contains the event pr, and = if=20 >> the value of pcslr is equal to the value of the EventsDescriptor=20 >> parameter rp, then the pr event shall be notified, and the value of=20 >> the statistic pcslr shall be reset to zero. The detection of the=20 >> event pr shall not cause the termination of the signal em or the=20 >> signal mbp, even if the KeepActive flag is not set for the pr event." >> >> Is this text sufficient? >> >> Regards, Christian >> >> Aleksandr Ryabin wrote: >> >>> Hi, >>> In continuation to this metering pulse support. >>> I've looked through amet package and it does not seem to >>> define procedure to detect metering pulses, it only has >>> a procedure to generate metering pulses. >>> I see no reason of defining a new package for detecting incoming >>> metering pulses and I propose to reuse amet and amend it to >>> define procedure for detecting incoming metering pulses. >>> Here is the summary of a proposed metering pulse detection >>> procedure using amet package: >>> The detection of metering pulse on a termination could be enabled >>> by MGC when no amet signals are played on a termination by >>> requesting detection amet/pr event with a required repetition = period. >>> MG would Notify MGC with amet/pr event when number of metering >>> pulses is detected according to repetition period parameter set. >>> On Subtract, or explicit AuditValue MG would send amet/cpc >>> and amet/pcslr statistics similar to as described in the package >>> provided their description extended to detection as well. >>> Comments? >>> Thanks >>> Aleks >>> BTW IANA MEGACO page is still not updated. >>> At 10:50 AM 9/16/2003, Aleksandr Ryabin wrote: >>> >>>> It is updated with H.248.22 and 25, but not with 23, 24, 26, 27 >>>> while all of them are dated in ITU the same. Strange. >>>> Aleks >>>> >>>> At 10:46 AM 9/16/2003, Kevin Boyle wrote: >>>> >>>>> If it is NOT updated, that is. (Apparently, it's going to be one = of=20 >>>>> those days!) >>>>> >>>>> Kevin >>>>> >>>>> -----Original Message----- >>>>> From: Boyle, Kevin [NCRTP:3Z40:EXCH] >>>>> Sent: Tuesday, September 16, 2003 10:39 AM >>>>> To: Aleksandr Ryabin; megaco@ietf.org >>>>> Subject: RE: [Megaco] CAS Metering Pulse support >>>>> >>>>> Ummm... yeah. That's what I get for not looking it up before=20 >>>>> sending the message. :) While amet is defined in the "Extended=20 >>>>> Analog Lines Packages" doc, there is nothing in the amet package=20 >>>>> that actually limits it to analog lines. >>>>> >>>>> >>>>> The updates for all the new (as of May) H.248 Sub-series=20 >>>>> Recommendations have already been requested of IANA. If it is=20 >>>>> updated by the end of the month, I'll ping them again. >>>>> >>>>> >>>>> Kevin >>>>> >>>>> -----Original Message----- >>>>> From: Aleksandr Ryabin [mailto:kengr@motorola.com] >>>>> Sent: Tuesday, September 16, 2003 10:32 AM >>>>> To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org >>>>> Subject: RE: [Megaco] CAS Metering Pulse support >>>>> >>>>> Hi, >>>>> >>>>> I guess you meant H.248.26. >>>>> Yes it seem to address the needs assuming it is extended to = digital=20 >>>>> lines as well. >>>>> >>>>> BTW IANA registry should be updated with H.248.26 and H.248.27 >>>>> http://www.iana.org/assignments/megaco-h248 >>>>> >>>>> >>>>> Thanks, >>>>> Aleks >>>>> >>>>> At 10:00 AM 9/16/2003, Kevin Boyle wrote: >>>>> >>>>> >>>>> H.248.27 has a metering package (automatic metering package or=20 >>>>> amet). This package may address your needs. >>>>> >>>>> Kevin >>>>> >>>>> -----Original Message----- >>>>> From: Aleksandr Ryabin [mailto:kengr@motorola.com=20 >>>>> ] >>>>> Sent: Tuesday, September 16, 2003 9:34 AM >>>>> To: megaco@ietf.org >>>>> Subject: [Megaco] CAS Metering Pulse support >>>>> >>>>> Hi all, >>>>> >>>>> Below are excerpts from a previous exchange related to defining of = >>>>> CAS Metering Pulse procedures in MEGACO. >>>>> >>>>> Now that CAS packages related work has been moved to ITU has = anyone=20 >>>>> done and/or planned anything in the direction to define CAS=20 >>>>> Metering Pulse procedures/package for MEGACO? >>>>> >>>>> Thanks >>>>> Aleks >>>>> >>>>> >From: klaha@hss.hns.com >>>>> >To: Aleksandr Ryabin >>>>> >cc: vnair@hss.hns.com, megaco@ietf.org, klaha@hss.hns.com >>>>> >Date: Tue, 4 Mar 2003 12:47:37 +0530 >>>>> >Subject: Re: [Megaco] Re: draft-ietf-megaco-r2package-03.txt :=20 >>>>> Difference >>>>> > from previous revision >>>>> ... >>>>> >Aleksandr Ryabin on 03/03/2003 10:43:20 PM >>>>> ... >>>>> >3. I can't seem to find a way to implement "Metering Pulse" = procedure >>>>> >defined for some R2 variants using ether bcas or R2 packages? For >>>>> >example, one of the definitions of such a pulse is a "seizure = ack" >>>>> >pulse from a terminating end on a circuit in connected/answer = state. >>>>> > >>>>> >[Kushanava] Metering is not specific to R2. It may be present in = any >>>>> >CAS signaling. Moreover not all flavours of R2 permit metering to = be >>>>> >mandatory. There should be therefore a general philosophy of=20 >>>>> attacking >>>>> >this problem common to all CAS signaling. The solution should be >>>>> >sensitive to >>>>> >a) Realizing that MGC is the master for collecting and generating = >>>>> charging >>>>> >information >>>>> >b) Interworking of the CAS "metering pulse" signals with other=20 >>>>> signaling >>>>> >(both PDN and PSTN) >>>>> >c) Optimizing the network traffic if metering information is=20 >>>>> transported to >>>>> >>>>> >and fro between MGC and MG >>>>> >d) Latency, if metering information is transported to and fro=20 >>>>> between MGC >>>>> >and MG >>>>> >We are working towards a separate package that addresses this = issue. >>>>> >Any suggestions? >>>>> ... >>>>> >>>>> _______________________________________________ >>>>> 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 >=20 >=20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you are not the intended recipient you are notified that = disclosing, copying, distributing or taking any action in reliance on = the contents of this information is strictly prohibited. If you have = received this email in error please notify the sender and delete the = email.=20 Santera, a Tekelec Company http://www.santera.com 972-461-4100 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Oct 3 14:02:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18638 for ; Fri, 3 Oct 2003 14:02:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5UFd-0002jl-P9; Fri, 03 Oct 2003 14:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5UFU-0002jU-Ru for megaco@optimus.ietf.org; Fri, 03 Oct 2003 14:01:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18624 for ; Fri, 3 Oct 2003 14:01:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5UFS-0004Iw-00 for megaco@ietf.org; Fri, 03 Oct 2003 14:01:50 -0400 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1A5UFR-0004It-00 for megaco@ietf.org; Fri, 03 Oct 2003 14:01:49 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id h93I1jgV028581; Fri, 3 Oct 2003 11:01:46 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id h93I1iSu025102; Fri, 3 Oct 2003 13:01:44 -0500 Message-Id: <5.2.1.1.0.20031003131529.00b13d50@IL06EXM13.corp.mot.com> X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 03 Oct 2003 13:56:27 -0400 To: "Soncodi, Adrian", From: Aleksandr Ryabin Subject: RE: [Megaco] CAS Metering Pulse support Cc: "Kevin Boyle", "Christian Groves" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Proposed new metd package will have functionality described in 1). However I have a slightly different proposal for relaying. In order to relay pulses all needed to be known is a repetition interval, changes to it, if any, and when to start, and stop metering pulses. If "receiving" MGC (the one that controls MG which receives metering pulses) gets notified with this information using new metd package then it can relay this information to "generating" MGC (the one that controls MG which generates metering pulses). Then "generating" MGC can use amet to start/stop, or modify generation of metering pulses. That is in reality, if repetition interval does not change during the call, "receiving" MGC will get only two notifies per call: first pulse detected, repetition interval calculated (e.g. second pulse detected) "Generating" MGC will need to send tree modifies: pulse once (when first pulse detected event is relayed) pulse forever (when repetition interval received) stop pulse generation (when call terminates) Regards, Aleks At 01:12 PM 10/3/2003, Soncodi, Adrian wrote: >In some countries a tandem switch is required to propagate meter pulses >(backwards) from the outgoing R2 trunk to the incoming R2 trunk. These >pulses are used for billing. A potential problem is that the pulse rate >may be very high, sometimes it can be a sub-second interval. Therefore, a >tandem MGC which has a considerable number of R2 trunks will have a big >overhead for propagating meter pulses, which will affect its call >processing rate. > >So I'm wondering if anything can be done about this. Here are two >possibilities: > >1) Allow the MG to detect meter pulses but report them in chunks of N. By >default, N=1 (report every pulse), but the MGC could also select, say, >N=10, in which case the MG reports once every 10 pulses. (A residual pulse >count could be reported on Subtract). This method saves a lot of NTFY >messages. However, on the other side, the MGC would be forced to propagate >the pulses as bursts-of-N, and I am not sure a switch is allowed to >transform constant-rate pulsing into bursts. (On the other hand why not? >because it's only the total pulse count that is relevant for charging. >Time-of-day periods with higher charging rates actually result in more >meter pulses.) > >2) Define a mode which allows the meter pulses to be propagated directly >between MGs, without MGC involvement, i.e. by a method similar to RFC2833. >RFC2833 does not currently have an event defined for meter pulses, but it >could be extended, since it defines a lot of signaling-related tones >anyway. In addition to solving the NTFY messaging overhead, this method >would have the side benefit that it would also work between two MGCs that >use SIP or BICC between them. Currently, there is no way to transport >meter pulse information in SIP or BICC, and this would have a terrible >overhead anyway. >Of course, the ability to detect meter pulses is still required, because >there is always the possibility that the MGC must perform the >meter-pulse-based charging itself (rather than propagate). > >Any other ideas or comments? > >Adrian Soncodi > > > >-----Original Message----- >From: Christian Groves [mailto:Christian.Groves@ericsson.com.au] >Sent: Thursday, October 02, 2003 10:38 PM >To: Aleksandr Ryabin >Cc: megaco@ietf.org; Kevin Boyle >Subject: Re: [Megaco] CAS Metering Pulse support > > >Hello Aleksandr, > >I'm happy enough to have the your proposed amendment if the editor agrees. > >Regards, Christian > >Aleksandr Ryabin wrote: > > Hi Christian, > > > > No description of the event does say how to use it for detection > > incoming metering pulse. More over it explicitly limits to generation: > > "This event is used in conjunction with the "enable metering" and > > "metering pulse burst" signals defined in this package..." > > > > My point being that descriptions of amet events and statistics > > are siting that event pr is generated and statistics are changed > > only based on previously applied em, or mbp signal. > > > > The wording needs to be amended to cover the cases when event > > is generated and statistics are changed as a result *detection* of > > incoming metering pulse. > > > > That is, for example, the text you have referenced should be changed > > to something like this (I've placed the changes in [] for visibility): > > > > "If following the application [or detection] of any metering pulse > > (regardless > > of [whether it was detected, or] whether it was generated as a result > > of the signal em or as a result of the signal mbp), the EventsDescriptor > > contains the event pr, and if the value of pcslr is equal to the value > > of the > > EventsDescriptor parameter rp, then the pr event shall be notified, and > > the value of the statistic pcslr shall be reset to zero. The detection of > > the event pr shall not cause the termination of the signal em or the > > signal mbp, [if currently active,] even if the KeepActive flag is not > > set for the pr event." > > > > Regards, > > Aleks > > > > At 07:46 PM 10/2/2003, Christian Groves wrote: > > > >> Hello Aleksandr, > >> > >> I agree that no new package is needed for the detection of metering > >> pulse functionality. From the description of the event it seems that > >> it clear how it to be used. > >> > >> The package also contains the procedural text: > >> "If following the application of any metering pulse (regardless of > >> whether it was generated as a result of the signal em or as a result > >> of the signal mbp), the EventsDescriptor contains the event pr, and if > >> the value of pcslr is equal to the value of the EventsDescriptor > >> parameter rp, then the pr event shall be notified, and the value of > >> the statistic pcslr shall be reset to zero. The detection of the > >> event pr shall not cause the termination of the signal em or the > >> signal mbp, even if the KeepActive flag is not set for the pr event." > >> > >> Is this text sufficient? > >> > >> Regards, Christian > >> > >> Aleksandr Ryabin wrote: > >> > >>> Hi, > >>> In continuation to this metering pulse support. > >>> I've looked through amet package and it does not seem to > >>> define procedure to detect metering pulses, it only has > >>> a procedure to generate metering pulses. > >>> I see no reason of defining a new package for detecting incoming > >>> metering pulses and I propose to reuse amet and amend it to > >>> define procedure for detecting incoming metering pulses. > >>> Here is the summary of a proposed metering pulse detection > >>> procedure using amet package: > >>> The detection of metering pulse on a termination could be enabled > >>> by MGC when no amet signals are played on a termination by > >>> requesting detection amet/pr event with a required repetition period. > >>> MG would Notify MGC with amet/pr event when number of metering > >>> pulses is detected according to repetition period parameter set. > >>> On Subtract, or explicit AuditValue MG would send amet/cpc > >>> and amet/pcslr statistics similar to as described in the package > >>> provided their description extended to detection as well. > >>> Comments? > >>> Thanks > >>> Aleks > >>> BTW IANA MEGACO page is still not updated. > >>> At 10:50 AM 9/16/2003, Aleksandr Ryabin wrote: > >>> > >>>> It is updated with H.248.22 and 25, but not with 23, 24, 26, 27 > >>>> while all of them are dated in ITU the same. Strange. > >>>> Aleks > >>>> > >>>> At 10:46 AM 9/16/2003, Kevin Boyle wrote: > >>>> > >>>>> If it is NOT updated, that is. (Apparently, it's going to be one of > >>>>> those days!) > >>>>> > >>>>> Kevin > >>>>> > >>>>> -----Original Message----- > >>>>> From: Boyle, Kevin [NCRTP:3Z40:EXCH] > >>>>> Sent: Tuesday, September 16, 2003 10:39 AM > >>>>> To: Aleksandr Ryabin; megaco@ietf.org > >>>>> Subject: RE: [Megaco] CAS Metering Pulse support > >>>>> > >>>>> Ummm... yeah. That's what I get for not looking it up before > >>>>> sending the message. :) While amet is defined in the "Extended > >>>>> Analog Lines Packages" doc, there is nothing in the amet package > >>>>> that actually limits it to analog lines. > >>>>> > >>>>> > >>>>> The updates for all the new (as of May) H.248 Sub-series > >>>>> Recommendations have already been requested of IANA. If it is > >>>>> updated by the end of the month, I'll ping them again. > >>>>> > >>>>> > >>>>> Kevin > >>>>> > >>>>> -----Original Message----- > >>>>> From: Aleksandr Ryabin [mailto:kengr@motorola.com] > >>>>> Sent: Tuesday, September 16, 2003 10:32 AM > >>>>> To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org > >>>>> Subject: RE: [Megaco] CAS Metering Pulse support > >>>>> > >>>>> Hi, > >>>>> > >>>>> I guess you meant H.248.26. > >>>>> Yes it seem to address the needs assuming it is extended to digital > >>>>> lines as well. > >>>>> > >>>>> BTW IANA registry should be updated with H.248.26 and H.248.27 > >>>>> http://www.iana.org/assignments/megaco-h248 > >>>>> > >>>>> > >>>>> Thanks, > >>>>> Aleks > >>>>> > >>>>> At 10:00 AM 9/16/2003, Kevin Boyle wrote: > >>>>> > >>>>> > >>>>> H.248.27 has a metering package (automatic metering package or > >>>>> amet). This package may address your needs. > >>>>> > >>>>> Kevin > >>>>> > >>>>> -----Original Message----- > >>>>> From: Aleksandr Ryabin [mailto:kengr@motorola.com > >>>>> ] > >>>>> Sent: Tuesday, September 16, 2003 9:34 AM > >>>>> To: megaco@ietf.org > >>>>> Subject: [Megaco] CAS Metering Pulse support > >>>>> > >>>>> Hi all, > >>>>> > >>>>> Below are excerpts from a previous exchange related to defining of > >>>>> CAS Metering Pulse procedures in MEGACO. > >>>>> > >>>>> Now that CAS packages related work has been moved to ITU has anyone > >>>>> done and/or planned anything in the direction to define CAS > >>>>> Metering Pulse procedures/package for MEGACO? > >>>>> > >>>>> Thanks > >>>>> Aleks > >>>>> > >>>>> >From: klaha@hss.hns.com > >>>>> >To: Aleksandr Ryabin > >>>>> >cc: vnair@hss.hns.com, megaco@ietf.org, klaha@hss.hns.com > >>>>> >Date: Tue, 4 Mar 2003 12:47:37 +0530 > >>>>> >Subject: Re: [Megaco] Re: draft-ietf-megaco-r2package-03.txt : > >>>>> Difference > >>>>> > from previous revision > >>>>> ... > >>>>> >Aleksandr Ryabin on 03/03/2003 10:43:20 PM > >>>>> ... > >>>>> >3. I can't seem to find a way to implement "Metering Pulse" procedure > >>>>> >defined for some R2 variants using ether bcas or R2 packages? For > >>>>> >example, one of the definitions of such a pulse is a "seizure ack" > >>>>> >pulse from a terminating end on a circuit in connected/answer state. > >>>>> > > >>>>> >[Kushanava] Metering is not specific to R2. It may be present in any > >>>>> >CAS signaling. Moreover not all flavours of R2 permit metering to be > >>>>> >mandatory. There should be therefore a general philosophy of > >>>>> attacking > >>>>> >this problem common to all CAS signaling. The solution should be > >>>>> >sensitive to > >>>>> >a) Realizing that MGC is the master for collecting and generating > >>>>> charging > >>>>> >information > >>>>> >b) Interworking of the CAS "metering pulse" signals with other > >>>>> signaling > >>>>> >(both PDN and PSTN) > >>>>> >c) Optimizing the network traffic if metering information is > >>>>> transported to > >>>>> > >>>>> >and fro between MGC and MG > >>>>> >d) Latency, if metering information is transported to and fro > >>>>> between MGC > >>>>> >and MG > >>>>> >We are working towards a separate package that addresses this issue. > >>>>> >Any suggestions? > >>>>> ... > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >This email and any files transmitted with it are confidential and intended >solely for the use of the individual or entity to whom they are >addressed. If you are not the intended recipient you are notified that >disclosing, copying, distributing or taking any action in reliance on the >contents of this information is strictly prohibited. If you have received >this email in error please notify the sender and delete the email. > >Santera, a Tekelec Company >http://www.santera.com >972-461-4100 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri Oct 3 14:02:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18654 for ; Fri, 3 Oct 2003 14:02:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5UFg-0002kX-U4 for megaco-archive@odin.ietf.org; Fri, 03 Oct 2003 14:02:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93I24eH010566 for megaco-archive@odin.ietf.org; Fri, 3 Oct 2003 14:02:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5UFg-0002kL-Q1 for megaco-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 14:02:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18631 for ; Fri, 3 Oct 2003 14:01:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5UFe-0004J7-00 for megaco-web-archive@ietf.org; Fri, 03 Oct 2003 14:02:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5UFd-0004J4-00 for megaco-web-archive@ietf.org; Fri, 03 Oct 2003 14:02:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5UFd-0002jl-P9; Fri, 03 Oct 2003 14:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5UFU-0002jU-Ru for megaco@optimus.ietf.org; Fri, 03 Oct 2003 14:01:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18624 for ; Fri, 3 Oct 2003 14:01:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5UFS-0004Iw-00 for megaco@ietf.org; Fri, 03 Oct 2003 14:01:50 -0400 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1A5UFR-0004It-00 for megaco@ietf.org; Fri, 03 Oct 2003 14:01:49 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id h93I1jgV028581; Fri, 3 Oct 2003 11:01:46 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id h93I1iSu025102; Fri, 3 Oct 2003 13:01:44 -0500 Message-Id: <5.2.1.1.0.20031003131529.00b13d50@IL06EXM13.corp.mot.com> X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 03 Oct 2003 13:56:27 -0400 To: "Soncodi, Adrian", From: Aleksandr Ryabin Subject: RE: [Megaco] CAS Metering Pulse support Cc: "Kevin Boyle", "Christian Groves" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Proposed new metd package will have functionality described in 1). However I have a slightly different proposal for relaying. In order to relay pulses all needed to be known is a repetition interval, changes to it, if any, and when to start, and stop metering pulses. If "receiving" MGC (the one that controls MG which receives metering pulses) gets notified with this information using new metd package then it can relay this information to "generating" MGC (the one that controls MG which generates metering pulses). Then "generating" MGC can use amet to start/stop, or modify generation of metering pulses. That is in reality, if repetition interval does not change during the call, "receiving" MGC will get only two notifies per call: first pulse detected, repetition interval calculated (e.g. second pulse detected) "Generating" MGC will need to send tree modifies: pulse once (when first pulse detected event is relayed) pulse forever (when repetition interval received) stop pulse generation (when call terminates) Regards, Aleks At 01:12 PM 10/3/2003, Soncodi, Adrian wrote: >In some countries a tandem switch is required to propagate meter pulses >(backwards) from the outgoing R2 trunk to the incoming R2 trunk. These >pulses are used for billing. A potential problem is that the pulse rate >may be very high, sometimes it can be a sub-second interval. Therefore, a >tandem MGC which has a considerable number of R2 trunks will have a big >overhead for propagating meter pulses, which will affect its call >processing rate. > >So I'm wondering if anything can be done about this. Here are two >possibilities: > >1) Allow the MG to detect meter pulses but report them in chunks of N. By >default, N=1 (report every pulse), but the MGC could also select, say, >N=10, in which case the MG reports once every 10 pulses. (A residual pulse >count could be reported on Subtract). This method saves a lot of NTFY >messages. However, on the other side, the MGC would be forced to propagate >the pulses as bursts-of-N, and I am not sure a switch is allowed to >transform constant-rate pulsing into bursts. (On the other hand why not? >because it's only the total pulse count that is relevant for charging. >Time-of-day periods with higher charging rates actually result in more >meter pulses.) > >2) Define a mode which allows the meter pulses to be propagated directly >between MGs, without MGC involvement, i.e. by a method similar to RFC2833. >RFC2833 does not currently have an event defined for meter pulses, but it >could be extended, since it defines a lot of signaling-related tones >anyway. In addition to solving the NTFY messaging overhead, this method >would have the side benefit that it would also work between two MGCs that >use SIP or BICC between them. Currently, there is no way to transport >meter pulse information in SIP or BICC, and this would have a terrible >overhead anyway. >Of course, the ability to detect meter pulses is still required, because >there is always the possibility that the MGC must perform the >meter-pulse-based charging itself (rather than propagate). > >Any other ideas or comments? > >Adrian Soncodi > > > >-----Original Message----- >From: Christian Groves [mailto:Christian.Groves@ericsson.com.au] >Sent: Thursday, October 02, 2003 10:38 PM >To: Aleksandr Ryabin >Cc: megaco@ietf.org; Kevin Boyle >Subject: Re: [Megaco] CAS Metering Pulse support > > >Hello Aleksandr, > >I'm happy enough to have the your proposed amendment if the editor agrees. > >Regards, Christian > >Aleksandr Ryabin wrote: > > Hi Christian, > > > > No description of the event does say how to use it for detection > > incoming metering pulse. More over it explicitly limits to generation: > > "This event is used in conjunction with the "enable metering" and > > "metering pulse burst" signals defined in this package..." > > > > My point being that descriptions of amet events and statistics > > are siting that event pr is generated and statistics are changed > > only based on previously applied em, or mbp signal. > > > > The wording needs to be amended to cover the cases when event > > is generated and statistics are changed as a result *detection* of > > incoming metering pulse. > > > > That is, for example, the text you have referenced should be changed > > to something like this (I've placed the changes in [] for visibility): > > > > "If following the application [or detection] of any metering pulse > > (regardless > > of [whether it was detected, or] whether it was generated as a result > > of the signal em or as a result of the signal mbp), the EventsDescriptor > > contains the event pr, and if the value of pcslr is equal to the value > > of the > > EventsDescriptor parameter rp, then the pr event shall be notified, and > > the value of the statistic pcslr shall be reset to zero. The detection of > > the event pr shall not cause the termination of the signal em or the > > signal mbp, [if currently active,] even if the KeepActive flag is not > > set for the pr event." > > > > Regards, > > Aleks > > > > At 07:46 PM 10/2/2003, Christian Groves wrote: > > > >> Hello Aleksandr, > >> > >> I agree that no new package is needed for the detection of metering > >> pulse functionality. From the description of the event it seems that > >> it clear how it to be used. > >> > >> The package also contains the procedural text: > >> "If following the application of any metering pulse (regardless of > >> whether it was generated as a result of the signal em or as a result > >> of the signal mbp), the EventsDescriptor contains the event pr, and if > >> the value of pcslr is equal to the value of the EventsDescriptor > >> parameter rp, then the pr event shall be notified, and the value of > >> the statistic pcslr shall be reset to zero. The detection of the > >> event pr shall not cause the termination of the signal em or the > >> signal mbp, even if the KeepActive flag is not set for the pr event." > >> > >> Is this text sufficient? > >> > >> Regards, Christian > >> > >> Aleksandr Ryabin wrote: > >> > >>> Hi, > >>> In continuation to this metering pulse support. > >>> I've looked through amet package and it does not seem to > >>> define procedure to detect metering pulses, it only has > >>> a procedure to generate metering pulses. > >>> I see no reason of defining a new package for detecting incoming > >>> metering pulses and I propose to reuse amet and amend it to > >>> define procedure for detecting incoming metering pulses. > >>> Here is the summary of a proposed metering pulse detection > >>> procedure using amet package: > >>> The detection of metering pulse on a termination could be enabled > >>> by MGC when no amet signals are played on a termination by > >>> requesting detection amet/pr event with a required repetition period. > >>> MG would Notify MGC with amet/pr event when number of metering > >>> pulses is detected according to repetition period parameter set. > >>> On Subtract, or explicit AuditValue MG would send amet/cpc > >>> and amet/pcslr statistics similar to as described in the package > >>> provided their description extended to detection as well. > >>> Comments? > >>> Thanks > >>> Aleks > >>> BTW IANA MEGACO page is still not updated. > >>> At 10:50 AM 9/16/2003, Aleksandr Ryabin wrote: > >>> > >>>> It is updated with H.248.22 and 25, but not with 23, 24, 26, 27 > >>>> while all of them are dated in ITU the same. Strange. > >>>> Aleks > >>>> > >>>> At 10:46 AM 9/16/2003, Kevin Boyle wrote: > >>>> > >>>>> If it is NOT updated, that is. (Apparently, it's going to be one of > >>>>> those days!) > >>>>> > >>>>> Kevin > >>>>> > >>>>> -----Original Message----- > >>>>> From: Boyle, Kevin [NCRTP:3Z40:EXCH] > >>>>> Sent: Tuesday, September 16, 2003 10:39 AM > >>>>> To: Aleksandr Ryabin; megaco@ietf.org > >>>>> Subject: RE: [Megaco] CAS Metering Pulse support > >>>>> > >>>>> Ummm... yeah. That's what I get for not looking it up before > >>>>> sending the message. :) While amet is defined in the "Extended > >>>>> Analog Lines Packages" doc, there is nothing in the amet package > >>>>> that actually limits it to analog lines. > >>>>> > >>>>> > >>>>> The updates for all the new (as of May) H.248 Sub-series > >>>>> Recommendations have already been requested of IANA. If it is > >>>>> updated by the end of the month, I'll ping them again. > >>>>> > >>>>> > >>>>> Kevin > >>>>> > >>>>> -----Original Message----- > >>>>> From: Aleksandr Ryabin [mailto:kengr@motorola.com] > >>>>> Sent: Tuesday, September 16, 2003 10:32 AM > >>>>> To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org > >>>>> Subject: RE: [Megaco] CAS Metering Pulse support > >>>>> > >>>>> Hi, > >>>>> > >>>>> I guess you meant H.248.26. > >>>>> Yes it seem to address the needs assuming it is extended to digital > >>>>> lines as well. > >>>>> > >>>>> BTW IANA registry should be updated with H.248.26 and H.248.27 > >>>>> http://www.iana.org/assignments/megaco-h248 > >>>>> > >>>>> > >>>>> Thanks, > >>>>> Aleks > >>>>> > >>>>> At 10:00 AM 9/16/2003, Kevin Boyle wrote: > >>>>> > >>>>> > >>>>> H.248.27 has a metering package (automatic metering package or > >>>>> amet). This package may address your needs. > >>>>> > >>>>> Kevin > >>>>> > >>>>> -----Original Message----- > >>>>> From: Aleksandr Ryabin [mailto:kengr@motorola.com > >>>>> ] > >>>>> Sent: Tuesday, September 16, 2003 9:34 AM > >>>>> To: megaco@ietf.org > >>>>> Subject: [Megaco] CAS Metering Pulse support > >>>>> > >>>>> Hi all, > >>>>> > >>>>> Below are excerpts from a previous exchange related to defining of > >>>>> CAS Metering Pulse procedures in MEGACO. > >>>>> > >>>>> Now that CAS packages related work has been moved to ITU has anyone > >>>>> done and/or planned anything in the direction to define CAS > >>>>> Metering Pulse procedures/package for MEGACO? > >>>>> > >>>>> Thanks > >>>>> Aleks > >>>>> > >>>>> >From: klaha@hss.hns.com > >>>>> >To: Aleksandr Ryabin > >>>>> >cc: vnair@hss.hns.com, megaco@ietf.org, klaha@hss.hns.com > >>>>> >Date: Tue, 4 Mar 2003 12:47:37 +0530 > >>>>> >Subject: Re: [Megaco] Re: draft-ietf-megaco-r2package-03.txt : > >>>>> Difference > >>>>> > from previous revision > >>>>> ... > >>>>> >Aleksandr Ryabin on 03/03/2003 10:43:20 PM > >>>>> ... > >>>>> >3. I can't seem to find a way to implement "Metering Pulse" procedure > >>>>> >defined for some R2 variants using ether bcas or R2 packages? For > >>>>> >example, one of the definitions of such a pulse is a "seizure ack" > >>>>> >pulse from a terminating end on a circuit in connected/answer state. > >>>>> > > >>>>> >[Kushanava] Metering is not specific to R2. It may be present in any > >>>>> >CAS signaling. Moreover not all flavours of R2 permit metering to be > >>>>> >mandatory. There should be therefore a general philosophy of > >>>>> attacking > >>>>> >this problem common to all CAS signaling. The solution should be > >>>>> >sensitive to > >>>>> >a) Realizing that MGC is the master for collecting and generating > >>>>> charging > >>>>> >information > >>>>> >b) Interworking of the CAS "metering pulse" signals with other > >>>>> signaling > >>>>> >(both PDN and PSTN) > >>>>> >c) Optimizing the network traffic if metering information is > >>>>> transported to > >>>>> > >>>>> >and fro between MGC and MG > >>>>> >d) Latency, if metering information is transported to and fro > >>>>> between MGC > >>>>> >and MG > >>>>> >We are working towards a separate package that addresses this issue. > >>>>> >Any suggestions? > >>>>> ... > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >This email and any files transmitted with it are confidential and intended >solely for the use of the individual or entity to whom they are >addressed. If you are not the intended recipient you are notified that >disclosing, copying, distributing or taking any action in reliance on the >contents of this information is strictly prohibited. If you have received >this email in error please notify the sender and delete the email. > >Santera, a Tekelec Company >http://www.santera.com >972-461-4100 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Oct 3 14:46:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20048 for ; Fri, 3 Oct 2003 14:46:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5UwE-0004wi-Ax; Fri, 03 Oct 2003 14:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5UvI-0004ud-RJ for megaco@optimus.ietf.org; Fri, 03 Oct 2003 14:45:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20007 for ; Fri, 3 Oct 2003 14:44:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5UvG-0004jL-00 for megaco@ietf.org; Fri, 03 Oct 2003 14:45:02 -0400 Received: from exchange.santera.com ([4.22.157.11] helo=excalibur.santera.com) by ietf-mx with smtp (Exim 4.12) id 1A5UvE-0004iH-00 for megaco@ietf.org; Fri, 03 Oct 2003 14:45:01 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: normal Priority: normal Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Megaco] CAS Metering Pulse support Date: Fri, 3 Oct 2003 13:44:20 -0500 Message-ID: Thread-Topic: [Megaco] CAS Metering Pulse support thread-index: AcOJ2HC3lIPvhFW+RgiWDPhlBBRjwgAAc3uA From: "Soncodi, Adrian" To: "Aleksandr Ryabin" , Cc: "Kevin Boyle" , "Christian Groves" Content-Transfer-Encoding: quoted-printable Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable The pulse rate can change during the call. This is done by the switch = downstream, which is the TAX office, and which changes the rate based on = time-of-day and provisioned charge rates. This means that the receiving = MG would also neeed an event for pulse rate change. A little more = overhead will occur, but I guess it is acceptable. However, it becomes = delicate when the pulse rate decreases: by the time the receiving MG = detects the lower pulse rate, the generating MG has already generated a = number of extra pulses, based on the higher rate. With some effort = though, one could make this work. But I don't understand how the meter pulse rate can be relayed between 2 = MGCs that talk SIP, for example in the following tandem-replacement = solution: Local office - R2 - (MG1, MGC1) - SIP - (MGC2, MG2) - R2 - TAX office I think an RFC2833-based solution causes less headache. But registering = a new RFC2833 event is outside the scope of the MEGACO working group = anyway. For registered events, the ability to negotiate the = 'telephone-event' codec is already available via MEGACO/SDP. Adrian Soncodi -----Original Message----- From: Aleksandr Ryabin [mailto:kengr@motorola.com] Sent: Friday, October 03, 2003 12:56 PM To: Soncodi, Adrian; megaco@ietf.org Cc: Kevin Boyle; Christian Groves Subject: RE: [Megaco] CAS Metering Pulse support Proposed new metd package will have functionality described in 1). However I have a slightly different proposal for relaying. In order to relay pulses all needed to be known is a repetition = interval, changes to it, if any, and when to start, and stop metering pulses. If "receiving" MGC (the one that controls MG which receives metering pulses) gets notified with this information using new metd package then it can relay this information to "generating" MGC (the one that controls MG which generates metering pulses). Then "generating" MGC can use amet to start/stop, or modify generation of metering pulses. That is in reality, if repetition interval does not change during the call, "receiving" MGC will get only two notifies per call: first pulse detected, repetition interval calculated (e.g. second pulse detected) "Generating" MGC will need to send tree modifies: pulse once (when first pulse detected event is relayed) pulse forever (when repetition interval received) stop pulse generation (when call terminates) Regards, Aleks At 01:12 PM 10/3/2003, Soncodi, Adrian wrote: >In some countries a tandem switch is required to propagate meter pulses = >(backwards) from the outgoing R2 trunk to the incoming R2 trunk. These=20 >pulses are used for billing. A potential problem is that the pulse rate = >may be very high, sometimes it can be a sub-second interval. Therefore, = a=20 >tandem MGC which has a considerable number of R2 trunks will have a big = >overhead for propagating meter pulses, which will affect its call=20 >processing rate. > >So I'm wondering if anything can be done about this. Here are two=20 >possibilities: > >1) Allow the MG to detect meter pulses but report them in chunks of N. = By=20 >default, N=3D1 (report every pulse), but the MGC could also select, = say,=20 >N=3D10, in which case the MG reports once every 10 pulses. (A residual = pulse=20 >count could be reported on Subtract). This method saves a lot of NTFY=20 >messages. However, on the other side, the MGC would be forced to = propagate=20 >the pulses as bursts-of-N, and I am not sure a switch is allowed to=20 >transform constant-rate pulsing into bursts. (On the other hand why = not?=20 >because it's only the total pulse count that is relevant for charging.=20 >Time-of-day periods with higher charging rates actually result in more=20 >meter pulses.) > >2) Define a mode which allows the meter pulses to be propagated = directly=20 >between MGs, without MGC involvement, i.e. by a method similar to = RFC2833.=20 >RFC2833 does not currently have an event defined for meter pulses, but = it=20 >could be extended, since it defines a lot of signaling-related tones=20 >anyway. In addition to solving the NTFY messaging overhead, this method = >would have the side benefit that it would also work between two MGCs = that=20 >use SIP or BICC between them. Currently, there is no way to transport=20 >meter pulse information in SIP or BICC, and this would have a terrible=20 >overhead anyway. >Of course, the ability to detect meter pulses is still required, = because=20 >there is always the possibility that the MGC must perform the=20 >meter-pulse-based charging itself (rather than propagate). > >Any other ideas or comments? > >Adrian Soncodi > > > >-----Original Message----- >From: Christian Groves [mailto:Christian.Groves@ericsson.com.au] >Sent: Thursday, October 02, 2003 10:38 PM >To: Aleksandr Ryabin >Cc: megaco@ietf.org; Kevin Boyle >Subject: Re: [Megaco] CAS Metering Pulse support > > >Hello Aleksandr, > >I'm happy enough to have the your proposed amendment if the editor = agrees. > >Regards, Christian > >Aleksandr Ryabin wrote: > > Hi Christian, > > > > No description of the event does say how to use it for detection > > incoming metering pulse. More over it explicitly limits to = generation: > > "This event is used in conjunction with the "enable metering" and > > "metering pulse burst" signals defined in this package..." > > > > My point being that descriptions of amet events and statistics > > are siting that event pr is generated and statistics are changed > > only based on previously applied em, or mbp signal. > > > > The wording needs to be amended to cover the cases when event > > is generated and statistics are changed as a result *detection* of > > incoming metering pulse. > > > > That is, for example, the text you have referenced should be changed > > to something like this (I've placed the changes in [] for = visibility): > > > > "If following the application [or detection] of any metering pulse > > (regardless > > of [whether it was detected, or] whether it was generated as a = result > > of the signal em or as a result of the signal mbp), the = EventsDescriptor > > contains the event pr, and if the value of pcslr is equal to the = value > > of the > > EventsDescriptor parameter rp, then the pr event shall be notified, = and > > the value of the statistic pcslr shall be reset to zero. The = detection of > > the event pr shall not cause the termination of the signal em or the > > signal mbp, [if currently active,] even if the KeepActive flag is = not > > set for the pr event." > > > > Regards, > > Aleks > > > > At 07:46 PM 10/2/2003, Christian Groves wrote: > > > >> Hello Aleksandr, > >> > >> I agree that no new package is needed for the detection of metering > >> pulse functionality. From the description of the event it seems = that > >> it clear how it to be used. > >> > >> The package also contains the procedural text: > >> "If following the application of any metering pulse (regardless of > >> whether it was generated as a result of the signal em or as a = result > >> of the signal mbp), the EventsDescriptor contains the event pr, and = if > >> the value of pcslr is equal to the value of the EventsDescriptor > >> parameter rp, then the pr event shall be notified, and the value of > >> the statistic pcslr shall be reset to zero. The detection of the > >> event pr shall not cause the termination of the signal em or the > >> signal mbp, even if the KeepActive flag is not set for the pr = event." > >> > >> Is this text sufficient? > >> > >> Regards, Christian > >> > >> Aleksandr Ryabin wrote: > >> > >>> Hi, > >>> In continuation to this metering pulse support. > >>> I've looked through amet package and it does not seem to > >>> define procedure to detect metering pulses, it only has > >>> a procedure to generate metering pulses. > >>> I see no reason of defining a new package for detecting incoming > >>> metering pulses and I propose to reuse amet and amend it to > >>> define procedure for detecting incoming metering pulses. > >>> Here is the summary of a proposed metering pulse detection > >>> procedure using amet package: > >>> The detection of metering pulse on a termination could be enabled > >>> by MGC when no amet signals are played on a termination by > >>> requesting detection amet/pr event with a required repetition = period. > >>> MG would Notify MGC with amet/pr event when number of metering > >>> pulses is detected according to repetition period parameter set. > >>> On Subtract, or explicit AuditValue MG would send amet/cpc > >>> and amet/pcslr statistics similar to as described in the package > >>> provided their description extended to detection as well. > >>> Comments? > >>> Thanks > >>> Aleks > >>> BTW IANA MEGACO page is still not updated. > >>> At 10:50 AM 9/16/2003, Aleksandr Ryabin wrote: > >>> > >>>> It is updated with H.248.22 and 25, but not with 23, 24, 26, 27 > >>>> while all of them are dated in ITU the same. Strange. > >>>> Aleks > >>>> > >>>> At 10:46 AM 9/16/2003, Kevin Boyle wrote: > >>>> > >>>>> If it is NOT updated, that is. (Apparently, it's going to be one = of > >>>>> those days!) > >>>>> > >>>>> Kevin > >>>>> > >>>>> -----Original Message----- > >>>>> From: Boyle, Kevin [NCRTP:3Z40:EXCH] > >>>>> Sent: Tuesday, September 16, 2003 10:39 AM > >>>>> To: Aleksandr Ryabin; megaco@ietf.org > >>>>> Subject: RE: [Megaco] CAS Metering Pulse support > >>>>> > >>>>> Ummm... yeah. That's what I get for not looking it up before > >>>>> sending the message. :) While amet is defined in the "Extended > >>>>> Analog Lines Packages" doc, there is nothing in the amet package > >>>>> that actually limits it to analog lines. > >>>>> > >>>>> > >>>>> The updates for all the new (as of May) H.248 Sub-series > >>>>> Recommendations have already been requested of IANA. If it is > >>>>> updated by the end of the month, I'll ping them again. > >>>>> > >>>>> > >>>>> Kevin > >>>>> > >>>>> -----Original Message----- > >>>>> From: Aleksandr Ryabin [mailto:kengr@motorola.com] > >>>>> Sent: Tuesday, September 16, 2003 10:32 AM > >>>>> To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org > >>>>> Subject: RE: [Megaco] CAS Metering Pulse support > >>>>> > >>>>> Hi, > >>>>> > >>>>> I guess you meant H.248.26. > >>>>> Yes it seem to address the needs assuming it is extended to = digital > >>>>> lines as well. > >>>>> > >>>>> BTW IANA registry should be updated with H.248.26 and H.248.27 > >>>>> http://www.iana.org/assignments/megaco-h248 > >>>>> > >>>>> > >>>>> Thanks, > >>>>> Aleks > >>>>> > >>>>> At 10:00 AM 9/16/2003, Kevin Boyle wrote: > >>>>> > >>>>> > >>>>> H.248.27 has a metering package (automatic metering package or > >>>>> amet). This package may address your needs. > >>>>> > >>>>> Kevin > >>>>> > >>>>> -----Original Message----- > >>>>> From: Aleksandr Ryabin [mailto:kengr@motorola.com > >>>>> ] > >>>>> Sent: Tuesday, September 16, 2003 9:34 AM > >>>>> To: megaco@ietf.org > >>>>> Subject: [Megaco] CAS Metering Pulse support > >>>>> > >>>>> Hi all, > >>>>> > >>>>> Below are excerpts from a previous exchange related to defining = of > >>>>> CAS Metering Pulse procedures in MEGACO. > >>>>> > >>>>> Now that CAS packages related work has been moved to ITU has = anyone > >>>>> done and/or planned anything in the direction to define CAS > >>>>> Metering Pulse procedures/package for MEGACO? > >>>>> > >>>>> Thanks > >>>>> Aleks > >>>>> > >>>>> >From: klaha@hss.hns.com > >>>>> >To: Aleksandr Ryabin > >>>>> >cc: vnair@hss.hns.com, megaco@ietf.org, klaha@hss.hns.com > >>>>> >Date: Tue, 4 Mar 2003 12:47:37 +0530 > >>>>> >Subject: Re: [Megaco] Re: draft-ietf-megaco-r2package-03.txt : > >>>>> Difference > >>>>> > from previous revision > >>>>> ... > >>>>> >Aleksandr Ryabin on 03/03/2003 10:43:20 = PM > >>>>> ... > >>>>> >3. I can't seem to find a way to implement "Metering Pulse" = procedure > >>>>> >defined for some R2 variants using ether bcas or R2 packages? = For > >>>>> >example, one of the definitions of such a pulse is a "seizure = ack" > >>>>> >pulse from a terminating end on a circuit in connected/answer = state. > >>>>> > > >>>>> >[Kushanava] Metering is not specific to R2. It may be present = in any > >>>>> >CAS signaling. Moreover not all flavours of R2 permit metering = to be > >>>>> >mandatory. There should be therefore a general philosophy of > >>>>> attacking > >>>>> >this problem common to all CAS signaling. The solution should = be > >>>>> >sensitive to > >>>>> >a) Realizing that MGC is the master for collecting and = generating > >>>>> charging > >>>>> >information > >>>>> >b) Interworking of the CAS "metering pulse" signals with other > >>>>> signaling > >>>>> >(both PDN and PSTN) > >>>>> >c) Optimizing the network traffic if metering information is > >>>>> transported to > >>>>> > >>>>> >and fro between MGC and MG > >>>>> >d) Latency, if metering information is transported to and fro > >>>>> between MGC > >>>>> >and MG > >>>>> >We are working towards a separate package that addresses this = issue. > >>>>> >Any suggestions? > >>>>> ... > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >This email and any files transmitted with it are confidential and = intended=20 >solely for the use of the individual or entity to whom they are=20 >addressed. If you are not the intended recipient you are notified that = >disclosing, copying, distributing or taking any action in reliance on = the=20 >contents of this information is strictly prohibited. If you have = received=20 >this email in error please notify the sender and delete the email. > >Santera, a Tekelec Company >http://www.santera.com >972-461-4100 This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you are not the intended recipient you are notified that = disclosing, copying, distributing or taking any action in reliance on = the contents of this information is strictly prohibited. If you have = received this email in error please notify the sender and delete the = email.=20 Santera, a Tekelec Company http://www.santera.com 972-461-4100 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri Oct 3 14:46:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20063 for ; Fri, 3 Oct 2003 14:46:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5UwN-0004yK-3E for megaco-archive@odin.ietf.org; Fri, 03 Oct 2003 14:46:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93IkBUD019106 for megaco-archive@odin.ietf.org; Fri, 3 Oct 2003 14:46:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5UwM-0004y5-Uz for megaco-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 14:46:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20035 for ; Fri, 3 Oct 2003 14:46:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5UwK-0004k7-00 for megaco-web-archive@ietf.org; Fri, 03 Oct 2003 14:46:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5UwJ-0004k4-00 for megaco-web-archive@ietf.org; Fri, 03 Oct 2003 14:46:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5UwE-0004wi-Ax; Fri, 03 Oct 2003 14:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5UvI-0004ud-RJ for megaco@optimus.ietf.org; Fri, 03 Oct 2003 14:45:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20007 for ; Fri, 3 Oct 2003 14:44:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5UvG-0004jL-00 for megaco@ietf.org; Fri, 03 Oct 2003 14:45:02 -0400 Received: from exchange.santera.com ([4.22.157.11] helo=excalibur.santera.com) by ietf-mx with smtp (Exim 4.12) id 1A5UvE-0004iH-00 for megaco@ietf.org; Fri, 03 Oct 2003 14:45:01 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: normal Priority: normal Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Megaco] CAS Metering Pulse support Date: Fri, 3 Oct 2003 13:44:20 -0500 Message-ID: Thread-Topic: [Megaco] CAS Metering Pulse support thread-index: AcOJ2HC3lIPvhFW+RgiWDPhlBBRjwgAAc3uA From: "Soncodi, Adrian" To: "Aleksandr Ryabin" , Cc: "Kevin Boyle" , "Christian Groves" Content-Transfer-Encoding: quoted-printable Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable The pulse rate can change during the call. This is done by the switch = downstream, which is the TAX office, and which changes the rate based on = time-of-day and provisioned charge rates. This means that the receiving = MG would also neeed an event for pulse rate change. A little more = overhead will occur, but I guess it is acceptable. However, it becomes = delicate when the pulse rate decreases: by the time the receiving MG = detects the lower pulse rate, the generating MG has already generated a = number of extra pulses, based on the higher rate. With some effort = though, one could make this work. But I don't understand how the meter pulse rate can be relayed between 2 = MGCs that talk SIP, for example in the following tandem-replacement = solution: Local office - R2 - (MG1, MGC1) - SIP - (MGC2, MG2) - R2 - TAX office I think an RFC2833-based solution causes less headache. But registering = a new RFC2833 event is outside the scope of the MEGACO working group = anyway. For registered events, the ability to negotiate the = 'telephone-event' codec is already available via MEGACO/SDP. Adrian Soncodi -----Original Message----- From: Aleksandr Ryabin [mailto:kengr@motorola.com] Sent: Friday, October 03, 2003 12:56 PM To: Soncodi, Adrian; megaco@ietf.org Cc: Kevin Boyle; Christian Groves Subject: RE: [Megaco] CAS Metering Pulse support Proposed new metd package will have functionality described in 1). However I have a slightly different proposal for relaying. In order to relay pulses all needed to be known is a repetition = interval, changes to it, if any, and when to start, and stop metering pulses. If "receiving" MGC (the one that controls MG which receives metering pulses) gets notified with this information using new metd package then it can relay this information to "generating" MGC (the one that controls MG which generates metering pulses). Then "generating" MGC can use amet to start/stop, or modify generation of metering pulses. That is in reality, if repetition interval does not change during the call, "receiving" MGC will get only two notifies per call: first pulse detected, repetition interval calculated (e.g. second pulse detected) "Generating" MGC will need to send tree modifies: pulse once (when first pulse detected event is relayed) pulse forever (when repetition interval received) stop pulse generation (when call terminates) Regards, Aleks At 01:12 PM 10/3/2003, Soncodi, Adrian wrote: >In some countries a tandem switch is required to propagate meter pulses = >(backwards) from the outgoing R2 trunk to the incoming R2 trunk. These=20 >pulses are used for billing. A potential problem is that the pulse rate = >may be very high, sometimes it can be a sub-second interval. Therefore, = a=20 >tandem MGC which has a considerable number of R2 trunks will have a big = >overhead for propagating meter pulses, which will affect its call=20 >processing rate. > >So I'm wondering if anything can be done about this. Here are two=20 >possibilities: > >1) Allow the MG to detect meter pulses but report them in chunks of N. = By=20 >default, N=3D1 (report every pulse), but the MGC could also select, = say,=20 >N=3D10, in which case the MG reports once every 10 pulses. (A residual = pulse=20 >count could be reported on Subtract). This method saves a lot of NTFY=20 >messages. However, on the other side, the MGC would be forced to = propagate=20 >the pulses as bursts-of-N, and I am not sure a switch is allowed to=20 >transform constant-rate pulsing into bursts. (On the other hand why = not?=20 >because it's only the total pulse count that is relevant for charging.=20 >Time-of-day periods with higher charging rates actually result in more=20 >meter pulses.) > >2) Define a mode which allows the meter pulses to be propagated = directly=20 >between MGs, without MGC involvement, i.e. by a method similar to = RFC2833.=20 >RFC2833 does not currently have an event defined for meter pulses, but = it=20 >could be extended, since it defines a lot of signaling-related tones=20 >anyway. In addition to solving the NTFY messaging overhead, this method = >would have the side benefit that it would also work between two MGCs = that=20 >use SIP or BICC between them. Currently, there is no way to transport=20 >meter pulse information in SIP or BICC, and this would have a terrible=20 >overhead anyway. >Of course, the ability to detect meter pulses is still required, = because=20 >there is always the possibility that the MGC must perform the=20 >meter-pulse-based charging itself (rather than propagate). > >Any other ideas or comments? > >Adrian Soncodi > > > >-----Original Message----- >From: Christian Groves [mailto:Christian.Groves@ericsson.com.au] >Sent: Thursday, October 02, 2003 10:38 PM >To: Aleksandr Ryabin >Cc: megaco@ietf.org; Kevin Boyle >Subject: Re: [Megaco] CAS Metering Pulse support > > >Hello Aleksandr, > >I'm happy enough to have the your proposed amendment if the editor = agrees. > >Regards, Christian > >Aleksandr Ryabin wrote: > > Hi Christian, > > > > No description of the event does say how to use it for detection > > incoming metering pulse. More over it explicitly limits to = generation: > > "This event is used in conjunction with the "enable metering" and > > "metering pulse burst" signals defined in this package..." > > > > My point being that descriptions of amet events and statistics > > are siting that event pr is generated and statistics are changed > > only based on previously applied em, or mbp signal. > > > > The wording needs to be amended to cover the cases when event > > is generated and statistics are changed as a result *detection* of > > incoming metering pulse. > > > > That is, for example, the text you have referenced should be changed > > to something like this (I've placed the changes in [] for = visibility): > > > > "If following the application [or detection] of any metering pulse > > (regardless > > of [whether it was detected, or] whether it was generated as a = result > > of the signal em or as a result of the signal mbp), the = EventsDescriptor > > contains the event pr, and if the value of pcslr is equal to the = value > > of the > > EventsDescriptor parameter rp, then the pr event shall be notified, = and > > the value of the statistic pcslr shall be reset to zero. The = detection of > > the event pr shall not cause the termination of the signal em or the > > signal mbp, [if currently active,] even if the KeepActive flag is = not > > set for the pr event." > > > > Regards, > > Aleks > > > > At 07:46 PM 10/2/2003, Christian Groves wrote: > > > >> Hello Aleksandr, > >> > >> I agree that no new package is needed for the detection of metering > >> pulse functionality. From the description of the event it seems = that > >> it clear how it to be used. > >> > >> The package also contains the procedural text: > >> "If following the application of any metering pulse (regardless of > >> whether it was generated as a result of the signal em or as a = result > >> of the signal mbp), the EventsDescriptor contains the event pr, and = if > >> the value of pcslr is equal to the value of the EventsDescriptor > >> parameter rp, then the pr event shall be notified, and the value of > >> the statistic pcslr shall be reset to zero. The detection of the > >> event pr shall not cause the termination of the signal em or the > >> signal mbp, even if the KeepActive flag is not set for the pr = event." > >> > >> Is this text sufficient? > >> > >> Regards, Christian > >> > >> Aleksandr Ryabin wrote: > >> > >>> Hi, > >>> In continuation to this metering pulse support. > >>> I've looked through amet package and it does not seem to > >>> define procedure to detect metering pulses, it only has > >>> a procedure to generate metering pulses. > >>> I see no reason of defining a new package for detecting incoming > >>> metering pulses and I propose to reuse amet and amend it to > >>> define procedure for detecting incoming metering pulses. > >>> Here is the summary of a proposed metering pulse detection > >>> procedure using amet package: > >>> The detection of metering pulse on a termination could be enabled > >>> by MGC when no amet signals are played on a termination by > >>> requesting detection amet/pr event with a required repetition = period. > >>> MG would Notify MGC with amet/pr event when number of metering > >>> pulses is detected according to repetition period parameter set. > >>> On Subtract, or explicit AuditValue MG would send amet/cpc > >>> and amet/pcslr statistics similar to as described in the package > >>> provided their description extended to detection as well. > >>> Comments? > >>> Thanks > >>> Aleks > >>> BTW IANA MEGACO page is still not updated. > >>> At 10:50 AM 9/16/2003, Aleksandr Ryabin wrote: > >>> > >>>> It is updated with H.248.22 and 25, but not with 23, 24, 26, 27 > >>>> while all of them are dated in ITU the same. Strange. > >>>> Aleks > >>>> > >>>> At 10:46 AM 9/16/2003, Kevin Boyle wrote: > >>>> > >>>>> If it is NOT updated, that is. (Apparently, it's going to be one = of > >>>>> those days!) > >>>>> > >>>>> Kevin > >>>>> > >>>>> -----Original Message----- > >>>>> From: Boyle, Kevin [NCRTP:3Z40:EXCH] > >>>>> Sent: Tuesday, September 16, 2003 10:39 AM > >>>>> To: Aleksandr Ryabin; megaco@ietf.org > >>>>> Subject: RE: [Megaco] CAS Metering Pulse support > >>>>> > >>>>> Ummm... yeah. That's what I get for not looking it up before > >>>>> sending the message. :) While amet is defined in the "Extended > >>>>> Analog Lines Packages" doc, there is nothing in the amet package > >>>>> that actually limits it to analog lines. > >>>>> > >>>>> > >>>>> The updates for all the new (as of May) H.248 Sub-series > >>>>> Recommendations have already been requested of IANA. If it is > >>>>> updated by the end of the month, I'll ping them again. > >>>>> > >>>>> > >>>>> Kevin > >>>>> > >>>>> -----Original Message----- > >>>>> From: Aleksandr Ryabin [mailto:kengr@motorola.com] > >>>>> Sent: Tuesday, September 16, 2003 10:32 AM > >>>>> To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org > >>>>> Subject: RE: [Megaco] CAS Metering Pulse support > >>>>> > >>>>> Hi, > >>>>> > >>>>> I guess you meant H.248.26. > >>>>> Yes it seem to address the needs assuming it is extended to = digital > >>>>> lines as well. > >>>>> > >>>>> BTW IANA registry should be updated with H.248.26 and H.248.27 > >>>>> http://www.iana.org/assignments/megaco-h248 > >>>>> > >>>>> > >>>>> Thanks, > >>>>> Aleks > >>>>> > >>>>> At 10:00 AM 9/16/2003, Kevin Boyle wrote: > >>>>> > >>>>> > >>>>> H.248.27 has a metering package (automatic metering package or > >>>>> amet). This package may address your needs. > >>>>> > >>>>> Kevin > >>>>> > >>>>> -----Original Message----- > >>>>> From: Aleksandr Ryabin [mailto:kengr@motorola.com > >>>>> ] > >>>>> Sent: Tuesday, September 16, 2003 9:34 AM > >>>>> To: megaco@ietf.org > >>>>> Subject: [Megaco] CAS Metering Pulse support > >>>>> > >>>>> Hi all, > >>>>> > >>>>> Below are excerpts from a previous exchange related to defining = of > >>>>> CAS Metering Pulse procedures in MEGACO. > >>>>> > >>>>> Now that CAS packages related work has been moved to ITU has = anyone > >>>>> done and/or planned anything in the direction to define CAS > >>>>> Metering Pulse procedures/package for MEGACO? > >>>>> > >>>>> Thanks > >>>>> Aleks > >>>>> > >>>>> >From: klaha@hss.hns.com > >>>>> >To: Aleksandr Ryabin > >>>>> >cc: vnair@hss.hns.com, megaco@ietf.org, klaha@hss.hns.com > >>>>> >Date: Tue, 4 Mar 2003 12:47:37 +0530 > >>>>> >Subject: Re: [Megaco] Re: draft-ietf-megaco-r2package-03.txt : > >>>>> Difference > >>>>> > from previous revision > >>>>> ... > >>>>> >Aleksandr Ryabin on 03/03/2003 10:43:20 = PM > >>>>> ... > >>>>> >3. I can't seem to find a way to implement "Metering Pulse" = procedure > >>>>> >defined for some R2 variants using ether bcas or R2 packages? = For > >>>>> >example, one of the definitions of such a pulse is a "seizure = ack" > >>>>> >pulse from a terminating end on a circuit in connected/answer = state. > >>>>> > > >>>>> >[Kushanava] Metering is not specific to R2. It may be present = in any > >>>>> >CAS signaling. Moreover not all flavours of R2 permit metering = to be > >>>>> >mandatory. There should be therefore a general philosophy of > >>>>> attacking > >>>>> >this problem common to all CAS signaling. The solution should = be > >>>>> >sensitive to > >>>>> >a) Realizing that MGC is the master for collecting and = generating > >>>>> charging > >>>>> >information > >>>>> >b) Interworking of the CAS "metering pulse" signals with other > >>>>> signaling > >>>>> >(both PDN and PSTN) > >>>>> >c) Optimizing the network traffic if metering information is > >>>>> transported to > >>>>> > >>>>> >and fro between MGC and MG > >>>>> >d) Latency, if metering information is transported to and fro > >>>>> between MGC > >>>>> >and MG > >>>>> >We are working towards a separate package that addresses this = issue. > >>>>> >Any suggestions? > >>>>> ... > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >This email and any files transmitted with it are confidential and = intended=20 >solely for the use of the individual or entity to whom they are=20 >addressed. If you are not the intended recipient you are notified that = >disclosing, copying, distributing or taking any action in reliance on = the=20 >contents of this information is strictly prohibited. If you have = received=20 >this email in error please notify the sender and delete the email. > >Santera, a Tekelec Company >http://www.santera.com >972-461-4100 This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you are not the intended recipient you are notified that = disclosing, copying, distributing or taking any action in reliance on = the contents of this information is strictly prohibited. If you have = received this email in error please notify the sender and delete the = email.=20 Santera, a Tekelec Company http://www.santera.com 972-461-4100 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Oct 3 15:19:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22502 for ; Fri, 3 Oct 2003 15:19:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5VSA-0006zW-6D; Fri, 03 Oct 2003 15:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5VS4-0006zI-53 for megaco@optimus.ietf.org; Fri, 03 Oct 2003 15:18:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22435 for ; Fri, 3 Oct 2003 15:18:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5VS2-0005BX-00 for megaco@ietf.org; Fri, 03 Oct 2003 15:18:54 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 1A5VS1-0005BU-00 for megaco@ietf.org; Fri, 03 Oct 2003 15:18:53 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h93JImpx007525; Fri, 3 Oct 2003 12:18:49 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id h93JIlSu032196; Fri, 3 Oct 2003 14:18:47 -0500 Message-Id: <5.2.1.1.0.20031003151228.024f8d50@IL06EXM13.corp.mot.com> X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 03 Oct 2003 15:16:17 -0400 To: "Soncodi, Adrian" From: Aleksandr Ryabin Subject: RE: [Megaco] CAS Metering Pulse support Cc: "Aleksandr Ryabin", , "Kevin Boyle", "Christian Groves" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi, How the pulse information is relayed between MGC is out of scope MEGACO. Whatever MGCs use for inter MGC communication will need to support this information. Regards, Aleks At 02:44 PM 10/3/2003, Soncodi, Adrian wrote: >The pulse rate can change during the call. This is done by the switch >downstream, which is the TAX office, and which changes the rate based on >time-of-day and provisioned charge rates. This means that the receiving MG >would also neeed an event for pulse rate change. A little more overhead >will occur, but I guess it is acceptable. However, it becomes delicate >when the pulse rate decreases: by the time the receiving MG detects the >lower pulse rate, the generating MG has already generated a number of >extra pulses, based on the higher rate. With some effort though, one could >make this work. > >But I don't understand how the meter pulse rate can be relayed between 2 >MGCs that talk SIP, for example in the following tandem-replacement solution: > > Local office - R2 - (MG1, MGC1) - SIP - (MGC2, MG2) - R2 - TAX office > >I think an RFC2833-based solution causes less headache. But registering a >new RFC2833 event is outside the scope of the MEGACO working group anyway. >For registered events, the ability to negotiate the 'telephone-event' >codec is already available via MEGACO/SDP. > >Adrian Soncodi > > >-----Original Message----- >From: Aleksandr Ryabin [mailto:kengr@motorola.com] >Sent: Friday, October 03, 2003 12:56 PM >To: Soncodi, Adrian; megaco@ietf.org >Cc: Kevin Boyle; Christian Groves >Subject: RE: [Megaco] CAS Metering Pulse support > > >Proposed new metd package will have functionality described in 1). > >However I have a slightly different proposal for relaying. >In order to relay pulses all needed to be known is a repetition interval, >changes to it, if any, and when to start, and stop metering pulses. > >If "receiving" MGC (the one that controls MG which receives >metering pulses) gets notified with this information using new >metd package then it can relay this information to "generating" >MGC (the one that controls MG which generates metering pulses). >Then "generating" MGC can use amet to start/stop, or modify >generation of metering pulses. > >That is in reality, if repetition interval does not change during >the call, "receiving" MGC will get only two notifies per call: >first pulse detected, >repetition interval calculated (e.g. second pulse detected) > >"Generating" MGC will need to send tree modifies: >pulse once (when first pulse detected event is relayed) >pulse forever (when repetition interval received) >stop pulse generation (when call terminates) > >Regards, > Aleks > >At 01:12 PM 10/3/2003, Soncodi, Adrian wrote: > >In some countries a tandem switch is required to propagate meter pulses > >(backwards) from the outgoing R2 trunk to the incoming R2 trunk. These > >pulses are used for billing. A potential problem is that the pulse rate > >may be very high, sometimes it can be a sub-second interval. Therefore, a > >tandem MGC which has a considerable number of R2 trunks will have a big > >overhead for propagating meter pulses, which will affect its call > >processing rate. > > > >So I'm wondering if anything can be done about this. Here are two > >possibilities: > > > >1) Allow the MG to detect meter pulses but report them in chunks of N. By > >default, N=1 (report every pulse), but the MGC could also select, say, > >N=10, in which case the MG reports once every 10 pulses. (A residual pulse > >count could be reported on Subtract). This method saves a lot of NTFY > >messages. However, on the other side, the MGC would be forced to propagate > >the pulses as bursts-of-N, and I am not sure a switch is allowed to > >transform constant-rate pulsing into bursts. (On the other hand why not? > >because it's only the total pulse count that is relevant for charging. > >Time-of-day periods with higher charging rates actually result in more > >meter pulses.) > > > >2) Define a mode which allows the meter pulses to be propagated directly > >between MGs, without MGC involvement, i.e. by a method similar to RFC2833. > >RFC2833 does not currently have an event defined for meter pulses, but it > >could be extended, since it defines a lot of signaling-related tones > >anyway. In addition to solving the NTFY messaging overhead, this method > >would have the side benefit that it would also work between two MGCs that > >use SIP or BICC between them. Currently, there is no way to transport > >meter pulse information in SIP or BICC, and this would have a terrible > >overhead anyway. > >Of course, the ability to detect meter pulses is still required, because > >there is always the possibility that the MGC must perform the > >meter-pulse-based charging itself (rather than propagate). > > > >Any other ideas or comments? > > > >Adrian Soncodi > > > > > > > >-----Original Message----- > >From: Christian Groves [mailto:Christian.Groves@ericsson.com.au] > >Sent: Thursday, October 02, 2003 10:38 PM > >To: Aleksandr Ryabin > >Cc: megaco@ietf.org; Kevin Boyle > >Subject: Re: [Megaco] CAS Metering Pulse support > > > > > >Hello Aleksandr, > > > >I'm happy enough to have the your proposed amendment if the editor agrees. > > > >Regards, Christian > > > >Aleksandr Ryabin wrote: > > > Hi Christian, > > > > > > No description of the event does say how to use it for detection > > > incoming metering pulse. More over it explicitly limits to generation: > > > "This event is used in conjunction with the "enable metering" and > > > "metering pulse burst" signals defined in this package..." > > > > > > My point being that descriptions of amet events and statistics > > > are siting that event pr is generated and statistics are changed > > > only based on previously applied em, or mbp signal. > > > > > > The wording needs to be amended to cover the cases when event > > > is generated and statistics are changed as a result *detection* of > > > incoming metering pulse. > > > > > > That is, for example, the text you have referenced should be changed > > > to something like this (I've placed the changes in [] for visibility): > > > > > > "If following the application [or detection] of any metering pulse > > > (regardless > > > of [whether it was detected, or] whether it was generated as a result > > > of the signal em or as a result of the signal mbp), the EventsDescriptor > > > contains the event pr, and if the value of pcslr is equal to the value > > > of the > > > EventsDescriptor parameter rp, then the pr event shall be notified, and > > > the value of the statistic pcslr shall be reset to zero. The > detection of > > > the event pr shall not cause the termination of the signal em or the > > > signal mbp, [if currently active,] even if the KeepActive flag is not > > > set for the pr event." > > > > > > Regards, > > > Aleks > > > > > > At 07:46 PM 10/2/2003, Christian Groves wrote: > > > > > >> Hello Aleksandr, > > >> > > >> I agree that no new package is needed for the detection of metering > > >> pulse functionality. From the description of the event it seems that > > >> it clear how it to be used. > > >> > > >> The package also contains the procedural text: > > >> "If following the application of any metering pulse (regardless of > > >> whether it was generated as a result of the signal em or as a result > > >> of the signal mbp), the EventsDescriptor contains the event pr, and if > > >> the value of pcslr is equal to the value of the EventsDescriptor > > >> parameter rp, then the pr event shall be notified, and the value of > > >> the statistic pcslr shall be reset to zero. The detection of the > > >> event pr shall not cause the termination of the signal em or the > > >> signal mbp, even if the KeepActive flag is not set for the pr event." > > >> > > >> Is this text sufficient? > > >> > > >> Regards, Christian > > >> > > >> Aleksandr Ryabin wrote: > > >> > > >>> Hi, > > >>> In continuation to this metering pulse support. > > >>> I've looked through amet package and it does not seem to > > >>> define procedure to detect metering pulses, it only has > > >>> a procedure to generate metering pulses. > > >>> I see no reason of defining a new package for detecting incoming > > >>> metering pulses and I propose to reuse amet and amend it to > > >>> define procedure for detecting incoming metering pulses. > > >>> Here is the summary of a proposed metering pulse detection > > >>> procedure using amet package: > > >>> The detection of metering pulse on a termination could be enabled > > >>> by MGC when no amet signals are played on a termination by > > >>> requesting detection amet/pr event with a required repetition period. > > >>> MG would Notify MGC with amet/pr event when number of metering > > >>> pulses is detected according to repetition period parameter set. > > >>> On Subtract, or explicit AuditValue MG would send amet/cpc > > >>> and amet/pcslr statistics similar to as described in the package > > >>> provided their description extended to detection as well. > > >>> Comments? > > >>> Thanks > > >>> Aleks > > >>> BTW IANA MEGACO page is still not updated. > > >>> At 10:50 AM 9/16/2003, Aleksandr Ryabin wrote: > > >>> > > >>>> It is updated with H.248.22 and 25, but not with 23, 24, 26, 27 > > >>>> while all of them are dated in ITU the same. Strange. > > >>>> Aleks > > >>>> > > >>>> At 10:46 AM 9/16/2003, Kevin Boyle wrote: > > >>>> > > >>>>> If it is NOT updated, that is. (Apparently, it's going to be one of > > >>>>> those days!) > > >>>>> > > >>>>> Kevin > > >>>>> > > >>>>> -----Original Message----- > > >>>>> From: Boyle, Kevin [NCRTP:3Z40:EXCH] > > >>>>> Sent: Tuesday, September 16, 2003 10:39 AM > > >>>>> To: Aleksandr Ryabin; megaco@ietf.org > > >>>>> Subject: RE: [Megaco] CAS Metering Pulse support > > >>>>> > > >>>>> Ummm... yeah. That's what I get for not looking it up before > > >>>>> sending the message. :) While amet is defined in the "Extended > > >>>>> Analog Lines Packages" doc, there is nothing in the amet package > > >>>>> that actually limits it to analog lines. > > >>>>> > > >>>>> > > >>>>> The updates for all the new (as of May) H.248 Sub-series > > >>>>> Recommendations have already been requested of IANA. If it is > > >>>>> updated by the end of the month, I'll ping them again. > > >>>>> > > >>>>> > > >>>>> Kevin > > >>>>> > > >>>>> -----Original Message----- > > >>>>> From: Aleksandr Ryabin [mailto:kengr@motorola.com] > > >>>>> Sent: Tuesday, September 16, 2003 10:32 AM > > >>>>> To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org > > >>>>> Subject: RE: [Megaco] CAS Metering Pulse support > > >>>>> > > >>>>> Hi, > > >>>>> > > >>>>> I guess you meant H.248.26. > > >>>>> Yes it seem to address the needs assuming it is extended to digital > > >>>>> lines as well. > > >>>>> > > >>>>> BTW IANA registry should be updated with H.248.26 and H.248.27 > > >>>>> http://www.iana.org/assignments/megaco-h248 > > >>>>> > > >>>>> > > >>>>> Thanks, > > >>>>> Aleks > > >>>>> > > >>>>> At 10:00 AM 9/16/2003, Kevin Boyle wrote: > > >>>>> > > >>>>> > > >>>>> H.248.27 has a metering package (automatic metering package or > > >>>>> amet). This package may address your needs. > > >>>>> > > >>>>> Kevin > > >>>>> > > >>>>> -----Original Message----- > > >>>>> From: Aleksandr Ryabin [mailto:kengr@motorola.com > > >>>>> ] > > >>>>> Sent: Tuesday, September 16, 2003 9:34 AM > > >>>>> To: megaco@ietf.org > > >>>>> Subject: [Megaco] CAS Metering Pulse support > > >>>>> > > >>>>> Hi all, > > >>>>> > > >>>>> Below are excerpts from a previous exchange related to defining of > > >>>>> CAS Metering Pulse procedures in MEGACO. > > >>>>> > > >>>>> Now that CAS packages related work has been moved to ITU has anyone > > >>>>> done and/or planned anything in the direction to define CAS > > >>>>> Metering Pulse procedures/package for MEGACO? > > >>>>> > > >>>>> Thanks > > >>>>> Aleks > > >>>>> > > >>>>> >From: klaha@hss.hns.com > > >>>>> >To: Aleksandr Ryabin > > >>>>> >cc: vnair@hss.hns.com, megaco@ietf.org, klaha@hss.hns.com > > >>>>> >Date: Tue, 4 Mar 2003 12:47:37 +0530 > > >>>>> >Subject: Re: [Megaco] Re: draft-ietf-megaco-r2package-03.txt : > > >>>>> Difference > > >>>>> > from previous revision > > >>>>> ... > > >>>>> >Aleksandr Ryabin on 03/03/2003 10:43:20 PM > > >>>>> ... > > >>>>> >3. I can't seem to find a way to implement "Metering Pulse" > procedure > > >>>>> >defined for some R2 variants using ether bcas or R2 packages? For > > >>>>> >example, one of the definitions of such a pulse is a "seizure ack" > > >>>>> >pulse from a terminating end on a circuit in connected/answer state. > > >>>>> > > > >>>>> >[Kushanava] Metering is not specific to R2. It may be present in any > > >>>>> >CAS signaling. Moreover not all flavours of R2 permit metering to be > > >>>>> >mandatory. There should be therefore a general philosophy of > > >>>>> attacking > > >>>>> >this problem common to all CAS signaling. The solution should be > > >>>>> >sensitive to > > >>>>> >a) Realizing that MGC is the master for collecting and generating > > >>>>> charging > > >>>>> >information > > >>>>> >b) Interworking of the CAS "metering pulse" signals with other > > >>>>> signaling > > >>>>> >(both PDN and PSTN) > > >>>>> >c) Optimizing the network traffic if metering information is > > >>>>> transported to > > >>>>> > > >>>>> >and fro between MGC and MG > > >>>>> >d) Latency, if metering information is transported to and fro > > >>>>> between MGC > > >>>>> >and MG > > >>>>> >We are working towards a separate package that addresses this issue. > > >>>>> >Any suggestions? > > >>>>> ... > > >>>>> > > >>>>> _______________________________________________ > > >>>>> 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 > > > >This email and any files transmitted with it are confidential and intended > >solely for the use of the individual or entity to whom they are > >addressed. If you are not the intended recipient you are notified that > >disclosing, copying, distributing or taking any action in reliance on the > >contents of this information is strictly prohibited. If you have received > >this email in error please notify the sender and delete the email. > > > >Santera, a Tekelec Company > >http://www.santera.com > >972-461-4100 > > >This email and any files transmitted with it are confidential and intended >solely for the use of the individual or entity to whom they are >addressed. If you are not the intended recipient you are notified that >disclosing, copying, distributing or taking any action in reliance on the >contents of this information is strictly prohibited. If you have received >this email in error please notify the sender and delete the email. > >Santera, a Tekelec Company >http://www.santera.com >972-461-4100 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri Oct 3 15:19:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22517 for ; Fri, 3 Oct 2003 15:19:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5VSD-00070E-L2 for megaco-archive@odin.ietf.org; Fri, 03 Oct 2003 15:19:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93JJ5nq026912 for megaco-archive@odin.ietf.org; Fri, 3 Oct 2003 15:19:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5VSD-0006zz-DN for megaco-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 15:19:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22441 for ; Fri, 3 Oct 2003 15:18:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5VSC-0005Be-00 for megaco-web-archive@ietf.org; Fri, 03 Oct 2003 15:19:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5VSB-0005Bb-00 for megaco-web-archive@ietf.org; Fri, 03 Oct 2003 15:19:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5VSA-0006zW-6D; Fri, 03 Oct 2003 15:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5VS4-0006zI-53 for megaco@optimus.ietf.org; Fri, 03 Oct 2003 15:18:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22435 for ; Fri, 3 Oct 2003 15:18:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5VS2-0005BX-00 for megaco@ietf.org; Fri, 03 Oct 2003 15:18:54 -0400 Received: from motgate2.mot.com ([136.182.1.10]) by ietf-mx with esmtp (Exim 4.12) id 1A5VS1-0005BU-00 for megaco@ietf.org; Fri, 03 Oct 2003 15:18:53 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h93JImpx007525; Fri, 3 Oct 2003 12:18:49 -0700 (MST) Received: from smilevm.motorola.com ([10.14.25.162]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id h93JIlSu032196; Fri, 3 Oct 2003 14:18:47 -0500 Message-Id: <5.2.1.1.0.20031003151228.024f8d50@IL06EXM13.corp.mot.com> X-Sender: A19776@IL06EXM13.corp.mot.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 03 Oct 2003 15:16:17 -0400 To: "Soncodi, Adrian" From: Aleksandr Ryabin Subject: RE: [Megaco] CAS Metering Pulse support Cc: "Aleksandr Ryabin", , "Kevin Boyle", "Christian Groves" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi, How the pulse information is relayed between MGC is out of scope MEGACO. Whatever MGCs use for inter MGC communication will need to support this information. Regards, Aleks At 02:44 PM 10/3/2003, Soncodi, Adrian wrote: >The pulse rate can change during the call. This is done by the switch >downstream, which is the TAX office, and which changes the rate based on >time-of-day and provisioned charge rates. This means that the receiving MG >would also neeed an event for pulse rate change. A little more overhead >will occur, but I guess it is acceptable. However, it becomes delicate >when the pulse rate decreases: by the time the receiving MG detects the >lower pulse rate, the generating MG has already generated a number of >extra pulses, based on the higher rate. With some effort though, one could >make this work. > >But I don't understand how the meter pulse rate can be relayed between 2 >MGCs that talk SIP, for example in the following tandem-replacement solution: > > Local office - R2 - (MG1, MGC1) - SIP - (MGC2, MG2) - R2 - TAX office > >I think an RFC2833-based solution causes less headache. But registering a >new RFC2833 event is outside the scope of the MEGACO working group anyway. >For registered events, the ability to negotiate the 'telephone-event' >codec is already available via MEGACO/SDP. > >Adrian Soncodi > > >-----Original Message----- >From: Aleksandr Ryabin [mailto:kengr@motorola.com] >Sent: Friday, October 03, 2003 12:56 PM >To: Soncodi, Adrian; megaco@ietf.org >Cc: Kevin Boyle; Christian Groves >Subject: RE: [Megaco] CAS Metering Pulse support > > >Proposed new metd package will have functionality described in 1). > >However I have a slightly different proposal for relaying. >In order to relay pulses all needed to be known is a repetition interval, >changes to it, if any, and when to start, and stop metering pulses. > >If "receiving" MGC (the one that controls MG which receives >metering pulses) gets notified with this information using new >metd package then it can relay this information to "generating" >MGC (the one that controls MG which generates metering pulses). >Then "generating" MGC can use amet to start/stop, or modify >generation of metering pulses. > >That is in reality, if repetition interval does not change during >the call, "receiving" MGC will get only two notifies per call: >first pulse detected, >repetition interval calculated (e.g. second pulse detected) > >"Generating" MGC will need to send tree modifies: >pulse once (when first pulse detected event is relayed) >pulse forever (when repetition interval received) >stop pulse generation (when call terminates) > >Regards, > Aleks > >At 01:12 PM 10/3/2003, Soncodi, Adrian wrote: > >In some countries a tandem switch is required to propagate meter pulses > >(backwards) from the outgoing R2 trunk to the incoming R2 trunk. These > >pulses are used for billing. A potential problem is that the pulse rate > >may be very high, sometimes it can be a sub-second interval. Therefore, a > >tandem MGC which has a considerable number of R2 trunks will have a big > >overhead for propagating meter pulses, which will affect its call > >processing rate. > > > >So I'm wondering if anything can be done about this. Here are two > >possibilities: > > > >1) Allow the MG to detect meter pulses but report them in chunks of N. By > >default, N=1 (report every pulse), but the MGC could also select, say, > >N=10, in which case the MG reports once every 10 pulses. (A residual pulse > >count could be reported on Subtract). This method saves a lot of NTFY > >messages. However, on the other side, the MGC would be forced to propagate > >the pulses as bursts-of-N, and I am not sure a switch is allowed to > >transform constant-rate pulsing into bursts. (On the other hand why not? > >because it's only the total pulse count that is relevant for charging. > >Time-of-day periods with higher charging rates actually result in more > >meter pulses.) > > > >2) Define a mode which allows the meter pulses to be propagated directly > >between MGs, without MGC involvement, i.e. by a method similar to RFC2833. > >RFC2833 does not currently have an event defined for meter pulses, but it > >could be extended, since it defines a lot of signaling-related tones > >anyway. In addition to solving the NTFY messaging overhead, this method > >would have the side benefit that it would also work between two MGCs that > >use SIP or BICC between them. Currently, there is no way to transport > >meter pulse information in SIP or BICC, and this would have a terrible > >overhead anyway. > >Of course, the ability to detect meter pulses is still required, because > >there is always the possibility that the MGC must perform the > >meter-pulse-based charging itself (rather than propagate). > > > >Any other ideas or comments? > > > >Adrian Soncodi > > > > > > > >-----Original Message----- > >From: Christian Groves [mailto:Christian.Groves@ericsson.com.au] > >Sent: Thursday, October 02, 2003 10:38 PM > >To: Aleksandr Ryabin > >Cc: megaco@ietf.org; Kevin Boyle > >Subject: Re: [Megaco] CAS Metering Pulse support > > > > > >Hello Aleksandr, > > > >I'm happy enough to have the your proposed amendment if the editor agrees. > > > >Regards, Christian > > > >Aleksandr Ryabin wrote: > > > Hi Christian, > > > > > > No description of the event does say how to use it for detection > > > incoming metering pulse. More over it explicitly limits to generation: > > > "This event is used in conjunction with the "enable metering" and > > > "metering pulse burst" signals defined in this package..." > > > > > > My point being that descriptions of amet events and statistics > > > are siting that event pr is generated and statistics are changed > > > only based on previously applied em, or mbp signal. > > > > > > The wording needs to be amended to cover the cases when event > > > is generated and statistics are changed as a result *detection* of > > > incoming metering pulse. > > > > > > That is, for example, the text you have referenced should be changed > > > to something like this (I've placed the changes in [] for visibility): > > > > > > "If following the application [or detection] of any metering pulse > > > (regardless > > > of [whether it was detected, or] whether it was generated as a result > > > of the signal em or as a result of the signal mbp), the EventsDescriptor > > > contains the event pr, and if the value of pcslr is equal to the value > > > of the > > > EventsDescriptor parameter rp, then the pr event shall be notified, and > > > the value of the statistic pcslr shall be reset to zero. The > detection of > > > the event pr shall not cause the termination of the signal em or the > > > signal mbp, [if currently active,] even if the KeepActive flag is not > > > set for the pr event." > > > > > > Regards, > > > Aleks > > > > > > At 07:46 PM 10/2/2003, Christian Groves wrote: > > > > > >> Hello Aleksandr, > > >> > > >> I agree that no new package is needed for the detection of metering > > >> pulse functionality. From the description of the event it seems that > > >> it clear how it to be used. > > >> > > >> The package also contains the procedural text: > > >> "If following the application of any metering pulse (regardless of > > >> whether it was generated as a result of the signal em or as a result > > >> of the signal mbp), the EventsDescriptor contains the event pr, and if > > >> the value of pcslr is equal to the value of the EventsDescriptor > > >> parameter rp, then the pr event shall be notified, and the value of > > >> the statistic pcslr shall be reset to zero. The detection of the > > >> event pr shall not cause the termination of the signal em or the > > >> signal mbp, even if the KeepActive flag is not set for the pr event." > > >> > > >> Is this text sufficient? > > >> > > >> Regards, Christian > > >> > > >> Aleksandr Ryabin wrote: > > >> > > >>> Hi, > > >>> In continuation to this metering pulse support. > > >>> I've looked through amet package and it does not seem to > > >>> define procedure to detect metering pulses, it only has > > >>> a procedure to generate metering pulses. > > >>> I see no reason of defining a new package for detecting incoming > > >>> metering pulses and I propose to reuse amet and amend it to > > >>> define procedure for detecting incoming metering pulses. > > >>> Here is the summary of a proposed metering pulse detection > > >>> procedure using amet package: > > >>> The detection of metering pulse on a termination could be enabled > > >>> by MGC when no amet signals are played on a termination by > > >>> requesting detection amet/pr event with a required repetition period. > > >>> MG would Notify MGC with amet/pr event when number of metering > > >>> pulses is detected according to repetition period parameter set. > > >>> On Subtract, or explicit AuditValue MG would send amet/cpc > > >>> and amet/pcslr statistics similar to as described in the package > > >>> provided their description extended to detection as well. > > >>> Comments? > > >>> Thanks > > >>> Aleks > > >>> BTW IANA MEGACO page is still not updated. > > >>> At 10:50 AM 9/16/2003, Aleksandr Ryabin wrote: > > >>> > > >>>> It is updated with H.248.22 and 25, but not with 23, 24, 26, 27 > > >>>> while all of them are dated in ITU the same. Strange. > > >>>> Aleks > > >>>> > > >>>> At 10:46 AM 9/16/2003, Kevin Boyle wrote: > > >>>> > > >>>>> If it is NOT updated, that is. (Apparently, it's going to be one of > > >>>>> those days!) > > >>>>> > > >>>>> Kevin > > >>>>> > > >>>>> -----Original Message----- > > >>>>> From: Boyle, Kevin [NCRTP:3Z40:EXCH] > > >>>>> Sent: Tuesday, September 16, 2003 10:39 AM > > >>>>> To: Aleksandr Ryabin; megaco@ietf.org > > >>>>> Subject: RE: [Megaco] CAS Metering Pulse support > > >>>>> > > >>>>> Ummm... yeah. That's what I get for not looking it up before > > >>>>> sending the message. :) While amet is defined in the "Extended > > >>>>> Analog Lines Packages" doc, there is nothing in the amet package > > >>>>> that actually limits it to analog lines. > > >>>>> > > >>>>> > > >>>>> The updates for all the new (as of May) H.248 Sub-series > > >>>>> Recommendations have already been requested of IANA. If it is > > >>>>> updated by the end of the month, I'll ping them again. > > >>>>> > > >>>>> > > >>>>> Kevin > > >>>>> > > >>>>> -----Original Message----- > > >>>>> From: Aleksandr Ryabin [mailto:kengr@motorola.com] > > >>>>> Sent: Tuesday, September 16, 2003 10:32 AM > > >>>>> To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org > > >>>>> Subject: RE: [Megaco] CAS Metering Pulse support > > >>>>> > > >>>>> Hi, > > >>>>> > > >>>>> I guess you meant H.248.26. > > >>>>> Yes it seem to address the needs assuming it is extended to digital > > >>>>> lines as well. > > >>>>> > > >>>>> BTW IANA registry should be updated with H.248.26 and H.248.27 > > >>>>> http://www.iana.org/assignments/megaco-h248 > > >>>>> > > >>>>> > > >>>>> Thanks, > > >>>>> Aleks > > >>>>> > > >>>>> At 10:00 AM 9/16/2003, Kevin Boyle wrote: > > >>>>> > > >>>>> > > >>>>> H.248.27 has a metering package (automatic metering package or > > >>>>> amet). This package may address your needs. > > >>>>> > > >>>>> Kevin > > >>>>> > > >>>>> -----Original Message----- > > >>>>> From: Aleksandr Ryabin [mailto:kengr@motorola.com > > >>>>> ] > > >>>>> Sent: Tuesday, September 16, 2003 9:34 AM > > >>>>> To: megaco@ietf.org > > >>>>> Subject: [Megaco] CAS Metering Pulse support > > >>>>> > > >>>>> Hi all, > > >>>>> > > >>>>> Below are excerpts from a previous exchange related to defining of > > >>>>> CAS Metering Pulse procedures in MEGACO. > > >>>>> > > >>>>> Now that CAS packages related work has been moved to ITU has anyone > > >>>>> done and/or planned anything in the direction to define CAS > > >>>>> Metering Pulse procedures/package for MEGACO? > > >>>>> > > >>>>> Thanks > > >>>>> Aleks > > >>>>> > > >>>>> >From: klaha@hss.hns.com > > >>>>> >To: Aleksandr Ryabin > > >>>>> >cc: vnair@hss.hns.com, megaco@ietf.org, klaha@hss.hns.com > > >>>>> >Date: Tue, 4 Mar 2003 12:47:37 +0530 > > >>>>> >Subject: Re: [Megaco] Re: draft-ietf-megaco-r2package-03.txt : > > >>>>> Difference > > >>>>> > from previous revision > > >>>>> ... > > >>>>> >Aleksandr Ryabin on 03/03/2003 10:43:20 PM > > >>>>> ... > > >>>>> >3. I can't seem to find a way to implement "Metering Pulse" > procedure > > >>>>> >defined for some R2 variants using ether bcas or R2 packages? For > > >>>>> >example, one of the definitions of such a pulse is a "seizure ack" > > >>>>> >pulse from a terminating end on a circuit in connected/answer state. > > >>>>> > > > >>>>> >[Kushanava] Metering is not specific to R2. It may be present in any > > >>>>> >CAS signaling. Moreover not all flavours of R2 permit metering to be > > >>>>> >mandatory. There should be therefore a general philosophy of > > >>>>> attacking > > >>>>> >this problem common to all CAS signaling. The solution should be > > >>>>> >sensitive to > > >>>>> >a) Realizing that MGC is the master for collecting and generating > > >>>>> charging > > >>>>> >information > > >>>>> >b) Interworking of the CAS "metering pulse" signals with other > > >>>>> signaling > > >>>>> >(both PDN and PSTN) > > >>>>> >c) Optimizing the network traffic if metering information is > > >>>>> transported to > > >>>>> > > >>>>> >and fro between MGC and MG > > >>>>> >d) Latency, if metering information is transported to and fro > > >>>>> between MGC > > >>>>> >and MG > > >>>>> >We are working towards a separate package that addresses this issue. > > >>>>> >Any suggestions? > > >>>>> ... > > >>>>> > > >>>>> _______________________________________________ > > >>>>> 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 > > > >This email and any files transmitted with it are confidential and intended > >solely for the use of the individual or entity to whom they are > >addressed. If you are not the intended recipient you are notified that > >disclosing, copying, distributing or taking any action in reliance on the > >contents of this information is strictly prohibited. If you have received > >this email in error please notify the sender and delete the email. > > > >Santera, a Tekelec Company > >http://www.santera.com > >972-461-4100 > > >This email and any files transmitted with it are confidential and intended >solely for the use of the individual or entity to whom they are >addressed. If you are not the intended recipient you are notified that >disclosing, copying, distributing or taking any action in reliance on the >contents of this information is strictly prohibited. If you have received >this email in error please notify the sender and delete the email. > >Santera, a Tekelec Company >http://www.santera.com >972-461-4100 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Sun Oct 5 20:45:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00824 for ; Sun, 5 Oct 2003 20:45:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6JUk-0004Bp-Dp; Sun, 05 Oct 2003 20:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6JTp-0004B8-4X for megaco@optimus.ietf.org; Sun, 05 Oct 2003 20:44:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00781 for ; Sun, 5 Oct 2003 20:43:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6JTm-0006rZ-00 for megaco@ietf.org; Sun, 05 Oct 2003 20:44:02 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 1A6JTl-0006rV-00 for megaco@ietf.org; Sun, 05 Oct 2003 20:44:02 -0400 Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h960dht29287; Mon, 6 Oct 2003 10:39:43 +1000 (EST) Received: from ericsson.com.au (146.11.245.220 [146.11.245.220]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SYC16WA1; Mon, 6 Oct 2003 10:41:42 +1000 Message-ID: <3F80B985.8040102@ericsson.com.au> Date: Mon, 06 Oct 2003 10:38:29 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: klaha@hss.hns.com CC: Aleksandr Ryabin , "Soncodi, Adrian" , megaco@ietf.org, Kevin Boyle Subject: Re: [Megaco] CAS Metering Pulse support References: <20031003192847.69054.qmail@web40909.mail.yahoo.com> In-Reply-To: <20031003192847.69054.qmail@web40909.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello, As Aleks said RTP is not in the scope of this working group. I believe the correct way to move this forward is to write a IETF draft of the carriage of metering pulses over RTP and submit it to the AVT WG for comment. Regards, Christian Kushanava Laha wrote: > Is it possible for this WG to convey this (metering > pulse via RTP) as a requirement to the relevant WG? > > > --- Aleksandr Ryabin wrote: > >>Hi, >> >>How the pulse information is relayed between MGC is >>out of scope MEGACO. >>Whatever MGCs use for inter MGC communication will >>need to support this >>information. >> >>Regards, >> Aleks >> >>At 02:44 PM 10/3/2003, Soncodi, Adrian wrote: >> >>>The pulse rate can change during the call. This is >> >>done by the switch >> >>>downstream, which is the TAX office, and which >> >>changes the rate based on >> >>>time-of-day and provisioned charge rates. This >> >>means that the receiving MG >> >>>would also neeed an event for pulse rate change. A >> >>little more overhead >> >>>will occur, but I guess it is acceptable. However, >> >>it becomes delicate >> >>>when the pulse rate decreases: by the time the >> >>receiving MG detects the >> >>>lower pulse rate, the generating MG has already >> >>generated a number of >> >>>extra pulses, based on the higher rate. With some >> >>effort though, one could >> >>>make this work. >>> >>>But I don't understand how the meter pulse rate can >> >>be relayed between 2 >> >>>MGCs that talk SIP, for example in the following >> >>tandem-replacement solution: >> >>> Local office - R2 - (MG1, MGC1) - SIP - (MGC2, >> >>MG2) - R2 - TAX office >> >>>I think an RFC2833-based solution causes less >> >>headache. But registering a >> >>>new RFC2833 event is outside the scope of the >> >>MEGACO working group anyway. >> >>>For registered events, the ability to negotiate the >> >>'telephone-event' >> >>>codec is already available via MEGACO/SDP. >>> >>>Adrian Soncodi >>> >>> >>>-----Original Message----- >>>From: Aleksandr Ryabin [mailto:kengr@motorola.com] >>>Sent: Friday, October 03, 2003 12:56 PM >>>To: Soncodi, Adrian; megaco@ietf.org >>>Cc: Kevin Boyle; Christian Groves >>>Subject: RE: [Megaco] CAS Metering Pulse support >>> >>> >>>Proposed new metd package will have functionality >> >>described in 1). >> >>>However I have a slightly different proposal for >> >>relaying. >> >>>In order to relay pulses all needed to be known is >> >>a repetition interval, >> >>>changes to it, if any, and when to start, and stop >> >>metering pulses. >> >>>If "receiving" MGC (the one that controls MG which >> >>receives >> >>>metering pulses) gets notified with this >> >>information using new >> >>>metd package then it can relay this information to >> >>"generating" >> >>>MGC (the one that controls MG which generates >> >>metering pulses). >> >>>Then "generating" MGC can use amet to start/stop, >> >>or modify >> >>>generation of metering pulses. >>> >>>That is in reality, if repetition interval does not >> >>change during >> >>>the call, "receiving" MGC will get only two >> >>notifies per call: >> >>>first pulse detected, >>>repetition interval calculated (e.g. second pulse >> >>detected) >> >>>"Generating" MGC will need to send tree modifies: >>>pulse once (when first pulse detected event is >> >>relayed) >> >>>pulse forever (when repetition interval received) >>>stop pulse generation (when call terminates) >>> >>>Regards, >>> Aleks >>> >>>At 01:12 PM 10/3/2003, Soncodi, Adrian wrote: >>> >>>>In some countries a tandem switch is required to >> >>propagate meter pulses >> >>>>(backwards) from the outgoing R2 trunk to the >> >>incoming R2 trunk. These >> >>>>pulses are used for billing. A potential problem >> >>is that the pulse rate >> >>>>may be very high, sometimes it can be a >> >>sub-second interval. Therefore, a >> >>>>tandem MGC which has a considerable number of R2 >> >>trunks will have a big >> >>>>overhead for propagating meter pulses, which will >> >>affect its call >> >>>>processing rate. >>>> >>>>So I'm wondering if anything can be done about >> >>this. Here are two >> >>>>possibilities: >>>> >>>>1) Allow the MG to detect meter pulses but report >> >>them in chunks of N. By >> >>>>default, N=1 (report every pulse), but the MGC >> >>could also select, say, >> >>>>N=10, in which case the MG reports once every 10 >> >>pulses. (A residual pulse >> >>>>count could be reported on Subtract). This method >> >>saves a lot of NTFY >> >>>>messages. However, on the other side, the MGC >> >>would be forced to propagate >> >>>>the pulses as bursts-of-N, and I am not sure a >> >>switch is allowed to >> >>>>transform constant-rate pulsing into bursts. (On >> >>the other hand why not? >> >>>>because it's only the total pulse count that is >> >>relevant for charging. >> >>>>Time-of-day periods with higher charging rates >> >>actually result in more >> >>>>meter pulses.) >>>> >>>>2) Define a mode which allows the meter pulses to >> >>be propagated directly >> >>>>between MGs, without MGC involvement, i.e. by a >> >>method similar to RFC2833. >> >>>>RFC2833 does not currently have an event defined >> >>for meter pulses, but it >> >>>>could be extended, since it defines a lot of >> >>signaling-related tones >> >>>>anyway. In addition to solving the NTFY messaging >> >>overhead, this method >> >>>>would have the side benefit that it would also >> >>work between two MGCs that >> >>>>use SIP or BICC between them. Currently, there is >> >>no way to transport >> >>>>meter pulse information in SIP or BICC, and this >> >>would have a terrible >> >>>>overhead anyway. >>>>Of course, the ability to detect meter pulses is >> >>still required, because >> >>>>there is always the possibility that the MGC must >> >>perform the >> >>>>meter-pulse-based charging itself (rather than >> >>propagate). >> >>>>Any other ideas or comments? >>>> >>>>Adrian Soncodi >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: Christian Groves >> >>[mailto:Christian.Groves@ericsson.com.au] >> >>>>Sent: Thursday, October 02, 2003 10:38 PM >>>>To: Aleksandr Ryabin >>>>Cc: megaco@ietf.org; Kevin Boyle >>>>Subject: Re: [Megaco] CAS Metering Pulse support >>>> >>>> >>>>Hello Aleksandr, >>>> >>>>I'm happy enough to have the your proposed >> >>amendment if the editor agrees. >> >>>>Regards, Christian >>>> >>>>Aleksandr Ryabin wrote: >>>> >>>>>Hi Christian, >>>>> >>>>>No description of the event does say how to >> >>use it for detection >> >>>>>incoming metering pulse. More over it >> >>explicitly limits to generation: >> >>>>>"This event is used in conjunction with the >> >>"enable metering" and >> >>>>>"metering pulse burst" signals defined in this >> >>package..." >> >>>>>My point being that descriptions of amet >> >>events and statistics >> >>>>>are siting that event pr is generated and >> >>statistics are changed >> >>>>>only based on previously applied em, or mbp >> >>signal. >> >>>>>The wording needs to be amended to cover the >> >>cases > > === message truncated === > > > ===== > Kushanava Laha > Hughes Software Systems > > __________________________________ > Do you Yahoo!? > The New Yahoo! Shopping - with improved product search > http://shopping.yahoo.com > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Sun Oct 5 20:45:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00839 for ; Sun, 5 Oct 2003 20:45:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6JUq-0004Cl-Ck for megaco-archive@odin.ietf.org; Sun, 05 Oct 2003 20:45:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h960j8Qw016164 for megaco-archive@odin.ietf.org; Sun, 5 Oct 2003 20:45:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6JUo-0004Cd-Qo for megaco-web-archive@optimus.ietf.org; Sun, 05 Oct 2003 20:45:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00809 for ; Sun, 5 Oct 2003 20:44:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6JUm-0006s7-00 for megaco-web-archive@ietf.org; Sun, 05 Oct 2003 20:45:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6JUm-0006s3-00 for megaco-web-archive@ietf.org; Sun, 05 Oct 2003 20:45:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6JUk-0004Bp-Dp; Sun, 05 Oct 2003 20:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6JTp-0004B8-4X for megaco@optimus.ietf.org; Sun, 05 Oct 2003 20:44:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00781 for ; Sun, 5 Oct 2003 20:43:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6JTm-0006rZ-00 for megaco@ietf.org; Sun, 05 Oct 2003 20:44:02 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 1A6JTl-0006rV-00 for megaco@ietf.org; Sun, 05 Oct 2003 20:44:02 -0400 Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h960dht29287; Mon, 6 Oct 2003 10:39:43 +1000 (EST) Received: from ericsson.com.au (146.11.245.220 [146.11.245.220]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SYC16WA1; Mon, 6 Oct 2003 10:41:42 +1000 Message-ID: <3F80B985.8040102@ericsson.com.au> Date: Mon, 06 Oct 2003 10:38:29 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: klaha@hss.hns.com CC: Aleksandr Ryabin , "Soncodi, Adrian" , megaco@ietf.org, Kevin Boyle Subject: Re: [Megaco] CAS Metering Pulse support References: <20031003192847.69054.qmail@web40909.mail.yahoo.com> In-Reply-To: <20031003192847.69054.qmail@web40909.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, As Aleks said RTP is not in the scope of this working group. I believe the correct way to move this forward is to write a IETF draft of the carriage of metering pulses over RTP and submit it to the AVT WG for comment. Regards, Christian Kushanava Laha wrote: > Is it possible for this WG to convey this (metering > pulse via RTP) as a requirement to the relevant WG? > > > --- Aleksandr Ryabin wrote: > >>Hi, >> >>How the pulse information is relayed between MGC is >>out of scope MEGACO. >>Whatever MGCs use for inter MGC communication will >>need to support this >>information. >> >>Regards, >> Aleks >> >>At 02:44 PM 10/3/2003, Soncodi, Adrian wrote: >> >>>The pulse rate can change during the call. This is >> >>done by the switch >> >>>downstream, which is the TAX office, and which >> >>changes the rate based on >> >>>time-of-day and provisioned charge rates. This >> >>means that the receiving MG >> >>>would also neeed an event for pulse rate change. A >> >>little more overhead >> >>>will occur, but I guess it is acceptable. However, >> >>it becomes delicate >> >>>when the pulse rate decreases: by the time the >> >>receiving MG detects the >> >>>lower pulse rate, the generating MG has already >> >>generated a number of >> >>>extra pulses, based on the higher rate. With some >> >>effort though, one could >> >>>make this work. >>> >>>But I don't understand how the meter pulse rate can >> >>be relayed between 2 >> >>>MGCs that talk SIP, for example in the following >> >>tandem-replacement solution: >> >>> Local office - R2 - (MG1, MGC1) - SIP - (MGC2, >> >>MG2) - R2 - TAX office >> >>>I think an RFC2833-based solution causes less >> >>headache. But registering a >> >>>new RFC2833 event is outside the scope of the >> >>MEGACO working group anyway. >> >>>For registered events, the ability to negotiate the >> >>'telephone-event' >> >>>codec is already available via MEGACO/SDP. >>> >>>Adrian Soncodi >>> >>> >>>-----Original Message----- >>>From: Aleksandr Ryabin [mailto:kengr@motorola.com] >>>Sent: Friday, October 03, 2003 12:56 PM >>>To: Soncodi, Adrian; megaco@ietf.org >>>Cc: Kevin Boyle; Christian Groves >>>Subject: RE: [Megaco] CAS Metering Pulse support >>> >>> >>>Proposed new metd package will have functionality >> >>described in 1). >> >>>However I have a slightly different proposal for >> >>relaying. >> >>>In order to relay pulses all needed to be known is >> >>a repetition interval, >> >>>changes to it, if any, and when to start, and stop >> >>metering pulses. >> >>>If "receiving" MGC (the one that controls MG which >> >>receives >> >>>metering pulses) gets notified with this >> >>information using new >> >>>metd package then it can relay this information to >> >>"generating" >> >>>MGC (the one that controls MG which generates >> >>metering pulses). >> >>>Then "generating" MGC can use amet to start/stop, >> >>or modify >> >>>generation of metering pulses. >>> >>>That is in reality, if repetition interval does not >> >>change during >> >>>the call, "receiving" MGC will get only two >> >>notifies per call: >> >>>first pulse detected, >>>repetition interval calculated (e.g. second pulse >> >>detected) >> >>>"Generating" MGC will need to send tree modifies: >>>pulse once (when first pulse detected event is >> >>relayed) >> >>>pulse forever (when repetition interval received) >>>stop pulse generation (when call terminates) >>> >>>Regards, >>> Aleks >>> >>>At 01:12 PM 10/3/2003, Soncodi, Adrian wrote: >>> >>>>In some countries a tandem switch is required to >> >>propagate meter pulses >> >>>>(backwards) from the outgoing R2 trunk to the >> >>incoming R2 trunk. These >> >>>>pulses are used for billing. A potential problem >> >>is that the pulse rate >> >>>>may be very high, sometimes it can be a >> >>sub-second interval. Therefore, a >> >>>>tandem MGC which has a considerable number of R2 >> >>trunks will have a big >> >>>>overhead for propagating meter pulses, which will >> >>affect its call >> >>>>processing rate. >>>> >>>>So I'm wondering if anything can be done about >> >>this. Here are two >> >>>>possibilities: >>>> >>>>1) Allow the MG to detect meter pulses but report >> >>them in chunks of N. By >> >>>>default, N=1 (report every pulse), but the MGC >> >>could also select, say, >> >>>>N=10, in which case the MG reports once every 10 >> >>pulses. (A residual pulse >> >>>>count could be reported on Subtract). This method >> >>saves a lot of NTFY >> >>>>messages. However, on the other side, the MGC >> >>would be forced to propagate >> >>>>the pulses as bursts-of-N, and I am not sure a >> >>switch is allowed to >> >>>>transform constant-rate pulsing into bursts. (On >> >>the other hand why not? >> >>>>because it's only the total pulse count that is >> >>relevant for charging. >> >>>>Time-of-day periods with higher charging rates >> >>actually result in more >> >>>>meter pulses.) >>>> >>>>2) Define a mode which allows the meter pulses to >> >>be propagated directly >> >>>>between MGs, without MGC involvement, i.e. by a >> >>method similar to RFC2833. >> >>>>RFC2833 does not currently have an event defined >> >>for meter pulses, but it >> >>>>could be extended, since it defines a lot of >> >>signaling-related tones >> >>>>anyway. In addition to solving the NTFY messaging >> >>overhead, this method >> >>>>would have the side benefit that it would also >> >>work between two MGCs that >> >>>>use SIP or BICC between them. Currently, there is >> >>no way to transport >> >>>>meter pulse information in SIP or BICC, and this >> >>would have a terrible >> >>>>overhead anyway. >>>>Of course, the ability to detect meter pulses is >> >>still required, because >> >>>>there is always the possibility that the MGC must >> >>perform the >> >>>>meter-pulse-based charging itself (rather than >> >>propagate). >> >>>>Any other ideas or comments? >>>> >>>>Adrian Soncodi >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: Christian Groves >> >>[mailto:Christian.Groves@ericsson.com.au] >> >>>>Sent: Thursday, October 02, 2003 10:38 PM >>>>To: Aleksandr Ryabin >>>>Cc: megaco@ietf.org; Kevin Boyle >>>>Subject: Re: [Megaco] CAS Metering Pulse support >>>> >>>> >>>>Hello Aleksandr, >>>> >>>>I'm happy enough to have the your proposed >> >>amendment if the editor agrees. >> >>>>Regards, Christian >>>> >>>>Aleksandr Ryabin wrote: >>>> >>>>>Hi Christian, >>>>> >>>>>No description of the event does say how to >> >>use it for detection >> >>>>>incoming metering pulse. More over it >> >>explicitly limits to generation: >> >>>>>"This event is used in conjunction with the >> >>"enable metering" and >> >>>>>"metering pulse burst" signals defined in this >> >>package..." >> >>>>>My point being that descriptions of amet >> >>events and statistics >> >>>>>are siting that event pr is generated and >> >>statistics are changed >> >>>>>only based on previously applied em, or mbp >> >>signal. >> >>>>>The wording needs to be amended to cover the >> >>cases > > === message truncated === > > > ===== > Kushanava Laha > Hughes Software Systems > > __________________________________ > Do you Yahoo!? > The New Yahoo! Shopping - with improved product search > http://shopping.yahoo.com > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Sun Oct 5 21:03:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01298 for ; Sun, 5 Oct 2003 21:03:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6Jm9-0004k4-Dp; Sun, 05 Oct 2003 21:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6JlN-0004jI-Hs for megaco@optimus.ietf.org; Sun, 05 Oct 2003 21:02:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01270 for ; Sun, 5 Oct 2003 21:02:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6JlK-00070B-00 for megaco@ietf.org; Sun, 05 Oct 2003 21:02:10 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 1A6JlJ-0006zz-00 for megaco@ietf.org; Sun, 05 Oct 2003 21:02:10 -0400 Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h960wnt01407; Mon, 6 Oct 2003 10:58:49 +1000 (EST) Received: from ericsson.com.au (146.11.245.220 [146.11.245.220]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SYC16W2Z; Mon, 6 Oct 2003 11:00:47 +1000 Message-ID: <3F80BDFF.7070409@ericsson.com.au> Date: Mon, 06 Oct 2003 10:57:35 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Boyle CC: Aleksandr Ryabin , megaco@ietf.org Subject: Re: [Megaco] CAS Metering Pulse support References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit G'Day Kevin, If we do have an amendment then I think some text needs to be changed in the original to make it very clear that it does not detect pulses. I think as the current text stands one could be forgiven for misinterpereting whether this is possible or not. Cheers, Christian Kevin Boyle wrote: > I have no problem with producing an amendment to H.248.26. There really is > no need for us to produce 1000 recommendations with 1 package each. > > Kevin > > -----Original Message----- > From: Aleksandr Ryabin [mailto:kengr@motorola.com] > Sent: Friday, October 03, 2003 11:21 AM > To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org > Cc: Christian Groves > Subject: RE: [Megaco] CAS Metering Pulse support > > > Hi, > > Sounds reasonable. Except that it probably should not be an extension since > an application might be needing detection only and no generation. That is it > should be then a standalone metd ("Metering Detection Package"). > > Since amet and metd are complimentary I think it would be reasonable to keep > them together, that is to a amend H.248.26 to include it. > > Would you as the editor of H.248.26 recommend amending it to include new > metd or rather have new H.248.metd, or something else? > > I can provide a baseline text, if necessary. > > Regards, > Aleks > > At 09:34 AM 10/3/2003, Kevin Boyle wrote: > >>The amet package was never designed to do pulse detection. The pr >>event is meant to allow the MGC to stay updated with the actual number >>of pulses applied -- it has nothing to do with pulses detected. This >>allows the MGC to have an accurate view of the number of pulses >>applied, rather than guessing -- and possibly being wrong due to >>network latency, message loss, retransmission, etc., etc., etc. I >>think shoehorning detection in here isn't really appropriate. >> >>Further, are we sure that ALL pulse generation applications will be >>required to detect pulses? In the analog line case, the MG has no >>reason to detect pulses -- pulses are being sent to the CPE for the >>end-user's benefit. I think that it would be far wiser to define an >>extension package to handle detection, and not subject applications >>that only want to do generation to doing detection as well. >> >>Kevin >> >>-----Original Message----- >>From: Christian Groves [mailto:Christian.Groves@ericsson.com.au] >>Sent: Thursday, October 02, 2003 11:38 PM >>To: Aleksandr Ryabin >>Cc: megaco@ietf.org; Boyle, Kevin [NCRTP:3Z40:EXCH] >>Subject: Re: [Megaco] CAS Metering Pulse support >> >> >>Hello Aleksandr, >> >>I'm happy enough to have the your proposed amendment if the editor >>agrees. >> >>Regards, Christian >> >>Aleksandr Ryabin wrote: >> >>>Hi Christian, >>> >>>No description of the event does say how to use it for detection >>>incoming metering pulse. More over it explicitly limits to >>>generation: "This event is used in conjunction with the "enable >>>metering" and "metering pulse burst" signals defined in this >>>package..." >>> >>>My point being that descriptions of amet events and statistics are >>>siting that event pr is generated and statistics are changed only >>>based on previously applied em, or mbp signal. >>> >>>The wording needs to be amended to cover the cases when event is >>>generated and statistics are changed as a result *detection* of >>>incoming metering pulse. >>> >>>That is, for example, the text you have referenced should be changed >>>to something like this (I've placed the changes in [] for >>>visibility): >>> >>>"If following the application [or detection] of any metering pulse >>>(regardless of [whether it was detected, or] whether it was >>>generated as a result of the signal em or as a result of the signal >>>mbp), the EventsDescriptor contains the event pr, and if the value >>>of pcslr is equal to the value of the >>>EventsDescriptor parameter rp, then the pr event shall be notified, and >>>the value of the statistic pcslr shall be reset to zero. The detection > > of > >>>the event pr shall not cause the termination of the signal em or the >>>signal mbp, [if currently active,] even if the KeepActive flag is not >>>set for the pr event." >>> >>>Regards, >>> Aleks >>> >>>At 07:46 PM 10/2/2003, Christian Groves wrote: >>> >>> >>>>Hello Aleksandr, >>>> >>>>I agree that no new package is needed for the detection of metering >>>>pulse functionality. From the description of the event it seems >>>>that it clear how it to be used. >>>> >>>>The package also contains the procedural text: >>>>"If following the application of any metering pulse (regardless of >>>>whether it was generated as a result of the signal em or as a >>>>result of the signal mbp), the EventsDescriptor contains the event >>>>pr, and if the value of pcslr is equal to the value of the >>>>EventsDescriptor parameter rp, then the pr event shall be notified, >>>>and the value of the statistic pcslr shall be reset to zero. The >>>>detection of the event pr shall not cause the termination of the >>>>signal em or the signal mbp, even if the KeepActive flag is not set >>>>for the pr event." >>>> >>>>Is this text sufficient? >>>> >>>>Regards, Christian >>>> >>>>Aleksandr Ryabin wrote: >>>> >>>> >>>>>Hi, >>>>>In continuation to this metering pulse support. >>>>>I've looked through amet package and it does not seem to define >>>>>procedure to detect metering pulses, it only has a procedure to >>>>>generate metering pulses. I see no reason of defining a new >>>>>package for detecting incoming metering pulses and I propose to >>>>>reuse amet and amend it to define procedure for detecting incoming >>>>>metering pulses. Here is the summary of a proposed metering pulse >>>>>detection procedure using amet package: The detection of metering >>>>>pulse on a termination could be enabled by MGC when no amet >>>>>signals are played on a termination by requesting detection >>>>>amet/pr event with a required repetition period. MG would Notify >>>>>MGC with amet/pr event when number of metering pulses is detected >>>>>according to repetition period parameter set. On Subtract, or >>>>>explicit AuditValue MG would send amet/cpc and amet/pcslr >>>>>statistics similar to as described in the package provided their >>>>>description extended to detection as well. Comments? >>>>>Thanks >>>>> Aleks >>>>>BTW IANA MEGACO page is still not updated. >>>>>At 10:50 AM 9/16/2003, Aleksandr Ryabin wrote: >>>>> >>>>> >>>>>>It is updated with H.248.22 and 25, but not with 23, 24, 26, 27 >>>>>>while all of them are dated in ITU the same. Strange. >>>>>> Aleks >>>>>> >>>>>>At 10:46 AM 9/16/2003, Kevin Boyle wrote: >>>>>> >>>>>> >>>>>>>If it is NOT updated, that is. (Apparently, it's going to be one >>>>>>>of those days!) >>>>>>> >>>>>>>Kevin >>>>>>> >>>>>>>-----Original Message----- >>>>>>>From: Boyle, Kevin [NCRTP:3Z40:EXCH] >>>>>>>Sent: Tuesday, September 16, 2003 10:39 AM >>>>>>>To: Aleksandr Ryabin; megaco@ietf.org >>>>>>>Subject: RE: [Megaco] CAS Metering Pulse support >>>>>>> >>>>>>>Ummm... yeah. That's what I get for not looking it up before >>>>>>>sending the message. :) While amet is defined in the "Extended >>>>>>>Analog Lines Packages" doc, there is nothing in the amet package >>>>>>>that actually limits it to analog lines. >>>>>>> >>>>>>> >>>>>>>The updates for all the new (as of May) H.248 Sub-series >>>>>>>Recommendations have already been requested of IANA. If it is >>>>>>>updated by the end of the month, I'll ping them again. >>>>>>> >>>>>>> >>>>>>>Kevin >>>>>>> >>>>>>>-----Original Message----- >>>>>>>From: Aleksandr Ryabin [mailto:kengr@motorola.com] >>>>>>>Sent: Tuesday, September 16, 2003 10:32 AM >>>>>>>To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org >>>>>>>Subject: RE: [Megaco] CAS Metering Pulse support >>>>>>> >>>>>>>Hi, >>>>>>> >>>>>>>I guess you meant H.248.26. >>>>>>>Yes it seem to address the needs assuming it is extended to >>>>>>>digital lines as well. >>>>>>> >>>>>>>BTW IANA registry should be updated with H.248.26 and H.248.27 >>>>>>>http://www.iana.org/assignments/megaco-h248 >>>>>>> >>>>>>> >>>>>>>Thanks, >>>>>>> Aleks >>>>>>> >>>>>>>At 10:00 AM 9/16/2003, Kevin Boyle wrote: >>>>>>> >>>>>>> >>>>>>>H.248.27 has a metering package (automatic metering package or >>>>>>>amet). This package may address your needs. >>>>>>> >>>>>>>Kevin >>>>>>> >>>>>>>-----Original Message----- >>>>>>>From: Aleksandr Ryabin [mailto:kengr@motorola.com >>>>>>> ] >>>>>>>Sent: Tuesday, September 16, 2003 9:34 AM >>>>>>>To: megaco@ietf.org >>>>>>>Subject: [Megaco] CAS Metering Pulse support >>>>>>> >>>>>>>Hi all, >>>>>>> >>>>>>>Below are excerpts from a previous exchange related to defining >>>>>>>of CAS Metering Pulse procedures in MEGACO. >>>>>>> >>>>>>>Now that CAS packages related work has been moved to ITU has >>>>>>>anyone done and/or planned anything in the direction to define >>>>>>>CAS Metering Pulse procedures/package for MEGACO? >>>>>>> >>>>>>>Thanks >>>>>>> Aleks >>>>>>> >>>>>>> >>>>>>>>From: klaha@hss.hns.com >>>>>>>>To: Aleksandr Ryabin >>>>>>>>cc: vnair@hss.hns.com, megaco@ietf.org, klaha@hss.hns.com >>>>>>>>Date: Tue, 4 Mar 2003 12:47:37 +0530 >>>>>>>>Subject: Re: [Megaco] Re: draft-ietf-megaco-r2package-03.txt : >>>>>>> >>>>>>>Difference >>>>>>> >>>>>>>> from previous revision >>>>>>> >>>>>>>... >>>>>>> >>>>>>>>Aleksandr Ryabin on 03/03/2003 10:43:20 >>>>>>>>PM >>>>>>> >>>>>>>... >>>>>>> >>>>>>>>3. I can't seem to find a way to implement "Metering Pulse" >>>>>>>>procedure defined for some R2 variants using ether bcas or R2 >>>>>>>>packages? For example, one of the definitions of such a pulse >>>>>>>>is a "seizure ack" pulse from a terminating end on a circuit in >>>>>>>>connected/answer state. >>>>>>>> >>>>>>>>[Kushanava] Metering is not specific to R2. It may be present >>>>>>>>in any CAS signaling. Moreover not all flavours of R2 permit >>>>>>>>metering to be mandatory. There should be therefore a general >>>>>>>>philosophy of >>>>>>> >>>>>>>attacking >>>>>>> >>>>>>>>this problem common to all CAS signaling. The solution should >>>>>>>>be sensitive to >>>>>>>>a) Realizing that MGC is the master for collecting and >>>>>>>>generating >>>>>>> >>>>>>>charging >>>>>>> >>>>>>>>information >>>>>>>>b) Interworking of the CAS "metering pulse" signals with other >>>>>>> >>>>>>>signaling >>>>>>> >>>>>>>>(both PDN and PSTN) >>>>>>>>c) Optimizing the network traffic if metering information is >>>>>>> >>>>>>>transported to >>>>>>> >>>>>>> >>>>>>>>and fro between MGC and MG >>>>>>>>d) Latency, if metering information is transported to and fro >>>>>>> >>>>>>>between MGC >>>>>>> >>>>>>>>and MG >>>>>>>>We are working towards a separate package that addresses this >>>>>>>>issue. Any suggestions? >>>>>>> >>>>>>>... >>>>>>> >>>>>>>_______________________________________________ >>>>>>>Megaco mailing list >>>>>>>Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco >>>>>>> >>>>>>>_______________________________________________ >>>>>>>Megaco mailing list >>>>>>>Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco >>> >>> > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Sun Oct 5 21:03:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01313 for ; Sun, 5 Oct 2003 21:03:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6JmB-0004ls-Fz for megaco-archive@odin.ietf.org; Sun, 05 Oct 2003 21:03:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h96133VF018297 for megaco-archive@odin.ietf.org; Sun, 5 Oct 2003 21:03:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6JmB-0004kt-8W for megaco-web-archive@optimus.ietf.org; Sun, 05 Oct 2003 21:03:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01282 for ; Sun, 5 Oct 2003 21:02:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6Jm8-00070l-00 for megaco-web-archive@ietf.org; Sun, 05 Oct 2003 21:03:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6Jm8-00070i-00 for megaco-web-archive@ietf.org; Sun, 05 Oct 2003 21:03:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6Jm9-0004k4-Dp; Sun, 05 Oct 2003 21:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6JlN-0004jI-Hs for megaco@optimus.ietf.org; Sun, 05 Oct 2003 21:02:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01270 for ; Sun, 5 Oct 2003 21:02:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6JlK-00070B-00 for megaco@ietf.org; Sun, 05 Oct 2003 21:02:10 -0400 Received: from ish7.ericsson.com.au ([61.88.9.195]) by ietf-mx with esmtp (Exim 4.12) id 1A6JlJ-0006zz-00 for megaco@ietf.org; Sun, 05 Oct 2003 21:02:10 -0400 Received: from eaubrnt019.epa.ericsson.se ([146.11.31.193]) by ish7.ericsson.com.au (8.11.7+Sun/8.11.7) with ESMTP id h960wnt01407; Mon, 6 Oct 2003 10:58:49 +1000 (EST) Received: from ericsson.com.au (146.11.245.220 [146.11.245.220]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SYC16W2Z; Mon, 6 Oct 2003 11:00:47 +1000 Message-ID: <3F80BDFF.7070409@ericsson.com.au> Date: Mon, 06 Oct 2003 10:57:35 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Boyle CC: Aleksandr Ryabin , megaco@ietf.org Subject: Re: [Megaco] CAS Metering Pulse support References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit G'Day Kevin, If we do have an amendment then I think some text needs to be changed in the original to make it very clear that it does not detect pulses. I think as the current text stands one could be forgiven for misinterpereting whether this is possible or not. Cheers, Christian Kevin Boyle wrote: > I have no problem with producing an amendment to H.248.26. There really is > no need for us to produce 1000 recommendations with 1 package each. > > Kevin > > -----Original Message----- > From: Aleksandr Ryabin [mailto:kengr@motorola.com] > Sent: Friday, October 03, 2003 11:21 AM > To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org > Cc: Christian Groves > Subject: RE: [Megaco] CAS Metering Pulse support > > > Hi, > > Sounds reasonable. Except that it probably should not be an extension since > an application might be needing detection only and no generation. That is it > should be then a standalone metd ("Metering Detection Package"). > > Since amet and metd are complimentary I think it would be reasonable to keep > them together, that is to a amend H.248.26 to include it. > > Would you as the editor of H.248.26 recommend amending it to include new > metd or rather have new H.248.metd, or something else? > > I can provide a baseline text, if necessary. > > Regards, > Aleks > > At 09:34 AM 10/3/2003, Kevin Boyle wrote: > >>The amet package was never designed to do pulse detection. The pr >>event is meant to allow the MGC to stay updated with the actual number >>of pulses applied -- it has nothing to do with pulses detected. This >>allows the MGC to have an accurate view of the number of pulses >>applied, rather than guessing -- and possibly being wrong due to >>network latency, message loss, retransmission, etc., etc., etc. I >>think shoehorning detection in here isn't really appropriate. >> >>Further, are we sure that ALL pulse generation applications will be >>required to detect pulses? In the analog line case, the MG has no >>reason to detect pulses -- pulses are being sent to the CPE for the >>end-user's benefit. I think that it would be far wiser to define an >>extension package to handle detection, and not subject applications >>that only want to do generation to doing detection as well. >> >>Kevin >> >>-----Original Message----- >>From: Christian Groves [mailto:Christian.Groves@ericsson.com.au] >>Sent: Thursday, October 02, 2003 11:38 PM >>To: Aleksandr Ryabin >>Cc: megaco@ietf.org; Boyle, Kevin [NCRTP:3Z40:EXCH] >>Subject: Re: [Megaco] CAS Metering Pulse support >> >> >>Hello Aleksandr, >> >>I'm happy enough to have the your proposed amendment if the editor >>agrees. >> >>Regards, Christian >> >>Aleksandr Ryabin wrote: >> >>>Hi Christian, >>> >>>No description of the event does say how to use it for detection >>>incoming metering pulse. More over it explicitly limits to >>>generation: "This event is used in conjunction with the "enable >>>metering" and "metering pulse burst" signals defined in this >>>package..." >>> >>>My point being that descriptions of amet events and statistics are >>>siting that event pr is generated and statistics are changed only >>>based on previously applied em, or mbp signal. >>> >>>The wording needs to be amended to cover the cases when event is >>>generated and statistics are changed as a result *detection* of >>>incoming metering pulse. >>> >>>That is, for example, the text you have referenced should be changed >>>to something like this (I've placed the changes in [] for >>>visibility): >>> >>>"If following the application [or detection] of any metering pulse >>>(regardless of [whether it was detected, or] whether it was >>>generated as a result of the signal em or as a result of the signal >>>mbp), the EventsDescriptor contains the event pr, and if the value >>>of pcslr is equal to the value of the >>>EventsDescriptor parameter rp, then the pr event shall be notified, and >>>the value of the statistic pcslr shall be reset to zero. The detection > > of > >>>the event pr shall not cause the termination of the signal em or the >>>signal mbp, [if currently active,] even if the KeepActive flag is not >>>set for the pr event." >>> >>>Regards, >>> Aleks >>> >>>At 07:46 PM 10/2/2003, Christian Groves wrote: >>> >>> >>>>Hello Aleksandr, >>>> >>>>I agree that no new package is needed for the detection of metering >>>>pulse functionality. From the description of the event it seems >>>>that it clear how it to be used. >>>> >>>>The package also contains the procedural text: >>>>"If following the application of any metering pulse (regardless of >>>>whether it was generated as a result of the signal em or as a >>>>result of the signal mbp), the EventsDescriptor contains the event >>>>pr, and if the value of pcslr is equal to the value of the >>>>EventsDescriptor parameter rp, then the pr event shall be notified, >>>>and the value of the statistic pcslr shall be reset to zero. The >>>>detection of the event pr shall not cause the termination of the >>>>signal em or the signal mbp, even if the KeepActive flag is not set >>>>for the pr event." >>>> >>>>Is this text sufficient? >>>> >>>>Regards, Christian >>>> >>>>Aleksandr Ryabin wrote: >>>> >>>> >>>>>Hi, >>>>>In continuation to this metering pulse support. >>>>>I've looked through amet package and it does not seem to define >>>>>procedure to detect metering pulses, it only has a procedure to >>>>>generate metering pulses. I see no reason of defining a new >>>>>package for detecting incoming metering pulses and I propose to >>>>>reuse amet and amend it to define procedure for detecting incoming >>>>>metering pulses. Here is the summary of a proposed metering pulse >>>>>detection procedure using amet package: The detection of metering >>>>>pulse on a termination could be enabled by MGC when no amet >>>>>signals are played on a termination by requesting detection >>>>>amet/pr event with a required repetition period. MG would Notify >>>>>MGC with amet/pr event when number of metering pulses is detected >>>>>according to repetition period parameter set. On Subtract, or >>>>>explicit AuditValue MG would send amet/cpc and amet/pcslr >>>>>statistics similar to as described in the package provided their >>>>>description extended to detection as well. Comments? >>>>>Thanks >>>>> Aleks >>>>>BTW IANA MEGACO page is still not updated. >>>>>At 10:50 AM 9/16/2003, Aleksandr Ryabin wrote: >>>>> >>>>> >>>>>>It is updated with H.248.22 and 25, but not with 23, 24, 26, 27 >>>>>>while all of them are dated in ITU the same. Strange. >>>>>> Aleks >>>>>> >>>>>>At 10:46 AM 9/16/2003, Kevin Boyle wrote: >>>>>> >>>>>> >>>>>>>If it is NOT updated, that is. (Apparently, it's going to be one >>>>>>>of those days!) >>>>>>> >>>>>>>Kevin >>>>>>> >>>>>>>-----Original Message----- >>>>>>>From: Boyle, Kevin [NCRTP:3Z40:EXCH] >>>>>>>Sent: Tuesday, September 16, 2003 10:39 AM >>>>>>>To: Aleksandr Ryabin; megaco@ietf.org >>>>>>>Subject: RE: [Megaco] CAS Metering Pulse support >>>>>>> >>>>>>>Ummm... yeah. That's what I get for not looking it up before >>>>>>>sending the message. :) While amet is defined in the "Extended >>>>>>>Analog Lines Packages" doc, there is nothing in the amet package >>>>>>>that actually limits it to analog lines. >>>>>>> >>>>>>> >>>>>>>The updates for all the new (as of May) H.248 Sub-series >>>>>>>Recommendations have already been requested of IANA. If it is >>>>>>>updated by the end of the month, I'll ping them again. >>>>>>> >>>>>>> >>>>>>>Kevin >>>>>>> >>>>>>>-----Original Message----- >>>>>>>From: Aleksandr Ryabin [mailto:kengr@motorola.com] >>>>>>>Sent: Tuesday, September 16, 2003 10:32 AM >>>>>>>To: Boyle, Kevin [NCRTP:3Z40:EXCH]; megaco@ietf.org >>>>>>>Subject: RE: [Megaco] CAS Metering Pulse support >>>>>>> >>>>>>>Hi, >>>>>>> >>>>>>>I guess you meant H.248.26. >>>>>>>Yes it seem to address the needs assuming it is extended to >>>>>>>digital lines as well. >>>>>>> >>>>>>>BTW IANA registry should be updated with H.248.26 and H.248.27 >>>>>>>http://www.iana.org/assignments/megaco-h248 >>>>>>> >>>>>>> >>>>>>>Thanks, >>>>>>> Aleks >>>>>>> >>>>>>>At 10:00 AM 9/16/2003, Kevin Boyle wrote: >>>>>>> >>>>>>> >>>>>>>H.248.27 has a metering package (automatic metering package or >>>>>>>amet). This package may address your needs. >>>>>>> >>>>>>>Kevin >>>>>>> >>>>>>>-----Original Message----- >>>>>>>From: Aleksandr Ryabin [mailto:kengr@motorola.com >>>>>>> ] >>>>>>>Sent: Tuesday, September 16, 2003 9:34 AM >>>>>>>To: megaco@ietf.org >>>>>>>Subject: [Megaco] CAS Metering Pulse support >>>>>>> >>>>>>>Hi all, >>>>>>> >>>>>>>Below are excerpts from a previous exchange related to defining >>>>>>>of CAS Metering Pulse procedures in MEGACO. >>>>>>> >>>>>>>Now that CAS packages related work has been moved to ITU has >>>>>>>anyone done and/or planned anything in the direction to define >>>>>>>CAS Metering Pulse procedures/package for MEGACO? >>>>>>> >>>>>>>Thanks >>>>>>> Aleks >>>>>>> >>>>>>> >>>>>>>>From: klaha@hss.hns.com >>>>>>>>To: Aleksandr Ryabin >>>>>>>>cc: vnair@hss.hns.com, megaco@ietf.org, klaha@hss.hns.com >>>>>>>>Date: Tue, 4 Mar 2003 12:47:37 +0530 >>>>>>>>Subject: Re: [Megaco] Re: draft-ietf-megaco-r2package-03.txt : >>>>>>> >>>>>>>Difference >>>>>>> >>>>>>>> from previous revision >>>>>>> >>>>>>>... >>>>>>> >>>>>>>>Aleksandr Ryabin on 03/03/2003 10:43:20 >>>>>>>>PM >>>>>>> >>>>>>>... >>>>>>> >>>>>>>>3. I can't seem to find a way to implement "Metering Pulse" >>>>>>>>procedure defined for some R2 variants using ether bcas or R2 >>>>>>>>packages? For example, one of the definitions of such a pulse >>>>>>>>is a "seizure ack" pulse from a terminating end on a circuit in >>>>>>>>connected/answer state. >>>>>>>> >>>>>>>>[Kushanava] Metering is not specific to R2. It may be present >>>>>>>>in any CAS signaling. Moreover not all flavours of R2 permit >>>>>>>>metering to be mandatory. There should be therefore a general >>>>>>>>philosophy of >>>>>>> >>>>>>>attacking >>>>>>> >>>>>>>>this problem common to all CAS signaling. The solution should >>>>>>>>be sensitive to >>>>>>>>a) Realizing that MGC is the master for collecting and >>>>>>>>generating >>>>>>> >>>>>>>charging >>>>>>> >>>>>>>>information >>>>>>>>b) Interworking of the CAS "metering pulse" signals with other >>>>>>> >>>>>>>signaling >>>>>>> >>>>>>>>(both PDN and PSTN) >>>>>>>>c) Optimizing the network traffic if metering information is >>>>>>> >>>>>>>transported to >>>>>>> >>>>>>> >>>>>>>>and fro between MGC and MG >>>>>>>>d) Latency, if metering information is transported to and fro >>>>>>> >>>>>>>between MGC >>>>>>> >>>>>>>>and MG >>>>>>>>We are working towards a separate package that addresses this >>>>>>>>issue. Any suggestions? >>>>>>> >>>>>>>... >>>>>>> >>>>>>>_______________________________________________ >>>>>>>Megaco mailing list >>>>>>>Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco >>>>>>> >>>>>>>_______________________________________________ >>>>>>>Megaco mailing list >>>>>>>Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco >>> >>> > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Oct 6 08:10:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26701 for ; Mon, 6 Oct 2003 08:10:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6UBf-0002Pu-0U; Mon, 06 Oct 2003 08:10:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5V5W-0005LK-49 for megaco@optimus.ietf.org; Fri, 03 Oct 2003 14:55:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20361 for ; Fri, 3 Oct 2003 14:55:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5V5T-0004r8-00 for megaco@ietf.org; Fri, 03 Oct 2003 14:55:35 -0400 Received: from web40907.mail.yahoo.com ([66.218.78.204]) by ietf-mx with smtp (Exim 4.12) id 1A5V5S-0004qX-00 for megaco@ietf.org; Fri, 03 Oct 2003 14:55:34 -0400 Message-ID: <20031003185504.30844.qmail@web40907.mail.yahoo.com> Received: from [128.107.253.40] by web40907.mail.yahoo.com via HTTP; Fri, 03 Oct 2003 11:55:04 PDT Date: Fri, 3 Oct 2003 11:55:04 -0700 (PDT) From: Kushanava Laha Reply-To: klaha@hss.hns.com Subject: RE: [Megaco] CAS Metering Pulse support To: "Soncodi, Adrian" , Christian Groves , Aleksandr Ryabin Cc: megaco@ietf.org, Kevin Boyle In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , All, The primary reason why MGC is involved in CAS metering is because it may need to do the billing. In which case, metering pulse 'detection' on CAS trunks is the only thing that it would be interested in and that too the bulk aggregation of pulses at the end of the call. So a simple stats property on the CAS termination should serve the purpose (without the need of MGC having to 'instruct' how the MG should collect the pulses or how it should report the accumulated pulses). At end of the call, MGC 'reads' the stats through Subtract or explicit audits. Secondly, in a pure CAS network, pulses traverse end-to-end and it is usually a toll CAS exchange that generates the pulses. Now, if one has CAS MGs in the path, then the MGs should be capable of propagating the metering pulses end-to-end. One way of doing this is to have MGs propagate the metering pulses on RTP - similar to RFC 2833 (as Adrian agrees). So the metering-receiving MG converts the CAS metering pulses to RTP special payload packets and the metering-transmitting MG regenerates the CAS metering pulses from the RTP special payload packets. The other way to do the same and also desired in other interworking scenarios would be the out-of-band propagation of the metering pulse via MGC. In order to do so, the minimal information that needs to be known by the MGC are a) Notification that MG has started receiving pulses and the periodicity of the pulses b) Update notifications from MG, when the pulse periodicity changes e.g time-of-day transition. Therefore, the metering-receiving MG must implement a process of 'learning' the metering periodicity and notify whenever there is a change (MG can notify a default periodicity in the beginning so that charging corresponding to the first couple of pulses are not lost). Based on these two information, MGC can recreate or regenerate the metering pulse information on the other MG. On the metering-transmitting CAS MG if the metering pulse needs to be applied out-of-band via the MGC, MGC should be equipped with the metering pulse application package. In same lines, the minimal information that needs to be applied to the CAS MG are (a) Start generating pulses at periodicity 'x' (b) Updates of the new periodicity, whenever the period changes. On the transmitting MG there also could be a statistics by which the MGC can read at the end of the call how many total pulses the MG has transmitted. This could also be used by the MGC for billing the CAS trunks of the transmitting MG. All said and done, I also feel that notification of pulse counts from both the receiving and transmitting MGs are also necessary during a call (and not just at the end of the call). This could be required by the MGC to monitor the call based on charging e.g. pre-paid calls. Hence we should retain the mechanism of MGC signaling the MG to report the pulse transmit/receive bucket when it crosses a MGC-set-threshold. The CAS metering solution should take all of the above into account. regards, Kushanava Question is why do we at all require MGC to know (detect) or apply the metering pulses in case of CAS. (1) MGC will do the billing (2) MGC needs to pass the metering --- "Soncodi, Adrian" wrote: > In some countries a tandem switch is required to > propagate meter pulses (backwards) from the outgoing > R2 trunk to the incoming R2 trunk. These pulses are > used for billing. A potential problem is that the > pulse rate may be very high, sometimes it can be a > sub-second interval. Therefore, a tandem MGC which > has a considerable number of R2 trunks will have a > big overhead for propagating meter pulses, which > will affect its call processing rate. > > So I'm wondering if anything can be done about this. > Here are two possibilities: > > 1) Allow the MG to detect meter pulses but report > them in chunks of N. By default, N=1 (report every > pulse), but the MGC could also select, say, N=10, in > which case the MG reports once every 10 pulses. (A > residual pulse count could be reported on Subtract). > This method saves a lot of NTFY messages. However, > on the other side, the MGC would be forced to > propagate the pulses as bursts-of-N, and I am not > sure a switch is allowed to transform constant-rate > pulsing into bursts. (On the other hand why not? > because it's only the total pulse count that is > relevant for charging. Time-of-day periods with > higher charging rates actually result in more meter > pulses.) > > 2) Define a mode which allows the meter pulses to be > propagated directly between MGs, without MGC > involvement, i.e. by a method similar to RFC2833. > RFC2833 does not currently have an event defined for > meter pulses, but it could be extended, since it > defines a lot of signaling-related tones anyway. In > addition to solving the NTFY messaging overhead, > this method would have the side benefit that it > would also work between two MGCs that use SIP or > BICC between them. Currently, there is no way to > transport meter pulse information in SIP or BICC, > and this would have a terrible overhead anyway. > Of course, the ability to detect meter pulses is > still required, because there is always the > possibility that the MGC must perform the > meter-pulse-based charging itself (rather than > propagate). > > Any other ideas or comments? > > Adrian Soncodi > > > > -----Original Message----- > From: Christian Groves > [mailto:Christian.Groves@ericsson.com.au] > Sent: Thursday, October 02, 2003 10:38 PM > To: Aleksandr Ryabin > Cc: megaco@ietf.org; Kevin Boyle > Subject: Re: [Megaco] CAS Metering Pulse support > > > Hello Aleksandr, > > I'm happy enough to have the your proposed amendment > if the editor agrees. > > Regards, Christian > > Aleksandr Ryabin wrote: > > Hi Christian, > > > > No description of the event does say how to use it > for detection > > incoming metering pulse. More over it explicitly > limits to generation: > > "This event is used in conjunction with the > "enable metering" and > > "metering pulse burst" signals defined in this > package..." > > > > My point being that descriptions of amet events > and statistics > > are siting that event pr is generated and > statistics are changed > > only based on previously applied em, or mbp > signal. > > > > The wording needs to be amended to cover the cases > when event > > is generated and statistics are changed as a > result *detection* of > > incoming metering pulse. > > > > That is, for example, the text you have referenced > should be changed > > to something like this (I've placed the changes in > [] for visibility): > > > > "If following the application [or detection] of > any metering pulse > > (regardless > > of [whether it was detected, or] whether it was > generated as a result > > of the signal em or as a result of the signal > mbp), the EventsDescriptor > > contains the event pr, and if the value of pcslr > is equal to the value > > of the > > EventsDescriptor parameter rp, then the pr event > shall be notified, and > > the value of the statistic pcslr shall be reset to > zero. The detection of > > the event pr shall not cause the termination of > the signal em or the > > signal mbp, [if currently active,] even if the > KeepActive flag is not > > set for the pr event." > > > > Regards, > > Aleks > > > > At 07:46 PM 10/2/2003, Christian Groves wrote: > > > >> Hello Aleksandr, > >> > >> I agree that no new package is needed for the > detection of metering > >> pulse functionality. From the description of the > event it seems that > >> it clear how it to be used. > >> > >> The package also contains the procedural text: > >> "If following the application of any metering > pulse (regardless of > >> whether it was generated as a result of the > signal em or as a result > >> of the signal mbp), the EventsDescriptor contains > the event pr, and if > >> the value of pcslr is equal to the value of the > EventsDescriptor > >> parameter rp, then the pr event shall be > notified, and the value of > >> the statistic pcslr shall be reset to zero. The > detection of the > >> event pr shall not cause the termination of the > signal em or the > >> signal mbp, even if the KeepActive flag is not > set for the pr event." > >> > >> Is this text sufficient? > >> > >> Regards, Christian > >> > >> Aleksandr Ryabin wrote: > >> > >>> Hi, > >>> In continuation to this metering pulse support. > >>> I've looked through amet package and it does not > seem to > >>> define procedure to detect metering pulses, it > only has > >>> a procedure to generate metering pulses. > >>> I see no reason of defining a new package for > detecting incoming > >>> metering pulses and I propose to reuse amet and > amend it to > >>> define procedure for detecting incoming metering > pulses. > >>> Here is the summary of a proposed metering pulse > detection > >>> procedure using amet package: > >>> The detection of metering pulse on a termination > could be enabled > >>> by MGC when no amet signals are played on a > termination by > >>> requesting detection amet/pr event with a > required repetition period. > >>> MG would Notify MGC with amet/pr event when > number of metering > >>> pulses is detected according to repetition > period parameter set. > >>> On Subtract, or explicit AuditValue MG would > send amet/cpc > >>> and amet/pcslr statistics similar to as > described in the package > >>> provided their description extended to detection > as well. > >>> Comments? > >>> Thanks > >>> Aleks > >>> BTW IANA MEGACO page is still not updated. > >>> At 10:50 AM 9/16/2003, Aleksandr Ryabin wrote: > >>> > >>>> It is updated with H.248.22 and 25, but not > with 23, 24, 26, 27 > >>>> while all of them are dated in ITU the same. > Strange. > >>>> Aleks > >>>> > >>>> At 10:46 AM 9/16/2003, Kevin Boyle wrote: > >>>> > === message truncated === ===== Kushanava Laha Hughes Software Systems __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Mon Oct 6 08:10:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26728 for ; Mon, 6 Oct 2003 08:10:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6UBj-0002T0-Rm for megaco-archive@odin.ietf.org; Mon, 06 Oct 2003 08:10:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h96CA7fG009466 for megaco-archive@odin.ietf.org; Mon, 6 Oct 2003 08:10:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6UBj-0002Sa-Ib for megaco-web-archive@optimus.ietf.org; Mon, 06 Oct 2003 08:10:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26689 for ; Mon, 6 Oct 2003 08:09:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6UBh-0004JJ-00 for megaco-web-archive@ietf.org; Mon, 06 Oct 2003 08:10:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6UBg-0004JD-00 for megaco-web-archive@ietf.org; Mon, 06 Oct 2003 08:10:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6UBg-0002Q4-3R; Mon, 06 Oct 2003 08:10:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Vc7-0007Pe-JD for megaco@optimus.ietf.org; Fri, 03 Oct 2003 15:29:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22943 for ; Fri, 3 Oct 2003 15:29:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Vc6-0005I6-00 for megaco@ietf.org; Fri, 03 Oct 2003 15:29:18 -0400 Received: from web40909.mail.yahoo.com ([66.218.78.206]) by ietf-mx with smtp (Exim 4.12) id 1A5Vc5-0005Hd-00 for megaco@ietf.org; Fri, 03 Oct 2003 15:29:17 -0400 Message-ID: <20031003192847.69054.qmail@web40909.mail.yahoo.com> Received: from [128.107.253.40] by web40909.mail.yahoo.com via HTTP; Fri, 03 Oct 2003 12:28:47 PDT Date: Fri, 3 Oct 2003 12:28:47 -0700 (PDT) From: Kushanava Laha Reply-To: klaha@hss.hns.com Subject: RE: [Megaco] CAS Metering Pulse support To: Aleksandr Ryabin , "Soncodi, Adrian" Cc: Aleksandr Ryabin , megaco@ietf.org, Kevin Boyle , Christian Groves In-Reply-To: <5.2.1.1.0.20031003151228.024f8d50@IL06EXM13.corp.mot.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Is it possible for this WG to convey this (metering pulse via RTP) as a requirement to the relevant WG? --- Aleksandr Ryabin wrote: > Hi, > > How the pulse information is relayed between MGC is > out of scope MEGACO. > Whatever MGCs use for inter MGC communication will > need to support this > information. > > Regards, > Aleks > > At 02:44 PM 10/3/2003, Soncodi, Adrian wrote: > >The pulse rate can change during the call. This is > done by the switch > >downstream, which is the TAX office, and which > changes the rate based on > >time-of-day and provisioned charge rates. This > means that the receiving MG > >would also neeed an event for pulse rate change. A > little more overhead > >will occur, but I guess it is acceptable. However, > it becomes delicate > >when the pulse rate decreases: by the time the > receiving MG detects the > >lower pulse rate, the generating MG has already > generated a number of > >extra pulses, based on the higher rate. With some > effort though, one could > >make this work. > > > >But I don't understand how the meter pulse rate can > be relayed between 2 > >MGCs that talk SIP, for example in the following > tandem-replacement solution: > > > > Local office - R2 - (MG1, MGC1) - SIP - (MGC2, > MG2) - R2 - TAX office > > > >I think an RFC2833-based solution causes less > headache. But registering a > >new RFC2833 event is outside the scope of the > MEGACO working group anyway. > >For registered events, the ability to negotiate the > 'telephone-event' > >codec is already available via MEGACO/SDP. > > > >Adrian Soncodi > > > > > >-----Original Message----- > >From: Aleksandr Ryabin [mailto:kengr@motorola.com] > >Sent: Friday, October 03, 2003 12:56 PM > >To: Soncodi, Adrian; megaco@ietf.org > >Cc: Kevin Boyle; Christian Groves > >Subject: RE: [Megaco] CAS Metering Pulse support > > > > > >Proposed new metd package will have functionality > described in 1). > > > >However I have a slightly different proposal for > relaying. > >In order to relay pulses all needed to be known is > a repetition interval, > >changes to it, if any, and when to start, and stop > metering pulses. > > > >If "receiving" MGC (the one that controls MG which > receives > >metering pulses) gets notified with this > information using new > >metd package then it can relay this information to > "generating" > >MGC (the one that controls MG which generates > metering pulses). > >Then "generating" MGC can use amet to start/stop, > or modify > >generation of metering pulses. > > > >That is in reality, if repetition interval does not > change during > >the call, "receiving" MGC will get only two > notifies per call: > >first pulse detected, > >repetition interval calculated (e.g. second pulse > detected) > > > >"Generating" MGC will need to send tree modifies: > >pulse once (when first pulse detected event is > relayed) > >pulse forever (when repetition interval received) > >stop pulse generation (when call terminates) > > > >Regards, > > Aleks > > > >At 01:12 PM 10/3/2003, Soncodi, Adrian wrote: > > >In some countries a tandem switch is required to > propagate meter pulses > > >(backwards) from the outgoing R2 trunk to the > incoming R2 trunk. These > > >pulses are used for billing. A potential problem > is that the pulse rate > > >may be very high, sometimes it can be a > sub-second interval. Therefore, a > > >tandem MGC which has a considerable number of R2 > trunks will have a big > > >overhead for propagating meter pulses, which will > affect its call > > >processing rate. > > > > > >So I'm wondering if anything can be done about > this. Here are two > > >possibilities: > > > > > >1) Allow the MG to detect meter pulses but report > them in chunks of N. By > > >default, N=1 (report every pulse), but the MGC > could also select, say, > > >N=10, in which case the MG reports once every 10 > pulses. (A residual pulse > > >count could be reported on Subtract). This method > saves a lot of NTFY > > >messages. However, on the other side, the MGC > would be forced to propagate > > >the pulses as bursts-of-N, and I am not sure a > switch is allowed to > > >transform constant-rate pulsing into bursts. (On > the other hand why not? > > >because it's only the total pulse count that is > relevant for charging. > > >Time-of-day periods with higher charging rates > actually result in more > > >meter pulses.) > > > > > >2) Define a mode which allows the meter pulses to > be propagated directly > > >between MGs, without MGC involvement, i.e. by a > method similar to RFC2833. > > >RFC2833 does not currently have an event defined > for meter pulses, but it > > >could be extended, since it defines a lot of > signaling-related tones > > >anyway. In addition to solving the NTFY messaging > overhead, this method > > >would have the side benefit that it would also > work between two MGCs that > > >use SIP or BICC between them. Currently, there is > no way to transport > > >meter pulse information in SIP or BICC, and this > would have a terrible > > >overhead anyway. > > >Of course, the ability to detect meter pulses is > still required, because > > >there is always the possibility that the MGC must > perform the > > >meter-pulse-based charging itself (rather than > propagate). > > > > > >Any other ideas or comments? > > > > > >Adrian Soncodi > > > > > > > > > > > >-----Original Message----- > > >From: Christian Groves > [mailto:Christian.Groves@ericsson.com.au] > > >Sent: Thursday, October 02, 2003 10:38 PM > > >To: Aleksandr Ryabin > > >Cc: megaco@ietf.org; Kevin Boyle > > >Subject: Re: [Megaco] CAS Metering Pulse support > > > > > > > > >Hello Aleksandr, > > > > > >I'm happy enough to have the your proposed > amendment if the editor agrees. > > > > > >Regards, Christian > > > > > >Aleksandr Ryabin wrote: > > > > Hi Christian, > > > > > > > > No description of the event does say how to > use it for detection > > > > incoming metering pulse. More over it > explicitly limits to generation: > > > > "This event is used in conjunction with the > "enable metering" and > > > > "metering pulse burst" signals defined in this > package..." > > > > > > > > My point being that descriptions of amet > events and statistics > > > > are siting that event pr is generated and > statistics are changed > > > > only based on previously applied em, or mbp > signal. > > > > > > > > The wording needs to be amended to cover the > cases === message truncated === ===== Kushanava Laha Hughes Software Systems __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Mon Oct 6 08:10:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26729 for ; Mon, 6 Oct 2003 08:10:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6UBj-0002T1-Rz for megaco-archive@odin.ietf.org; Mon, 06 Oct 2003 08:10:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h96CA7u9009471 for megaco-archive@odin.ietf.org; Mon, 6 Oct 2003 08:10:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6UBj-0002Sb-Jq for megaco-web-archive@optimus.ietf.org; Mon, 06 Oct 2003 08:10:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26687 for ; Mon, 6 Oct 2003 08:09:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6UBh-0004JG-00 for megaco-web-archive@ietf.org; Mon, 06 Oct 2003 08:10:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6UBg-0004JC-00 for megaco-web-archive@ietf.org; Mon, 06 Oct 2003 08:10:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6UBf-0002Pu-0U; Mon, 06 Oct 2003 08:10:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5V5W-0005LK-49 for megaco@optimus.ietf.org; Fri, 03 Oct 2003 14:55:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20361 for ; Fri, 3 Oct 2003 14:55:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5V5T-0004r8-00 for megaco@ietf.org; Fri, 03 Oct 2003 14:55:35 -0400 Received: from web40907.mail.yahoo.com ([66.218.78.204]) by ietf-mx with smtp (Exim 4.12) id 1A5V5S-0004qX-00 for megaco@ietf.org; Fri, 03 Oct 2003 14:55:34 -0400 Message-ID: <20031003185504.30844.qmail@web40907.mail.yahoo.com> Received: from [128.107.253.40] by web40907.mail.yahoo.com via HTTP; Fri, 03 Oct 2003 11:55:04 PDT Date: Fri, 3 Oct 2003 11:55:04 -0700 (PDT) From: Kushanava Laha Reply-To: klaha@hss.hns.com Subject: RE: [Megaco] CAS Metering Pulse support To: "Soncodi, Adrian" , Christian Groves , Aleksandr Ryabin Cc: megaco@ietf.org, Kevin Boyle In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , All, The primary reason why MGC is involved in CAS metering is because it may need to do the billing. In which case, metering pulse 'detection' on CAS trunks is the only thing that it would be interested in and that too the bulk aggregation of pulses at the end of the call. So a simple stats property on the CAS termination should serve the purpose (without the need of MGC having to 'instruct' how the MG should collect the pulses or how it should report the accumulated pulses). At end of the call, MGC 'reads' the stats through Subtract or explicit audits. Secondly, in a pure CAS network, pulses traverse end-to-end and it is usually a toll CAS exchange that generates the pulses. Now, if one has CAS MGs in the path, then the MGs should be capable of propagating the metering pulses end-to-end. One way of doing this is to have MGs propagate the metering pulses on RTP - similar to RFC 2833 (as Adrian agrees). So the metering-receiving MG converts the CAS metering pulses to RTP special payload packets and the metering-transmitting MG regenerates the CAS metering pulses from the RTP special payload packets. The other way to do the same and also desired in other interworking scenarios would be the out-of-band propagation of the metering pulse via MGC. In order to do so, the minimal information that needs to be known by the MGC are a) Notification that MG has started receiving pulses and the periodicity of the pulses b) Update notifications from MG, when the pulse periodicity changes e.g time-of-day transition. Therefore, the metering-receiving MG must implement a process of 'learning' the metering periodicity and notify whenever there is a change (MG can notify a default periodicity in the beginning so that charging corresponding to the first couple of pulses are not lost). Based on these two information, MGC can recreate or regenerate the metering pulse information on the other MG. On the metering-transmitting CAS MG if the metering pulse needs to be applied out-of-band via the MGC, MGC should be equipped with the metering pulse application package. In same lines, the minimal information that needs to be applied to the CAS MG are (a) Start generating pulses at periodicity 'x' (b) Updates of the new periodicity, whenever the period changes. On the transmitting MG there also could be a statistics by which the MGC can read at the end of the call how many total pulses the MG has transmitted. This could also be used by the MGC for billing the CAS trunks of the transmitting MG. All said and done, I also feel that notification of pulse counts from both the receiving and transmitting MGs are also necessary during a call (and not just at the end of the call). This could be required by the MGC to monitor the call based on charging e.g. pre-paid calls. Hence we should retain the mechanism of MGC signaling the MG to report the pulse transmit/receive bucket when it crosses a MGC-set-threshold. The CAS metering solution should take all of the above into account. regards, Kushanava Question is why do we at all require MGC to know (detect) or apply the metering pulses in case of CAS. (1) MGC will do the billing (2) MGC needs to pass the metering --- "Soncodi, Adrian" wrote: > In some countries a tandem switch is required to > propagate meter pulses (backwards) from the outgoing > R2 trunk to the incoming R2 trunk. These pulses are > used for billing. A potential problem is that the > pulse rate may be very high, sometimes it can be a > sub-second interval. Therefore, a tandem MGC which > has a considerable number of R2 trunks will have a > big overhead for propagating meter pulses, which > will affect its call processing rate. > > So I'm wondering if anything can be done about this. > Here are two possibilities: > > 1) Allow the MG to detect meter pulses but report > them in chunks of N. By default, N=1 (report every > pulse), but the MGC could also select, say, N=10, in > which case the MG reports once every 10 pulses. (A > residual pulse count could be reported on Subtract). > This method saves a lot of NTFY messages. However, > on the other side, the MGC would be forced to > propagate the pulses as bursts-of-N, and I am not > sure a switch is allowed to transform constant-rate > pulsing into bursts. (On the other hand why not? > because it's only the total pulse count that is > relevant for charging. Time-of-day periods with > higher charging rates actually result in more meter > pulses.) > > 2) Define a mode which allows the meter pulses to be > propagated directly between MGs, without MGC > involvement, i.e. by a method similar to RFC2833. > RFC2833 does not currently have an event defined for > meter pulses, but it could be extended, since it > defines a lot of signaling-related tones anyway. In > addition to solving the NTFY messaging overhead, > this method would have the side benefit that it > would also work between two MGCs that use SIP or > BICC between them. Currently, there is no way to > transport meter pulse information in SIP or BICC, > and this would have a terrible overhead anyway. > Of course, the ability to detect meter pulses is > still required, because there is always the > possibility that the MGC must perform the > meter-pulse-based charging itself (rather than > propagate). > > Any other ideas or comments? > > Adrian Soncodi > > > > -----Original Message----- > From: Christian Groves > [mailto:Christian.Groves@ericsson.com.au] > Sent: Thursday, October 02, 2003 10:38 PM > To: Aleksandr Ryabin > Cc: megaco@ietf.org; Kevin Boyle > Subject: Re: [Megaco] CAS Metering Pulse support > > > Hello Aleksandr, > > I'm happy enough to have the your proposed amendment > if the editor agrees. > > Regards, Christian > > Aleksandr Ryabin wrote: > > Hi Christian, > > > > No description of the event does say how to use it > for detection > > incoming metering pulse. More over it explicitly > limits to generation: > > "This event is used in conjunction with the > "enable metering" and > > "metering pulse burst" signals defined in this > package..." > > > > My point being that descriptions of amet events > and statistics > > are siting that event pr is generated and > statistics are changed > > only based on previously applied em, or mbp > signal. > > > > The wording needs to be amended to cover the cases > when event > > is generated and statistics are changed as a > result *detection* of > > incoming metering pulse. > > > > That is, for example, the text you have referenced > should be changed > > to something like this (I've placed the changes in > [] for visibility): > > > > "If following the application [or detection] of > any metering pulse > > (regardless > > of [whether it was detected, or] whether it was > generated as a result > > of the signal em or as a result of the signal > mbp), the EventsDescriptor > > contains the event pr, and if the value of pcslr > is equal to the value > > of the > > EventsDescriptor parameter rp, then the pr event > shall be notified, and > > the value of the statistic pcslr shall be reset to > zero. The detection of > > the event pr shall not cause the termination of > the signal em or the > > signal mbp, [if currently active,] even if the > KeepActive flag is not > > set for the pr event." > > > > Regards, > > Aleks > > > > At 07:46 PM 10/2/2003, Christian Groves wrote: > > > >> Hello Aleksandr, > >> > >> I agree that no new package is needed for the > detection of metering > >> pulse functionality. From the description of the > event it seems that > >> it clear how it to be used. > >> > >> The package also contains the procedural text: > >> "If following the application of any metering > pulse (regardless of > >> whether it was generated as a result of the > signal em or as a result > >> of the signal mbp), the EventsDescriptor contains > the event pr, and if > >> the value of pcslr is equal to the value of the > EventsDescriptor > >> parameter rp, then the pr event shall be > notified, and the value of > >> the statistic pcslr shall be reset to zero. The > detection of the > >> event pr shall not cause the termination of the > signal em or the > >> signal mbp, even if the KeepActive flag is not > set for the pr event." > >> > >> Is this text sufficient? > >> > >> Regards, Christian > >> > >> Aleksandr Ryabin wrote: > >> > >>> Hi, > >>> In continuation to this metering pulse support. > >>> I've looked through amet package and it does not > seem to > >>> define procedure to detect metering pulses, it > only has > >>> a procedure to generate metering pulses. > >>> I see no reason of defining a new package for > detecting incoming > >>> metering pulses and I propose to reuse amet and > amend it to > >>> define procedure for detecting incoming metering > pulses. > >>> Here is the summary of a proposed metering pulse > detection > >>> procedure using amet package: > >>> The detection of metering pulse on a termination > could be enabled > >>> by MGC when no amet signals are played on a > termination by > >>> requesting detection amet/pr event with a > required repetition period. > >>> MG would Notify MGC with amet/pr event when > number of metering > >>> pulses is detected according to repetition > period parameter set. > >>> On Subtract, or explicit AuditValue MG would > send amet/cpc > >>> and amet/pcslr statistics similar to as > described in the package > >>> provided their description extended to detection > as well. > >>> Comments? > >>> Thanks > >>> Aleks > >>> BTW IANA MEGACO page is still not updated. > >>> At 10:50 AM 9/16/2003, Aleksandr Ryabin wrote: > >>> > >>>> It is updated with H.248.22 and 25, but not > with 23, 24, 26, 27 > >>>> while all of them are dated in ITU the same. > Strange. > >>>> Aleks > >>>> > >>>> At 10:46 AM 9/16/2003, Kevin Boyle wrote: > >>>> > === message truncated === ===== Kushanava Laha Hughes Software Systems __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Oct 6 08:35:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27485 for ; Mon, 6 Oct 2003 08:35:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6UZq-0003XF-TG; Mon, 06 Oct 2003 08:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6UZ6-0003WV-RX for megaco@optimus.ietf.org; Mon, 06 Oct 2003 08:34:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27470 for ; Mon, 6 Oct 2003 08:34:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6UZ5-0004b8-00 for megaco@ietf.org; Mon, 06 Oct 2003 08:34:15 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1A6UZ5-0004at-00 for megaco@ietf.org; Mon, 06 Oct 2003 08:34:15 -0400 Received: from zcard307.ca.nortel.com (americasm07.nt.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h96CXbd08290; Mon, 6 Oct 2003 08:33:37 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZX22AVQ; Mon, 6 Oct 2003 08:33:37 -0400 Received: from nortelnetworks.com (acart1e5.ca.nortel.com [47.129.129.114]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZW5NBDZ; Mon, 6 Oct 2003 08:33:37 -0400 Message-ID: <3F816120.7050500@nortelnetworks.com> Date: Mon, 06 Oct 2003 08:33:36 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: megaco@ietf.org CC: NuritS@audiocodes.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Megaco] Problem in H.248.2 in 'ctyp' package Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Sent on behalf of Nurit Shenhar . Hi list I am not sure if it was raised before, but in H.248.2 in the Call Type Discrimination package there are two properties with the same text in the names: What should be the name of the second one? */ /* */Nurit Shenhar/* */H.248 Prime/* ** E-Mail: nurit.shenhar@audiocodes.com Fax. +972-3-5394223 www.audiocodes.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Mon Oct 6 08:35:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27500 for ; Mon, 6 Oct 2003 08:35:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6UZs-0003Yd-RE for megaco-archive@odin.ietf.org; Mon, 06 Oct 2003 08:35:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h96CZ4Bs013633 for megaco-archive@odin.ietf.org; Mon, 6 Oct 2003 08:35:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6UZs-0003Xf-KJ for megaco-web-archive@optimus.ietf.org; Mon, 06 Oct 2003 08:35:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27474 for ; Mon, 6 Oct 2003 08:34:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6UZr-0004bP-00 for megaco-web-archive@ietf.org; Mon, 06 Oct 2003 08:35:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6UZr-0004bM-00 for megaco-web-archive@ietf.org; Mon, 06 Oct 2003 08:35:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6UZq-0003XF-TG; Mon, 06 Oct 2003 08:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6UZ6-0003WV-RX for megaco@optimus.ietf.org; Mon, 06 Oct 2003 08:34:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27470 for ; Mon, 6 Oct 2003 08:34:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6UZ5-0004b8-00 for megaco@ietf.org; Mon, 06 Oct 2003 08:34:15 -0400 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1A6UZ5-0004at-00 for megaco@ietf.org; Mon, 06 Oct 2003 08:34:15 -0400 Received: from zcard307.ca.nortel.com (americasm07.nt.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h96CXbd08290; Mon, 6 Oct 2003 08:33:37 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZX22AVQ; Mon, 6 Oct 2003 08:33:37 -0400 Received: from nortelnetworks.com (acart1e5.ca.nortel.com [47.129.129.114]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZW5NBDZ; Mon, 6 Oct 2003 08:33:37 -0400 Message-ID: <3F816120.7050500@nortelnetworks.com> Date: Mon, 06 Oct 2003 08:33:36 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: megaco@ietf.org CC: NuritS@audiocodes.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Megaco] Problem in H.248.2 in 'ctyp' package Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sent on behalf of Nurit Shenhar . Hi list I am not sure if it was raised before, but in H.248.2 in the Call Type Discrimination package there are two properties with the same text in the names: What should be the name of the second one? */ /* */Nurit Shenhar/* */H.248 Prime/* ** E-Mail: nurit.shenhar@audiocodes.com Fax. +972-3-5394223 www.audiocodes.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Oct 6 09:00:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26702 for ; Mon, 6 Oct 2003 08:10:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6UBg-0002Q4-3R; Mon, 06 Oct 2003 08:10:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Vc7-0007Pe-JD for megaco@optimus.ietf.org; Fri, 03 Oct 2003 15:29:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22943 for ; Fri, 3 Oct 2003 15:29:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Vc6-0005I6-00 for megaco@ietf.org; Fri, 03 Oct 2003 15:29:18 -0400 Received: from web40909.mail.yahoo.com ([66.218.78.206]) by ietf-mx with smtp (Exim 4.12) id 1A5Vc5-0005Hd-00 for megaco@ietf.org; Fri, 03 Oct 2003 15:29:17 -0400 Message-ID: <20031003192847.69054.qmail@web40909.mail.yahoo.com> Received: from [128.107.253.40] by web40909.mail.yahoo.com via HTTP; Fri, 03 Oct 2003 12:28:47 PDT Date: Fri, 3 Oct 2003 12:28:47 -0700 (PDT) From: Kushanava Laha Reply-To: klaha@hss.hns.com Subject: RE: [Megaco] CAS Metering Pulse support To: Aleksandr Ryabin , "Soncodi, Adrian" Cc: Aleksandr Ryabin , megaco@ietf.org, Kevin Boyle , Christian Groves In-Reply-To: <5.2.1.1.0.20031003151228.024f8d50@IL06EXM13.corp.mot.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Is it possible for this WG to convey this (metering pulse via RTP) as a requirement to the relevant WG? --- Aleksandr Ryabin wrote: > Hi, > > How the pulse information is relayed between MGC is > out of scope MEGACO. > Whatever MGCs use for inter MGC communication will > need to support this > information. > > Regards, > Aleks > > At 02:44 PM 10/3/2003, Soncodi, Adrian wrote: > >The pulse rate can change during the call. This is > done by the switch > >downstream, which is the TAX office, and which > changes the rate based on > >time-of-day and provisioned charge rates. This > means that the receiving MG > >would also neeed an event for pulse rate change. A > little more overhead > >will occur, but I guess it is acceptable. However, > it becomes delicate > >when the pulse rate decreases: by the time the > receiving MG detects the > >lower pulse rate, the generating MG has already > generated a number of > >extra pulses, based on the higher rate. With some > effort though, one could > >make this work. > > > >But I don't understand how the meter pulse rate can > be relayed between 2 > >MGCs that talk SIP, for example in the following > tandem-replacement solution: > > > > Local office - R2 - (MG1, MGC1) - SIP - (MGC2, > MG2) - R2 - TAX office > > > >I think an RFC2833-based solution causes less > headache. But registering a > >new RFC2833 event is outside the scope of the > MEGACO working group anyway. > >For registered events, the ability to negotiate the > 'telephone-event' > >codec is already available via MEGACO/SDP. > > > >Adrian Soncodi > > > > > >-----Original Message----- > >From: Aleksandr Ryabin [mailto:kengr@motorola.com] > >Sent: Friday, October 03, 2003 12:56 PM > >To: Soncodi, Adrian; megaco@ietf.org > >Cc: Kevin Boyle; Christian Groves > >Subject: RE: [Megaco] CAS Metering Pulse support > > > > > >Proposed new metd package will have functionality > described in 1). > > > >However I have a slightly different proposal for > relaying. > >In order to relay pulses all needed to be known is > a repetition interval, > >changes to it, if any, and when to start, and stop > metering pulses. > > > >If "receiving" MGC (the one that controls MG which > receives > >metering pulses) gets notified with this > information using new > >metd package then it can relay this information to > "generating" > >MGC (the one that controls MG which generates > metering pulses). > >Then "generating" MGC can use amet to start/stop, > or modify > >generation of metering pulses. > > > >That is in reality, if repetition interval does not > change during > >the call, "receiving" MGC will get only two > notifies per call: > >first pulse detected, > >repetition interval calculated (e.g. second pulse > detected) > > > >"Generating" MGC will need to send tree modifies: > >pulse once (when first pulse detected event is > relayed) > >pulse forever (when repetition interval received) > >stop pulse generation (when call terminates) > > > >Regards, > > Aleks > > > >At 01:12 PM 10/3/2003, Soncodi, Adrian wrote: > > >In some countries a tandem switch is required to > propagate meter pulses > > >(backwards) from the outgoing R2 trunk to the > incoming R2 trunk. These > > >pulses are used for billing. A potential problem > is that the pulse rate > > >may be very high, sometimes it can be a > sub-second interval. Therefore, a > > >tandem MGC which has a considerable number of R2 > trunks will have a big > > >overhead for propagating meter pulses, which will > affect its call > > >processing rate. > > > > > >So I'm wondering if anything can be done about > this. Here are two > > >possibilities: > > > > > >1) Allow the MG to detect meter pulses but report > them in chunks of N. By > > >default, N=1 (report every pulse), but the MGC > could also select, say, > > >N=10, in which case the MG reports once every 10 > pulses. (A residual pulse > > >count could be reported on Subtract). This method > saves a lot of NTFY > > >messages. However, on the other side, the MGC > would be forced to propagate > > >the pulses as bursts-of-N, and I am not sure a > switch is allowed to > > >transform constant-rate pulsing into bursts. (On > the other hand why not? > > >because it's only the total pulse count that is > relevant for charging. > > >Time-of-day periods with higher charging rates > actually result in more > > >meter pulses.) > > > > > >2) Define a mode which allows the meter pulses to > be propagated directly > > >between MGs, without MGC involvement, i.e. by a > method similar to RFC2833. > > >RFC2833 does not currently have an event defined > for meter pulses, but it > > >could be extended, since it defines a lot of > signaling-related tones > > >anyway. In addition to solving the NTFY messaging > overhead, this method > > >would have the side benefit that it would also > work between two MGCs that > > >use SIP or BICC between them. Currently, there is > no way to transport > > >meter pulse information in SIP or BICC, and this > would have a terrible > > >overhead anyway. > > >Of course, the ability to detect meter pulses is > still required, because > > >there is always the possibility that the MGC must > perform the > > >meter-pulse-based charging itself (rather than > propagate). > > > > > >Any other ideas or comments? > > > > > >Adrian Soncodi > > > > > > > > > > > >-----Original Message----- > > >From: Christian Groves > [mailto:Christian.Groves@ericsson.com.au] > > >Sent: Thursday, October 02, 2003 10:38 PM > > >To: Aleksandr Ryabin > > >Cc: megaco@ietf.org; Kevin Boyle > > >Subject: Re: [Megaco] CAS Metering Pulse support > > > > > > > > >Hello Aleksandr, > > > > > >I'm happy enough to have the your proposed > amendment if the editor agrees. > > > > > >Regards, Christian > > > > > >Aleksandr Ryabin wrote: > > > > Hi Christian, > > > > > > > > No description of the event does say how to > use it for detection > > > > incoming metering pulse. More over it > explicitly limits to generation: > > > > "This event is used in conjunction with the > "enable metering" and > > > > "metering pulse burst" signals defined in this > package..." > > > > > > > > My point being that descriptions of amet > events and statistics > > > > are siting that event pr is generated and > statistics are changed > > > > only based on previously applied em, or mbp > signal. > > > > > > > > The wording needs to be amended to cover the > cases === message truncated === ===== Kushanava Laha Hughes Software Systems __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Mon Oct 6 09:55:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00520 for ; Mon, 6 Oct 2003 09:55:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6VpH-0006nx-3y; Mon, 06 Oct 2003 09:55:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6Vov-0006n1-QI for megaco@optimus.ietf.org; Mon, 06 Oct 2003 09:54:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00463 for ; Mon, 6 Oct 2003 09:54:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6Vot-0005Vw-00 for megaco@ietf.org; Mon, 06 Oct 2003 09:54:39 -0400 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1A6Vot-0005VZ-00 for megaco@ietf.org; Mon, 06 Oct 2003 09:54:39 -0400 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h96Ds7L21446 for ; Mon, 6 Oct 2003 09:54:07 -0400 (EDT) Received: from zrtpd0jh.us.nortel.com ([47.140.202.34]) by zrtpd0j7.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZYHBAM5; Mon, 6 Oct 2003 09:54:07 -0400 Received: by zrtpd0jh.us.nortel.com with Internet Mail Service (5.5.2653.19) id <41VA5KFX>; Mon, 6 Oct 2003 09:54:07 -0400 Message-ID: X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Kevin Boyle" To: "Tom-PT Taylor" , megaco@ietf.org Cc: NuritS@audiocodes.com Subject: RE: [Megaco] Problem in H.248.2 in 'ctyp' package Date: Mon, 6 Oct 2003 09:54:05 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , See item 7.6 in the IG. The PhaseReversalDetect property has been corrected to PropertyID phrevdet. Kevin -----Original Message----- From: Taylor, Tom-PT [CAR:5N00:EXCH] Sent: Monday, October 06, 2003 8:34 AM To: megaco@ietf.org Cc: NuritS@audiocodes.com Subject: [Megaco] Problem in H.248.2 in 'ctyp' package Sent on behalf of Nurit Shenhar . Hi list I am not sure if it was raised before, but in H.248.2 in the Call Type Discrimination package there are two properties with the same text in the names: What should be the name of the second one? */ /* */Nurit Shenhar/* */H.248 Prime/* ** E-Mail: nurit.shenhar@audiocodes.com Fax. +972-3-5394223 www.audiocodes.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 exim@www1.ietf.org Mon Oct 6 09:55:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00537 for ; Mon, 6 Oct 2003 09:55:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6VpM-0006pe-Ia for megaco-archive@odin.ietf.org; Mon, 06 Oct 2003 09:55:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h96Dt8wn026252 for megaco-archive@odin.ietf.org; Mon, 6 Oct 2003 09:55:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6VpM-0006om-BB for megaco-web-archive@optimus.ietf.org; Mon, 06 Oct 2003 09:55:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00477 for ; Mon, 6 Oct 2003 09:54:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6VpK-0005WQ-00 for megaco-web-archive@ietf.org; Mon, 06 Oct 2003 09:55:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6VpJ-0005WN-00 for megaco-web-archive@ietf.org; Mon, 06 Oct 2003 09:55:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6VpH-0006nx-3y; Mon, 06 Oct 2003 09:55:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6Vov-0006n1-QI for megaco@optimus.ietf.org; Mon, 06 Oct 2003 09:54:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00463 for ; Mon, 6 Oct 2003 09:54:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6Vot-0005Vw-00 for megaco@ietf.org; Mon, 06 Oct 2003 09:54:39 -0400 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1A6Vot-0005VZ-00 for megaco@ietf.org; Mon, 06 Oct 2003 09:54:39 -0400 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h96Ds7L21446 for ; Mon, 6 Oct 2003 09:54:07 -0400 (EDT) Received: from zrtpd0jh.us.nortel.com ([47.140.202.34]) by zrtpd0j7.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZYHBAM5; Mon, 6 Oct 2003 09:54:07 -0400 Received: by zrtpd0jh.us.nortel.com with Internet Mail Service (5.5.2653.19) id <41VA5KFX>; Mon, 6 Oct 2003 09:54:07 -0400 Message-ID: X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Kevin Boyle" To: "Tom-PT Taylor" , megaco@ietf.org Cc: NuritS@audiocodes.com Subject: RE: [Megaco] Problem in H.248.2 in 'ctyp' package Date: Mon, 6 Oct 2003 09:54:05 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , See item 7.6 in the IG. The PhaseReversalDetect property has been corrected to PropertyID phrevdet. Kevin -----Original Message----- From: Taylor, Tom-PT [CAR:5N00:EXCH] Sent: Monday, October 06, 2003 8:34 AM To: megaco@ietf.org Cc: NuritS@audiocodes.com Subject: [Megaco] Problem in H.248.2 in 'ctyp' package Sent on behalf of Nurit Shenhar . Hi list I am not sure if it was raised before, but in H.248.2 in the Call Type Discrimination package there are two properties with the same text in the names: What should be the name of the second one? */ /* */Nurit Shenhar/* */H.248 Prime/* ** E-Mail: nurit.shenhar@audiocodes.com Fax. +972-3-5394223 www.audiocodes.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-admin@ietf.org Mon Oct 6 10:07:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01613 for ; Mon, 6 Oct 2003 10:07:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6W0s-0007Ad-1i; Mon, 06 Oct 2003 10:07:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6W03-00078X-1M for megaco@optimus.ietf.org; Mon, 06 Oct 2003 10:06:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01380 for ; Mon, 6 Oct 2003 10:06:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6W00-0005iY-00 for megaco@ietf.org; Mon, 06 Oct 2003 10:06:08 -0400 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1A6Vzz-0005hh-00 for megaco@ietf.org; Mon, 06 Oct 2003 10:06:08 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h96E5ZL05738 for ; Mon, 6 Oct 2003 10:05:36 -0400 (EDT) Received: from zrtpd0jh.us.nortel.com ([47.140.202.34]) by zrtpd0jn.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T9HCQV8N; Mon, 6 Oct 2003 10:05:36 -0400 Received: by zrtpd0jh.us.nortel.com with Internet Mail Service (5.5.2653.19) id <41VA5LPX>; Mon, 6 Oct 2003 10:05:36 -0400 Message-ID: X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Kevin Boyle" To: Christian Groves , klaha@hss.hns.com Cc: Aleksandr Ryabin , "Soncodi, Adrian" , megaco@ietf.org Subject: RE: [Megaco] CAS Metering Pulse support Date: Mon, 6 Oct 2003 10:05:11 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , There is a 2833-bis draft out now that proposes some extensions to the set of detectable events under RFC2833. If we want CAS metering included (and from reading all this, I think we do), then someone needs to contact the authors of the 2833-bis document and get the CAS metering stuff added. The 2833-bis draft can be found at http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2833bis-03.txt. Kevin -----Original Message----- From: Christian Groves [mailto:Christian.Groves@ericsson.com.au] Sent: Sunday, October 05, 2003 8:38 PM To: klaha@hss.hns.com Cc: Aleksandr Ryabin; Soncodi, Adrian; megaco@ietf.org; Boyle, Kevin [NCRTP:3Z40:EXCH] Subject: Re: [Megaco] CAS Metering Pulse support Hello, As Aleks said RTP is not in the scope of this working group. I believe the correct way to move this forward is to write a IETF draft of the carriage of metering pulses over RTP and submit it to the AVT WG for comment. Regards, Christian Kushanava Laha wrote: > Is it possible for this WG to convey this (metering > pulse via RTP) as a requirement to the relevant WG? > > > --- Aleksandr Ryabin wrote: > >>Hi, >> >>How the pulse information is relayed between MGC is >>out of scope MEGACO. >>Whatever MGCs use for inter MGC communication will >>need to support this >>information. >> >>Regards, >> Aleks >> >>At 02:44 PM 10/3/2003, Soncodi, Adrian wrote: >> >>>The pulse rate can change during the call. This is >> >>done by the switch >> >>>downstream, which is the TAX office, and which >> >>changes the rate based on >> >>>time-of-day and provisioned charge rates. This >> >>means that the receiving MG >> >>>would also neeed an event for pulse rate change. A >> >>little more overhead >> >>>will occur, but I guess it is acceptable. However, >> >>it becomes delicate >> >>>when the pulse rate decreases: by the time the >> >>receiving MG detects the >> >>>lower pulse rate, the generating MG has already >> >>generated a number of >> >>>extra pulses, based on the higher rate. With some >> >>effort though, one could >> >>>make this work. >>> >>>But I don't understand how the meter pulse rate can >> >>be relayed between 2 >> >>>MGCs that talk SIP, for example in the following >> >>tandem-replacement solution: >> >>> Local office - R2 - (MG1, MGC1) - SIP - (MGC2, >> >>MG2) - R2 - TAX office >> >>>I think an RFC2833-based solution causes less >> >>headache. But registering a >> >>>new RFC2833 event is outside the scope of the >> >>MEGACO working group anyway. >> >>>For registered events, the ability to negotiate the >> >>'telephone-event' >> >>>codec is already available via MEGACO/SDP. >>> >>>Adrian Soncodi >>> >>> >>>-----Original Message----- >>>From: Aleksandr Ryabin [mailto:kengr@motorola.com] >>>Sent: Friday, October 03, 2003 12:56 PM >>>To: Soncodi, Adrian; megaco@ietf.org >>>Cc: Kevin Boyle; Christian Groves >>>Subject: RE: [Megaco] CAS Metering Pulse support >>> >>> >>>Proposed new metd package will have functionality >> >>described in 1). >> >>>However I have a slightly different proposal for >> >>relaying. >> >>>In order to relay pulses all needed to be known is >> >>a repetition interval, >> >>>changes to it, if any, and when to start, and stop >> >>metering pulses. >> >>>If "receiving" MGC (the one that controls MG which >> >>receives >> >>>metering pulses) gets notified with this >> >>information using new >> >>>metd package then it can relay this information to >> >>"generating" >> >>>MGC (the one that controls MG which generates >> >>metering pulses). >> >>>Then "generating" MGC can use amet to start/stop, >> >>or modify >> >>>generation of metering pulses. >>> >>>That is in reality, if repetition interval does not >> >>change during >> >>>the call, "receiving" MGC will get only two >> >>notifies per call: >> >>>first pulse detected, >>>repetition interval calculated (e.g. second pulse >> >>detected) >> >>>"Generating" MGC will need to send tree modifies: >>>pulse once (when first pulse detected event is >> >>relayed) >> >>>pulse forever (when repetition interval received) >>>stop pulse generation (when call terminates) >>> >>>Regards, >>> Aleks >>> >>>At 01:12 PM 10/3/2003, Soncodi, Adrian wrote: >>> >>>>In some countries a tandem switch is required to >> >>propagate meter pulses >> >>>>(backwards) from the outgoing R2 trunk to the >> >>incoming R2 trunk. These >> >>>>pulses are used for billing. A potential problem >> >>is that the pulse rate >> >>>>may be very high, sometimes it can be a >> >>sub-second interval. Therefore, a >> >>>>tandem MGC which has a considerable number of R2 >> >>trunks will have a big >> >>>>overhead for propagating meter pulses, which will >> >>affect its call >> >>>>processing rate. >>>> >>>>So I'm wondering if anything can be done about >> >>this. Here are two >> >>>>possibilities: >>>> >>>>1) Allow the MG to detect meter pulses but report >> >>them in chunks of N. By >> >>>>default, N=1 (report every pulse), but the MGC >> >>could also select, say, >> >>>>N=10, in which case the MG reports once every 10 >> >>pulses. (A residual pulse >> >>>>count could be reported on Subtract). This method >> >>saves a lot of NTFY >> >>>>messages. However, on the other side, the MGC >> >>would be forced to propagate >> >>>>the pulses as bursts-of-N, and I am not sure a >> >>switch is allowed to >> >>>>transform constant-rate pulsing into bursts. (On >> >>the other hand why not? >> >>>>because it's only the total pulse count that is >> >>relevant for charging. >> >>>>Time-of-day periods with higher charging rates >> >>actually result in more >> >>>>meter pulses.) >>>> >>>>2) Define a mode which allows the meter pulses to >> >>be propagated directly >> >>>>between MGs, without MGC involvement, i.e. by a >> >>method similar to RFC2833. >> >>>>RFC2833 does not currently have an event defined >> >>for meter pulses, but it >> >>>>could be extended, since it defines a lot of >> >>signaling-related tones >> >>>>anyway. In addition to solving the NTFY messaging >> >>overhead, this method >> >>>>would have the side benefit that it would also >> >>work between two MGCs that >> >>>>use SIP or BICC between them. Currently, there is >> >>no way to transport >> >>>>meter pulse information in SIP or BICC, and this >> >>would have a terrible >> >>>>overhead anyway. >>>>Of course, the ability to detect meter pulses is >> >>still required, because >> >>>>there is always the possibility that the MGC must >> >>perform the >> >>>>meter-pulse-based charging itself (rather than >> >>propagate). >> >>>>Any other ideas or comments? >>>> >>>>Adrian Soncodi >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: Christian Groves >> >>[mailto:Christian.Groves@ericsson.com.au] >> >>>>Sent: Thursday, October 02, 2003 10:38 PM >>>>To: Aleksandr Ryabin >>>>Cc: megaco@ietf.org; Kevin Boyle >>>>Subject: Re: [Megaco] CAS Metering Pulse support >>>> >>>> >>>>Hello Aleksandr, >>>> >>>>I'm happy enough to have the your proposed >> >>amendment if the editor agrees. >> >>>>Regards, Christian >>>> >>>>Aleksandr Ryabin wrote: >>>> >>>>>Hi Christian, >>>>> >>>>>No description of the event does say how to >> >>use it for detection >> >>>>>incoming metering pulse. More over it >> >>explicitly limits to generation: >> >>>>>"This event is used in conjunction with the >> >>"enable metering" and >> >>>>>"metering pulse burst" signals defined in this >> >>package..." >> >>>>>My point being that descriptions of amet >> >>events and statistics >> >>>>>are siting that event pr is generated and >> >>statistics are changed >> >>>>>only based on previously applied em, or mbp >> >>signal. >> >>>>>The wording needs to be amended to cover the >> >>cases > > === message truncated === > > > ===== > Kushanava Laha > Hughes Software Systems > > __________________________________ > Do you Yahoo!? > The New Yahoo! Shopping - with improved product search > http://shopping.yahoo.com > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Mon Oct 6 10:07:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01632 for ; Mon, 6 Oct 2003 10:07:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6W0x-0007Dw-4X for megaco-archive@odin.ietf.org; Mon, 06 Oct 2003 10:07:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h96E7691027755 for megaco-archive@odin.ietf.org; Mon, 6 Oct 2003 10:07:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6W0v-0007DF-SU for megaco-web-archive@optimus.ietf.org; Mon, 06 Oct 2003 10:07:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01543 for ; Mon, 6 Oct 2003 10:06:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6W0t-0005jw-00 for megaco-web-archive@ietf.org; Mon, 06 Oct 2003 10:07:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6W0s-0005jq-00 for megaco-web-archive@ietf.org; Mon, 06 Oct 2003 10:07:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6W0s-0007Ad-1i; Mon, 06 Oct 2003 10:07:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6W03-00078X-1M for megaco@optimus.ietf.org; Mon, 06 Oct 2003 10:06:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01380 for ; Mon, 6 Oct 2003 10:06:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6W00-0005iY-00 for megaco@ietf.org; Mon, 06 Oct 2003 10:06:08 -0400 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1A6Vzz-0005hh-00 for megaco@ietf.org; Mon, 06 Oct 2003 10:06:08 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h96E5ZL05738 for ; Mon, 6 Oct 2003 10:05:36 -0400 (EDT) Received: from zrtpd0jh.us.nortel.com ([47.140.202.34]) by zrtpd0jn.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T9HCQV8N; Mon, 6 Oct 2003 10:05:36 -0400 Received: by zrtpd0jh.us.nortel.com with Internet Mail Service (5.5.2653.19) id <41VA5LPX>; Mon, 6 Oct 2003 10:05:36 -0400 Message-ID: X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Kevin Boyle" To: Christian Groves , klaha@hss.hns.com Cc: Aleksandr Ryabin , "Soncodi, Adrian" , megaco@ietf.org Subject: RE: [Megaco] CAS Metering Pulse support Date: Mon, 6 Oct 2003 10:05:11 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , There is a 2833-bis draft out now that proposes some extensions to the set of detectable events under RFC2833. If we want CAS metering included (and from reading all this, I think we do), then someone needs to contact the authors of the 2833-bis document and get the CAS metering stuff added. The 2833-bis draft can be found at http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2833bis-03.txt. Kevin -----Original Message----- From: Christian Groves [mailto:Christian.Groves@ericsson.com.au] Sent: Sunday, October 05, 2003 8:38 PM To: klaha@hss.hns.com Cc: Aleksandr Ryabin; Soncodi, Adrian; megaco@ietf.org; Boyle, Kevin [NCRTP:3Z40:EXCH] Subject: Re: [Megaco] CAS Metering Pulse support Hello, As Aleks said RTP is not in the scope of this working group. I believe the correct way to move this forward is to write a IETF draft of the carriage of metering pulses over RTP and submit it to the AVT WG for comment. Regards, Christian Kushanava Laha wrote: > Is it possible for this WG to convey this (metering > pulse via RTP) as a requirement to the relevant WG? > > > --- Aleksandr Ryabin wrote: > >>Hi, >> >>How the pulse information is relayed between MGC is >>out of scope MEGACO. >>Whatever MGCs use for inter MGC communication will >>need to support this >>information. >> >>Regards, >> Aleks >> >>At 02:44 PM 10/3/2003, Soncodi, Adrian wrote: >> >>>The pulse rate can change during the call. This is >> >>done by the switch >> >>>downstream, which is the TAX office, and which >> >>changes the rate based on >> >>>time-of-day and provisioned charge rates. This >> >>means that the receiving MG >> >>>would also neeed an event for pulse rate change. A >> >>little more overhead >> >>>will occur, but I guess it is acceptable. However, >> >>it becomes delicate >> >>>when the pulse rate decreases: by the time the >> >>receiving MG detects the >> >>>lower pulse rate, the generating MG has already >> >>generated a number of >> >>>extra pulses, based on the higher rate. With some >> >>effort though, one could >> >>>make this work. >>> >>>But I don't understand how the meter pulse rate can >> >>be relayed between 2 >> >>>MGCs that talk SIP, for example in the following >> >>tandem-replacement solution: >> >>> Local office - R2 - (MG1, MGC1) - SIP - (MGC2, >> >>MG2) - R2 - TAX office >> >>>I think an RFC2833-based solution causes less >> >>headache. But registering a >> >>>new RFC2833 event is outside the scope of the >> >>MEGACO working group anyway. >> >>>For registered events, the ability to negotiate the >> >>'telephone-event' >> >>>codec is already available via MEGACO/SDP. >>> >>>Adrian Soncodi >>> >>> >>>-----Original Message----- >>>From: Aleksandr Ryabin [mailto:kengr@motorola.com] >>>Sent: Friday, October 03, 2003 12:56 PM >>>To: Soncodi, Adrian; megaco@ietf.org >>>Cc: Kevin Boyle; Christian Groves >>>Subject: RE: [Megaco] CAS Metering Pulse support >>> >>> >>>Proposed new metd package will have functionality >> >>described in 1). >> >>>However I have a slightly different proposal for >> >>relaying. >> >>>In order to relay pulses all needed to be known is >> >>a repetition interval, >> >>>changes to it, if any, and when to start, and stop >> >>metering pulses. >> >>>If "receiving" MGC (the one that controls MG which >> >>receives >> >>>metering pulses) gets notified with this >> >>information using new >> >>>metd package then it can relay this information to >> >>"generating" >> >>>MGC (the one that controls MG which generates >> >>metering pulses). >> >>>Then "generating" MGC can use amet to start/stop, >> >>or modify >> >>>generation of metering pulses. >>> >>>That is in reality, if repetition interval does not >> >>change during >> >>>the call, "receiving" MGC will get only two >> >>notifies per call: >> >>>first pulse detected, >>>repetition interval calculated (e.g. second pulse >> >>detected) >> >>>"Generating" MGC will need to send tree modifies: >>>pulse once (when first pulse detected event is >> >>relayed) >> >>>pulse forever (when repetition interval received) >>>stop pulse generation (when call terminates) >>> >>>Regards, >>> Aleks >>> >>>At 01:12 PM 10/3/2003, Soncodi, Adrian wrote: >>> >>>>In some countries a tandem switch is required to >> >>propagate meter pulses >> >>>>(backwards) from the outgoing R2 trunk to the >> >>incoming R2 trunk. These >> >>>>pulses are used for billing. A potential problem >> >>is that the pulse rate >> >>>>may be very high, sometimes it can be a >> >>sub-second interval. Therefore, a >> >>>>tandem MGC which has a considerable number of R2 >> >>trunks will have a big >> >>>>overhead for propagating meter pulses, which will >> >>affect its call >> >>>>processing rate. >>>> >>>>So I'm wondering if anything can be done about >> >>this. Here are two >> >>>>possibilities: >>>> >>>>1) Allow the MG to detect meter pulses but report >> >>them in chunks of N. By >> >>>>default, N=1 (report every pulse), but the MGC >> >>could also select, say, >> >>>>N=10, in which case the MG reports once every 10 >> >>pulses. (A residual pulse >> >>>>count could be reported on Subtract). This method >> >>saves a lot of NTFY >> >>>>messages. However, on the other side, the MGC >> >>would be forced to propagate >> >>>>the pulses as bursts-of-N, and I am not sure a >> >>switch is allowed to >> >>>>transform constant-rate pulsing into bursts. (On >> >>the other hand why not? >> >>>>because it's only the total pulse count that is >> >>relevant for charging. >> >>>>Time-of-day periods with higher charging rates >> >>actually result in more >> >>>>meter pulses.) >>>> >>>>2) Define a mode which allows the meter pulses to >> >>be propagated directly >> >>>>between MGs, without MGC involvement, i.e. by a >> >>method similar to RFC2833. >> >>>>RFC2833 does not currently have an event defined >> >>for meter pulses, but it >> >>>>could be extended, since it defines a lot of >> >>signaling-related tones >> >>>>anyway. In addition to solving the NTFY messaging >> >>overhead, this method >> >>>>would have the side benefit that it would also >> >>work between two MGCs that >> >>>>use SIP or BICC between them. Currently, there is >> >>no way to transport >> >>>>meter pulse information in SIP or BICC, and this >> >>would have a terrible >> >>>>overhead anyway. >>>>Of course, the ability to detect meter pulses is >> >>still required, because >> >>>>there is always the possibility that the MGC must >> >>perform the >> >>>>meter-pulse-based charging itself (rather than >> >>propagate). >> >>>>Any other ideas or comments? >>>> >>>>Adrian Soncodi >>>> >>>> >>>> >>>>-----Original Message----- >>>>From: Christian Groves >> >>[mailto:Christian.Groves@ericsson.com.au] >> >>>>Sent: Thursday, October 02, 2003 10:38 PM >>>>To: Aleksandr Ryabin >>>>Cc: megaco@ietf.org; Kevin Boyle >>>>Subject: Re: [Megaco] CAS Metering Pulse support >>>> >>>> >>>>Hello Aleksandr, >>>> >>>>I'm happy enough to have the your proposed >> >>amendment if the editor agrees. >> >>>>Regards, Christian >>>> >>>>Aleksandr Ryabin wrote: >>>> >>>>>Hi Christian, >>>>> >>>>>No description of the event does say how to >> >>use it for detection >> >>>>>incoming metering pulse. More over it >> >>explicitly limits to generation: >> >>>>>"This event is used in conjunction with the >> >>"enable metering" and >> >>>>>"metering pulse burst" signals defined in this >> >>package..." >> >>>>>My point being that descriptions of amet >> >>events and statistics >> >>>>>are siting that event pr is generated and >> >>statistics are changed >> >>>>>only based on previously applied em, or mbp >> >>signal. >> >>>>>The wording needs to be amended to cover the >> >>cases > > === message truncated === > > > ===== > Kushanava Laha > Hughes Software Systems > > __________________________________ > Do you Yahoo!? > The New Yahoo! Shopping - with improved product search > http://shopping.yahoo.com > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Oct 9 04:12:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11071 for ; Thu, 9 Oct 2003 04:12:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Vtx-0003Ar-M0; Thu, 09 Oct 2003 04:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Vto-0003AG-4w for megaco@optimus.ietf.org; Thu, 09 Oct 2003 04:11:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11060 for ; Thu, 9 Oct 2003 04:11:43 -0400 (EDT) From: rui.suying@zte.com.cn Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Vtl-0003H3-00 for megaco@ietf.org; Thu, 09 Oct 2003 04:11:49 -0400 Received: from [210.21.227.66] (helo=zte.com.cn) by ietf-mx with esmtp (Exim 4.12) id 1A7Vtk-0003GD-00 for megaco@ietf.org; Thu, 09 Oct 2003 04:11:48 -0400 To: megaco@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 Message-ID: Date: Thu, 9 Oct 2003 16:10:05 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 5.0.8 |June 18, 2001) at 2003-10-09 16:13:15, Serialize complete at 2003-10-09 16:13:15 Content-Type: multipart/alternative; boundary="=_alternative 002CFB3548256DBA_=" Subject: [Megaco] about signallist Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 002CFB3548256DBA_= Content-Type: text/plain; charset="US-ASCII" Hi all, signal descriptor is defined to support parameter "signallist". i think that SIGNALLIST is different from other parameters such as signalrequest. the process of signallist may last for a long period. My question is when to reply MGC? reply immediately or after all sigals in signallist are played? if reply immediately, while failure occurs in process, how can MG report the failure to MGC? use servicechange? use notify? or any other good method? thanks! ********************************************** Rui Suying SoftSwitch Software Design Department Nanjing R&D Center ZTE Co. China Mobile: 13851939625 (China only) ********************************************** --=_alternative 002CFB3548256DBA_= Content-Type: text/html; charset="US-ASCII"
Hi all,
        signal descriptor is defined to support parameter "signallist". i think that SIGNALLIST is different from other parameters such as signalrequest. the process of signallist may last for a long period. My question is when to reply MGC? reply immediately or after all sigals in signallist are played? if reply immediately, while failure occurs in process, how can MG report the failure to MGC? use servicechange? use notify? or any other good method?

        thanks!
       
       

**********************************************
                Rui Suying
   SoftSwitch Software Design Department
            Nanjing R&D Center
                ZTE Co. China
   Mobile: 13851939625 (China only)    
**********************************************
 --=_alternative 002CFB3548256DBA_=-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Oct 9 04:12:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11086 for ; Thu, 9 Oct 2003 04:12:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Vu5-0003Cp-DC for megaco-archive@odin.ietf.org; Thu, 09 Oct 2003 04:12:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h998C9GC012263 for megaco-archive@odin.ietf.org; Thu, 9 Oct 2003 04:12:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Vu4-0003Ba-7M for megaco-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 04:12:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11066 for ; Thu, 9 Oct 2003 04:11:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Vu1-0003HE-00 for megaco-web-archive@ietf.org; Thu, 09 Oct 2003 04:12:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7Vu0-0003HA-00 for megaco-web-archive@ietf.org; Thu, 09 Oct 2003 04:12:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Vtx-0003Ar-M0; Thu, 09 Oct 2003 04:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Vto-0003AG-4w for megaco@optimus.ietf.org; Thu, 09 Oct 2003 04:11:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11060 for ; Thu, 9 Oct 2003 04:11:43 -0400 (EDT) From: rui.suying@zte.com.cn Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Vtl-0003H3-00 for megaco@ietf.org; Thu, 09 Oct 2003 04:11:49 -0400 Received: from [210.21.227.66] (helo=zte.com.cn) by ietf-mx with esmtp (Exim 4.12) id 1A7Vtk-0003GD-00 for megaco@ietf.org; Thu, 09 Oct 2003 04:11:48 -0400 To: megaco@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 Message-ID: Date: Thu, 9 Oct 2003 16:10:05 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 5.0.8 |June 18, 2001) at 2003-10-09 16:13:15, Serialize complete at 2003-10-09 16:13:15 Content-Type: multipart/alternative; boundary="=_alternative 002CFB3548256DBA_=" Subject: [Megaco] about signallist Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 002CFB3548256DBA_= Content-Type: text/plain; charset="US-ASCII" Hi all, signal descriptor is defined to support parameter "signallist". i think that SIGNALLIST is different from other parameters such as signalrequest. the process of signallist may last for a long period. My question is when to reply MGC? reply immediately or after all sigals in signallist are played? if reply immediately, while failure occurs in process, how can MG report the failure to MGC? use servicechange? use notify? or any other good method? thanks! ********************************************** Rui Suying SoftSwitch Software Design Department Nanjing R&D Center ZTE Co. China Mobile: 13851939625 (China only) ********************************************** --=_alternative 002CFB3548256DBA_= Content-Type: text/html; charset="US-ASCII"
Hi all,
        signal descriptor is defined to support parameter "signallist". i think that SIGNALLIST is different from other parameters such as signalrequest. the process of signallist may last for a long period. My question is when to reply MGC? reply immediately or after all sigals in signallist are played? if reply immediately, while failure occurs in process, how can MG report the failure to MGC? use servicechange? use notify? or any other good method?

        thanks!
       
       

**********************************************
                Rui Suying
   SoftSwitch Software Design Department
            Nanjing R&D Center
                ZTE Co. China
   Mobile: 13851939625 (China only)    
**********************************************
 --=_alternative 002CFB3548256DBA_=-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Oct 9 04:39:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11871 for ; Thu, 9 Oct 2003 04:39:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7WK7-0004ci-8X; Thu, 09 Oct 2003 04:39:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7WJL-0004Xq-Ng for megaco@optimus.ietf.org; Thu, 09 Oct 2003 04:38:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11840 for ; Thu, 9 Oct 2003 04:38:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7WJI-0003Zp-00 for megaco@ietf.org; Thu, 09 Oct 2003 04:38:12 -0400 Received: from mail.tdsoft.com ([212.143.64.34] helo=tdsoft.com) by ietf-mx with smtp (Exim 4.12) id 1A7WJH-0003Zm-00 for megaco@ietf.org; Thu, 09 Oct 2003 04:38:11 -0400 Received: from exchange.td-soft.co.il ([IP=172.16.0.250]) by eSafe SMTP Relay 1065625822; Thu Oct 09 10:36:16 2003 Received: by exchange.td-soft.co.il with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Oct 2003 10:35:35 +0200 Message-ID: From: Raphael Tryster To: "'rui.suying@zte.com.cn'" , megaco@ietf.org Subject: RE: [Megaco] about signallist Date: Thu, 9 Oct 2003 10:35:32 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38E40.4D870010" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C38E40.4D870010 Content-Type: text/plain; charset="iso-8859-1" You may find a discussion in this list from a year ago to be helpful. I am copying my question and two of the replies here. If you like, look in the archive to find the rest of the thread. Raphael Tryster From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Monday, October 21, 2002 7:47 AM To: Taylor, Tom-PT [CAR:B602:EXCH]; 'Anil Jangam'; megaco@ietf.org Cc: SHRI KUMAR; Boyle, Kevin [NCRTP:3R90:EXCH] Subject: RE: [Megaco] State of the termination after failure of a command. The recent part of this thread refers to a signal being stopped because some other descriptor in the command failed. I would like to turn the question around, and ask, what happens to the rest of the command if the signal descriptor fails? Let me ask this in a general and a specific way: General: Are there some descriptors whose failure has no impact on the success or failure of the command in which they appear? Specific: Does failure to play a signal cause the command in which the signal descriptor appears to fail? I would like to argue that the answers are, respectively, yes and no, and that failure to play a signal should not fail the containing command. I am talking about a hardware or resource failure, not a parsing or logical error in specifying the signals descriptor. Consider the following command: MEGACO/1 [172.16.1.70]:2944 Transaction = 30645 { Context = - { Modify = Yafit0@TdSoft.com { Events = 2223 { al/on, dd/ce {DigitMap=Dialplan0} }, Signals {SL = 1 { cg/dt, cg/bt } }, DigitMap= Dialplan0{ (0| 00|[1-7]xxx|8xxxxxxx|Fxxxxxxx|Exx|91xxxxxxxxxx|9011x.)} } } } cg/dt is a timeout signal, following which cg/bt shall be played. I am sure nobody suggests that the reply to transaction 30645 should be withheld until the MG verifies that it is able to start playing cg/bt. Thus, the success of the command is independent of the success of the second signal. Now, logically, why should the first signal be treated any differently from the others? Therefore, I would expect the success of the command to be independent of the success of all signals. Perhaps for this reason, Megaco allows the MGC to request NotifyCompletion if it wants to be certain that the signal succeeded. Otherwise, a signal descriptor is by definition successful. Comments please? Raphael Tryster From: Terry L Anderson [SMTP:tlatla@verizon.net] Sent: Monday, 21 October 2002 14:08 To: Raphael Tryster Cc: Tom-PT Taylor; 'Anil Jangam'; megaco@ietf.org; SHRI KUMAR; Kevin Boyle Subject: Re: [Megaco] State of the termination after failure of a command. I am not sure that we would want to make a narrow exception to the general principle just for signals. I think if any descriptor "fails" then the command fails. But that being said we DO have to be careful of what is considered a failure. There are certainly things that can fail about a signal well after the signal has begun playing that I would not consider a error of the descriptor, just as failure of the network is not an error in the Local/Remote descriptors. In the specific case you raise, I would expect that the MG should "reserve resources" for all signals when it accepts the descriptor. If it has no ability to play cg/bt because it is not implemented or some other resource limit as known at the time the descriptor is received, then I would expect it to return an error failing the entire command. On the other hand, if (as far as it knows when the descriptor is received) it can play them, it should return success immediately and notify in any other appropriate way (if events are set) about any sort of later failure. From: Tom-PT Taylor [SMTP:taylor@nortelnetworks.com] Sent: Monday, 21 October 2002 15:03 To: Raphael Tryster; 'Anil Jangam'; megaco@ietf.org Cc: SHRI KUMAR; Kevin Boyle Subject: RE: [Megaco] State of the termination after failure of a command. It's really a matter of timing: if the attempt to dispatch the signal fails immediately, then the command has failed. This leaves a certain amount of discretion to the implementor. I address this issue a bit in distinguishing failures from error events in the Advanced Media Server packages. There is some relevant text in section 8.2.2 that leans toward your view: "A SignalsDescriptor is considered to have been processed when it has been established that the descriptor is syntactically valid, the requested signals are supported and they have been queued to be applied." -----Original Message----- From: rui.suying@zte.com.cn [SMTP:rui.suying@zte.com.cn] Sent: Thursday, 9 October 2003 10:10 To: megaco@ietf.org Subject: [Megaco] about signallist Hi all, signal descriptor is defined to support parameter "signallist". i think that SIGNALLIST is different from other parameters such as signalrequest. the process of signallist may last for a long period. My question is when to reply MGC? reply immediately or after all sigals in signallist are played? if reply immediately, while failure occurs in process, how can MG report the failure to MGC? use servicechange? use notify? or any other good method? thanks! ********************************************** Rui Suying SoftSwitch Software Design Department Nanjing R&D Center ZTE Co. China Mobile: 13851939625 (China only) ********************************************** ------_=_NextPart_001_01C38E40.4D870010 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Megaco] about signallist

You may find a discussion in this list f= rom a year ago to be helpful.  I am copying my question and two of t= he replies here.  If you like, look in the archive to find the rest = of the thread.

Raphael Tryster

From:   Raphael Tryster [mailto:raphael@tdsoft.com]<= /B>
Sent:   Monday, October 21, 2= 002 7:47 AM
To:     Taylor, Tom= -PT [CAR:B602:EXCH]; 'Anil Jangam'; megaco@ietf.org
Cc:     SHRI KUMAR;= Boyle, Kevin [NCRTP:3R90:EXCH]
Subject:     &= nbsp;  RE: [Megaco] State of the termination after failure of a comm= and.


The recent part of this thread refers to= a signal being stopped because some other descriptor in the command fail= ed.  I would like to turn the question around, and ask, what happens= to the rest of the command if the signal descriptor fails?  Let me = ask this in a general and a specific way:

General:  Are there some descriptor= s whose failure has no impact on the success or failure of the command in= which they appear?  Specific:  Does failure to play a signal c= ause the command in which the signal descriptor appears to fail? <= /P>

I would like to argue that the answers a= re, respectively, yes and no, and that failure to play a signal should no= t fail the containing command.  I am talking about a hardware or res= ource failure, not a parsing or logical error in specifying the signals d= escriptor.  Consider the following command:

MEGACO/1 [172.16.1.70]:2944
Transaction =3D 30645 {

      Context =3D - {

Modify =3D Yafit0@= TdSoft.com {
Events =3D 2223 {
al/on, dd/ce {DigitMap=3DDialplan0}&nbs= p;          
     &nb= sp;          },

      Signals {SL =3D 1 { cg/dt, cg/bt } },
      DigitMap=3D Dialplan0{

(0| 00|[1-7]xxx|8xxxxxxx|Fxxxxxxx|Exx|91= xxxxxxxxxx|9011x.)}   
     &nb= sp;          }
     &nb= sp;  }
}
cg/dt is a timeout signal, following wh= ich cg/bt shall be played.  I am sure nobody suggests that the reply= to transaction 30645 should be withheld until the MG verifies that it is= able to start playing cg/bt.  Thus, the success of the command is i= ndependent of the success of the second signal.  Now, logically, why= should the first signal be treated any differently from the others? = ; Therefore, I would expect the success of the command to be independent = of the success of all signals.

Perhaps for this reason, Megaco allows t= he MGC to request NotifyCompletion if it wants to be certain that the sig= nal succeeded.  Otherwise, a signal descriptor is by definition succ= essful.

Comments please?
Raphael Tryster

From:   Terry L Anderson [S= MTP:tlatla@verizon.net]
Sent:   Monday, 21 October 2002 14:08
To:     Raphael Tryster
Cc:     Tom-PT Taylor; 'Anil Jangam'; megaco@iet= f.org; SHRI KUMAR; Kevin Boyle
Subject:    &nbs= p;   Re: [Megaco] Stat= e of the termination after failure of a command.

I am not sure that we would want t= o make a narrow exception to the
general principle just for signal= s.  I think if any descriptor "fails"
then the command fails.  But= that being said we DO have to be careful of
what is considered a failure.&nbs= p; There are certainly things that can fail
about a signal well after the sig= nal has begun playing that I would not
consider a error of the descripto= r, just as failure of the network is
not an error in the Local/Remote = descriptors. 

In the specific case you raise, I = would expect that the MG should
"reserve resources" for= all signals when it accepts the descriptor.  If
it has no ability to play cg/bt b= ecause it is not implemented or some
other resource limit as known at = the time the descriptor is received,
then I would expect it to return = an error failing the entire command.
 On the other hand, if (as f= ar as it knows when the descriptor is
received) it can play them, it sh= ould return success immediately and
notify in any other appropriate w= ay (if events are set) about any sort
of later failure.

From:   Tom-PT Taylor [SMTP= :taylor@nortelnetworks.com]
Sent:   Monday, 21 October 2002 15:03
To:     Raphael Tryster; 'Anil Jangam'; megaco@i= etf.org
Cc:     SHRI KUMAR; Kevin Boyle
Subject:    &nbs= p;   RE: [Megaco] Stat= e of the termination after failure of a command.

It's really a matter of timing: if= the attempt to dispatch the signal fails
immediately, then the command has= failed.  This leaves a certain amount of
discretion to the implementor.&nb= sp; I address this issue a bit in distinguishing
failures from error events in the= Advanced Media Server packages.

There is some relevant text in sec= tion 8.2.2 that leans toward your view:
  "A SignalsDescriptor = is considered to have been processed when it has
   been established tha= t the descriptor is syntactically valid, the
   requested signals ar= e supported and they have been queued to be
   applied."

    -----Original Mess= age-----
    From:   rui.suying@zte.com= =2Ecn [SMTP:rui.suying@zte.com.cn]
    Sent:   Thursday, 9 October 2003 10:10
    To:     megaco@ietf.org
    Subject:    &nbs= p;   [Megaco] about si= gnallist


    Hi all,=
    =A0 =A0 =A0 =A0 signal descript= or is defined to support parameter "signallist". i think that S= IGNALLIST is different from other parameters such as signalrequest. the p= rocess of signallist may last for a long period. My question is when to r= eply MGC? reply immediately or after all sigals in signallist are played?= if reply immediately, while failure occurs in process, how can MG report= the failure to MGC? use servicechange? use notify? or any other good met= hod?

    =A0 =A0 =A0 =A0 thanks!<= FONT FACE=3D"Arial">
    =A0 =A0 =A0 =A0
    =A0 =A0 =A0 =A0

    **************************************= ********
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Rui Suying
    =A0 =A0SoftSwitch Software Design Department
    =A0 =A0 =A0 =A0 =A0 =A0 Nanjing R&D Center
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ZTE Co. China
    =A0 =A0Mobile: 13851939625 (China only) =A0 =A0
    **********************************************

------_=_NextPart_001_01C38E40.4D870010-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Oct 9 04:39:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11886 for ; Thu, 9 Oct 2003 04:39:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7WKG-0004eD-2K for megaco-archive@odin.ietf.org; Thu, 09 Oct 2003 04:39:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h998dAta017858 for megaco-archive@odin.ietf.org; Thu, 9 Oct 2003 04:39:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7WKB-0004dx-MH for megaco-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 04:39:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11862 for ; Thu, 9 Oct 2003 04:38:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7WK8-0003a6-00 for megaco-web-archive@ietf.org; Thu, 09 Oct 2003 04:39:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7WK8-0003a3-00 for megaco-web-archive@ietf.org; Thu, 09 Oct 2003 04:39:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7WK7-0004ci-8X; Thu, 09 Oct 2003 04:39:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7WJL-0004Xq-Ng for megaco@optimus.ietf.org; Thu, 09 Oct 2003 04:38:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11840 for ; Thu, 9 Oct 2003 04:38:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7WJI-0003Zp-00 for megaco@ietf.org; Thu, 09 Oct 2003 04:38:12 -0400 Received: from mail.tdsoft.com ([212.143.64.34] helo=tdsoft.com) by ietf-mx with smtp (Exim 4.12) id 1A7WJH-0003Zm-00 for megaco@ietf.org; Thu, 09 Oct 2003 04:38:11 -0400 Received: from exchange.td-soft.co.il ([IP=172.16.0.250]) by eSafe SMTP Relay 1065625822; Thu Oct 09 10:36:16 2003 Received: by exchange.td-soft.co.il with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Oct 2003 10:35:35 +0200 Message-ID: From: Raphael Tryster To: "'rui.suying@zte.com.cn'" , megaco@ietf.org Subject: RE: [Megaco] about signallist Date: Thu, 9 Oct 2003 10:35:32 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38E40.4D870010" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C38E40.4D870010 Content-Type: text/plain; charset="iso-8859-1" You may find a discussion in this list from a year ago to be helpful. I am copying my question and two of the replies here. If you like, look in the archive to find the rest of the thread. Raphael Tryster From: Raphael Tryster [mailto:raphael@tdsoft.com] Sent: Monday, October 21, 2002 7:47 AM To: Taylor, Tom-PT [CAR:B602:EXCH]; 'Anil Jangam'; megaco@ietf.org Cc: SHRI KUMAR; Boyle, Kevin [NCRTP:3R90:EXCH] Subject: RE: [Megaco] State of the termination after failure of a command. The recent part of this thread refers to a signal being stopped because some other descriptor in the command failed. I would like to turn the question around, and ask, what happens to the rest of the command if the signal descriptor fails? Let me ask this in a general and a specific way: General: Are there some descriptors whose failure has no impact on the success or failure of the command in which they appear? Specific: Does failure to play a signal cause the command in which the signal descriptor appears to fail? I would like to argue that the answers are, respectively, yes and no, and that failure to play a signal should not fail the containing command. I am talking about a hardware or resource failure, not a parsing or logical error in specifying the signals descriptor. Consider the following command: MEGACO/1 [172.16.1.70]:2944 Transaction = 30645 { Context = - { Modify = Yafit0@TdSoft.com { Events = 2223 { al/on, dd/ce {DigitMap=Dialplan0} }, Signals {SL = 1 { cg/dt, cg/bt } }, DigitMap= Dialplan0{ (0| 00|[1-7]xxx|8xxxxxxx|Fxxxxxxx|Exx|91xxxxxxxxxx|9011x.)} } } } cg/dt is a timeout signal, following which cg/bt shall be played. I am sure nobody suggests that the reply to transaction 30645 should be withheld until the MG verifies that it is able to start playing cg/bt. Thus, the success of the command is independent of the success of the second signal. Now, logically, why should the first signal be treated any differently from the others? Therefore, I would expect the success of the command to be independent of the success of all signals. Perhaps for this reason, Megaco allows the MGC to request NotifyCompletion if it wants to be certain that the signal succeeded. Otherwise, a signal descriptor is by definition successful. Comments please? Raphael Tryster From: Terry L Anderson [SMTP:tlatla@verizon.net] Sent: Monday, 21 October 2002 14:08 To: Raphael Tryster Cc: Tom-PT Taylor; 'Anil Jangam'; megaco@ietf.org; SHRI KUMAR; Kevin Boyle Subject: Re: [Megaco] State of the termination after failure of a command. I am not sure that we would want to make a narrow exception to the general principle just for signals. I think if any descriptor "fails" then the command fails. But that being said we DO have to be careful of what is considered a failure. There are certainly things that can fail about a signal well after the signal has begun playing that I would not consider a error of the descriptor, just as failure of the network is not an error in the Local/Remote descriptors. In the specific case you raise, I would expect that the MG should "reserve resources" for all signals when it accepts the descriptor. If it has no ability to play cg/bt because it is not implemented or some other resource limit as known at the time the descriptor is received, then I would expect it to return an error failing the entire command. On the other hand, if (as far as it knows when the descriptor is received) it can play them, it should return success immediately and notify in any other appropriate way (if events are set) about any sort of later failure. From: Tom-PT Taylor [SMTP:taylor@nortelnetworks.com] Sent: Monday, 21 October 2002 15:03 To: Raphael Tryster; 'Anil Jangam'; megaco@ietf.org Cc: SHRI KUMAR; Kevin Boyle Subject: RE: [Megaco] State of the termination after failure of a command. It's really a matter of timing: if the attempt to dispatch the signal fails immediately, then the command has failed. This leaves a certain amount of discretion to the implementor. I address this issue a bit in distinguishing failures from error events in the Advanced Media Server packages. There is some relevant text in section 8.2.2 that leans toward your view: "A SignalsDescriptor is considered to have been processed when it has been established that the descriptor is syntactically valid, the requested signals are supported and they have been queued to be applied." -----Original Message----- From: rui.suying@zte.com.cn [SMTP:rui.suying@zte.com.cn] Sent: Thursday, 9 October 2003 10:10 To: megaco@ietf.org Subject: [Megaco] about signallist Hi all, signal descriptor is defined to support parameter "signallist". i think that SIGNALLIST is different from other parameters such as signalrequest. the process of signallist may last for a long period. My question is when to reply MGC? reply immediately or after all sigals in signallist are played? if reply immediately, while failure occurs in process, how can MG report the failure to MGC? use servicechange? use notify? or any other good method? thanks! ********************************************** Rui Suying SoftSwitch Software Design Department Nanjing R&D Center ZTE Co. China Mobile: 13851939625 (China only) ********************************************** ------_=_NextPart_001_01C38E40.4D870010 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Megaco] about signallist

You may find a discussion in this list f= rom a year ago to be helpful.  I am copying my question and two of t= he replies here.  If you like, look in the archive to find the rest = of the thread.

Raphael Tryster

From:   Raphael Tryster [mailto:raphael@tdsoft.com]<= /B>
Sent:   Monday, October 21, 2= 002 7:47 AM
To:     Taylor, Tom= -PT [CAR:B602:EXCH]; 'Anil Jangam'; megaco@ietf.org
Cc:     SHRI KUMAR;= Boyle, Kevin [NCRTP:3R90:EXCH]
Subject:     &= nbsp;  RE: [Megaco] State of the termination after failure of a comm= and.


The recent part of this thread refers to= a signal being stopped because some other descriptor in the command fail= ed.  I would like to turn the question around, and ask, what happens= to the rest of the command if the signal descriptor fails?  Let me = ask this in a general and a specific way:

General:  Are there some descriptor= s whose failure has no impact on the success or failure of the command in= which they appear?  Specific:  Does failure to play a signal c= ause the command in which the signal descriptor appears to fail? <= /P>

I would like to argue that the answers a= re, respectively, yes and no, and that failure to play a signal should no= t fail the containing command.  I am talking about a hardware or res= ource failure, not a parsing or logical error in specifying the signals d= escriptor.  Consider the following command:

MEGACO/1 [172.16.1.70]:2944
Transaction =3D 30645 {

      Context =3D - {

Modify =3D Yafit0@= TdSoft.com {
Events =3D 2223 {
al/on, dd/ce {DigitMap=3DDialplan0}&nbs= p;          
     &nb= sp;          },

      Signals {SL =3D 1 { cg/dt, cg/bt } },
      DigitMap=3D Dialplan0{

(0| 00|[1-7]xxx|8xxxxxxx|Fxxxxxxx|Exx|91= xxxxxxxxxx|9011x.)}   
     &nb= sp;          }
     &nb= sp;  }
}
cg/dt is a timeout signal, following wh= ich cg/bt shall be played.  I am sure nobody suggests that the reply= to transaction 30645 should be withheld until the MG verifies that it is= able to start playing cg/bt.  Thus, the success of the command is i= ndependent of the success of the second signal.  Now, logically, why= should the first signal be treated any differently from the others? = ; Therefore, I would expect the success of the command to be independent = of the success of all signals.

Perhaps for this reason, Megaco allows t= he MGC to request NotifyCompletion if it wants to be certain that the sig= nal succeeded.  Otherwise, a signal descriptor is by definition succ= essful.

Comments please?
Raphael Tryster

From:   Terry L Anderson [S= MTP:tlatla@verizon.net]
Sent:   Monday, 21 October 2002 14:08
To:     Raphael Tryster
Cc:     Tom-PT Taylor; 'Anil Jangam'; megaco@iet= f.org; SHRI KUMAR; Kevin Boyle
Subject:    &nbs= p;   Re: [Megaco] Stat= e of the termination after failure of a command.

I am not sure that we would want t= o make a narrow exception to the
general principle just for signal= s.  I think if any descriptor "fails"
then the command fails.  But= that being said we DO have to be careful of
what is considered a failure.&nbs= p; There are certainly things that can fail
about a signal well after the sig= nal has begun playing that I would not
consider a error of the descripto= r, just as failure of the network is
not an error in the Local/Remote = descriptors. 

In the specific case you raise, I = would expect that the MG should
"reserve resources" for= all signals when it accepts the descriptor.  If
it has no ability to play cg/bt b= ecause it is not implemented or some
other resource limit as known at = the time the descriptor is received,
then I would expect it to return = an error failing the entire command.
 On the other hand, if (as f= ar as it knows when the descriptor is
received) it can play them, it sh= ould return success immediately and
notify in any other appropriate w= ay (if events are set) about any sort
of later failure.

From:   Tom-PT Taylor [SMTP= :taylor@nortelnetworks.com]
Sent:   Monday, 21 October 2002 15:03
To:     Raphael Tryster; 'Anil Jangam'; megaco@i= etf.org
Cc:     SHRI KUMAR; Kevin Boyle
Subject:    &nbs= p;   RE: [Megaco] Stat= e of the termination after failure of a command.

It's really a matter of timing: if= the attempt to dispatch the signal fails
immediately, then the command has= failed.  This leaves a certain amount of
discretion to the implementor.&nb= sp; I address this issue a bit in distinguishing
failures from error events in the= Advanced Media Server packages.

There is some relevant text in sec= tion 8.2.2 that leans toward your view:
  "A SignalsDescriptor = is considered to have been processed when it has
   been established tha= t the descriptor is syntactically valid, the
   requested signals ar= e supported and they have been queued to be
   applied."

    -----Original Mess= age-----
    From:   rui.suying@zte.com= =2Ecn [SMTP:rui.suying@zte.com.cn]
    Sent:   Thursday, 9 October 2003 10:10
    To:     megaco@ietf.org
    Subject:    &nbs= p;   [Megaco] about si= gnallist


    Hi all,=
    =A0 =A0 =A0 =A0 signal descript= or is defined to support parameter "signallist". i think that S= IGNALLIST is different from other parameters such as signalrequest. the p= rocess of signallist may last for a long period. My question is when to r= eply MGC? reply immediately or after all sigals in signallist are played?= if reply immediately, while failure occurs in process, how can MG report= the failure to MGC? use servicechange? use notify? or any other good met= hod?

    =A0 =A0 =A0 =A0 thanks!<= FONT FACE=3D"Arial">
    =A0 =A0 =A0 =A0
    =A0 =A0 =A0 =A0

    **************************************= ********
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Rui Suying
    =A0 =A0SoftSwitch Software Design Department
    =A0 =A0 =A0 =A0 =A0 =A0 Nanjing R&D Center
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ZTE Co. China
    =A0 =A0Mobile: 13851939625 (China only) =A0 =A0
    **********************************************

------_=_NextPart_001_01C38E40.4D870010-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Oct 9 05:09:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12735 for ; Thu, 9 Oct 2003 05:09:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Wn8-0007OE-5S; Thu, 09 Oct 2003 05:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7WmN-0007Im-6y for megaco@optimus.ietf.org; Thu, 09 Oct 2003 05:08:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12705 for ; Thu, 9 Oct 2003 05:08:06 -0400 (EDT) From: assingh@hss.hns.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7WmJ-0003tr-00 for megaco@ietf.org; Thu, 09 Oct 2003 05:08:11 -0400 Received: from [202.54.26.202] (helo=hindon.hss.co.in) by ietf-mx with esmtp (Exim 4.12) id 1A7WmH-0003tQ-00 for megaco@ietf.org; Thu, 09 Oct 2003 05:08:10 -0400 Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h9993hv16970; Thu, 9 Oct 2003 14:33:43 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id h9998TP00144; Thu, 9 Oct 2003 14:38:30 +0530 (IST) Subject: Re: [Megaco] about signallist To: rui.suying@zte.com.cn Cc: megaco@ietf.org Date: Thu, 9 Oct 2003 14:33:16 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 09/10/2003 02:30:28 PM MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Rui, Signal List may play for a long time, so MG should not wait for complet= ion of all signals in the Signal List before replying to the MGC. Mg should= send reply immediately. If some intermediate signal in the list fails t= o play, then MG can inform MGC about this by sending Notify command for Signal Completion g/sc event with Signal List id, Signal id of the sign= al which has terminated and Termination Method as "NC". Thanks Ashish. rui.suying@zte.com.cn@ietf.org on 10/09/2003 01:40:05 PM Sent by: megaco-admin@ietf.org To: megaco@ietf.org cc: Subject: [Megaco] about signallist Hi all, =A0 =A0 =A0 =A0 signal descriptor is defined to support parameter "sign= allist". i think that SIGNALLIST is different from other parameters such as signalrequest. the process of signallist may last for a long period. My= question is when to reply MGC? reply immediately or after all sigals in= signallist are played? if reply immediately, while failure occurs in process, how can MG report the failure to MGC? use servicechange? use notify? or any other good method? =A0 =A0 =A0 =A0 thanks! ********************************************** =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Rui Suying =A0 =A0SoftSwitch Software Design Department =A0 =A0 =A0 =A0 =A0 =A0 Nanjing R&D Center =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ZTE Co. China =A0 =A0Mobile: 13851939625 (China only) ********************************************** = _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Oct 9 05:09:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12750 for ; Thu, 9 Oct 2003 05:09:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7WnC-0007Pa-OT for megaco-archive@odin.ietf.org; Thu, 09 Oct 2003 05:09:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99996EP028489 for megaco-archive@odin.ietf.org; Thu, 9 Oct 2003 05:09:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7WnC-0007PQ-Gj for megaco-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 05:09:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12717 for ; Thu, 9 Oct 2003 05:08:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Wn9-0003uT-00 for megaco-web-archive@ietf.org; Thu, 09 Oct 2003 05:09:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7Wn8-0003uQ-00 for megaco-web-archive@ietf.org; Thu, 09 Oct 2003 05:09:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Wn8-0007OE-5S; Thu, 09 Oct 2003 05:09:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7WmN-0007Im-6y for megaco@optimus.ietf.org; Thu, 09 Oct 2003 05:08:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12705 for ; Thu, 9 Oct 2003 05:08:06 -0400 (EDT) From: assingh@hss.hns.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7WmJ-0003tr-00 for megaco@ietf.org; Thu, 09 Oct 2003 05:08:11 -0400 Received: from [202.54.26.202] (helo=hindon.hss.co.in) by ietf-mx with esmtp (Exim 4.12) id 1A7WmH-0003tQ-00 for megaco@ietf.org; Thu, 09 Oct 2003 05:08:10 -0400 Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h9993hv16970; Thu, 9 Oct 2003 14:33:43 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id h9998TP00144; Thu, 9 Oct 2003 14:38:30 +0530 (IST) Subject: Re: [Megaco] about signallist To: rui.suying@zte.com.cn Cc: megaco@ietf.org Date: Thu, 9 Oct 2003 14:33:16 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 09/10/2003 02:30:28 PM MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Rui, Signal List may play for a long time, so MG should not wait for complet= ion of all signals in the Signal List before replying to the MGC. Mg should= send reply immediately. If some intermediate signal in the list fails t= o play, then MG can inform MGC about this by sending Notify command for Signal Completion g/sc event with Signal List id, Signal id of the sign= al which has terminated and Termination Method as "NC". Thanks Ashish. rui.suying@zte.com.cn@ietf.org on 10/09/2003 01:40:05 PM Sent by: megaco-admin@ietf.org To: megaco@ietf.org cc: Subject: [Megaco] about signallist Hi all, =A0 =A0 =A0 =A0 signal descriptor is defined to support parameter "sign= allist". i think that SIGNALLIST is different from other parameters such as signalrequest. the process of signallist may last for a long period. My= question is when to reply MGC? reply immediately or after all sigals in= signallist are played? if reply immediately, while failure occurs in process, how can MG report the failure to MGC? use servicechange? use notify? or any other good method? =A0 =A0 =A0 =A0 thanks! ********************************************** =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Rui Suying =A0 =A0SoftSwitch Software Design Department =A0 =A0 =A0 =A0 =A0 =A0 Nanjing R&D Center =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ZTE Co. China =A0 =A0Mobile: 13851939625 (China only) ********************************************** = _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Oct 10 14:22:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10694 for ; Fri, 10 Oct 2003 14:22:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A81tp-0007ft-I2; Fri, 10 Oct 2003 14:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A81kL-0007EQ-2B for megaco@optimus.ietf.org; Fri, 10 Oct 2003 14:12:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10384 for ; Fri, 10 Oct 2003 14:12:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A81kI-000794-00 for megaco@ietf.org; Fri, 10 Oct 2003 14:12:10 -0400 Received: from web8101.mail.in.yahoo.com ([203.199.70.28] helo=web8101.in.yahoo.com) by ietf-mx with smtp (Exim 4.12) id 1A81kG-00078Q-00 for megaco@ietf.org; Fri, 10 Oct 2003 14:12:08 -0400 Message-ID: <20031010181124.86600.qmail@web8101.in.yahoo.com> Received: from [128.107.253.41] by web8101.mail.in.yahoo.com via HTTP; Fri, 10 Oct 2003 19:11:24 BST Date: Fri, 10 Oct 2003 19:11:24 +0100 (BST) From: =?iso-8859-1?q?Shobhit=20Bansal?= To: megaco@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-786028276-1065809484=:85401" Content-Transfer-Encoding: 8bit Subject: [Megaco] Regarding Context Audit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --0-786028276-1065809484=:85401 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi List, I have a doubt in context audit grammer. Assume that there is an active context which is not emergency. Now a context audit request comes with only emergency token MEGACO/1 [10.10.1.1]:2100 Transaction=1100000 {Context = 1 { ContextAudit {Emergency} } } As per the grammer Action reply should have error descriptor or command reply. In command reply we can send context properties whose grammer is contextProperties = contextProperty *(COMMA contextProperty) contextProperty = (topologyDescriptor / priority / EmergencyToken) Now here it is mandatory to send one of these tokens in context properties. It is not possible to send emergency token in this case as context is not emergency and the emergency token does not have a way to specify the value as TRUE or FALSE. What should be returned in this case ? Is there a way to send an empty context audit reply. Thanks in advance Shobhit Yahoo! India Matrimony: Find your partner online.Post your profile. --0-786028276-1065809484=:85401 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi List,
 
I have a doubt in context audit grammer.
 
Assume that there is an active context which is not emergency. Now a context audit request comes with only emergency token
MEGACO/1 [10.10.1.1]:2100 Transaction=1100000 {Context = 1 { ContextAudit {Emergency} } }
 
As per the grammer
Action reply should have error descriptor or command reply. In command reply we can send context properties whose grammer is
contextProperties    = contextProperty *(COMMA contextProperty) 
contextProperty    = (topologyDescriptor / priority / EmergencyToken)
Now here it is mandatory to send one of these tokens in context properties. It is not possible to send emergency token in this case as context is not emergency and the emergency token does not have a way to specify the value as TRUE or FALSE.
 
What should be returned in this case ? Is there a way to send an empty context audit reply.
 
Thanks in advance
Shobhit

Yahoo! India Matrimony: Find your partner online. Post your profile. --0-786028276-1065809484=:85401-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri Oct 10 14:22:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10724 for ; Fri, 10 Oct 2003 14:22:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A81tw-0007iN-HG for megaco-archive@odin.ietf.org; Fri, 10 Oct 2003 14:22:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AIM8fp029649 for megaco-archive@odin.ietf.org; Fri, 10 Oct 2003 14:22:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A81tw-0007i8-E9 for megaco-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 14:22:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10687 for ; Fri, 10 Oct 2003 14:21:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A81tt-0007FR-00 for megaco-web-archive@ietf.org; Fri, 10 Oct 2003 14:22:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A81tt-0007FN-00 for megaco-web-archive@ietf.org; Fri, 10 Oct 2003 14:22:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A81tp-0007ft-I2; Fri, 10 Oct 2003 14:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A81kL-0007EQ-2B for megaco@optimus.ietf.org; Fri, 10 Oct 2003 14:12:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10384 for ; Fri, 10 Oct 2003 14:12:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A81kI-000794-00 for megaco@ietf.org; Fri, 10 Oct 2003 14:12:10 -0400 Received: from web8101.mail.in.yahoo.com ([203.199.70.28] helo=web8101.in.yahoo.com) by ietf-mx with smtp (Exim 4.12) id 1A81kG-00078Q-00 for megaco@ietf.org; Fri, 10 Oct 2003 14:12:08 -0400 Message-ID: <20031010181124.86600.qmail@web8101.in.yahoo.com> Received: from [128.107.253.41] by web8101.mail.in.yahoo.com via HTTP; Fri, 10 Oct 2003 19:11:24 BST Date: Fri, 10 Oct 2003 19:11:24 +0100 (BST) From: =?iso-8859-1?q?Shobhit=20Bansal?= To: megaco@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-786028276-1065809484=:85401" Content-Transfer-Encoding: 8bit Subject: [Megaco] Regarding Context Audit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , --0-786028276-1065809484=:85401 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi List, I have a doubt in context audit grammer. Assume that there is an active context which is not emergency. Now a context audit request comes with only emergency token MEGACO/1 [10.10.1.1]:2100 Transaction=1100000 {Context = 1 { ContextAudit {Emergency} } } As per the grammer Action reply should have error descriptor or command reply. In command reply we can send context properties whose grammer is contextProperties = contextProperty *(COMMA contextProperty) contextProperty = (topologyDescriptor / priority / EmergencyToken) Now here it is mandatory to send one of these tokens in context properties. It is not possible to send emergency token in this case as context is not emergency and the emergency token does not have a way to specify the value as TRUE or FALSE. What should be returned in this case ? Is there a way to send an empty context audit reply. Thanks in advance Shobhit Yahoo! India Matrimony: Find your partner online.Post your profile. --0-786028276-1065809484=:85401 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Hi List,
 
I have a doubt in context audit grammer.
 
Assume that there is an active context which is not emergency. Now a context audit request comes with only emergency token
MEGACO/1 [10.10.1.1]:2100 Transaction=1100000 {Context = 1 { ContextAudit {Emergency} } }
 
As per the grammer
Action reply should have error descriptor or command reply. In command reply we can send context properties whose grammer is
contextProperties    = contextProperty *(COMMA contextProperty) 
contextProperty    = (topologyDescriptor / priority / EmergencyToken)
Now here it is mandatory to send one of these tokens in context properties. It is not possible to send emergency token in this case as context is not emergency and the emergency token does not have a way to specify the value as TRUE or FALSE.
 
What should be returned in this case ? Is there a way to send an empty context audit reply.
 
Thanks in advance
Shobhit

Yahoo! India Matrimony: Find your partner online. Post your profile. --0-786028276-1065809484=:85401-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Oct 10 23:27:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06093 for ; Fri, 10 Oct 2003 23:27:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8APG-00008R-0D; Fri, 10 Oct 2003 23:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8AP6-00007I-LZ for megaco@optimus.ietf.org; Fri, 10 Oct 2003 23:26:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06073 for ; Fri, 10 Oct 2003 23:26:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8AP4-00074E-00 for megaco@ietf.org; Fri, 10 Oct 2003 23:26:50 -0400 Received: from law15-f9.law15.hotmail.com ([64.4.23.9] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1A8AP3-000747-00 for megaco@ietf.org; Fri, 10 Oct 2003 23:26:49 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 10 Oct 2003 20:26:19 -0700 Received: from 210.83.240.187 by lw15fd.law15.hotmail.msn.com with HTTP; Sat, 11 Oct 2003 03:26:18 GMT X-Originating-IP: [210.83.240.187] X-Originating-Email: [juniperfu@hotmail.com] From: "å® ä»" To: megaco@ietf.org Date: Sat, 11 Oct 2003 11:26:18 +0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 11 Oct 2003 03:26:19.0467 (UTC) FILETIME=[6FCF41B0:01C38FA7] Subject: [Megaco] a problem about the individual digit events Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , All, In megaco v2 section 7.1.14.4, The document said mgc can set the individual digit events, But I can't find how to set the individual digit events, who can help me, thanks! Mark _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri Oct 10 23:27:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06108 for ; Fri, 10 Oct 2003 23:27:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8APV-00009n-Gs for megaco-archive@odin.ietf.org; Fri, 10 Oct 2003 23:27:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9B3RHsS000602 for megaco-archive@odin.ietf.org; Fri, 10 Oct 2003 23:27:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8APV-00009d-4r for megaco-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 23:27:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06088 for ; Fri, 10 Oct 2003 23:27:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8APS-00074a-00 for megaco-web-archive@ietf.org; Fri, 10 Oct 2003 23:27:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A8APS-00074X-00 for megaco-web-archive@ietf.org; Fri, 10 Oct 2003 23:27:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8APG-00008R-0D; Fri, 10 Oct 2003 23:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8AP6-00007I-LZ for megaco@optimus.ietf.org; Fri, 10 Oct 2003 23:26:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06073 for ; Fri, 10 Oct 2003 23:26:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8AP4-00074E-00 for megaco@ietf.org; Fri, 10 Oct 2003 23:26:50 -0400 Received: from law15-f9.law15.hotmail.com ([64.4.23.9] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1A8AP3-000747-00 for megaco@ietf.org; Fri, 10 Oct 2003 23:26:49 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 10 Oct 2003 20:26:19 -0700 Received: from 210.83.240.187 by lw15fd.law15.hotmail.msn.com with HTTP; Sat, 11 Oct 2003 03:26:18 GMT X-Originating-IP: [210.83.240.187] X-Originating-Email: [juniperfu@hotmail.com] From: "å® ä»" To: megaco@ietf.org Date: Sat, 11 Oct 2003 11:26:18 +0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 11 Oct 2003 03:26:19.0467 (UTC) FILETIME=[6FCF41B0:01C38FA7] Subject: [Megaco] a problem about the individual digit events Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , All, In megaco v2 section 7.1.14.4, The document said mgc can set the individual digit events, But I can't find how to set the individual digit events, who can help me, thanks! Mark _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Sat Oct 11 22:29:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21119 for ; Sat, 11 Oct 2003 22:29:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8Vyf-0008LL-Gs; Sat, 11 Oct 2003 22:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8Vxp-0008KZ-1F for megaco@optimus.ietf.org; Sat, 11 Oct 2003 22:28:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20972 for ; Sat, 11 Oct 2003 22:27:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8Vxi-0002IS-00 for megaco@ietf.org; Sat, 11 Oct 2003 22:28:02 -0400 Received: from law15-f56.law15.hotmail.com ([64.4.23.56] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1A8Vxh-0002I8-00 for megaco@ietf.org; Sat, 11 Oct 2003 22:28:02 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 11 Oct 2003 19:27:31 -0700 Received: from 210.21.224.54 by lw15fd.law15.hotmail.msn.com with HTTP; Sun, 12 Oct 2003 02:27:30 GMT X-Originating-IP: [210.21.224.54] X-Originating-Email: [juniperfu@hotmail.com] From: "å® ä»" To: megaco@ietf.org Date: Sun, 12 Oct 2003 10:27:30 +0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 12 Oct 2003 02:27:31.0266 (UTC) FILETIME=[63404220:01C39068] Subject: [Megaco] a problem about audit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , All, When MGC restart or HA, Maybe it need audit the context and termination of MG, and it can send the command Context = * { AuditValue= ROOT {Audit { } } and the MG should return Context = 100 { AuditValue= TermA, TermB } Context = 200 { AuditValue= TermC, TermD } Context = 300 { AuditValue= TermE, TermF } And my problem is if the MG has a lot of context and a megaco message can't include them, So how do the mg return all its context, thanks! Mark _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Sat Oct 11 22:29:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21134 for ; Sat, 11 Oct 2003 22:29:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8Vyk-0008MB-IV for megaco-archive@odin.ietf.org; Sat, 11 Oct 2003 22:29:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9C2T6oW032117 for megaco-archive@odin.ietf.org; Sat, 11 Oct 2003 22:29:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8Vyk-0008Lw-EZ for megaco-web-archive@optimus.ietf.org; Sat, 11 Oct 2003 22:29:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21072 for ; Sat, 11 Oct 2003 22:28:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8Vyh-0002Ka-00 for megaco-web-archive@ietf.org; Sat, 11 Oct 2003 22:29:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A8Vyg-0002KV-00 for megaco-web-archive@ietf.org; Sat, 11 Oct 2003 22:29:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8Vyf-0008LL-Gs; Sat, 11 Oct 2003 22:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8Vxp-0008KZ-1F for megaco@optimus.ietf.org; Sat, 11 Oct 2003 22:28:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20972 for ; Sat, 11 Oct 2003 22:27:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8Vxi-0002IS-00 for megaco@ietf.org; Sat, 11 Oct 2003 22:28:02 -0400 Received: from law15-f56.law15.hotmail.com ([64.4.23.56] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1A8Vxh-0002I8-00 for megaco@ietf.org; Sat, 11 Oct 2003 22:28:02 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 11 Oct 2003 19:27:31 -0700 Received: from 210.21.224.54 by lw15fd.law15.hotmail.msn.com with HTTP; Sun, 12 Oct 2003 02:27:30 GMT X-Originating-IP: [210.21.224.54] X-Originating-Email: [juniperfu@hotmail.com] From: "å® ä»" To: megaco@ietf.org Date: Sun, 12 Oct 2003 10:27:30 +0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 12 Oct 2003 02:27:31.0266 (UTC) FILETIME=[63404220:01C39068] Subject: [Megaco] a problem about audit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , All, When MGC restart or HA, Maybe it need audit the context and termination of MG, and it can send the command Context = * { AuditValue= ROOT {Audit { } } and the MG should return Context = 100 { AuditValue= TermA, TermB } Context = 200 { AuditValue= TermC, TermD } Context = 300 { AuditValue= TermE, TermF } And my problem is if the MG has a lot of context and a megaco message can't include them, So how do the mg return all its context, thanks! Mark _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Sat Oct 11 22:31:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21352 for ; Sat, 11 Oct 2003 22:31:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8W0d-00006U-0U; Sat, 11 Oct 2003 22:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8Vzf-0008PW-Q0 for megaco@optimus.ietf.org; Sat, 11 Oct 2003 22:30:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21187 for ; Sat, 11 Oct 2003 22:29:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8Vzb-0002Mg-00 for megaco@ietf.org; Sat, 11 Oct 2003 22:29:59 -0400 Received: from law15-f109.law15.hotmail.com ([64.4.23.109] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1A8Vzb-0002Ls-00 for megaco@ietf.org; Sat, 11 Oct 2003 22:29:59 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 11 Oct 2003 19:29:30 -0700 Received: from 210.21.224.54 by lw15fd.law15.hotmail.msn.com with HTTP; Sun, 12 Oct 2003 02:29:29 GMT X-Originating-IP: [210.21.224.54] X-Originating-Email: [juniperfu@hotmail.com] From: "å® ä»" To: megaco@ietf.org Date: Sun, 12 Oct 2003 10:29:29 +0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 12 Oct 2003 02:29:30.0015 (UTC) FILETIME=[AA07EAF0:01C39068] Subject: [Megaco] a problem about the buffer time of digit buffer Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , All, In megaco v2, The document said that the mg can buffer the digit in the buffer time, And Who can tell me how to set the digit buffer time, thanks! Mark _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Sat Oct 11 22:31:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21368 for ; Sat, 11 Oct 2003 22:31:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8W0e-00008A-Mp for megaco-archive@odin.ietf.org; Sat, 11 Oct 2003 22:31:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9C2V4ak000491 for megaco-archive@odin.ietf.org; Sat, 11 Oct 2003 22:31:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8W0e-00007l-ES for megaco-web-archive@optimus.ietf.org; Sat, 11 Oct 2003 22:31:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21292 for ; Sat, 11 Oct 2003 22:30:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8W0a-0002PK-00 for megaco-web-archive@ietf.org; Sat, 11 Oct 2003 22:31:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A8W0a-0002PG-00 for megaco-web-archive@ietf.org; Sat, 11 Oct 2003 22:31:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8W0d-00006U-0U; Sat, 11 Oct 2003 22:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8Vzf-0008PW-Q0 for megaco@optimus.ietf.org; Sat, 11 Oct 2003 22:30:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21187 for ; Sat, 11 Oct 2003 22:29:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8Vzb-0002Mg-00 for megaco@ietf.org; Sat, 11 Oct 2003 22:29:59 -0400 Received: from law15-f109.law15.hotmail.com ([64.4.23.109] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1A8Vzb-0002Ls-00 for megaco@ietf.org; Sat, 11 Oct 2003 22:29:59 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 11 Oct 2003 19:29:30 -0700 Received: from 210.21.224.54 by lw15fd.law15.hotmail.msn.com with HTTP; Sun, 12 Oct 2003 02:29:29 GMT X-Originating-IP: [210.21.224.54] X-Originating-Email: [juniperfu@hotmail.com] From: "å® ä»" To: megaco@ietf.org Date: Sun, 12 Oct 2003 10:29:29 +0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 12 Oct 2003 02:29:30.0015 (UTC) FILETIME=[AA07EAF0:01C39068] Subject: [Megaco] a problem about the buffer time of digit buffer Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , All, In megaco v2, The document said that the mg can buffer the digit in the buffer time, And Who can tell me how to set the digit buffer time, thanks! Mark _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Oct 14 08:12:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05557 for ; Tue, 14 Oct 2003 08:12:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9O1x-00010c-Fy; Tue, 14 Oct 2003 08:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8yTO-0005tK-UI for megaco@optimus.ietf.org; Mon, 13 Oct 2003 04:54:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26901 for ; Mon, 13 Oct 2003 04:54:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8yTL-0000RH-00 for megaco@ietf.org; Mon, 13 Oct 2003 04:54:35 -0400 Received: from smtrly01.smartm.com ([158.116.149.131]) by ietf-mx with esmtp (Exim 4.12) id 1A8yTL-0000RD-00 for megaco@ietf.org; Mon, 13 Oct 2003 04:54:35 -0400 Received: from freexcbh1.smartm.com ([10.149.1.65]) by smtrly01.smartm.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 13 Oct 2003 01:52:57 -0700 Received: from SR-BNG-EXC01.smartm.com (sr-bng-exc01.int.tsbu.net [10.208.1.24]) by freexcbh1.smartm.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id 4T26N4PX; Mon, 13 Oct 2003 01:57:24 -0700 Received: by sr-bng-exc01.int.tsbu.net with Internet Mail Service (5.5.2653.19) id ; Mon, 13 Oct 2003 14:28:06 +0530 Message-ID: <903E17B6FF22A24C96B4E28C2C0214D7013F4043@sr-bng-exc01.int.tsbu.net> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Nagaich Nitin To: megaco@ietf.org Date: Mon, 13 Oct 2003 14:28:06 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 13 Oct 2003 08:52:57.0937 (UTC) FILETIME=[663BF410:01C39167] Subject: [Megaco] PPT on megaco Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi, I am beginner in this field. I would appreciate you, if you could send me a detailed PPT/PDF on megaco which talks about the commands etc. thanks in advance, Nitin _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Tue Oct 14 08:12:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05572 for ; Tue, 14 Oct 2003 08:12:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9O23-00011X-Es for megaco-archive@odin.ietf.org; Tue, 14 Oct 2003 08:12:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9ECC7L8003933 for megaco-archive@odin.ietf.org; Tue, 14 Oct 2003 08:12:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9O23-00011M-4S for megaco-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 08:12:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05546 for ; Tue, 14 Oct 2003 08:11:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9O21-0001Vi-00 for megaco-web-archive@ietf.org; Tue, 14 Oct 2003 08:12:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9O21-0001Ve-00 for megaco-web-archive@ietf.org; Tue, 14 Oct 2003 08:12:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9O1x-00010c-Fy; Tue, 14 Oct 2003 08:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8yTO-0005tK-UI for megaco@optimus.ietf.org; Mon, 13 Oct 2003 04:54:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26901 for ; Mon, 13 Oct 2003 04:54:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8yTL-0000RH-00 for megaco@ietf.org; Mon, 13 Oct 2003 04:54:35 -0400 Received: from smtrly01.smartm.com ([158.116.149.131]) by ietf-mx with esmtp (Exim 4.12) id 1A8yTL-0000RD-00 for megaco@ietf.org; Mon, 13 Oct 2003 04:54:35 -0400 Received: from freexcbh1.smartm.com ([10.149.1.65]) by smtrly01.smartm.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 13 Oct 2003 01:52:57 -0700 Received: from SR-BNG-EXC01.smartm.com (sr-bng-exc01.int.tsbu.net [10.208.1.24]) by freexcbh1.smartm.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id 4T26N4PX; Mon, 13 Oct 2003 01:57:24 -0700 Received: by sr-bng-exc01.int.tsbu.net with Internet Mail Service (5.5.2653.19) id ; Mon, 13 Oct 2003 14:28:06 +0530 Message-ID: <903E17B6FF22A24C96B4E28C2C0214D7013F4043@sr-bng-exc01.int.tsbu.net> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Nagaich Nitin To: megaco@ietf.org Date: Mon, 13 Oct 2003 14:28:06 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 13 Oct 2003 08:52:57.0937 (UTC) FILETIME=[663BF410:01C39167] Subject: [Megaco] PPT on megaco Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi, I am beginner in this field. I would appreciate you, if you could send me a detailed PPT/PDF on megaco which talks about the commands etc. thanks in advance, Nitin _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Oct 14 08:22:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05937 for ; Tue, 14 Oct 2003 08:22:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9OBd-0001nh-0Q; Tue, 14 Oct 2003 08:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9OAp-0001mL-S1 for megaco@optimus.ietf.org; Tue, 14 Oct 2003 08:21:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05897 for ; Tue, 14 Oct 2003 08:21:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9OAo-0001dn-00 for megaco@ietf.org; Tue, 14 Oct 2003 08:21:10 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1A9OAn-0001dF-00 for megaco@ietf.org; Tue, 14 Oct 2003 08:21:10 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9ECKNlN018930; Tue, 14 Oct 2003 14:20:23 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <45JQCACL>; Tue, 14 Oct 2003 14:20:49 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'Nagaich Nitin'" , megaco@ietf.org Subject: RE: [Megaco] PPT on megaco Date: Tue, 14 Oct 2003 14:19:43 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi, RFC 3525 is a good start (www.ietf.org/rfc/rfc3525.txt). Regards, Christer Holmberg Ericsson Finland > -----Original Message----- > From: Nagaich Nitin [mailto:NitinN@smartm.com] > Sent: 13. lokakuuta 2003 11:58 > To: megaco@ietf.org > Subject: [Megaco] PPT on megaco > > > Hi, > I am beginner in this field. I would appreciate you, if > you could send me > a detailed PPT/PDF on megaco which talks about the commands etc. > > thanks in advance, > Nitin > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Tue Oct 14 08:22:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05952 for ; Tue, 14 Oct 2003 08:22:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9OBg-0001pJ-JM for megaco-archive@odin.ietf.org; Tue, 14 Oct 2003 08:22:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9ECM43U007015 for megaco-archive@odin.ietf.org; Tue, 14 Oct 2003 08:22:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9OBg-0001p2-CQ for megaco-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 08:22:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05926 for ; Tue, 14 Oct 2003 08:21:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9OBf-0001em-00 for megaco-web-archive@ietf.org; Tue, 14 Oct 2003 08:22:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9OBe-0001ej-00 for megaco-web-archive@ietf.org; Tue, 14 Oct 2003 08:22:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9OBd-0001nh-0Q; Tue, 14 Oct 2003 08:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9OAp-0001mL-S1 for megaco@optimus.ietf.org; Tue, 14 Oct 2003 08:21:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05897 for ; Tue, 14 Oct 2003 08:21:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9OAo-0001dn-00 for megaco@ietf.org; Tue, 14 Oct 2003 08:21:10 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1A9OAn-0001dF-00 for megaco@ietf.org; Tue, 14 Oct 2003 08:21:10 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9ECKNlN018930; Tue, 14 Oct 2003 14:20:23 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <45JQCACL>; Tue, 14 Oct 2003 14:20:49 +0200 Message-ID: From: "Christer Holmberg (JO/LMF)" To: "'Nagaich Nitin'" , megaco@ietf.org Subject: RE: [Megaco] PPT on megaco Date: Tue, 14 Oct 2003 14:19:43 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi, RFC 3525 is a good start (www.ietf.org/rfc/rfc3525.txt). Regards, Christer Holmberg Ericsson Finland > -----Original Message----- > From: Nagaich Nitin [mailto:NitinN@smartm.com] > Sent: 13. lokakuuta 2003 11:58 > To: megaco@ietf.org > Subject: [Megaco] PPT on megaco > > > Hi, > I am beginner in this field. I would appreciate you, if > you could send me > a detailed PPT/PDF on megaco which talks about the commands etc. > > thanks in advance, > Nitin > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Oct 15 10:12:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00737 for ; Wed, 15 Oct 2003 10:12:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9mNe-0000NT-Ke; Wed, 15 Oct 2003 10:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9mNB-0000Mh-8Z for megaco@optimus.ietf.org; Wed, 15 Oct 2003 10:11:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00635 for ; Wed, 15 Oct 2003 10:11:19 -0400 (EDT) From: bvswamy@hss.hns.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9mN4-0004lJ-00 for megaco@ietf.org; Wed, 15 Oct 2003 10:11:26 -0400 Received: from [202.54.26.202] (helo=hindon.hss.co.in) by ietf-mx with esmtp (Exim 4.12) id 1A9mN3-0004kO-00 for megaco@ietf.org; Wed, 15 Oct 2003 10:11:25 -0400 Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h9FE6kv24044 for ; Wed, 15 Oct 2003 19:36:46 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id h9FEBlJ05662 for ; Wed, 15 Oct 2003 19:41:47 +0530 (IST) To: Megaco Mailing List Date: Wed, 15 Oct 2003 19:36:37 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 15/10/2003 07:33:39 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [Megaco] IG guide for H248V2 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi All What is the latest document of H248.1 V2. Is it H248.1 V2 as of 05/2002 or any other draft version. Secondly is there any IG for H248.1 V2. Regards Venkat www.hssworld.com Hughes Software Systems "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Oct 15 10:12:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00758 for ; Wed, 15 Oct 2003 10:12:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9mNy-0000OT-VI for megaco-archive@odin.ietf.org; Wed, 15 Oct 2003 10:12:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FECM47001507 for megaco-archive@odin.ietf.org; Wed, 15 Oct 2003 10:12:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9mNw-0000OE-Mk for megaco-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 10:12:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00709 for ; Wed, 15 Oct 2003 10:12:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9mNu-0004mc-00 for megaco-web-archive@ietf.org; Wed, 15 Oct 2003 10:12:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9mNt-0004mY-00 for megaco-web-archive@ietf.org; Wed, 15 Oct 2003 10:12:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9mNe-0000NT-Ke; Wed, 15 Oct 2003 10:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9mNB-0000Mh-8Z for megaco@optimus.ietf.org; Wed, 15 Oct 2003 10:11:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00635 for ; Wed, 15 Oct 2003 10:11:19 -0400 (EDT) From: bvswamy@hss.hns.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9mN4-0004lJ-00 for megaco@ietf.org; Wed, 15 Oct 2003 10:11:26 -0400 Received: from [202.54.26.202] (helo=hindon.hss.co.in) by ietf-mx with esmtp (Exim 4.12) id 1A9mN3-0004kO-00 for megaco@ietf.org; Wed, 15 Oct 2003 10:11:25 -0400 Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h9FE6kv24044 for ; Wed, 15 Oct 2003 19:36:46 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id h9FEBlJ05662 for ; Wed, 15 Oct 2003 19:41:47 +0530 (IST) To: Megaco Mailing List Date: Wed, 15 Oct 2003 19:36:37 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 15/10/2003 07:33:39 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [Megaco] IG guide for H248V2 Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi All What is the latest document of H248.1 V2. Is it H248.1 V2 as of 05/2002 or any other draft version. Secondly is there any IG for H248.1 V2. Regards Venkat www.hssworld.com Hughes Software Systems "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Oct 15 14:02:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13165 for ; Wed, 15 Oct 2003 14:02:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9pyC-0007uz-Ll; Wed, 15 Oct 2003 14:02:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9pxI-0007sN-Lq for megaco@optimus.ietf.org; Wed, 15 Oct 2003 14:01:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13088 for ; Wed, 15 Oct 2003 14:00:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9pxG-0000vX-00 for megaco@ietf.org; Wed, 15 Oct 2003 14:01:02 -0400 Received: from relay.pacwest.com ([66.52.88.5]) by ietf-mx with esmtp (Exim 4.12) id 1A9pxF-0000vJ-00 for megaco@ietf.org; Wed, 15 Oct 2003 14:01:01 -0400 Received: from relay.pacwest.com (relay-dmz [172.16.1.39]) by relay.pacwest.com (8.11.6/8.11.6d) with ESMTP id h9FHgL623988 for ; Wed, 15 Oct 2003 10:42:21 -0700 Received: from exchange.adpw.pacwest.com ([172.16.1.133]) by relay.pacwest.com (8.11.6/8.11.6r) with ESMTP id h9FHgLH23982 for ; Wed, 15 Oct 2003 10:42:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Oct 2003 10:59:42 -0700 Message-ID: Thread-Topic: NAS package implementation Thread-Index: AcOTRhwBzIR+u7rFTJat5y1ZQgByVg== From: "Joseph Lee (CNS)" To: Content-Transfer-Encoding: quoted-printable Subject: [Megaco] NAS package implementation Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Anybody aware of any commercial implementation of the Megaco NAS package = on the either gateway or softswitch side? - Joseph Lee _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Oct 15 14:02:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13180 for ; Wed, 15 Oct 2003 14:02:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9pyG-0007w2-Im for megaco-archive@odin.ietf.org; Wed, 15 Oct 2003 14:02:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FI24Mn030501 for megaco-archive@odin.ietf.org; Wed, 15 Oct 2003 14:02:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9pyG-0007vs-8j for megaco-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 14:02:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13132 for ; Wed, 15 Oct 2003 14:01:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9pyD-0000wG-00 for megaco-web-archive@ietf.org; Wed, 15 Oct 2003 14:02:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9pyD-0000wD-00 for megaco-web-archive@ietf.org; Wed, 15 Oct 2003 14:02:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9pyC-0007uz-Ll; Wed, 15 Oct 2003 14:02:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9pxI-0007sN-Lq for megaco@optimus.ietf.org; Wed, 15 Oct 2003 14:01:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13088 for ; Wed, 15 Oct 2003 14:00:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9pxG-0000vX-00 for megaco@ietf.org; Wed, 15 Oct 2003 14:01:02 -0400 Received: from relay.pacwest.com ([66.52.88.5]) by ietf-mx with esmtp (Exim 4.12) id 1A9pxF-0000vJ-00 for megaco@ietf.org; Wed, 15 Oct 2003 14:01:01 -0400 Received: from relay.pacwest.com (relay-dmz [172.16.1.39]) by relay.pacwest.com (8.11.6/8.11.6d) with ESMTP id h9FHgL623988 for ; Wed, 15 Oct 2003 10:42:21 -0700 Received: from exchange.adpw.pacwest.com ([172.16.1.133]) by relay.pacwest.com (8.11.6/8.11.6r) with ESMTP id h9FHgLH23982 for ; Wed, 15 Oct 2003 10:42:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Oct 2003 10:59:42 -0700 Message-ID: Thread-Topic: NAS package implementation Thread-Index: AcOTRhwBzIR+u7rFTJat5y1ZQgByVg== From: "Joseph Lee (CNS)" To: Content-Transfer-Encoding: quoted-printable Subject: [Megaco] NAS package implementation Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Anybody aware of any commercial implementation of the Megaco NAS package = on the either gateway or softswitch side? - Joseph Lee _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Oct 16 03:16:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22571 for ; Thu, 16 Oct 2003 03:16:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA2Me-0003oH-GV; Thu, 16 Oct 2003 03:16:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA2Lx-0003hm-36 for megaco@optimus.ietf.org; Thu, 16 Oct 2003 03:15:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22533 for ; Thu, 16 Oct 2003 03:15:11 -0400 (EDT) From: bvswamy@hss.hns.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA2Lu-0001S9-00 for Megaco@ietf.org; Thu, 16 Oct 2003 03:15:18 -0400 Received: from [202.54.26.202] (helo=hindon.hss.co.in) by ietf-mx with esmtp (Exim 4.12) id 1AA2Ls-0001RP-00 for Megaco@ietf.org; Thu, 16 Oct 2003 03:15:17 -0400 Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h9G7Aav13262; Thu, 16 Oct 2003 12:40:36 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id h9G7FcA07990; Thu, 16 Oct 2003 12:45:38 +0530 (IST) Subject: RE: [Megaco] IG guide for H248V2 To: Nagaich Nitin Cc: Megaco@ietf.org Date: Thu, 16 Oct 2003 12:40:28 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 16/10/2003 12:37:28 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi Thanx for reply. However my query was for H248.1 Version 2 and not for version 1 documents. RFC 3525(ITU equivalent H248.1 V1 , 03/2002) does not contain new features added in H248.1 Version2(ITU) and draft-ietf-megaco-h248v2-04.txt(IETF). Regards Venkat Nagaich Nitin on 10/16/2003 11:55:08 AM To: B Venkat S.R Swamy/HSS@HSS cc: Subject: RE: [Megaco] IG guide for H248V2 rfc 3525 is the latest document. http://www.ietf.org/rfc/rfc3525.txt?number=3525 regards, Nitin -----Original Message----- From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com] Sent: Wednesday, October 15, 2003 7:37 PM To: Megaco Mailing List Subject: [Megaco] IG guide for H248V2 Hi All What is the latest document of H248.1 V2. Is it H248.1 V2 as of 05/2002 or any other draft version. Secondly is there any IG for H248.1 V2. Regards Venkat www.hssworld.com Hughes Software Systems "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Oct 16 03:16:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22586 for ; Thu, 16 Oct 2003 03:16:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA2Mp-0003pX-V3 for megaco-archive@odin.ietf.org; Thu, 16 Oct 2003 03:16:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9G7GFgN014722 for megaco-archive@odin.ietf.org; Thu, 16 Oct 2003 03:16:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA2Mp-0003pN-5H for megaco-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 03:16:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22565 for ; Thu, 16 Oct 2003 03:16:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA2Mm-0001Sb-00 for megaco-web-archive@ietf.org; Thu, 16 Oct 2003 03:16:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AA2Mm-0001SY-00 for megaco-web-archive@ietf.org; Thu, 16 Oct 2003 03:16:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA2Me-0003oH-GV; Thu, 16 Oct 2003 03:16:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA2Lx-0003hm-36 for megaco@optimus.ietf.org; Thu, 16 Oct 2003 03:15:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22533 for ; Thu, 16 Oct 2003 03:15:11 -0400 (EDT) From: bvswamy@hss.hns.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA2Lu-0001S9-00 for Megaco@ietf.org; Thu, 16 Oct 2003 03:15:18 -0400 Received: from [202.54.26.202] (helo=hindon.hss.co.in) by ietf-mx with esmtp (Exim 4.12) id 1AA2Ls-0001RP-00 for Megaco@ietf.org; Thu, 16 Oct 2003 03:15:17 -0400 Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h9G7Aav13262; Thu, 16 Oct 2003 12:40:36 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id h9G7FcA07990; Thu, 16 Oct 2003 12:45:38 +0530 (IST) Subject: RE: [Megaco] IG guide for H248V2 To: Nagaich Nitin Cc: Megaco@ietf.org Date: Thu, 16 Oct 2003 12:40:28 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 16/10/2003 12:37:28 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi Thanx for reply. However my query was for H248.1 Version 2 and not for version 1 documents. RFC 3525(ITU equivalent H248.1 V1 , 03/2002) does not contain new features added in H248.1 Version2(ITU) and draft-ietf-megaco-h248v2-04.txt(IETF). Regards Venkat Nagaich Nitin on 10/16/2003 11:55:08 AM To: B Venkat S.R Swamy/HSS@HSS cc: Subject: RE: [Megaco] IG guide for H248V2 rfc 3525 is the latest document. http://www.ietf.org/rfc/rfc3525.txt?number=3525 regards, Nitin -----Original Message----- From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com] Sent: Wednesday, October 15, 2003 7:37 PM To: Megaco Mailing List Subject: [Megaco] IG guide for H248V2 Hi All What is the latest document of H248.1 V2. Is it H248.1 V2 as of 05/2002 or any other draft version. Secondly is there any IG for H248.1 V2. Regards Venkat www.hssworld.com Hughes Software Systems "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Oct 16 07:46:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29316 for ; Thu, 16 Oct 2003 07:46:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA6Zv-00011O-E6; Thu, 16 Oct 2003 07:46:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA6Zr-00010o-HY for megaco@optimus.ietf.org; Thu, 16 Oct 2003 07:45:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29295 for ; Thu, 16 Oct 2003 07:45:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA6Zq-0003mt-00 for megaco@ietf.org; Thu, 16 Oct 2003 07:45:58 -0400 Received: from [203.197.168.150] (helo=mailscanout256k.tataelxsi.co.in) by ietf-mx with smtp (Exim 4.12) id 1AA6Zp-0003mW-00 for megaco@ietf.org; Thu, 16 Oct 2003 07:45:57 -0400 Received: FROM vscaninternal.tataelxsi.co.in BY mailscanout256k.tataelxsi.co.in ; Thu Oct 16 17:17:23 2003 +0500 Received: FROM bsh BY vscaninternal.tataelxsi.co.in ; Thu Oct 16 17:17:06 2003 +0500 From: "Shridhara B" To: Date: Thu, 16 Oct 2003 17:16:33 +0530 Message-ID: <001001c393db$26881800$d528010a@telxsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Content-Transfer-Encoding: 7bit Subject: [Megaco] Query on IP Transport Package. Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello All, We are implementing the IP Transport Package defined in 3GPP 29.232 v 5.6.0. Could any one of you please clarify the following? For the PropertyID, 'ipv4trans', the type is defined as 32 bit IPv4 Address. Similarly for the PropertyID, 'ipv6trans', the type is defined as 128 bit IPv6 Address. What should be the actual type of these? Whether we should treat it as 32/128 bit octet string OR we should treat 'ipv4trans' as the integer & 'ipv6trans' as the octet string? Some of the earlier answers suggests that we can treat in either way. Is there any way to get the contact information of the author of this package to really know the type to be used for the above. Thanks in advance. - Shridhara.B _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Oct 16 07:46:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29331 for ; Thu, 16 Oct 2003 07:46:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA6Zz-00012F-Gi for megaco-archive@odin.ietf.org; Thu, 16 Oct 2003 07:46:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GBk7El003973 for megaco-archive@odin.ietf.org; Thu, 16 Oct 2003 07:46:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA6Zz-000120-C2 for megaco-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 07:46:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29303 for ; Thu, 16 Oct 2003 07:45:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA6Zy-0003n4-00 for megaco-web-archive@ietf.org; Thu, 16 Oct 2003 07:46:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AA6Zy-0003n1-00 for megaco-web-archive@ietf.org; Thu, 16 Oct 2003 07:46:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA6Zv-00011O-E6; Thu, 16 Oct 2003 07:46:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA6Zr-00010o-HY for megaco@optimus.ietf.org; Thu, 16 Oct 2003 07:45:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29295 for ; Thu, 16 Oct 2003 07:45:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA6Zq-0003mt-00 for megaco@ietf.org; Thu, 16 Oct 2003 07:45:58 -0400 Received: from [203.197.168.150] (helo=mailscanout256k.tataelxsi.co.in) by ietf-mx with smtp (Exim 4.12) id 1AA6Zp-0003mW-00 for megaco@ietf.org; Thu, 16 Oct 2003 07:45:57 -0400 Received: FROM vscaninternal.tataelxsi.co.in BY mailscanout256k.tataelxsi.co.in ; Thu Oct 16 17:17:23 2003 +0500 Received: FROM bsh BY vscaninternal.tataelxsi.co.in ; Thu Oct 16 17:17:06 2003 +0500 From: "Shridhara B" To: Date: Thu, 16 Oct 2003 17:16:33 +0530 Message-ID: <001001c393db$26881800$d528010a@telxsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Content-Transfer-Encoding: 7bit Subject: [Megaco] Query on IP Transport Package. Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello All, We are implementing the IP Transport Package defined in 3GPP 29.232 v 5.6.0. Could any one of you please clarify the following? For the PropertyID, 'ipv4trans', the type is defined as 32 bit IPv4 Address. Similarly for the PropertyID, 'ipv6trans', the type is defined as 128 bit IPv6 Address. What should be the actual type of these? Whether we should treat it as 32/128 bit octet string OR we should treat 'ipv4trans' as the integer & 'ipv6trans' as the octet string? Some of the earlier answers suggests that we can treat in either way. Is there any way to get the contact information of the author of this package to really know the type to be used for the above. Thanks in advance. - Shridhara.B _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Oct 16 09:08:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01680 for ; Thu, 16 Oct 2003 09:08:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA7rF-000682-8o; Thu, 16 Oct 2003 09:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA7qn-00061C-5s for megaco@optimus.ietf.org; Thu, 16 Oct 2003 09:07:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01662 for ; Thu, 16 Oct 2003 09:07:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA7ql-0004aB-00 for Megaco@ietf.org; Thu, 16 Oct 2003 09:07:31 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1AA7qk-0004a7-00 for Megaco@ietf.org; Thu, 16 Oct 2003 09:07:31 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9GD6r624797 for ; Thu, 16 Oct 2003 09:06:53 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Oct 2003 09:06:53 -0400 Message-ID: From: "Kevin Boyle" To: bvswamy@hss.hns.com, Nagaich Nitin Cc: Megaco@ietf.org Subject: RE: [Megaco] IG guide for H248V2 Date: Thu, 16 Oct 2003 09:06:52 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , The current version 2 document is the 05/2002 document. I anticipate a Corrigendum being issued due to the January SG16 meeting, so look for an updated version in March next year. The current approved IG is available from the ITU. The most recent version was approved this past May. Kevin -----Original Message----- From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com] Sent: Thursday, October 16, 2003 3:10 AM To: Nagaich Nitin Cc: Megaco@ietf.org Subject: RE: [Megaco] IG guide for H248V2 Hi Thanx for reply. However my query was for H248.1 Version 2 and not for version 1 documents. RFC 3525(ITU equivalent H248.1 V1 , 03/2002) does not contain new features added in H248.1 Version2(ITU) and draft-ietf-megaco-h248v2-04.txt(IETF). Regards Venkat Nagaich Nitin on 10/16/2003 11:55:08 AM To: B Venkat S.R Swamy/HSS@HSS cc: Subject: RE: [Megaco] IG guide for H248V2 rfc 3525 is the latest document. http://www.ietf.org/rfc/rfc3525.txt?number=3525 regards, Nitin -----Original Message----- From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com] Sent: Wednesday, October 15, 2003 7:37 PM To: Megaco Mailing List Subject: [Megaco] IG guide for H248V2 Hi All What is the latest document of H248.1 V2. Is it H248.1 V2 as of 05/2002 or any other draft version. Secondly is there any IG for H248.1 V2. Regards Venkat www.hssworld.com Hughes Software Systems "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Oct 16 09:08:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01695 for ; Thu, 16 Oct 2003 09:08:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA7rI-00069k-8b for megaco-archive@odin.ietf.org; Thu, 16 Oct 2003 09:08:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GD84XA023651 for megaco-archive@odin.ietf.org; Thu, 16 Oct 2003 09:08:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA7rH-00069J-V8 for megaco-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 09:08:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01669 for ; Thu, 16 Oct 2003 09:07:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA7rG-0004aR-00 for megaco-web-archive@ietf.org; Thu, 16 Oct 2003 09:08:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AA7rG-0004aO-00 for megaco-web-archive@ietf.org; Thu, 16 Oct 2003 09:08:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA7rF-000682-8o; Thu, 16 Oct 2003 09:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA7qn-00061C-5s for megaco@optimus.ietf.org; Thu, 16 Oct 2003 09:07:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01662 for ; Thu, 16 Oct 2003 09:07:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA7ql-0004aB-00 for Megaco@ietf.org; Thu, 16 Oct 2003 09:07:31 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1AA7qk-0004a7-00 for Megaco@ietf.org; Thu, 16 Oct 2003 09:07:31 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9GD6r624797 for ; Thu, 16 Oct 2003 09:06:53 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Oct 2003 09:06:53 -0400 Message-ID: From: "Kevin Boyle" To: bvswamy@hss.hns.com, Nagaich Nitin Cc: Megaco@ietf.org Subject: RE: [Megaco] IG guide for H248V2 Date: Thu, 16 Oct 2003 09:06:52 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , The current version 2 document is the 05/2002 document. I anticipate a Corrigendum being issued due to the January SG16 meeting, so look for an updated version in March next year. The current approved IG is available from the ITU. The most recent version was approved this past May. Kevin -----Original Message----- From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com] Sent: Thursday, October 16, 2003 3:10 AM To: Nagaich Nitin Cc: Megaco@ietf.org Subject: RE: [Megaco] IG guide for H248V2 Hi Thanx for reply. However my query was for H248.1 Version 2 and not for version 1 documents. RFC 3525(ITU equivalent H248.1 V1 , 03/2002) does not contain new features added in H248.1 Version2(ITU) and draft-ietf-megaco-h248v2-04.txt(IETF). Regards Venkat Nagaich Nitin on 10/16/2003 11:55:08 AM To: B Venkat S.R Swamy/HSS@HSS cc: Subject: RE: [Megaco] IG guide for H248V2 rfc 3525 is the latest document. http://www.ietf.org/rfc/rfc3525.txt?number=3525 regards, Nitin -----Original Message----- From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com] Sent: Wednesday, October 15, 2003 7:37 PM To: Megaco Mailing List Subject: [Megaco] IG guide for H248V2 Hi All What is the latest document of H248.1 V2. Is it H248.1 V2 as of 05/2002 or any other draft version. Secondly is there any IG for H248.1 V2. Regards Venkat www.hssworld.com Hughes Software Systems "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Oct 17 09:20:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00966 for ; Fri, 17 Oct 2003 09:20:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAUWQ-0003s4-R9; Fri, 17 Oct 2003 09:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAUVk-0003pZ-PX for megaco@optimus.ietf.org; Fri, 17 Oct 2003 09:19:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00940 for ; Fri, 17 Oct 2003 09:19:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAUVj-0003HH-00 for megaco@ietf.org; Fri, 17 Oct 2003 09:19:19 -0400 Received: from smtrly01.smartm.com ([158.116.149.131]) by ietf-mx with esmtp (Exim 4.12) id 1AAUVi-0003H0-00 for megaco@ietf.org; Fri, 17 Oct 2003 09:19:18 -0400 Received: from freexcbh1.smartm.com ([10.149.1.65]) by smtrly01.smartm.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 17 Oct 2003 06:17:35 -0700 Received: from SR-BNG-EXC01.smartm.com (sr-bng-exc01.int.tsbu.net [10.208.1.24]) by freexcbh1.smartm.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id VB1JW8CN; Fri, 17 Oct 2003 06:22:07 -0700 Received: by sr-bng-exc01.int.tsbu.net with Internet Mail Service (5.5.2653.19) id <4854K97F>; Fri, 17 Oct 2003 18:47:55 +0530 Message-ID: <903E17B6FF22A24C96B4E28C2C0214D7013F40FD@sr-bng-exc01.int.tsbu.net> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Nagaich Nitin To: megaco@ietf.org Date: Fri, 17 Oct 2003 18:47:48 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 17 Oct 2003 13:17:35.0812 (UTC) FILETIME=[07D66840:01C394B1] Subject: [Megaco] free open-source downloadable Megaco stack Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi, Is there any free open-source downloadable Megaco stack? thanks in advance! Regards, Nitin _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri Oct 17 09:20:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00984 for ; Fri, 17 Oct 2003 09:20:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAUWX-0003tA-U1 for megaco-archive@odin.ietf.org; Fri, 17 Oct 2003 09:20:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HDK9Eq014940 for megaco-archive@odin.ietf.org; Fri, 17 Oct 2003 09:20:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAUWW-0003st-QK for megaco-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 09:20:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00955 for ; Fri, 17 Oct 2003 09:19:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAUWV-0003Hd-00 for megaco-web-archive@ietf.org; Fri, 17 Oct 2003 09:20:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAUWU-0003HZ-00 for megaco-web-archive@ietf.org; Fri, 17 Oct 2003 09:20:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAUWQ-0003s4-R9; Fri, 17 Oct 2003 09:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAUVk-0003pZ-PX for megaco@optimus.ietf.org; Fri, 17 Oct 2003 09:19:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00940 for ; Fri, 17 Oct 2003 09:19:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAUVj-0003HH-00 for megaco@ietf.org; Fri, 17 Oct 2003 09:19:19 -0400 Received: from smtrly01.smartm.com ([158.116.149.131]) by ietf-mx with esmtp (Exim 4.12) id 1AAUVi-0003H0-00 for megaco@ietf.org; Fri, 17 Oct 2003 09:19:18 -0400 Received: from freexcbh1.smartm.com ([10.149.1.65]) by smtrly01.smartm.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 17 Oct 2003 06:17:35 -0700 Received: from SR-BNG-EXC01.smartm.com (sr-bng-exc01.int.tsbu.net [10.208.1.24]) by freexcbh1.smartm.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id VB1JW8CN; Fri, 17 Oct 2003 06:22:07 -0700 Received: by sr-bng-exc01.int.tsbu.net with Internet Mail Service (5.5.2653.19) id <4854K97F>; Fri, 17 Oct 2003 18:47:55 +0530 Message-ID: <903E17B6FF22A24C96B4E28C2C0214D7013F40FD@sr-bng-exc01.int.tsbu.net> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Nagaich Nitin To: megaco@ietf.org Date: Fri, 17 Oct 2003 18:47:48 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 17 Oct 2003 13:17:35.0812 (UTC) FILETIME=[07D66840:01C394B1] Subject: [Megaco] free open-source downloadable Megaco stack Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi, Is there any free open-source downloadable Megaco stack? thanks in advance! Regards, Nitin _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Oct 17 11:32:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06659 for ; Fri, 17 Oct 2003 11:32:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAWa7-00022Z-Vb; Fri, 17 Oct 2003 11:31:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAWZW-00021I-1e for megaco@optimus.ietf.org; Fri, 17 Oct 2003 11:31:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06541 for ; Fri, 17 Oct 2003 11:31:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAWZV-0004WL-00 for megaco@ietf.org; Fri, 17 Oct 2003 11:31:21 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1AAWZU-0004W7-00 for megaco@ietf.org; Fri, 17 Oct 2003 11:31:20 -0400 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9HFVIoq007177; Fri, 17 Oct 2003 17:31:19 +0200 Received: from super.du.uab.ericsson.se ([134.138.176.16]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 45JYV3DA; Fri, 17 Oct 2003 17:34:58 +0200 Received: from bifur.du.uab.ericsson.se (daemon@bifur [134.138.177.75]) by super.du.uab.ericsson.se (8.10.1/8.10.1/erix-1.8) with ESMTP id h9HFVHT08908; Fri, 17 Oct 2003 17:31:17 +0200 (MET DST) Received: (from bmk@localhost) by bifur.du.uab.ericsson.se (8.11.6+Sun/8.9.1/client-1.0) id h9HFVHf20922; Fri, 17 Oct 2003 17:31:17 +0200 (MEST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <16272.2882.73819.810031@gargle.gargle.HOWL> Date: Fri, 17 Oct 2003 17:31:14 +0200 From: Micael Karlberg Reply-To: micael.karlberg@ericsson.com Organization: Ericsson AB (EAB/UKH/KD) To: Nagaich Nitin Cc: megaco@ietf.org Subject: [Megaco] free open-source downloadable Megaco stack In-Reply-To: <903E17B6FF22A24C96B4E28C2C0214D7013F40FD@sr-bng-exc01.int.tsbu.net> References: <903E17B6FF22A24C96B4E28C2C0214D7013F40FD@sr-bng-exc01.int.tsbu.net> X-Mailer: VM 7.07 under Emacs 21.1.1 Content-Transfer-Encoding: quoted-printable Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi, Try http://www.erlang.org/project/megaco/ The latest version 1.2.3 is however only available as=20 part of Erlang/OTP version R9C (also free), which you=20 have to download anyway, from http://www.erlang.org/. Regards, =09/BMK Nagaich Nitin writes: > Hi, > Is there any free open-source downloadable Megaco stack? >=20 > thanks in advance! >=20 > Regards, > Nitin >=20 > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco --=20 Micael Karlberg Ericsson AB, =C4lvsj=F6 Sweden Tel: +46 8 727 5668 EAB/UHK/KD - OTP Product Development ECN: 851 5668 Mail: micael.karlberg@ericsson.com Fax: +46 8 727 5775 =20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri Oct 17 11:32:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06674 for ; Fri, 17 Oct 2003 11:32:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAWaD-00024j-FI for megaco-archive@odin.ietf.org; Fri, 17 Oct 2003 11:32:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HFW5w3007971 for megaco-archive@odin.ietf.org; Fri, 17 Oct 2003 11:32:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAWaD-00024U-A9 for megaco-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 11:32:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06589 for ; Fri, 17 Oct 2003 11:31:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAWaC-0004Xf-00 for megaco-web-archive@ietf.org; Fri, 17 Oct 2003 11:32:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAWaB-0004Xc-00 for megaco-web-archive@ietf.org; Fri, 17 Oct 2003 11:32:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAWa7-00022Z-Vb; Fri, 17 Oct 2003 11:31:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAWZW-00021I-1e for megaco@optimus.ietf.org; Fri, 17 Oct 2003 11:31:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06541 for ; Fri, 17 Oct 2003 11:31:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAWZV-0004WL-00 for megaco@ietf.org; Fri, 17 Oct 2003 11:31:21 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1AAWZU-0004W7-00 for megaco@ietf.org; Fri, 17 Oct 2003 11:31:20 -0400 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9HFVIoq007177; Fri, 17 Oct 2003 17:31:19 +0200 Received: from super.du.uab.ericsson.se ([134.138.176.16]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 45JYV3DA; Fri, 17 Oct 2003 17:34:58 +0200 Received: from bifur.du.uab.ericsson.se (daemon@bifur [134.138.177.75]) by super.du.uab.ericsson.se (8.10.1/8.10.1/erix-1.8) with ESMTP id h9HFVHT08908; Fri, 17 Oct 2003 17:31:17 +0200 (MET DST) Received: (from bmk@localhost) by bifur.du.uab.ericsson.se (8.11.6+Sun/8.9.1/client-1.0) id h9HFVHf20922; Fri, 17 Oct 2003 17:31:17 +0200 (MEST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <16272.2882.73819.810031@gargle.gargle.HOWL> Date: Fri, 17 Oct 2003 17:31:14 +0200 From: Micael Karlberg Reply-To: micael.karlberg@ericsson.com Organization: Ericsson AB (EAB/UKH/KD) To: Nagaich Nitin Cc: megaco@ietf.org Subject: [Megaco] free open-source downloadable Megaco stack In-Reply-To: <903E17B6FF22A24C96B4E28C2C0214D7013F40FD@sr-bng-exc01.int.tsbu.net> References: <903E17B6FF22A24C96B4E28C2C0214D7013F40FD@sr-bng-exc01.int.tsbu.net> X-Mailer: VM 7.07 under Emacs 21.1.1 Content-Transfer-Encoding: quoted-printable Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, Try http://www.erlang.org/project/megaco/ The latest version 1.2.3 is however only available as=20 part of Erlang/OTP version R9C (also free), which you=20 have to download anyway, from http://www.erlang.org/. Regards, =09/BMK Nagaich Nitin writes: > Hi, > Is there any free open-source downloadable Megaco stack? >=20 > thanks in advance! >=20 > Regards, > Nitin >=20 > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco --=20 Micael Karlberg Ericsson AB, =C4lvsj=F6 Sweden Tel: +46 8 727 5668 EAB/UHK/KD - OTP Product Development ECN: 851 5668 Mail: micael.karlberg@ericsson.com Fax: +46 8 727 5775 =20 _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Oct 21 07:38:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13878 for ; Tue, 21 Oct 2003 07:38:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABupu-0007AC-KK; Tue, 21 Oct 2003 07:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABupJ-0006r8-NZ for megaco@optimus.ietf.org; Tue, 21 Oct 2003 07:37:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13860 for ; Tue, 21 Oct 2003 07:37:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABupJ-0002T3-00 for Megaco@ietf.org; Tue, 21 Oct 2003 07:37:25 -0400 Received: from [202.54.26.202] (helo=hindon.hss.co.in) by ietf-mx with esmtp (Exim 4.12) id 1ABupH-0002Ss-00 for Megaco@ietf.org; Tue, 21 Oct 2003 07:37:24 -0400 Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h9LBWSv04187; Tue, 21 Oct 2003 17:02:28 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id h9LBbhe13620; Tue, 21 Oct 2003 17:07:43 +0530 (IST) From: megaco_maillist@hss.hns.com Subject: RE: [Megaco] IG guide for H248V2 To: "Kevin Boyle" Cc: Megaco@ietf.org Date: Tue, 21 Oct 2003 17:02:31 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 21/10/2003 04:59:26 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi As far as the IG is concerned the most recent one is the May 2003 which have corrections over and above the H248.1 V1 and not for the H248.1 V2. Correct me if I am wrong. Regards Venkat "Kevin Boyle" @ietf.org on 10/16/2003 06:36:52 PM Sent by: megaco-admin@ietf.org To: B Venkat S.R Swamy/HSS@HSS, Nagaich Nitin cc: Megaco@ietf.org Subject: RE: [Megaco] IG guide for H248V2 The current version 2 document is the 05/2002 document. I anticipate a Corrigendum being issued due to the January SG16 meeting, so look for an updated version in March next year. The current approved IG is available from the ITU. The most recent version was approved this past May. Kevin -----Original Message----- From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com] Sent: Thursday, October 16, 2003 3:10 AM To: Nagaich Nitin Cc: Megaco@ietf.org Subject: RE: [Megaco] IG guide for H248V2 Hi Thanx for reply. However my query was for H248.1 Version 2 and not for version 1 documents. RFC 3525(ITU equivalent H248.1 V1 , 03/2002) does not contain new features added in H248.1 Version2(ITU) and draft-ietf-megaco-h248v2-04.txt(IETF). Regards Venkat Nagaich Nitin on 10/16/2003 11:55:08 AM To: B Venkat S.R Swamy/HSS@HSS cc: Subject: RE: [Megaco] IG guide for H248V2 rfc 3525 is the latest document. http://www.ietf.org/rfc/rfc3525.txt?number=3525 regards, Nitin -----Original Message----- From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com] Sent: Wednesday, October 15, 2003 7:37 PM To: Megaco Mailing List Subject: [Megaco] IG guide for H248V2 Hi All What is the latest document of H248.1 V2. Is it H248.1 V2 as of 05/2002 or any other draft version. Secondly is there any IG for H248.1 V2. Regards Venkat www.hssworld.com Hughes Software Systems "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Tue Oct 21 07:38:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13893 for ; Tue, 21 Oct 2003 07:38:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABuq0-0007EK-UP for megaco-archive@odin.ietf.org; Tue, 21 Oct 2003 07:38:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LBc8HV027778 for megaco-archive@odin.ietf.org; Tue, 21 Oct 2003 07:38:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABupz-0007D5-E3 for megaco-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 07:38:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13866 for ; Tue, 21 Oct 2003 07:37:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABupy-0002TC-00 for megaco-web-archive@ietf.org; Tue, 21 Oct 2003 07:38:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABupy-0002T8-00 for megaco-web-archive@ietf.org; Tue, 21 Oct 2003 07:38:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABupu-0007AC-KK; Tue, 21 Oct 2003 07:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABupJ-0006r8-NZ for megaco@optimus.ietf.org; Tue, 21 Oct 2003 07:37:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13860 for ; Tue, 21 Oct 2003 07:37:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABupJ-0002T3-00 for Megaco@ietf.org; Tue, 21 Oct 2003 07:37:25 -0400 Received: from [202.54.26.202] (helo=hindon.hss.co.in) by ietf-mx with esmtp (Exim 4.12) id 1ABupH-0002Ss-00 for Megaco@ietf.org; Tue, 21 Oct 2003 07:37:24 -0400 Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h9LBWSv04187; Tue, 21 Oct 2003 17:02:28 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id h9LBbhe13620; Tue, 21 Oct 2003 17:07:43 +0530 (IST) From: megaco_maillist@hss.hns.com Subject: RE: [Megaco] IG guide for H248V2 To: "Kevin Boyle" Cc: Megaco@ietf.org Date: Tue, 21 Oct 2003 17:02:31 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 21/10/2003 04:59:26 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi As far as the IG is concerned the most recent one is the May 2003 which have corrections over and above the H248.1 V1 and not for the H248.1 V2. Correct me if I am wrong. Regards Venkat "Kevin Boyle" @ietf.org on 10/16/2003 06:36:52 PM Sent by: megaco-admin@ietf.org To: B Venkat S.R Swamy/HSS@HSS, Nagaich Nitin cc: Megaco@ietf.org Subject: RE: [Megaco] IG guide for H248V2 The current version 2 document is the 05/2002 document. I anticipate a Corrigendum being issued due to the January SG16 meeting, so look for an updated version in March next year. The current approved IG is available from the ITU. The most recent version was approved this past May. Kevin -----Original Message----- From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com] Sent: Thursday, October 16, 2003 3:10 AM To: Nagaich Nitin Cc: Megaco@ietf.org Subject: RE: [Megaco] IG guide for H248V2 Hi Thanx for reply. However my query was for H248.1 Version 2 and not for version 1 documents. RFC 3525(ITU equivalent H248.1 V1 , 03/2002) does not contain new features added in H248.1 Version2(ITU) and draft-ietf-megaco-h248v2-04.txt(IETF). Regards Venkat Nagaich Nitin on 10/16/2003 11:55:08 AM To: B Venkat S.R Swamy/HSS@HSS cc: Subject: RE: [Megaco] IG guide for H248V2 rfc 3525 is the latest document. http://www.ietf.org/rfc/rfc3525.txt?number=3525 regards, Nitin -----Original Message----- From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com] Sent: Wednesday, October 15, 2003 7:37 PM To: Megaco Mailing List Subject: [Megaco] IG guide for H248V2 Hi All What is the latest document of H248.1 V2. Is it H248.1 V2 as of 05/2002 or any other draft version. Secondly is there any IG for H248.1 V2. Regards Venkat www.hssworld.com Hughes Software Systems "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Tue Oct 21 22:54:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24722 for ; Tue, 21 Oct 2003 22:54:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC98L-0001Us-Mn; Tue, 21 Oct 2003 22:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC980-0001RX-MU for megaco@optimus.ietf.org; Tue, 21 Oct 2003 22:53:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24712 for ; Tue, 21 Oct 2003 22:53:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC97w-0006sT-00 for Megaco@ietf.org; Tue, 21 Oct 2003 22:53:36 -0400 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1AC97w-0006sQ-00 for Megaco@ietf.org; Tue, 21 Oct 2003 22:53:36 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9M2qxP07587 for ; Tue, 21 Oct 2003 22:52:59 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Oct 2003 22:53:00 -0400 Message-ID: From: "Kevin Boyle" To: megaco_maillist@hss.hns.com Cc: Megaco@ietf.org Subject: RE: [Megaco] IG guide for H248V2 Date: Tue, 21 Oct 2003 22:52:52 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Consider yourself corrected. The IG contains any corrections identified for any of the H.248 sub-series, including H.248.1 v2. Kevin -----Original Message----- From: megaco_maillist@hss.hns.com [mailto:megaco_maillist@hss.hns.com] Sent: Tuesday, October 21, 2003 7:33 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH] Cc: Megaco@ietf.org Subject: RE: [Megaco] IG guide for H248V2 Hi As far as the IG is concerned the most recent one is the May 2003 which have corrections over and above the H248.1 V1 and not for the H248.1 V2. Correct me if I am wrong. Regards Venkat "Kevin Boyle" @ietf.org on 10/16/2003 06:36:52 PM Sent by: megaco-admin@ietf.org To: B Venkat S.R Swamy/HSS@HSS, Nagaich Nitin cc: Megaco@ietf.org Subject: RE: [Megaco] IG guide for H248V2 The current version 2 document is the 05/2002 document. I anticipate a Corrigendum being issued due to the January SG16 meeting, so look for an updated version in March next year. The current approved IG is available from the ITU. The most recent version was approved this past May. Kevin -----Original Message----- From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com] Sent: Thursday, October 16, 2003 3:10 AM To: Nagaich Nitin Cc: Megaco@ietf.org Subject: RE: [Megaco] IG guide for H248V2 Hi Thanx for reply. However my query was for H248.1 Version 2 and not for version 1 documents. RFC 3525(ITU equivalent H248.1 V1 , 03/2002) does not contain new features added in H248.1 Version2(ITU) and draft-ietf-megaco-h248v2-04.txt(IETF). Regards Venkat Nagaich Nitin on 10/16/2003 11:55:08 AM To: B Venkat S.R Swamy/HSS@HSS cc: Subject: RE: [Megaco] IG guide for H248V2 rfc 3525 is the latest document. http://www.ietf.org/rfc/rfc3525.txt?number=3525 regards, Nitin -----Original Message----- From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com] Sent: Wednesday, October 15, 2003 7:37 PM To: Megaco Mailing List Subject: [Megaco] IG guide for H248V2 Hi All What is the latest document of H248.1 V2. Is it H248.1 V2 as of 05/2002 or any other draft version. Secondly is there any IG for H248.1 V2. Regards Venkat www.hssworld.com Hughes Software Systems "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Tue Oct 21 22:54:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24737 for ; Tue, 21 Oct 2003 22:54:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC98R-0001XM-3S for megaco-archive@odin.ietf.org; Tue, 21 Oct 2003 22:54:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9M2s7xR005902 for megaco-archive@odin.ietf.org; Tue, 21 Oct 2003 22:54:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC98Q-0001X7-W4 for megaco-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 22:54:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24716 for ; Tue, 21 Oct 2003 22:53:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC98N-0006sc-00 for megaco-web-archive@ietf.org; Tue, 21 Oct 2003 22:54:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AC98N-0006sZ-00 for megaco-web-archive@ietf.org; Tue, 21 Oct 2003 22:54:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC98L-0001Us-Mn; Tue, 21 Oct 2003 22:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC980-0001RX-MU for megaco@optimus.ietf.org; Tue, 21 Oct 2003 22:53:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24712 for ; Tue, 21 Oct 2003 22:53:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC97w-0006sT-00 for Megaco@ietf.org; Tue, 21 Oct 2003 22:53:36 -0400 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1AC97w-0006sQ-00 for Megaco@ietf.org; Tue, 21 Oct 2003 22:53:36 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9M2qxP07587 for ; Tue, 21 Oct 2003 22:52:59 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Oct 2003 22:53:00 -0400 Message-ID: From: "Kevin Boyle" To: megaco_maillist@hss.hns.com Cc: Megaco@ietf.org Subject: RE: [Megaco] IG guide for H248V2 Date: Tue, 21 Oct 2003 22:52:52 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Consider yourself corrected. The IG contains any corrections identified for any of the H.248 sub-series, including H.248.1 v2. Kevin -----Original Message----- From: megaco_maillist@hss.hns.com [mailto:megaco_maillist@hss.hns.com] Sent: Tuesday, October 21, 2003 7:33 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH] Cc: Megaco@ietf.org Subject: RE: [Megaco] IG guide for H248V2 Hi As far as the IG is concerned the most recent one is the May 2003 which have corrections over and above the H248.1 V1 and not for the H248.1 V2. Correct me if I am wrong. Regards Venkat "Kevin Boyle" @ietf.org on 10/16/2003 06:36:52 PM Sent by: megaco-admin@ietf.org To: B Venkat S.R Swamy/HSS@HSS, Nagaich Nitin cc: Megaco@ietf.org Subject: RE: [Megaco] IG guide for H248V2 The current version 2 document is the 05/2002 document. I anticipate a Corrigendum being issued due to the January SG16 meeting, so look for an updated version in March next year. The current approved IG is available from the ITU. The most recent version was approved this past May. Kevin -----Original Message----- From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com] Sent: Thursday, October 16, 2003 3:10 AM To: Nagaich Nitin Cc: Megaco@ietf.org Subject: RE: [Megaco] IG guide for H248V2 Hi Thanx for reply. However my query was for H248.1 Version 2 and not for version 1 documents. RFC 3525(ITU equivalent H248.1 V1 , 03/2002) does not contain new features added in H248.1 Version2(ITU) and draft-ietf-megaco-h248v2-04.txt(IETF). Regards Venkat Nagaich Nitin on 10/16/2003 11:55:08 AM To: B Venkat S.R Swamy/HSS@HSS cc: Subject: RE: [Megaco] IG guide for H248V2 rfc 3525 is the latest document. http://www.ietf.org/rfc/rfc3525.txt?number=3525 regards, Nitin -----Original Message----- From: bvswamy@hss.hns.com [mailto:bvswamy@hss.hns.com] Sent: Wednesday, October 15, 2003 7:37 PM To: Megaco Mailing List Subject: [Megaco] IG guide for H248V2 Hi All What is the latest document of H248.1 V2. Is it H248.1 V2 as of 05/2002 or any other draft version. Secondly is there any IG for H248.1 V2. Regards Venkat www.hssworld.com Hughes Software Systems "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Wed Oct 22 05:14:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00031 for ; Wed, 22 Oct 2003 05:14:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACF45-000589-PW; Wed, 22 Oct 2003 05:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACF3j-00052B-DX for megaco@optimus.ietf.org; Wed, 22 Oct 2003 05:13:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00010 for ; Wed, 22 Oct 2003 05:13:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACF3f-0002R2-00 for megaco@ietf.org; Wed, 22 Oct 2003 05:13:35 -0400 Received: from [147.6.42.146] (helo=filter2.kt.co.kr) by ietf-mx with esmtp (Exim 4.12) id 1ACF3a-0002Qs-00 for megaco@ietf.org; Wed, 22 Oct 2003 05:13:30 -0400 Received: from external ([147.6.60.37]) by filter2 (1.0) id h9M9AH118686; Wed, 22 Oct 2003 18:10:17 +0900 Message-ID: <002901c3987c$adc659d0$253c0693@hawks> From: =?utf-8?B?7Jyk64+Z7J28?= To: Date: Wed, 22 Oct 2003 18:12:55 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0025_01C398C8.1D79F980" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Megaco] about Stream ID Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0025_01C398C8.1D79F980 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0026_01C398C8.1D7B8020" ------=_NextPart_001_0026_01C398C8.1D7B8020 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkuDQoNCkknbSBEb25nLUlsIFlvb24gaW4gS1QuDQoNCiANCg0KSSBoYXZlIGEgcXVlc3Rpb24g YWJvdXQgc3RyZWFtIGRlc2NyaXB0b3Igb2YgTUVHQUNPIHByb3RvY29sLiANCg0KIA0KDQpJbiA3 LjEuNCBNZWRpYSBkZXNjcmlwdG9yIG9mIEguMjQ4LjEsIHRoZXJlIGlzIGEgbGFzdCBzZW50ZW5j ZSBhcyANCg0KIiBBcyBhIGNvbnZlbmllbmNlLCBMb2NhbENvbnRyb2wsIExvY2FsLCBvciBSZW1v dGUgZGVzY3JpcHRvcnMgbWF5IGJlIGluY2x1ZGVkIGluIHRoZSBNZWRpYSBkZXNjcmlwdG9yIHdp dGhvdXQgYW4gZW5jbG9zaW5nIFN0cmVhbSBkZXNjcmlwdG9yLiBJbiB0aGlzIGNhc2UsIHRoZSBT dHJlYW1JRCBpcyBhc3N1bWVkIHRvIGJlIDEuIg0KDQogDQoNCkkgdGhpbmsgdGhhdCB0aG9zZSBz ZW50ZW5zZSB3aWxsIG5vdCBhcHBseSB0byBtZWdhY28gQ29tbWFuZCBSZXBseSBtZXNzYWdlIGJ1 dCBDb21tYW5kIFJlcXVlc3QgbWVzc2FnZS4NCg0KSSBtZWFuLCBmb3IgZXhhbXBsZSwgaWYgTUdD IHNlbmQgQWRkIFJlcXVlc3QgbWVzc2FnZSB3aXRoIFN0cmVhbUlEPTEgdGhlbiBNRyBtdXN0IHJl c3BvbnNlIEFkZCBSZXBseSBtZXNzYWdlIHdpdGggc2FtZSBTdHJlYW1JRD0xLCBhbmQgaWYgTUdD IHNlbmQgQWRkIFJlcXVlc3QgbWVzc2FnZSAgd2l0aG91dCBTdHJlYW1JRCB0aGVuIE1HIG11c3Qg cmVzcG9uc2UgQWRkIFJlcGx5IHdpdGhvdXQgU3RyZWFtSUQuDQoNCiANCg0KSW4gY29uY2x1c2lv biwgbGFzdCBzZW50ZW5zZSBpbiA3LjEuNCAsIEkgdGhpbmssICB5b3UgbWVhbiB0aGF0ICwgYXMg YSBjb252ZW5pZW5jZSwgTUdDIGNhbiBvbWl0IFN0cmVhbSBkZXNjcmlwdG9yIHdoZW4gdGhlIHN0 cmVhbUlEPTEsIGFuZCB0aGVuIE1HIGhhdmUgdG8gYXNzdW1lIHRoYXQgc3RyZWFtSUQ9MS4NCg0K IA0KDQpJIGFtIGNvbmNlcm5lZCB0aGF0IG15IGFuYWx5c2UgaXMgcmlnaHQuIA0KDQpJJ20gd2Fp dGluZyB5b3VyIHJlc3BvbnNlLg0KDQogDQoNClJlZ2FyZHMuDQo= ------=_NextPart_001_0026_01C398C8.1D7B8020 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI4MDAuMTI2NCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4N CjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD4NCjxQIGNsYXNz PU1zb05vcm1hbCANCnN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0OyBXT1JELUJSRUFLOiBrZWVw LWFsbDsgVEVYVC1BTElHTjogbGVmdDsgbXNvLWxheW91dC1ncmlkLWFsaWduOiBub25lIiANCmFs aWduPWxlZnQ+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULUZBTUlMWTog6rW066a8OyBt c28taGFuc2ktZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYmlkaS1mb250LWZh bWlseTog6rW066a8OyBtc28tZm9udC1rZXJuaW5nOiAwcHQiPjxGT05UIA0Kc2l6ZT0yPkhpLjw/ eG1sOm5hbWVzcGFjZSBwcmVmaXggPSBvIG5zID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNv bTpvZmZpY2U6b2ZmaWNlIiAvPjxvOnA+PC9vOnA+PC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFz cz1Nc29Ob3JtYWwgDQpzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdDsgV09SRC1CUkVBSzoga2Vl cC1hbGw7IFRFWFQtQUxJR046IGxlZnQ7IG1zby1sYXlvdXQtZ3JpZC1hbGlnbjogbm9uZSIgDQph bGlnbj1sZWZ0PjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1GQU1JTFk6IOq1tOumvDsg bXNvLWhhbnNpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWJpZGktZm9udC1m YW1pbHk6IOq1tOumvDsgbXNvLWZvbnQta2VybmluZzogMHB0Ij48Rk9OVCANCnNpemU9Mj5JJ20g RG9uZy1JbCBZb29uIGluIEtULjxvOnA+PC9vOnA+PC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFz cz1Nc29Ob3JtYWwgDQpzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdDsgV09SRC1CUkVBSzoga2Vl cC1hbGw7IFRFWFQtQUxJR046IGxlZnQ7IG1zby1sYXlvdXQtZ3JpZC1hbGlnbjogbm9uZSIgDQph bGlnbj1sZWZ0PjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1GQU1JTFk6IOq1tOumvDsg bXNvLWhhbnNpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWJpZGktZm9udC1m YW1pbHk6IOq1tOumvDsgbXNvLWZvbnQta2VybmluZzogMHB0Ij48bzpwPjxGT05UIA0Kc2l6ZT0y PiZuYnNwOzwvRk9OVD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIA0Kc3R5 bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQ7IFdPUkQtQlJFQUs6IGtlZXAtYWxsOyBURVhULUFMSUdO OiBsZWZ0OyBtc28tbGF5b3V0LWdyaWQtYWxpZ246IG5vbmUiIA0KYWxpZ249bGVmdD48U1BBTiBs YW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiDqtbTrprw7IG1zby1oYW5zaS1mb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiDqtbTrprw7IG1z by1mb250LWtlcm5pbmc6IDBwdCI+PEZPTlQgDQpzaXplPTI+SSBoYXZlIGEgcXVlc3Rpb24gYWJv dXQgc3RyZWFtIGRlc2NyaXB0b3Igb2YgTUVHQUNPIHByb3RvY29sLiANCjxvOnA+PC9vOnA+PC9G T05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgDQpzdHlsZT0iTUFSR0lOOiAwY20g MGNtIDBwdDsgV09SRC1CUkVBSzoga2VlcC1hbGw7IFRFWFQtQUxJR046IGxlZnQ7IG1zby1sYXlv dXQtZ3JpZC1hbGlnbjogbm9uZSIgDQphbGlnbj1sZWZ0PjxTUEFOIGxhbmc9RU4tVVMgDQpzdHls ZT0iRk9OVC1GQU1JTFk6IOq1tOumvDsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJzsgbXNvLWJpZGktZm9udC1mYW1pbHk6IOq1tOumvDsgbXNvLWZvbnQta2VybmluZzog MHB0Ij48bzpwPjxGT05UIA0Kc2l6ZT0yPiZuYnNwOzwvRk9OVD48L286cD48L1NQQU4+PC9QPg0K PFAgY2xhc3M9TXNvTm9ybWFsIA0Kc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQ7IFdPUkQtQlJF QUs6IGtlZXAtYWxsOyBURVhULUFMSUdOOiBsZWZ0OyBtc28tbGF5b3V0LWdyaWQtYWxpZ246IG5v bmUiIA0KYWxpZ249bGVmdD48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiDq tbTrprw7IG1zby1oYW5zaS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1iaWRp LWZvbnQtZmFtaWx5OiDqtbTrprw7IG1zby1mb250LWtlcm5pbmc6IDBwdCI+PEZPTlQgDQpzaXpl PTI+SW4gNy4xLjQgTWVkaWEgZGVzY3JpcHRvciBvZiBILjI0OC4xLCB0aGVyZSBpcyBhIGxhc3Qg c2VudGVuY2UgYXMgDQo8bzpwPjwvbzpwPjwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNv Tm9ybWFsIA0Kc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQ7IFdPUkQtQlJFQUs6IGtlZXAtYWxs OyBURVhULUFMSUdOOiBsZWZ0OyBtc28tbGF5b3V0LWdyaWQtYWxpZ246IG5vbmUiIA0KYWxpZ249 bGVmdD48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiDqtbTrprw7IG1zby1o YW5zaS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1iaWRpLWZvbnQtZmFtaWx5 OiDqtbTrprw7IG1zby1mb250LWtlcm5pbmc6IDBwdCI+PEZPTlQgDQpzaXplPTI+IiBBcyBhIGNv bnZlbmllbmNlLCBMb2NhbENvbnRyb2wsIExvY2FsLCBvciBSZW1vdGUgZGVzY3JpcHRvcnMgbWF5 IGJlIA0KaW5jbHVkZWQgaW4gdGhlIE1lZGlhIGRlc2NyaXB0b3Igd2l0aG91dCBhbiBlbmNsb3Np bmcgU3RyZWFtIGRlc2NyaXB0b3IuIEluIHRoaXMgDQpjYXNlLCB0aGUgU3RyZWFtSUQgaXMgYXNz dW1lZCB0byBiZSAxLiI8bzpwPjwvbzpwPjwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNv Tm9ybWFsIA0Kc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQ7IFdPUkQtQlJFQUs6IGtlZXAtYWxs OyBURVhULUFMSUdOOiBsZWZ0OyBtc28tbGF5b3V0LWdyaWQtYWxpZ246IG5vbmUiIA0KYWxpZ249 bGVmdD48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiDqtbTrprw7IG1zby1o YW5zaS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1iaWRpLWZvbnQtZmFtaWx5 OiDqtbTrprw7IG1zby1mb250LWtlcm5pbmc6IDBwdCI+PG86cD48Rk9OVCANCnNpemU9Mj4mbmJz cDs8L0ZPTlQ+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCANCnN0eWxlPSJN QVJHSU46IDBjbSAwY20gMHB0OyBXT1JELUJSRUFLOiBrZWVwLWFsbDsgVEVYVC1BTElHTjogbGVm dDsgbXNvLWxheW91dC1ncmlkLWFsaWduOiBub25lIiANCmFsaWduPWxlZnQ+PFNQQU4gbGFuZz1F Ti1VUyANCnN0eWxlPSJGT05ULUZBTUlMWTog6rW066a8OyBtc28taGFuc2ktZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYmlkaS1mb250LWZhbWlseTog6rW066a8OyBtc28tZm9u dC1rZXJuaW5nOiAwcHQiPjxGT05UIA0Kc2l6ZT0yPkkgdGhpbmsgdGhhdCB0aG9zZSBzZW50ZW5z ZSB3aWxsIG5vdCBhcHBseSB0byBtZWdhY28gQ29tbWFuZCBSZXBseSANCm1lc3NhZ2UgYnV0IENv bW1hbmQgUmVxdWVzdCBtZXNzYWdlLjxvOnA+PC9vOnA+PC9GT05UPjwvU1BBTj48L1A+DQo8UCBj bGFzcz1Nc29Ob3JtYWwgDQpzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdDsgV09SRC1CUkVBSzog a2VlcC1hbGw7IFRFWFQtQUxJR046IGxlZnQ7IG1zby1sYXlvdXQtZ3JpZC1hbGlnbjogbm9uZSIg DQphbGlnbj1sZWZ0PjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1GQU1JTFk6IOq1tOum vDsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWJpZGktZm9u dC1mYW1pbHk6IOq1tOumvDsgbXNvLWZvbnQta2VybmluZzogMHB0Ij48Rk9OVCANCnNpemU9Mj5J IG1lYW4sIGZvciBleGFtcGxlLCBpZiBNR0Mgc2VuZCBBZGQgUmVxdWVzdCBtZXNzYWdlIHdpdGgg U3RyZWFtSUQ9MSB0aGVuIA0KTUcgbXVzdCByZXNwb25zZSBBZGQgUmVwbHkgbWVzc2FnZSB3aXRo IHNhbWUgU3RyZWFtSUQ9MSwgYW5kIGlmIE1HQyBzZW5kIEFkZCANClJlcXVlc3QgbWVzc2FnZTxT UEFOIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvU1BBTj53aXRob3V0IFN0cmVh bUlEIA0KdGhlbiBNRyBtdXN0IHJlc3BvbnNlIEFkZCBSZXBseSB3aXRob3V0IFN0cmVhbUlELjxv OnA+PC9vOnA+PC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgDQpzdHlsZT0i TUFSR0lOOiAwY20gMGNtIDBwdDsgV09SRC1CUkVBSzoga2VlcC1hbGw7IFRFWFQtQUxJR046IGxl ZnQ7IG1zby1sYXlvdXQtZ3JpZC1hbGlnbjogbm9uZSIgDQphbGlnbj1sZWZ0PjxTUEFOIGxhbmc9 RU4tVVMgDQpzdHlsZT0iRk9OVC1GQU1JTFk6IOq1tOumvDsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWJpZGktZm9udC1mYW1pbHk6IOq1tOumvDsgbXNvLWZv bnQta2VybmluZzogMHB0Ij48bzpwPjxGT05UIA0Kc2l6ZT0yPiZuYnNwOzwvRk9OVD48L286cD48 L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIA0Kc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAw cHQ7IFdPUkQtQlJFQUs6IGtlZXAtYWxsOyBURVhULUFMSUdOOiBsZWZ0OyBtc28tbGF5b3V0LWdy aWQtYWxpZ246IG5vbmUiIA0KYWxpZ249bGVmdD48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZP TlQtRkFNSUxZOiDqtbTrprw7IG1zby1oYW5zaS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h bic7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiDqtbTrprw7IG1zby1mb250LWtlcm5pbmc6IDBwdCI+ PEZPTlQgDQpzaXplPTI+SW4gY29uY2x1c2lvbiwgbGFzdCBzZW50ZW5zZSBpbiA3LjEuNCAsIEkg dGhpbmssPFNQQU4gDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyA8L1NQQU4+eW91 IG1lYW4gdGhhdCAsIGFzIGEgY29udmVuaWVuY2UsIE1HQyANCmNhbiBvbWl0IFN0cmVhbSBkZXNj cmlwdG9yIHdoZW4gdGhlIHN0cmVhbUlEPTEsIGFuZCB0aGVuIE1HIGhhdmUgdG8gYXNzdW1lIHRo YXQgDQpzdHJlYW1JRD0xLjxvOnA+PC9vOnA+PC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1N c29Ob3JtYWwgDQpzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdDsgV09SRC1CUkVBSzoga2VlcC1h bGw7IFRFWFQtQUxJR046IGxlZnQ7IG1zby1sYXlvdXQtZ3JpZC1hbGlnbjogbm9uZSIgDQphbGln bj1sZWZ0PjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1GQU1JTFk6IOq1tOumvDsgbXNv LWhhbnNpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWJpZGktZm9udC1mYW1p bHk6IOq1tOumvDsgbXNvLWZvbnQta2VybmluZzogMHB0Ij48bzpwPjxGT05UIA0Kc2l6ZT0yPiZu YnNwOzwvRk9OVD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIA0Kc3R5bGU9 Ik1BUkdJTjogMGNtIDBjbSAwcHQ7IFdPUkQtQlJFQUs6IGtlZXAtYWxsOyBURVhULUFMSUdOOiBs ZWZ0OyBtc28tbGF5b3V0LWdyaWQtYWxpZ246IG5vbmUiIA0KYWxpZ249bGVmdD48U1BBTiBsYW5n PUVOLVVTIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiDqtbTrprw7IG1zby1oYW5zaS1mb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiDqtbTrprw7IG1zby1m b250LWtlcm5pbmc6IDBwdCI+PEZPTlQgDQpzaXplPTI+SSBhbSBjb25jZXJuZWQgdGhhdCBteSBh bmFseXNlIGlzIHJpZ2h0LiA8bzpwPjwvbzpwPjwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9 TXNvTm9ybWFsIA0Kc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQ7IFdPUkQtQlJFQUs6IGtlZXAt YWxsOyBURVhULUFMSUdOOiBsZWZ0OyBtc28tbGF5b3V0LWdyaWQtYWxpZ246IG5vbmUiIA0KYWxp Z249bGVmdD48U1BBTiANCnN0eWxlPSJGT05ULUZBTUlMWTog6rW066a8OyBtc28taGFuc2ktZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYmlkaS1mb250LWZhbWlseTog6rW066a8 OyBtc28tZm9udC1rZXJuaW5nOiAwcHQ7IG1zby1hbnNpLWxhbmd1YWdlOiBLTyI+PEZPTlQgDQpz aXplPTI+SSdtIHdhaXRpbmcgeW91ciByZXNwb25zZS48bzpwPjwvbzpwPjwvRk9OVD48L1NQQU4+ PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIA0Kc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQ7IFdP UkQtQlJFQUs6IGtlZXAtYWxsOyBURVhULUFMSUdOOiBsZWZ0OyBtc28tbGF5b3V0LWdyaWQtYWxp Z246IG5vbmUiIA0KYWxpZ249bGVmdD48U1BBTiANCnN0eWxlPSJGT05ULUZBTUlMWTog6rW066a8 OyBtc28taGFuc2ktZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYmlkaS1mb250 LWZhbWlseTog6rW066a8OyBtc28tZm9udC1rZXJuaW5nOiAwcHQ7IG1zby1hbnNpLWxhbmd1YWdl OiBLTyI+PG86cD48Rk9OVCANCnNpemU9Mj4mbmJzcDs8L0ZPTlQ+PC9vOnA+PC9TUEFOPjwvUD4N CjxQIGNsYXNzPU1zb05vcm1hbCANCnN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0OyBXT1JELUJS RUFLOiBrZWVwLWFsbDsgVEVYVC1BTElHTjogbGVmdDsgbXNvLWxheW91dC1ncmlkLWFsaWduOiBu b25lIiANCmFsaWduPWxlZnQ+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6IOq1tOumvDsgbXNv LWhhbnNpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWJpZGktZm9udC1mYW1p bHk6IOq1tOumvDsgbXNvLWZvbnQta2VybmluZzogMHB0OyBtc28tYW5zaS1sYW5ndWFnZTogS08i PjxGT05UIA0Kc2l6ZT0yPlJlZ2FyZHMuPG86cD48L286cD48L0ZPTlQ+PC9TUEFOPjwvUD48L0ZP TlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_001_0026_01C398C8.1D7B8020-- ------=_NextPart_000_0025_01C398C8.1D79F980 Content-Type: text/x-vcard; name="=?utf-8?B?7Jyk64+Z7J28LnZjZg==?=" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="=?utf-8?B?7Jyk64+Z7J28LnZjZg==?=" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:;=C0=B1=B5=BF=C0=CF FN:=C0=B1=B5=BF=C0=CF ORG:042-870-8345 TITLE:=C5=EB=BD=C5=B8=C1=BF=AC=B1=B8=BC=D2 TEL;CELL;VOICE:016-451-2385 TEL;WORK;FAX:KT ADR;WORK:;042-870-8389 LABEL;WORK:042-870-8389 EMAIL;PREF;INTERNET:diyoon@kt.co.kr REV:20031022T091255Z END:VCARD ------=_NextPart_000_0025_01C398C8.1D79F980-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Wed Oct 22 05:14:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00047 for ; Wed, 22 Oct 2003 05:14:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACF48-0005A0-Rl for megaco-archive@odin.ietf.org; Wed, 22 Oct 2003 05:14:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9M9E45S019833 for megaco-archive@odin.ietf.org; Wed, 22 Oct 2003 05:14:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACF48-00059o-Fg for megaco-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 05:14:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00019 for ; Wed, 22 Oct 2003 05:13:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACF44-0002RF-00 for megaco-web-archive@ietf.org; Wed, 22 Oct 2003 05:14:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACF44-0002RC-00 for megaco-web-archive@ietf.org; Wed, 22 Oct 2003 05:14:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACF45-000589-PW; Wed, 22 Oct 2003 05:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACF3j-00052B-DX for megaco@optimus.ietf.org; Wed, 22 Oct 2003 05:13:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00010 for ; Wed, 22 Oct 2003 05:13:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACF3f-0002R2-00 for megaco@ietf.org; Wed, 22 Oct 2003 05:13:35 -0400 Received: from [147.6.42.146] (helo=filter2.kt.co.kr) by ietf-mx with esmtp (Exim 4.12) id 1ACF3a-0002Qs-00 for megaco@ietf.org; Wed, 22 Oct 2003 05:13:30 -0400 Received: from external ([147.6.60.37]) by filter2 (1.0) id h9M9AH118686; Wed, 22 Oct 2003 18:10:17 +0900 Message-ID: <002901c3987c$adc659d0$253c0693@hawks> From: =?utf-8?B?7Jyk64+Z7J28?= To: Date: Wed, 22 Oct 2003 18:12:55 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0025_01C398C8.1D79F980" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Megaco] about Stream ID Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0025_01C398C8.1D79F980 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0026_01C398C8.1D7B8020" ------=_NextPart_001_0026_01C398C8.1D7B8020 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkuDQoNCkknbSBEb25nLUlsIFlvb24gaW4gS1QuDQoNCiANCg0KSSBoYXZlIGEgcXVlc3Rpb24g YWJvdXQgc3RyZWFtIGRlc2NyaXB0b3Igb2YgTUVHQUNPIHByb3RvY29sLiANCg0KIA0KDQpJbiA3 LjEuNCBNZWRpYSBkZXNjcmlwdG9yIG9mIEguMjQ4LjEsIHRoZXJlIGlzIGEgbGFzdCBzZW50ZW5j ZSBhcyANCg0KIiBBcyBhIGNvbnZlbmllbmNlLCBMb2NhbENvbnRyb2wsIExvY2FsLCBvciBSZW1v dGUgZGVzY3JpcHRvcnMgbWF5IGJlIGluY2x1ZGVkIGluIHRoZSBNZWRpYSBkZXNjcmlwdG9yIHdp dGhvdXQgYW4gZW5jbG9zaW5nIFN0cmVhbSBkZXNjcmlwdG9yLiBJbiB0aGlzIGNhc2UsIHRoZSBT dHJlYW1JRCBpcyBhc3N1bWVkIHRvIGJlIDEuIg0KDQogDQoNCkkgdGhpbmsgdGhhdCB0aG9zZSBz ZW50ZW5zZSB3aWxsIG5vdCBhcHBseSB0byBtZWdhY28gQ29tbWFuZCBSZXBseSBtZXNzYWdlIGJ1 dCBDb21tYW5kIFJlcXVlc3QgbWVzc2FnZS4NCg0KSSBtZWFuLCBmb3IgZXhhbXBsZSwgaWYgTUdD IHNlbmQgQWRkIFJlcXVlc3QgbWVzc2FnZSB3aXRoIFN0cmVhbUlEPTEgdGhlbiBNRyBtdXN0IHJl c3BvbnNlIEFkZCBSZXBseSBtZXNzYWdlIHdpdGggc2FtZSBTdHJlYW1JRD0xLCBhbmQgaWYgTUdD IHNlbmQgQWRkIFJlcXVlc3QgbWVzc2FnZSAgd2l0aG91dCBTdHJlYW1JRCB0aGVuIE1HIG11c3Qg cmVzcG9uc2UgQWRkIFJlcGx5IHdpdGhvdXQgU3RyZWFtSUQuDQoNCiANCg0KSW4gY29uY2x1c2lv biwgbGFzdCBzZW50ZW5zZSBpbiA3LjEuNCAsIEkgdGhpbmssICB5b3UgbWVhbiB0aGF0ICwgYXMg YSBjb252ZW5pZW5jZSwgTUdDIGNhbiBvbWl0IFN0cmVhbSBkZXNjcmlwdG9yIHdoZW4gdGhlIHN0 cmVhbUlEPTEsIGFuZCB0aGVuIE1HIGhhdmUgdG8gYXNzdW1lIHRoYXQgc3RyZWFtSUQ9MS4NCg0K IA0KDQpJIGFtIGNvbmNlcm5lZCB0aGF0IG15IGFuYWx5c2UgaXMgcmlnaHQuIA0KDQpJJ20gd2Fp dGluZyB5b3VyIHJlc3BvbnNlLg0KDQogDQoNClJlZ2FyZHMuDQo= ------=_NextPart_001_0026_01C398C8.1D7B8020 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI4MDAuMTI2NCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4N CjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbD4NCjxQIGNsYXNz PU1zb05vcm1hbCANCnN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0OyBXT1JELUJSRUFLOiBrZWVw LWFsbDsgVEVYVC1BTElHTjogbGVmdDsgbXNvLWxheW91dC1ncmlkLWFsaWduOiBub25lIiANCmFs aWduPWxlZnQ+PFNQQU4gbGFuZz1FTi1VUyANCnN0eWxlPSJGT05ULUZBTUlMWTog6rW066a8OyBt c28taGFuc2ktZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYmlkaS1mb250LWZh bWlseTog6rW066a8OyBtc28tZm9udC1rZXJuaW5nOiAwcHQiPjxGT05UIA0Kc2l6ZT0yPkhpLjw/ eG1sOm5hbWVzcGFjZSBwcmVmaXggPSBvIG5zID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNv bTpvZmZpY2U6b2ZmaWNlIiAvPjxvOnA+PC9vOnA+PC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFz cz1Nc29Ob3JtYWwgDQpzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdDsgV09SRC1CUkVBSzoga2Vl cC1hbGw7IFRFWFQtQUxJR046IGxlZnQ7IG1zby1sYXlvdXQtZ3JpZC1hbGlnbjogbm9uZSIgDQph bGlnbj1sZWZ0PjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1GQU1JTFk6IOq1tOumvDsg bXNvLWhhbnNpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWJpZGktZm9udC1m YW1pbHk6IOq1tOumvDsgbXNvLWZvbnQta2VybmluZzogMHB0Ij48Rk9OVCANCnNpemU9Mj5JJ20g RG9uZy1JbCBZb29uIGluIEtULjxvOnA+PC9vOnA+PC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFz cz1Nc29Ob3JtYWwgDQpzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdDsgV09SRC1CUkVBSzoga2Vl cC1hbGw7IFRFWFQtQUxJR046IGxlZnQ7IG1zby1sYXlvdXQtZ3JpZC1hbGlnbjogbm9uZSIgDQph bGlnbj1sZWZ0PjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1GQU1JTFk6IOq1tOumvDsg bXNvLWhhbnNpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWJpZGktZm9udC1m YW1pbHk6IOq1tOumvDsgbXNvLWZvbnQta2VybmluZzogMHB0Ij48bzpwPjxGT05UIA0Kc2l6ZT0y PiZuYnNwOzwvRk9OVD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIA0Kc3R5 bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQ7IFdPUkQtQlJFQUs6IGtlZXAtYWxsOyBURVhULUFMSUdO OiBsZWZ0OyBtc28tbGF5b3V0LWdyaWQtYWxpZ246IG5vbmUiIA0KYWxpZ249bGVmdD48U1BBTiBs YW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiDqtbTrprw7IG1zby1oYW5zaS1mb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiDqtbTrprw7IG1z by1mb250LWtlcm5pbmc6IDBwdCI+PEZPTlQgDQpzaXplPTI+SSBoYXZlIGEgcXVlc3Rpb24gYWJv dXQgc3RyZWFtIGRlc2NyaXB0b3Igb2YgTUVHQUNPIHByb3RvY29sLiANCjxvOnA+PC9vOnA+PC9G T05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgDQpzdHlsZT0iTUFSR0lOOiAwY20g MGNtIDBwdDsgV09SRC1CUkVBSzoga2VlcC1hbGw7IFRFWFQtQUxJR046IGxlZnQ7IG1zby1sYXlv dXQtZ3JpZC1hbGlnbjogbm9uZSIgDQphbGlnbj1sZWZ0PjxTUEFOIGxhbmc9RU4tVVMgDQpzdHls ZT0iRk9OVC1GQU1JTFk6IOq1tOumvDsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJzsgbXNvLWJpZGktZm9udC1mYW1pbHk6IOq1tOumvDsgbXNvLWZvbnQta2VybmluZzog MHB0Ij48bzpwPjxGT05UIA0Kc2l6ZT0yPiZuYnNwOzwvRk9OVD48L286cD48L1NQQU4+PC9QPg0K PFAgY2xhc3M9TXNvTm9ybWFsIA0Kc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQ7IFdPUkQtQlJF QUs6IGtlZXAtYWxsOyBURVhULUFMSUdOOiBsZWZ0OyBtc28tbGF5b3V0LWdyaWQtYWxpZ246IG5v bmUiIA0KYWxpZ249bGVmdD48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiDq tbTrprw7IG1zby1oYW5zaS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1iaWRp LWZvbnQtZmFtaWx5OiDqtbTrprw7IG1zby1mb250LWtlcm5pbmc6IDBwdCI+PEZPTlQgDQpzaXpl PTI+SW4gNy4xLjQgTWVkaWEgZGVzY3JpcHRvciBvZiBILjI0OC4xLCB0aGVyZSBpcyBhIGxhc3Qg c2VudGVuY2UgYXMgDQo8bzpwPjwvbzpwPjwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNv Tm9ybWFsIA0Kc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQ7IFdPUkQtQlJFQUs6IGtlZXAtYWxs OyBURVhULUFMSUdOOiBsZWZ0OyBtc28tbGF5b3V0LWdyaWQtYWxpZ246IG5vbmUiIA0KYWxpZ249 bGVmdD48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiDqtbTrprw7IG1zby1o YW5zaS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1iaWRpLWZvbnQtZmFtaWx5 OiDqtbTrprw7IG1zby1mb250LWtlcm5pbmc6IDBwdCI+PEZPTlQgDQpzaXplPTI+IiBBcyBhIGNv bnZlbmllbmNlLCBMb2NhbENvbnRyb2wsIExvY2FsLCBvciBSZW1vdGUgZGVzY3JpcHRvcnMgbWF5 IGJlIA0KaW5jbHVkZWQgaW4gdGhlIE1lZGlhIGRlc2NyaXB0b3Igd2l0aG91dCBhbiBlbmNsb3Np bmcgU3RyZWFtIGRlc2NyaXB0b3IuIEluIHRoaXMgDQpjYXNlLCB0aGUgU3RyZWFtSUQgaXMgYXNz dW1lZCB0byBiZSAxLiI8bzpwPjwvbzpwPjwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNv Tm9ybWFsIA0Kc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQ7IFdPUkQtQlJFQUs6IGtlZXAtYWxs OyBURVhULUFMSUdOOiBsZWZ0OyBtc28tbGF5b3V0LWdyaWQtYWxpZ246IG5vbmUiIA0KYWxpZ249 bGVmdD48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiDqtbTrprw7IG1zby1o YW5zaS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1iaWRpLWZvbnQtZmFtaWx5 OiDqtbTrprw7IG1zby1mb250LWtlcm5pbmc6IDBwdCI+PG86cD48Rk9OVCANCnNpemU9Mj4mbmJz cDs8L0ZPTlQ+PC9vOnA+PC9TUEFOPjwvUD4NCjxQIGNsYXNzPU1zb05vcm1hbCANCnN0eWxlPSJN QVJHSU46IDBjbSAwY20gMHB0OyBXT1JELUJSRUFLOiBrZWVwLWFsbDsgVEVYVC1BTElHTjogbGVm dDsgbXNvLWxheW91dC1ncmlkLWFsaWduOiBub25lIiANCmFsaWduPWxlZnQ+PFNQQU4gbGFuZz1F Ti1VUyANCnN0eWxlPSJGT05ULUZBTUlMWTog6rW066a8OyBtc28taGFuc2ktZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYmlkaS1mb250LWZhbWlseTog6rW066a8OyBtc28tZm9u dC1rZXJuaW5nOiAwcHQiPjxGT05UIA0Kc2l6ZT0yPkkgdGhpbmsgdGhhdCB0aG9zZSBzZW50ZW5z ZSB3aWxsIG5vdCBhcHBseSB0byBtZWdhY28gQ29tbWFuZCBSZXBseSANCm1lc3NhZ2UgYnV0IENv bW1hbmQgUmVxdWVzdCBtZXNzYWdlLjxvOnA+PC9vOnA+PC9GT05UPjwvU1BBTj48L1A+DQo8UCBj bGFzcz1Nc29Ob3JtYWwgDQpzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdDsgV09SRC1CUkVBSzog a2VlcC1hbGw7IFRFWFQtQUxJR046IGxlZnQ7IG1zby1sYXlvdXQtZ3JpZC1hbGlnbjogbm9uZSIg DQphbGlnbj1sZWZ0PjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1GQU1JTFk6IOq1tOum vDsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWJpZGktZm9u dC1mYW1pbHk6IOq1tOumvDsgbXNvLWZvbnQta2VybmluZzogMHB0Ij48Rk9OVCANCnNpemU9Mj5J IG1lYW4sIGZvciBleGFtcGxlLCBpZiBNR0Mgc2VuZCBBZGQgUmVxdWVzdCBtZXNzYWdlIHdpdGgg U3RyZWFtSUQ9MSB0aGVuIA0KTUcgbXVzdCByZXNwb25zZSBBZGQgUmVwbHkgbWVzc2FnZSB3aXRo IHNhbWUgU3RyZWFtSUQ9MSwgYW5kIGlmIE1HQyBzZW5kIEFkZCANClJlcXVlc3QgbWVzc2FnZTxT UEFOIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7IDwvU1BBTj53aXRob3V0IFN0cmVh bUlEIA0KdGhlbiBNRyBtdXN0IHJlc3BvbnNlIEFkZCBSZXBseSB3aXRob3V0IFN0cmVhbUlELjxv OnA+PC9vOnA+PC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1Nc29Ob3JtYWwgDQpzdHlsZT0i TUFSR0lOOiAwY20gMGNtIDBwdDsgV09SRC1CUkVBSzoga2VlcC1hbGw7IFRFWFQtQUxJR046IGxl ZnQ7IG1zby1sYXlvdXQtZ3JpZC1hbGlnbjogbm9uZSIgDQphbGlnbj1sZWZ0PjxTUEFOIGxhbmc9 RU4tVVMgDQpzdHlsZT0iRk9OVC1GQU1JTFk6IOq1tOumvDsgbXNvLWhhbnNpLWZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWJpZGktZm9udC1mYW1pbHk6IOq1tOumvDsgbXNvLWZv bnQta2VybmluZzogMHB0Ij48bzpwPjxGT05UIA0Kc2l6ZT0yPiZuYnNwOzwvRk9OVD48L286cD48 L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIA0Kc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAw cHQ7IFdPUkQtQlJFQUs6IGtlZXAtYWxsOyBURVhULUFMSUdOOiBsZWZ0OyBtc28tbGF5b3V0LWdy aWQtYWxpZ246IG5vbmUiIA0KYWxpZ249bGVmdD48U1BBTiBsYW5nPUVOLVVTIA0Kc3R5bGU9IkZP TlQtRkFNSUxZOiDqtbTrprw7IG1zby1oYW5zaS1mb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h bic7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiDqtbTrprw7IG1zby1mb250LWtlcm5pbmc6IDBwdCI+ PEZPTlQgDQpzaXplPTI+SW4gY29uY2x1c2lvbiwgbGFzdCBzZW50ZW5zZSBpbiA3LjEuNCAsIEkg dGhpbmssPFNQQU4gDQpzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyA8L1NQQU4+eW91 IG1lYW4gdGhhdCAsIGFzIGEgY29udmVuaWVuY2UsIE1HQyANCmNhbiBvbWl0IFN0cmVhbSBkZXNj cmlwdG9yIHdoZW4gdGhlIHN0cmVhbUlEPTEsIGFuZCB0aGVuIE1HIGhhdmUgdG8gYXNzdW1lIHRo YXQgDQpzdHJlYW1JRD0xLjxvOnA+PC9vOnA+PC9GT05UPjwvU1BBTj48L1A+DQo8UCBjbGFzcz1N c29Ob3JtYWwgDQpzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdDsgV09SRC1CUkVBSzoga2VlcC1h bGw7IFRFWFQtQUxJR046IGxlZnQ7IG1zby1sYXlvdXQtZ3JpZC1hbGlnbjogbm9uZSIgDQphbGln bj1sZWZ0PjxTUEFOIGxhbmc9RU4tVVMgDQpzdHlsZT0iRk9OVC1GQU1JTFk6IOq1tOumvDsgbXNv LWhhbnNpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWJpZGktZm9udC1mYW1p bHk6IOq1tOumvDsgbXNvLWZvbnQta2VybmluZzogMHB0Ij48bzpwPjxGT05UIA0Kc2l6ZT0yPiZu YnNwOzwvRk9OVD48L286cD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIA0Kc3R5bGU9 Ik1BUkdJTjogMGNtIDBjbSAwcHQ7IFdPUkQtQlJFQUs6IGtlZXAtYWxsOyBURVhULUFMSUdOOiBs ZWZ0OyBtc28tbGF5b3V0LWdyaWQtYWxpZ246IG5vbmUiIA0KYWxpZ249bGVmdD48U1BBTiBsYW5n PUVOLVVTIA0Kc3R5bGU9IkZPTlQtRkFNSUxZOiDqtbTrprw7IG1zby1oYW5zaS1mb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiDqtbTrprw7IG1zby1m b250LWtlcm5pbmc6IDBwdCI+PEZPTlQgDQpzaXplPTI+SSBhbSBjb25jZXJuZWQgdGhhdCBteSBh bmFseXNlIGlzIHJpZ2h0LiA8bzpwPjwvbzpwPjwvRk9OVD48L1NQQU4+PC9QPg0KPFAgY2xhc3M9 TXNvTm9ybWFsIA0Kc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQ7IFdPUkQtQlJFQUs6IGtlZXAt YWxsOyBURVhULUFMSUdOOiBsZWZ0OyBtc28tbGF5b3V0LWdyaWQtYWxpZ246IG5vbmUiIA0KYWxp Z249bGVmdD48U1BBTiANCnN0eWxlPSJGT05ULUZBTUlMWTog6rW066a8OyBtc28taGFuc2ktZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYmlkaS1mb250LWZhbWlseTog6rW066a8 OyBtc28tZm9udC1rZXJuaW5nOiAwcHQ7IG1zby1hbnNpLWxhbmd1YWdlOiBLTyI+PEZPTlQgDQpz aXplPTI+SSdtIHdhaXRpbmcgeW91ciByZXNwb25zZS48bzpwPjwvbzpwPjwvRk9OVD48L1NQQU4+ PC9QPg0KPFAgY2xhc3M9TXNvTm9ybWFsIA0Kc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSAwcHQ7IFdP UkQtQlJFQUs6IGtlZXAtYWxsOyBURVhULUFMSUdOOiBsZWZ0OyBtc28tbGF5b3V0LWdyaWQtYWxp Z246IG5vbmUiIA0KYWxpZ249bGVmdD48U1BBTiANCnN0eWxlPSJGT05ULUZBTUlMWTog6rW066a8 OyBtc28taGFuc2ktZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tYmlkaS1mb250 LWZhbWlseTog6rW066a8OyBtc28tZm9udC1rZXJuaW5nOiAwcHQ7IG1zby1hbnNpLWxhbmd1YWdl OiBLTyI+PG86cD48Rk9OVCANCnNpemU9Mj4mbmJzcDs8L0ZPTlQ+PC9vOnA+PC9TUEFOPjwvUD4N CjxQIGNsYXNzPU1zb05vcm1hbCANCnN0eWxlPSJNQVJHSU46IDBjbSAwY20gMHB0OyBXT1JELUJS RUFLOiBrZWVwLWFsbDsgVEVYVC1BTElHTjogbGVmdDsgbXNvLWxheW91dC1ncmlkLWFsaWduOiBu b25lIiANCmFsaWduPWxlZnQ+PFNQQU4gDQpzdHlsZT0iRk9OVC1GQU1JTFk6IOq1tOumvDsgbXNv LWhhbnNpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWJpZGktZm9udC1mYW1p bHk6IOq1tOumvDsgbXNvLWZvbnQta2VybmluZzogMHB0OyBtc28tYW5zaS1sYW5ndWFnZTogS08i PjxGT05UIA0Kc2l6ZT0yPlJlZ2FyZHMuPG86cD48L286cD48L0ZPTlQ+PC9TUEFOPjwvUD48L0ZP TlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_001_0026_01C398C8.1D7B8020-- ------=_NextPart_000_0025_01C398C8.1D79F980 Content-Type: text/x-vcard; name="=?utf-8?B?7Jyk64+Z7J28LnZjZg==?=" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="=?utf-8?B?7Jyk64+Z7J28LnZjZg==?=" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:;=C0=B1=B5=BF=C0=CF FN:=C0=B1=B5=BF=C0=CF ORG:042-870-8345 TITLE:=C5=EB=BD=C5=B8=C1=BF=AC=B1=B8=BC=D2 TEL;CELL;VOICE:016-451-2385 TEL;WORK;FAX:KT ADR;WORK:;042-870-8389 LABEL;WORK:042-870-8389 EMAIL;PREF;INTERNET:diyoon@kt.co.kr REV:20031022T091255Z END:VCARD ------=_NextPart_000_0025_01C398C8.1D79F980-- _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Oct 23 02:30:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04402 for ; Thu, 23 Oct 2003 02:30:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACYyv-0002vm-MU; Thu, 23 Oct 2003 02:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACYy6-0002mO-N7 for megaco@optimus.ietf.org; Thu, 23 Oct 2003 02:29:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04355 for ; Thu, 23 Oct 2003 02:29:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACYy2-00020C-00 for megaco@ietf.org; Thu, 23 Oct 2003 02:29:06 -0400 Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1ACYxw-000202-00 for megaco@ietf.org; Thu, 23 Oct 2003 02:29:06 -0400 Received: from z14593 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HN700IRS5W5JF@mta0.huawei.com> for megaco@ietf.org; Thu, 23 Oct 2003 14:26:30 +0800 (CST) Date: Thu, 23 Oct 2003 14:27:53 +0800 From: Zhao Bo To: Kevin Boyle Cc: megaco@ietf.org Message-id: <001901c3992e$caa0ff80$f8486e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 X-Mailer: Microsoft Outlook Express 5.50.4922.1500 Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [Megaco] Another Question About Caller ID Package Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hi Kevin: In some countries the Caller ID is sent to user by DTMF, with the message format like: ...... which is quite different from the FSK SDMF/MDMF format. The caller id package, andisp, define the data block as SDMF/MDMF format, do you think it's also suitable for DTMF caller id case? Thanks very much and best regard. Zhao Bo ***************************************************************** This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ***************************************************************** _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Oct 23 02:30:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04418 for ; Thu, 23 Oct 2003 02:30:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACYz5-0002yM-K5 for megaco-archive@odin.ietf.org; Thu, 23 Oct 2003 02:30:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N6UBQb011404 for megaco-archive@odin.ietf.org; Thu, 23 Oct 2003 02:30:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACYz3-0002xr-NN for megaco-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 02:30:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04371 for ; Thu, 23 Oct 2003 02:29:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACYyz-00028u-00 for megaco-web-archive@ietf.org; Thu, 23 Oct 2003 02:30:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACYyz-00028p-00 for megaco-web-archive@ietf.org; Thu, 23 Oct 2003 02:30:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACYyv-0002vm-MU; Thu, 23 Oct 2003 02:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACYy6-0002mO-N7 for megaco@optimus.ietf.org; Thu, 23 Oct 2003 02:29:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04355 for ; Thu, 23 Oct 2003 02:29:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACYy2-00020C-00 for megaco@ietf.org; Thu, 23 Oct 2003 02:29:06 -0400 Received: from mta0.huawei.com ([61.144.161.41] helo=huawei.com) by ietf-mx with esmtp (Exim 4.12) id 1ACYxw-000202-00 for megaco@ietf.org; Thu, 23 Oct 2003 02:29:06 -0400 Received: from z14593 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HN700IRS5W5JF@mta0.huawei.com> for megaco@ietf.org; Thu, 23 Oct 2003 14:26:30 +0800 (CST) Date: Thu, 23 Oct 2003 14:27:53 +0800 From: Zhao Bo To: Kevin Boyle Cc: megaco@ietf.org Message-id: <001901c3992e$caa0ff80$f8486e0a@HUAWEI.COM> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 X-Mailer: Microsoft Outlook Express 5.50.4922.1500 Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [Megaco] Another Question About Caller ID Package Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi Kevin: In some countries the Caller ID is sent to user by DTMF, with the message format like: ...... which is quite different from the FSK SDMF/MDMF format. The caller id package, andisp, define the data block as SDMF/MDMF format, do you think it's also suitable for DTMF caller id case? Thanks very much and best regard. Zhao Bo ***************************************************************** This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ***************************************************************** _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Oct 23 03:24:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06214 for ; Thu, 23 Oct 2003 03:24:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZpB-00029x-IV; Thu, 23 Oct 2003 03:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZoc-00021v-JS for megaco@optimus.ietf.org; Thu, 23 Oct 2003 03:23:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06181 for ; Thu, 23 Oct 2003 03:23:17 -0400 (EDT) From: gsachin@hss.hns.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACZoa-0002m6-00 for megaco@ietf.org; Thu, 23 Oct 2003 03:23:24 -0400 Received: from [202.54.26.202] (helo=hindon.hss.co.in) by ietf-mx with esmtp (Exim 4.12) id 1ACZoZ-0002lz-00 for megaco@ietf.org; Thu, 23 Oct 2003 03:23:23 -0400 Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h9N7ILv18156 for ; Thu, 23 Oct 2003 12:48:22 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id h9N7NZO22036 for ; Thu, 23 Oct 2003 12:53:35 +0530 (IST) To: megaco@ietf.org Date: Thu, 23 Oct 2003 12:47:17 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 23/10/2003 12:45:19 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [Megaco] Read-only property Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi, If a property is defined as read-only property ( either in LocalControl or Termination State Descriptor) what are the operations can MGC do on these values. 1> MGC will definalely be able to Audit them but, 2> Can MGC specify these values as CHOOSE in the command request? Is there any other operation from MGC on such property values. Pls Respond. Regards Sachin Gupta "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Oct 23 03:24:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06231 for ; Thu, 23 Oct 2003 03:24:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZpD-0002Bm-Pp for megaco-archive@odin.ietf.org; Thu, 23 Oct 2003 03:24:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N7O3b2008408 for megaco-archive@odin.ietf.org; Thu, 23 Oct 2003 03:24:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZpD-0002BX-Fb for megaco-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 03:24:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06190 for ; Thu, 23 Oct 2003 03:23:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACZpB-0002mP-00 for megaco-web-archive@ietf.org; Thu, 23 Oct 2003 03:24:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACZpA-0002mM-00 for megaco-web-archive@ietf.org; Thu, 23 Oct 2003 03:24:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZpB-00029x-IV; Thu, 23 Oct 2003 03:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACZoc-00021v-JS for megaco@optimus.ietf.org; Thu, 23 Oct 2003 03:23:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06181 for ; Thu, 23 Oct 2003 03:23:17 -0400 (EDT) From: gsachin@hss.hns.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACZoa-0002m6-00 for megaco@ietf.org; Thu, 23 Oct 2003 03:23:24 -0400 Received: from [202.54.26.202] (helo=hindon.hss.co.in) by ietf-mx with esmtp (Exim 4.12) id 1ACZoZ-0002lz-00 for megaco@ietf.org; Thu, 23 Oct 2003 03:23:23 -0400 Received: from ultra.hss.co.in (ultra [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id h9N7ILv18156 for ; Thu, 23 Oct 2003 12:48:22 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id h9N7NZO22036 for ; Thu, 23 Oct 2003 12:53:35 +0530 (IST) To: megaco@ietf.org Date: Thu, 23 Oct 2003 12:47:17 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 23/10/2003 12:45:19 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: [Megaco] Read-only property Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Hi, If a property is defined as read-only property ( either in LocalControl or Termination State Descriptor) what are the operations can MGC do on these values. 1> MGC will definalely be able to Audit them but, 2> Can MGC specify these values as CHOOSE in the command request? Is there any other operation from MGC on such property values. Pls Respond. Regards Sachin Gupta "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Oct 23 11:01:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27701 for ; Thu, 23 Oct 2003 11:01:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACgxR-0000sv-Ro; Thu, 23 Oct 2003 11:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACgwd-0000mN-VZ for megaco@optimus.ietf.org; Thu, 23 Oct 2003 11:00:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27620 for ; Thu, 23 Oct 2003 10:59:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACgwb-0001qx-00 for megaco@ietf.org; Thu, 23 Oct 2003 11:00:09 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1ACgwa-0001q5-00 for megaco@ietf.org; Thu, 23 Oct 2003 11:00:08 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9NExUH24449 for ; Thu, 23 Oct 2003 10:59:30 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Oct 2003 10:59:30 -0400 Message-ID: From: "Kevin Boyle" To: Zhao Bo Cc: megaco@ietf.org Date: Thu, 23 Oct 2003 10:59:30 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [Megaco] RE: Another Question About Caller ID Package Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , It seems to me that you have two possibilities: Decode the FSK in the andisp signal and translate that to DTMF digits. Use the DTMF Generation package to produce the digits. My gut feeling is that you should do the latter. Kevin -----Original Message----- From: Zhao Bo [mailto:zbo@huawei.com] Sent: Thursday, October 23, 2003 2:28 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH] Cc: megaco@ietf.org Subject: Another Question About Caller ID Package Hi Kevin: In some countries the Caller ID is sent to user by DTMF, with the message format like: ...... which is quite different from the FSK SDMF/MDMF format. The caller id package, andisp, define the data block as SDMF/MDMF format, do you think it's also suitable for DTMF caller id case? Thanks very much and best regard. Zhao Bo ***************************************************************** This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ***************************************************************** _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Oct 23 11:01:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27720 for ; Thu, 23 Oct 2003 11:01:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACgxY-0000w9-5U for megaco-archive@odin.ietf.org; Thu, 23 Oct 2003 11:01:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NF189c003600 for megaco-archive@odin.ietf.org; Thu, 23 Oct 2003 11:01:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACgxY-0000vz-2G for megaco-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 11:01:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27655 for ; Thu, 23 Oct 2003 11:00:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACgxV-0001rP-00 for megaco-web-archive@ietf.org; Thu, 23 Oct 2003 11:01:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACgxV-0001rM-00 for megaco-web-archive@ietf.org; Thu, 23 Oct 2003 11:01:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACgxR-0000sv-Ro; Thu, 23 Oct 2003 11:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACgwd-0000mN-VZ for megaco@optimus.ietf.org; Thu, 23 Oct 2003 11:00:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27620 for ; Thu, 23 Oct 2003 10:59:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACgwb-0001qx-00 for megaco@ietf.org; Thu, 23 Oct 2003 11:00:09 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1ACgwa-0001q5-00 for megaco@ietf.org; Thu, 23 Oct 2003 11:00:08 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9NExUH24449 for ; Thu, 23 Oct 2003 10:59:30 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Oct 2003 10:59:30 -0400 Message-ID: From: "Kevin Boyle" To: Zhao Bo Cc: megaco@ietf.org Date: Thu, 23 Oct 2003 10:59:30 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [Megaco] RE: Another Question About Caller ID Package Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , It seems to me that you have two possibilities: Decode the FSK in the andisp signal and translate that to DTMF digits. Use the DTMF Generation package to produce the digits. My gut feeling is that you should do the latter. Kevin -----Original Message----- From: Zhao Bo [mailto:zbo@huawei.com] Sent: Thursday, October 23, 2003 2:28 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH] Cc: megaco@ietf.org Subject: Another Question About Caller ID Package Hi Kevin: In some countries the Caller ID is sent to user by DTMF, with the message format like: ...... which is quite different from the FSK SDMF/MDMF format. The caller id package, andisp, define the data block as SDMF/MDMF format, do you think it's also suitable for DTMF caller id case? Thanks very much and best regard. Zhao Bo ***************************************************************** This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ***************************************************************** _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Oct 23 11:56:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02062 for ; Thu, 23 Oct 2003 11:56:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AChof-0003mI-6Z; Thu, 23 Oct 2003 11:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AChoS-0003ku-8t for megaco@optimus.ietf.org; Thu, 23 Oct 2003 11:55:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02034 for ; Thu, 23 Oct 2003 11:55:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AChoR-0003Dz-00 for megaco@ietf.org; Thu, 23 Oct 2003 11:55:47 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1AChoQ-0003Dd-00 for megaco@ietf.org; Thu, 23 Oct 2003 11:55:46 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9NFtFa00685 for ; Thu, 23 Oct 2003 11:55:15 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Oct 2003 11:55:15 -0400 Message-ID: From: "Kevin Boyle" To: gsachin@hss.hns.com, megaco@ietf.org Subject: RE: [Megaco] Read-only property Date: Thu, 23 Oct 2003 11:55:13 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Read-only means exactly that -- read only. The MGC may not alter the value through a Modify command, whether using CHOOSE or any other means. Such a command should be replied with error 534. Kevin -----Original Message----- From: gsachin@hss.hns.com [mailto:gsachin@hss.hns.com] Sent: Thursday, October 23, 2003 3:17 AM To: megaco@ietf.org Subject: [Megaco] Read-only property Hi, If a property is defined as read-only property ( either in LocalControl or Termination State Descriptor) what are the operations can MGC do on these values. 1> MGC will definalely be able to Audit them but, 2> Can MGC specify these values as CHOOSE in the command request? Is there any other operation from MGC on such property values. Pls Respond. Regards Sachin Gupta "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Oct 23 11:56:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02078 for ; Thu, 23 Oct 2003 11:56:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AChom-0003oO-9H for megaco-archive@odin.ietf.org; Thu, 23 Oct 2003 11:56:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9NFu8Gw014648 for megaco-archive@odin.ietf.org; Thu, 23 Oct 2003 11:56:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AChom-0003o3-3F for megaco-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 11:56:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02042 for ; Thu, 23 Oct 2003 11:55:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AChok-0003EC-00 for megaco-web-archive@ietf.org; Thu, 23 Oct 2003 11:56:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AChok-0003E9-00 for megaco-web-archive@ietf.org; Thu, 23 Oct 2003 11:56:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AChof-0003mI-6Z; Thu, 23 Oct 2003 11:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AChoS-0003ku-8t for megaco@optimus.ietf.org; Thu, 23 Oct 2003 11:55:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02034 for ; Thu, 23 Oct 2003 11:55:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AChoR-0003Dz-00 for megaco@ietf.org; Thu, 23 Oct 2003 11:55:47 -0400 Received: from zrtps06s.nortelnetworks.com ([47.140.48.50]) by ietf-mx with esmtp (Exim 4.12) id 1AChoQ-0003Dd-00 for megaco@ietf.org; Thu, 23 Oct 2003 11:55:46 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9NFtFa00685 for ; Thu, 23 Oct 2003 11:55:15 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Oct 2003 11:55:15 -0400 Message-ID: From: "Kevin Boyle" To: gsachin@hss.hns.com, megaco@ietf.org Subject: RE: [Megaco] Read-only property Date: Thu, 23 Oct 2003 11:55:13 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Read-only means exactly that -- read only. The MGC may not alter the value through a Modify command, whether using CHOOSE or any other means. Such a command should be replied with error 534. Kevin -----Original Message----- From: gsachin@hss.hns.com [mailto:gsachin@hss.hns.com] Sent: Thursday, October 23, 2003 3:17 AM To: megaco@ietf.org Subject: [Megaco] Read-only property Hi, If a property is defined as read-only property ( either in LocalControl or Termination State Descriptor) what are the operations can MGC do on these values. 1> MGC will definalely be able to Audit them but, 2> Can MGC specify these values as CHOOSE in the command request? Is there any other operation from MGC on such property values. Pls Respond. Regards Sachin Gupta "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Oct 24 13:45:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19828 for ; Fri, 24 Oct 2003 13:45:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD5zj-0007Xb-IQ; Fri, 24 Oct 2003 13:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD5zN-0007NQ-HD for megaco@optimus.ietf.org; Fri, 24 Oct 2003 13:44:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19743 for ; Fri, 24 Oct 2003 13:44:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD5zL-0001YN-00 for megaco@ietf.org; Fri, 24 Oct 2003 13:44:39 -0400 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1AD5zK-0001XD-00 for megaco@ietf.org; Fri, 24 Oct 2003 13:44:38 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9OHi1p02247 for ; Fri, 24 Oct 2003 13:44:02 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Oct 2003 13:44:02 -0400 Message-ID: From: "Kevin Boyle" To: Zhao Bo Cc: megaco@ietf.org Subject: RE: [Megaco] RE: Another Question About Caller ID Package Date: Fri, 24 Oct 2003 13:43:59 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Caller ID between the first and second rings is a North American requirement. Other regions/locales have different requirements. If the MGC has to apply ringing and the DTMF for CallerID in such a way that the timing is impossible using the DG package, then certainly encoding the digits as FSK and utilizing the andisp package is a viable way of sending the callerID info to the MG. The caveat is that the MG will have to be able to decode the FSK to be able to generate the digits. Kevin -----Original Message----- From: Zhao Bo [mailto:zbo@huawei.com] Sent: Friday, October 24, 2003 1:00 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH] Cc: megaco@ietf.org Subject: Re: [Megaco] RE: Another Question About Caller ID Package If I do the latter, MGC will have to send both a DTMF siganl and a ringing signal. In most case caller id shall be between the 1st and the 2nd ringing, if MGC sends two signals, maybe the time requirement can't be assured? ----- Original Message ----- From: "Kevin Boyle" To: "Zhao Bo" Cc: Sent: Thursday, October 23, 2003 10:59 PM Subject: [Megaco] RE: Another Question About Caller ID Package > It seems to me that you have two possibilities: > > Decode the FSK in the andisp signal and translate that to DTMF digits. > Use the DTMF Generation package to produce the digits. > > My gut feeling is that you should do the latter. > > Kevin > > -----Original Message----- > From: Zhao Bo [mailto:zbo@huawei.com] > Sent: Thursday, October 23, 2003 2:28 AM > To: Boyle, Kevin [NCRTP:3Z40:EXCH] > Cc: megaco@ietf.org > Subject: Another Question About Caller ID Package > > > Hi Kevin: > In some countries the Caller ID is sent to user by DTMF, with the > message format like: > ...... > which is quite different from the FSK SDMF/MDMF format. > The caller id package, andisp, define the data block as SDMF/MDMF > format, do you think it's also suitable for DTMF caller id case? > Thanks very much and best regard. > > Zhao Bo > > ***************************************************************** > This e-mail and its attachments contain confidential information from > HUAWEI, which is intended only for the person or entity whose address > is listed above. Any use of the information contained herein in any > way (including, but not limited to, total or partial disclosure, > reproduction, or dissemination) by persons other than the intended > recipient(s) is prohibited. If you receive this e-mail in error, > please notify the sender by phone or email immediately and delete it! > ***************************************************************** > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri Oct 24 13:45:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19843 for ; Fri, 24 Oct 2003 13:45:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD5zs-0007ch-C7 for megaco-archive@odin.ietf.org; Fri, 24 Oct 2003 13:45:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OHjCDq029297 for megaco-archive@odin.ietf.org; Fri, 24 Oct 2003 13:45:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD5zs-0007cS-7q for megaco-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 13:45:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19787 for ; Fri, 24 Oct 2003 13:45:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD5zp-0001ZL-00 for megaco-web-archive@ietf.org; Fri, 24 Oct 2003 13:45:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AD5zp-0001ZH-00 for megaco-web-archive@ietf.org; Fri, 24 Oct 2003 13:45:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD5zj-0007Xb-IQ; Fri, 24 Oct 2003 13:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD5zN-0007NQ-HD for megaco@optimus.ietf.org; Fri, 24 Oct 2003 13:44:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19743 for ; Fri, 24 Oct 2003 13:44:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD5zL-0001YN-00 for megaco@ietf.org; Fri, 24 Oct 2003 13:44:39 -0400 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1AD5zK-0001XD-00 for megaco@ietf.org; Fri, 24 Oct 2003 13:44:38 -0400 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9OHi1p02247 for ; Fri, 24 Oct 2003 13:44:02 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Oct 2003 13:44:02 -0400 Message-ID: From: "Kevin Boyle" To: Zhao Bo Cc: megaco@ietf.org Subject: RE: [Megaco] RE: Another Question About Caller ID Package Date: Fri, 24 Oct 2003 13:43:59 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Caller ID between the first and second rings is a North American requirement. Other regions/locales have different requirements. If the MGC has to apply ringing and the DTMF for CallerID in such a way that the timing is impossible using the DG package, then certainly encoding the digits as FSK and utilizing the andisp package is a viable way of sending the callerID info to the MG. The caveat is that the MG will have to be able to decode the FSK to be able to generate the digits. Kevin -----Original Message----- From: Zhao Bo [mailto:zbo@huawei.com] Sent: Friday, October 24, 2003 1:00 AM To: Boyle, Kevin [NCRTP:3Z40:EXCH] Cc: megaco@ietf.org Subject: Re: [Megaco] RE: Another Question About Caller ID Package If I do the latter, MGC will have to send both a DTMF siganl and a ringing signal. In most case caller id shall be between the 1st and the 2nd ringing, if MGC sends two signals, maybe the time requirement can't be assured? ----- Original Message ----- From: "Kevin Boyle" To: "Zhao Bo" Cc: Sent: Thursday, October 23, 2003 10:59 PM Subject: [Megaco] RE: Another Question About Caller ID Package > It seems to me that you have two possibilities: > > Decode the FSK in the andisp signal and translate that to DTMF digits. > Use the DTMF Generation package to produce the digits. > > My gut feeling is that you should do the latter. > > Kevin > > -----Original Message----- > From: Zhao Bo [mailto:zbo@huawei.com] > Sent: Thursday, October 23, 2003 2:28 AM > To: Boyle, Kevin [NCRTP:3Z40:EXCH] > Cc: megaco@ietf.org > Subject: Another Question About Caller ID Package > > > Hi Kevin: > In some countries the Caller ID is sent to user by DTMF, with the > message format like: > ...... > which is quite different from the FSK SDMF/MDMF format. > The caller id package, andisp, define the data block as SDMF/MDMF > format, do you think it's also suitable for DTMF caller id case? > Thanks very much and best regard. > > Zhao Bo > > ***************************************************************** > This e-mail and its attachments contain confidential information from > HUAWEI, which is intended only for the person or entity whose address > is listed above. Any use of the information contained herein in any > way (including, but not limited to, total or partial disclosure, > reproduction, or dissemination) by persons other than the intended > recipient(s) is prohibited. If you receive this e-mail in error, > please notify the sender by phone or email immediately and delete it! > ***************************************************************** > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Oct 30 00:34:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26433 for ; Thu, 30 Oct 2003 00:34:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF5Ra-0002fR-6A; Thu, 30 Oct 2003 00:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF5Qi-0002b7-H3 for megaco@optimus.ietf.org; Thu, 30 Oct 2003 00:33:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26385 for ; Thu, 30 Oct 2003 00:32:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AF5Qf-0005Dr-00 for megaco@ietf.org; Thu, 30 Oct 2003 00:33:05 -0500 Received: from [203.197.168.150] (helo=mailscanout256k.tataelxsi.co.in) by ietf-mx with smtp (Exim 4.12) id 1AF5Qe-0005DN-00 for megaco@ietf.org; Thu, 30 Oct 2003 00:33:05 -0500 Received: FROM vscaninternal.tataelxsi.co.in BY mailscanout256k.tataelxsi.co.in ; Thu Oct 30 11:05:07 2003 +0500 Received: FROM bsh BY vscaninternal.tataelxsi.co.in ; Thu Oct 30 11:04:30 2003 +0500 From: "Shridhara B" To: Date: Thu, 30 Oct 2003 11:04:10 +0530 Message-ID: <004701c39ea7$72dae120$d528010a@telxsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Megaco] Query on correct package specifications. Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit All, Could any of you please clarify the followings? 1) Following package specifications are present both in H.248.25 specification and the draft-manyfolks-megaco-caspacakge-02. Word of caution present at the beginning of H.248.25 specification says that this is an un-edited version and will be replaced by the published version after editing. Given this, for the below packages which of these (H.248.25 OR draft-manyfolks-megaco-caspacakge-02) specifications should be followed? - Basic CAS package - Robbed bit signaling package - Operator service and emergency services package - Operator service extension package 2) Specification for Basic CAS Addressing Package is present only in H.248.25. Given the word of caution at the beginning of H.248.25 specification is it safe to follow this document for the Basic CAS Addressing Package ? If not, which specification should be followed for this package? Thanks in advance - Shridhara.B _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Oct 30 00:34:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26448 for ; Thu, 30 Oct 2003 00:34:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF5Rf-0002gS-LO for megaco-archive@odin.ietf.org; Thu, 30 Oct 2003 00:34:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9U5Y74F010312 for megaco-archive@odin.ietf.org; Thu, 30 Oct 2003 00:34:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF5Rf-0002gF-G5 for megaco-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 00:34:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26414 for ; Thu, 30 Oct 2003 00:33:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AF5Rc-0005Ed-00 for megaco-web-archive@ietf.org; Thu, 30 Oct 2003 00:34:04 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AF5Rc-0005EW-00 for megaco-web-archive@ietf.org; Thu, 30 Oct 2003 00:34:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF5Ra-0002fR-6A; Thu, 30 Oct 2003 00:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF5Qi-0002b7-H3 for megaco@optimus.ietf.org; Thu, 30 Oct 2003 00:33:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26385 for ; Thu, 30 Oct 2003 00:32:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AF5Qf-0005Dr-00 for megaco@ietf.org; Thu, 30 Oct 2003 00:33:05 -0500 Received: from [203.197.168.150] (helo=mailscanout256k.tataelxsi.co.in) by ietf-mx with smtp (Exim 4.12) id 1AF5Qe-0005DN-00 for megaco@ietf.org; Thu, 30 Oct 2003 00:33:05 -0500 Received: FROM vscaninternal.tataelxsi.co.in BY mailscanout256k.tataelxsi.co.in ; Thu Oct 30 11:05:07 2003 +0500 Received: FROM bsh BY vscaninternal.tataelxsi.co.in ; Thu Oct 30 11:04:30 2003 +0500 From: "Shridhara B" To: Date: Thu, 30 Oct 2003 11:04:10 +0530 Message-ID: <004701c39ea7$72dae120$d528010a@telxsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Megaco] Query on correct package specifications. Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit All, Could any of you please clarify the followings? 1) Following package specifications are present both in H.248.25 specification and the draft-manyfolks-megaco-caspacakge-02. Word of caution present at the beginning of H.248.25 specification says that this is an un-edited version and will be replaced by the published version after editing. Given this, for the below packages which of these (H.248.25 OR draft-manyfolks-megaco-caspacakge-02) specifications should be followed? - Basic CAS package - Robbed bit signaling package - Operator service and emergency services package - Operator service extension package 2) Specification for Basic CAS Addressing Package is present only in H.248.25. Given the word of caution at the beginning of H.248.25 specification is it safe to follow this document for the Basic CAS Addressing Package ? If not, which specification should be followed for this package? Thanks in advance - Shridhara.B _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Thu Oct 30 01:24:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27656 for ; Thu, 30 Oct 2003 01:24:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF6Dx-0000p6-An; Thu, 30 Oct 2003 01:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF6Dg-0000ny-JE for megaco@optimus.ietf.org; Thu, 30 Oct 2003 01:23:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27609 for ; Thu, 30 Oct 2003 01:23:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AF6Dd-0005mQ-00 for megaco@ietf.org; Thu, 30 Oct 2003 01:23:41 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AF6Dc-0005lv-00 for megaco@ietf.org; Thu, 30 Oct 2003 01:23:40 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9U6N5M12423; Thu, 30 Oct 2003 01:23:05 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VRTPDBNL; Thu, 30 Oct 2003 01:23:05 -0500 Received: from nortelnetworks.com (acart1f8.ca.nortel.com [47.129.129.150]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZW5N2PG; Thu, 30 Oct 2003 01:23:05 -0500 Message-ID: <3FA0AE48.7020002@nortelnetworks.com> Date: Thu, 30 Oct 2003 01:23:04 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Shridhara B CC: megaco@ietf.org Subject: Re: [Megaco] Query on correct package specifications. References: <004701c39ea7$72dae120$d528010a@telxsi.com> In-Reply-To: <004701c39ea7$72dae120$d528010a@telxsi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit You should follow H.248.25. The caution is standard -- what it means is that you should watch out for possible typos and let Christian Groves know about them. There will be no technical changes when the final version is published. Shridhara B wrote: > All, > > Could any of you please clarify the followings? > > 1) Following package specifications are present both in H.248.25 > specification and the draft-manyfolks-megaco-caspacakge-02. Word of caution > present at the beginning of H.248.25 specification says that this is an > un-edited version and will be replaced by the published version after > editing. Given this, for the below packages which of these (H.248.25 OR > draft-manyfolks-megaco-caspacakge-02) specifications should be followed? > > - Basic CAS package > - Robbed bit signaling package > - Operator service and emergency services package > - Operator service extension package > > 2) Specification for Basic CAS Addressing Package is present only in > H.248.25. Given the word of caution at the beginning of H.248.25 > specification is it safe to follow this document for the Basic CAS > Addressing Package ? If not, which specification should be followed for this > package? > > Thanks in advance > > - Shridhara.B > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Thu Oct 30 01:24:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27671 for ; Thu, 30 Oct 2003 01:24:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF6Dz-0000q8-Dc for megaco-archive@odin.ietf.org; Thu, 30 Oct 2003 01:24:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9U6O3dC003222 for megaco-archive@odin.ietf.org; Thu, 30 Oct 2003 01:24:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF6Dz-0000pl-9v for megaco-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 01:24:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27620 for ; Thu, 30 Oct 2003 01:23:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AF6Dw-0005mh-00 for megaco-web-archive@ietf.org; Thu, 30 Oct 2003 01:24:00 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AF6Dv-0005me-00 for megaco-web-archive@ietf.org; Thu, 30 Oct 2003 01:23:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF6Dx-0000p6-An; Thu, 30 Oct 2003 01:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF6Dg-0000ny-JE for megaco@optimus.ietf.org; Thu, 30 Oct 2003 01:23:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27609 for ; Thu, 30 Oct 2003 01:23:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AF6Dd-0005mQ-00 for megaco@ietf.org; Thu, 30 Oct 2003 01:23:41 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AF6Dc-0005lv-00 for megaco@ietf.org; Thu, 30 Oct 2003 01:23:40 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9U6N5M12423; Thu, 30 Oct 2003 01:23:05 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard309.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VRTPDBNL; Thu, 30 Oct 2003 01:23:05 -0500 Received: from nortelnetworks.com (acart1f8.ca.nortel.com [47.129.129.150]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id SZW5N2PG; Thu, 30 Oct 2003 01:23:05 -0500 Message-ID: <3FA0AE48.7020002@nortelnetworks.com> Date: Thu, 30 Oct 2003 01:23:04 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Shridhara B CC: megaco@ietf.org Subject: Re: [Megaco] Query on correct package specifications. References: <004701c39ea7$72dae120$d528010a@telxsi.com> In-Reply-To: <004701c39ea7$72dae120$d528010a@telxsi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit You should follow H.248.25. The caution is standard -- what it means is that you should watch out for possible typos and let Christian Groves know about them. There will be no technical changes when the final version is published. Shridhara B wrote: > All, > > Could any of you please clarify the followings? > > 1) Following package specifications are present both in H.248.25 > specification and the draft-manyfolks-megaco-caspacakge-02. Word of caution > present at the beginning of H.248.25 specification says that this is an > un-edited version and will be replaced by the published version after > editing. Given this, for the below packages which of these (H.248.25 OR > draft-manyfolks-megaco-caspacakge-02) specifications should be followed? > > - Basic CAS package > - Robbed bit signaling package > - Operator service and emergency services package > - Operator service extension package > > 2) Specification for Basic CAS Addressing Package is present only in > H.248.25. Given the word of caution at the beginning of H.248.25 > specification is it safe to follow this document for the Basic CAS > Addressing Package ? If not, which specification should be followed for this > package? > > Thanks in advance > > - Shridhara.B > > > _______________________________________________ > Megaco mailing list > Megaco@ietf.org > https://www1.ietf.org/mailman/listinfo/megaco > _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Oct 31 14:40:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15458 for ; Fri, 31 Oct 2003 14:40:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFf7s-0007aX-16; Fri, 31 Oct 2003 14:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFf73-0007Xs-SZ for megaco@optimus.ietf.org; Fri, 31 Oct 2003 14:39:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15397 for ; Fri, 31 Oct 2003 14:39:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFf71-0005vq-00 for Megaco@ietf.org; Fri, 31 Oct 2003 14:39:11 -0500 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AFf70-0005vA-00 for Megaco@ietf.org; Fri, 31 Oct 2003 14:39:10 -0500 Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h9VJcaL02036 for ; Fri, 31 Oct 2003 13:38:36 -0600 (CST) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id OAA07127; Fri, 31 Oct 2003 14:38:51 -0500 (EST) Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id OAA07123; Fri, 31 Oct 2003 14:38:51 -0500 (EST) Message-ID: <3FA2BAB1.3000606@bell-labs.com> Date: Fri, 31 Oct 2003 14:40:33 -0500 From: Troy Cauble User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Megaco@ietf.org Subject: Re: [Megaco] IG guide for H248V2 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit So where is the latest IG ??? Kevin Boyle wrote: > Consider yourself corrected. The IG contains any corrections identified for > any of the H.248 sub-series, including H.248.1 v2. > > Kevin > > -----Original Message----- > Hi > As far as the IG is concerned the most recent one is the May 2003 > which have corrections over and above the H248.1 V1 and not for the H248.1 > V2. > Correct me if I am wrong. > > Regards > Venkat _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri Oct 31 14:40:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15474 for ; Fri, 31 Oct 2003 14:40:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFf82-0007c9-Fe for megaco-archive@odin.ietf.org; Fri, 31 Oct 2003 14:40:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9VJeDGo029263 for megaco-archive@odin.ietf.org; Fri, 31 Oct 2003 14:40:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFf7z-0007bu-Jp for megaco-web-archive@optimus.ietf.org; Fri, 31 Oct 2003 14:40:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15444 for ; Fri, 31 Oct 2003 14:39:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFf7w-0005wb-00 for megaco-web-archive@ietf.org; Fri, 31 Oct 2003 14:40:08 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFf7w-0005wX-00 for megaco-web-archive@ietf.org; Fri, 31 Oct 2003 14:40:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFf7s-0007aX-16; Fri, 31 Oct 2003 14:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFf73-0007Xs-SZ for megaco@optimus.ietf.org; Fri, 31 Oct 2003 14:39:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15397 for ; Fri, 31 Oct 2003 14:39:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFf71-0005vq-00 for Megaco@ietf.org; Fri, 31 Oct 2003 14:39:11 -0500 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AFf70-0005vA-00 for Megaco@ietf.org; Fri, 31 Oct 2003 14:39:10 -0500 Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h9VJcaL02036 for ; Fri, 31 Oct 2003 13:38:36 -0600 (CST) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id OAA07127; Fri, 31 Oct 2003 14:38:51 -0500 (EST) Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id OAA07123; Fri, 31 Oct 2003 14:38:51 -0500 (EST) Message-ID: <3FA2BAB1.3000606@bell-labs.com> Date: Fri, 31 Oct 2003 14:40:33 -0500 From: Troy Cauble User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Megaco@ietf.org Subject: Re: [Megaco] IG guide for H248V2 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit So where is the latest IG ??? Kevin Boyle wrote: > Consider yourself corrected. The IG contains any corrections identified for > any of the H.248 sub-series, including H.248.1 v2. > > Kevin > > -----Original Message----- > Hi > As far as the IG is concerned the most recent one is the May 2003 > which have corrections over and above the H248.1 V1 and not for the H248.1 > V2. > Correct me if I am wrong. > > Regards > Venkat _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From megaco-admin@ietf.org Fri Oct 31 14:58:19 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16235 for ; Fri, 31 Oct 2003 14:58:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFfPF-0001RR-Dx; Fri, 31 Oct 2003 14:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFfOg-0001M1-Fi for megaco@optimus.ietf.org; Fri, 31 Oct 2003 14:57:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16170 for ; Fri, 31 Oct 2003 14:57:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFfOd-0006Di-00 for Megaco@ietf.org; Fri, 31 Oct 2003 14:57:23 -0500 Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AFfOc-0006DA-00 for Megaco@ietf.org; Fri, 31 Oct 2003 14:57:23 -0500 Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by ihemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h9VJteA28130 for ; Fri, 31 Oct 2003 13:56:09 -0600 (CST) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id OAA07241; Fri, 31 Oct 2003 14:55:57 -0500 (EST) Cc: Megaco@ietf.org Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id OAA07237; Fri, 31 Oct 2003 14:55:57 -0500 (EST) Message-ID: <3FA2BEB3.3070105@bell-labs.com> Date: Fri, 31 Oct 2003 14:57:39 -0500 From: Troy Cauble User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 Original-CC: Megaco@ietf.org Subject: Re: [Megaco] IG guide for H248V2 References: <3FA2BAB1.3000606@bell-labs.com> In-Reply-To: <3FA2BAB1.3000606@bell-labs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Troy Cauble wrote: > So where is the latest IG ??? > Never mind. I found it at http://www.itu.int/itudoc/itu-t/com16/implgd/h248ig.html -troy _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco From exim@www1.ietf.org Fri Oct 31 14:58:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16250 for ; Fri, 31 Oct 2003 14:58:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFfPH-0001T1-BP for megaco-archive@odin.ietf.org; Fri, 31 Oct 2003 14:58:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9VJw3fx005633 for megaco-archive@odin.ietf.org; Fri, 31 Oct 2003 14:58:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFfPH-0001Sl-6a for megaco-web-archive@optimus.ietf.org; Fri, 31 Oct 2003 14:58:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16216 for ; Fri, 31 Oct 2003 14:57:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFfPE-0006El-00 for megaco-web-archive@ietf.org; Fri, 31 Oct 2003 14:58:00 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFfPD-0006Ei-00 for megaco-web-archive@ietf.org; Fri, 31 Oct 2003 14:57:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFfPF-0001RR-Dx; Fri, 31 Oct 2003 14:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFfOg-0001M1-Fi for megaco@optimus.ietf.org; Fri, 31 Oct 2003 14:57:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16170 for ; Fri, 31 Oct 2003 14:57:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFfOd-0006Di-00 for Megaco@ietf.org; Fri, 31 Oct 2003 14:57:23 -0500 Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AFfOc-0006DA-00 for Megaco@ietf.org; Fri, 31 Oct 2003 14:57:23 -0500 Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by ihemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h9VJteA28130 for ; Fri, 31 Oct 2003 13:56:09 -0600 (CST) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id OAA07241; Fri, 31 Oct 2003 14:55:57 -0500 (EST) Cc: Megaco@ietf.org Received: from bell-labs.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id OAA07237; Fri, 31 Oct 2003 14:55:57 -0500 (EST) Message-ID: <3FA2BEB3.3070105@bell-labs.com> Date: Fri, 31 Oct 2003 14:57:39 -0500 From: Troy Cauble User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 Original-CC: Megaco@ietf.org Subject: Re: [Megaco] IG guide for H248V2 References: <3FA2BAB1.3000606@bell-labs.com> In-Reply-To: <3FA2BAB1.3000606@bell-labs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: megaco-admin@ietf.org Errors-To: megaco-admin@ietf.org X-BeenThere: megaco@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Media Gateway Control List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Troy Cauble wrote: > So where is the latest IG ??? > Never mind. I found it at http://www.itu.int/itudoc/itu-t/com16/implgd/h248ig.html -troy _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco